draft-ietf-tsvwg-admitted-realtime-dscp-01.txt   draft-ietf-tsvwg-admitted-realtime-dscp-02.txt 
Transport Working Group F. Baker Transport Working Group F. Baker
Internet-Draft J. Polk Internet-Draft J. Polk
Updates: 4542,4594 Cisco Systems Updates: 4542,4594 Cisco Systems
(if approved) M. Dolly (if approved) M. Dolly
Intended status: Best Current AT&T Labs Intended status: Best Current AT&T Labs
Practice March 22, 2007 Practice November 16, 2007
Expires: September 23, 2007 Expires: May 19, 2008
DSCPs for Capacity-Admitted Traffic DSCPs for Capacity-Admitted Traffic
draft-ietf-tsvwg-admitted-realtime-dscp-01 draft-ietf-tsvwg-admitted-realtime-dscp-02
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 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 23, 2007. This Internet-Draft will expire on May 19, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document requests two DSCPs from the IANA for real-time traffic This document requests one DSCP from the IANA for real-time traffic
classes similar to voice and video, conforming to the Expedited classes similar to voice conforming to the Expedited Forwarding Per
Forwarding Per Hop Behavior, and admitted using a CAC procedure Hop Behavior, and admitted using a CAC procedure involving
involving authentication, authorization, and capacity admission, as authentication, authorization, and capacity admission, as compared to
compared to a class of real-time traffic conforming to the Expedited a class of real-time traffic conforming to the Expedited Forwarding
Forwarding Per Hop Behavior but not subject to capacity admission or Per Hop Behavior but not subject to capacity admission or subject to
subject to very coarse capacity admission. very coarse capacity admission.
It also recommends that certain classes of video traffic described in
RFC 4594 and which have similar requirements be require admission
using a CAC procedure involving authentication, authorization, and
capacity admission.
One of the reasons behind this is the need for classes of traffic One of the reasons behind this is the need for classes of traffic
that are handled under special policies, such as the non-preemptive that are handled under special policies, such as the non-preemptive
Emergency Telecommunication Service, the US DoD's Assured Service Emergency Telecommunication Service, the US DoD's Assured Service
(which is similar to MLPP), or e-911. These do not need separate (which is similar to MLPP), or e-911. Capacity-admitted traffic
DSCPs or separate PHBs that separate them from each other, but they classes need separation from traffic not subject to admission
need a traffic class that separates them from the traffic not subject control, from which they can deterministically obtain their service
to admission control, from which they can deterministically obtain requirements, including SLA matters.
their service requirements, including SLA matters.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 7 1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . 8
2. Implementation of the Admitted Service Classes . . . . . . . . 7 2. Implementation of the Admitted Service Classes . . . . . . . . 8
2.1. Potential implementations of EF in this model . . . . . . 7 2.1. Potential implementations of EF in this model . . . . . . 8
2.2. Capacity admission control . . . . . . . . . . . . . . . . 9 2.2. Capacity admission control . . . . . . . . . . . . . . . . 10
2.2.1. Capacity admission control by assumption . . . . . . . 9 2.2.1. Capacity admission control by assumption . . . . . . . 10
2.2.2. Capacity admission control by call counting . . . . . 10 2.2.2. Capacity admission control by call counting . . . . . 11
2.2.3. End-point capacity admission performed by probing 2.2.3. End-point capacity admission performed by probing
the network . . . . . . . . . . . . . . . . . . . . . 10 the network . . . . . . . . . . . . . . . . . . . . . 11
2.2.4. Centralized capacity admission control . . . . . . . . 11 2.2.4. Centralized capacity admission control . . . . . . . . 12
2.2.5. Distributed capacity admission control . . . . . . . . 11 2.2.5. Distributed capacity admission control . . . . . . . . 12
2.3. Prioritized capacity admission control . . . . . . . . . . 12 2.3. Prioritized capacity admission control . . . . . . . . . . 13
3. Recommendations on implementation of an Admitted Telephony 3. Recommendations on implementation of an Admitted Telephony
Service Class . . . . . . . . . . . . . . . . . . . . . . . . 13 Service Class . . . . . . . . . . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
This document requests two DSCPs from the IANA for two classes of This document requests one DSCP from the IANA for a class of real-
real-time traffic conforming to the Expedited Forwarding [RFC3246] time traffic conforming to the Expedited Forwarding [RFC3246]
[RFC3247] Per Hop Behavior and admitted using a CAC procedure [RFC3247] Per Hop Behavior and admitted using a CAC procedure
involving authentication, authorization, and capacity admission, as involving authentication, authorization, and capacity admission, as
compared to a class of real-time traffic conforming to the Expedited compared to a class of real-time traffic conforming to the Expedited
Forwarding Per Hop Behavior but not subject to capacity admission or Forwarding Per Hop Behavior but not subject to capacity admission or
subject to very coarse capacity admission. subject to very coarse capacity admission.
It also recommends that certain classes of video described in
[RFC4594] be treated as requiring capacity admission as well.
These applications have one or more potential congestion points
between the video distribution/conferencing bridge or gaming server
and the user(s), and reserving capacity for them is important to
application performance. All of these applications have low
tolerance to jitter (aka delay variation) and loss, as summarized in
Section 2, and most (except for multimedia conferencing) have
inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow
behavior and low jitter/loss tolerance are the service
characteristics that define the need for admission control behavior.
One of the reasons behind this is the need for classes of traffic One of the reasons behind this is the need for classes of traffic
that are handled under special policies, such as the non-preemptive that are handled under special policies, such as the non-preemptive
Emergency Telecommunication Service, the US DoD's Assured Service Emergency Telecommunication Service, the US DoD's Assured Service
(which is similar to MLPP and uses preemption), or e-911, in addition (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 to normal routine calls that use call admission. It is possible to
use control plane protocols to generally restrict session admission use control plane protocols to generally restrict session admission
such that admitted traffic should receive the desired service, and such that admitted traffic should receive the desired service, and
the policy (e.g., routine, National Security or Emergency the policy (e.g. Routine, National Security or Emergency
Preparedness [NS/EP] communications, e-911, etc) need not be signaled Preparedness [NS/EP] communications, e-911, etc) need not be signaled
in a DSCP. However, service providers need to distinguish between in a DSCP. However, service providers need to distinguish between
special-policy traffic and other classes, particularly the existing special-policy traffic and other classes, particularly the existing
VoIP services that perform no capacity admission or only very coarse VoIP services that perform no capacity admission or only very coarse
capacity admission and can exceed their allocated resources. capacity admission and can exceed their allocated resources.
One of these DSCPs applies to the Telephony Service Class described The requested DSCP applies to the Telephony Service Class described
in [RFC4594]. The other applies to the Multimedia Conferencing in [RFC4594]. The video classes addressed include the
Service Class described in the same docuemnt. Other video classes
are not belieevd to be required by the targetted services and to not o interactive real-time traffic (CS4, used for Video conferencing
have the current problem of confusion with unadmitted traffic. and Interactive gaming),
WIthin an ISP and on inter-ISP links (i.e., within networks whose
internal paths are uniform at hundreds of megabits or faster), one o broadcast TV (CS3) for use in a video on demand context, and
would expect all of this traffic to be carried in the Real Time
Traffic Class described in [I-D.ietf-tsvwg-diffserv-class-aggr]. o AF4 Multimedia conferencing (video conferencing).
Other video classes are not believed to be required by the targeted
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 1.1. Definitions
The following terms and acronyms are used in this document. The following terms and acronyms are used in this document.
PHB: A Per-Hop-Behavior (PHB) is the externally observable PHB: A Per-Hop-Behavior (PHB) is the externally observable
forwarding behavior applied at a DS-compliant node to a DS forwarding behavior applied at a DS-compliant node to a DS
behavior aggregate [RFC2475]. It may be thought of as a program behavior aggregate [RFC2475]. It may be thought of as a program
configured on the interface of an Internet host or router, configured on the interface of an Internet host or router,
specified drop probabilities, queuing priorities or rates, and specified drop probabilities, queuing priorities or rates, and
skipping to change at page 5, line 28 skipping to change at page 5, line 45
UNI: A User/Network Interface (UNI) is the interface (often a UNI: A User/Network Interface (UNI) is the interface (often a
physical link or its virtual equivalent) that connects two physical link or its virtual equivalent) that connects two
entities that do not trust each other, and in which one (the user) entities that do not trust each other, and in which one (the user)
purchases connectivity services from the other (the network). purchases connectivity services from the other (the network).
Figure 1 shows two user networks connected by what appears to each Figure 1 shows two user networks connected by what appears to each
of them to be a single network ("The Internet", access to which is of them to be a single network ("The Internet", access to which is
provided by their service provider) which provides connectivity provided by their service provider) which provides connectivity
services to other users. services to other users.
UNIs tend to be the bottlenecks in the Internet, where users
purchase relatively low amounts of bandwidth for cost or service
reasons, and as a result are most subject to congestion issues and
therefore issues requiring traffic conditioning and service
prioritization.
NNI: A Network/Network Interface (NNI) is the interface (often a NNI: A Network/Network Interface (NNI) is the interface (often a
physical link or its virtual equivalent) that connects two physical link or its virtual equivalent) that connects two
entities that trust each other within limits, and in which the two entities that trust each other within limits, and in which the two
are seen as trading services for value. Figure 1 shows three are seen as trading services for value. Figure 1 shows three
service networks that together provide the connectivity services service networks that together provide the connectivity services
that we call "the Internet". They are different administrations that we call "the Internet". They are different administrations
and are very probably in competition, but exchange contracts for and are very probably in competition, but exchange contracts for
connectivity and capacity that enable them to offer specific connectivity and capacity that enable them to offer specific
services to their customers. services to their customers.
NNIs are not as commonly bottlenecks in the Internet, because
service providers contractually agree to provision serious amounts
of excess capacity at them. However, they are policy-controlled
interfaces (especially in BGP), and therefore may require policy
to be applied in traffic prioritization.
Queue: There are multiple ways to build a multi-queue scheduler. Queue: There are multiple ways to build a multi-queue scheduler.
Weighted Round Robin (WRR) literally builds multiple lists and Weighted Round Robin (WRR) literally builds multiple lists and
visits them in a specified order, while a calendar queue (often visits them in a specified order, while a calendar queue (often
used to implement Weighted Fair Queuing,or WFQ) builds a list for used to implement Weighted Fair Queuing,or WFQ) builds a list for
each time interval and enqueues at most a stated amount of data in each time interval and enqueues at most a stated amount of data in
each such list for transmission during that time interval. While each such list for transmission during that time interval. While
these differ dramatically in implementation, the external these differ dramatically in implementation, the external
difference in behavior is generally negligible when they are difference in behavior is generally negligible when they are
properly configured. Consistent with the definitions used in the properly configured. Consistent with the definitions used in the
Differentiated Services Architecture [RFC2475], these are treated Differentiated Services Architecture [RFC2475], these are treated
skipping to change at page 14, line 19 skipping to change at page 15, line 19
This note requests that IANA assign a DSCP value to a second EF This note requests that IANA assign a DSCP value to a second EF
traffic class consistent with [RFC3246] and [RFC3247]. It implements traffic class consistent with [RFC3246] and [RFC3247]. It implements
the Telephony Service Class described in [RFC4594] at lower speeds the Telephony Service Class described in [RFC4594] at lower speeds
and is included in the Real Time Treatment Aggregate and is included in the Real Time Treatment Aggregate
[I-D.ietf-tsvwg-diffserv-class-aggr] at higher speeds. The [I-D.ietf-tsvwg-diffserv-class-aggr] at higher speeds. The
recommended value for the code point 101101, paralleling the EF code recommended value for the code point 101101, paralleling the EF code
point, which is 101110, and is allocated from the pool set aside for point, which is 101110, and is allocated from the pool set aside for
experimental use but potentially available for standards use as well experimental use but potentially available for standards use as well
in [RFC2474]. The code point should be referred to as VOICE-ADMIT. in [RFC2474]. The code point should be referred to as VOICE-ADMIT.
Additionally, it requests that IANA assign a DSCP value to a traffic This traffic class requires the use of capacity admission such as
class consistent with [RFC2597]. It implements the Multimedia RSVP services together with AAA services at the User/Network
Conferencing Service Class described in [RFC4594] at lower speeds and Interface (UNI); the use of such services at the NNI is at the option
is included in the Real Time Treatment Aggregate of the interconnected networks.
[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.
5. Security Considerations 5. Security Considerations
A major requirement of this service is effective use of a signaling A major requirement of this service is effective use of a signaling
protocol such as RSVP, with the capabilities to identify its user protocol such as RSVP, with the capabilities to identify its user
either as an individual or as a member of some corporate entity, and either as an individual or as a member of some corporate entity, and
assert a policy such as "routine" or "priority". assert a policy such as "routine" or "priority".
This capability, one has to believe, will be abused by script kiddies 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 and others if the proof of identity is not adequately strong or if
policies are written or implemented improperly by the carriers. This policies are written or implemented improperly by the carriers. This
goes without saying, but this section is here for it to be said... goes without saying, but this section is here for it to be said...
6. Acknowledgements 6. Acknowledgements
Kwok Ho Chan offered some textual comments and rewrote Section 2.2.3. Kwok Ho Chan offered some textual comments and rewrote Section 2.2.3.
Georgios Karagiannis offered additional comments on the same section. Georgios Karagiannis offered additional comments on the same section.
The impetus for including Video in the discussion, which initially The impetus for including Video in the discussion, which initially
only targetted voice, is from Dave McDysan. only targeted voice, is from Dave McDysan, and text he suggested was
included.
7. References 7. References
7.1. Normative 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-01 (work in
progress), October 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. 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, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002. 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, 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 7.2. Informative References
[I-D.briscoe-tsvwg-cl-architecture] [I-D.briscoe-tsvwg-cl-architecture]
Briscoe, B., "An edge-to-edge Deployment Model for Pre- Briscoe, B., "An edge-to-edge Deployment Model for Pre-
Congestion Notification: Admission Control over a Congestion Notification: Admission Control over a
DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04 DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04
(work in progress), October 2006. (work in progress), October 2006.
[I-D.briscoe-tsvwg-cl-phb] [I-D.briscoe-tsvwg-cl-phb]
Briscoe, B., "Pre-Congestion Notification marking", Briscoe, B., "Pre-Congestion Notification marking",
draft-briscoe-tsvwg-cl-phb-03 (work in progress), draft-briscoe-tsvwg-cl-phb-03 (work in progress),
October 2006. October 2006.
[I-D.chan-pcn-problem-statement] [I-D.chan-pcn-problem-statement]
Chan, K., "Pre-Congestion Notification Problem Statement", Chan, K., "Pre-Congestion Notification Problem Statement",
draft-chan-pcn-problem-statement-01 (work in progress), draft-chan-pcn-problem-statement-01 (work in progress),
October 2006. October 2006.
[I-D.charny-pcn-single-marking] [I-D.charny-pcn-single-marking]
Charny, A., "Pre-Congestion Notification Using Single Charny, A., "Pre-Congestion Notification Using Single
Marking for Admission and Pre-emption", Marking for Admission and Termination",
draft-charny-pcn-single-marking-00 (work in progress), draft-charny-pcn-single-marking-02 (work in progress),
October 2006. July 2007.
[I-D.ietf-tsvwg-diffserv-class-aggr]
Chan, K., Babiarz, J., and F. Baker, "Aggregation of
DiffServ Service Classes",
draft-ietf-tsvwg-diffserv-class-aggr-07 (work in
progress), November 2007.
[I-D.morita-tsvwg-pps] [I-D.morita-tsvwg-pps]
Morita, N. and G. Karlsson, "Framework of Priority Morita, N. and G. Karlsson, "Framework of Priority
Promotion Scheme", draft-morita-tsvwg-pps-01 (work in Promotion Scheme", draft-morita-tsvwg-pps-01 (work in
progress), October 2003. progress), October 2003.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", Services in the Internet Architecture: an Overview",
RFC 1633, June 1994. RFC 1633, June 1994.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, [RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell,
M., Romanow, A., Weinrib, A., and L. Zhang, "Resource M., Romanow, A., Weinrib, A., and L. Zhang, "Resource
ReSerVation Protocol (RSVP) Version 1 Applicability ReSerVation Protocol (RSVP) Version 1 Applicability
Statement Some Guidelines on Deployment", RFC 2208, Statement Some Guidelines on Deployment", RFC 2208,
September 1997. September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904, D. Spence, "AAA Authorization Framework", RFC 2904,
August 2000. August 2000.
[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.
[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, April 2002.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002. Protocol (SIP)", RFC 3312, October 2002.
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Supporting Emergency Telecommunications Service (ETS) in Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005. IP Telephony", RFC 4190, November 2005.
[RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
Device Requirements and Configuration", RFC 4504, Device Requirements and Configuration", RFC 4504,
May 2006. May 2006.
[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.
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Phone: +1-408-526-4257 Phone: +1-408-526-4257
Email: fred@cisco.com Email: fred@cisco.com
 End of changes. 25 change blocks. 
99 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/