draft-ietf-tsvwg-diffserv-service-classes-00.txt   draft-ietf-tsvwg-diffserv-service-classes-01.txt 
TSVWG J. Babiarz TSVWG J. Babiarz
Internet-Draft K. Chan Internet-Draft K. Chan
Expires: August 15, 2005 Nortel Networks Expires: January 16, 2006 Nortel Networks
F. Baker F. Baker
Cisco Systems Cisco Systems
February 11, 2005 July 15, 2005
Configuration Guidelines for DiffServ Service Classes Configuration Guidelines for DiffServ Service Classes
draft-ietf-tsvwg-diffserv-service-classes-00 draft-ietf-tsvwg-diffserv-service-classes-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 15, 2005. This Internet-Draft will expire on January 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This paper summarizes the recommended correlation between service This paper summarizes the recommended correlation between service
classes and their usage, with references to their corresponding classes and their usage, with references to their corresponding
recommended Differentiated Service Code Points (DSCP), traffic recommended Differentiated Service Code Points (DSCP), traffic
skipping to change at page 2, line 32 skipping to change at page 2, line 30
1.4.5 Per-Hop Behavior (PHB) . . . . . . . . . . . . . . . . 8 1.4.5 Per-Hop Behavior (PHB) . . . . . . . . . . . . . . . . 8
1.5 Key Service Concepts . . . . . . . . . . . . . . . . . . . 8 1.5 Key Service Concepts . . . . . . . . . . . . . . . . . . . 8
1.5.1 Default Forwarding (DF) . . . . . . . . . . . . . . . 9 1.5.1 Default Forwarding (DF) . . . . . . . . . . . . . . . 9
1.5.2 Assured Forwarding (AF) . . . . . . . . . . . . . . . 9 1.5.2 Assured Forwarding (AF) . . . . . . . . . . . . . . . 9
1.5.3 Expedited Forwarding (EF) . . . . . . . . . . . . . . 10 1.5.3 Expedited Forwarding (EF) . . . . . . . . . . . . . . 10
1.5.4 Class Selector (CS) . . . . . . . . . . . . . . . . . 10 1.5.4 Class Selector (CS) . . . . . . . . . . . . . . . . . 10
1.5.5 Admission Control . . . . . . . . . . . . . . . . . . 11 1.5.5 Admission Control . . . . . . . . . . . . . . . . . . 11
2. Service Differentiation . . . . . . . . . . . . . . . . . . . 11 2. Service Differentiation . . . . . . . . . . . . . . . . . . . 11
2.1 Service Classes . . . . . . . . . . . . . . . . . . . . . 11 2.1 Service Classes . . . . . . . . . . . . . . . . . . . . . 11
2.2 Categorization of User Service Classes . . . . . . . . . . 13 2.2 Categorization of User Service Classes . . . . . . . . . . 13
2.3 Service Class Characteristics . . . . . . . . . . . . . . 15 2.3 Service Class Characteristics . . . . . . . . . . . . . . 16
2.4 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 20 2.4 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 21
2.4.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 20 2.4.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 21
2.4.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 21 2.4.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 22
2.4.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . 23 2.4.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . 25
3. Network Control Traffic . . . . . . . . . . . . . . . . . . . 26 3. Network Control Traffic . . . . . . . . . . . . . . . . . . . 27
3.1 Current Practice in The Internet . . . . . . . . . . . . . 26 3.1 Current Practice in The Internet . . . . . . . . . . . . . 27
3.2 Network Control Service Class . . . . . . . . . . . . . . 26 3.2 Network Control Service Class . . . . . . . . . . . . . . 27
3.3 OAM Service Class . . . . . . . . . . . . . . . . . . . . 28 3.3 OAM Service Class . . . . . . . . . . . . . . . . . . . . 29
4. User Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 29 4. User Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1 Telephony Service Class . . . . . . . . . . . . . . . . . 30 4.1 Telephony Service Class . . . . . . . . . . . . . . . . . 31
4.2 Signaling Service Class . . . . . . . . . . . . . . . . . 31 4.2 Signaling Service Class . . . . . . . . . . . . . . . . . 32
4.3 Multimedia Conferencing Service Class . . . . . . . . . . 33 4.3 Multimedia Conferencing Service Class . . . . . . . . . . 34
4.4 Real-time Interactive Service Class . . . . . . . . . . . 36 4.4 Real-time Interactive Service Class . . . . . . . . . . . 37
4.5 Multimedia Streaming Service Class . . . . . . . . . . . . 37 4.5 Multimedia Streaming Service Class . . . . . . . . . . . . 38
4.6 Broadcast Video Service Class . . . . . . . . . . . . . . 39 4.6 Broadcast Video Service Class . . . . . . . . . . . . . . 40
4.7 Low Latency Data Service Class . . . . . . . . . . . . . . 41 4.7 Low Latency Data Service Class . . . . . . . . . . . . . . 42
4.8 High Throughput Data Service Class . . . . . . . . . . . . 43 4.8 High Throughput Data Service Class . . . . . . . . . . . . 44
4.9 Standard Service Class . . . . . . . . . . . . . . . . . . 45 4.9 Standard Service Class . . . . . . . . . . . . . . . . . . 46
4.10 Low Priority Data . . . . . . . . . . . . . . . . . . . . 46 4.10 Low Priority Data . . . . . . . . . . . . . . . . . . . . 47
5. Additional Information on Service Class Usage . . . . . . . . 47 5. Additional Information on Service Class Usage . . . . . . . . 48
5.1 Mapping for Signaling . . . . . . . . . . . . . . . . . . 47 5.1 Mapping for Signaling . . . . . . . . . . . . . . . . . . 48
5.2 Mapping for NTP . . . . . . . . . . . . . . . . . . . . . 47 5.2 Mapping for NTP . . . . . . . . . . . . . . . . . . . . . 48
5.3 VPN Service Mapping . . . . . . . . . . . . . . . . . . . 48 5.3 VPN Service Mapping . . . . . . . . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 48 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49
7. Summary of Changes from Previous Draft . . . . . . . . . . . . 49 7. Summary of Changes from Previous Draft . . . . . . . . . . . . 50
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 50 9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.1 Explanation of Ring Clipping . . . . . . . . . . . . . . . 50 9.1 Explanation of Ring Clipping . . . . . . . . . . . . . . . 51
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.1 Normative References . . . . . . . . . . . . . . . . . . . 51 10.1 Normative References . . . . . . . . . . . . . . . . . . . 52
10.2 Informative References . . . . . . . . . . . . . . . . . . 52 10.2 Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . . 55 Intellectual Property and Copyright Statements . . . . . . . . 56
1. Introduction 1. Introduction
This paper summarizes the recommended correlation between service This paper summarizes the recommended correlation between service
classes and their usage, with references to their corresponding classes and their usage, with references to their corresponding
recommended Differentiated Service Code Points (DSCP), traffic recommended Differentiated Service Code Points (DSCP), traffic
conditioners, Per-Hop Behaviors (PHB) and Active Queue Management conditioners, Per-Hop Behaviors (PHB) and Active Queue Management
(AQM) mechanisms. There is no intrinsic requirement that particular (AQM) mechanisms. There is no intrinsic requirement that particular
DSCPs, traffic conditioner PHBs and AQM be used for a certain service DSCPs, traffic conditioner PHBs and AQM be used for a certain service
class, but as a policy it is useful that they be applied consistently class, but as a policy it is useful that they be applied consistently
across the network. across the network.
Service classes are defined based on the different traffic Service classes are defined based on the different traffic
characteristics and required performance of the characteristics and required performance of the applications/
applications/services. This approach allows us to map current and services. This approach allows us to map current and future
future applications/services of similar traffic characteristics and applications/services of similar traffic characteristics and
performance requirements into the same service class. Since the performance requirements into the same service class. Since the
applications'/services' characteristics and required performance are applications'/services' characteristics and required performance are
end to end, the service class notion needs to be preserved end to end to end, the service class notion needs to be preserved end to
end. With this approach, a limited set of service classes is end. With this approach, a limited set of service classes is
required. For completeness, we have defined twelve different service required. For completeness, we have defined twelve different service
classes, two for network operation/administration and ten for classes, two for network operation/administration and ten for user/
user/subscriber applications/services. However, we expect that subscriber applications/services. However, we expect that network
network administrators will implement a subset of these classes administrators will implement a subset of these classes relevant to
relevant to their customers and their service offerings. Network their customers and their service offerings. Network Administrators
Administrators may also find it of value to add locally defined may also find it of value to add locally defined service classes,
service classes, although these will not necessarily enjoy end to end although these will not necessarily enjoy end to end properties of
properties of the same type. the same type.
Section 1, provides an introduction and overview of technologies that Section 1, provides an introduction and overview of technologies that
are used for service differentiation in IP networks. Section 2, is are used for service differentiation in IP networks. Section 2, is
an overview of how service classes are constructed to provide service an overview of how service classes are constructed to provide service
differentiation with examples of deployment scenarios. Section 3, differentiation with examples of deployment scenarios. Section 3,
provides configuration guidelines of service classes that are used provides configuration guidelines of service classes that are used
for stable operation and administration of the network. Section 4, for stable operation and administration of the network. Section 4,
provides configuration guidelines of service classes that are used provides configuration guidelines of service classes that are used
for differentiation of user/subscriber traffic. Section 5, provides for differentiation of user/subscriber traffic. Section 5, provides
additional guidance on mapping different applications/protocol to additional guidance on mapping different applications/protocol to
skipping to change at page 12, line 42 skipping to change at page 12, line 42
o Multimedia Streaming service class is best suited for variable o Multimedia Streaming service class is best suited for variable
rate elastic streaming media applications where a human is waiting rate elastic streaming media applications where a human is waiting
for output and where the application has the capability to react for output and where the application has the capability to react
to packet loss by reducing its transmission rate, such as to packet loss by reducing its transmission rate, such as
streaming video and audio, web cast, etc. streaming video and audio, web cast, etc.
o Broadcast Video service class is best suited for inelastic o Broadcast Video service class is best suited for inelastic
streaming media applications that may be of constant or variable streaming media applications that may be of constant or variable
rate, requiring low jitter and very low packet loss, such as rate, requiring low jitter and very low packet loss, such as
broadcast TV and live events, video surveillance and security. broadcast TV and live events, video surveillance and security.
o Low Latency Data service class is best suited for data processing o Low Latency Data service class is best suited for data processing
applications where a human is waiting for output, such as applications where a human is waiting for output, such as web-
web-based ordering, Enterprise Resource Planning (ERP) based ordering, Enterprise Resource Planning (ERP) application,
application, etc. etc.
o High Throughput Data service class is best suited for store and o High Throughput Data service class is best suited for store and
forward applications such as FTP, billing record transfer, etc. forward applications such as FTP, billing record transfer, etc.
o Standard service class is for traffic that has not been identified o Standard service class is for traffic that has not been identified
as requiring differentiated treatment and is normally referred as as requiring differentiated treatment and is normally referred as
best effort. best effort.
o Low Priority Data service class is intended for packet flows where o Low Priority Data service class is intended for packet flows where
bandwidth assurance is not required. bandwidth assurance is not required.
2.2 Categorization of User Service Classes 2.2 Categorization of User Service Classes
The ten defined user/subscriber services classes listed above can be The ten defined user/subscriber services classes listed above can be
grouped into a small number of application categories. For some grouped into a small number of application categories. For some
application categories, it was felt that more than one service class application categories, it was felt that more than one service class
was needed to provide service differentiation within that category was needed to provide service differentiation within that category
due to the different traffic characteristic of the applications, due to the different traffic characteristic of the applications,
skipping to change at page 17, line 21 skipping to change at page 18, line 16
loss can create problems in setting up calls, a moderate level of loss can create problems in setting up calls, a moderate level of
jitter merely makes call placement a little less predictable in jitter merely makes call placement a little less predictable in
duration. duration.
Service classes indicate the required traffic forwarding treatment in Service classes indicate the required traffic forwarding treatment in
order to meet user, application or network expectations. Section 3in order to meet user, application or network expectations. Section 3in
this document defines the service classes that MAY be used for this document defines the service classes that MAY be used for
forwarding network control traffic and Section 4 defines the service forwarding network control traffic and Section 4 defines the service
classes that MAY be used for forwarding user traffic with examples of classes that MAY be used for forwarding user traffic with examples of
intended application types mapped into each service class. Note that intended application types mapped into each service class. Note that
the application types are only examples and are not meant to be the application types are only examples and are not meant to be all-
all-inclusive or prescriptive. Also it should be noted that the inclusive or prescriptive. Also it should be noted that the service
service class naming or ordering does not imply any priority class naming or ordering does not imply any priority ordering. They
ordering. They are simply reference names that are used in this are simply reference names that are used in this document with
document with associated QoS behaviors that are optimized for the associated QoS behaviors that are optimized for the particular
particular application types they support. Network administrators application types they support. Network administrators MAY choose to
MAY choose to assign different service class names, to the service assign different service class names, to the service classes that
classes that they will support. Figure 3 defines the RECOMMENDED they will support. Figure 3 defines the RECOMMENDED relationship
relationship between service classes and DS codepoint(s) assignment between service classes and DS codepoint(s) assignment with
with application examples. It is RECOMMENDED that this relationship application examples. It is RECOMMENDED that this relationship be
be preserved end to end. preserved end to end.
------------------------------------------------------------------ ------------------------------------------------------------------
| Service | DSCP | DSCP | Application | | Service | DSCP | DSCP | Application |
| Class name | name | value | Examples | | Class name | name | value | Examples |
|===============+=========+=============+==========================| |===============+=========+=============+==========================|
|Network Control| CS6 | 110000 | Network routing | |Network Control| CS6 | 110000 | Network routing |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Telephony | EF | 101110 | IP Telephony bearer | | Telephony | EF | 101110 | IP Telephony bearer |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Signaling | CS5 | 101000 | IP Telephony signaling | | Signaling | CS5 | 101000 | IP Telephony signaling |
skipping to change at page 20, line 6 skipping to change at page 21, line 27
o The PHB for Broadcast Video service class SHOULD be configured to o The PHB for Broadcast Video service class SHOULD be configured to
provide high bandwidth assurance. It MAY be configured as a third provide high bandwidth assurance. It MAY be configured as a third
EF PHB that uses relaxed performance parameters and a rate EF PHB that uses relaxed performance parameters and a rate
scheduler. scheduler.
o In network segments that use IP precedence marking, only one of o In network segments that use IP precedence marking, only one of
the two service classes can be supported, High Throughput Data or the two service classes can be supported, High Throughput Data or
Low Priority Data. We RECOMMEND that the DSCP value(s) of the Low Priority Data. We RECOMMEND that the DSCP value(s) of the
unsupported service class to be changed to 000xx1 on ingress and unsupported service class to be changed to 000xx1 on ingress and
changed back to original value(s) on egress of the network segment changed back to original value(s) on egress of the network segment
that uses precedence marking. For example, if Low Priority Data that uses precedence marking. For example, if Low Priority Data
is mapped to Standard service class, than 000001 DSCP marking MAY is mapped to Standard service class, then 000001 DSCP marking MAY
be used to distinguish it from Standard marked packets on egress. be used to distinguish it from Standard marked packets on egress.
2.4 Deployment Scenarios 2.4 Deployment Scenarios
It is expected that network administrators will choose the service It is expected that network administrators will choose the service
classes that they will support based on their need, starting off with classes that they will support based on their need, starting off with
three or four service classes for user traffic and add more service three or four service classes for user traffic and add more service
classes as the need arises. In this section we provide three classes as the need arises. In this section we provide three
examples of possible deployment scenarios. examples of possible deployment scenarios.
skipping to change at page 22, line 5 skipping to change at page 23, line 17
(telephony) service (telephony) service
o Provide TV and on demand movie viewing service to residential o Provide TV and on demand movie viewing service to residential
subscribers subscribers
o Provide network based data storage and file backup service to o Provide network based data storage and file backup service to
business customers business customers
The new additional services that the network administrator would like The new additional services that the network administrator would like
to offer are addressed with the deployment of the following four to offer are addressed with the deployment of the following four
additional service classes. (These are additions to the six service additional service classes. (These are additions to the six service
classes already defined in Example 1): classes already defined in Example 1):
o Real-time Interactive service class for transport of MPEG-4 o Real-time Interactive service class for transport of MPEG-4 real-
real-time video flows to support desktop video conferencing. The time video flows to support desktop video conferencing. The
control/signaling for video conferencing is done using the control/signaling for video conferencing is done using the
Signaling service class. Signaling service class.
o Broadcast Video service class for transport of IPTV broadcast o Broadcast Video service class for transport of IPTV broadcast
information. The channel selection and control is via IGMP information. The channel selection and control is via IGMP
(Internet Group Management Protocol) mapped into the Signaling (Internet Group Management Protocol) mapped into the Signaling
service class. service class.
o Multimedia Streaming service class for transport of stored MPEG-2 o Multimedia Streaming service class for transport of stored MPEG-2
or MPEG-4 content. The selection and control of streaming or MPEG-4 content. The selection and control of streaming
information is done using the Signaling service class. The information is done using the Signaling service class. The
selection of Multimedia Streaming service class for on demand selection of Multimedia Streaming service class for on demand
movie service was chosen as the set-top box used for this service movie service was chosen as the set-top box used for this service
has local buffering capability to compensate for the bandwidth has local buffering capability to compensate for the bandwidth
variability of the elastic streaming information. Note, if variability of the elastic streaming information. Note, if
transport of on demand movie service is inelastic, than the transport of on demand movie service is inelastic, then the
Broadcast Video service class SHOULD be used. Broadcast Video service class SHOULD be used.
o High Throughput Data service class is for transport of bulk data o High Throughput Data service class is for transport of bulk data
for network based storage and file backup service to business for network based storage and file backup service to business
customers. customers.
Figure 6, provides a summary of the mechanisms needed for delivery of Figure 6, provides a summary of the mechanisms needed for delivery of
service differentiation for all the service classes used in Example service differentiation for all the service classes used in Example
2. 2.
------------------------------------------------------------------- -------------------------------------------------------------------
skipping to change at page 26, line 24 skipping to change at page 27, line 24
operating, administering, controlling or managing the network operating, administering, controlling or managing the network
segments. Network Control Traffic may be split into two service segments. Network Control Traffic may be split into two service
classes, i.e. Network Control and OAM. classes, i.e. Network Control and OAM.
3.1 Current Practice in The Internet 3.1 Current Practice in The Internet
Based on today's routing protocols and network control procedures Based on today's routing protocols and network control procedures
that are used in The Internet, we have determined that CS6 DSCP value that are used in The Internet, we have determined that CS6 DSCP value
SHOULD be used for routing and control and that CS7 DSCP value be SHOULD be used for routing and control and that CS7 DSCP value be
reserved for future use, potentially for future routing and/or reserved for future use, potentially for future routing and/or
control protocols. Network administrator MAY use a control protocols. Network administrator MAY use a Local/
Local/Experimental DSCP therefore a locally defined service class Experimental DSCP therefore a locally defined service class within
within their network to further differentiate their routing and their network to further differentiate their routing and control
control traffic. traffic.
RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets: RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets:
o Drop or remark CS7 marked packets at ingress to DiffServ network o Drop or remark CS7 marked packets at ingress to DiffServ network
domain. domain.
o CS7 marked packets SHOULD NOT be sent across peering points. o CS7 marked packets SHOULD NOT be sent across peering points.
Exchange of control information across peering points SHOULD be Exchange of control information across peering points SHOULD be
done using CS6 DSCP, using Network Control service class. done using CS6 DSCP, using Network Control service class.
3.2 Network Control Service Class 3.2 Network Control Service Class
skipping to change at page 29, line 12 skipping to change at page 30, line 12
user devices) SHOULD be verified at ingress to DiffServ network user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in [RFC2475]. using Multifield (MF) Classification methods defined in [RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g. using single rate policed at ingress to DiffServ network, e.g. using single rate
with burst size token bucket policer to ensure that the traffic with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds. stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (routers inside administered o Packet flows from trusted sources (routers inside administered
network) MAY not require policing. network) MAY not require policing.
o Normally OAM&P CS2 marked packet flows are not allowed to flow o Normally OAM&P CS2 marked packet flows are not allowed to flow
across peering points, if that is the case, than CS2 marked packet across peering points, if that is the case, then CS2 marked
SHOULD be policed (dropped) at both egress and ingress peering packets SHOULD be policed (dropped) at both egress and ingress
interfaces. peering interfaces.
The fundamental service offered to "OAM" traffic is enhanced best The fundamental service offered to "OAM" traffic is enhanced best
effort service with controlled rate. The service SHOULD be effort service with controlled rate. The service SHOULD be
engineered so that CS2 marked packet flows have sufficient bandwidth engineered so that CS2 marked packet flows have sufficient bandwidth
in the network to provide high assurance of delivery. Since this in the network to provide high assurance of delivery. Since this
service class is used to forward both elastic and inelastic flows, service class is used to forward both elastic and inelastic flows,
the service SHOULD be engineered so that Active Queue Management the service SHOULD be engineered so that Active Queue Management
[RFC2309] is applied to CS2 marked packets. [RFC2309] is applied to CS2 marked packets.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
skipping to change at page 30, line 28 skipping to change at page 31, line 28
ATM CBR service, which has guaranteed bandwidth and which, if it ATM CBR service, which has guaranteed bandwidth and which, if it
stays within the negotiated rate, experiences nominal delay and no stays within the negotiated rate, experiences nominal delay and no
loss. The EF PHB has a similar guarantee. loss. The EF PHB has a similar guarantee.
Typical configurations negotiate the setup of telephone calls over IP Typical configurations negotiate the setup of telephone calls over IP
using protocols such as H.248, MEGACO, H.323, or SIP. When a user using protocols such as H.248, MEGACO, H.323, or SIP. When a user
has been authorized to send telephony traffic, the call admission has been authorized to send telephony traffic, the call admission
procedure should have verified that the newly admitted flow will be procedure should have verified that the newly admitted flow will be
within the capacity of the Telephony service class forwarding within the capacity of the Telephony service class forwarding
capability in the network. For VoIP (telephony) service, call capability in the network. For VoIP (telephony) service, call
admission control is usually performed by a telephony call admission control is usually performed by a telephony call server/
server/gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.) gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.) on
on access points to the network. The bandwidth in the core network access points to the network. The bandwidth in the core network and
and the number of simultaneous VoIP sessions that can be supported the number of simultaneous VoIP sessions that can be supported needs
needs to be engineered and controlled so that there is no congestion to be engineered and controlled so that there is no congestion for
for this service. Since RTP telephony flows do not react to loss or this service. Since RTP telephony flows do not react to loss or
substantial delay in any substantive way, the Telephony service class substantial delay in any substantive way, the Telephony service class
SHOULD forward packet as soon as possible. SHOULD forward packet as soon as possible.
The Telephony service class SHOULD use Expedited Forwarding (EF) PHB The Telephony service class SHOULD use Expedited Forwarding (EF) PHB
as defined in [RFC3246] and SHOULD be configured to receive as defined in [RFC3246] and SHOULD be configured to receive
guaranteed forwarding resources so that all packets are forwarded guaranteed forwarding resources so that all packets are forwarded
quickly. The Telephony service class SHOULD be configured to use a quickly. The Telephony service class SHOULD be configured to use a
Priority Queuing system such as defined in Section 1.4.1.1 of this Priority Queuing system such as defined in Section 1.4.1.1 of this
document. document.
skipping to change at page 31, line 51 skipping to change at page 32, line 51
have sufficient bandwidth in the network to provide guaranteed have sufficient bandwidth in the network to provide guaranteed
delivery. Normally traffic in this service class does not respond delivery. Normally traffic in this service class does not respond
dynamically to packet loss. As such, Active Queue Management dynamically to packet loss. As such, Active Queue Management
[RFC2309] SHOULD NOT be applied to EF marked packet flows. [RFC2309] SHOULD NOT be applied to EF marked packet flows.
4.2 Signaling Service Class 4.2 Signaling Service Class
The Signaling service class is RECOMMENDED for delay sensitive The Signaling service class is RECOMMENDED for delay sensitive
client-server (traditional telephony) and peer-to-peer application client-server (traditional telephony) and peer-to-peer application
signaling. Telephony signaling includes signaling between IP phone signaling. Telephony signaling includes signaling between IP phone
and soft-switch, soft-client and soft-switch, media gateway and and soft-switch, soft-client and soft-switch, media gateway and soft-
soft-switch as well as peer-to-peer using various protocols. This switch as well as peer-to-peer using various protocols. This service
service class is intended to be used for control of sessions and class is intended to be used for control of sessions and
applications. Applications using this service class requiring a applications. Applications using this service class requiring a
relatively fast response as there are typically several message of relatively fast response as there are typically several message of
different size sent for control of the session. This service class different size sent for control of the session. This service class
is configured to provide good response for short lived, intermittent is configured to provide good response for short lived, intermittent
flows that require real-time packet forwarding. To minimize the flows that require real-time packet forwarding. To minimize the
possibility of ring clipping at start of call for VoIP service that possibility of ring clipping at start of call for VoIP service that
interface to a circuit switch Exchange in the Public Switch Telephone interface to a circuit switch Exchange in the Public Switch Telephone
Network (PSTN), the Signaling service class SHOULD be configured so Network (PSTN), the Signaling service class SHOULD be configured so
that the probability of packet drop or significant queuing delay that the probability of packet drop or significant queuing delay
under peak load is very low in IP network segments that provide this under peak load is very low in IP network segments that provide this
skipping to change at page 33, line 45 skipping to change at page 34, line 47
The Multimedia Conferencing service class is RECOMMENDED for The Multimedia Conferencing service class is RECOMMENDED for
applications that require real-time service for rate adaptive applications that require real-time service for rate adaptive
traffic. H.323/V2 and later versions of video conferencing equipment traffic. H.323/V2 and later versions of video conferencing equipment
with dynamic bandwidth adjustment is such an application. The with dynamic bandwidth adjustment is such an application. The
traffic sources (applications) in this service class have the traffic sources (applications) in this service class have the
capability to dynamically change their transmission rate based on capability to dynamically change their transmission rate based on
feedback received from the receiving end, within bounds of packet feedback received from the receiving end, within bounds of packet
loss by the receiver is sent using the applications control stream to loss by the receiver is sent using the applications control stream to
the transmitter as an indication of possible congestion; the the transmitter as an indication of possible congestion; the
transmitter then selects a lower transmission rate based on transmitter then selects a lower transmission rate based on pre-
pre-configured encoding rates (or transmission rates). Note, today configured encoding rates (or transmission rates). Note, today many
many H.323/V2 video conferencing solutions implement fixed step H.323/V2 video conferencing solutions implement fixed step bandwidth
bandwidth change (usually reducing the rate), traffic resembling change (usually reducing the rate), traffic resembling step-wise CBR.
step-wise CBR.
Typical video conferencing configurations negotiate the setup of Typical video conferencing configurations negotiate the setup of
multimedia session using protocols such as H.323. When a multimedia session using protocols such as H.323. When a user/
user/end-point has been authorized to start a multimedia session the end-point has been authorized to start a multimedia session the
admission procedure should have verified that the newly admitted data admission procedure should have verified that the newly admitted data
rate will be within the engineered capacity of the Multimedia rate will be within the engineered capacity of the Multimedia
Conferencing service class. The bandwidth in the core network and Conferencing service class. The bandwidth in the core network and
the number of simultaneous video conferencing sessions that can be the number of simultaneous video conferencing sessions that can be
supported SHOULD be engineered to control traffic load for this supported SHOULD be engineered to control traffic load for this
service. service.
The Multimedia Conferencing service class SHOULD use the Assured The Multimedia Conferencing service class SHOULD use the Assured
Forwarding (AF) PHB defined in [RFC2597]. This service class SHOULD Forwarding (AF) PHB defined in [RFC2597]. This service class SHOULD
be configured to provide a bandwidth assurance for AF41, AF42, and be configured to provide a bandwidth assurance for AF41, AF42, and
skipping to change at page 36, line 25 skipping to change at page 37, line 27
The Real-time Interactive service class is RECOMMENDED for The Real-time Interactive service class is RECOMMENDED for
applications that require low loss, jitter and very low delay for applications that require low loss, jitter and very low delay for
variable rate inelastic traffic sources. Interactive gaming and variable rate inelastic traffic sources. Interactive gaming and
video conferencing applications that do not have the ability to video conferencing applications that do not have the ability to
change encoding rates or mark packets with different importance change encoding rates or mark packets with different importance
indications are such applications. The traffic sources in this indications are such applications. The traffic sources in this
traffic class does not have the ability to reduce their transmission traffic class does not have the ability to reduce their transmission
rate based on feedback received from the receiving end. rate based on feedback received from the receiving end.
Typically, applications in this service class are configured to Typically, applications in this service class are configured to
negotiate the setup of RTP/UDP control session. When a negotiate the setup of RTP/UDP control session. When a user/
user/end-point has been authorized to start a new session the end-point has been authorized to start a new session the admission
admission procedure should have verified that the newly admitted data procedure should have verified that the newly admitted data rates
rates will be within the engineered capacity of the Real-time will be within the engineered capacity of the Real-time Interactive
Interactive service class. The bandwidth in the core network and the service class. The bandwidth in the core network and the number of
number of simultaneous Real-time Interactive sessions that can be simultaneous Real-time Interactive sessions that can be supported
supported SHOULD be engineered to control traffic load for this SHOULD be engineered to control traffic load for this service.
service.
The Real-time Interactive service class SHOULD use the Class Selector The Real-time Interactive service class SHOULD use the Class Selector
(CS) PHB defined in [RFC2474]. This service class SHOULD be (CS) PHB defined in [RFC2474]. This service class SHOULD be
configured to provide a high assurance for bandwidth for CS4 marked configured to provide a high assurance for bandwidth for CS4 marked
packets to ensure that they get forwarded. The Real-time Interactive packets to ensure that they get forwarded. The Real-time Interactive
service class SHOULD be configured to use a Rate Queuing system such service class SHOULD be configured to use a Rate Queuing system such
as defined in Section 1.4.1.2 of this document. Note, this service as defined in Section 1.4.1.2 of this document. Note, this service
class MAY be configured as a second EF PHB that uses relaxed class MAY be configured as a second EF PHB that uses relaxed
performance parameter, a rate scheduler and CS4 DSCP value. performance parameter, a rate scheduler and CS4 DSCP value.
skipping to change at page 40, line 27 skipping to change at page 41, line 34
o Higher the rate, higher density of large packets o Higher the rate, higher density of large packets
o Mixture of variable and constant rate flows o Mixture of variable and constant rate flows
o Fixed packet emission time intervals o Fixed packet emission time intervals
o Inelastic flows o Inelastic flows
RECOMMENDED DSCP marking: RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS3 (Class o All flows in this service class are marked with CS3 (Class
Selector 3) Selector 3)
o In some cases, like for security and video surveillance o In some cases, like for security and video surveillance
applications, it may be desirable to use a different DSCP marking. applications, it may be desirable to use a different DSCP marking.
If so, than locally user definable (EXP/LU) codepoint(s) in the If so, then locally user definable (EXP/LU) codepoint(s) in the
range '011xx1' MAY be used to provide unique traffic range '011xx1' MAY be used to provide unique traffic
identification. The locally user definable (EXP/LU) codepoint(s) identification. The locally user definable (EXP/LU) codepoint(s)
MAY be associated with the PHB that is used for CS3 traffic. MAY be associated with the PHB that is used for CS3 traffic.
Further, depending on the network scenario, additional network Further, depending on the network scenario, additional network
edge conditioning policy MAY be need for the EXP/LU codepoint(s) edge conditioning policy MAY be need for the EXP/LU codepoint(s)
used. used.
Applications or IP end points SHOULD pre-mark their packets with CS3 Applications or IP end points SHOULD pre-mark their packets with CS3
DSCP value. If the end point is not capable of setting the DSCP DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point SHOULD value, then the router topologically closest to the end point SHOULD
skipping to change at page 46, line 4 skipping to change at page 47, line 14
effort service with active queue management to limit over-all delay. effort service with active queue management to limit over-all delay.
Typical configurations SHOULD use random packet dropping to implement Typical configurations SHOULD use random packet dropping to implement
Active Queue Management [RFC2309] or Explicit Congestion Notification Active Queue Management [RFC2309] or Explicit Congestion Notification
[RFC3168], and MAY impose a minimum or maximum rate on the queue. [RFC3168], and MAY impose a minimum or maximum rate on the queue.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth, and the max-threshold specifies the specifies a target queue depth, and the max-threshold specifies the
queue depth above which all traffic is dropped or ECN marked. Thus, queue depth above which all traffic is dropped or ECN marked. Thus,
in this service class, the following inequality should hold in queue in this service class, the following inequality should hold in queue
configurations: configurations:
o min-threshold DF < max-threshold DF o min-threshold DF < max-threshold DF
o max-threshold DF <= memory assigned to the queue o max-threshold DF <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result. configured to achieve a similar result.
4.10 Low Priority Data 4.10 Low Priority Data
The Low Priority Data service class serves applications that run over The Low Priority Data service class serves applications that run over
TCP [RFC0793] or a transport with consistent congestion avoidance TCP [RFC0793] or a transport with consistent congestion avoidance
procedure [RFC2581][RFC2582], and which the user is willing to accept procedure [RFC2581] [RFC2582], and which the user is willing to
service without guarantees. This service class is specified in accept service without guarantees. This service class is specified
[QBSS] and [RFC3662]. in [QBSS] and [RFC3662].
The following applications MAY use the Low Priority Data service The following applications MAY use the Low Priority Data service
class: class:
o Any TCP based application/packet flow transported through the o Any TCP based application/packet flow transported through the
DiffServ enabled network that does not require any bandwidth DiffServ enabled network that does not require any bandwidth
assurances assurances
Traffic Characteristics: Traffic Characteristics:
o Non real-time and elastic o Non real-time and elastic
skipping to change at page 47, line 29 skipping to change at page 48, line 37
o Peer-to-peer signaling using SIP/H.323 are marked with CS5 DSCP o Peer-to-peer signaling using SIP/H.323 are marked with CS5 DSCP
(use Signaling service class). (use Signaling service class).
o Client-server signaling as used in many implementation for IP o Client-server signaling as used in many implementation for IP
telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN or telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN or
proprietary protocols are marked with CS5 DSCP (use Signaling proprietary protocols are marked with CS5 DSCP (use Signaling
service class). service class).
o Signaling between call servers or soft-switches in carrier's o Signaling between call servers or soft-switches in carrier's
network using SIP, SIP-T, IP encapsulated ISUP, are marked with network using SIP, SIP-T, IP encapsulated ISUP, are marked with
CS5 DSCP (use Signaling service class). CS5 DSCP (use Signaling service class).
o RSVP signaling, depends on the application. If RSVP signaling is o RSVP signaling, depends on the application. If RSVP signaling is
"on-path" as used in IntServ, than it needs to be forwarded from "on-path" as used in IntServ, then it needs to be forwarded from
the same queue (service class) and marked with the same DSCP value the same queue (service class) and marked with the same DSCP value
as application data that it is controlling. This may also apply as application data that it is controlling. This may also apply
to the "on-path" NSIS signaling protocol. to the "on-path" NSIS signaling protocol.
o IGMP (Internet Group Management Protocol). If used for multicast o IGMP (Internet Group Management Protocol). If used for multicast
session control such as channel changing in IPTV systems, then session control such as channel changing in IPTV systems, then
IGMP packets should be marked with CS5 DSCP (use Signaling service IGMP packets should be marked with CS5 DSCP (use Signaling service
class). When IGMP is used only for the normal multicast routing class). When IGMP is used only for the normal multicast routing
purpose, it should be marked with CS6 DSCP (use Network Control purpose, it should be marked with CS6 DSCP (use Network Control
service class). service class).
skipping to change at page 48, line 23 skipping to change at page 49, line 32
differentiation. differentiation.
o The DSCP value(s) that is/are used to represent a PHB or a PHB o The DSCP value(s) that is/are used to represent a PHB or a PHB
group should be the same for the networks at both ends of the VPN group should be the same for the networks at both ends of the VPN
tunnel, unless remarking of DSCP is done as ingress/egress tunnel, unless remarking of DSCP is done as ingress/egress
processing function of the tunnel. DSCP marking needs to be processing function of the tunnel. DSCP marking needs to be
preserve end-to-end. preserve end-to-end.
o The VPN may be configured to support one or more service o The VPN may be configured to support one or more service
class(es). It is left up to the administrators of the two class(es). It is left up to the administrators of the two
networks to agree on the level of traffic differentiation that networks to agree on the level of traffic differentiation that
will be provide in the network that supports VPN service. Service will be provide in the network that supports VPN service. Service
classes are than mapped into the supported VPN traffic forwarding classes are then mapped into the supported VPN traffic forwarding
behaviors that meet the traffic characteristics and performance behaviors that meet the traffic characteristics and performance
requirements of the encapsulated service classes. requirements of the encapsulated service classes.
o The traffic treatment in the network that is providing the VPN o The traffic treatment in the network that is providing the VPN
service needs to be such that the encapsulated service class or service needs to be such that the encapsulated service class or
classes receive comparable behavior and performance in terms of classes receive comparable behavior and performance in terms of
delay, jitter, packet loss and they are within the limits of the delay, jitter, packet loss and they are within the limits of the
service specified. service specified.
o The DSCP value in the external header of the packet forwarded o The DSCP value in the external header of the packet forwarded
through the network providing the VPN service may be different through the network providing the VPN service may be different
than the DSCP value that is used end-to-end for service than the DSCP value that is used end-to-end for service
skipping to change at page 49, line 30 skipping to change at page 50, line 40
traffic should be dropped or remarked by ingress filters. Where traffic should be dropped or remarked by ingress filters. Where
service classes are available under the SLA only to an authenticated service classes are available under the SLA only to an authenticated
user rather than to the entire population of users, AAA services such user rather than to the entire population of users, AAA services such
as described in [I-D.iab-auth-mech] are required. as described in [I-D.iab-auth-mech] are required.
7. Summary of Changes from Previous Draft 7. Summary of Changes from Previous Draft
NOTE TO RFC EDITOR: Please remove this section during the publication NOTE TO RFC EDITOR: Please remove this section during the publication
process. process.
Changes made to draft-baker-diffserv-basic-classes-04 (previous to Changes made to draft-ietf-tsvwg-diffserv-service-classes-00 based on
draft-ietf-tsvwg-diffserv-service-classes-00) of draft based on minor typos on review by Mike Fidler. Following typos were fixed.
reviews by Brian E. Carpenter, Shane Amante and co-authors.
1. Moved the "Requirements Notation" to Section 1.1 after
Introduction.
2. Changed reference to RFC 2474 from RFC 2475 where appropriate.
3. Added reference to PDB in "Service Class Definition" section.
4. In Multimedia Conferencing Service Class section, minor cleanup 1. page 20 first paragraph, "than 000001 DSCP marking" should be
of wording and changed the term that describes the behavior of "then 000001 DSCP marking"
traffic from "elastic" to "rate adaptive" as well where appropriated
throughout the draft.
5. Moved the Explanation of Ring Clipping section to Appendix A, 2. page 22 last sentence of third bullet "than the Broadcast Video
added explanation of terms, etc. service class" should be "then the Broadcast..."
6. In VPN Service Mapping section, added reference to use guidelines 3. page 29 third bullet "than CS2 marked packet" should be "then CS2
in RFC 2983 for tunnels, etc. marked packets" (note plural also)
4. page 40 second sentence of second bullet under "RECOMMENDED DSCP
marking" "If so, than" should be "If so, then"
7. Removed the Administrative Service Class from the draft as it was 5. page 47 section 5.1 fourth bullet "than it needs to be forwarded"
felt that this service class and CS7 DS codepoint are not widely used should be "then it needs to be forwarded"
for the purpose as stated. When there is a demonstrated need or
usage for another routing or network/administrator class we can than
define a service class and assign CS7 DSCP value to it. Made changes
so that the Network Control service class and CS6 DS codepoint are
used only for routing and control and the CS7 is undefined and
reserved. Administrative section is replaced with "Current Practice
in The Internet".
8. Defined Network Control service class to be used only for routing 6. page 48 section 5.3 second bullet "Service classes are than
and network control. Moved network services , DNS, DHCP, BootP from mapped" should be "Service classes are then mapped"
Network Control (CS6) to Standard (DF) service class.
8. Acknowledgements 8. Acknowledgements
The authors thank the TSVWG reviewers, David Black, Brian E Carpenter The authors thank the TSVWG reviewers, David Black, Brian E Carpenter
and Alan O'Neill for their review and input to this draft. and Alan O'Neill for their review and input to this draft.
The authors acknowledge great many inputs, most notably from Bruce The authors acknowledge great many inputs, most notably from Bruce
Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet, Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet,
Morgan Littlewood, Robert Milne, John Shuler, Nalin Mistry, Al Morgan Littlewood, Robert Milne, John Shuler, Nalin Mistry, Al
Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil Dickinson and Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil Dickinson and
skipping to change at page 50, line 45 skipping to change at page 51, line 41
end of a ringing signal is altered because the bearer channel is not end of a ringing signal is altered because the bearer channel is not
made available in time to carry all of the audible ringing signal. made available in time to carry all of the audible ringing signal.
This condition may occur due to a race condition between when the This condition may occur due to a race condition between when the
tone generator located in the circuit switch Exchange is turn on and tone generator located in the circuit switch Exchange is turn on and
when the bearer path through the IP network is enabled. To reduce when the bearer path through the IP network is enabled. To reduce
ring clipping from occurring, delay of signaling path needs to be ring clipping from occurring, delay of signaling path needs to be
minimized. Below is a more detailed explanation. minimized. Below is a more detailed explanation.
The bearer path setup delay target is defined as the ISUP Initial The bearer path setup delay target is defined as the ISUP Initial
Address Message (IAM) / Address Complete Message (ACM) round trip Address Message (IAM) / Address Complete Message (ACM) round trip
delay. ISUP refers to ISDN User Part of Signaling System No. 7 delay. ISUP refers to ISDN User Part of Signaling System No. 7 (SS7)
(SS7) as defined by ITU-T. This consists of the amount of time it as defined by ITU-T. This consists of the amount of time it takes
takes for the ISUP Initial Address Message (IAM) to leave the Transit for the ISUP Initial Address Message (IAM) to leave the Transit
Exchange, travel through the SS7 network (including any applicable Exchange, travel through the SS7 network (including any applicable
STPs (Signaling Transfer Points)), be processed by the End Exchange STPs (Signaling Transfer Points)), be processed by the End Exchange
thus generating the Address Complete Message (ACM) and for the ACM to thus generating the Address Complete Message (ACM) and for the ACM to
travel back through the SS7 network and return to the Transit travel back through the SS7 network and return to the Transit
Exchange. If the bearer path has not been set up within the Exchange. If the bearer path has not been set up within the soft-
soft-switch, media gateway and the IP network that is performing the switch, media gateway and the IP network that is performing the
Transit Exchange function by the time the ACM is forwarded to the Transit Exchange function by the time the ACM is forwarded to the
originating End Exchange, the phenomenon known as ring clipping may originating End Exchange, the phenomenon known as ring clipping may
occur. If ACM processing within soft-switch, media gateway and delay occur. If ACM processing within soft-switch, media gateway and delay
through the IP network is excessive, it will delay the setup of the through the IP network is excessive, it will delay the setup of the
bearer path therefore may cause clipping of ring tone to be heard. bearer path therefore may cause clipping of ring tone to be heard.
A generic maximum ISUP IAM signaling delay value of 240ms for intra A generic maximum ISUP IAM signaling delay value of 240ms for intra
Exchange, which may consist of soft-switch, media gateways, queuing Exchange, which may consist of soft-switch, media gateways, queuing
delay in routers and distance delays between media gateway and delay in routers and distance delays between media gateway and soft-
soft-switch implementations is assumed. This value represents the switch implementations is assumed. This value represents the
threshold where ring clipping theoretically commences. It is threshold where ring clipping theoretically commences. It is
important to note that the 240ms delay objective as presented is a important to note that the 240ms delay objective as presented is a
maximum value. Service administrators are free to choose specific maximum value. Service administrators are free to choose specific
IAM delay values based on their own preferences (i.e., they may wish IAM delay values based on their own preferences (i.e., they may wish
to set a very low mean delay objective for strategic reasons to to set a very low mean delay objective for strategic reasons to
differentiate themselves from other providers). In summary, out of differentiate themselves from other providers). In summary, out of
the 240ms delay budget, 200ms is allocated as cross-Exchange delay the 240ms delay budget, 200ms is allocated as cross-Exchange delay
(soft-switch and media gateway) and 40ms for network delay (queuing (soft-switch and media gateway) and 40ms for network delay (queuing
and distance). and distance).
10. References 10. References
10.1 Normative References 10.1 Normative References
[I-D.iab-auth-mech] [I-D.iab-auth-mech]
Rescorla, E., "A Survey of Authentication Mechanisms", Rescorla, E., "A Survey of Authentication Mechanisms",
Internet-Draft draft-iab-auth-mech-03, March 2004. draft-iab-auth-mech-03 (work in progress), March 2004.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
1981. September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol [RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992. Suite", RFC 1349, July 1992.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995. RFC 1812, June 1995.
[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.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J. and L. Zhang, "Recommendations on Queue S., Wroclawski, J., and L. Zhang, "Recommendations on
Management and Congestion Avoidance in the Internet", Queue Management and Congestion Avoidance in the
RFC 2309, April 1998. Internet", RFC 2309, April 1998.
[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, December Field) in the IPv4 and IPv6 Headers", RFC 2474,
1998. December 1998.
[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.
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597, June 1999.
[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. Stiliadis, J., Courtney, W., Davari, S., Firoiu, V., and D.
"An Expedited Forwarding PHB (Per-Hop Behavior)", Stiliadis, "An Expedited Forwarding PHB (Per-Hop
RFC 3246, March 2002. Behavior)", RFC 3246, March 2002.
[RFC3662] Bless, R., Nichols, K. and K. Wehrle, "A Lower Effort [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, December 2003. RFC 3662, December 2003.
10.2 Informative References 10.2 Informative References
[QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2
Technical Report Proposed Service Definition, March 2001. Technical Report Proposed Service Definition, March 2001.
[RFC1633] Braden, B., Clark, D. and S. Shenker, "Integrated Services [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
in the Internet Architecture: an Overview", RFC 1633, June Services in the Internet Architecture: an Overview",
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.
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to [RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to
TCP's Fast Recovery Algorithm", RFC 2582, April 1999. TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999. Marker", RFC 2697, September 1999.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, September 1999. Marker", RFC 2698, September 1999.
skipping to change at page 53, line 21 skipping to change at page 54, line 15
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000. RFC 2983, October 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000. November 2000.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of [RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, April 2001. their Specification", RFC 3086, April 2001.
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
Explicit Congestion Notification (ECN) to IP", RFC 3168, of Explicit Congestion Notification (ECN) to IP",
September 2001. RFC 3168, September 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", "Aggregation of RSVP for IPv4 and IPv6 Reservations",
RFC 3175, September 2001. RFC 3175, September 2001.
[RFC3290] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290, Informal Management Model for Diffserv Routers", RFC 3290,
May 2002. May 2002.
Authors' Addresses Authors' Addresses
Jozef Babiarz Jozef Babiarz
Nortel Networks Nortel Networks
3500 Carling Avenue 3500 Carling Avenue
Ottawa, Ont. K2H 8E9 Ottawa, Ont. K2H 8E9
Canada Canada
 End of changes. 

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