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