Internet Engineering Task Force Mika Loukola INTERNET DRAFT Helsinki University of Technology Expires May 1999 Jussi Ruutu Nokia Research Center Kalevi Kilkki Nokia Research Center November, 1998 Dynamic RT/NRT PHB Group Status of this Memo This document is an Internet-Draft. 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. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document defines a general use Differentiated Services (DS) [Blake] Per-Hop-Behavior (PHB) Group called Dynamic RT/NRT (DRT) PHB Group. This PHB Group provides delivery of real-time and non-real- time IP traffic. DRT introduces two independently forwarded classes: a real-time (RT) class, and a non-real-time (NRT) class. Within each class an IP packet can be assigned one of six different levels of drop precedence. These levels have a relative order so that a single service (RT / NRT) is formed inside which the packet loss of lower levels does not have any significant effect on upper levels. This concept introduces dynamic RT and NRT services that allow the user to dynamically adjust the packet loss probability in response to the varying network load. A DS node does not re-order IP packets of the same microflow if they belong to the same DRT class. Recommended codepoints for this PHB Group are given. Loukola Dynamic RT/NRT PHB Group [Page 1] INTERNET DRAFT November, 1998 1. Purpose and Overview There is a demand to provide support for real-time IP traffic over the Internet. The user must have the ability to inform the network if the traffic is real-time or non-real-time. The network can utilize this information by offering not only higher probability of timely forwarding but also lower delay for the real-time traffic class. The network load typically changes a lot based on time and routes in the network. As stated in [Blake] the basic philosophy of Differentiated Services is based on not keeping flow states in core network nodes. For this reason it is not possible to a) know the network load at the edge b) predict the network load in advance c) know the exact route of the flow. The Internet traffic is known to be highly variable at different time scales ranging from milliseconds to weeks. On the other hand, the network capacity should be utilized as well as possible. Thus, it is not possible to know beforehand the capacity offered to a certain flow. As a consequence, both the real-time and non-real-time service benefit from the possibility to dynamically adjust to the momentary network load. If the service differentiation is based on using two service levels, the amount of higher level traffic accepted at the network edge must be small enough to guarantee high quality also in the congested areas of the network. Thus, most of the capacity is only used for best effort type of traffic and the benefits of DiffServ remain negligible. The use of more service levels offers higher granularity and fair bandwidth utilization. This Internet Draft defines Dynamic RT/NRT (DRT) PHB Group that provides forwarding of IP packets in real-time or non-real-time DRT classes. Packets are not re-ordered within the class. Both of these classes contain six drop precedence levels. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Bradner]. 2. The DRT PHB Group Dynamic RT/NRT (DRT) PHB Group provides forwarding of IP packets in two DRT classes. The non-real-time (NRT) class (class number 1) has six levels of drop precedence as well as the real-time (RT) class (class number 2). An IP packet that belongs to an DRT class i and has drop precedence j is marked with the DRT codepoint DRT_ij, where 1 <= i <= 2 and 1 <= j <= 6. Loukola Dynamic RT/NRT PHB Group [Page 2] INTERNET DRAFT November, 1998 Under reasonable operating conditions and traffic loads, packets of real-time DRT class (2) have smaller delay and delay variation than the packets belonging to the non-real-time class (1). The real-time DRT class supports applications that are sensitive to delays and delay variations. Even under highly congested network conditions the delay of delivered packets MUST NOT significantly exceed the delay under normal conditions. Traffic that is not considered as time sensitive is forwarded within non-real-time DRT class. Within a DRT class, an IP packet with drop precedence p MUST NOT be forwarded with smaller probability than an IP packet with drop precedence q if p < q. The corresponding drop precedence levels of the two DRT classes SHOULD NOT differ significantly from each other. A DS node MUST NOT re-order DRT packets of the same microflow when they belong to the same DRT class (RT or NRT) regardless of their drop precedence. There are no quantifiable timing requirements (delay or delay variation) associated with the forwarding of DRT packets. It is highly recommended that all six drop precedence levels are implemented. However, if the use of six levels is not possible it is allowed to use also four or five levels. In this case, a DS node MUST accept all six drop precedence codepoints and they MUST yield at least four different levels of loss probability. The DRT PHB group MAY be used to implement both end-to-end and domain edge-to-domain edge services. 3. Traffic Conditioning Actions A DS domain MAY at the edge of a domain control the amount of DRT traffic that enters or exits the domain at various levels of drop precedence. Such traffic conditioning actions MAY include traffic shaping and discarding of packets. Each DS boundary node implementing DRT PHB Group MUST perform one of the following actions: 1) The boundary node has a multi-field (MF) classifier and a meter for measuring the traffic flow. A marker is used to mark the set the DSCP values according to the SLA. DSCP values MAY also depend on the measurement results of the meter. Policer MAY demote PHBs inside the DRT classes. 2) The boundary node has a bandwidth aggregate (BA) classifier. In this case the user pre-marks packets with DSCPs and then the boundary node conditions and polices the user traffic utilizing SLA and the measurement results of the meter. Loukola Dynamic RT/NRT PHB Group [Page 3] INTERNET DRAFT November, 1998 Boundary node MUST classify the traffic into RT and NRT DRT classes according to the SLAs unless the user identified the class. The default DRT class is non-real-time DRT class. Inside the DS domain DSCP MUST NOT be changed. The traffic conditioning actions MUST NOT cause re-ordering of packets belonging to the same DRT class. 4. Tunneling When DRT packets are tunneled, packets belonging to the same microflow MUST NOT be re-ordered. The DSCP of the tunneled packet MUST be reserved. 5. Recommended Codepoints The RECOMMENDED values for the DRT PHB group are as follows. DRT non-real-time traffic is marked by DRT_1x and DRT real-time traffic with DRT_2x. The x indicates the drop precedence value. DRT_11 = '000010', DRT_12 = '000100', DRT_13 = '000110', DRT_14 = '001010', DRT_15 = '001100', DRT_16 = '001110', DRT_21 = '010110', DRT_22 = '011110', DRT_23 = '100110', DRT_24 = '110010', DRT_25 = '110100', DRT_26 = '110110'. The table below summarizes the RECOMMENDED DRT codepoint as well as the previously RECOMMENDED DSCP values for the standard action pool 1. Loukola Dynamic RT/NRT PHB Group [Page 4] INTERNET DRAFT November, 1998 +-----------------+-------------------------------------+ | DSCP value | PHB | +-----------------+-------------------------------------+ | 000000 (P1,00) | Default PHB, Class Selector - DP0 | | 000010 (P1,01) | DRT_11 | | 000100 (P1,02) | DRT_12 | | 000110 (P1,03) | DRT_13 | | 001000 (P1,04) | Class Selector - DP1 | | 001010 (P1,05) | DRT_14 | | 001100 (P1,06) | DRT_15 | | 001110 (P1,07) | DRT_16 | | 010000 (P1,08) | Class Selector - DP2, AF11 | | 010010 (P1,09) | AF12 | | 010100 (P1,10) | AF13 | | 010110 (P1,11) | DRT_21 | | 011000 (P1,12) | Class Selector - DP3, AF21 | | 011010 (P1,13) | AF22 | | 011100 (P1,14) | AF23 | | 011110 (P1,15) | DRT_22 | | 100000 (P1,16) | Class Selector - DP4, AF31 | | 100010 (P1,17) | AF32 | | 100100 (P1,18) | AF33 | | 100110 (P1,19) | DRT_23 | | 101000 (P1,20) | Class Selector - DP5, AF41 | | 101010 (P1,21) | AF42 | | 101100 (P1,22) | AF43, EF | | 101110 (P1,23) | *EF | | 110000 (P1,24) | Class Selector - DP6 | | 110010 (P1,25) | DRT_24 | | 110100 (P1,26) | DRT_25 | | 110110 (P1,27) | DRT_26 | | 111000 (P1,28) | Class Selector - DP7 | | 111010 (P1,29) | | | 111100 (P1,30) | | | 111110 (P1,31) | | +-----------------+-------------------------------------+ * Proposed solution for AF/EF conflict 6. Interactions with Other PHB Groups The behavior of DRT PHB group service can not be implemented using the Assured Forwarding (AF) [Heinanen] PHB Group. Dynamic classes operate best with six (minimum four) different levels of drop precedence. If two AF classes are used to implement one DRT class, packets of the same microflow MAY be re-ordered in the DS node since packet re-ordering MAY occur between AF classes. The same applies for Class Selector Compliant PHB group [Nichols]. Loukola Dynamic RT/NRT PHB Group [Page 5] INTERNET DRAFT November, 1998 That is why twelve new DSCPs of DRT PHB group are needed - six for the non-real-time class and six for the real-time class. All previously presented PHBs: Default PHB [Nichols], Class Selector PHB Group [Nichols], Expedited Forwarding PHB [Jacobson] and Assured Forwarding PHB Group [Heinanen] MAY co-exist with the DRT PHB Group within the same DS domain provided that the other PHB groups do not preempt the resources allocated to the DRT classes. The EF PHB SHOULD have a higher relative order than any DRT PHB. 7. Security Implications In order to protect itself against denial of service attacks, a provider DS domain SHOULD limit the traffic at different drop precedence levels so that traffic at better drop precedence levels will receive sufficient quality. This MAY also limit the total amount of traffic in both DRT classes. In order to protect a link to a customer DS domain from denial of service attacks, the provider DS domain SHOULD allow the customer DS domain to specify how the resources of the link are allocated to DRT packets. If a service offering requires that traffic marked with an DRT codepoint be limited by such attributes as source or destination address, it is the responsibility of the ingress node in a network to verify validity of such attributes. Other security considerations are covered in [Blake] and [Nichols]. 8. Minimal Conformance Requirements A DS node MUST support two DRT classes - a non-real-time (class number 1) and a real-time (class number 2) class. Within each DRT class, a DS node MUST accept all six drop precedence codepoints and they MUST yield at least four different levels of loss probability. An IP packet that belongs to an DRT class i and has drop precedence j is marked with the DRT codepoint DRT_ij, where 1 <= i <= 2 and 1 <= j <= 6. Appendix: Example Services A Service Level Agreement (SLA) between the user and the network provider can include a virtual bit rate value. When the user transmits traffic to the DS network with the momentary bit rate being the virtual one, the DS boundary node marks the packets originating from that user with medium drop precedence. As the momentary bit rate exceeds the virtual one the packets are marked with a drop precedence value indicating a lower relative order. Loukola Dynamic RT/NRT PHB Group [Page 6] INTERNET DRAFT November, 1998 As the momentary bit rate falls below the virtual bit rate packets are marked with a drop precedence indicating a higher relative order. Essentially this kind of service treats all the packets as "in- profile", but the drop precedence level indicates how conservatively the packet is transmitted with respect to the SLA. Thus during network congestion packets fitting more conservatively to their respective profiles receive better Quality of Service (QoS). The DRT PHB group could be used to implement a wide range of services whose time sensitivity and tolerance for packet loss characteristics vary a lot. DRT PHB group supports non-real-time (class number 1) and real-time (class number 2) applications. The charge of the service may be based only on the virtual bit rate. The user can optimize the packet loss versus cost by changing the transmission rate. At times of network congestion the packets marked with higher drop precedence are isolated from the congestion experienced by the packets of lower drop precedence. Appendix: Example Mechanisms for Implementing Real-Time PHB Group The re-ordering of packets belonging to the same microflow can easily be avoided by having separate queues for each DRT class. DRT classes may be realized by a variety of mechanisms, including Weighted Random Early Detection (WRED) as the active queue management algorithm with six separate threshold values, one for each drop precedence level. The real-time queue has a strict priority over the non-real-time queue. The length of the real-time queue is small, typically less than 10 percent of the non-real-time queue. As an example: real-time queue 25 packets, and non-real-time queue 500 packets in length. An essential part of the design is the multi-field (MF) classifier. It measures the momentary bit rate of each flow constantly and marks the incoming packets according to the momentary bit rate and the virtual bit rate agreed upon in the SLA. This measuring approach could be based on the well-known principle of exponential moving average. Another possibility is to utilize the bandwidth aggregate (BA) classifier approach. In this case the user is able to premark the DSCPs that may be demoted by the DS boundary node. Loukola Dynamic RT/NRT PHB Group [Page 7] INTERNET DRAFT November, 1998 References [Blake] Blake, S., et al., An Architecture for Differentiated Services. Internet draft draft-ietf-diffserv-arch-02.txt, October 1998. [Bradner] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels. Internet RFC 2119, March 1997. [Heinanen] Heinanen, J., et al., Assured Forwarding PHB Group. Internet draft draft-ietf-diffserv-af-02-txt, October 1998. [Nichols] Nichols, K., et al., Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. Internet draft draft-ietf-diffserv-header-04.txt, October 1998. [Jacobson] Van Jacobson, et al., An Expedited Forwarding PHB. Internet Draft draft-ietf-diffserv-phb-ef-00.txt, August 1998. Author Information Mika Loukola Helsinki University of Technology Otakaari 5 A 02150 Espoo, Finland Email: mika.loukola@hut.fi Jussi Ruutu Nokia Research Center Itälahdenkatu 22 B 00210 Helsinki, Finland E-mail: jussi.ruutu@research.nokia.com Kalevi Kilkki Nokia Research Center 3 Burlington Woods Drive Suite 260, Burlington MA 01803, USA E-mail: kalevi.kilkki@research.nokia.com Loukola Dynamic RT/NRT PHB Group [Page 8] INTERNET DRAFT November, 1998 Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Loukola Dynamic RT/NRT PHB Group [Page 9]