Network Working Group C. Alexander, Ed. Internet-Draft J. Babiarz Expires: January 12, 2006 J. Matthews Nortel July 11, 2005 Real-time ECN Use Cases draft-alexander-rtecn-use-cases-00.txt 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 January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes use cases for the mechanisms described in draft "Congestion Notification Process for Real-Time Traffic" and the RTP payload format defined in draft "RTP Payload Format for ECN Probing". Specifically, it describes admission control and preemption use cases. Alexander, et al. Expires January 12, 2006 [Page 1] Internet-Draft Real-time ECN Use Cases July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Admission Control . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Probing Mechanism . . . . . . . . . . . . . . . . . . . . 6 3.2 Delaying Session Establishment . . . . . . . . . . . . . . 6 3.3 Usage Examples . . . . . . . . . . . . . . . . . . . . . . 6 3.3.1 Unidirectional Probing without Cheater Detection . . . 7 3.3.2 Unidirectional Probing with Cheater Detection . . . . 9 3.3.3 Bidirectional Mechanisms . . . . . . . . . . . . . . . 11 4. Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1 Usage Example . . . . . . . . . . . . . . . . . . . . . . 12 4.2 Preemption Guidelines . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1 Normative References . . . . . . . . . . . . . . . . . . . 19 9.2 Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 21 Alexander, et al. Expires January 12, 2006 [Page 2] Internet-Draft Real-time ECN Use Cases July 2005 1. Introduction Converged networks that are configured to provide multi-services normally are engineered to provide the required quality of service using Diffserv technologies. Real-time inelastic traffic (e.g. voice) normally is configured to use Expedited Forwarding (EF) PHB to provide very low delay, loss and jitter transport. To stay within that engineered quality of service, and to ensure a quality of service level for that traffic, some type of admission control mechanism is necessary. Due to the sensitive nature of voice and other telephony applications (video conferencing, multi-media streaming), freely allowing these types of sessions onto a network where resources are limited can quickly lead to degradation of service that users may not tolerate. And in a packet based network, the degradation is not limited to the offending flows, which the provider may not tolerate. The Real-Time ECN process offers two levels of congestion indication. There is an intermediate congestion indication in addition to a maximum congestion indication. This adds flexibility to admission control decisions. The intermediate congestion indication essentially warns endpoint applications that network congestion is relatively high but that there is still some bandwidth available. Using this information, applications can possibly decide to filter out certain types of sessions for admission in favor of other types. Applications demanding a large amount of bandwidth like video conferencing might be denied, while less bandwidth-intensive voice sessions could be admitted. Whatever the admission control basis, Real-Time ECN enables some discernment in the decision making rather than wholesale denial of sessions. This document proposes an admission control solution based on "Congestion Notification Process for Real-Time Traffic" [1] and "RTP Payload Format for ECN Probing" [2]. The gist of the solution is that nodes at selected points in the network, where congestion is most likely to occur, measure traffic flow per service class and mark the ECN bits in the IP header based on observed traffic level(s). During session setup a probing mechanism is used between endpoints to verify traffic level (or congestion) along the path. The probing travels along the media path between the endpoints, where the endpoints are on either side of one or more bandwidth constrained links. At the links, ECN-capable nodes are provisioned with congestion thresholds based on a traffic type's real-time service class. The routers mark the ECN bits in the IP headers of the probe packets according to the routers' experienced level of congestion for the particular service class. As packets arrive, the ECN-capable endpoints recognize any ECN markings and make an admission control decision according to the indicated congestion level and session Alexander, et al. Expires January 12, 2006 [Page 3] Internet-Draft Real-time ECN Use Cases July 2005 precedence. This document also proposes a preemption solution based on [1] and [2]. This relies on endpoints monitoring the ECN value of incoming media packets, specifically for the second level of congestion. When present, the endpoint can initiate a preemption mechanism as dictated by local policy. Real-Time ECN does not introduce a significant amount of overhead to the network. Not every node in the network needs to be ECN-capable. Only those nodes located at congestion points need the capability. At the nodes, ECN metering and marking is quick. There is practically no real-time hit to the routing. An ECN node does not maintain flow state and does not add delay with any intricate policy decisions. Its impact on the network is very low. The remainder of this memo provides two high-level examples depicting unidirectional ECN-based probing for admission control, plus a section describing how the same unidirectional probing can be used twice to provide bidirectional probing. It also provides a single high-level example depicting preemption. While the examples provided are protocol-agnostic, general recommendations are provided as to how the payload format defined in [2] should be used in the context of admission control. No protocol-specific signaling is defined or suggested herein to show how to use the payload while admitting a new session. This document replaces a prior draft, "Admission Control Use Case for Real-time ECN" [5]. Alexander, et al. Expires January 12, 2006 [Page 4] Internet-Draft Real-time ECN Use Cases July 2005 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and indicate requirement levels for compliant implementations. Alexander, et al. Expires January 12, 2006 [Page 5] Internet-Draft Real-time ECN Use Cases July 2005 3. Admission Control Admission control can use a probing mechanism to determine whether there is available bandwidth for a session. The endpoints of a session perform this probing during session setup, having first delayed session establishment. Depending upon the results of the probing mechanism, the session will be either admitted or denied. This decision can be made within an endpoint, or by a session server. 3.1 Probing Mechanism The probing mechanism makes use of [1] and [2]. The mechanism is unidirectional, but bidirectional probing is possible using two unidirectional probes. In either case, probing is end-to-end. 3.2 Delaying Session Establishment Session establishment should be delayed during the admission control process, at a minimum to avoid indicating the new session to the users prematurely, before an admission decision has been made. For SIP, preconditions can accomplish this as described in "A Congestion Status Precondition for the Session Initiation Protocol (SIP)" [3]. 3.3 Usage Examples Two usage examples are provided. These cover use of the RTP payload format in [2] with unidirectional probing, both with and without detection of Cheaters along the media path. A third section describes how bidirectional probing is accomplished. The terminology used is defined in [2]. All examples presume that probing starts at a point during session setup when the Receiver endpoint addressing information is known by the Sender, and the dynamic payload type used for the packets carrying the payload has been determined. 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. All examples list the relevant field contents where necessary. In a real implementation, it is recommended that the payload be secured. In order to ensure there is no confusion between different versions of the referenced drafts, the following ECN bit definitions are used in the four examples: Alexander, et al. Expires January 12, 2006 [Page 6] Internet-Draft Real-time ECN Use Cases July 2005 00 Not ECN-capable 10 ECN-capable, with no congestion experienced 11 ECN-capable, with congestion experienced at the first level 01 ECN-capable, with congestion experienced at the second level 3.3.1 Unidirectional Probing without Cheater Detection A unidirectional probing mechanism without cheater detection is the simplest possible use of the payload format defined in [2]. The Version field MUST be set appropriately, i.e., for this memo, to zero. The remaining fields SHOULD be set to zero. If the session for which admission control is being performed is bidirectional, then two of these unidirectional probes can be used, one in each direction. (1) (3) +------+ +----------+ +------+ | | | | | | | EP A | ----> | Router A | ----> + EP B | (5) | | | | | | +------+ +----------+ +------+ (2) (4) Figure 1: Unidirectional Probing without Cheater Detection 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. IP Header: DSCP: ECN: 10 RTP Header: Payload Type: ECN Probe Payload: Version: 0000 ECN: 00 IRSN: 0000 0000 0000 0000 Reserved: 00 0000 0000 Alexander, et al. Expires January 12, 2006 [Page 7] Internet-Draft Real-time ECN Use Cases July 2005 2. Router A receives the Probe Packet, and applies to it the methods described in [1] for real-time inelastic traffic. 3. Router A re-marks the ECN field in the IP header of the Probe Packet as described in [1], then forwards the packet. IP Header: DSCP: ECN: RTP Header: Payload Type: ECN Probe Payload: Version: 0000 ECN: 00 IRSN: 0000 0000 0000 0000 Reserved: 00 0000 0000 4. EP B receives the Probe Packet. The ECN value, ReqECN, in the IP header indicates the highest level of congestion on the path towards EP B. IP Header: DSCP: ECN: RTP Header: Payload Type: ECN Probe Payload: Version: 0000 ECN: 00 IRSN: 0000 0000 0000 0000 Reserved: 00 0000 0000 5. EP B inspects the ECN value, ReqECN, in the IP header, then knows the highest level of congestion on the path towards EP B. Based on this, EP B can determine whether the session should be admitted. Alexander, et al. Expires January 12, 2006 [Page 8] Internet-Draft Real-time ECN Use Cases July 2005 3.3.2 Unidirectional Probing with Cheater Detection A unidirectional probing mechanism with cheater detection differs from the first example in two respects. First, the ECN field in the Probe Packet contains the ECN value set in the ECN field in the IP header. Second, the IRSN field contains the initial RTP sequence number selected randomly by EP A for the associated RTP media stream. This may be used by the endpoints for cheater detection after the real media exchange begins. Third, additional processing in EP B is necessary to determine if there are Cheaters present on the path towards EP B. In order to perform Cheater detection, more than one Probe Packet must be sent, each with different ECN values in the IP header, as described in [1]. As with the first example, if the session for which admission control is being performed is bidirectional, then two of these unidirectional probes can be used, one in each direction. (1) (3) +------+ +----------+ +------+ | | | | | | | EP A | ----> | Router A | ----> + EP B | (5) | | | | | | +------+ +----------+ +------+ (2) (4) Figure 5: Unidirectional Probing without Cheater Detection 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. At least three Probe Packets are sent. A random ordering of the three ECN value 01, 10, and 11 is chosen, and these values are used in sequential Probe Packets as the ECN value in the IP header and the ECN field in the ECN Probe Payload. Refer to [1] for additional details. At least three Probe Packets are needed so that three sequential packets are received by the Receiver in order to determine the actual marking from the routers along the network path. Alexander, et al. Expires January 12, 2006 [Page 9] Internet-Draft Real-time ECN Use Cases July 2005 IP Header: DSCP: ECN: <01, 10, or 11> RTP Header: Payload Type: ECN Probe Payload: Version: 0000 ECN: IRSN: Reserved: 00 0000 0000 2. Router A receives the Probe Packet, and applies to it the methods described in [1] for real-time inelastic traffic. 3. Router A re-marks the ECN field in the IP header of the Probe Packet as described in [1], then forwards the packet. IP Header: DSCP: ECN: RTP Header: Payload Type: ECN Probe Payload: Version: 0000 ECN: IRSN: Reserved: 00 0000 0000 4. EP B receives the Probe Packet. EP B tracks the ECN value, ReqECN, from the IP header, and the ECN value from the ECN Probe Payload until it receives at least three sequential Probe Packets. Alexander, et al. Expires January 12, 2006 [Page 10] Internet-Draft Real-time ECN Use Cases July 2005 IP Header: DSCP: ECN: RTP Header: Payload Type: ECN Probe Payload: Version: 0000 ECN: IRSN: Reserved: 00 0000 0000 5. Once EP B has received three sequential Probe Packets, it can follow the steps described in [1] to both detect if Cheaters are present on the path towards EP B, and to filter out the highest actual level of congestion on path towards EP B. The decision to admit is made based on whether Cheaters are present and the level of congestion indicated by the ECN markings. 3.3.3 Bidirectional Mechanisms As described in each of the examples, bidirectional probing can be accomplished by utilizing two unidirectional probes, one in each direction. As it is simply a combination of two unidirectional, it is not explicitly depicted here. Alexander, et al. Expires January 12, 2006 [Page 11] Internet-Draft Real-time ECN Use Cases July 2005 4. Preemption The Real-time ECN mechanism defined in [1] can be used to provide preemption capabilities. As with the unidirectional probe streams described in the context of admission control earlier, endpoints can similarly monitor the ECN value of RTP media packets and react accordingly to provide preemption. If the first or second threshold levels are exceeded, as indicated by the ECN value of the media packets, local policy may dictate preemption as a required action to keep bandwidth usage within engineered limits. 4.1 Usage Example 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 a local policy dictating that preemption occurs when the second 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 9: 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 ECN 10. Refer to [1] for additional details. IP Header: DSCP: ECN: 10 RTP Header: Payload Type: 2. Router A receives the RTP media packets, and applies to them the methods described in [1] for real-time inelastic traffic. Alexander, et al. Expires January 12, 2006 [Page 12] Internet-Draft Real-time ECN Use Cases July 2005 3. Router A re-marks the ECN field in the IP header of the RTP media packets as described in [1], then forwards the packet. For the purposes of this example, it is presumed that bandwidth exists such that Router A marks ECN 01 to indicate that the second level of congestion has been exceeded. IP Header: DSCP: ECN: 01 RTP Header: Payload Type: 4. EP B receives the RTP media packets. EP B monitors the ECN value of RTP media packets, and upon receiving packets marked with ECN 01 to indicate that the second level of congestion has been exceeded somewhere along the path in the network, it follows local policy to initiate preemption. IP Header: DSCP: ECN: 01 RTP Header: Payload Type: 5. The specific actions taken to carry out preemption may vary, but some general guidelines will be specified below. 4.2 Preemption Guidelines The specific actions taken to carry out preemption may vary, but some general guidelines can be specified. Because the marking mechanism described in [1] functions on all packets with the appropriate DSCP code point, versus only on packets for an individual media flow, there needs to be a mechanism in place that can control the rate and number of sessions that are preempted. In other words, allowing preemption to be performed immediately and directly within an endpoint that detects a preempting congestion level in the network would likely result in many more sessions being preempted than is necessary to bring bandwidth levels back under the preempting congestion level. This is due to the likelihood that more than one endpoint will receive indication of the preemption congestion level via ECN markings on their respective RTP media packets. It is Alexander, et al. Expires January 12, 2006 [Page 13] Internet-Draft Real-time ECN Use Cases July 2005 envisioned that when an endpoint detects this preempting congestion level, it will send an indication to a preempting device which will perform the actual preemption actions. In SIP, this indication would take the form of an event package, and the preempting device would be a back-to-back user agent (B2BUA). Given this description, two things need to be considered. First, the indications sent from the endpoints when the preempting congestion level is detected need to be throttled among all the endpoints that detect the preempting congtestion level. This will reduce the number of indications sent at roughly the same time, and will allow the preempting device to more easily manage their arrival. To accomplish this, local policy could specify that endpoints would send these indications only after a delay, selected randomly by the individual endpoints from a range of a zero to ten seconds. Second, to further ensure that no more preemptions occur than are necessary, the preempting device needs to pace the preemption rate, allowing a preemption and the resulting session termination time to propagate through the network. This can be accomplished by limiting the rate of preemption to no less than one preemption every 500 milliseconds. Alexander, et al. Expires January 12, 2006 [Page 14] Internet-Draft Real-time ECN Use Cases July 2005 5. Security Considerations Refer to [1] and [2] for security-related considerations. Alexander, et al. Expires January 12, 2006 [Page 15] Internet-Draft Real-time ECN Use Cases July 2005 6. IANA Considerations There are no IANA considerations. Alexander, et al. Expires January 12, 2006 [Page 16] Internet-Draft Real-time ECN Use Cases July 2005 7. IAB Considerations There are no IAB considerations. Alexander, et al. Expires January 12, 2006 [Page 17] Internet-Draft Real-time ECN Use Cases July 2005 8. Acknowledgements The authors acknowledge a great many inputs, including the following: John Rutledge, Marvin Krym, Stephen Dudley, and Kwok-Ho Chan. Alexander, et al. Expires January 12, 2006 [Page 18] Internet-Draft Real-time ECN Use Cases July 2005 9. References 9.1 Normative References [1] Babiarz, J., Chan, K., and V. Firoiu, "Congestion Notification Process for Real-Time Traffic", Internet-Draft draft-babiarz-tsvwg-rtecn-04.txt (Work in Progress), July 2005. [2] Alexander, C., Ed. and J. Babiarz, "RTP Payload Format for ECN Probing", Internet-Draft draft-alexander-rtp-payload-for-ecn-probing-01.txt (Work in Progress), July 2005. [3] Alexander, C., Ed. and J. Rutledge, "A Congestion Status Precondition for the Session Initiation Protocol (SIP)", Internet-Draft draft-alexander-congestion-status-preconditions-00.txt (Work in Progress), July 2005. 9.2 Informative References [4] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [5] Alexander, C., Ed., Babiarz, J., and J. Matthews, "Admission Control Use Case for Real-time ECN", Internet-Draft draft-alexander-rtecn-admission-control-use-case-00.txt (Work in Progress), February 2005. Authors' Addresses Corey W. Alexander (editor) Nortel MS 08704A30 2370 Performance Drive Richardson, TX 75082 USA Phone: +1 972 684-8320 Email: coreya@nortel.com Alexander, et al. Expires January 12, 2006 [Page 19] Internet-Draft Real-time ECN Use Cases July 2005 Jozef Z. Babiarz Nortel MS 04331C04 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763-6098 Email: babiarz@nortel.com Jeremy P. Matthews Nortel MS 08704A30 2370 Performance Drive Richardson, TX 75082 USA Phone: +1 972 684-0336 Email: jeremym@nortel.com Alexander, et al. Expires January 12, 2006 [Page 20] Internet-Draft Real-time ECN Use Cases July 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. Alexander, et al. Expires January 12, 2006 [Page 21]