TSVWG J. Babiarz Internet-Draft K. Chan Expires: July 2, 2005 Nortel Networks V. Firoiu BAE Systems January 2005 Congestion Notification Process for Real-Time Traffic draft-babiarz-tsvwg-rtecn-02 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. 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." 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 July 2, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies the usage of Explicit Congestion Notification (ECN) markings for real-time inelastic flows such as voice, video conferencing, and multimedia streaming. We build on the principles of RFC 3168, "The Addition of Explicit Congestion Notification to IP", and apply them to real-time inelastic traffic in DiffServ Babiarz, et al. Expires July 2, 2005 [Page 1] Internet-Draft Document January 2005 networks. The method specified in this document has the requirement that these real-time inelastic flows can be distinguished from other flows and may receive separate treatment from the network. We introduce new ECN semantics that provide information for two levels of experienced congestion along the path for real-time inelastic flows. This document describes how network nodes perform ECN marking for real-time inelastic flows when congestion is experienced, but it is left up to the application designers to define how end-systems should react to ECN bit marking. For illustration purposes, an example is provided showing how ECN for real-time UDP flows can be used for admission control of VoIP flows. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Requirements Notation . . . . . . . . . . . . . . . . . . 4 1.2 Applicability and Operating Environment . . . . . . . . . 4 1.3 Network with DiffServ and Real-Time ECN Support . . . . . 4 2. General Principles . . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Congestion for Real-Time Traffic . . . . . . . . 6 3.1 Avoiding Congestion for Real-Time Traffic . . . . . . . . 7 3.2 Congestion Detection for Real-Time Traffic . . . . . . . . 8 3.3 Behavior of Meter and Marker . . . . . . . . . . . . . . . 9 3.4 Marking for Congestion Notification . . . . . . . . . . . 9 3.4.1 Congestion Notification for Real-Time Traffic . . . . 9 3.4.2 ECN Marking of Real-Time Inelastic Flows . . . . . . . 10 3.4.3 Definition of Congestion for Real-Time Traffic . . . . 11 4. Possible Inappropriate Changes to the ECN Field . . . . . . . 12 5. Example of ECN usage for Admission Control . . . . . . . . . . 13 6. Non-compliance . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Issues List . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 A. Meter Example . . . . . . . . . . . . . . . . . . . . . . . . 17 A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 17 A.2 Meter Configuration . . . . . . . . . . . . . . . . . . . 18 A.3 Meter Behavior . . . . . . . . . . . . . . . . . . . . . . 19 A.4 Marking . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.5 Summary of the Behavior . . . . . . . . . . . . . . . . . 20 11. Normative References . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 22 Babiarz, et al. Expires July 2, 2005 [Page 2] Internet-Draft Document January 2005 1. Introduction This document summarizes the recommended method for providing end-to-end Explicit Congestion Notification (ECN) for real-time inelastic flows such as voice, video conferencing, and multimedia streaming. RFC 3168 [6] specifies the incorporation of ECN for IP, including ECN's use of two bits in the IP header. This document builds on the concepts of RFC 3168, "The Addition of Explicit Congestion Notification to IP", and applies them to real-time inelastic flows in DiffServ enabled networks. To address a wider usage of this mechanism, it is necessary to introduce new semantics for the ECN field of the IP header (bits 6 and 7 of the TOS byte) that can provide two levels of congestion indication for real-time inelastic flows. There are applications and services that need to provide different treatment at the application level based on the importance of the flow for a given level of congestion experienced. For example, higher importance flows within a service class used for real-time traffic may need to get priority access to the network resources over regular traffic. This document specifies the required behavior of network nodes that are configured to provide ECN-capability for real-time flows. The operating environment is discussed first, and then functions are defined that need to be performed in the network for real-time flows. Specifically, this includes (1) congestion detection through the use of flow measurement and (2) marking of ECN bits in the IP header of real-time packets for a given DSCP-marked service class. Since real-time inelastic flows like voice and video conferencing are very delay sensitive, a different method than what is specified in RFC 3168 for determining levels of congestion needs to be used. The proposal is to use ECN as a method to notify the application that packets flowing on this path are above the engineered capacity of the service class that is used for real-time traffic in the network. Based on this information, the application may take action to reduce its sending rate by whatever means is appropriate; for example stop sending packets, or reduce its rate, or not admit new flows while the path remains congested. The reaction or decision taken by the application to the ECN marking is not specified in this document as it will depend on the application. It is left up to application designers to define how applications in end-systems should react to ECN bit marking that is performed in the network. It is expected that application specific documents will be produced to explain the application's usage of this real-time ECN mechanism. For illustration purposes, a high level example of a procedure that may be used for admission of VoIP flows based on ECN marking within a service class in the network is provided. Babiarz, et al. Expires July 2, 2005 [Page 3] Internet-Draft Document January 2005 1.1 Requirements Notation 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 RFC 2119 [3]. 1.2 Applicability and Operating Environment Networks that need to support real-time inelastic services may need to provide a controlled environment that allows for a high level of guarantees on the quality of service to be honored. We suggest the use of DiffServ service classes to separate the real-time inelastic traffic from the other traffic for such a controlled environment, and applying the Real-Time ECN process discussed in this document. This document addresses the use of the ECN markings in a DiffServ controlled environment, with both marking as defined herein and in RFC 3168 [6] co-existing in the same network but in different service classes. As well, there may be network segments that do not deploy any ECN processing at all. These operating environments are explored and discussed herein. But in all cases, DiffServ separation of the real-time inelastic traffic from the other traffic should be supported. With the basic rules of: o no mixing of Real-Time ECN and RFC 3168 ECN marking in the same service class o no mixing of traffic from Real-Time ECN capable end-systems and from Real-Time ECN un-capable end-systems into the same service class o allowed mixing of traffic from ECN and non ECN capable end-systems at points where congestion is not possible 1.3 Network with DiffServ and Real-Time ECN Support The real-time ECN process requires that the real-time inelastic traffic is separated from the other traffic. Within a DiffServ network, it is perfectly fine to deploy RFC 3168 ECN marking for service classes that are used for elastic TCP traffic and to deploy Real-Time ECN marking as defined herein for service classes that are used for inelastic real-time traffic. DiffServ is used to separate the real-time traffic from the other traffic flows, and Real-Time ECN processing is applied to this separated traffic to provide control within the service class. Under this condition, the most optimal deployment is to have all network segments support DiffServ, with Real-Time ECN marking capability on selected nodes where congestion Babiarz, et al. Expires July 2, 2005 [Page 4] Internet-Draft Document January 2005 within the real-time service class is likely. Over time, as traffic levels within the real-time service class become complex and/or the network topology becomes more complex, it may be preferable that Real-Time ECN capability is extended to all or most network nodes. This notion of traffic separation into different service classes also applies to end-systems supporting Real-Time ECN processing. Traffic from end-systems that do not support Real-Time ECN processing (reaction to ECN marking) should not be placed into the same DiffServ service class as traffic that does. If it were, the end-systems that do not support the Real-Time ECN processing would not "back off" on onset of congestion conditions and would impact flows from end-systems that support Real-Time ECN processing. This approach allows for specific network nodes where congestion is very unlikely to occur not to require DiffServ or Real-Time ECN processing to be deployed. 2. General Principles In this section, some of the important design principles and assumptions guiding the development of this proposal are described. o Because ECN for real-time flows is likely to be adopted gradually and selectively in nodes, accommodating migration and selective deployment is essential. Some nodes may not be able to detect congestion or mark the ECN bits within IP packet headers. Also there may be parts of the network where congestion is very unlikely and therefore there is no need for an ECN function. The most viable strategy is one that accommodates selective or incremental deployment in a network with both ECN-capable and non-ECN-capable nodes. o Asymmetric routing is likely to be a normal occurrence within IP networks. That is, the path (the sequence of links and nodes) taken by forward and reverse packet flows may be different. o Many nodes process the "regular" header in IP packets more efficiently than they process the header information in IP options. This suggests that the ideal approach is to keep "congestion experienced" information in the regular header of an IP packet. o A specific DiffServ service class would be implemented exclusively for real-time traffic flows from ECN-capable end-systems. A different DiffServ service class is used to identify real-time flows that are not ECN-capable. Hence, the ECT(0) or ECT(1) indicators defined in RFC 3168 [6] are not needed. The assumption Babiarz, et al. Expires July 2, 2005 [Page 5] Internet-Draft Document January 2005 is that a signaling protocol (SIP, H.323, MGCP, H.248, etc.) will be used to determine if the end-systems are capable of understanding ECN bit marking and thus, are willing to participate in congestion control prior to usage of the specific ECN-enabled service class. o Furthermore, it is desirable that real-time traffic flows from ECN-capable and non-ECN-capable end-systems are not aggregated into the same DiffServ service class. Aggregating the two may cause the flows that are non-ECN-capable to generate congestion and to introduce delay and/or packet drop to both ECN-capable and non-ECN-capable flows. o The proposed real-time ECN mechanism assumes end-to-end usage of DiffServ in order to allow differentiation of real-time ECN capable traffic from all other traffic on the network. For the real-time ECN capable traffic, the ECT(0) and ECT(1) states defined in RFC 3168 [6] are not used in the network. This is reasonable as the proposed mechanism is meant for managed IP networks. o Flow measurement and marking of ECN bits is defined herein to be performed on flows that are mapped to a set pf ECM-enable service classes, and is performed only on selected node links in the network where congestion is likely to occur. Other traffic flows are not affected by this function. Nodes that do not support this function forward packets without modifying bit 6 and 7 in the ECN field of the IP header. o ECN procedure as defined in RFC 3168 [6] may also be applied to DiffServ service classes in the IP network. Both methods may co-exist in the network, but in different DiffServ service classes. 3. Definition of Congestion for Real-Time Traffic Real-time traffic generated by applications such as voice, video conferencing, and multimedia streaming have different performance requirements when compared with non-real-time applications that use a protocol such as TCP. One such requirement is that end-to-end delay be bounded by a small value, and that packets should not be dropped. It is generally accepted that such performance requirements can be achieved when the real-time flows are serviced by the nodes in their path through a real-time service class such as one based on the EF PHB treatment. This treatment can be provided only when the real-time service class is not overloaded (i.e., when the aggregate Babiarz, et al. Expires July 2, 2005 [Page 6] Internet-Draft Document January 2005 of input traffic never exceeds the class' capacity, and thus no congestion condition occurs). It should also be noted that when the overloaded condition occurs, all real-time traffic flows within the real-time service class at the congestion point will be affected, not just the offending traffic flow. Hence, it is desirable to avoid the overloaded condition as much as possible. With the above performance requirements for real-time inelastic traffic in mind, "congestion of real-time inelastic traffic" is defined to be the network condition when aggregated packet flows within the service class exceed an engineered traffic level. The engineering of the network is such that traffic exceeding this engineered traffic level by a defined and limited amount does not generally cause an increase in packet queuing or packet dropping (service class overload) in the network. Instead, the ECN field is used to provide an indication that traffic is above the engineered traffic level. This can be viewed as explicit notification to prevent congestion. However, uncontrolled or prolonged increase in traffic above the defined amount may result in an increase in packet queuing and/or packet dropping, and therefore may cause overload of the real-time service class. 3.1 Avoiding Congestion for Real-Time Traffic Congestion (ECN) notification can be utilized in a flow admission control scheme to ensure sufficient forwarding resources (bandwidth). In this scheme, a continuous process at selected link(s)/node(s) measures the traffic going through a specified real-time service class and indicates a level of congestion (such as "not congested", "mildly congested" or "severely congested"). This congestion indication as described in Section 3.4.3 is then used by the application to select the action that will be taken by the application controlling the service. The action could be to admit or not to admit a new flow into that real-time service class in the network, or have the sending rate of ECN marked flows reduced or stopped, or terminate a flow. All with the effect of reducing level of offered traffic. Based on the performance requirements of real-time traffic, it is desirable that the measurement process indicate congestion of real-time traffic before any significant packet accumulates in the queue occurs. This is such that no significant queuing delay is added to existing real-time flows' end-to-end delay. An alternative method to avoid the overloaded condition of a service class is through resource reservation and admission control: a (centralized or distributed) database maintains a record of available resources (bandwidth) for the real-time service class on each link in the network and a new flow is admitted only if there are enough Babiarz, et al. Expires July 2, 2005 [Page 7] Internet-Draft Document January 2005 resources on the links in its path so that the overloaded condition is avoided. Checking for available resources can be done with a reservation protocol or through a policy based protocol. An important issue is that the maintenance and per-flow querying of the resource database in conjunction with the routing database is an important overhead that is undesirable in many implementations. 3.2 Congestion Detection for Real-Time Traffic One of the goals is to keep the amount of processing that is performed in the network to be very small and not require any other computations or state information to be kept in network nodes. One way to achieve this is through monitoring the aggregate rate of traffic in the specified real-time service class and to indicate congestion when a certain traffic threshold is exceeded. Hence the network nodes only need to perform flow measurement of packets marked with the defined DSCP value(s) and set the ECN bit(s) when that traffic rate exceeds the defined level. The application monitors the ECN field, and takes an appropriate action based on the marking. Figure 1 below shows a block diagram of the traffic measurement and ECN marking function. The Meter meters each packet within the real-time service class and passes the packet and the metering result to the ECN Marker: +------------+ | Result | | V +-------+ +--------+ | | | ECN | Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream | | | | +-------+ +--------+ Figure 1: Block Diagram of Meter and Marker Function The Marker sets the ECN bit values for each packet within the real-time service class based on the results of the Meter. The traffic rate of the specified service class may be measured with a simple token bucket meter, an exponentially weighted moving average meter, or other methods. The goals of a rate measuring method are simplicity and minimum or no added delay to traffic forwarding. The specification of the traffic measurement mechanism is outside the scope of this document. The intention is that an existing traffic measurement mechanisms may be used. In Appendix A, an example of a simple token bucket method for measurement and marking is provided. Babiarz, et al. Expires July 2, 2005 [Page 8] Internet-Draft Document January 2005 3.3 Behavior of Meter and Marker When the measured rate exceeds the engineered traffic level (i.e., when token bucket runs out of tokens), the Meter sets its result flag and passes it to the Marker. The Marker, sets the appropriate ECN value for all packets belonging to the service class that is measured until the result flag from the Meter is cleared. When the measured traffic rate is, or is reduced below the engineered rate (the token bucket becomes full) the Meter clears the result flag if set. The clearing of the result flag output from the Meter stops marking ECN bits by the Marker. The metering function has built-in hysteresis for setting and clearing the result flag. The amount of hysteresis is controlled by the configuration parameters of the traffic measurement mechanism and should be configured to meet the characteristics of the real-time inelastic traffic that is being measured. 3.4 Marking for Congestion Notification Marking for Explicit Congestion Notifications is done through the use of the two ECN bits in the IP header. 0 1 2 3 4 5 6 7 ----+----+----+----+----+----+----+---- | DS FIELD, DSCP |ECN FIELD| ----+----+----+----+----+----+----+---- DSCP: Differentiated Services Codepoint ECN: Explicit Congestion Notification Figure 2: DS and ECN Fields in IP Header Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field. The IPv4 TOS octet corresponds to the Traffic Class octet in IPv6, and the ECN field is defined identically in both cases. The definitions for the IPv4 TOS octet RFC 791 [1] and the IPv6 Traffic Class octet have been superseded by the six-bit Differentiated Services (DS) field RFC 2474 [4], RFC 2780 [5]. Bits 6 and 7 are listed in RFC 2474 [4] as Currently Unused, and are specified in RFC 2780 as approved for experimental use for ECN. Finally, RFC 3168 [6] standardizes the use of the ECN bits. 3.4.1 Congestion Notification for Real-Time Traffic Proposed is an additional usage of the ECN bits for indicating two levels of congestion for real-time inelastic packet flows in DiffServ capable networks. The selected nodes in the network are configured to measure real-time traffic that is classified and marked via a DS Babiarz, et al. Expires July 2, 2005 [Page 9] Internet-Draft Document January 2005 codepoint as requiring congestion control, i.e., EF DSCP. We would like to keep the amount of processing that is performed in the network elements to be minimal and not require any flow state information to be kept in network nodes. The network nodes only need to perform flow measurement of packets marked with the defined DSCP value(s) and set the ECN bit when that traffic rate exceeds the defined level. Whereas, the application running in the end-system may care about the semantics of the total ECN field as a whole. Figure 3 defines the new ECN semantics as they apply to real-time inelastic flows. It should be noted that the definition and naming of ECN codepoints for real-time flows is different than what is defined in RFC 3168. RFC 3168 addressed ECN marking for a single level of congestion. The ECN-Capable Transport (ECT) codepoints '10' (ECT(0)) and '01' (ECT(1)) defined in RFC 3168 that are set by the data sender to indicate that the end-system's transport are ECN-Capable are not used for applications that use real-time inelastic flows, as only the real-time ECN capable traffic will be placed in the specific service class to receive the real-time ECN treatment in the network. The targeted applications have a requirement that the network provide real-time transport with very low packet loss and delay. Mixing flows from ECN-capable and non-ECN-capable end-systems into the same service class and using ECT for providing treatment differentiation (dropping or ECN marking) in nodes may result in non-ECN-capable end-systems continuing to offer traffic at the current level or possibly even increase the offered rate, therefore causing queue buildup (delay) and eventually introducing packet loss to flows from both ECN-capable and non-ECN-capable end-systems. We prefer to take a gradual or incremental approach for deployment of ECN-capable nodes in the network and use the DiffServ architecture for flow differentiation. Therefore, this new functionality needs only to be deployed in selected nodes, where congestion is likely to occur. The premise is that different traffic types are separated using Differentiated Services into two or more service classes with different polices for each traffic type. However, both methods as described in RFC 3168 and as documented herein for real-time inelastic traffic can co-exist in the network, using independent DiffServ service classes. 3.4.2 ECN Marking of Real-Time Inelastic Flows Marking of ECN bits for real-time inelastic flows is defined so that nodes in the path only need to set one of the ECN bits when an engineered rate is exceeded. Other approaches could be used, but for simplicity we have chosen this one. Babiarz, et al. Expires July 2, 2005 [Page 10] Internet-Draft Document January 2005 Nodes that are configured to support congestion notification for real-time flows need to provide the following capability: o Congestion detection SHOULD be performed using a real-time measurement mechanism (e.g., flow metering). o At a minimum, one flow congestion detection mechanism is REQUIRED to be associated to a link where congestion measurement is performed. o Bit 7 of the ECN field in the IP header MUST be set to 1, when the flow rate exceeds the configured rate "A" (i.e., the first level of congestion). o Bit 6 of the ECN field in the IP header MUST be set to 1, when the flow rate exceeds the configured rate "B" (i.e., the second level of congestion). o Measured rate "B" SHOULD be greater than rate "A". Nodes in the IP network MAY be configured to support one or two congestion detection levels. 3.4.3 Definition of Congestion for Real-Time Traffic Some real-time applications or services need the indication of two levels of congestion experienced, CE(0) and CE(1), for first and second level respectively. Other applications may only need a single indication. To address a wide range of usage, we have selected the following ECN semantics as interpreted by applications for real-time inelastic traffic. ECN States as Interpreted by Application: Bits 6 and 7 values 0 0 Not-CE - Congestion Not Experienced 0 1 CE(0) - Congestion Experienced only at 1st level 1 0 CE(1) - Congestion Experienced only at 2nd level 1 1 CE(2) - Congestion Experienced at 1st and 2nd level Figure 3: ECN Semantics for Real-Time Flows Specific applications may take different action(s) in response to congestion being experienced in the network. Depending on the application, one possible outcome may be for the application to stop initiating new real-time inelastic flows at the 1st level of congestion, and if the offered load in the selected service class reaches the 2nd level of congestion, the application in the end-system stops sending packets. Most likely, different Babiarz, et al. Expires July 2, 2005 [Page 11] Internet-Draft Document January 2005 applications will take various independent actions. The various independent actions taken by the applications are out of scope of this document. 4. Possible Inappropriate Changes to the ECN Field This section discusses in detail possible inappropriate changes to the ECN field in the network, such as falsely reporting no congestion, by erasing the ECN congestion indication. In the implementation of a Real-Time ECN mechanism in the network, the network administrator through the use of polices or through the use of signaling/control protocols such as SIP can verify the capabilities and conformance of the end-systems. As stated earlier, only end-systems that are capable and conformant to Real-Time ECN mechanism may use it. End-systems that are not Real-Time ECN capable or conformant are mapped into a different service class (a service class that is configured not to use Real-Time ECN) or are not allowed access to the network through a deployment of a filter policy at the network edge. The Real-Time ECN mechanism provides two levels of congestion indication; therefore, the cheating mechanism as defined in RFC 3168 that uses ECT(0) and ECT(1) state can not be used. Instead, the following procedure may be used to catch cheaters, network nodes, software drivers or plug-ins that are not part of the certified application in the end-system, altering ECN bit marking. The outlined procedure may be executed under the control of the application prior to admission of a new real-time flow or periodically to verify the conformance of ECN marking. The testing for conformance is between the two ECN capable and conformant applications running in the end-systems referred to as sender and responder. o Under the control of the application, the sender sends four test packets referred to as Request probe packets. The packets' ECN field are distinctly marked with values in the range of "00 - 11". The order of the marking can be random ("00, 11, 01, and 10" or "10, 00, 11, and 01", etc). o Upon reception of the Request probe packet, the responder echoes the received Request probe packets back to the sender as Response probe packets including the value of ECN field in the IP header o The sender compares the received ECN marking of the Response probe packets to Request probe packets originally sent For example, if the following ECN field markings sequence 11, 10, 00, Babiarz, et al. Expires July 2, 2005 [Page 12] Internet-Draft Document January 2005 01 is sent by the sender, the following list of received Response probe packets are possible for paths that are not cheating in both directions: o 11, 10, 00, 01; meaning ECN = 00 Not-CE o 11, 11, 01, 01; meaning ECN = 01 CE(0) o 11, 11, 11, 11; meaning ECN = 11 CE(2) o 11, 10, 10, 11; meaning ECN = 10 CE(1) The following list of ECN field markings of received Response probe packets for the above sent sequence would indicate that the path is not conformant, meaning that one or more nodes in one or the other direction is miss-marking ECN bits (remarking ECN bit(s) to zero): o 00, 00, 00, 00; one or more nodes is setting ECN bit 6 and/or 7 to zero o 10, 10, 00, 00; one or more nodes is setting ECN bit 7 to zero o 01, 00, 00, 01; one or more nodes is setting ECN bit 6 to zero The following list of ECN field markings of received Response probe packets for the above sent sequence would indicate that one or more nodes is selectively remarking (setting ECN bit(s) to zero in only one packet (cheating): o 10, 10, 00, 01; indicates that ECN state 11 was remarked to 10 o 01, 10, 00, 01; indicates that ECN state 11 was remarked to 01 o 11, 00, 00, 01; indicates that ECN state 10 was remarked to 00 o 11, 10, 00, 00; indicates that ECN state 01 was remarked to 00 This method requires the sending of four test packets to determine conformance (no cheating) of network nodes that are in the data path in both directions. The defined method only detects network nodes clearing congestion indication by setting ECN bit(s) to zero. To detect the opposite cheating condition, the setting of ECN bits high to indicate the presence of congestion falsely, traffic load levels in the network needs to be known. 5. Example of ECN usage for Admission Control Normally real-time VoIP bearer traffic is marked with EF DSCP and is Babiarz, et al. Expires July 2, 2005 [Page 13] Internet-Draft Document January 2005 mapped into a DiffServ service class that produces very low latency, jitter and packet loss when the traffic load is within the specified parameters. Currently there is no method defined that can limit (without dropping packets) the amount of traffic that can be aggregated onto a link. As a result, controlling loads to within engineered limits is difficult. To address this issue, we propose that for real-time flows we use the metering and ECN marking method defined in this document. Here we describe how ECN can be used in real-time VoIP solution to provide end-to-end admission of new media flows. This is only a simple example of how admission control may be implemented using rate metering and ECN bit marking in the network. Different applications may use modified approaches to verify if there is sufficient bandwidth before admitting a new flow. Let us assume that the network is configured to mark real-time VoIP payload packets with EF DSCP, and only this traffic is mapped into a DiffServ service class referred to as Telephony service class. Mapping of real-time traffic marked with other DSCP values is possible but to keep this example simple we will only talk about EF marked packets. For example, before a session (i.e., a call) is established between two clients, the two endpoints involved in the call will execute a request/response transaction where the called party (Client B) sends a Request probe packet to the calling party (Client A) and the calling party correspondingly sends back a Response probe packet to the called party. Probe packets are marked with EF DSCP and are mapped into the Telephony service class. A DiffServ style traffic conditioner, meter and ECN marker are used on selected nodes in the network along the path to measure the aggregated (real-time media and probe packets) flow rate of EF marked packets. If the flow rate of the EF marked packets as measured by the meter is greater than rate "A", bit 7 in the ECN field of IP header is set to 1 and the packet is forwarded as usual. The metering and marking of ECN bit only needs to be performed on selected nodes where bandwidth constraints exist and where congestion is likely to occur. Upon receipt of the Request probe packet, the calling party generates and sends a Response probe packet to the called party, echoing the status of the received ECN bits in the Response probe packet. Again, a DiffServ style traffic conditioner, meter and ECN marker are used on selected nodes in the network along the reverse path to measure the aggregated flow rate of EF marked packets. If the flow rate of EF marked packets as measured by the meter is greater than rate "A", Babiarz, et al. Expires July 2, 2005 [Page 14] Internet-Draft Document January 2005 bit 7 in ECN field of IP header is set to 1 and the packet is forwarded as usual. On receipt of the Response probe packet, the called party could send a notification with the ECN Status to relay the ECN bit status results for the media path to a server in the network where call admission control is performed. Based on the received congestion status (bandwidth usage) for that path, the admission control function will make a decision as to whether or not to continue with call setup and admit this new real-time flow. Should bandwidth usage parameters as indicated by ECN bit marking be exceeded, then this new real-time flow will not be admitted. 6. Non-compliance Because of the unstable history of the TOS octet, the use of the ECN field as specified in this document cannot be guaranteed to be backwards compatible with any past uses of these two bits that pre-date ECN. The potential dangers of this lack of backwards compatibility are discussed in RFC 3168 [6] Section 22. 7. Issues List NOTE TO RFC EDITOR: Please remove this section during the publication process. Babiarz, et al. Expires July 2, 2005 [Page 15] Internet-Draft Document January 2005 The following issues list are based on comments received. Issues from Sally during our discussion at San Diego IETF 8/1-6/2004 on -01 version of the draft. 1. Need to resolve Receiver Cheating situations. Section on cheating was added to draft. 2. Need to indicate why we are not concerned with ECT usage. Explanation was added. However, we are still investigating scenarios where ECT may be useful. 3. Clarify to indicate using specific DiffServ Code Point. Added clarification in "Abstract" section and added "Applicability and Operating Environment" section. 4. Need Applicability Statement up front. Added clarification in "Abstract" section and added "Applicability and Operating Environment" section. 5. Change the draft to indicate RFC 3168 applies to UDP as well as TCP (all IP traffic). Removed mentioning of RFC3168 focusing on TCP in "Introduction" and bottom of "Assumptions and General Principles" sections. 6. Provide an explanation on situation where there is a node in the middle that does not understand DiffServ but can do ECN. Added "Applicability and Operating Environment" section. 7. Sally preferred to have the ECN bits to have: 00=Not-CE, 01=CE(0), 10=CE(1), 11=Not-DiffServ-CE. Open: Keeping current marking as is for this version of draft. Investigate alternate marking approach pros and cons for two level of congestion. Figure 4 8. Security Considerations This document discusses detection of congestion for real-time traffic flows and also describes a common policy configuration, for the use and application of ECN bit marking. If implemented as described, it should require the network to do nothing that the network has not already allowed. If that is the case, no new security issues should arise from the use of such a policy. Babiarz, et al. Expires July 2, 2005 [Page 16] Internet-Draft Document January 2005 It is possible for the policy to be applied incorrectly, or for a wrong policy to be applied in the network for the defined congestion detection point. In that case, a policy issue exists that the network must detect, assess, and deal with. This is a known security issue in any network dependent on policy-directed behavior. A well known flaw appears when bandwidth is reserved or enabled for a service (for example, voice transport) and another service or an attacking traffic stream uses it. This possibility is inherent in DiffServ technology, which depends on appropriate packet markings. When bandwidth reservation or a priority queuing system is used in a vulnerable network, the use of authentication and flow admission is recommended. To the author's knowledge, there is no known technical way to respond to or act upon a data stream that has been admitted for service but that it is not intended for authenticated use. 9. IANA Considerations To be completed. 10. Acknowledgements The authors acknowledge a great many inputs, most notably from Sally Floyd, Nabil Bitar, Hadriel Kaplan, David McDysan, Mike Pierce, Alia Atlas, John Rutledge, Francois Audet, Tony MacDonald, Mary Barnes, Greg Thor, Corey Alexander, Jeremy Matthews, Marvin Krym, and Stephen Dudley. Appendix A. Meter Example The below is a description of a Single Rate Meter and ECN Marker. For scenarios that require two traffic levels within a service class to be measured for congestion indications, two instances of the single rate meter and ECN marker can be used, one for configured rate "A" and one for configured rate "B". The meter parameters should be selected to meet the characteristics and performance requirements of traffic being measured as well meters' behavior for each level. Appendix A.1 Introduction The Single Rate Meter and ECN Marker is configured by assigning values to four parameters: Committed Information Rate (CIR), Token Bucket Size (TBS), upper threshold m (in percentage of TBS) and lower threshold n (in percentage of TBS). The Token Bucket Update duration (TBU) is an implementation parameter that may not be configurable. We also consider the Token Bucket Drain duration (TBD) resulting from the first two configurable parameters, TBD=TBS/CIR. The meter also has an internal state "flag" which when set indicates a condition Babiarz, et al. Expires July 2, 2005 [Page 17] Internet-Draft Document January 2005 where the measured traffic has exceeded the CIR and token in the token bucket where exhausted below n threshold, as described below. CIR is measured in bytes of IP packets per second, i.e., it includes the IP header, but not link specific headers. The Meter meters each packet within the real-time service class and passes the packet and the metering result to the Marker: +------------+ | Result | | V +-------+ +--------+ | | | | Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream | | | | +-------+ +--------+ Figure 5: Block Diagram of Meter and Marker Function The Marker sets the ECN bit values for each packet within the real-time service class based on the results of the Meter. Appendix A.2 Meter Configuration The Single Rate Meter and ECN Marker is configured by assigning values to four traffic parameters: Committed Information Rate (CIR), Token Bucket Size (TBS), Token Bucket Drain duration (TBD) TBD=TBS/CIR and Token Bucket Update duration (TBU). CIR is measured in bytes of IP packets per second, i.e., it includes the IP header, but not link specific headers. TBS is measured in bytes, and represents the variants of the rate being measured. Normally, variable rate traffic will need larger token bucket than constant rate traffic, and the size will depend on the characteristics of traffic being measured. TBS should be configured such that traffic variation within the specified rate as measured at the node should not use up all the available tokens during a single TBD duration. TBD and TBU are measured in seconds and TBD should be configured to be at least 2 times greater than TBU. For real-time inelastic traffic, it is recommended that TBD be configured to be greater than the expected inter-packet emission time at sender for the measured packet stream. For best accuracy, TBU should be a small value, as small as implementation practical. Babiarz, et al. Expires July 2, 2005 [Page 18] Internet-Draft Document January 2005 Appendix A.3 Meter Behavior The behavior of the Meter is specified in terms of its Token Bucket Size (TBS) with its rates CIR and Token Bucket Update duration (TBU). Where TBD = TBS/CIR and Where TBD > 2 x TBU The token bucket (TBS) initially (at time 0) is full, i.e., the token count is represented by Tp. Where Tp(0) = TBS Thereafter, tokens (Tp) are added to the token bucket at rate of (CIR x TBU) per TBU. Every TBU; Tp = Tp(t)+(TBU x CIR) If Tp(t) > TBS, Set Tp = TBS If result flag is set and Tp(t) + (TBU x CIR) > m x TBS, clear result flag, and set Tp = TBS Where m = 1-100% of TBS When a packet of size B bytes arrives at time t, the following happens: If result flag is not set and Tp(t)-B < n x TBS, set result flag, and set Tp to zero. (TBS empty) Where n = 0-99% of TBS else Decrement Tp by B. Where m > n; both m and n are a percentage of TBS. The actual implementation of a Meter doesn't need to be modeled according to the above formal specification. Appendix A.4 Marking The ECN Marker reflects the result flag setting received from the meter. If result flag is set, all packets serviced by the real-time inelastic service class have their ECN bit set. The ECN Marker sets Babiarz, et al. Expires July 2, 2005 [Page 19] Internet-Draft Document January 2005 the ECN bit as long as the result flag from the meter is set. Appendix A.5 Summary of the Behavior When the measured rate is exceeded (token bucket runs out of tokens) the meter sets the "result flag" and passes it to the ECN Marker. The ECN Marker, sets the ECN bit of all packets belonging to the service classes flowing through the interface being measured until the traffic rate is reduced below the measuring threshold; thereby the token bucket becomes full. When the token bucket becomes full, the meter clears the "result flag" if set. The clearing of the result flag output from the meter, stops marking of ECN bit by the Marker. 11 Normative References [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] 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. [5] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [6] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. Authors' Addresses Jozef Z. Babiarz Nortel Networks 3500 Carling Avenue Ottawa, Ont. K2H 8E9 Canada Phone: +1-613-763-6098 Fax: +1-613-768-2231 EMail: babiarz@nortel.com Babiarz, et al. Expires July 2, 2005 [Page 20] Internet-Draft Document January 2005 Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US Phone: +1-978-288-8175 Fax: +1-978-288-4690 EMail: khchan@nortelnetworks.com Victor Firoiu BAE Systems 6 New England Executive Park Burlington, MA 01803 US Phone: Fax: EMail: victor.firoiu@baesystems.com Babiarz, et al. Expires July 2, 2005 [Page 21] Internet-Draft Document January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Babiarz, et al. Expires July 2, 2005 [Page 22]