draft-ietf-tsvwg-admitted-realtime-dscp-06.txt   draft-ietf-tsvwg-admitted-realtime-dscp-07.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: Standards Track AT&T Labs Intended status: Standards Track AT&T Labs
Expires: June 4, 2010 December 4, 2009 Expires: Sept 8, 2010 March 8, 2010
DSCP for Capacity-Admitted Traffic DSCP for Capacity-Admitted Traffic
draft-ietf-tsvwg-admitted-realtime-dscp-06 draft-ietf-tsvwg-admitted-realtime-dscp-07
Abstract Abstract
This document requests one Differentiated Services Code Point (DSCP) This document requests one Differentiated Services Code Point (DSCP)
from the Internet Assigned Numbers Authority (IANA) for real-time from the Internet Assigned Numbers Authority (IANA) for a class of
traffic classes similar to voice conforming to the Expedited real-time traffic. This class conforms to the Expedited Forwarding
Forwarding Per Hop Behavior, and admitted using a call admission Per Hop Behavior. It is also admitted using a CAC procedure
procedure involving authentication, authorization, and capacity
admission.
This document also recommends that certain classes of video traffic
described in RFC 4594 and which have similar requirements be changed
to require admission using a Call Admission Control (CAC) procedure
involving authentication, authorization, and capacity admission. involving authentication, authorization, and capacity admission.
This differs from a real-time traffic class conforming to the
Expedited Forwarding Per Hop Behavior but not subject to capacity
admission or subject to very coarse capacity admission.
Legal
This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 48 skipping to change at page 2, line 6
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference 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 June 4, 2010. This Internet-Draft will expire on September 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 42 skipping to change at page 2, line 49
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Candidate Implementations of the Admitted Telephony 2. Candidate Implementations of the Admitted Telephony
Service Class . . . . . . . . . . . . . . . . . . . . . . . 7 Service Class . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Potential implementations of EF in this model . . . . . . 7 2.1. Potential implementations of EF in this model . . . . . . 7
2.2. Capacity admission control . . . . . . . . . . . . . . . 9 2.2. Capacity admission control . . . . . . . . . . . . . . . 8
2.3. Recommendations on implementation of an Admitted 2.3. Recommendations on implementation of an Admitted
Telephony Service Class . . . . . . . . . . . . . . . . . 10 Telephony Service Class . . . . . . . . . . . . . . . . . 10
3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . 11 3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
skipping to change at page 3, line 19 skipping to change at page 3, line 24
real-time traffic. This class conforms to the Expedited Forwarding real-time traffic. This class conforms to the Expedited Forwarding
[RFC3246] [RFC3247] Per Hop Behavior. It is also admitted using a [RFC3246] [RFC3247] Per Hop Behavior. It is also admitted using a
CAC procedure involving authentication, authorization, and capacity CAC procedure involving authentication, authorization, and capacity
admission. This differs from a real-time traffic class conforming admission. This differs from a real-time traffic class conforming
to the Expedited Forwarding Per Hop Behavior but not subject to to the Expedited Forwarding Per Hop Behavior but not subject to
capacity admission or subject to very coarse capacity admission. capacity admission or subject to very coarse capacity admission.
It also recommends that certain classes of video described in It also recommends that certain classes of video described in
[RFC4594] be treated as requiring capacity admission as well. [RFC4594] be treated as requiring capacity admission as well.
These applications have one or more potential congestion points Real-time traffic flows have one or more potential congestion points
between the endpoints. Reserving capacity for them is important to between the endpoints. Reserving capacity for these flows is
application performance. All of these applications have low important to application performance. All of these applications
tolerance to jitter (aka delay variation) and loss, as summarized in have low tolerance to jitter (aka delay variation) and loss, as
Section 2, and most (except for multimedia conferencing) have summarized in Section 2, and most (except for multimedia
inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow conferencing) have inelastic flow behavior from Figure 1 of
behavior and low jitter/loss tolerance are the service [RFC4594]. Inelastic flow behavior and low jitter/loss tolerance
characteristics that define the need for admission control behavior. 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. Service providers need to
Emergency Telecommunication Service, the US Department of Defense's distinguish between special-policy traffic and other classes,
Assured Service (which is similar to Multi-Level Precedence and particularly the existing VoIP services that perform no capacity
Preemption [ITU.MLPP.1990] procedure), or e-911, in addition to admission or only very coarse capacity admission and can exceed
normal routine calls that use call admission. It is possible to use their allocated resources.
control plane protocols to generally restrict session admission such
that admitted traffic should receive the desired service, and 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.
The requested DSCP applies to the Telephony Service Class described The requested DSCP applies to the Telephony Service Class described
in [RFC4594]. in [RFC4594].
Since video classes have not had the history of mixing admitted and Since video classes have not had the history of mixing admitted and
non-admitted traffic in the same Per-Hop Behavior (PHB) as has non-admitted traffic in the same Per-Hop Behavior (PHB) as has
occurred for EF, an additional DSCP code point is not recommended. occurred for EF, an additional DSCP code point is not recommended
Instead, the recommended "best practice" is to perform admission within this document for video. Instead, the recommended "best
control for all traffic in three of [RFC4594]'s video classes: the practice" is to perform admission control for all traffic in three
of [RFC4594]'s video classes: the
o Interactive Real-Time Traffic (CS4, used for Video conferencing o Interactive Real-Time Traffic (CS4, used for Video conferencing
and Interactive gaming), and Interactive gaming),
o Broadcast TV (CS3) for use in a video on demand context, and o Broadcast TV (CS3) for use in a video on demand context, and
o AF4 Multimedia Conferencing (video conferencing). o AF4 Multimedia Conferencing (video conferencing).
Other video classes are believed to not have the current problem of Other video classes are believed to not have the current problem of
confusion with unadmitted traffic and therefore would not benefit confusion with unadmitted traffic and therefore would not benefit
from the notion of a separate DSCP for admitted traffic. Within an from the notion of a separate DSCP for admitted traffic. Within an
ISP and on inter-ISP links (i.e. within networks whose internal ISP and on inter-ISP links (i.e. within networks whose internal
paths are uniform at hundreds of megabits or faster), one would paths are uniform at hundreds of megabits per second or faster), one
expect all of this traffic to be carried in the Real Time Traffic would expect all of this traffic to be carried in the Real-Time
(RTP) Class described in [RFC5127]. Traffic (RTP) Class described in [RFC5127].
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 Differentiated Services forwarding behavior applied at a Differentiated Services
compliant node to a DS behavior aggregate [RFC2475]. It may be compliant node to a DS behavior aggregate [RFC2475]. It may be
thought of as a program configured on the interface of an thought of as a program configured on the interface of an
Internet host or router, specified drop probabilities, queuing Internet host or router, specified in terms of drop
priorities or rates, and other handling characteristics for the probabilities, queuing priorities or rates, and other handling
traffic class. characteristics for the traffic class.
DSCP: The Differentiated Services Code Point (DSCP), as defined in DSCP: The Differentiated Services Code Point (DSCP), as defined in
[RFC2474], is a value which is encoded in the DS field, and which [RFC2474], is a value which is encoded in the DS field, and which
each DS Node MUST use to select the PHB which is to be each DS Node MUST use to select the PHB which is to be
experienced by each packet it forwards [RFC3260]. It is a 6-bit experienced by each packet it forwards [RFC3260]. It is a 6-bit
number embedded into the 8-bit TOS field of an IPv4 datagram or number embedded into the 8-bit TOS field of an IPv4 datagram or
the Traffic Class field of an IPv6 datagram. the Traffic Class field of an IPv6 datagram.
CAC: Call Admission Control includes concepts of authorization and CAC: Call Admission Control includes concepts of authorization and
capacity admission. "Authorization" refers to any procedure that capacity admission. "Authorization" refers to any procedure that
skipping to change at page 6, line 45 skipping to change at page 6, line 45
Figure 1: UNI and NNI interfaces Figure 1: UNI and NNI interfaces
1.2. Problem 1.2. Problem
In short, the Telephony Service Class described in [RFC4594] permits In short, the Telephony Service Class described in [RFC4594] permits
the use of capacity admission in implementing the service, but the use of capacity admission in implementing the service, but
present implementations either provide no capacity admission present implementations either provide no capacity admission
services or do so in a manner that depends on specific traffic services or do so in a manner that depends on specific traffic
engineering. In the context of the Internet backbone, the two are engineering. In the context of the Internet backbone, the two are
essentially equivalent; the edge network depends on specific essentially equivalent; the edge network depends on specific
engineering by the service provider that may not be present, engineering by the service provider that might not be present,
especially in a mobile environment. especially in a mobile environment.
However, services are being requested of the network that would However, services are being requested of the network that would
specifically make use of capacity admission, and would distinguish specifically make use of capacity admission, and would distinguish
among users or the uses of available Voice-over-IP or Video-over-IP among users or the uses of available Voice-over-IP or Video-over-IP
capacity in various ways. Various agencies would like to provide capacity in various ways. Various agencies would like to provide
services as described in section 2.6 of [RFC4504] or in [RFC4190]. services as described in section 2.6 of [RFC4504] or in [RFC4190].
This requires the use of capacity admission to differentiate among This requires the use of capacity admission to differentiate among
users (which might be 911 call centers, other offices with users to provide services to them that are not afforded to
preferential service contracts, or individual users gaining access non-capacity admitted customer-to-customer IP telephony sessions.
with special credentials) to provide services to them that are not
afforded to non-capacity admitted customer-to-customer IP telephony
sessions.
2. Candidate Implementations of the Admitted Telephony Service Class 2. Candidate Implementations of the Admitted Telephony Service Class
2.1. Potential implementations of EF in this model 2.1. Potential implementations of EF in this model
There are at least two possible ways to implement isolation between There are at least two possible ways to implement isolation between
the Capacity Admitted PHB and the Expedited Forwarding PHB in this the Capacity Admitted PHB and the Expedited Forwarding PHB in this
model. They are to implement separate classes as a set of model. They are to implement separate classes as a set of
o Multiple data plane traffic classes, each consisting of a policer o Multiple data plane traffic classes, each consisting of a policer
skipping to change at page 7, line 34 skipping to change at page 7, line 31
We will explain the difference, and describe in what way they differ We will explain the difference, and describe in what way they differ
in operation. The reason this is necessary is that there is current in operation. The reason this is necessary is that there is current
confusion in the industry. confusion in the industry.
The multi-priority model is shown in Figure 2. In this model, The multi-priority model is shown in Figure 2. In this model,
traffic from each service class is placed into a separate priority traffic from each service class is placed into a separate priority
queue. If data is present in more than one queue, traffic from one queue. If data is present in more than one queue, traffic from one
of them will always be selected for transmission. This has the of them will always be selected for transmission. This has the
effect of transferring jitter from the higher priority queue to the effect of transferring jitter from the higher priority queue to the
lower priority queue, and reordering traffic in a way that gives the lower priority queues, and reordering traffic in a way that gives
higher priority traffic a smaller average queuing delay. Each queue the higher priority traffic a smaller average queuing delay. Each
must have its own policer, however, to protect the network from queue must have its own policer, however, to protect the network
errors and attacks; if a traffic class thinks it is carrying a from errors and attacks; if a traffic class thinks it is carrying a
certain data rate but an abuse sends significantly more, the effect certain data rate but an abuse sends significantly more, the effect
of simple prioritization would not preserve the lower priorities of of simple prioritization would not preserve the lower priorities of
traffic, which could cause routing to fail or otherwise impact an traffic, which could cause routing to fail or otherwise impact an
SLA. SLA.
. .
policers priorities |`. policers priorities |`.
Admitted EF <=> ----------||----+ `. Admitted EF <=> ----------||----+ `.
high| `. high| `.
Unadmitted EF <=> ----------||----+ .'----------- Unadmitted EF <=> ----------||----+ .'-----------
skipping to change at page 10, line 37 skipping to change at page 10, line 24
o If multiple policies are in use in a network, that the user is o If multiple policies are in use in a network, that the user is
identified and the correct policy applied. identified and the correct policy applied.
o Under periods of network stress, the process of admission of new o Under periods of network stress, the process of admission of new
sessions does not disrupt existing sessions, unless the service sessions does not disrupt existing sessions, unless the service
explicitly allows for disruption of calls. explicitly allows for disruption of calls.
2.3. Recommendations on implementation of an Admitted Telephony 2.3. Recommendations on implementation of an Admitted Telephony
Service Class Service Class
It is the belief of the authors that either PHB implementation When coupled with adequate AAA and capacity admission procedures as
described in Section 2.1, if coupled with adequate AAA and capacity described in Section 2.2, either of the two PHB implementations
admission procedures as described in Section 2.2, are sufficient to described in Section 2.1 is sufficient to provide the services
provide the services required for an Admitted Telephony service required for an Admitted Telephony service class. If preemption is
class. If preemption is required, as described in section 2.3.5.2 required, as described in section 2.3.5.2 of [RFC4542], this
of [RFC4542], this provides the tools for carrying out the provides the tools for carrying out the preemption. If preemption is
preemption. If preemption is not in view, or if used in addition to not in view, or if used in addition to preemptive services, the
preemptive services, the application of different thresholds application of different thresholds depending on call precedence has
depending on call precedence has the effect of improving the the effect of improving the probability of call completion by
probability of call completion by admitting preferred calls at a admitting preferred calls at a time that other calls are being
time that other calls are being refused. Routine and priority refused. Routine and priority traffic can be admitted using the
traffic can be admitted using the same DSCP value, as the choice of same DSCP value, as the choice of which calls are admitted is
which calls are admitted is handled in the admission procedure handled in the admission procedure executed in the control plane,
executed in the control plane, not the policing of the data plane. not the policing of the data plane.
On the point of what protocols and procedures are required for On the point of what protocols and procedures are required for
authentication, authorization, and capacity admission, we note that authentication, authorization, and capacity admission, we note that
clear standards do not exist at this time for bandwidth brokers, clear standards do not exist at this time for bandwidth brokers,
NSIS has not been finalized at this time and in any event is limited NSIS has not been finalized at this time and in any event is limited
to unicast sessions, and that RSVP has been standardized and has the to unicast sessions, and that RSVP has been standardized and has the
relevant services. We therefore recommend the use of RSVP at the relevant services. We therefore RECOMMEND the use of a protocol,
UNI. Procedures at the NNI are business matters to be discussed such as RSVP, at the UNI. Procedures at the NNI are business
between the relevant networks, and are recommended but not required. matters to be discussed between the relevant networks, and are
I RECOMMENDED but NOT REQUIRED.
3. Summary: changes from RFC 4594 3. Summary: changes from RFC 4594
To summarize, there are two changes to [RFC4594] discussed in this To summarize, there are two changes to [RFC4594] discussed in this
document: document:
Telephony class: The Telephony Service Class in RFC 4594 does not Telephony class: The Telephony Service Class in RFC 4594 does not
involve capacity admission, but depends on application layer involve capacity admission, but depends on application layer
admission that only estimates capacity, and that through static admission that only estimates capacity, and that through static
engineering. In addition to that class, a separate Admitted engineering. In addition to that class, a separate Admitted
skipping to change at page 11, line 33 skipping to change at page 11, line 22
class when used for video on demand, and the Multimedia class when used for video on demand, and the Multimedia
Conferencing class. Conferencing class.
4. IANA Considerations 4. IANA Considerations
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] in the traffic class consistent with [RFC3246] and [RFC3247] in the
"Differentiated Services Field Codepoints" registry. It implements "Differentiated Services Field Codepoints" registry. 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 [RFC5127] at and is included in the Real Time Treatment Aggregate [RFC5127] at
higher speeds. The recommended value for the code point is 101100, higher speeds. The recommended code point value should be from pool
paralleling the EF code point, which is 101110. The code point 1 within the dscp-registry. This document RECOMMENDS retaining a
should be referred to as VOICE-ADMIT. parallel with the existing EF code point (101110) by assigning a
value for the code point of 101100 -- keeping the (left to right)
first 4 binary values the same in both. The code point described
within this document should be referred to as VOICE-ADMIT. Here is
the recommended addition to the Pool 1 Codepoint registry:
This traffic class requires the use of capacity admission such as Sub-registry: Pool 1 Codepoints
RSVP services together with AAA services at the User/Network Reference: [RFC2474]
Registration Procedures: Standards Action
Registry:
Name Space Reference
--------- ------- ---------
VOICE-ADMIT 101100 [this document]
This traffic class REQUIRES 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 Interface (UNI); the use of such services at the NNI is at the
option of the interconnected networks. 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 "normal", "routine" or some level of
"priority".
This capability, one has to believe, will be abused by script This capability, one has to believe, will be abused by script
kiddies and others if the proof of identity is not adequately strong kiddies and others if the proof of identity is not adequately strong
or if policies are written or implemented improperly by the or if policies are written or implemented improperly by the
carriers. This goes without saying, but this section is here for it carriers. This goes without saying, but this section is here for it
to be said... to be said...
Much of the security considerations from RFC 3246 [RFC3246] applies
to this document, as well as the security considerations in RFC
2474 and RFC 4542. RFC 4230 [RFC4230] analyzes RSVP, providing some
gap analysis to the NSIS WG as they started their work. Keep in mind
that this document is advocating RSVP at the UNI only, while RFC
4230 discusses (mostly) RSVP from a more complete point of view
(i.e., e2e and edge2edge). When considering the RSVP aspect of this
document, understanding Section 6 of RFC 4230 is a good source of
information.
6. Acknowledgements 6. Acknowledgements
Kwok Ho Chan, Georgios Karagiannis, Dan Voce, and Bob Briscoe Kwok Ho Chan, Georgios Karagiannis, Dan Voce, and Bob Briscoe
commented and offered text. The impetus for including Video in the commented and offered text. The impetus for including Video in the
discussion, which initially only targeted voice, is from Dave discussion, which initially only targeted voice, is from Dave
McDysan. McDysan.
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at page 12, line 30 skipping to change at page 12, line 42
[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.
[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.
[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
[ITU.MLPP.1990]
International Telecommunications Union, "Multilevel
Precedence and Preemption Service", ITU-T Recommendation
I.255.3, 1990.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A., [RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K. Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
Ramakrishnan, "Supplemental Information for the New Ramakrishnan, "Supplemental Information for the New
Definition of the EF PHB (Expedited Forwarding Per-Hop Definition of the EF PHB (Expedited Forwarding Per-Hop
Behavior)", RFC 3247, March 2002. Behavior)", RFC 3247, March 2002.
skipping to change at page 13, line 17 skipping to change at page 13, line 20
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 [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency
Telecommunications Service (ETS) for Real-Time Services Telecommunications Service (ETS) for Real-Time Services
in the Internet Protocol Suite", RFC 4542, May 2006. 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.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
DiffServ Service Classes", RFC 5127, February 2008. DiffServ Service Classes", RFC 5127, February 2008.
[RFC4230] H. Tschofenig, R. Graveman, "RSVP Security Properties",
RFC4230, December 2005
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. 27 change blocks. 
88 lines changed or deleted 110 lines changed or added

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