One document matched: draft-petithuguenin-sip-fragmentation-responses-01.txt
Differences from draft-petithuguenin-sip-fragmentation-responses-00.txt
Network Working Group M. Petit-Huguenin
Internet-Draft 8x8, Inc.
Intended status: Standards Track December 5, 2006
Expires: June 8, 2007
Preventing IP Fragmentation in Responses for the Session Initiation
Protocol (SIP)
draft-petithuguenin-sip-fragmentation-responses-01
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 June 8, 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 June 8, 2007 [Page 1]
Internet-Draft IP fragmentation in SIP December 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. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Norminative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Petit-Huguenin Expires June 8, 2007 [Page 2]
Internet-Draft IP fragmentation in SIP December 2006
1. Introduction
[RFC3261] 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 larger than the MTU.
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 SIP server
(proxy or UAS) 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 [RFC2119].
3. Overview of Operation
The protocol works by adding one, two or three parameters on each
Via. The first parameter, "delta", contains a negative or 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,
"mtu", 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 6?? Congestion Control response with a 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 June 8, 2007 [Page 3]
Internet-Draft IP fragmentation in SIP December 2006
The protocol also adds the size of the response in the 6??
Congestion Control response, so each element can evaluate on the
second try if the congestion controlled transport needs to be used.
4. Detailed Processing Rules
4.1. UAC Behavior
When an UAC sends over any protocol a request that is not the result
of a 6?? Congestion Control response, it MUST add a delta parameter
equal to 0 to the Via header field. When sending the request over
UDP, an UAC MUST also add a mtu 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 mtu 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 [RFC2914]
congestion controlled transport.
When an UAC receives a 6?? 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 delta and mtu 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 [RFC2914] congestion controlled transport. This
can be done by applying again the [RFC3263] algorithm, but this time
by excluding UDP from the list of supported protocols. The new
request must have a Via header field with a different branch
parameter, a delta parameter equal to 0, no mtu parameter and a size
parameter equals to the size value in the Target header field
received in the 6?? Congestion Control response.
4.2. Proxy Behavior
The proxy will remove and eventually add elements to the response
that will be proxied and so will increase or decrease the size of the
response by a number of bytes. In the majority of cases this size
can be evaluated from the content of the request that will trigger
the response and from the knowledge of the internal proxy processing.
The proxy MUST evaluate this value before proxying the request and
add this value in a delta parameter to the Via header field that will
be added as part of the proxy operation. If the top Via header field
contains a size parameter then the delta value must be substracted
from this value and the result must be compared to the MTU. If the
MTU is lower than the adjusted size then the UDP transport MUST be
excluded from the list of transports that can be used to proxy the
request. The adjusted size value MUST be copied in size parameter of
Petit-Huguenin Expires June 8, 2007 [Page 4]
Internet-Draft IP fragmentation in SIP December 2006
the new Via header field. If the request will be proxied using an
UDP transport then the path MTU (or 1500 if the path MTU is not
known) MUST be added as a mtu parameter to the new Via header field.
The mtu parameter MUST NOT be added for other protocols.
When a proxy receives a 6?? Congestion Control response it MUST
check for the presence of the Target header field. If the field
contains the target value 0, then the response is for this proxy. If
the response 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 by using a
congestion controlled transport. The new request must have a Via
header field with a different branch parameter, a delta parameter, no
mtu parameter and a size parameter equal to the size value in the
Target header field received in the 6?? Congestion Control response.
If the response is not for this proxy, the value of the Target header
field MUST be decremented by one, the proxy MUST cancel all the
eventual pending branches and MUST forward the response upstream.
4.3. UAS Behavior
When an UAS received a request, it initializes a variable named
target with the value 0 and a variable named size with the total size
in bytes of the response that will be sent. If the UAS can send
provisional responses the maximum size of all the possible responses
is used instead. Then the UAS will execute the following steps on
each Via header fields, starting from the top Via:
o If the Via header field does not contain a delta parameter or if
there is no other Via header field in the list then the process
stops here. If the Target header was previously created then one
of the hop must be replaced by a congestion controlled transport.
A 6?? response must be created, the Target header must be added to
this response and the response must be sent.
o If the Via header field contains a mtu parameter that is lower
than the value of the size variable, then this hop must be
replaced by a congestion controlled transport. The current values
of the target and size parameters must be copied in a Target
header.
o The target variable value is incremented by one and the value of
the delta parameter of the Via is added to the size variable value
(the value is incremented or decremented depending on the sign of
the delta parameter value).
Petit-Huguenin Expires June 8, 2007 [Page 5]
Internet-Draft IP fragmentation in SIP December 2006
5. Grammar
This specification defines three new Via header field parameters,
delta, mtu and size. The following ABNF [RFC4234] uses some
definitions from [RFC3261]:
via-params = via-ttl / via-maddr / via-received / via-branch / via-
delta / via-mtu / via-size / via-extension
via-delta = "delta" EQUAL [-] 1*DIGIT
via-mtu = "mtu" EQUAL 1*DIGIT
via-size = "size" EQUAL 1*DIGIT
This specification defines also a new header field parameters,
Target. The following ABNF [RFC4234] uses some definitions from
[RFC3261]:
Target = "Target" HCOLON target-val LWS target-size
target-val = 1*DIGIT
target-size = 1*DIGIT
6. IANA Considerations
TBD
7. Security Considerations
TBD
Petit-Huguenin Expires June 8, 2007 [Page 6]
Internet-Draft IP fragmentation in SIP December 2006
8. Example
Alice Atlanta Biloxi Bob
| | | |
|Request UDP | | |
F1 |----------------->|Request TCP | |
F2 |delta=0 mtu=1500 |====================>|Request UDP |
F3 | |delta=100 |-------------------->|
| | |delta=100 mtu=1500 |
| | | |
| | | 6?? Response|
F4 | | 6?? Response|<--------------------|
F5 | 6?? Response|<====================| Target: 2 1800|
F6 |<-----------------| Target: 1 1800| |
| Target: 0 1800| | |
| | | |
|Request TCP | | |
F7 |=================>|Request TCP | |
F8 |delta=0 size=1800 |====================>|Request TCP |
F9 | |delta=100 size=1700 |====================>|
| | |delta=100 size=1600 |
| | | |
Figure 1
F1: The UAC sends a request to the Atlanta proxy with a delta
parameter equal to 0 added to the Via. As the transport chosen is
UDP, a mtu parameter is added to the Via header.
F2: The Atlanta proxy prepares to proxy the request to the Biloxi
proxy, and evaluates the number of bytes that it would add or
substract to the response received from Biloxi for this request.
It adds this value as a delta parameter to the Via of the proxied
request. As the proxy chooses TCP, a congestion controlled
transport, for the proxied request it does not add any mtu
parameter to the Via header.
F3: The Biloxi proxy prepares to proxy the request to the UAS, and
evaluate the number of bytes that it would add or substract to the
response received from the UAS for this request. It adds this
value as a delta parameter to the Via of the proxied request. As
the proxy choose UDP as transport for the proxied request, it adds
a mtu parameter to the Via header.
F4: The UAS evaluates the size of the response that will be sent and
finds a value of 1600 bytes. It initializes the target variable
to 0 and the size variable to the size of the response so we have
target=0 and size=1600. The UAS then looks at the first Via and
find a mtu value that is lower than the current size value, so it
copies the target and size variables in the Target header (Target:
0 1600). It then adds the delta value to the size variable and
Petit-Huguenin Expires June 8, 2007 [Page 7]
Internet-Draft IP fragmentation in SIP December 2006
increments the target variable so we now have target=1 and
size=1700. The UAS then looks at the second Via header and finds
no mtu parameter. It then adds the delta value to the size
variable and increments the target variable so we now have
target=2 and size=1800. The UAS then looks at the third Via
header and finds a mtu value that is lower than the current size
variable so it copies the target and size values in the Target
header (Target: 2 1800). There is no other Via in the list and
there was at least one mtu too small in the list so the UAS
creates a 6?? response, adds the Target header field on it and
sends it back to the Biloxi proxy.
F5: The Biloxi proxy receives the 6?? response, checks that the
target value in the Target header is different than 0, cancels all
the eventual branches, and decrements the target value in the
Target header field before forwarding the response to the Atlanta
proxy.
F6: The Athanta proxy receives the 6?? response, checks that the
target value in the Target header is different than 0, cancels all
the eventual branches and decrements the target value in the
Target header field before forwarding the response to the UAC.
F7: The Alice UAC receives the 6?? response and reexecutes the
RFC3263 algorithm, but this time by excluding UDP from the list of
supported transports. The same request is then sent over the
selected transport with a Via header containing a delta parameter
equal to 0 and with a size parameter equals to the size value
received in the Target parameter of the 6?? response.
F8: The Atlanta proxy prepares to proxy the request to the Biloxi
proxy, and evaluates the number of bytes that it would add or
substract to the response received from Biloxi for this request.
It adds this value as a delta parameter to the Via of the proxied
request. The proxy also looks at the top Via and finds that there
is a size parameter on it. It substracts the delta value that was
just calculated and as the value is higher than the MTU, UDP is
excluded from the list of transports selected by the RFC 3263
algorithm. As the proxy chooses TCP, a congestion controlled
transport, for the proxied request it does not add any mtu
parameter to the Via header. The proxy also adds the modified
size in the new Via.
F9: The Biloxi proxy prepares to proxy the request to the Biloxi
proxy, and evaluates the number of bytes that it would add or
substract to the response received from the UAS for this request.
It adds this value as a delta parameter to the Via of the proxied
request. The proxy also looks at the top Via and finds that there
is a size parameter on it. It substract the delta value that was
just calculated and as the value is higher than the MTU, UDP is
excluded from the list of transports selected by the RFC 3263
algorithm. As the proxy chooses TCP, a congestion controlled
transport, for the proxied request it does not add any mtu
Petit-Huguenin Expires June 8, 2007 [Page 8]
Internet-Draft IP fragmentation in SIP December 2006
parameter to the Via header. The proxy also adds the modified
size in the new Via.
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.
10. References
10.1. Norminative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC3261] 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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
10.2. Informative References
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 June 8, 2007 [Page 9]
Internet-Draft IP fragmentation in SIP December 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 June 8, 2007 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 16:07:03 |