TSVWG J. Babiarz Internet-Draft K. Chan Expires: April 27, 2006 Nortel Networks V. Firoiu BAE Systems October 24, 2005 Congestion Notification Process for Real-Time Traffic draft-babiarz-tsvwg-rtecn-05 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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 April 27, 2006. 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 networks. Defined in this document are, new ECN semantics that Babiarz, et al. Expires April 27, 2006 [Page 1] Internet-Draft Document October 2005 provide two levels of experienced congestion along the path for real- time inelastic flows, the required ECN marking behavior in network nodes, and state the required behavior of end-systems that support this function with an explanation of how the two ECN schemes can co- exist safely in the network. Babiarz, et al. Expires April 27, 2006 [Page 2] Internet-Draft Document October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.2. Applicability and Operating Environment . . . . . . . . . 5 2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Application Decisions based on Network Information . . . . 6 2.2. Network Information for Supporting Application Decisions . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Operational Overview with SIP Applications . . . . . . . . 9 2.3.1. Session Admission Control . . . . . . . . . . . . . . 10 2.3.2. Session Preemption . . . . . . . . . . . . . . . . . . 11 2.3.3. Operational Overview Summary . . . . . . . . . . . . . 13 3. General Principles . . . . . . . . . . . . . . . . . . . . . . 13 4. Definition of Congestion for Real-Time Traffic . . . . . . . . 14 4.1. Avoiding Congestion for Real-Time Traffic . . . . . . . . 15 4.2. Congestion Detection for Real-Time Traffic . . . . . . . . 16 4.3. Behavior of Meter and Marker . . . . . . . . . . . . . . . 17 4.4. Marking for Congestion Notification . . . . . . . . . . . 17 4.4.1. ECN Marking of Real-Time Inelastic Flows . . . . . . . 18 4.4.2. ECN Semantics for Real-Time Traffic . . . . . . . . . 18 4.5. End-System Behavior . . . . . . . . . . . . . . . . . . . 19 5. Detection of Inappropriate Changes to the ECN Field . . . . . 20 5.1. During Session Setup . . . . . . . . . . . . . . . . . . . 20 5.2. After Session is Established . . . . . . . . . . . . . . . 23 6. Network with DiffServ and Real-Time ECN Support . . . . . . . 25 6.1. Workable Approach for Co-existence of RT-ECN . . . . . . . 26 7. Discussion on Different Marking Approaches . . . . . . . . . . 27 7.1. Alternate RT-ECN marking . . . . . . . . . . . . . . . . . 27 7.2. Implication of this Marking . . . . . . . . . . . . . . . 27 7.3. Reason for Not Using this RT-ECN Marking . . . . . . . . . 28 8. Example of ECN usage for Admission Control . . . . . . . . . . 28 9. Non-compliance . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Changes from Previous Version . . . . . . . . . . . . . . . . 29 11. Security Considerations . . . . . . . . . . . . . . . . . . . 30 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 14. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 31 14.2. Meter Configuration . . . . . . . . . . . . . . . . . . . 31 14.3. Meter Behavior . . . . . . . . . . . . . . . . . . . . . . 32 14.4. Marking . . . . . . . . . . . . . . . . . . . . . . . . . 33 14.5. Summary of the Behavior . . . . . . . . . . . . . . . . . 33 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . . 33 15.2. Informative References . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 36 Babiarz, et al. Expires April 27, 2006 [Page 3] Internet-Draft Document October 2005 1. Introduction Proposed is an additional usage of Explicit Congestion Notification (ECN) for real-time inelastic flows such as voice, video conferencing, and multimedia streaming. RFC 3168 [7] 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 perform admission control and session preemption. 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 byte two in IPv4 header) 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 or precedence of the flow for a given level of congestion experienced. For example, situation critical or life threatening VoIP flows within a service class used for real-time traffic may need to get priority access to the network resources over regular VoIP traffic. In the specification of the required behavior for network nodes and end- systems that are configured to provide ECN-capability for real-time flows, we factor in the requirements specified in Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field [17]. The operating environment is discussed first, then a framework is provided, 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, (2) marking of ECN bits in the IP header of real-time packets for a given DSCP- marked service class and (3) actions that the end-systems needs to take based on the ECN bits marking. Since real-time inelastic flows like voice and video conferencing are very delay sensitive, a different method than what is described in RFC 3168 for determining levels of congestion needs to be used. The proposal is to use ECN as a method to notify the end-systems 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 end-system needs to 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 detailed mechanism used in the end-system to achieve the required behavior 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 Babiarz, et al. Expires April 27, 2006 [Page 4] Internet-Draft Document October 2005 end-systems should perform the required actions to conform to ECN bit marking 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, one such example is Real-time ECN Use Cases [11] which defines admission control and preemption procedures for VoIP flows. For illustration purposes, a high level example of admission control is provided in this document. 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 [12] 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 [7] 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, or there may be a router in the path that does not support DiffServ but performs ECN marking as defined in RFC 3168. 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 Allow mixing of traffic from Real-Time ECN capable and incapable end-systems in the same service class and using ECN bits to provide the differentiation. o Allow traffic from both Real-Time ECN capable and RFC 3168 conformant end-systems as long as the traffic is marked with different DSCP values (using different service classes). Babiarz, et al. Expires April 27, 2006 [Page 5] Internet-Draft Document October 2005 2. Framework When the packet forwarding network is used to support Session Based Real Time Application usage, the application behavior requires different support from the network. For example, random packet drops does not trigger application to lessen the offered load to the network, it just degrade the session service the application needs. The mechanism described by this document is used within a framework where we try to achieve the following goals: 1. Allow the application control and signaling be separate from the packet forwarding network control and signaling. 2. Keeping the packet forwarding network and its control simple. 3. Allow application features be controlled in the application layer. The above set of goals point us to an architecture where: 1. The network plays a role of providing current network information concerning the availability of network resource to support the application needs. 2. The application uses the information provided by the network to make application level decisions. In the context of Session Admission Control for Real Time traffic with Voice Over IP as an example, we will discuss the framework in the following sections. 2.1. Application Decisions based on Network Information For this document the application decisions is for support of real time traffic session admission control. This includes the decision of: 1. should normal priority real time sessions be admitted. 2. should higher priority real time sessions be admitted. 3. should normal priority real time sessions be terminated. 4. should higher priority real time sessions be terminated. Notice these are decisions local to the application and the actual actions can be controlled by the use of local application level policies. Babiarz, et al. Expires April 27, 2006 [Page 6] Internet-Draft Document October 2005 For normal priority real time session admission control, the goal is to make sure the additional offered load by the new normal priority real time session does not push the network resource utilization into a state that will negatively affect the packet delay, delay variation, loss requirements of the already admitted real time sessions. Hence the application decision is to admit or not to admit a new real time session based on a set of network information. For higher priority real time session admission control, the goal is to make sure the additional offered load by the new higher priority real time session does not push the network resource utilization into a state that will negatively affect the packet delay, delay variation, loss requirements of the already admitted real time sessions. Hence the application decision is to admit or not to admit a new real time session based on a set of network information. Notice by the nature of higher priority real time session, the decision can be to admit higher priority session when not admitting normal priority sessions while approaching fuller utilization of network resources. With the notion of normal priority and higher priority sessions being application level notions and the decisions be application level decisions, possibly determined using local application policies. For normal priority real time session termination decision, the goal is to have a method to decrease the offered load to the network when the network resource utilization approaches the level of affecting the packet delay, delay variation, loss requirements of the already admitted real time sessions. This action is taken due to the fact that for real time sessions like VoIP, the affect will be on all real time sessions that shares the limiting network resource. This decision is to sacrifice a single (or limited number of) real time session on behave of all the other affected real time sessions. For higher priority real time session termination decision, the goal is to have a method to decrease the offered load to the network when the network resource utilization approaches the level of affecting the packet delay, delay variation, loss requirements of the already admitted real time sessions. This action is taken due to the fact that for real time sessions like VoIP, the affect will be on all real time sessions that shares the limiting network resource. This decision is to sacrifice a single (or limited number of) real time session on behave of all the other affected real time sessions. By the nature of higher priority, the normal priority sessions are sacrificed/terminated before higher priority sessions. This can be controlled using local application level policies. Notice the action of the decisions are controlled by local application policies, one example is to do nothing when higher Babiarz, et al. Expires April 27, 2006 [Page 7] Internet-Draft Document October 2005 priority real time session termination decision needs to be made, hence not supporting the higher priority session termination function. We call this Session Admission Control at the application layer. 2.2. Network Information for Supporting Application Decisions For Session Admission Control of Real Time traffic, due to the nature of real time traffic like VoIP, the network information needs to indicate will the offered load introduced by the to-be-admitted session affect the existing admitted sessions. The application also requires the network to indication when more aggressive action is needed by the application to allow acceptable network service be provided to the admitted sessions. Hence we propose the following network information: 1. Network information for session admission control. This information is used to assist the application to decide if a new application session should be admitted to use the packet forwarding network resource. For real time in-elastic session, this information needs to indicate the on-set of additional packet delay/delay-variation/loss that affects the real time in- elastic sessions sharing the packet forwarding network resource. For normal priority session admission control, we allow the network device along the session's packet forwarding path to indicate if a certain level of resource utilization is reached. We call this Admission-Level, and uses bits per second as the basic measurement unit at the network device. When the network resource utilization at a network device exceeds Admission -Level, the network device indicates this condition by using some field in the packet (proposing the use of the ECN field) being forwarded to the session end point. Please notice that the setting of Admission -Level is a local network provisioning policy for the network device. And it may depend on the link speed being used, other traffic sharing the link resource, and other local network device provisioning criterion. This approach allows the network devices' local provisioning policy to control the allocation of resources of the network device, allowing network devices with different capabilities be used in the session packet forwarding path, and providing the information to the application to assist the making of session admission control decision. 2. Network information for session termination. This information is used to assist the application to decide if the network load offered by the application should be lessened to allow existing application sessions to receive acceptable service from the Babiarz, et al. Expires April 27, 2006 [Page 8] Internet-Draft Document October 2005 packet forwarding network. For real time in-elastic session, this information needs to indicate a more severe on-set of additional packet delay/delay-variation/loss that affects the real time in-elastic sessions sharing the packet forwarding network resource, as compared with session admission control information. For normal priority session termination, we allow the network device along the session's packet forwarding path to indicate if a certain level of resource utilization is reached. We call this Termination-Level, and uses bits per second as the basic measurement unit at the network device. When the network resource utilization at a network device exceeds Termination- Level, the network device indicates this condition by using some field in the packet (proposing the use of the ECN field) being forwarded to the session end point. Please notice that the setting of Termination-Level is a local network provisioning policy for the network device. And it may depend on the link speed being used, other traffic sharing the link resource, and other local network device provisioning criterion. This approach allows the network devices' local provisioning policy to control the allocation of resources of the network device, allowing network devices with different capabilities be used in the session packet forwarding path, and providing the information to the application to assist the making of session termination decision. The Termination-Level indication can also be used for higher priority sessions' admission control decision. For example, when Termination-Level indication is received by the application session decision point, higher priority sessions may not be admitted but their session initiation request being queued, depending on the application level higher priority session admission control policy. There are also mechanisms for smoothing out the session termination process and to provide network information to allow multiple higher level session termination. These will be discussed in the detail mechanism sections of this document. In the following section, we provide an operational overview using SIP to show how the above information are used together. In later sections we provide the details of the packet forwarding network mechanism itself. 2.3. Operational Overview with SIP Applications This operational overview section provides some high level indication of how the goals and ideas of previous sections of the framework can be used together in a SIP application environment. We separated the overview into subsections, each describing session admission control operation and session preemption operation. Babiarz, et al. Expires April 27, 2006 [Page 9] Internet-Draft Document October 2005 2.3.1. Session Admission Control For session admission control application level decisions, the application requires the knowledge of "will the offered load of the new session push the network resource utilization along the application media packet forwarding path (called media path for short) beyond the network resource's ability to support the required service". The network provides this information by performing a measurement of packet traffic along the media path and comparing the measurement with a preset Admission-Level. Notice that this Admission-Level can be setup using static or dynamic network device configuration. The mechanism described by this document is independent from network control, provisioning, signaling. Hence allowing network devices freedom to setup Admission-Level based on its capability and local network control/provisioning policy. Since this measurement is performed prior to any application media traffic can flow, we use a pre-media probing method to allow the application to learn this information for session admission control decision. For SIP environment this is described in "RTP Payload Format for ECN Probing" [15]. We also use the SIP application level signaling pre-condition mechanism to indicate the use of this method. Please see A Congestion Status Precondition for the Session Initiation Protocol (SIP) [18] for details. We provided a simple high level operational walk through below, with the presumption that probing starts at a point during session setup when the Receiver endpoint addressing information is known by the Sender. As the immediate application is admission control, the endpoints involved SHOULD NOT begin alerting or otherwise notifying the user of a new session until the admission control procedures determine whether to admit the new session. With an unidirectional probing mechanism, after the Sender knows addressing information specific to the Receiver, it can begin generating probe packets to the Receiver. When the probe packets are received at the Receiver, an admission decision can be made based on the congestion level indicated by the probe packets and the priority associated with the session. The process of making this decision may involve a unilateral decision made in the Receiver, or it may involve communication either back to the Sender, or to another device responsible for making the session admission decision. Babiarz, et al. Expires April 27, 2006 [Page 10] Internet-Draft Document October 2005 (1) (3) +------+ +----------+ +------+ | | | | | | | EP A | ----> | Router A | ----> + EP B | (5) | | | | | | +------+ +----------+ +------+ (2) (4) Figure 1: Session Admission Control 1. Endpoint (EP) A starts the process. It creates a Probe Packet and sends it to the address and port it has for EP B. 2. Router A receives the Probe Packet, and applies a metering and marking mechanism for real-time inelastic traffic. 3. Router A re-marks the ECN field in the IP header of the Probe Packet based on the metering and marking mechanism being used, then forwards the packet. 4. EP B receives the Probe Packet. The ECN value received in the Probe Packet in the IP header indicates exceeding the admission control level of congestion on the path towards EP B. 5. EP B inspects the ECN value received in the IP header, and uses it to begin the decision process on whether to admit the session. In the context of admission control, application level session admission policy may dictate that higher priority sessions may get admitted when the Probe Packets indicate pre-congestion level that prevent normal priority sessions from being admitted. 2.3.2. Session Preemption For application level session preemption decisions, the application requires the knowledge of "is the current offered load of network traffic pushing the network resource utilization along the application media packet forwarding path beyond the network resource's ability to support the required service for the admitted sessions?". This condition can occur even when session admission control have been applied. For example, packet network routing change can cause previously different session packet forwarding paths to merge at some points in the network and pushed the network Babiarz, et al. Expires April 27, 2006 [Page 11] Internet-Draft Document October 2005 resource utilization at these points to beyond their ability to support the required service. These packet network routing change may be caused by router failures or other reasons, this framework allows the packet forwarding network to use whatever method it chooses to provide the best packet forwarding network service without getting in its way. The application just need to know if it needs to take action based on the resulting packet forwarding network conditions. The above knowledge can be provided to the application by the network. As with the probe packets described in the context of session admission control, endpoints can similarly monitor the ECN value of RTP media packets and react accordingly, initiating preemption mechanisms when necessary. If the preemption threshold level is exceeded, as indicated by the ECN value of the media packets, application level local policy may dictate session preemption as a required action to keep bandwidth resource usage within engineered limits. The example provided here shows only a unidirectional media flow. A bidirectional session would operate similarly, but with two unidirectional flows in opposite directions. The example provided here describes an application level local policy dictating that preemption occurs when the preemption threshold level has been exceeded, as indicated by the ECN value of the media packets. (1) (3) +------+ +----------+ +------+ | | | | | | | EP A | ----> | Router A | ----> + EP B | (5) | | | | | | +------+ +----------+ +------+ (2) (4) Figure 2: Preemption 1. Endpoint (EP) A starts the process. It creates an RTP media packet and sends it to the address and port it has for EP B. Each media packet is marked with default ECN value to indicate no congestion. 2. Router A receives the RTP media packets, and applies a metering and marking mechanism for real-time inelastic traffic. Babiarz, et al. Expires April 27, 2006 [Page 12] Internet-Draft Document October 2005 3. Router A re-marks the ECN field in the IP header of the RTP media packets based on the metering and marking mechanism being used, then forwards the packet. For the purposes of this example, it is presumed the network resource condition is such that Router A marks the ECN bits to indicate that the preemption level of congestion has been exceeded. 4. EP B receives the RTP media packets. EP B monitors the ECN value of RTP media packets, and upon receiving packets marked with the ECN value indicating that the preemption level of congestion has been exceeded somewhere along the path in the network, it follows local application level session preemption policy to initiate session preemption. 5. The specific actions taken to carry out preemption may vary, as they are local application level session preemption policy. 2.3.3. Operational Overview Summary The simple high level walk through of operational overview for session admission control and session preemption in previous sections provided some overview of how we: 1. Keep the application features being controlled in the application layer using application level session policies. 2. Keep the packet forwarding network and its control simple by just adding simple network condition indication to the forwarded packet with existing packet header field. 3. Allow the application control and signaling be separate from the packet forwarding network control and signaling. And allowing the packet forwarding network to do what it does best without adding application level baggage to it. And allowing the application layer to do what it does best on utilizing the packet forwarding network resources. 3. 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 Babiarz, et al. Expires April 27, 2006 [Page 13] Internet-Draft Document October 2005 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 for real- time traffic. 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 marking packets as ECN-Capable Transport (ECT). o Flow measurement and marking of ECN bits as defined herein is performed on flows from ECN-capable end-systems that is mapped to a ECN-enabled service class, and may be performed 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 the ECN field of the IP header. o ECN procedure as defined in RFC 3168 [7] 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. 4. 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 elastic applications that use a protocol such as TCP. One such requirement is that end- to-end delay be bounded to a small value, and that packets should not be dropped. It is generally accepted that such performance requirements can be Babiarz, et al. Expires April 27, 2006 [Page 14] Internet-Draft Document October 2005 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 Expedited Forwarding (EF) PHB [8] 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. 4.1. Avoiding Congestion for Real-Time Traffic Congestion notification can be utilized in a flow admission control scheme to ensure sufficient forwarding resources (bandwidth), hence for Real-Time Traffic, ECN is used to prevent congestion. 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 4.4.2 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. Babiarz, et al. Expires April 27, 2006 [Page 15] Internet-Draft Document October 2005 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 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. 4.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 need only to perform flow measurement of packets marked with specific DS codepoint and with ECN indication that the end- system is ECN-capable. Another policy that may be used is where network nodes perform flow measurement of packets marked with a specific DS codepoint and if the rate is exceeded, only ECN mark packets that indicate that they are ECN-capable. The application monitors the ECN field, and takes an appropriate action based on the marking. Figure 3 below shows a block diagram of the traffic measurement and ECN marking function. +------------+ | Result | | V +-------+ +--------+ | | | ECN | Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream | | | | +-------+ +--------+ Figure 3: Block Diagram of Meter and Marker Function The Meter meters each packet within the real-time service class and passes the packet and the metering result to the ECN Marker. The Marker sets the ECN congestion level for each packet that is marked as ECN-capable within the real-time service class based on the results of the Meter. Babiarz, et al. Expires April 27, 2006 [Page 16] Internet-Draft Document October 2005 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. 4.3. Behavior of Meter and Marker When the measured rate exceeds the engineered traffic level for ECN- capable marked packets, the Meter sets its result flag and passes it to the Marker. The Marker, sets the appropriate ECN value for all ECN-capable marked packets belonging to the service class that is measured until the result flag from the Meter is cleared. When the measured traffic rate is reduced below the engineered rate 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 (example size of the token bucket) of the traffic measurement mechanism and should be configured to meet the characteristics of the real-time inelastic traffic that is being measured. See report, Simulation of RT-ECN based Admission Control and Preemption [13] for results of the above metering and marking as well analysis of different metering approaches in Discussion of Congestion Marking with RT-ECN [14]. 4.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 4: DS and ECN Fields in IP Header Bits 6 and 7 in the IPv4 octet are designated as the ECN field. This octet of the IPv4 header corresponds to the Traffic Class octet in IPv6, and the ECN field is defined identically in both cases. The Babiarz, et al. Expires April 27, 2006 [Page 17] Internet-Draft Document October 2005 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 [6]. 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 [7] standardizes the use of the ECN bits. 4.4.1. ECN Marking of Real-Time Inelastic Flows Marking of ECN bits for real-time inelastic flows is defined so that nodes in the path need only to perform an ECN set function when an engineered rate is exceeded for packets that are marked as ECN- capable. With this approach there is no need to perform a test to determine the congestion level marking of the received packet before a node performs ECN marking. Other approaches could be used, but for simplicity we have chosen this one. In Section 7 we discuss the different marking approaches that were studied. Network nodes that are configured to support congestion notification for real-time flows need to provide the following capability: o Congestion detection of packets marked indicating that the end- system is ECN-capable (ECT) SHOULD be performed using a real-time measurement mechanism (e.g., flow metering). o When the flow rate exceeds configured rate "A" (i.e., the first level of congestion), ECN bit 7 of ECT marked 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". 4.4.2. 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 a single indication. To address a wide range of usage, we have selected the following ECN semantics for real-time inelastic traffic. Babiarz, et al. Expires April 27, 2006 [Page 18] Internet-Draft Document October 2005 ECN Marking: Bits 6 and 7 values 0 0 Not-ECT - End-system is Not ECN-Capable Transport 1 0 ECT(0) - End-system is ECN-Capable Transport 1 1 CE(1) - Congestion Experienced at 1st level 0 1 CE(2) - Congestion Experienced at 2nd level Figure 5: ECN Semantics for Real-Time Flows 4.5. End-System Behavior Listed below are reactions to ECN marking that needs to be supported by end-systems that indicated that they are ECN-capable: o Under normal (non emergency or situation critical) conditions during new flow establishment, ECN-capable end-system that receive packets marked indicating that congestion was experienced at 1st level CE(1), SHOULD NOT proceed with the session setup. New flows that indicate that they are "emergency or situation critical" SHOULD be allowed admission at CE(1). The definition and verification of what flow is classified as "emergency or situation critical" is left up to the application. o Once a flow has been admitted and the path experience 1st level of congestion CE(1), ECN-capable end-systems that have ability to dynamically react to ECN marking, SHOULD reduce their sending rate as agreed to during session setup. o During new flow establishment, ECN-capable end-systems that receive packets marked indicating that congestion was experience at 2nd level CE(2) SHOULD NOT proceed with session setup. o Systems with established flows that experience the 2nd level of congestion CE(2) SHOULD terminating sessions or reduce sending rate in a controlled manner, and continue until the congestion level drops below the 2nd level of congestion. Generally, at 1st level of congestion, no additional traffic should be added with the exception for flows that are identified as being potentially life threatening i.e., E911 or situation critical. End- systems that have the ability to reduce their sending rate should do so. At 2nd level of congestion, no additional traffic is added to the congested path plus selected flows on the congested path are removed to reduce congestion below 2nd level. Babiarz, et al. Expires April 27, 2006 [Page 19] Internet-Draft Document October 2005 5. Detection of Inappropriate Changes to the ECN Field This section discusses in detail some of the possible inappropriate changes to the ECN field in the network, such as reducing level of congestion, falsely reporting no congestion, or modifying ECN bits to indicate that the path is or is not Real-Time ECN compliant. Reducing the level of congestion or falsely reporting no congestion will be referred to here as "cheating". The Real-Time ECN mechanism provides two levels of congestion indication. Therefore, the cheating detection mechanism as defined in RFC 3168 [7] and RFC 3540 [10] that uses ECT(0) and ECT(1) states can not be used. Instead, the procedure outlined in this memo SHOULD be used to detect if inappropriate changes to the ECN bits have occurred between originator and receiver. The outlined procedure is executed under the control of the application prior to admission of a new real-time flow. The testing for conformance is performed between the two Real-Time ECN-capable and conformant applications running in the end-systems. These two end-systems will be referred to as sender and receiver. 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 applications running in end-systems that are capable and conformant to this Real-Time ECN mechanism may use it. End-systems that are not Real-Time ECN-capable or conformant MUST set ECN field to '00' when sending packets. 5.1. During Session Setup During the admission of a new real-time flow, application signaling is used to exchange end-system capabilities, including whether the end-systems are Real-Time ECN capable. The Real-Time ECN mechanism defined in this memo can be used to provide admission control capabilities to end-systems. In order to provide this capability, the signaling used by the end-systems requires a means to both trigger the Real-Time ECN probing process as described in "RTP Payload Format for ECN Probing" [15] and "Real-time ECN Use Cases" [11], as well as to delay session setup; - specifically user indication of a new session, i.e., ringing until an admission control decision has been made. In the context of SIP, preconditions can be used to accomplish both of these requirements. For more details, see A Congestion Status Precondition for the Session Initiation Protocol (SIP) [18]. If signaling indicates that the destination end-system does not Babiarz, et al. Expires April 27, 2006 [Page 20] Internet-Draft Document October 2005 support the Real-Time ECN mechanism, the originating end-system MAY reattempt the session without stipulating the use of the Real-Time ECN mechanism. While such a session would not undergo the Real-Time ECN admission control tests, this does allow session creation between end-systems that support the Real-Time ECN mechanism and those that do not. Prior to admission of a new real-time flow, the following procedure SHOULD be used to detect inappropriate changes to ECN field. Note that this procedure can be independent of an actual admission control procedure. Under the control of the application, the sender generates and sends a stream of RTP-probe packets. This stream of RTP-probe packets is specified as follows: 1. A random sequence of the four possible ECN bit combinations is selected, and this sequence of values is used as the ECN field values on the initial four RTP-probe packets. The ECN field marking is also copied into the RTP-probe payload [15] and the payload should be secured. SRTP RFC 3711 [9] is one mechanism that can provide the necessary security for the probe packets. 2. After the sequence of four RTP-probe packets is sent, the sender sends RTP-probe packets with randomly generated ECN bit of '10', '11' and '01' until probing is stopped. As before, the ECN field marking is also copied into the RTP-probe payload and the payload should be secured. The probing sequence just described is one method that can be implemented for probing to detect inappropriate changes to the ECN field. Because the ECN field marking on probe packets is always copied into the RTP-probe payload, the receiving end-system is always able to compare the received ECN value in the IP header with that in the secured RTP-probe payload. Therefore the ability to detect inappropriate changes to the ECN Field via probing is independent of the ECN bit sequence used. Upon reception of the RTP-probe packet, the receiver compares the received ECN marking in the IP header to ECN marking in RTP-probe payload. A packet sent with ECN field '10' and received as indicated below have the meanings as indicated: o Received as '10': path is valid, no congestion. Babiarz, et al. Expires April 27, 2006 [Page 21] Internet-Draft Document October 2005 o Received as '11': path is valid, congestion experienced at 1st level. o Received as '01': path is valid, congestion experienced at 2nd level. o Received as '00': path is not valid, device in path zeroed ECN field. Packet sent with ECN field '01' and received as indicated below have the meanings as indicated: o Received as '01': path is valid. o Received as '11': path is not valid, device in path reduced congestion experienced to 1st level, this could also mean that the path is through a congested router that used RFC 3168 for ECN marking of this flow. o Received as '10': path is not valid, device in path cleared indication of congestion experienced. o Received as '00': path is not valid, device in path zeroed ECN field. Packet sent with ECN field '11' and received as indicated below have the meanings as indicated: o Received as '11': path is valid. o Received as '01': path is valid, congestion experienced at 2nd level. o Received as '10': path is not valid, device in path cleared indication of congestion experienced. o Received as '00': path is not valid, device in path zeroed ECN field. Packet sent with ECN field '00' and received as indicated below have the meanings as indicated: o Received as '00': path is valid. o Received other than '00':, path is not conformant. The above mechanism will detect when a device in the path tries to cheat by changing the ECN field to indicate no congestion, or reduce Babiarz, et al. Expires April 27, 2006 [Page 22] Internet-Draft Document October 2005 the level of congestion, or incorrectly indicate a path is or is not ECN capable. Due to the nature of the Real-time ECN process described in this memo, it is not possible to detect the presence of devices which raise the level of congestion in the ECN marking. The detection of presence of devices that lower ECN marking is only possible if there are no other Real-Time ECN capable routers down stream from the cheating device along the network path legitimately marking the ECN bits, masking out the cheating condition. However, this is not a problem if the down steam router marks ECN back to the appropriate congestion level, as the end-system will take the correct action for that flow. The outlined procedure for detection of inappropriate changes to the ECN field is also applied to RTP-probe flow in the direction from call originator to the far-end as outlined in Real-time ECN Use Cases [11]. During session setup phase, if it is determined that the path is invalid, non-conformant or congested, the setup of the session SHOULD be terminated with cause information provided to the user. 5.2. After Session is Established Once a new real-time flow has been admitted, the following procedure SHOULD be used to detect cheaters and routers that use ECN procedure defined in RFC 3168: o For real-time flow, the media packets are sent with an ECN value of '10' set in the IP header. At random intervals, a single media packet will be sent with '01' in order to detect the cheaters and congested RFC 3168-capable routers. The receiver must be aware of which packets the sender marked with '01', so that it does not misinterpret such packets as indicating congestion. o In order that both the sender and receiver are synchronized as to which packets are marked '01', they will use a common function to determine which packets are marked. The Mersenne Twister MT 19937 [16] random number generator, seeded with the initial RTP Sequence Number used by the sender, is utilized in this synchronization process. o During the initial RTP-probe sequence [15] that was used to verify conformance of path during session setup, the initial Sequence Number used by the sender is sent to the receiver in the payload of the probe packets. This value is used as a seed in a Mersenne Twister MT 19937 random number generator in both the sender and receiver. The sender begins sending media packets marked with ECN Babiarz, et al. Expires April 27, 2006 [Page 23] Internet-Draft Document October 2005 '10'. The sender and receiver each use the MT 19937 function to select the next pseudorandom number in the sequence, modulus 4, to determine the next packet to mark with ECN '01'. The use of modulus 4 is to keep the interval between packets used for detection of cheaters, etc., bounded. In the sender, the following steps describe this process: 1. During probing, send the Initial RTP Sequence Number (IRSN), in the payload of the probe packet. 2. Seed the MT 19937 function with the initial sequence number: MT19937.seed(IRSN). 3. Calculate N, the number of media packets to be marked with ECN '10', before marking a single media packet with ECN '01', as follows: N = (MT19937.next)(MOD 4) + 1. 4. Once the real-time flow begins, mark N packets with ECN '10'. 5. Send the next packet with ECN '01'. 6. Repeat starting with Step 3, until the real-time flow is terminated. In the receiver, the following steps describe this process: 1. During probing, pull the Initial RTP Sequence Number (IRSN) from the payload of a received probe packet[15]. Initialize NSN (described in Step 4 below): NSN = IRSN. 2. Seed the MT19937 function with the initial sequence number: MT19937.seed(IRSN). 3. Calculate N, the number of media packets to be marked with ECN '10', before marking a single media packet with ECN '01', as follows: N = (MT19937.next)(MOD 4) + 1. 4. Calculate NSN, the sequence number of the next packet expected to be marked with ECN '01': NSN = NSN + N. 5. Receive media packets, watching for a packet with a sequence number equal to or greater than NSN, until the real-time flow is terminated: A. Packets with a sequence number less than NSN are used for congestion detection. Repeat Step 5. Babiarz, et al. Expires April 27, 2006 [Page 24] Internet-Draft Document October 2005 B. Packets with a sequence number equal to NSN are used for detection of cheaters and congested RFC 3168-enabled routers. If the ECN value of this packet is not '01', a cheater or congested RFC 3168-enabled router is present along the network path. Jump to Step 3 and repeat. C. Packets with a sequence number greater than NSN should result in calculation of a new NSN value. Jump to Step 3 and repeat. The previous algorithm is one that should be used. Other methods can be used as long as both the sender and receiver agree to it. Upon receipt of an RTP packet the receiver expects to be marked '01', the end-system compares the received ECN field with the expected value of '01', or CE(2). If a cheater is present, and is not being overridden by marking of one or more Real-Time ECN capable routers along the path through the network, the end-system detects the presence of a cheater if the received ECN value is '10' or '11' or '00', (ECT(0) or CE(1) or Not-ECT). Also, this procedure can be used to detect the presence of congested routers that use RFC 3168 as its ECN marking. A congested router that uses the ECN marking procedure as defined in RFC 3168 will interpret ECN value '01' as ECT(1) and change the marking to '11' (CE). If after a session has been admitted it is detected that there is a cheater or congested router that uses RFC 3168 for ECN marking of real-time flows, the established session SHOULD be terminated with cause information provided to the user. 6. 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 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. Babiarz, et al. Expires April 27, 2006 [Page 25] Internet-Draft Document October 2005 This approach allows for incremental deployment of DiffServ and Real- Time ECN. Specific network nodes where congestion is not likely to occur may delay its use of DiffServ and ECN. 6.1. Workable Approach for Co-existence of RT-ECN Routers need a method to understand which ECN mechanism should be applied based on the traffic being forwarded. We believe DiffServ architecture can provide this capability. The normal practice is to segregate elastic and real-time inelastic flows into different service classes that use different PHBs with the DS codepoint being used as the indicator for selection of the PHB. Router can implement both ECN procedures and use DS codepoint for indicating which ECN mechanism applies to each packet. The approach that we selected allows for two different ECN mechanisms, one for elastic flows and the other for real-time inelastic flows with the following rules for deployment: 1. ECN as per RFC 3168 applies to the Default Forwarding [4] PHB '000000'. 2. In DiffServ enable networks, DS codepoints is used to indicate the ECN mechanisms that may be supported. A. ECN as per RFC 3168 should be used with the AF [5] PHBs. B. RT-ECN should be used with EF [8] PHB. C. Class Selector PHBs may use RFC 3168 or RT-ECN and should be based on traffic characteristic assigned to the PHB. See Configuration Guidelines for DiffServ Service Classes [12] for guidance. 3. As RFC 3168 defines the default behavior, all other mechanisms that are defined should not cause harm to the default ECN behavior or network if the alternate ECN mechanism encounters RFC 3168 marking. As stated in Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field [17] "that the default ECN semantics defined in RFC 3168 are the current default semantics for the ECN field, regardless of the contents of any other fields in the IP header. In particular, the default ECN semantics apply for more than best-effort traffic with a codepoint of '000000' for the diffserv field - the default ECN semantics currently apply regardless of the contents of the diffserv field." We propose that an amendment to RFC 3168 be considered that would allow non default DS codepoints Babiarz, et al. Expires April 27, 2006 [Page 26] Internet-Draft Document October 2005 to be used for indicating alternate ECN semantics with guidance as stated above. 7. Discussion on Different Marking Approaches In our analysis of ECN marking to address the needs of real-time flows like voice and video conferencing, we look at different marking schemes so that the ECN bit definition and meanings be closely aligned with what is defined in RFC 3168. Below is one example worth noting that was considered but rejected even if it uses the same ECN semantics as what is defined in RFC 3168. 7.1. Alternate RT-ECN marking During session setup (flow admission), end-system marks its' packets with ECT(0) ECN='10' and once the flow is admitted the end-system marks its' packets with ECT(1) ECN='01'. With the following metering and marking policy in router, packets that are marked as ECN-capable (ECN= 10, 11 or 01) are meter by both meters: o If traffic exceeds 1st threshold level, mark ECN-capable ECT(0) '10' packets to indicate that congestion was experienced CE '11'. o If traffic exceeds 2nd threshold level, mark ECN-capable ECT(1) '01'packets to indicate that congestion was experienced CE '11'. ECN Marking (identical to RFC 3168): Bits 6 and 7 values 0 0 Not-ECT - End-system is Not ECN-capable 0 1 ECT(1) - End-system is ECT, once flow is admitted 1 0 ECT(0) - End-system is ECT, during flow admission 1 1 CE - Congestion Experienced Figure 6: Alternate ECN Semantics for Real-Time Flows 7.2. Implication of this Marking During session setup (admission control) end-systems send their packets marked with ECT(0) '10' and once the flow is admitted, end- systems mark their packets with ECT(1) '01'. Routers have a policy that meters all ECN-capable traffic, packets marked with ECT(0) are measured to the 1st threshold level and packets marked with ECT(1) are measured against the 2nd threshold level. The receiving end- system must be informed (some how) if the packet is ECT(0) or ECT(1), Babiarz, et al. Expires April 27, 2006 [Page 27] Internet-Draft Document October 2005 during RTP-probing as well after, and there are methods to achieve this. 7.3. Reason for Not Using this RT-ECN Marking The concern that the authors of this draft had with the use of the same ECN semantics for two different congestion control mechanism is that there is no simple method for detection of the wrong ECN behavior being applied by router in the path. As stated in Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field [17] a method is needed for end-systems to verify that routers are applying the compliant marking for safe co- existence of alternate ECN behavior. For the proposed ECN semantics (see Section 4.4.2), and Section 5 of this document defines a method that can be used to detect the presence of congested routers that use RFC 3168 for its ECN marking. As well, we would like to note that the procedure outlined in RFC 3540 can be used to detect presence of congested routers that use RT-ECN marking. 8. 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 Babiarz, et al. Expires April 27, 2006 [Page 28] Internet-Draft Document October 2005 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", 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. 9. 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 [7] Section 22. 10. Changes from Previous Version NOTE TO RFC EDITOR: Please remove this section during the publication process. Babiarz, et al. Expires April 27, 2006 [Page 29] Internet-Draft Document October 2005 This version of the draft was rework to address the requirements stated in Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field [17], updated section that define "Detection of Inappropriate Changes to the ECN Field" and changes to Appendix A. 11. 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 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. 12. IANA Considerations To be completed. 13. 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, Stephen Dudley, Bob Briscoe, David Black, and Ralph Carsten. 14. Appendix A Babiarz, et al. Expires April 27, 2006 [Page 30] Internet-Draft Document October 2005 Below is a description of a Single Rate Meters and ECN Marker. For scenarios that require two traffic levels within a service class to be measured for congestion indication, two instances of the single rate meter can be used, one for configured rate "A" and the other for configured rate "B", with a single ECN marker. The meter parameters should be selected to meet the characteristics and performance requirements of traffic being measured. 14.1. Introduction The Single Rate Meters and ECN Marker is configured by assigning values to four parameters: Committed Information Rate (CIR), Token Bucket Size (TBS), ECN set threshold 'm' as a percentage of TBS and ECN clear threshold 'n' as a percentage of TBS. The meter has an internal state "result flag" which when set indicates a condition where the measured traffic has exceeded the CIR and token in the token bucket where exhausted below 'm' threshold. When the rate decreases below CIR, token bucket is filled above 'n' threshold and the internal "result flag" is cleared. 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 7: 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. 14.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), and values 'm' and 'n' representing percentage fullness of Token Bucket. 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. 'm' and 'n' are percentages that change size of TBS depending on the state of the result flag. Normally, variable rate traffic will need larger token bucket than Babiarz, et al. Expires April 27, 2006 [Page 31] Internet-Draft Document October 2005 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 measurement duration. 14.3. Meter Behavior The behavior of the Meter is specified in terms of its Committed Information Rate (CIR), Token Bucket Size (TBS) and its ECN set and clear thresholds 'm' and 'n'. Initially (at time 0), token bucket (TBS) is full, i.e., the token count is represented by Tp. Where Tp(0) = TBS As well, the internal meter result flag (1st_result_flag) is cleared. When a packet of size B arrives at time t, the following happens: Tp = Tp(t) + (CIR x delta_t) //tokens added at CIR Tp = Min (Tp(t), TBS) //keep Tp from growing pass full Tp = Tp(t) - B //decrement Tp by B bytes Tp = Max (0,Tp(t)) //keep Tp from going negative if (1st_result_flag = = 0) //internal result_flag not set? if (Tp < TBS x m) //has traffic exceeded CIR? 1st_result_flag = 1 //set internal result_flag Tp = 0 //set token bucket to zero else //if internal result_flag is set if (Tp > TBS x n) //is traffic below CIR? 1st_result_flag = 0 //clear internal result_flag Tp = TBS //set Tp to TBS return Where m and n is 1-99% Notes: - delta_t is the elapsed time from the previous received packets. - m controls token bucket threshold for setting the result flag. - n controls token bucket threshold for clearing the result flag. A second instance of this single rate meter can be configured for measurement of rate "B" (the second rate). The actual implementation of a Meter doesn't need to be modeled according to the above formal specification. Babiarz, et al. Expires April 27, 2006 [Page 32] Internet-Draft Document October 2005 14.4. Marking The ECN Marker reflects the result flag setting received from the Meters. If 1st_result_flag is set, all packets indicating that the end-system is ECN-capable, have their ECN bit 7 set to '1'. If the 2nd_result-flag is set, all packets indicating that the end-system is ECN-capable have their ECN bits 6 and 7 set to '01'. The ECN Marker sets the ECN bit of ECN-capable marked packets as long as the result flag(s) from the meters is set. 14.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(s) of all ECN-capable marked packets marked with a specific DS codepoint 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". The clearing of the result flag output from the meter, stops marking of ECN bit by the Marker. 15. References 15.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] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [6] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [7] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, Babiarz, et al. Expires April 27, 2006 [Page 33] Internet-Draft Document October 2005 September 2001. [8] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 15.2. Informative References [10] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003. [11] Alexander, C., "Real-time ECN Use Cases", draft-alexander-rtecn-use-cases-00 , July 2005. [12] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", draft-ietf-tsvwg-diffserv-service-classes-01 , July 2005. [13] Dudley, S., "Simulation of RT-ECN based Admission Control and Preemption", draft-dudley-tsvwg-rtecn-simulation-00 , July 2005. [14] Babiarz, J., Dudley, S., and K. Chan, "Discussion of Congestion Marking with RT-ECN", draft-babiarz-rtecn-marking-00 . [15] Alexander, C. and J. Babiarz, "RTP Payload Format for ECN Probing", draft-alexander-rtp-payload-for-ecn-probing-01 , July 2005. [16] Matsumoto, M. and T. Nishimura, "Mersenne Twister MT 19937", http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html http://en.wikipedia.org/wiki/Mersenne_twister, March 2004. [17] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", draft-floyd-ecn-alternates-01 , July 2005. [18] Alexander, C. and J. Rutledge, "A Congestion Status Precondition for the Session Initiation Protocol (SIP)", draft-alexander-congestion-status-preconditions-00 , July 2005. Babiarz, et al. Expires April 27, 2006 [Page 34] Internet-Draft Document October 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: Fax: Email: victor.firoiu@baesystems.com Babiarz, et al. Expires April 27, 2006 [Page 35] Internet-Draft Document October 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 April 27, 2006 [Page 36]