draft-ietf-ieprep-domain-req-05.txt   draft-ietf-ieprep-domain-req-06.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
Sep 12, 2005 Nov 17, 2005
Emergency Telecommunications Services (ETS) Requirements Emergency Telecommunications Services (ETS) Requirements
for a Single Administrative Domain for a Single Administrative Domain
<draft-ietf-ieprep-domain-req-05.txt> <draft-ietf-ieprep-domain-req-06.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 4, line 39 skipping to change at page 4, line 39
in requirements because there may be fewer bits (a smaller field) in requirements because there may be fewer bits (a smaller field)
available at the network layer than in the transport or application available at the network layer than in the transport or application
layer. layer.
3.2 Proxies 3.2 Proxies
Proxies MAY set ETS labels on behalf of the source of a flow. This Proxies MAY set ETS labels on behalf of the source of a flow. This
may involve removing labels that have been set by upstream node(s). may involve removing labels that have been set by upstream node(s).
If proxies take such action, then the security measures discussed in If proxies take such action, then the security measures discussed in
[rfc3689] MUST be considered. More discussion about security in the [rfc3689] MUST be considered. More information about security in the
single domain context is discussed in section 5. single domain context is found below in Section 5.
3.3 QoS mechanisms 3.3 QoS mechanisms
[rfc3689] defines a label as an identifier, and the set of [rfc3689] defines a label as an identifier, and the set of
characteristics associated with the label as policy. However, characteristics associated with the label as policy. However,
Quality of Service (QoS) in the traditional sense of delay or Quality of Service (QoS) in the traditional sense of delay or
bandwidth is not automatically bound to a label. MPLS [rfc3031] is bandwidth is not automatically bound to a label. MPLS [rfc3031] is
an example of a labeling mechanism that can provide specific QoS or an example of a labeling mechanism that can provide specific QoS or
simply traffic engineering of labeled flows. simply traffic engineering of labeled flows.
skipping to change at page 5, line 20 skipping to change at page 5, line 20
links. links.
Note well. Over-provisioning is a normal cost-effective practice Note well. Over-provisioning is a normal cost-effective practice
amongst network administrators/engineers. The amount of over- amongst network administrators/engineers. The amount of over-
provisioning can be a topic of debate. More in-depth discussion on provisioning can be a topic of debate. More in-depth discussion on
this topic is presented in the companion Framework document of this topic is presented in the companion Framework document of
[frame]. [frame].
3.4 Users 3.4 Users
Any application layer label mechanisms used to support ETS MUST be Regarding existing IETF specified applications, augmentations in the
capable of supporting both the set of ETS and non-ETS (presumably, form of labeling mechanisms to support ETS MUST NOT adversely affect
normal) users. its legacy usage by non-ETS users. With respect to future
applications, such labeling mechanisms SHOULD allow the application
to support a "normal" (non-emergency) condition.
3.5 Policy 3.5 Policy
Policy MUST be used to determine the percentage of resources of a Policy MUST be used to determine the percentage of resources of a
mechanism used to support the various (ETS and non-ETS) users. Under mechanism used to support the various (ETS and non-ETS) users. Under
certain conditions, this percentage MAY reach 100% for a specific set certain conditions, this percentage MAY reach 100% for a specific set
of users. However, we recommend that this "all-or-nothing" approach of users. However, we recommend that this "all-or-nothing" approach
be considered with great care. be considered with great care.
3.6 Discovery 3.6 Discovery
 End of changes. 4 change blocks. 
7 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/