Network Working Group M. Petit-Huguenin Internet-Draft 8x8, Inc. Intended status: Standards Track October 3, 2006 Expires: April 6, 2007 Preventing IP Fragmentation in Responses for the Session Initiation Protocol (SIP) draft-petithuguenin-sip-fragmentation-responses-00 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 6, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract There is limited support to prevent IP fragmentation when using the UDP transport with the Session Initiation Protocol (SIP). This document describes an extension to prevent fragmentation in responses. Petit-Huguenin Expires April 6, 2007 [Page 1] Internet-Draft IP fragmentation in SIP October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . . 3 4. Detailed Processing Rules . . . . . . . . . . . . . . . . . . . 4 4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 4 4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 5. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Norminative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Petit-Huguenin Expires April 6, 2007 [Page 2] Internet-Draft IP fragmentation in SIP October 2006 1. Introduction RFC 3261 [3] section 18.1.1 presents a simple algorithm to prevent fragmentation in the response, by sending the request over a congestion controlled transport protocol (e.g. TCP) if the size of the packet is too large. The problem is that it is difficult to calculate the size of the packets that will be received from the size of the packet sent so the algorithm simply presumes that the response will be 200 bytes bigger than the request. The real size of the packet can be lower than this, and perhaps small enough to do not mandate the use of TCP, or can be higher than this and then resulting in unexpected fragmentation. The fundamental assumption for this extension is that a proxy is capable to evaluate the number of bytes it will increase or decrease the size of the response received before forwarding it. If the proxy stores this value in the Via header, and all the other proxies on the path to the endpoint are also doing this, then the UAS will be able to evaluate if the response will be fragmented when sent back by this proxy. 2. Terminology 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 [1]. 3. Overview of Operation The protocol works by adding one or two parameters on each Via. The first parameter, "inc", contains a negative of positive value that indicates the number of bytes that will be added or removed when traversing this network element. It also signals that this element is supporting this specification. The second parameter, "max", contains the MTU for the network element that added the Via. This parameter is added only when UDP is used. By walking through the Via list, an UAS supporting this specification can find which network element need to switch to a congestion controlled transport protocol to prevent IP fragmentation. If it is the case, the UAS sends a 607 Congestion Control response with a Redirect-Target header that is used to propagate the response to the chosen network element. The network element then resend the request by using a congestion controlled transport protocol. Petit-Huguenin Expires April 6, 2007 [Page 3] Internet-Draft IP fragmentation in SIP October 2006 4. Detailed Processing Rules 4.1. UAC Behavior When an UAC sends over any protocol a request that is not the result of a 607 Congestion Control response, it MUST add an inc parameter equal to 0. When sending the request over UDP, an UAC MUST also add a max parameter with a value equal to the path MTU (or 1500 if the MTU is unknown) to the Via header field. For other protocols the UAC MUST NOT add the max parameter to the Via header field. The rules described in section 18.1.1 of RFC 3261 are used to choose if the request is sent over UDP or a RFC 2914 [2] congestion controlled transport protocol. When an UAC receives a 607 Congestion Control response, it checks if the response was received from the UDP transport. If not, then an element did not follow this specification and the branch MUST be retried with the same protocol but without the inc and max Via parameters defined by this specification. If the response was received from the UDP transport, then the branch MUST be retried, but this time by using a RFC 2914 [2] congestion controlled transport protocol. The new request must have a Via header field with a different branch parameter, an inc parameter equal to 0 and no max parameter. The UAC retries the branch by applying the RFC 3263 [4] algorithm to the same Request-URI, but this time by excluding UDP from the list of supported protocols. 4.2. Proxy Behavior A proxy can choose to forward a response received. Before forwarding the response the proxy will remove and eventually add elements to the message and so will increase or decrease the size of the response by a number of bytes. In the majority of cases the size added or removed can be evaluated from the content of the request that will trigger the response and from the knowledge of the internal processing done by the proxy. The proxy MUST evaluate this value before proxying the request and add this value in an inc parameter to the Via header field that will be added as part of the proxy operation. If the request will be proxied using an UDP transport then the path MTU (or 1500 if the path MTU is not known) MUST also be added as a max parameter to the new Via header field. The max parameter MUST NOT be added for other protocols. When a proxy receives a 607 Congestion Control response it MUST check for the presence of the Redirect-Target header field. If the field does not exist, or contains the value 0, then the response is for Petit-Huguenin Expires April 6, 2007 [Page 4] Internet-Draft IP fragmentation in SIP October 2006 this proxy. If the reponse is for this proxy, then it checks that this response was received from the UDP transport. If not, then an element did not follow this specification and the branch must be retried with the same protocol, but without the Via parameters defined by this specification. If the response is for this proxy and was received from the UDP transport, then the branch must be retried, but this time by using a congestion controlled transport protocol. The new request must have a Via header field with a different branch parameter, an inc parameter and no max parameter. If the response is not for this proxy, the value of the Redirect-Target header field MUST be decremented by one. The proxy MUST cancel all the eventual pending branches and forwards the response downstream. 4.3. UAS Behavior When an UAS receives a request it searches if an UDP transport was used somewhere in the path from the UAC and if the client that used this transport follows this specification. To do this the UAS searches the first Via header field that contains a max parameter, starting from the top Via header field. If none are found then there is no UDP transport in the path that can be changed to a congestion controlled transport protocol, and the remaining of this section can be skipped. If a Via header field with a max parameter is found, then the UAS must check that all the Via headers field between this Via header field and the top Via header field (including this two Via header fields) contain an inc parameter. If not then one of the proxies does not support this specification, and the remaining of this section can be skipped. The UAS then calculates the size of the response that will be sent (if the UAS can send provisional responses the maximum size of all the possible responses is used). The UAS then inspects each Via header fields in the request, starting from the top Via. The processing stops when a Via header field does not contain an inc parameter or when there is no other Via header field to process. If the Via header field contains a max value, then the max value is compared to the size of the response. If the size of the response is higher than the value of the max parameter, then the UAS MUST send a 607 response. The UAS MUST add a Redirect-Target header field with a value equal to the index of the Via containing the max parameter, with the top Via having the index 0 and the subsequent Via incrementing the index value by one. If the response size is lower or equal to the max parameter value, then the inc parameter value must be added to the response size. The next Via header field will be then processed by using this modified value as the response size. Petit-Huguenin Expires April 6, 2007 [Page 5] Internet-Draft IP fragmentation in SIP October 2006 5. Grammar This specification defines two new Via header field parameters, inc and max. The following ABNF [5] uses some definitions from RFC 3261 [3]: via-params = via-ttl / via-maddr / via-received / via-branch / via- inc / via-max / via-extension via-inc = "inc" EQUAL [-] 1*DIGIT via-max = "max" EQUAL 1*DIGIT This specification defines also a new header field parameters, Redirect-Target. The following ABNF [5] uses some definitions from RFC 3261 [3]: Redirect-Target = "Redirect-Target" HCOLON target-val target-val = 1*DIGIT 6. IANA Considerations TBD 7. Security Considerations TBD 8. Examples TBD 9. Acknowledgements Internal versions of this document were reviewed by Patrice Bruno, Lee Hong, Garth Judge, Suhas Joshi, Jim Kleck, Eric Lin, Jason Liu, Vadim Tsyganok and Qing Zhao. The Redirect-Target header definition and behavior were borrowed from [6] 10. References Petit-Huguenin Expires April 6, 2007 [Page 6] Internet-Draft IP fragmentation in SIP October 2006 10.1. Norminative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [3] 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. [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. 10.2. Informative References [6] Rosenberg, J., "Construction of the Route Header Field in the Session Initiation Protocol (SIP)", draft-rosenberg-sip-route-construct-01 (work in progress), March 2006. Author's Address Marc Petit-Huguenin 8x8, Inc. 3151 Jay Street Santa Clara, CA 95054 US Phone: +1 408 654 0875 Email: marc@8x8.com Petit-Huguenin Expires April 6, 2007 [Page 7] Internet-Draft IP fragmentation in SIP October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Petit-Huguenin Expires April 6, 2007 [Page 8]