One document matched: draft-jain-dispatch-sip-transport-connection-reuse-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3324 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3324.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY I-D.I-D.ietf-sip-connect-reuse PUBLIC "" 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-connect-reuse.xml'>
]>
<rfc category="std"
ipr="full3978"
ipr="trust200811"
ipr="noModificationTrust200811"
ipr="noDerivativesTrust200811"
ipr="trust200902"
ipr="noModificationTrust200902"
ipr="noDerivativesTrust200902"
ipr="pre5378Trust200902"
docName="draft-jain-dispatch-sip-transport-connection-reuse-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc strict="no" ?>
<front>
<title abbrev="Connection Reuse in SIP">Reusing Transport Layer Connections in Session Initiation Protocol (SIP)</title>
<workgroup>DISPATCH Working Group</workgroup>
<author initials='R.J' surname="Jain" fullname='Rajnish Jain' role="editor">
<organization>IPC Systems</organization>
<address>
<postal>
<street>777 Commerce Drive</street>
<city>Fairfield</city> <region>CT</region>
<code>06825 </code>
<country>USA </country>
</postal>
<email>rajnish.jain@ipc.com</email>
</address>
</author>
<author initials='V.G' surname="Gurbani" fullname='Vijay Gurbani'>
<organization>Bell Laboratories, Alcatel-Lucent</organization>
<address>
<postal>
<street>2000 Lucent Lane</street>
<street>Rm 6G-440</street>
<city>Naperville</city> <region>IL</region>
<code>60566 </code>
<country>USA </country>
</postal>
<email>vkg@lucent.com</email>
</address>
</author>
<author initials='H.K' surname="Kaplan" fullname='Hadriel Kaplan'>
<organization>AcmePacket</organization>
<address>
<postal>
<street>71 Third Ave.</street>
<city>Burlington</city> <region>MA</region>
<code>01803 </code>
<country>USA </country>
</postal>
<email>hkaplan@acmepacket.com</email>
</address>
</author>
<date/>
<abstract><t>The current Session Initiation Protocol (SIP) specification dictates
that a transport layer connection can carry SIP requests in only one direction i.e. from
the client to the server. This presents scalability problems as twice the number of
connections are needed for each pair of SIP entities that communicate with each other.
The internet-draft <xref target="I-D.ietf-sip-connect-reuse"/> specifies a mechanism for reusing
SIP over TLS connections. However, that document is predicated on secure TLS mutual authentication
and specifically refrains connection reuse for transports such as SIP over TCP and SCTP. There are
many situations, such as in Trust Domains <xref target="RFC3324"/>, where TLS mutual authentication
may not be required but where connection reuse is beneficial. This document specifies connection
reuse for SIP over connection-oriented transports such as TCP and SCTP. It specifies the same
mechanism for connection reuse as specified in <xref target="I-D.ietf-sip-connect-reuse"/>,
however, the solution is presented in the context of Trust Domains.</t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>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 <xref target="RFC2119"/>.</t>
<t>This document uses the concepts of Trust Domain and Spec(T), as specified
in section 2.3 of RFC 3324 <xref target="RFC3324"/>.</t>
<t>This document uses the same terminology as defined in section 1 of
<xref target="I-D.ietf-sip-connect-reuse"/>.</t>
</section>
<section title="Applicability Statement">
<t>This document describes a mechanism that allows two SIP entities separated
by a single hop that communicate over a connection-oriented transport protocol (e.g. TCP,
SCTP) to reuse a connection for SIP requests sent in both directions. Many existing SIP
implementations currently support this feature in their own proprietary ways. This document
standardizes a mechanism for SIP over TCP and SCTP connection reuse.</t>
<t>This document makes use of the same SIP extension for connection reuse
as the one specified in <xref target="I-D.ietf-sip-connect-reuse"/>, expect that the security
considerations in this document are different. This document assumes that the SIP entities
that make use of this mechanism are in a Trust Domain <xref target="RFC3324"/> or they have
mutually authenticated themselves through some other means. Therefore, unlike
<xref target="I-D.ietf-sip-connect-reuse"/>, this document does not mandate TLS mutual
authentication as a prerequisite for connection reuse.</t>
</section>
<section title="Introduction">
<t>The current Session Initiation Protocol (SIP) <xref target="RFC3261"/> specification
dictates that a transport layer connection can carry SIP requests in only one direction i.e.
from the client to the server. This characteristic of SIP presents scalability problems as
typically twice the number of connections are needed for each pair of SIP entities
that communicate with each other.</t>
<t>The client and server roles in SIP are transactional. Therefore, there is no
fundamental reason why SIP initiated connections cannot be reused for requests
in both directions. An existing internet-draft <xref target="I-D.ietf-sip-connect-reuse"/>
proposes a mechanism for reusing SIP over TLS connections. However, that
specification is predicated on secure TLS mutual authentication and specifically refrains
connection reuse for transports such as SIP over TCP and SCTP.</t>
<t>There are many situations, such as in Trust Domains <xref target="RFC3324"/>, where TLS
mutual authentication is not required but where connection reuse is beneficial.
This document enables connection reuse for SIP over TCP and SCTP transports.
This document uses the same SIP extension for connection reuse as in
<xref target="I-D.ietf-sip-connect-reuse"/> (the Via "alias" parameter), expect that
the security considerations in this document are different.</t>
<t>This document assumes that the SIP entities that make use of the mechanism
described here are in a Trust Domain <xref target="RFC3324"/> or they have mutually
authenticated themselves through some other means. Therefore, unlike
<xref target="I-D.ietf-sip-connect-reuse"/>, this document does not mandate TLS
mutual authentication as a prerequisite for connection reuse.</t>
<t>In the interest of avoiding duplication, this document only describes
its differences from the SIP over TLS connection reuse document
<xref target="I-D.ietf-sip-connect-reuse"/>. It frequently refers
to the sections of <xref target="I-D.ietf-sip-connect-reuse"/> wherever
there is commonality between the two documents.</t>
<t>Section 3 of <xref target="I-D.ietf-sip-connect-reuse"/> describes the
uni-directional nature of connections for SIP requests in the current SIP
specification and how their reuse is possible. That discussion also applies
to SIP over TCP and SCTP transports and therefore this document.</t>
</section>
<section title="Benefits of TCP, SCTP Connection Reuse">
<t>Section 4 of <xref target="I-D.ietf-sip-connect-reuse"/> describes the
benefits of TLS connection reuse. Many of the benefits of TLS connection reuse
also apply to TCP and SCTP connection reuse. Each new TCP connection requires
a 3-way handshake. Each new SCTP association requires a 4-way handshake.
These handshakes contribute to latency, post-dial delay, media clipping etc.
Section 4 of <xref target="I-D.ietf-sip-connect-reuse"/> describes scenarios such
as call flows involving frequent mid-dialog messages where connection reuse
proves highly advantageous.</t>
<t>Connections consume resources on both hosts that terminate a connection.
Connections require state management and periodic maintenance and therefore
consume computing resources on both ends. This presents scalability and
performance problems. Therefore, any technique that allows SIP entities to
conserve and reuse connections is beneficial.</t>
</section>
<section title="Overview of operation">
<t>Section 5 of <xref target="I-D.ietf-sip-connect-reuse"/> provides a tutorial
on the operation of SIP over TLS connection reuse. Almost all of the discussion
in that section including concepts such as the Via "alias" parameter, the columns
in the alias table, the way RFC 3263 rules are applied are also applicable to SIP
over TCP and SCTP connection reuse. The mention of TLS in the alias table
and Via header example should be replaced with TCP or SCTP. In addition, any steps
pertaining to X.509 certificate exchange should be ignored.</t>
</section>
<section title="Requirements">
<t>Section 6 of <xref target="I-D.ietf-sip-connect-reuse"/> lists various requirements
behind its proposed SIP over TLS connection reuse solution. All of those requirements
apply to SIP over TCP and SCTP connection reuse as well. This document imposes an
additional requirement:</t>
<t>1. The SIP entities that utilize the connection sharing mechanism MUST be members of
a Trust Domain, T, and must comply to its Spec(T), as defined in section 2.3 of
RFC 3324 <xref target="RFC3324"/>.</t>
</section>
<section title="Formal Syntax">
<t>Section 7 of <xref target="I-D.ietf-sip-connect-reuse"/> presents the formal syntax
of the Via header "alias" parameter. The SIP over TCP and SCTP connection reuse
mechanism uses the same parameter and the same formal definition.</t>
</section>
<section title="Normative Behavior">
<t>This section is largely a duplication of section 8 of
<xref target="I-D.ietf-sip-connect-reuse"/> except that all the normative text
surrounding TLS and X.509 certificate exchange has not been carried over.
Given that this section contains normative text, the authors felt that repetition
of text from section 8 of <xref target="I-D.ietf-sip-connect-reuse"/> is necessary. The
repetition is not verbatim, however. The text has been modified to reflect
SIP over TCP and SCTP connection reuse.</t>
<section title="Client Behavior">
<t>Clients SHOULD keep connections up as long as they are needed.
Connection reuse works best when the client and the server maintain
their connections for long periods of time. Clients, therefore,
SHOULD NOT automatically drop connections on completion of a
transaction or termination of a dialog.</t>
<t>The proposed mechanism uses the Via header field parameter specified in
<xref target="I-D.ietf-sip-connect-reuse"/>. The "alias" header field parameter is
included in a Via header field value to indicate that the client wants to
create a transport layer alias. The client places its advertised address
in the Via header field value (in the "sent-by" production).</t>
<t>If the client places an "alias" header field parameter in the topmost
Via header of the request, the client MUST keep the connection open
for as long as the resources on the host operating system allow it
to, and that the client MUST accept requests over this connection --
in addition to the default listening port -- from its downstream
peer. And furthermore, the client SHOULD reuse the connection when
subsequent requests in the same or different transactions are
destined to the same resolved address.</t>
<t>Whether or not to allow an aliased connection ultimately depends on
the recipient of the request; i.e., the client does not get any
confirmation that its downstream peer created the alias, or indeed
that it even supports this specification. Thus, clients MUST NOT
assume that the acceptance of a request by a server automatically
enables connection aliasing. Clients MUST continue receiving
requests on their default port.</t>
<t>The client MUST also populate the destination IP address,
port, and transport of the server in the alias table; these fields
are retrieved from executing RFC3263 server resolution process on the
next hop URI. And finally, the client MUST populate the alias
descriptor field with the connection handle (or identifier) used to
connect to the server.</t>
<t>Once the alias table has been updated with a resolved address, and
the client wants to send a new request in the direction of the
server, the client reuses the connection only if all of the following
conditions hold:</t>
<t> 1. The client uses the RFC3263 resolution on a URI and arrives at a
resolved address contained in the alias table, and</t>
<t> 2. The URI used for RFC3263 server resolution matches one of the
identities stored in the alias table row corresponding to that
resolved address.</t>
<t>Clients MUST be prepared for the case that the connection no longer
exists when they are ready to send a subsequent request over it. In
such a case, a new connection MUST be opened to the resolved address
and the alias table updated accordingly.</t>
<t>This behavior has an adverse side effect when a CANCEL request or an
ACK request for a non-2xx response is sent downstream. Normally,
these would be sent over the same connection that the INVITE request
was sent over. However, if between the sending of the INVITE request
and subsequent sending of the CANCEL request or ACK request to a non-
2xx response, the connection was reclaimed, then the client SHOULD
open a new connection to the resolved address and send the CANCEL
request or ACK request there instead. The client MAY insert the
newly opened connection into the alias table.</t>
</section>
<section title="Server Behavior">
<t>Servers SHOULD keep connections up unless they need to reclaim
resources. Connection reuse works best when the client and the
server maintain their connections for long periods of time. Servers,
therefore, SHOULD NOT automatically drop connections on completion of
a transaction or termination of a dialog.</t>
<t>When a server receives a request over TCP and SCTP whose topmost Via header
field contains an "alias" header field parameter, it signifies that
the upstream client will leave the connection open beyond the
transaction and dialog lifetime, and that subsequent transactions and
dialogs that are destined to a resolved address that matches the
identifiers in the advertised address in the topmost Via header field
can reuse this connection.</t>
<t>Whether or not to use in the reverse direction a connection marked
with the "alias" Via header field parameter ultimately depends on the
policies of the server. It can choose to honor it, and thereby send
subsequent requests over the aliased connection. If the server
chooses not to honor an aliased connection, the server MUST allow the
request to proceed as though the "alias" header field parameter was
not present in the topmost Via header.</t>
<t>This assures interoperability with <xref target="RFC3261"/> server
behavior. Clients can include the "alias" header field parameter without
fear that the server will reject the SIP request because of its
presence.</t>
<t>Servers MUST be prepared to deal with the case that the aliased
connection no longer exists when they are ready to send a subsequent
request over it. This can happen if the peer ran out of operating
system resources and had to close the connection. In such a case,
the server MUST open a new connection to the resolved address and the
alias table updated accordingly.</t>
<t>If the sent-by production of the Via header field contains a port,
the server MUST use it as a destination port. Otherwise the default
port is the destination port.</t>
<t>The server also populates the destination IP address, port and transport
in the alias table from the topmost Via header field (using the
";received" parameter for the destination IP address). If the port
number is omitted, a default port number of 5060 is to be used. And
finally, the server populates the alias descriptor field with the
connection handle (or identifier) used to accept the connection from
the client (see Section 5 for the contents of the alias table.)</t>
<t>Once the alias table has been updated, and the server wants to send a
request in the direction of the client, it reuses the connection only
if all of the following conditions hold:</t>
<t>1. The server, which acts as a client for this transaction, uses the
RFC3263 resolution process on a URI and arrives at a resolved
address contained in the alias table, and</t>
<t>2. The URI used for RFC3263 server resolution matches one of the
identities stored in the alias table row corresponding to that
resolved address.</t>
</section>
<section title="Closing a TCP or SCTP connection">
<t>Either the client or the server may terminate a TCP or SCTP connection.
Before closing a TCP or SCTP connection, the initiator of the closure
MUST either wait for any outstanding SIP transactions to complete, or
explicitly abandon them.</t>
<t>After one side has gracefully initiated connection termination (e.g. by
sending FIN message in TCP or SHUTDOWN message in SCTP), it MUST
discard any TCP or SCTP messages until it has received an acknowledgement
of the same from its peer. The receiver of the connection termination message
MUST NOT start any new SIP transactions after the receipt of that message.</t>
</section>
</section>
<section title="Security Considerations">
<t>This specification assumes that the entities that make use of the SIP connection
reuse mechanism described here are members of a Trust Domain, T, and they comply with
its Spec(T), as defined in section 2.3 of RFC 3324 <xref target="RFC3324"/>. Connection
reuse outside of a Trust Domain or between different Trust Domains is specified in SIP over
TLS connection reuse specification <xref target="I-D.ietf-sip-connect-reuse"/>.</t>
</section>
<section title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc3261;
<?rfc include="reference.I-D.ietf-sip-connect-reuse" ?>
</references>
<references title='Informational References'>
&rfc3324;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:58:00 |