MMUSIC Working Group James Polk Internet-Draft Subha Dhesikan Expires: April 17th, 2006 Cisco Systems Gonzalo Camarillo Ericcson Oct 17th, 2005 An Identification of QoS Mechanism for Preconditions draft-polk-mmusic-qos-mechanism-identification-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 April 17th, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Session Initiation Protocol (SIP) defines a means for delaying application layer session set-up signaling from progressing until a quality of service (QoS) guarantee is established between user agents. This is specified in RFC 3312. The examples within that document show the use of the Resource Reservation Protocol (RSVP) for this service. Now that more than one quality of service mechanism exists, a means of negotiation is necessary for interoperability between these user agents. This document will update RFC 3312 by providing a means of identifying which QoS mechanism is desired during session establishment. Polk, et al Expires April 17th, 2005 [Page 1] Internet-Draft Preconditions QoS Mechanism Oct 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Conventions used in this document . . . . . . . . . . . . 3 2. E2E Signaling as shown in 3312 . . . . . . . . . . . . . . . 3 2.1 Problems Exist with Current Mechanisms . . . . . . . . . 5 3. Requirements for QoS indication . . . . . . . . . . . . . . . 6 4. Extending SIP and SDP to Solve this Interoperability Problem 6 4.1 Option-Tags . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 New Attribute Line . . . . . . . . . . . . . . . . . . . . 7 4.3 Error Responses . . . . . . . . . . . . . . . . . . . . . . 8 5. Message Flows for Various qos-selection Scenarios . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1 Normative References . . . . . . . . . . . . . . . . . . 15 9.2 Informative References . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . 16 1. Introduction The Session Initiation Protocol (SIP) defines a means for delaying session set-up signaling from completing until a quality of service (QoS) guarantee is established between user agents. This is specified in RFC 3312 [RFC3312]. Preconditions can be used for many reasons, including providing a level of service between user agents prior to the called user agent (UA) phone from ringing. A limitation within that document is that the QoS mechanism to be used between user agents to accomplish this level of service is not discussed; but that a prior agreement between UAs is necessary to ensure each utilizes the same mechanism to achieve interoperability. At the time of that document, there was one reservation protocol in use: Resource Reservation Protocol (RSVP) initially defined in [RFC2205]. The examples within RFC 3312 were written with RSVP in mind, but the RFC did not mandate RSVP in any way to achieve preconditions. Now that another reservation protocol has been developed, an indication of which QoS protocol intended to be used is necessary, specifically with end-to-end QoS Preconditions. This new reservation protocol is NSIS (Next Steps in Signaling), defined in at least 3 documents: [ID-GIMPS], [RFC4080] and [ID-NSLP]. This document will update RFC 3312 by extending SIP signaling to indicate a qos-mechanism is required as part of the precondition for a session, and SDP [RFC2327] by providing an indication of which QoS mechanism is desired during session establishment. Additionally, if Polk, et al Expires April 17th, 2005 [Page 2] Internet-Draft Preconditions QoS Mechanism Oct 2005 more than one qos-mechanism is offered by the offerer, the list of qos-mechanisms is given in preferential order. IANA registrations will be in this document for the SIP and SDP indications. 1.1 Conventions used in this document 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 [RFC2119]. 2. E2E Signaling as shown in 3312 Preconditions can be on an end-to-end basis or on a segmented basis. In the case of a segmented basis, the UAS will not ever see which QoS mechanism or protocol the UAC chose to use, and the UAC will not ever see which QoS mechanism or protocol the UAS chose to use. Thus, two different mechanisms can be used and no interoperability issues will exist. However, for end-to-end signaling of Preconditions, the QoS mechanism will have to be understood by the other UA, even if one direction uses one QoS mechanism and the reverse direction uses another mechanism. In this case, and in the more traditional case of only one mechanism being used for QoS Preconditions, there must be a means for indicating which is supported by the endsystems. Looking at the existing end-to-end signaling model from [RFC3312], the following basic message flow is shown: Alice Bob | | |-------------(1) INVITE SDP1--------------->| | | |<------(2) 183 Session Progress SDP2--------| | *** *** | |--*R*-----------(3) PRACK-------------*R*-->| | *E* *E* | |<-*S*-------(4) 200 OK (PRACK)--------*S*---| | *E* *E* | | *R* *R* | | *V* *V* | | *A* *A* | | *T* *T* | | *I* *I* | | *O* *O* | | *N* *N* | | *** *** | | *** | Polk, et al Expires April 17th, 2005 [Page 3] Internet-Draft Preconditions QoS Mechanism Oct 2005 | *** | |-------------(5) UPDATE SDP3--------------->| | | |<--------(6) 200 OK (UPDATE) SDP4-----------| | | |<-------------(7) 180 Ringing---------------| | | |-----------------(8) PRACK----------------->| | | |<------------(9) 200 OK (PRACK)-------------| | | |<-----------(10) 200 OK (INVITE)------------| | | |------------------(11) ACK----------------->| | | | | Figure 1: Basic e2e session establishment using preconditions Only the first 6 messages are pertinent to this discussion, as we are focusing on QoS interoperability and how this can be achieved by SIP. From the flow, Message [M1] is an INVITE from Alice containing SDP which requests preconditions, but does not clarify which form, just that it is "qos" preconditions, that is be e2e, and that it is mandatory before Bob is alerted to the call set-up. Message [M1] could look like this: INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP pc33.atlanta.example.com:5060 ;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob From: Alice ;tag=9fxced76sl Allow: INVITE, CANCEL, ACK, BYE, PRACK, UPDATE, OPTIONS Call-ID: 3848276298220188511 CSeq: 31862 INVITE Requires: 100rel, preconditions Contact: Content-Type: application/sdp Content-Length: ... v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com c=IN IP4 10.1.3.33 t=0 0 m=audio 20000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv The last two lines of the SDP above indicate preconditions are Polk, et al Expires April 17th, 2005 [Page 4] Internet-Draft Preconditions QoS Mechanism Oct 2005 desired, and that they are mandatory according to Alice's UA on an end-to-end basis. Notice in this SIP message, there is no indication of which type of QoS protocol is expected. [RFC3312] states each UA will need to have decided upon that in a way outside that specification. We will show soon how that can be a problem. Bob's UA receives this INVITE message and if his UA agrees with all that is in the offer, it might create a 183 (Session Progressing) message like this [M2] below: SIP/2.0 183 Session Progress Via: SIP/2.0/TCP swc50.atlanta.example.com:5060 ;branch=z9hG4bK74bf9 ;received=10.1.3.33 To: Bob ;tag=8321234356 From: Alice ;tag=9fxced76sl Allow: INVITE, CANCEL, ACK, BYE, PRACK, UPDATE, OPTIONS Call-ID: 3848276298220188511 CSeq: 31862 INVITE RSeq: 813520 Contact: Content-Type: application/sdp Content-Length: ... v=0 o=bob 2890844527 2890844527 IN IP4 biloxi.example.com c=IN IP4 192.168.10.1 t=0 0 m=audio 30000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv a=conf:qos e2e recv The next section will briefly discuss what problems can arise at this stage in the message flow if the two endpoints do not understand each other's preferences and capabilities. 2.1 Problems Exist with Current Mechanisms If Bob supports RSVP, his UA will initiate RSVP Path message towards Alice. If Alice only supported NSIS then her UA may not receive or understand the RSVP Path message and therefore her UA will not know what response to provide. Instead her UA may initiate the NSIS Query message or the NSIS receive message which Bob's UA will not understand. So, the UA's not receiving a response for the message sent will fail the session after some time interval. This causes a large post-dial delay that can be avoided by the mechanisms described in this draft. Polk, et al Expires April 17th, 2005 [Page 5] Internet-Draft Preconditions QoS Mechanism Oct 2005 Alice Router1 Router2 Bob | | | PATH | | | PATH |<---------+ | PATH |<---------+ | |<---------+ | | | | | | | QUERY | | | +--------->| QUERY | | | +--------->| QUERY | Figure 2: Basic QoS Mechanism Interoperability Problem This problem occurs even if one or both UA supported multiple QoS mechanisms because the current mechanisms do not allow the UA to select a common QoS mechanism to use between them. For example let us have Bob support RSVP and NSIS whereas Alice only supports NSIS. If Bob initiated RSVP, the session will fail as mentioned above. With the mechanisms described in this draft, such problems can be avoided and Alice and Bob can negotiate to use RSVP as Alice only supported RSVP. 3. Requirements for QoS Indication Here are the requirements to solve the above scenarios: Req#1 - An offerer MUST be able to indicate which qos mechanism it supports to ensure the answerer knows which is intended. Req#2 - An answerer MUST be able to respond with an indication it does not support any qos mechanisms. Req#3 - A means of listing however many qos mechanisms the offerer supports MUST be possible. Req#4 - A means of listing a preferential order of qos mechanisms the offerer supports MUST be possible. Req#5 - The answerer SHOULD choose the preferred qos mechanism of the answerer. Req#6 - The offerer MAY choose to list a subset of the qos- mechanisms it supports. 4. Extending SIP and SDP to Solve this Interoperability Problem 4.1 Option-Tags Option-tags in SIP are an indication of an extension to SIP [RFC3261]. Option-tags appear in the Requires, Supported and Unsupported headers indicating to the receiving UA that another UA Polk, et al Expires April 17th, 2005 [Page 6] Internet-Draft Preconditions QoS Mechanism Oct 2005 either requires its usage, supports the extension or does not support the extension. The following new option-tag is defined in this document: qos-selection This Option-Tag indicates there will be a specific qos mechanism(s) listed for qos preconditions within this transaction. The list of one or more mechanisms will be in an SDP attribute line. This an example of the Requires with this option-tag: Requires: qos-selection As [RFC3261] states, this can be its own Requires header line, or it can be combined with other option-tags separated by a comma, ','. For example, this could be an example of an appropriate Requires header involving qos preconditions: Requires: rel100, preconditions, qos-selection This option-tag has the following rules: - "qos-selection" MUST be used in a Requires header in a Request message if the preconditions are mandatory. - "qos-selection" SHOULD be used in a Supported header in a Request message if the preconditions are optional, and MAY be in a Requires header. - "qos-selection" MUST be in a Unsupported header in a Response message if the recipient of the original Request (having it in a Requires header) does not understand the extension. 4.2 New Attribute Line Within SDP [RFC2327], attribute lines located above all M lines are session attributes associated with all the media of that session unless overridden an attribute of the same name in the media description. This new attribute media level attribute within SDP. We define the following media level SDP attribute: qos-mechanism = "a=qos-mechanism:" SP qos-mechanism-type SP direction-tag qos-mechanism-type = "rsvp" | "nsis" | token direction-tag = ("none" | "send" | "recv" | "sendrecv") If an endsystem offers both RSVP and NSIS, and wants qos in both directions, the new attribute line would look as follows: a=qos-mechanism: rsvp nsis sendrecv Polk, et al Expires April 17th, 2005 [Page 7] Internet-Draft Preconditions QoS Mechanism Oct 2005 Although the above line looks similar to the M line listing a series of codecs supported in an offer, we define here an intended order of preference by the offerer in which the first qos mechanism listed is preferred by the offerer, and if that qos mechanism is supported by the answerer, it SHOULD be chosen by the answerer. For example, if there is a qos-mechanism line such as this: a=qos-mechanism: rsvp nsis foo bar sendrecv and the answerer supports rsvp, rsvp SHOULD be what is chosen for that session, even if the answerer would normally prefer any one of the other qos-mechanisms listed if they were the offerer. If the answerer in this example does not support rsvp, the next preferred qos-mechanism is nsis, with the same rule of 'SHOULD chose this mechanism if supported by the answerer'. If an offer has a Requires header indicating "qos-selection", the offerer MUST include this new "qos-mechanism" attribute line where appropriate in SDP, including at least one qos value it supports. If, based on local policy, prefers one qos-mechanism over another, it is RECOMMENDED the offerer understand the preferential order capability this document defines, and list whichever one it prefers first. Examples of usage are in section 5 of this document, including what occurs when there is a lack of support for the mechanisms in an offer, and when there are interoperability problems. 4.3 Error Responses A SIP element that is properly processing a SIP Request with a Requires header with a value of qos-selection and the entity does not support that extension, the entity MUST respond with a 420 (Bad Extension) and list this option tag in an Unsupported Header in the 420. If the SIP entity does support the extension qos-selection, yet does not support any qos mechanism(s) listed in the offer (SDP), the proper response is a 488 (Not Acceptable Here) with an SDP indicating which qos mechanisms the UAS does support. 5. Message Flows for Various qos-selection Scenarios Here are some simple message flows that indicate the solution given in this document. All examples lack some necessary to normal operation, but unneeded headers and lines within each message for this discussion, for brevity. Polk, et al Expires April 17th, 2005 [Page 8] Internet-Draft Preconditions QoS Mechanism Oct 2005 5.1 Offer Many - Accept One Example Alice INVITEs with multiple qos-mechanisms and Bob accepts one of Them. Alice Bob | INVITE (qos-selection) | |------------------------->| | | | 183 Session Progress | |<-------------------------| | | | PRACK | |------------------------->| | 200 OK | |<-------------------------| Figure 4. INVITE Bob@ SIP/2.0 To: Bob From: Alice Requires: preconditions, qos-selection m=audio a=qos-mechanism: rsvp nsis sendrecv a=curr:qos e2e none a=des:qos mandatory e2e sendrecv SIP/2.0 183 Session Progress To: Bob From: Alice Supported: preconditions, qos-selection m=audio a=qos-mechanism: rsvp sendrecv a=curr:qos e2e none a=des:qos mandatory e2e sendrecv Alice's INVITE includes a list of qos-mechanisms that her UA wishes to use. They are arranged by preference. If Bob supports any one of the listed mechanisms then Bob accepts the INVITE by sending a 183 (Session Progress) message. It is recommended that Bob select the earliest mechanism in the list that his UA supports. 5.2 Offer One - Accept None Example Bob does not support the qos-mechanism listed by Alice in her INVITE. Polk, et al Expires April 17th, 2005 [Page 9] Internet-Draft Preconditions QoS Mechanism Oct 2005 Alice sends an INVITE message with a qos-mechanism Bob does not support. Bob's response is a 488 (Not Acceptable Here) with an attribute line indicating which qos-mechanism(s) he does support. Alice Bob | INVITE (qos-selection) | |------------------------->| | | | 488 Not Acceptable Here | |<-------------------------| | | | ACK | |------------------------->| | | Figure 5. INVITE Bob@ SIP/2.0 To: Bob From: Alice Requires: preconditions, qos-selection m=audio a=qos-mechanism: rsvp sendrecv a=curr:qos e2e none a=des:qos mandatory e2e sendrecv SIP/2.0 488 Not Acceptable Here To: Bob From: Alice Supported: preconditions, qos-selection m=audio a=qos-mechanism: nsis sendrecv a=curr:qos e2e none a=des:qos mandatory e2e sendrecv Bob sends a 488 (Not Acceptable Here) message as the qos-mechanism listed by Alice (rsvp) is not supported by Bob. Alice, if her UA supports this precondition mechanism, MAY send a new INVITE with preconditions using NSIS and have a reasonable expectation that Bob's UA will not reject that session request. 5.3 Offer Many - Accept One in Each Direction Example Alice INVITEs Bob and Bob chooses a different qos-mechanism for each direction from Alice's list Alice sends Bob an INVITE containing more than one qos-mechanism. Polk, et al Expires April 17th, 2005 [Page 10] Internet-Draft Preconditions QoS Mechanism Oct 2005 Alice Bob | INVITE (qos-selection) | |------------------------->| | | | 183 Session Progress | |<-------------------------| | | | PRACK | |------------------------->| | 200 OK | |<-------------------------| Figure 6. INVITE Bob@ SIP/2.0 To: Bob From: Alice Requires: preconditions, qos-selection m=audio a=curr:qos e2e none a= qos-mechanism: rsvp nsis foo sendrecv a=des:qos mandatory e2e sendrecv SIP/2.0 183 Session Progress To: Bob From: Alice Supported: preconditions, qos-selection m=audio a=curr:qos e2e none a=qos-mechanism: nsis send a=qos-mechanism: rsvp recv a=des:qos mandatory e2e sendrecv Bob chooses rsvp (Bob's first preference) for recv direction but prefers to do nsis for streams that his UA originates. Hence, Bob selects a different mechanism for each direction. However, as both mechanisms selected by Bob were originally in Alice's list, Bob accepts the session and issues a 183 (Session Progress) message. 5.4 Offer Many - Prefer Unlisted Combination Example Alice INVITEs Bob and Bob chooses a qos-mechanism for one direction that is not on Alice's list. Alice sends Bob an INVITE with more than one qos-mechanism in this offer. Polk, et al Expires April 17th, 2005 [Page 11] Internet-Draft Preconditions QoS Mechanism Oct 2005 Alice Bob | INVITE (qos-selection) | |------------------------->| | | | 488 Not Acceptable Here | |<-------------------------| | | | ACK | |------------------------->| | | Figure 7. INVITE Bob@ SIP/2.0 To: Bob From: Alice Requires: preconditions, qos-selection m=audio a=qos-mechanism: rsvp nsis sendrecv a=curr:qos e2e none a=des:qos mandatory e2e sendrecv SIP/2.0 488 Not Acceptable Here To: Bob From: Alice Supported: preconditions, qos-selection m=audio a=qos-mechanism: rsvp recv a=qos-mechanism: foo send a=curr:qos e2e none a=des:qos mandatory e2e sendrecv Bob sends a 488 (Not Acceptable Here) message as his UA supports qos-mechanism "foo" for the stream that his UA originates. Alice, if her UA supports this "foo" precondition mechanism, MAY send a new INVITE with preconditions using rsvp for send direction and foo for recv direction and have a reasonable expectation that Bob's UA will not reject that session request. 5.5 Offer Any - Preconditions Unknown Example Bob does not support the qos-selection extension within SIP. Alice Bob | INVITE (qos-selection) | |------------------------->| Polk, et al Expires April 17th, 2005 [Page 12] Internet-Draft Preconditions QoS Mechanism Oct 2005 | | | 420 Bad Extension | |<-------------------------| | | | ACK | |------------------------->| | | Figure 8. INVITE Bob@ SIP/2.0 To: Bob From: Alice Requires: preconditions, qos-selection m=audio a=qos-mechanism: rsvp nsis sendrecv a=curr:qos e2e none a=des:qos mandatory e2e sendrecv SIP/2.0 420 Bad Extension To: Bob From: Alice Unsupported: qos-selection Since Bob does not support qos-selection option, he responds to Alice's INVITE with a 420 Bad Extension. 5.6 Offer Many with Optional Strength - Accept One Example Use of qos-selection as a required option tag with optional strength tag precondition Alice Bob | INVITE (qos-selection) | |------------------------->| | | | 183 Session Progressing | |<-------------------------| | | | ACK | |------------------------->| | | Figure 8. INVITE Bob@ SIP/2.0 To: Bob From: Alice Polk, et al Expires April 17th, 2005 [Page 13] Internet-Draft Preconditions QoS Mechanism Oct 2005 Requires: preconditions, qos-selection m=audio a=qos-mechanism: rsvp nsis sendrecv a=curr:qos e2e none a=des:qos optional e2e sendrecv SIP/2.0 183 Session Progressing To: Bob From: Alice Supported: preconditions, qos-selection m=audio a=qos-mechanism: rsvp sendrecv a=curr:qos e2e none a=des:qos optional e2e sendrecv Since [RFC 3312] states that UAs SHOULD try to reserve resources, it is acceptable to use the Requires option tag with qos-selection. Qos-selection will be made and reservation will be attempted using the selected qos-mechanism but the session will progress even if the UAs are not able to secure reservation. 6. IANA Considerations This document IANA registers the following SIP Option-Tag to be added to the sip-parameters: qos-selection as follows: Name Description Reference ----------- ------------------------------------------ --------- qos-selection This Option-Tag indicates there will be a [This doc] specific qos mechanism(s) listed for qos preconditions within this transaction. The list of one or more mechanisms will be in an SDP attribute line. Section 4.1 of this document defines its usage. This document IANA registers the following SDP attribute field type to be added to the sdp-parameters: qos-mechanism as follows: Polk, et al Expires April 17th, 2005 [Page 14] Internet-Draft Preconditions QoS Mechanism Oct 2005 Type SDP Name Reference ---- ------------------ --------- att-field (media level only) qos-mechanism [This document] Section 4.2 of this document defines its usage. 7. Security Considerations This document provides a means for greater granularity of an existing SIP mechanism. SIP Preconditions as defined without this document may be hidden in a S/MIME encrypted message body preventing revelation. This document defines a set of option-tags that may reveal the use of preconditions where it would otherwise not have been revealed. Caution should be taken with this in might. 8. Acknowledgements To Dave Oran for his help in forming this effort. 9. References 9.1 Normative References [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC3312] G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312 Preconditions, October 2002 [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997 [RFC2327] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998 9.2 Informative References [RFC4080] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005 Polk, et al Expires April 17th, 2005 [Page 15] Internet-Draft Preconditions QoS Mechanism Oct 2005 [ID-GIMPS] H. Schulzrinne, R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-07, "work in progress", July 2005 [ID-NSLP] J. Manner, G. Karagiannis, A. McDonald, S. Van den Bosch, "NSLP for Quality-of-Service signaling", draft-ietf-nsis- qos-nslp-07.txt, "work in progress", July 2005 Author's Address James M. Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Email: jmpolk@cisco.com Subha Dhesikan Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: sdhesika@cisco.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com 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 Polk, et al Expires April 17th, 2005 [Page 16] Internet-Draft Preconditions QoS Mechanism Oct 2005 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. Polk & Expires April 17th, 2006 [Page 17]