One document matched: draft-petithuguenin-sip-fragmentation-responses-02.txt
Differences from draft-petithuguenin-sip-fragmentation-responses-01.txt
Network Working Group M. Petit-Huguenin
Internet-Draft 8x8, Inc.
Intended status: Standards Track March 4, 2007
Expires: September 5, 2007
Preventing IP Fragmentation in Responses for the Session Initiation
Protocol (SIP)
draft-petithuguenin-sip-fragmentation-responses-02
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 September 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
There is limited support to prevent IP fragmentation when using a UDP
or Datagram Transport Layer Security (DTLS) transport with the
Session Initiation Protocol (SIP). This document describes an
extension to prevent fragmentation in SIP responses.
Petit-Huguenin Expires September 5, 2007 [Page 1]
Internet-Draft IP fragmentation in SIP March 2007
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
6.1. Header Field Parameters . . . . . . . . . . . . . . . . . 6
6.2. Header Field . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Response Code . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. Norminative References . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Petit-Huguenin Expires September 5, 2007 [Page 2]
Internet-Draft IP fragmentation in SIP March 2007
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.
[I-D.jennings-sip-dtls] describes how to use DTLS [RFC4347] over SIP
and states that "[t]he normal rules for sending a request over UDP in
RFC 3261 apply to sending over DTLS." This means that the same
problem exists when evaluating if a SIP transaction should use DTLS
or TLS.
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
header field. 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 or DTLS is used. By
walking through the Via list, an UAS supporting this specification
can find which network element needs to switch to a congestion
Petit-Huguenin Expires September 5, 2007 [Page 3]
Internet-Draft IP fragmentation in SIP March 2007
controlled transport protocol to prevent IP fragmentation. If it is
the case, the UAS sends a 6XX Congestion Control response with a
Target header that is used to propagate the response to the chosen
network element. The network element then resends the request by
using a congestion controlled transport protocol.
The protocol also adds the size of the response in the 6XX 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 6XX Congestion Control response, it MUST add a delta parameter
equal to 0 to the Via header field. When sending the request over
UDP or DTLS, 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 DTLS or a
[RFC2914] congestion controlled transport.
When an UAC receives a 6XX Congestion Control response, it checks if
the response was received from the UDP or DTLS 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 over the UDP or DTLS 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 and DTLS 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 6XX 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
Petit-Huguenin Expires September 5, 2007 [Page 4]
Internet-Draft IP fragmentation in SIP March 2007
be added as part of the proxy operation. If the top Via header field
contains a size parameter then the delta value must be subtracted
from this value and the result must be compared to the MTU. If the
MTU is lower than the adjusted size then the UDP or DTLS 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 the new Via header field. If the request will be
proxied using an UDP or DTLS 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 6XX 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 over the UDP or DTLS 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
over the UDP or DTLS 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 6XX 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 6XX 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
Petit-Huguenin Expires September 5, 2007 [Page 5]
Internet-Draft IP fragmentation in SIP March 2007
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).
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, 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
This specification registers three new Via header field parameters
according to the processes of [RFC3968], one new header field and one
response code according to the processes of [RFC3261].
6.1. Header Field Parameters
Header field in which the parameter can appear: Via
Name of the Parameter: delta
Predefined values: no
Petit-Huguenin Expires September 5, 2007 [Page 6]
Internet-Draft IP fragmentation in SIP March 2007
RFC Reference: RFC XXXX:
Header field in which the parameter can appear: Via
Name of the Parameter: mtu
Predefined values: no
RFC Reference: RFC XXXX:
Header field in which the parameter can appear: Via
Name of the Parameter: size
Predefined values: no
RFC Reference: RFC XXXX:
6.2. Header Field
RFC Number: RFC XXXX
Header Field Name: Target
Compact Form: none
6.3. Response Code
Response Code Number: 6XX
Default Reason Phrase: Congestion Control
7. Security Considerations
TBD
Petit-Huguenin Expires September 5, 2007 [Page 7]
Internet-Draft IP fragmentation in SIP March 2007
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 |
| | | |
| | | 6XX Response|
F4 | | 6XX Response|<--------------------|
F5 | 6XX 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
subtract 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 subtract 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 September 5, 2007 [Page 8]
Internet-Draft IP fragmentation in SIP March 2007
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 6XX response, adds the Target header field on it and
sends it back to the Biloxi proxy.
F5: The Biloxi proxy receives the 6XX 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 Atlanta proxy receives the 6XX 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 6XX response and re-executes 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 6XX 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
subtract 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 subtracts 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
subtract 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 subtract 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 September 5, 2007 [Page 9]
Internet-Draft IP fragmentation in SIP March 2007
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. 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.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[I-D.jennings-sip-dtls]
Jennings, C. and N. Modadugu, "Session Initiation Protocol
(SIP) over Datagram Transport Layer Security (DTLS)",
draft-jennings-sip-dtls-03 (work in progress),
February 2007.
Petit-Huguenin Expires September 5, 2007 [Page 10]
Internet-Draft IP fragmentation in SIP March 2007
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 September 5, 2007 [Page 11]
Internet-Draft IP fragmentation in SIP March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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 September 5, 2007 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 16:07:05 |