One document matched: draft-petithuguenin-sip-outbound-fragmentation-01.txt
Differences from draft-petithuguenin-sip-outbound-fragmentation-00.txt
Network Working Group M. Petit-Huguenin
Internet-Draft 8x8, Inc.
Intended status: Standards Track January 4, 2007
Expires: July 8, 2007
Preventing Fragmentation for Client Initiated Connections in the Session
Initiation Protocol (SIP)
draft-petithuguenin-sip-outbound-fragmentation-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 July 8, 2007.
Copyright Notice
Copyright (C) The Internet Society (2007).
Abstract
There is cases when a Session Initiation Protocol (SIP) client can
initiate a bidirectional UDP stream or a TCP connection to a SIP
server but the SIP server cannot do the same in the other direction.
The server can reuse the existing bidirectional UDP stream or TCP
connection but cannot use a TCP connection if the client chose to use
a bidirectional UDP stream. This document described a method to
force the client to initiate a TCP connection to the server.
Petit-Huguenin Expires July 8, 2007 [Page 1]
Internet-Draft Outbound fragmentation January 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
4. Client Discovery of Server . . . . . . . . . . . . . . . . . . 5
5. Server Determination of Usage . . . . . . . . . . . . . . . . 5
6. New Requests or Indications . . . . . . . . . . . . . . . . . 5
6.1. ForceTCP Method . . . . . . . . . . . . . . . . . . . . . 5
6.1.1. Server Behavior . . . . . . . . . . . . . . . . . . . 5
6.1.2. Client Behavior . . . . . . . . . . . . . . . . . . . 6
6.2. GetToken Method . . . . . . . . . . . . . . . . . . . . . 6
6.2.1. Server Behavior . . . . . . . . . . . . . . . . . . . 6
6.2.2. Client Behavior . . . . . . . . . . . . . . . . . . . 7
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. FLOW-TOKEN . . . . . . . . . . . . . . . . . . . . . . . . 7
8. New Error Response Codes . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10.1. New STUN methods . . . . . . . . . . . . . . . . . . . . . 8
10.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 8
10.3. New STUN response code . . . . . . . . . . . . . . . . . . 8
11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Norminative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Petit-Huguenin Expires July 8, 2007 [Page 2]
Internet-Draft Outbound fragmentation January 2007
1. Introduction
The SIP specification [RFC3261] uses an hybrid TCP-UDP transport.
All the messages exchanged on a specific SIP transaction must use the
same transport but an implementation is free to use differents
transports for each transaction between two SIP elements. The SIP
specification only mandates to use the TCP transport or another
congestion controlled transport protocol if the size of the message
to send is bigger than the MTU. Excepted for the case documented in
[I-D.petithuguenin-sip-fragmentation-responses] and
[I-D.gurbani-sip-large-udp-response], this mechanism works well on
the open Internet.
Unfortunately this is no longer the case if the two SIP elements are
separated by one or more NATs or firewalls. Bidirectional UDP
streams and TCP connections can only be initiated from inside the
NAT/firewall and this prevents the outside SIP element to contact the
SIP element inside the NAT or firewall. The Oubound
[I-D.ietf-sip-outbound] specification fixes this problem by reusing a
"flow" (i.e. a bidirectional UDP stream or TCP connection) initiated
by the SIP element inside the NAT/firewall for transactions initiated
in the reversed direction.
The problem with Outbound is that there is only one flow created,
either over an UDP or a congestion controlled transport and so the
SIP elements no longer have the possibility to choose the best
transport for each transaction. Even the SIP element inside the NAT/
firewall cannot easily change the transport as it will have to
replace the existing flow by initiating a new REGISTER transaction.
Creating two flows, one over UDP and the other over TCP, does not
work either as the transport is encoded in the flow token and an edge
proxy will have no way to find the TCP connection if the flow token
contains the flow information for the UDP bidirectional stream.
Because fragmentation must be prevented [I-D.heffner-frag-harmful]
and because the Outbound specification prevents hybrid UDP-TCP
transport to be used, it effectively changes SIP by removing the
possibility of using UDP, which is mandatory in all SIP elements.
There is multiples reasons why a SIP element should be able to choose
between an hybrid TCP-UDP transport and a permanent TCP connection.
For instance, maintaining thousands of permanent TCP connections uses
more resources than using UDP for the same number of UA. A SIP
endpoint in fact does not need very often to use TCP to send or
receive messages; the SIP registration messages are generally smaller
than the MTU; the SIP subscriptions [RFC3265] also generally does not
need TCP, as partial state update and URL indirection [RFC4483] can
Petit-Huguenin Expires July 8, 2007 [Page 3]
Internet-Draft Outbound fragmentation January 2007
be used. It is interesting to note that there is existing research
efforts to add hybrid TCP-UDP transport [DHTTP][HYBRID] to HTTP
[RFC2616].
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] and indicate requirement
levels for compliant implementations.
3. Overview of Operation
An UA using this specification creates flows as defined in the
Outbound specification. If the flow is created over TCP, the
processing defined in Outbound is used. If the flow is created over
UDP, the UA must be prepared to open a temporary TCP connection to
the same destination than the destination used for the UDP flow. The
UA must be able to associate the UDP flow with the TCP flow and with
the flow token for the TCP flow. The flow token is an opaque value
which is encoded by the SIP edge proxy.
The UA that created a UDP flow can create at any time an additional
TCP flow by opening a TCP connection to the same edge proxy, and
sending a STUN GetToken request over this connection. The edge proxy
will respond with a STUN getToken response with a FLOW-TOKEN
attribute that contain a flow token generated as if a REGISTER was
received over this TCP connection and the edge proxy had generated a
flow token to store in the user part of the SIP URI in the Record-
Route. The UA then associates the TCP connection and the flow token
with the UDP flow. As long as the TCP connection is open, the UA can
use it to send oversized SIP messages to the SIP edge proxy. The UA
can close the connection after using it or can keep it open for a
longer time. The UA must be ready to handle disconnection from the
server. After a disconnection, the UA removes the association
between the UDP flow and the TCP connection and flow token.
When a edge proxy receives a request that need to be forwarded to the
UA, it uses the flow token to find the flow. If the flow is over
TCP, or over UDP and the message size is lower than the MTU, the
processing described in Outbound is used. If the flow is over UDP
and the message size is higher than the MTU, then the edge proxy
sends a STUN ForceTCP request to the UA over the UDP flow. The UA
responds with a STUN ForceTCP response with a FLOW-TOKEN attribute
that contains a flow token that can be used as if the edge proxy
received it in the request to forward. The UA returns the flow token
Petit-Huguenin Expires July 8, 2007 [Page 4]
Internet-Draft Outbound fragmentation January 2007
that is associated to the UDP flow from which it received the STUN
ForceTCP request. If there is no flow token associated with the UDP
flow, the UA creates a TCP connection and sends a STUN GetToken
request to retrieve it from the edge proxy.
4. Client Discovery of Server
STUN requires all usages to define the mechanism by which a client
discovers the server [I-D.ietf-behave-rfc3489bis].
This STUN usage uses the same source and destination IP address and
port than the SIP protocol. In fact it uses the same path than the
NAT keepalives usage described in [I-D.ietf-behave-rfc3489bis].
5. Server Determination of Usage
STUN requires all usages to define the mechanism by which the server
determines the usage [I-D.ietf-behave-rfc3489bis].
This usage is defined by a specific set of methods.
6. New Requests or Indications
This usage defines two new methods:
0x009: ForceTCP
0x00A: GetToken
6.1. ForceTCP Method
The ForceTCP method is used by an edge proxy or a registrar when it
needs to request the UA to open a TCP connection to the edge proxy or
registrar.
6.1.1. Server Behavior
The server first processes the request according to the general
request processing rules in [I-D.ietf-behave-rfc3489bis]. The server
SHOULD NOT authenticate or look for a MESSAGE-INTEGRITY attribute.
If the request is not received over UDP, the server MUST reject the
request with a 448 (Operation for UDP Only) response error code.
The server then checks if there is a TCP connection and a flow token
associated with the UDP flow that received the request. If there is
Petit-Huguenin Expires July 8, 2007 [Page 5]
Internet-Draft Outbound fragmentation January 2007
no existing TCP connection associated with the UDP flow, the server
will use the procedures defined in Section 6.2 to create a TCP
connection and retrieve a flow token. The newly created connection
and the retrieved flow token are associated with the existing UDP
flow.
The server generates a ForceTCP response using the general procedures
defines in [I-D.ietf-behave-rfc3489bis]. The flow token associated
with the UDP flow MUST be included in the FLOW-TOKEN attribute in the
response.
6.1.2. Client Behavior
An edge proxy that receives a SIP request that, after been processed
according to section 5.3 of [I-D.ietf-sip-outbound], will be
forwarded over an UDP flow with a MTU smaller than the size of the
SIP message MUST send a ForceTCP request to the UA over the UDP flow.
This request is constructed and sent using the general procedures
defined in [I-D.ietf-behave-rfc3489bis].
Processing of the response follows the general procedures of
[I-D.ietf-behave-rfc3489bis]. A successful response will contain a
FLOW-TOKEN attribute that contain a flow token for a TCP connection
that can be used to send the oversized SIP message to the same
destination than the flow token that was extracted from the received
SIP request.
If the edge proxy receives a 400 response, it knows that the UA does
not support this specification and MUST reject the SIP request with a
430 (Flow Failed), as if the flow was not found.
6.2. GetToken Method
The GetToken method is used by an UA to establish a TCP connection
and request a flow token that can be used by the edge proxy.
6.2.1. Server Behavior
The server first processes the request according to the general
request processing rules in [I-D.ietf-behave-rfc3489bis]. The server
SHOULD NOT authenticate or look for a MESSAGE-INTEGRITY attribute.
If the request is not received over TCP, the server MUST reject the
request with a 445 (Operation for TCP Only) response error code
[I-D.ietf-behave-turn].
The server then generates a flow token as if a SIP REGISTER request
was received over this TCP connection. The server can use any one of
Petit-Huguenin Expires July 8, 2007 [Page 6]
Internet-Draft Outbound fragmentation January 2007
the algorithms listed in [I-D.ietf-sip-outbound] or any other
algorithm. The server then generates a GetToken response using the
procedures defined in [I-D.ietf-behave-rfc3489bis]. The flow token
MUST be included in the FLOW-TOKEN attribute in the response.
The server SHOULD NOT close the connection after the end of the SIP
transaction. It MAY close the connection if it is a long lived
connection and resources need to be reclaimed.
6.2.2. Client Behavior
An UA can at any time, or when receiving a ForceTCP request without
existing TCP connection, create a TCP connection and send a GetToken
request over this connection. This request is constructed and sent
using the general procedures defined in [I-D.ietf-behave-rfc3489bis].
Processing of the response follows the general procedures of
[I-D.ietf-behave-rfc3489bis]. A successful response will contain a
FLOW-TOKEN attribute that contain a flow token for the newly created
TCP connection. This flow token can be associated with the UDP flow
and the TCP connection to be used later when the UA will receive a
ForceTCP request.
The UA SHOULD NOT close the connection as soon it has received the
STUN response and SHOULD keep it open until at least the end of the
SIP transaction or 5 seconds if there is no SIP transaction on the
connection. The UA can keep the connection open after the end of the
SIP transaction but MUST be ready to process a disconnection from the
server.
7. New Attributes
This usage defines the following new attributes:
0x0024: FLOW-TOKEN
7.1. FLOW-TOKEN
The FLOW-TOKEN attribute is present in the ForceTCP and GetToken
responses and contains a flow token as defined by
[I-D.ietf-sip-outbound]. The value of FLOW-TOKEN is a variable
length opaque value and can be the result of one of the algorithms
defined in section 5.2 of [I-D.ietf-sip-outbound] or any other
algorithm. The base64 encoding step described in the algorithms can
be skipped.
If the FLOW-TOKEN is not a multiple of four bytes it is padded for
Petit-Huguenin Expires July 8, 2007 [Page 7]
Internet-Draft Outbound fragmentation January 2007
encoding into the STUN message, in which case the attribute length
represents the length of the FLOW-TOKEN prior to padding.
8. New Error Response Codes
This usage defines the following new Error response code:
448 (Operation for UDP Only): The client tried to send a request to
perform a UDP-only operation.
9. Security Considerations
TBD
10. IANA Considerations
This specification defines two new STUN methods and one response
code. This section directs IANA to add these protocol elements to
the IANA registry of STUN protocol elements.
10.1. New STUN methods
0x009: ForceTCP
0x00A: GetToken
10.2. New STUN Attributes
0x0024: FLOW-TOKEN
10.3. New STUN response code
448 Operation for UDP Only
Petit-Huguenin Expires July 8, 2007 [Page 8]
Internet-Draft Outbound fragmentation January 2007
Page intentionnaly left blank
Petit-Huguenin Expires July 8, 2007 [Page 9]
Internet-Draft Outbound fragmentation January 2007
11. Example
In Figure 1, The vertical line made of ":" characters represents a
firewall or a NAT. The horizontal lines made of "-" characters
represent the sending of messages over UDP and the horizontal lines
made of "=" characters represent the sending of messages over TCP.
Endpoint : Edge Registrar Home
| : | | |
| REGISTER : | | |
F1 |-------------------->| REGISTER | |
F2 | : |==========>| |
| : | 200 R | |
F3 | : 200 R |<==========| |
F4 |<--------------------| | |
| Binding Request | | |
F5 |-------------------->| | |
| Binding Response | | |
F6 |<--------------------| | |
: : : : :
: : : : :
| : | | | INVITE
F7 | : | | INVITE |<========
F8 | ForceTCP Request |<======================|
F9 |<--------------------| | |
| GetToken Request | | |
F10 |====================>| | |
| GetToken Response | | |
F11 |<====================| | |
| ForceTCP Response | | |
F12 |-------------------->| | |
| : INVITE | | |
F13 |<====================| | |
| 200 I : | | |
F14 |====================>| 200 I | |
| : |======================>| 200 I
| : | | |========>
| : | | | ACK
| : | | ACK |<========
| : ACK |<======================|
F15 |<--------------------| | |
| : | | |
Figure 1
Petit-Huguenin Expires July 8, 2007 [Page 10]
Internet-Draft Outbound fragmentation January 2007
F1: The UA sends a REGISTER request over UDP to the edge proxy.
F2: The edge proxy proxies the REGISTER request to the registrar
using TCP.
The registrar sends a 200 OK response to the edge proxy.
F4: The edge proxy forwards the 200 OK to the UA.
F5: The UA sends a STUN Binding Request to the edge proxy to keep
the binding alive.
F6: The edge proxy responds by sending a Binding Response to the UA.
F7: The home proxy receives an INVITE request.
F8: The home proxy queries the registrar (not shown in the diagram),
and proxies the request to the edge proxy.
F9: The edge proxy finds that the request cannot be sent over the
existing UDP flow because the packet size is higher that the MTU.
The edge proxy uses the flow token to send a STUN ForceTCP request
over the UDP flow.
F10: The UA immediately open a TCP connection to the edge proxy and
send a STUN GetToken request.
F11: The edge proxy calculates a flow token for the TCP connection
and send it back to the UA over the same TCP connection in a
GetToken response.
F12: The UA copies the flow token received on the TCP connection and
send it to the edge proxy in a STUN ForceTCP response over the UDP
flow.
F13: The edge proxy now have a TCP token that can be used to send
the INVITE to the UA over a TCP flow.
F14: The UA responds to the INVITE request by sending a 200 OK
response over the TCP flow and close the TCP connection.
F15: The SIP ACK message is received by the edge proxy and sent over
the UDP flow as it is smaller than the MTU.
12. References
12.1. Norminative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-06 (work in progress),
November 2006.
Petit-Huguenin Expires July 8, 2007 [Page 11]
Internet-Draft Outbound fragmentation January 2007
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., "Simple Traversal Underneath Network
Address Translators (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-05 (work in progress),
October 2006.
[I-D.ietf-behave-turn]
Rosenberg, J., "Obtaining Relay Addresses from Simple
Traversal Underneath NAT (STUN)",
draft-ietf-behave-turn-02 (work in progress),
October 2006.
12.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC4483] Burger, E., "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", RFC 4483,
May 2006.
[I-D.petithuguenin-sip-fragmentation-responses]
Petit-Huguenin, M., "Preventing IP Fragmentation in
Responses for the Session Initiation Protocol (SIP)",
draft-petithuguenin-sip-fragmentation-responses-01 (work
in progress), December 2006.
[I-D.gurbani-sip-large-udp-response]
Gurbani, V. and S. Lawrence, "Handling Large User Datagram
Protocol (UDP) Responses in the Session Initiation
Protocol (SIP)", draft-gurbani-sip-large-udp-response-00
(work in progress), October 2006.
[I-D.heffner-frag-harmful]
Heffner, J., "IPv4 Fragmentation Considered Very Harmful",
draft-heffner-frag-harmful-03 (work in progress),
December 2006.
[DHTTP] Rabinovich, M., "DHTTP: An Efficient and Cache-Friendly
Transfer Protocol for the Web", in IEEE/ACM Transactions
on Networking, Vol. 12, No 6, December 2004.
[HYBRID] Cidon, I., Gupta, A., Rom, R., and C. Schuba, "Hybrid TCP-
UDP Transport for Web Traffic", in Proc. IEEE Int.
Petit-Huguenin Expires July 8, 2007 [Page 12]
Internet-Draft Outbound fragmentation January 2007
Performance, Computing and Communications Conf, pp 177-
184, January 1999.
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 July 8, 2007 [Page 13]
Internet-Draft Outbound fragmentation January 2007
Full Copyright Statement
Copyright (C) The Internet Society (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 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 July 8, 2007 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 22:17:19 |