TSVWG J. Babiarz Internet-Draft K. Chan Expires: August 22, 2005 Nortel Networks V. Firoiu BAE Systems February 18, 2005 Congestion Notification Process for Real-Time Traffic draft-babiarz-tsvwg-rtecn-03 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 August 22, 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 Babiarz, et al. Expires August 22, 2005 [Page 1] Internet-Draft Document February 2005 IP", and apply them to real-time inelastic traffic in DiffServ 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 . . . . 10 3.4.2 ECN Marking of Real-Time Inelastic Flows . . . . . . . 11 3.4.3 ECN Semantics for Real-Time Traffic . . . . . . . . . 11 4. Detection of Inappropriate Changes to the ECN Field . . . . . 12 5. Example of ECN usage for Admission Control . . . . . . . . . . 14 6. Non-compliance . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Issues List . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1 Normative References . . . . . . . . . . . . . . . . . . . 17 11.2 Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 A. Meter Example . . . . . . . . . . . . . . . . . . . . . . . . 18 A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 19 A.2 Meter Configuration . . . . . . . . . . . . . . . . . . . 19 A.3 Meter Behavior . . . . . . . . . . . . . . . . . . . . . . 20 A.4 Marking . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.5 Summary of the Behavior . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 22 Babiarz, et al. Expires August 22, 2005 [Page 2] Internet-Draft Document February 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. The details of this Babiarz, et al. Expires August 22, 2005 [Page 3] Internet-Draft Document February 2005 example is provided by Admission Control Use Case for Real-time ECN [7]. 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 ECN marking both 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 Babiarz, et al. Expires August 22, 2005 [Page 4] Internet-Draft Document February 2005 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 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 Babiarz, et al. Expires August 22, 2005 [Page 5] Internet-Draft Document February 2005 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 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 does not use the same DiffServ service class. Mixing 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 of ECN-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 Babiarz, et al. Expires August 22, 2005 [Page 6] Internet-Draft Document February 2005 PHB treatment. This treatment can be provided only when the real-time service class is not overloaded (i.e., when the aggregate 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 accumulation 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 Babiarz, et al. Expires August 22, 2005 [Page 7] Internet-Draft Document February 2005 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 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. The present proposal of using ECN for congestion indication on real-time flows enables measurement-based solutions for congestion avoidance that do not have such scalability problems associated with resource databases. 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 Babiarz, et al. Expires August 22, 2005 [Page 8] Internet-Draft Document February 2005 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 mechanism may be used. In Appendix A, an example of a simple token bucket method for measurement and marking is provided. 3.3 Behavior of Meter and Marker When the measured rate exceeds the engineered traffic level (for example, 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 equal to, 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] Babiarz, et al. Expires August 22, 2005 [Page 9] Internet-Draft Document February 2005 standardized the use of the ECN bits. 3.4.1 Congestion Notification for Real-Time Traffic Proposed is an usage of the ECN bits in addition to RFC 3168 [6] 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 codepoint as requiring congestion control. 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 ECN-Capable Transport (ECT) marked packets for the defined DSCP value(s) and set the ECN bit to indicated congestion experienced when that traffic rate exceeds the defined level. Figure 3 defines the new ECN semantics for two levels of congestion experienced marking as they apply to real-time inelastic flows. This ECN marking was selected to keep some commonality with the marking and naming in RFC 3168 [6]. RFC 3168 [6] defined ECN marking for a single level of congestion with two ECT codepoints '10' ECT(0) and '01' ECT(1) to provide one-bit ECN nonce for detection of cheaters. Since many application that posses real-time inelastic traffic characteristics require two levels of congestion notification, we have redefined ECN codepoint '01' to represent congestion experienced at 2nd level CE(2). Also, ECN codepoint '11' is renamed from congestion experienced (CE) to congestion experienced at 1st level CE(1). See Section 4 for a procedure that may be used to detect cheaters. The targeted applications have a requirement that the network provide real-time transport with very low packet loss and delay. When 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), policing (metering and dropping) of Not-ECT marked packets SHOULD be performed so that the service class is not oversubscribed. Oversubscription 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 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 Babiarz, et al. Expires August 22, 2005 [Page 10] Internet-Draft Document February 2005 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 perform an ECN set function when an engineered rate is exceeded. With this approach there is no need to perform a test of ECT marked packets to determine at what level of congestion experienced that packet is marked. Other approaches could be used, but for simplicity we have chosen this one. Nodes that are configured to support congestion notification for real-time flows need to provide the following capabilities: o Congestion detection of ECT marked packets 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 When the flow rate exceeds configured rate "A" (i.e., the first level of congestion), ECN bit 7 of ECT market packets is set to '1'. o When the flow rate exceeds configured rate "B" (i.e., the second level of congestion), ECN bits 6 and 7 of ECT market packets are set to '01'. 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 ECN Semantics for Real-Time Traffic Some real-time applications or services need the indication of two levels of congestion experienced, CE(1) and CE(2), for first and second level respectively. Other applications may only need the indication of a single level of congestion experienced. To address a wide range of usage, we have selected the following ECN semantics for real-time inelastic traffic. Babiarz, et al. Expires August 22, 2005 [Page 11] Internet-Draft Document February 2005 ECN Marking: Bits 6 and 7 values 0 0 Not-ECT - Endpoints are Not ECN-Capable 0 1 CE(2) - Congestion Experienced at 2nd level 1 0 ECT(0) - Endpoints are ECN-Capable 1 1 CE(1) - Congestion Experienced at 1st 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 applications will take various independent actions. The various independent actions taken by the applications are out of scope of this document. 4. Detection of 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 policies 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 detection 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 Babiarz, et al. Expires August 22, 2005 [Page 12] Internet-Draft Document February 2005 applications running in the end-systems referred to as sender and responder. Prior to admission of a new real-time flow, the following procedure can be used to detect cheaters. Note that this procedure is independent of an actual admission control procedure. o Under the control of the application, the sender generates and sends a single test packet referred to as a Request Probe Packet. The packet's ECN field is distinctly marked with the value 01, which an ECN-capable router and the responder will perceive as CE(2). o Upon reception of the Request Probe Packet, the responder echoes the received Request Probe Packet back to the sender as a Response Probe Packet, including the value of the ECN field in the IP header of the Request Probe Packet in the payload of the Response Probe Packet. o The sender compares the received ECN marking in the payload of the Response Probe Packet with the value 01 originally set in the Request Probe Packet. If it is 10 or 11 (ECT(0) or CE(1)), then a cheater is present in the network which lowered the ECN marking. The above procedure can optionally be used a second time, but using the ECN value 11, or CE(1), on the Request Probe Packet. Due to the nature of the Real-time ECN process described in this memo, it is only possible to detect for the presence of cheaters which lower the ECN marking. Also, detection of cheaters is only possible if there are no other ECN-capable routers down stream from the cheating device along the network path legitimately marking the ECN bits, masking out the cheating condition. If there are one or more ECN-capable routers along the network path after the cheating device, then the cheater can only be detected if the ECN-capable router(s) after it do not mark the probe packets with a higher ECN value than set by the cheating device. Once a new real-time flow has been admitted, the following procedure can be used to detect cheaters: o The two endpoints involved in a flow negotiate a value N. Normally, a ECN-capable endpoint uses the value 10, or ECT(0), as the ECN for an RTP packet in a flow. The negotiated value N is used such that every Nth packet sent for the flow is initially marked with ECN 01, or CE(2). Upon receipt of the RTP packets, Babiarz, et al. Expires August 22, 2005 [Page 13] Internet-Draft Document February 2005 the endpoint compares the received ECN with the expect value of 01, or CE(2). If a cheater is present, and is not being overridden by one or more ECN-capable router after it along the path through the network, the endpoint detects the presence of a cheater if the received ECN value is 10 or 11 (ECT(0) or CE(1)). 5. Example of ECN usage for Admission Control Normally real-time VoIP bearer traffic is marked with EF DSCP and is 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 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 Babiarz, et al. Expires August 22, 2005 [Page 14] Internet-Draft Document February 2005 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 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", 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. 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. In -02: Section on cheating was added to draft. 2. Need to indicate why we are not concerned with ECT usage. In -02: Explanation was added. However, we are still investigating scenarios where ECT may be useful In -03: Added back the usage of ECT(0). Babiarz, et al. Expires August 22, 2005 [Page 15] Internet-Draft Document February 2005 But because ECT(1) is not used, catching cheating is still different from RFC 3168. 3. Clarify to indicate using specific DiffServ Code Point. In -02: Added clarification in "Abstract" section and added "Applicability and Operating Environment" section. 4. Need Applicability Statement up front. In -02: 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). In -02: 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. In -02: 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. In -02: Open: Keeping current marking as is for this version of draft. Investigate alternate marking approach pros and cons for two level of congestion. In -03: Adopted the use of 00=Not-ECT, 01=CE(2), 10=ECT(0), 11=CE(1); the Alt-1 semantics in early discussions. 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. 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 Babiarz, et al. Expires August 22, 2005 [Page 16] Internet-Draft Document February 2005 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. 11. References 11.1 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. 11.2 Informative References [7] Alexander, C., "Admission Control Use Case for Real-time ECN", Babiarz, et al. Expires August 22, 2005 [Page 17] Internet-Draft Document February 2005 Internet-Draft draft-alexander-rtecn-admission-control-use-case-00 , February 2005. 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 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@nortel.com Victor Firoiu BAE Systems 6 New England Executive Park Burlington, MA 01803 US Phone: +1-781-505-4677 Fax: +1-781-273-9345 Email: victor.firoiu@baesystems.com Appendix A. Meter Example This appendix provides an example of Real-Time ECN capability in a network node. This example uses a Single Rate Meter and ECN Marker. For scenarios that require to measure two traffic levels within a service class 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. Babiarz, et al. Expires August 22, 2005 [Page 18] Internet-Draft Document February 2005 Appendix A.1 Introduction The Single Rate Meter and ECN Marker is configured by assigning values to the following 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 where the measured traffic has exceeded the CIR and token in the token bucket were exhausted below the 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 4: 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 six traffic parameters: Committed Information Rate (CIR), Token Bucket Size (TBS), Token Bucket Drain duration (TBD) TBD=TBS/CIR, Token Bucket Update duration (TBU), and two thresholds (m and n) in percent of TBS. 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 Babiarz, et al. Expires August 22, 2005 [Page 19] Internet-Draft Document February 2005 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. 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-99% 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 = 1-99% of TBS else Decrement Tp by B. Where m > n; both m and n are a percentage of TBS. Babiarz, et al. Expires August 22, 2005 [Page 20] Internet-Draft Document February 2005 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 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 the marking of ECN bit by the Marker. Babiarz, et al. Expires August 22, 2005 [Page 21] Internet-Draft Document February 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 August 22, 2005 [Page 22]