Session Initiation Proposal C. Alexander, Ed. Investigation J. Rutledge Internet-Draft Nortel Expires: January 12, 2006 July 11, 2005 A Congestion Status Precondition for the Session Initiation Protocol (SIP) draft-alexander-congestion-status-preconditions-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 defines the Congestion Status precondition for SIP, utilizing the framework defined in RFC 3312 and updated in RFC 4032. The Congestion Status precondition requires that the participant verify that congestion thresholds along the network path for the session media have not been exceeded before continuing with session establishment or modification. This verification is performed via an RTP probe utilizing draft "Congestion Notification Process for Real- Alexander & Rutledge Expires January 12, 2006 [Page 1]
Internet-Draft Congestion Status Precondition July 2005 Time Traffic" and draft "RTP Payload Format for ECN Probing". Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Congestion Status Precondition Definition . . . . . . . . . . 6 4.1 Precondition Type Tag . . . . . . . . . . . . . . . . . . 6 4.2 Additional Data Type . . . . . . . . . . . . . . . . . . . 6 4.3 Payload Type . . . . . . . . . . . . . . . . . . . . . . . 6 4.4 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . 7 4.5 Status Type . . . . . . . . . . . . . . . . . . . . . . . 7 4.6 Precondition Strength . . . . . . . . . . . . . . . . . . 7 4.7 Direction Tag . . . . . . . . . . . . . . . . . . . . . . 7 4.8 Suspending and Resuming Session Establishment . . . . . . 7 4.9 Cessation of ECN Probing . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Normative References . . . . . . . . . . . . . . . . . . . 16 8.2 Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Alexander & Rutledge Expires January 12, 2006 [Page 2]
Internet-Draft Congestion Status Precondition July 2005 1. Introduction RFC 3312 [2], updated by RFC 4032 [3], defines the basic concept of preconditions, and a framework through which new preconditions can be defined. This document defines a new Congestion Status precondition, "cong", that provides an admission control mechanism based on whether there is congestion in the network. An entity can use the Congestion Status precondition to delay session establishment or modification until a determination can be made that congestion thresholds along the network path between the offerer and answerer have not been exceeded. When a mandatory Congestion Status precondition is received in an offer, session establishment or modification MUST be delayed until the Congestion Status precondition has been met, i.e., the Explicit Congestion Notification (ECN) value in ECN probe packets, as defined in "RTP Payload Format for ECN Probing" [6], explicitly indicates that congestion thresholds along the network path for the new session media have not been exceeded. The Congestion Status precondition relies on "Congestion Notification Process for Real-Time Traffic" [5] to be implemented within select routers in the network, specifically those routers at which congestion is likely to occur. It also relies on [6] and "Real-time ECN Use Cases" [7] for the end-systems to probe for congestion. The probe streams received at each end-system are analyzed, and the ECN markings are used to either pass or fail the preconditions. Alexander & Rutledge Expires January 12, 2006 [Page 3]
Internet-Draft Congestion Status Precondition 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 RFC2119 [15] and indicate requirement levels for compliant implementations. Alexander & Rutledge Expires January 12, 2006 [Page 4]
Internet-Draft Congestion Status Precondition July 2005 3. Definitions The following terms are used in this document, many adopted directly from RFC 3264 [4]: Agent: An agent is the protocol implementation involved in the offer/ answer exchange. There are two agents involved in an offer/answer exchange. Answer: An SDP message sent by an answerer in response to an offer received from an offerer. Answerer: An agent which receives a session description from another agent describing aspects of desired media communication, and then responds to that with its own session description. ECN Probe Stream: [7] describes a stream of RTP packets whose payload consists of that described in [6]. The ECN probe stream is used to detect congestion in the network via the mechanisms described in [5]. Media Stream: As defined in RFC 2326 [11], a media stream is a single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. In SDP, a media stream is described by an "m=" line and its associated attributes. Offer: An SDP message sent by an offerer. Offerer: An agent which generates a session description in order to create or modify a session. Alexander & Rutledge Expires January 12, 2006 [Page 5]
Internet-Draft Congestion Status Precondition July 2005 4. Congestion Status Precondition Definition The Congestion Status precondition type is represented by "cong". 4.1 Precondition Type Tag The precondition-type tag for the Congestion Status precondition is "cong". The resulting precondition-type grammar refined from that defined in [2] is: precondition-type = "cong" | "qos" | token 4.2 Additional Data Type A new type, additional-data, is defined for the desired-status attribute. It is generically specified as follows: additional-data = "" This tag allows preconditions to extend the desired-status attribute line with data specific to their function and behavior, while keeping the tag itself generic to any precondition that requires its use. 4.3 Payload Type [6] specifies a dynamic payload type for the ECN probe packets in an ECN probe stream. The dynamic payload type values are defined in RFC 3551 [12]. This will be specified on the desired-status line of the Congestion Status precondition as a value within the additional-data type. For the specification of this value, a new type, payload-type, is defined for use with this precondition. This also necessitates the modification of the additional-data type defined earlier. The payload-type type is REQUIRED for the Congestion Status precondition. additional-data = "" | payload-type payload-type = 96-127 The payload-type value specified in the initial INVITE offer specifying the Congestion Status precondition indicates the payload type the offerer and/or answerer will use to identify ECN probe packets in an ECN probe stream. It SHOULD be used as the payload- type value in any ECN probe flows associated with the corresponding media type. If the corresponding answer indicates a different payload-type value than that in the offer, then the payload-type value in the offer indicates the payload-type value the offerer expects to see for ECN probe packets it receives, and the payload- type value in the answer indicates the payload-type value the Alexander & Rutledge Expires January 12, 2006 [Page 6]
Internet-Draft Congestion Status Precondition July 2005 answerer expects to see for ECN probe packets it receives. 4.4 SDP Parameters Based on the new precondition-type value, and the new additional-data and payload-type types, the SDP parameters specified in [2] are modified as follows: desired-status = "a=des" precondition-type SP strength-tag SP status-type SP direction-tag SP additional-data precondition-type = "cong" | "qos" | token additional-data = "" | payload-type payload-type = 96-127 4.5 Status Type The Congestion Status precondition MUST support the end-to-end status type as defined in [2]. An implementation MAY support the segmented status types. 4.6 Precondition Strength The Congestion Status precondition is defined as a mandatory precondition. Note that use of a mandatory precondition requires the presence of a Require header with the option tag "precondition". 4.7 Direction Tag As described in [2], the direction tags represent the point of view of the entity generating the SDP description. For example, in an offer, "send" is the direction offerer->answerer, while in an answer, "send" is the direction answerer->offerer. 4.8 Suspending and Resuming Session Establishment When the preconditions requirement is accepted by the answerer, session setup is suspended until the preconditions are met or fail. During this suspension of session setup, neither the offerer or answerer provide any type of ringing. The Congestion Status precondition allows one or both of the offerer and answerer to verify during session setup, before ringing begins, that there is adequate bandwidth available in the network for the associated session media. It utilizes the probe payload defined in [6], and a probing mechanism such as that desribed in [7], to probe for congestion in the network. If the probe indicates that the Alexander & Rutledge Expires January 12, 2006 [Page 7]
Internet-Draft Congestion Status Precondition July 2005 congestion thresholds along the network path have not been exceeded, the preconditions are met. Otherwise, they are failed. In the example SDPs that follow, note that there is no rtpmap attribute in the SDP associated with ECN probing. This is because the probing mechanism and payload format are implicitly linked to the Congestion Status precondition, as can be seen by the payload-type value associated with the desired-status attribute of this precondition. Only the rtpmap attribute for the session media is explicitly described in the SDP. [6] also describes that the probe flow can optionally mimic various properties of the session media, specifically the send rate. This is determined implicitly, as well, based on the preferred media specified in the SDP. Offerer Answerer | | |------------ (1) INVITE SDP1 -------------->| | | |<----- (2) 183 Session Progress SDP2 -------| | | |<========= (3) RTP Probe Flow ==============| | | |========== (4) RTP Probe Flow =============>| | | |--------------- (5) PRACK ----------------->| | | |<---------- (6) 200 OK (PRACK) -------------| | | |------------ (7) UPDATE SDP3 -------------->| | | |<------- (8) 200 OK (UPDATE) SDP4 ----------| | | |<------------ (9) 180 Ringing --------------| | | |---------------- (10) PRACK --------------->| | | |<----------- (11) 200 OK (PRACK) -----------| | | | | | | |<---------- (12) 200 OK (INVITE) -----------| | | |----------------- (13) ACK ---------------->| | | Alexander & Rutledge Expires January 12, 2006 [Page 8]
Internet-Draft Congestion Status Precondition July 2005 In SDP1, the offerer specifies a mandatory end-to-end Congestion Status precondition with "sendrecv" as the desired status. "sendrecv" indicates that congestion must be checked in both the send and receive direction, from the point of view of the offerer. The offerer's local status table is: Direction | Current | Desired Strength | Confirm -----------+-----------+------------------+--------- send | no | mandatory | no recv | no | mandatory | no The SDP content for SDP1 is: m=audio 50002 RTP/AVP 0 8 18 c=IN IP4 192.168.1.200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=curr:cong e2e none a=des:conn mandatory e2e sendrecv 104 SDP1 carries to the answerer the IP address and port number for the offerer. Note that the value 104 is specified on the desired-status line as the payload-type value that the offerer expects to see for ECN probe packets. Once the offerer sends SDP1, it MUST begin listening for probe packets on the IP address and port number associated with the Congestion Status precondition in SDP1. In SDP2, the answerer responds indicating that it wants the offerer to inform it about the congestion status in the network from the answerer to the offerer. The answerer's local status table is: Direction | Current | Desired Strength | Confirm -----------+-----------+------------------+--------- send | no | mandatory | no recv | no | mandatory | no The answerer indicates that it wants the offerer to inform it about congestion from the answerer to the offerer by using the confirm- status attribute. The SDP content for SDP2 is: Alexander & Rutledge Expires January 12, 2006 [Page 9]
Internet-Draft Congestion Status Precondition July 2005 m=audio 51286 RTP/AVP 0 8 18 c=IN IP4 192.168.1.235 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=curr:cong e2e none a=des:conn mandatory e2e sendrecv 104 a=conf:cong e2e send SDP2 carries to the offerer the IP address and port number for the answerer. Note that the value 104 is specified on the desired-status line, unchanged from SDP1, as the payload-type value the answerer expects to see for ECN probe packets. Once the answerer sends SDP2, it MUST begin listening for probe packets on the IP address and port number associated with the Congestion Status precondition in SDP2. It MUST also begin generating a stream of probe packets to the IP address and port number for the offerer that it determined from SDP1. The probe packets MUST adhere to the format defined in [6], optionally padded to a size corresponding to the codec to be used for session media. When the offerer receives SDP2, it updates its local status table to reflect the confirm-status attribute as follows: Direction | Current | Desired Strength | Confirm -----------+-----------+------------------+--------- send | no | mandatory | no recv | no | mandatory | yes The offerer MUST also begin generating a stream of probe packets to the IP address and port number for the answerer that it determined from SDP2. The probe packets MUST adhere to the format defined in [6], optionally padded to a size corresponding to the codec to be used for session media. Both the offerer and answerer, upon receiving the stream of probe packets, determines whether congestion is present in the network by applying [5]. As the offerer receives the stream of probe packets from the answerer indicating that congestion thresholds along the network path have not been exceeded, the offerer's local status table is updated to: Direction | Current | Desired Strength | Confirm -----------+-----------+------------------+--------- send | no | mandatory | no recv | yes | mandatory | yes Alexander & Rutledge Expires January 12, 2006 [Page 10]
Internet-Draft Congestion Status Precondition July 2005 As the answerer receives the stream of probe packets from the offerer indicating that congestion thresholds along the network path have not been exceeded, the answerer's local status table is updated to: Direction | Current | Desired Strength | Confirm -----------+-----------+------------------+--------- send | no | mandatory | no recv | yes | mandatory | no The answerer now waits on the offerer to confirm the congestion status in the network from the answerer to the offerer. The offerer generates and sends SDP3 in an UPDATE request as follows: m=audio 50002 RTP/AVP 0 8 18 c=IN IP4 192.168.1.200 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=curr:cong e2e recv a=des:conn mandatory e2e sendrecv 104 The answerer uses SDP3 to update its local status table as follows: Direction | Current | Desired Strength | Confirm -----------+-----------+------------------+--------- send | yes | mandatory | no recv | yes | mandatory | no Should the UPDATE request from the offerer arrive at the answerer before the stream of probe packets from the offerer, the answerer sends a 500 Server Internal Error response with the Retry-After header indicating the request should be attempted again in 1-3 seconds. At this point, the Congestion Status precondition has been successfully met. The answerer responds with SDP4 as follows: m=audio 51286 RTP/AVP 0 8 18 c=IN IP4 192.168.1.235 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=curr:cong e2e sendrecv a=des:conn mandatory e2e sendrecv 104 As the Congestion Status precondition has now been met, ringing begins with the answerer sending a 180 Ringing response. Alexander & Rutledge Expires January 12, 2006 [Page 11]
Internet-Draft Congestion Status Precondition July 2005 4.9 Cessation of ECN Probing The ECN probe stream(s) generated as a result of the Congestion Status precondition MAY be terminated by the answer after receiving an UPDATE request from the offerer containing SDP3 and/or by the offerer after receiving either a 200 UPDATE response from the answerer containing SDP4, or a 580 Precondition Failure final response. Alternatively, the ECN probe stream(s) MAY continue to be generated after preconditions are met successfully. In this case, the ECN probe stream(s) started after the 183 Session Progress message was sent/received MAY continue to be sent, until either session establishment is aborted via a CANCEL from the offerer or a final response from the answerer, or the session is established. The agents MUST continue to monitor the ECN probe stream(s) for network congestion. If detected, local policy will be used to dictate the action to be taken. The typical action upon detection of congestion is to terminate the session setup with a CANCEL message if congestion is detected by the offerer, or a 503 Service Unavailable final response if detected by the answerer. If the session is established, both the offerer and/or answerer SHOULD stop sending their respective ECN probe stream(s), and immediately begin sending session media. The answerer MAY do this as soon as it sends the 200 OK indicating that the session is established. The offerer MAY do this as soon as it receives the 200 OK indicating that the session was established. Alexander & Rutledge Expires January 12, 2006 [Page 12]
Internet-Draft Congestion Status Precondition July 2005 5. Security Considerations [2] and [3] describe security considerations for preconditions. In addition, security considerations specific to the Congestion Status precondition are described here. [5] and [6] describe security considerations for the Real-time ECN mechanism and the associated RTP payload format. They consider the possibility of devices attempting to change the level of congestion reported by the ECN probe stream, and describe mechanisms to detect such changes. Similar to the recommendations in [5] and [6], the RTP packets in the ECN probe stream(s) SHOULD be secured, and the SIP/SDP messaging SHOULD also be secured with S/MIME [8] or TLS [9], [10]. This precondition utilizes an RTP stream - the ECN probe stream - to detect congestion during session setup. A denial of service attack is possible, but harbors little more risk than for any other RTP media stream. The ECN probe stream is only generated during session setup, prior to answer, so the agents involved only listen and expect such a stream during this time. [5] discusses the possibility of a denial of service attack in which false congestion is reported. Alexander & Rutledge Expires January 12, 2006 [Page 13]
Internet-Draft Congestion Status Precondition July 2005 6. IANA Considerations This document extends the desired-status SDP attribute defined in [2] with two new types, additional-data and payload-type. These are described in Section 4.2 and Section 4.3. This document defines the following precondition, with the request that it be registered by the IANA: Precondition-Type Reference Description ----------------- ------------- ------------------------------ cong This document Congestion Status precondition Alexander & Rutledge Expires January 12, 2006 [Page 14]
Internet-Draft Congestion Status Precondition July 2005 7. Acknowledgements The authors acknowledge a great many inputs, including the following: Francois Audet, Jeremy Matthews, and Stephen Dudley. Alexander & Rutledge Expires January 12, 2006 [Page 15]
Internet-Draft Congestion Status Precondition July 2005 8. References 8.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Camarillo, G., Marshall, B., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, June 2002. [3] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005. [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [5] 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. [6] 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. 8.2 Informative References [7] Alexander, C., Ed., Babiarz, J., and J. Matthews, "Real-time ECN Use Cases", Internet-Draft draft-alexander-rtecn-use-cases-00.txt (Work in Progress), July 2005. [8] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004. [9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [10] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [11] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. Alexander & Rutledge Expires January 12, 2006 [Page 16]
Internet-Draft Congestion Status Precondition July 2005 [12] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. [13] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002. [14] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002. [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Authors' Addresses Corey W. Alexander (editor) Nortel MS 08704A30 2370 Performance Drive Richardson, Texas 75082 US Phone: +1 972 684-8320 Email: coreya@nortel.com John Rutledge Nortel MS 08704A30 2370 Performance Drive Richardson, Texas 75082 US Phone: +1 972 684-7528 Email: jrutledg@nortel.com Alexander & Rutledge Expires January 12, 2006 [Page 17]
Internet-Draft Congestion Status Precondition 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 & Rutledge Expires January 12, 2006 [Page 18]