--- 1/draft-ietf-tsvwg-admitted-realtime-dscp-00.txt 2007-03-28 17:12:16.000000000 +0200 +++ 2/draft-ietf-tsvwg-admitted-realtime-dscp-01.txt 2007-03-28 17:12:16.000000000 +0200 @@ -1,21 +1,21 @@ -Please post the attached as a working group document in tsvwg Transport Working Group F. Baker Internet-Draft J. Polk -Updates: 4542,4594 (if approved) Cisco Systems -Intended status: Informational M. Dolly -Expires: June 14, 2007 AT&T Labs - December 13, 2006 +Updates: 4542,4594 Cisco Systems +(if approved) M. Dolly +Intended status: Best Current AT&T Labs +Practice March 22, 2007 +Expires: September 23, 2007 - An EF DSCP for Capacity-Admitted Traffic - draft-ietf-tsvwg-admitted-realtime-dscp-00 + DSCPs for Capacity-Admitted Traffic + draft-ietf-tsvwg-admitted-realtime-dscp-01 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -26,98 +26,110 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 14, 2007. + This Internet-Draft will expire on September 23, 2007. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). Abstract - This document requests a DSCP from the IANA for a class of real-time - traffic conforming to the Expedited Forwarding Per Hop Behavior and - admitted using a CAC procedure involving authentication, - authorization, and capacity admission, as compared to a class of - real-time traffic conforming to the Expedited Forwarding Per Hop - Behavior but not subject to capacity admission or subject to very - coarse capacity admission. + This document requests two DSCPs from the IANA for real-time traffic + classes similar to voice and video, conforming to the Expedited + Forwarding Per Hop Behavior, and admitted using a CAC procedure + involving authentication, authorization, and capacity admission, as + compared to a class of real-time traffic conforming to the Expedited + Forwarding Per Hop Behavior but not subject to capacity admission or + subject to very coarse capacity admission. One of the reasons behind this is the need for classes of traffic that are handled under special policies, such as the non-preemptive Emergency Telecommunication Service, the US DoD's Assured Service (which is similar to MLPP), or e-911. These do not need separate - DSCPs or separate PHBs that are separate from each other, but they - need a traffic class from which they can deterministically obtain - their service requirements from including SLA matters. + DSCPs or separate PHBs that separate them from each other, but they + need a traffic class that separates them from the traffic not subject + to admission control, from which they can deterministically obtain + their service requirements, including SLA matters. + +Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 6 - 2. Implementation of the Admitted Telephony Service Class . . . . 6 - 2.1. Potential implementations of EF in this model . . . . . . 6 - 2.2. Capacity admission control . . . . . . . . . . . . . . . . 8 - 2.2.1. Capacity admission control by assumption . . . . . . . 8 - 2.2.2. Capacity admission control by call counting . . . . . 9 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 7 + 2. Implementation of the Admitted Service Classes . . . . . . . . 7 + 2.1. Potential implementations of EF in this model . . . . . . 7 + 2.2. Capacity admission control . . . . . . . . . . . . . . . . 9 + 2.2.1. Capacity admission control by assumption . . . . . . . 9 + 2.2.2. Capacity admission control by call counting . . . . . 10 2.2.3. End-point capacity admission performed by probing - the network . . . . . . . . . . . . . . . . . . . . . 9 - 2.2.4. Centralized capacity admission control . . . . . . . . 10 + the network . . . . . . . . . . . . . . . . . . . . . 10 + 2.2.4. Centralized capacity admission control . . . . . . . . 11 2.2.5. Distributed capacity admission control . . . . . . . . 11 - 2.3. Prioritized capacity admission control . . . . . . . . . . 11 + 2.3. Prioritized capacity admission control . . . . . . . . . . 12 3. Recommendations on implementation of an Admitted Telephony - Service Class . . . . . . . . . . . . . . . . . . . . . . . . 12 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 - Intellectual Property and Copyright Statements . . . . . . . . . . 17 + Service Class . . . . . . . . . . . . . . . . . . . . . . . . 13 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 + Intellectual Property and Copyright Statements . . . . . . . . . . 19 1. Introduction - This document requests a DSCP from the IANA for a class of real-time - traffic conforming to the Expedited Forwarding [RFC3246][RFC3247] Per - Hop Behavior and admitted using a CAC procedure involving - authentication, authorization, and capacity admission, as compared to - a class of real-time traffic conforming to the Expedited Forwarding - Per Hop Behavior but not subject to capacity admission or subject to - very coarse capacity admission. + This document requests two DSCPs from the IANA for two classes of + real-time traffic conforming to the Expedited Forwarding [RFC3246] + [RFC3247] Per Hop Behavior and admitted using a CAC procedure + involving authentication, authorization, and capacity admission, as + compared to a class of real-time traffic conforming to the Expedited + Forwarding Per Hop Behavior but not subject to capacity admission or + subject to very coarse capacity admission. One of the reasons behind this is the need for classes of traffic that are handled under special policies, such as the non-preemptive Emergency Telecommunication Service, the US DoD's Assured Service (which is similar to MLPP and uses preemption), or e-911, in addition to normal routine calls that use call admission. It is possible to use control plane protocols to generally restrict session admission such that admitted traffic should receive the desired service, and - the policy (e.g., routine, NS/EP, e-911, etc) need not be signaled in - a DSCP. However, service providers need to distinguish between + the policy (e.g., routine, National Security or Emergency + Preparedness [NS/EP] communications, e-911, etc) need not be signaled + in a DSCP. However, service providers need to distinguish between special-policy traffic and other classes, particularly the existing VoIP services that perform no capacity admission or only very coarse capacity admission and can exceed their allocated resources. - This DSCP applies to the Telephony Service Class described in - [RFC4594]. WIthin an ISP and on inter-ISP links (i.e., within - networks whose internal paths are uniform at hundreds of megabits or - faster), one would expect this traffic to be carried in the Real Time + One of these DSCPs applies to the Telephony Service Class described + in [RFC4594]. The other applies to the Multimedia Conferencing + Service Class described in the same docuemnt. Other video classes + are not belieevd to be required by the targetted services and to not + have the current problem of confusion with unadmitted traffic. + WIthin an ISP and on inter-ISP links (i.e., within networks whose + internal paths are uniform at hundreds of megabits or faster), one + would expect all of this traffic to be carried in the Real Time Traffic Class described in [I-D.ietf-tsvwg-diffserv-class-aggr]. 1.1. Definitions The following terms and acronyms are used in this document. PHB: A Per-Hop-Behavior (PHB) is the externally observable forwarding behavior applied at a DS-compliant node to a DS behavior aggregate [RFC2475]. It may be thought of as a program configured on the interface of an Internet host or router, @@ -208,45 +220,45 @@ In short, the Telephony Service Class described in [RFC4594] permits the use of capacity admission in implementing the service, but present implementations either provide no capacity admission services or do so in a manner that depends on specific traffic engineering. In the context of the Internet backbone, the two are essentially equivalent; the edge network is depending on specific engineering by the service provider that may not be present. However, services are being requested of the network that would specifically make use of capacity admission, and would distinguish - among users or the uses of available Voice-on-IP capacity in various - ways. Various agencies would like to provide services as described - in section 2.6 of [RFC4504] or in [RFC4190]. This requires the use - of capacity admission to differentiate among users (which might be - 911 call centers, other offices with preferential service contracts, - or individual users gaining access with special credentials) to - provide services to them that are not afforded to routine customer- - to-customer IP telephony sessions. + among users or the uses of available Voice-on-IP or Video-on-IP + capacity in various ways. Various agencies would like to provide + services as described in section 2.6 of [RFC4504] or in [RFC4190]. + This requires the use of capacity admission to differentiate among + users (which might be 911 call centers, other offices with + preferential service contracts, or individual users gaining access + with special credentials) to provide services to them that are not + afforded to routine customer-to-customer IP telephony sessions. 1.3. Proposed Solution The IETF is asked to differentiate, in the Telephony Service, between sessions that are originated without capacity admission or using traffic engineering and sessions that are originated using more robust capacity admission procedures. Sessions of the first type use a traffic class in which they compete without network-originated control as described in Section 2.2.1 or Section 2.2.2, and in the worst case lose traffic due to policing. Sessions of the second type cooperate with network control, and may be given different levels of preference depending on the policies that the network applies. In order to provide this differentiation, the IETF requests that the IANA assign a separate DSCP value to admitted sessions using the Telephony service (see Section 4). -2. Implementation of the Admitted Telephony Service Class +2. Implementation of the Admitted Service Classes 2.1. Potential implementations of EF in this model There are at least two possible ways to implement the Expedited Forwarding PHB in this model. They are to implement separate classes as a set of o Multiple data plane traffic classes, each consisting of a policer and a queue, and the queues enjoying different priorities, or @@ -330,21 +342,21 @@ If, on the other hand, the two traffic classes are carrying the same type of application with the same jitter requirements, then giving one preference in this sense does not benefit the higher priority traffic and may harm the lower priority traffic. In such a case, using separate policers and a common queue is a superior approach. 2.2. Capacity admission control There are five major ways that capacity admission is done or has been - proposed to be done in Internet Voice applications: + proposed to be done in real-time applications: o Capacity admission control by assumption, o Capacity admission control by call counting, o End-point capacity admission performed by probing the network, o Centralized capacity admission control, and o Distributed capacity admission control @@ -354,30 +366,30 @@ The first approach is to ignore the matter entirely. If one assumes that the capacity available to the application is uniformly far in excess of its requirements, it is perhaps overhead that can be ignored. This assumption is currently made in Internet VoIP offerings such as Skype and Vonage; the end user is responsible to place his service on a LAN connected to the Internet backbone by a high speed broadband connection and use capable ISPs to deliver the service. There is an authorization step in the sense that the service ensures that the user pays his bills, but no capacity admission is considered because there is a clear separation from the - voice application service provider admitting the calls and the access + application service provider admitting the calls and the access network provider admitting the traffic. The two have no way of knowing about each other, except maybe in the abstract sense. 2.2.2. Capacity admission control by call counting The H.323 gatekeeper, originally specified in 1996, operates on the model that the considerations of Section 2.2.1 generally apply, and that it is therefore sufficient to count calls in order to ensure - that any bottlenecks in the network are never overloaded. . Which + that any bottlenecks in the network are never overloaded. Which phone is calling which phone is configured information into the Gatekeeper, ensuring it doesn't admit too many calls across a low speed link. The area of influence of a Gatekeeper is called a Zone, and limits how far away a Gatekeeper can influence calls. This is because call counting doesn't scale when more than one server is admitting flows across the same limited speed links. This approach is consistent with the original design of H.323, which in 1996 was a mechanism for connecting H.320 media gateways across a LAN. VoIP has come a long way since then, however, and the engineering trade-offs this approach requires in complex networks are unsatisfactory. @@ -392,89 +404,84 @@ or do not configure the use of [RFC3312], or other call management systems, the amount of traffic between the two must be contained below that bottleneck even if the normal path is of much higher bandwidth. In addition, the multiplexing of traffic streams between different pairs of gatekeepers over a common LAN infrastructure is not handled by the application, and so must be managed in the engineering of the network. 2.2.3. End-point capacity admission performed by probing the network - [I-D.briscoe-tsvwg-cl-architecture] is one of many proposals that - have looked at probing of the network by the end system to determine - its capacity to accept a new session. Such proposals have been made - a number of times by the likes of NTT Labs, UIUC researchers, Cisco - Systems (which used its Service Assurance Architecture to probe - capacity using pings and report when network delay variability - increased), and others. Many of the proposals tested in research - have fared reasonably well in high bandwidth environments where - actual network congestion is unusual, but have not scaled down to - slower access links. + The IETF started looking into the use of Pre-Congestion Notification + mechanism to full fill the need of admission control for real-time + traffic. The main contribution of this work for admission control is + to allow the network to provide the network's pre-congestion + information using encoding of a field in the IP header. This network + pre-congestion information is then used for making admission control + decisions. With the decision influenced by this network pre- + congestion notification information and any applicable policy + information with possible user credentials and situational + information. The pre-congestion notification mechanism does not + limit the placement of the admission control decision point or the + signaling protocol used. - The problem has been, in essence, that variable rate codecs can be on - the quiet side of the average for lengthy periods of time and then - become noisier. New sessions can be disrupted or disrupt existing - sessions if they perform their capacity admission procedures at a - quiet time and find themselves overrunning the allocated capacity - during a noisy time. In addition, for a service in which the network - must exercise control and differentiate among users, the users cannot - be depended on to differentiate among themselves in the network's - favor. The network must manage that service. + The overview of one of the current proposals is provided by + [I-D.chan-pcn-problem-statement]. With the pre-congestion + notification encoding described in [I-D.briscoe-tsvwg-cl-phb]. An + initial deployment model provided by + [I-D.briscoe-tsvwg-cl-architecture]. Another proposal is embodied in + [I-D.charny-pcn-single-marking]. Similar approaches have been + proposed in [I-D.morita-tsvwg-pps] and its related drafts, by Ivars + and Karlsson in their PBAC work, and many others. - For this reason, [I-D.briscoe-tsvwg-cl-architecture] is only proposed - as a solution within backbone networks, leaving access networks to - provide other forms of capacity admission, and more generally such - techniques are only recommended in high bandwidth contexts. What is - not addressed, is when these quite times become not-at-all quite due - to some event occurring, leading to great amounts of traffic. A - means of maintaining existing critical calls is essential to retain a - given service. Times of disaster can be such times of extreme bursts - of the number of call attempts. Once a call is established, that - call needs to be retained. + Current simulation work have shown the pre-congestion notification + mechanism works well with large number of audio and video flows on + high speed lines. This work is ongoing. 2.2.4. Centralized capacity admission control The concept of a Bandwidth Broker was first discussed in the research world surrounding ESNET and Internet II in the late 1990's, and has been discussed in the literature pertaining to the Differentiated Services Architecture [RFC2475]. It is, in short, a central system that performs a variety of services on behalf of clients of a network - including applying AAA services (as in [RFC2904])and authorizing them - to use specified capacity at specified times. Its strength is that - it is relatively simple, at least in concept, and can keep track of - simple book-keeping functions apart from network elements such as + including applying AAA services (as in [RFC2904] )and authorizing + them to use specified capacity at specified times. Its strength is + that it is relatively simple, at least in concept, and can keep track + of simple book-keeping functions apart from network elements such as routers. Its weakness is that it has no idea what the specific routing of any stated data flow is, or its capacity apart from services such as MPLS Traffic Engineering or engineering assumptions specified by the designers of a network, and obtaining that information from the network via SNMP GET or other network management action can impose a severe network overhead, and is obviously not in real-time. For scaling reasons, operational Bandwidth Brokers generally take on a semi-distributed or fully distributed nature. They are implemented on a per-point-of-presence basis, and in satellite networks might be implemented in each terminal. At this point, they become difficult to operationally distinguish from distributed capacity admission services such as described in Section 2.2.5. 2.2.5. Distributed capacity admission control The IETF developed the Integrated Services Model [RFC1633]and the RSVP capacity admission protocol [RFC2205] in the early 1990's, and then integrated it with the Differentiated Services Architecture in - [RFC2998]. Since then, the IETF has worked to describe a next - generation capacity admission protocol, which is calls NSIS, and - which is limited in scope to considering unicast sessions. [RFC4542] - looked at the issue of providing preferential services in the - Internet, and determined that RSVP with its defined extensions could - provide those services to unicast and multicast sessions. + [RFC2998]. Since then, the IETF has been working on a next + generation signaling protocol called NSIS that can be used for + capacity admission protocol, and which is limited in scope to + considering unicast sessions. [RFC4542] looked at the issue of + providing preferential services in the Internet, and determined that + RSVP with its defined extensions could provide those services to + unicast and multicast sessions. As with the Bandwidth Broker model, there are concerns regarding scaling, mentioned in [RFC2208]. Present implementations that have been measured have been found to not display the scaling concerns, however, and in any event the use of RSVP Aggregation enables the backbone to handle such sessions in a manner similar to an ATM Virtual Path, bundling sessions together for capacity management purposes. 2.3. Prioritized capacity admission control @@ -532,126 +539,173 @@ thresholds can be applied to the critical points of the path that the traffic in question actually takes because one is asking the equipment that the path traverses. 3. Recommendations on implementation of an Admitted Telephony Service Class It is the belief of the authors that either data plane PHB described in Section 2.1, if coupled with adequate AAA and capacity admission procedures as described in Section 2.2.5, are sufficient to provide - the services required for an Admitted Telephony service class. If - preemption is in view, as described in section 2.3.5.2 or [RFC4542], - this provides the tools for carrying out the preemption. If - preemption is not in view, or in addition to preemptive services, the - application of different thresholds depending on call precedence has - the effect of improving the probability of call completion by - admitting preferred calls at a time that other calls are being - refused. Routine and priority traffic can be admitted using the same - DSCP value, as the choice of which calls are admitted is handled in - the admission procedure executed in the control plane, not the - policing of the data plane. + the services required for an Admitted Telephony service class and an + Admitted Multimedia Conferencing Service Class. If preemption is in + view, as described in section 2.3.5.2 of [RFC4542], this provides the + tools for carrying out the preemption. If preemption is not in view, + or in addition to preemptive services, the application of different + thresholds depending on call precedence has the effect of improving + the probability of call completion by admitting preferred calls at a + time that other calls are being refused. Routine and priority + traffic can be admitted using the same DSCP value, as the choice of + which calls are admitted is handled in the admission procedure + executed in the control plane, not the policing of the data plane. On the point of what protocols and procedures are required for authentication, authorization, and capacity admission, we note that clear standards do not at this time exist for bandwidth brokers, NSIS has not at this time been finalized and in any event is limited to unicast sessions, and that RSVP has been standardized and has the relevant services. We therefore recommend the use of RSVP at the UNI. Procedures at the NNI are business matters to be discussed between the relevant networks, and are recommended but not required. 4. IANA Considerations - This note, fundamentally, requests IANA the assign a DSCP value to a - second EF traffic class consistent with [RFC3246] and [RFC3247] and - implementing the Telephony Service Class described in [RFC4594] at - lower speeds and [I-D.ietf-tsvwg-diffserv-class-aggr] at higher - speeds. This new traffic class requires the use of capacity + This note requests that IANA assign a DSCP value to a second EF + traffic class consistent with [RFC3246] and [RFC3247]. It implements + the Telephony Service Class described in [RFC4594] at lower speeds + and is included in the Real Time Treatment Aggregate + [I-D.ietf-tsvwg-diffserv-class-aggr] at higher speeds. The + recommended value for the code point 101101, paralleling the EF code + point, which is 101110, and is allocated from the pool set aside for + experimental use but potentially available for standards use as well + in [RFC2474]. The code point should be referred to as VOICE-ADMIT. + + Additionally, it requests that IANA assign a DSCP value to a traffic + class consistent with [RFC2597]. It implements the Multimedia + Conferencing Service Class described in [RFC4594] at lower speeds and + is included in the Real Time Treatment Aggregate + [I-D.ietf-tsvwg-diffserv-class-aggr] at higher speeds. The + recommended value for the code point 100101, paralleling the AF42 + code point, which is 100100, and is allocated from the pool set aside + for experimental use but potentially available for standards use as + well in [RFC2474]. The code point should be referred to as VIDEO- + ADMIT. + + Both of these new traffic classes require the use of capacity admission such as RSVP services together with AAA services at the User/Network Interface (UNI); the use of such services at the NNI is - at the option of the interconnected networks. The recommended value - for the code point 101100, paralleling the EF code point, which is - 101110, and both of which are allocated from Pool 1 as described in - [RFC2474]. - - The code point should be referred to as EF-ADMIT. + at the option of the interconnected networks. 5. Security Considerations A major requirement of this service is effective use of a signaling protocol such as RSVP, with the capabilities to identify its user either as an individual or as a member of some corporate entity, and assert a policy such as "routine" or "priority". This capability, one has to believe, will be abused by script kiddies and others if the proof of identity is not adequately strong or if policies are written or implemented improperly by the carriers. This goes without saying, but this section is here for it to be said... 6. Acknowledgements + Kwok Ho Chan offered some textual comments and rewrote Section 2.2.3. + Georgios Karagiannis offered additional comments on the same section. + The impetus for including Video in the discussion, which initially + only targetted voice, is from Dave McDysan. + 7. References 7.1. Normative References [I-D.ietf-tsvwg-diffserv-class-aggr] Chan, K., "Aggregation of DiffServ Service Classes", - draft-ietf-tsvwg-diffserv-class-aggr-00 (work in - progress), June 2006. + draft-ietf-tsvwg-diffserv-class-aggr-01 (work in + progress), October 2006. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. + [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, + "Assured Forwarding PHB Group", RFC 2597, June 1999. + [RFC2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000. [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Ramakrishnan, "Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior)", RFC 3247, March 2002. [RFC3260] Grossman, D., "New Terminology and Clarifications for - Diffserv", RFC 3260, June 14002. + Diffserv", RFC 3260, April 2002. [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite", RFC 4542, May 2006. + [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration + Guidelines for DiffServ Service Classes", RFC 4594, + August 2006. + 7.2. Informative References [I-D.briscoe-tsvwg-cl-architecture] Briscoe, B., "An edge-to-edge Deployment Model for Pre- Congestion Notification: Admission Control over a - DiffServ Region", draft-briscoe-tsvwg-cl-architecture-03 - (work in progress), June 2006. + DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 + (work in progress), October 2006. + + [I-D.briscoe-tsvwg-cl-phb] + Briscoe, B., "Pre-Congestion Notification marking", + draft-briscoe-tsvwg-cl-phb-03 (work in progress), + October 2006. + + [I-D.chan-pcn-problem-statement] + Chan, K., "Pre-Congestion Notification Problem Statement", + draft-chan-pcn-problem-statement-01 (work in progress), + October 2006. + + [I-D.charny-pcn-single-marking] + Charny, A., "Pre-Congestion Notification Using Single + Marking for Admission and Pre-emption", + draft-charny-pcn-single-marking-00 (work in progress), + October 2006. + + [I-D.morita-tsvwg-pps] + Morita, N. and G. Karlsson, "Framework of Priority + Promotion Scheme", draft-morita-tsvwg-pps-01 (work in + progress), October 2003. [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. - Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997. [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., @@ -664,41 +718,37 @@ Protocol (SIP)", RFC 3312, October 2002. [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005. [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony Device Requirements and Configuration", RFC 4504, May 2006. - [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration - Guidelines for DiffServ Service Classes", RFC 4594, - August 2006. - Authors' Addresses Fred Baker Cisco Systems Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Email: fred@cisco.com + James Polk Cisco Systems Richardson, Texas 75082 USA Phone: +1-817-271-3552 Email: jmpolk@cisco.com - Martin Dolly AT&T Labs Middletown Township, New Jersey 07748 USA Phone: +1-732-420-4574 Email: mdolly@att.com Full Copyright Statement @@ -695,32 +745,32 @@ Martin Dolly AT&T Labs Middletown Township, New Jersey 07748 USA Phone: +1-732-420-4574 Email: mdolly@att.com Full Copyright Statement - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information