Status of this Memo

By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668.

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 January 10, 2005.

Copyright Notice

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

This document provides guidelines for implementors using the transmission control protocol (TCP) in the Session Initiation Protocol (SIP). Although the discussions in this document pertain to TCP, the core ideas presented in the document should be applicable to any stream-oriented transport, including Transport Layer Security (TLS) over TCP and the Stream Control Transport Protocol (SCTP).

Table of Contents

1.  Introduction
2.  General guidelines
    2.1  Maintaining a cache
    2.2  When do connections become stale, or do they?
    2.3  Heuristics for determining candidate server side sockets for closing
    2.4  How to impart neediness of a connection
    2.5  Keeping a connection warm (or redundant connection to a proxy)
    2.6  Operating system specific information
3.  Guidelines for UAC to proxy connections
    3.1  UAC Behavior
    3.2  Proxy Behavior
4.  Guidelines for proxy to UAS connections
    4.1  Proxy Behavior
    4.2  UAS Behavior
5.  Guidelines for proxy to proxy connections
6.  Guidelines for UAC to UAS connections
7.  Guidelines for UAC to registrar connections
8.  Guidelines for UAC to redirect server connections
9.  Extensions to SIP
10.  Security considerations
11.  Acknowledgements
§.  Normative References
§.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1. Introduction

Re-using existing TCP connection between entities is not explicitly specified in the SIP specificationRosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, SIP: Session Initiation Protocol, June 2002.[1]. The specification recognizes that two communicating SIP entities (A and B) will have two independent (bi-directional) connections open between them. The first connection would be for requests going from A to B, and the second connection for requests from B to A. The connect-reuse draftMahy, R., Connection Reuse in the Session Initiation Protocol (SIP), August 2004.[2] attempts to mitigate this shortcoming by associating an 'alias' for a connection between A and B. Thus, when B receives a SIP request from A, it will create a mapping such that requests going to A re-use the same connection.

Both [1] and [2] recommend that connections be kept open for some period of time after the last message was exchanged over the connection; however, the exact time period to leave the connection open is implementation defined. This leads to implementations with different assumptions on how to treat the connection once a final response has been sent (or received). The authors' have witnessed implementations that immediately close the connection after sending a response and others that actually open a new TCP connection to send a provisional response. Multiple choices lead to ambiguity in interoperability. An example illustrates the problems inherent in a UAS rapidly closing connections after sending a response

Consider the following time line flow:

UAC                UAS (REGISTRAR)
1 |----------SYN---------->|
2 |<-------SYN/ACK---------|
3 |----------ACK---------->|
4 |--------REGISTER------->|
5 |<---------401-----------|
6 |-REGISTER->   <-FIN/ACK-|
7 |<-FIN/ACK-   -REGISTER->|
8 |----------ACK---------->|
9 |<-------FIN/ACK---------|
10|<---------ACK-----------|

Figure 1: Race condition.

Sometime (a short interval) after sending a 401, the UAS closes the TCP connection, generating a FIN which is on its way to the UAC (step 6). At the same time, the UAC issues a new REGISTER request with a response to the challenge and send it on the same TCP connection. A race condition ensues. This could have been avoided by better guidelines on connection management.

As it turns out, the amount of time a connection is left open will vary greatly between a UA and a proxy. A fixed (location-wise) UA using a default outbound proxy can leave the connection open forever, or until the proxy closes it. Traffic to and from the proxy must occur on that connection. On the other hand, a mobile UA will not be able to do leave a connection open. Likewise, two proxies in a high traffic throughput peering relationship will benefit from a long lived connection, whereas a proxy whose traffic patterns dictate that it contact many downstream entities will need to maintain a shorter life of a TCP connection.

References [1] and [2] do not address two aspects of connections: neediness and connection duration. Neediness can best be explained by an example: a UA behind a Network Address Traversal (NAT) device would like to keep a NAT-negotiated connection open for a long duration. Even when it uses the procedure outlined in [2], it is left upto its peer on if it will honor the alias and send requests going in the opposite direction (i.e. headed towards the UA behind the NAT) through the open connection.

Oftentimes, it may be advantageous for both the SIP entities to agree on a connection duration, after which it becomes stale and may be closed by either of the entities. A duration is useful in cases where a proxy farm is being used for a DNS-based load balancing (round robin DNS, for example). In such a case, an upstream element wanting to send a request to the proxy farm will use an existing connection if it is not stale and query DNS only when the connection becomes stale. Possible ways to mitigate neediness and connection duration are are presented in the persistent-conn-reqsJain, R. and V. Gurbani, Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP), May 2004.[3] draft.

And finally, existing literature on SIP connection reuse [1,2,3] does not provide any prorgammatic tricks, techniques, or heuristics on how to consider connections stale, how to build SIP proxies that support a large number of connections, what does the proxy or UA do when it detects a broken connection, what does a proxy do when it runs out of connections (clearly, it should now start closing stale connections to reclaim resources, which brings us back to when does a connection become stale), etc.

There, thus, exists a need for a document to serve as a guideline for developers to reference while using connection-oriented transports. We hope that this document serves as such a guideline. We will address the issues we have faced while constructing SIP entities that use connection- oriented transports. We also recognize that some of the issues may be best served by extensions to the SIP protocol; however, it is fairly pre-mature to quantify such extensions as yet. The analysis and discussions presented in this draft will better guide us to a solution which may require an extension.

The issues can be broadly classified into six profiles

1. Communications between an UAC and a proxy
2. Communications between a proxy and an UAS
3. Communications between a proxy and another proxy
4. Direct communications between an UAC and an UAS
5. Communications between a UAC and a registrar
6. Communications between a UAC and a redirect server

The guidelines for behavior with respect to connection management is different for each classification. In the rest of this document, we first provide general guidelines for connection oriented transports and then look into the specific profiles identified above.

2. General guidelines

2.1 Maintaining a cache

In order to reuse TCP connections, UACs and proxies maintain a cache. The cache is populated by UACs (including the UAC half of a proxy) based on the result of DNS lookups as specified in RFC 3263Rosenberg, J. and H. Schulzrinne, Session Initiation Protocol (SIP): Locating SIP Servers, June 2002.[4]. Once a downstream destination has been identified and the IP address/port combination is obtained, the UAC MUST check the cache to determine if an existing connection to the downstream host is available; if so, the existing connection MUST be used. If the check fails, the UAC establishes a connection with the downstream UAS and caches the connection information. As an added optimization, a UAS-half of a proxy sending a response upstream over a connection- oriented transport and finding the connection stale, will open a new connection to the host identified in the topmost Via. This connection MAY be cached for future use as well.

The cache may be indexed by the server's IP address and port number. Other ancillary information that an implementation may find useful may be saved for the connection; this includes the connection creation timestamp, timestamp when the last activity occurred on the connection, or a reference count of how many times the connection has been used.

Clearly, the entries in the cache need to be periodically reclaimed to preserve operating resources (file descriptors, buffers, etc.). Strategies to expire the entries in the cache are implementation dependent. Some strategies that may be used include expiring least recently used (LRU) connections or expiring the connection with the earliest timestamp (note that the LRU connection may not be the same with the earliest timestamp). See discussion in Section 2.3 for some more heuristics.

2.2 When do connections become stale, or do they?

A connection is considered stale when the metric that a particular implementation uses to determine the validity of the connection indicates so. Based on the discussion in the previous section, this could be the LRU timestamp or the timestamp when a connection was created. Implementations are free to define and save implementation-specific metrics to aid in the determination of connection staleness. This draft does not recommend any specific metrics (NOTE: should we?).

A connection is also considered stale if the underlying TCP state machine is not in a connected mode when an attempt is made to use that connection (i.e. the peer closed its end of the connection). In such a case, the remaining peer MUST close the connection to reclaim resources and remove the connection tuple from the cache.

2.3 Heuristics for determining candidate server side sockets for closing

Section 2.1 provided some heuristics for determining candidate connections that can be closed. However, note that this determination is implementation dependent and many factors can be considered besides LRU and earliest-timestamp-first. For instance, if a connection has been setup for emergency calls, it must be maintained even though minimal traffic has utilizied it and it has been open for a long time. Likewise, the imposition of NATs and firewalls may argue that a connection, once opened, remains so until explicitly closed. An implementation must take into consideration such heuristics which are appropriate for its proper functioning in order to arrive at a sufficient metric for connection expiration.

Additionally, parties that have negotiated TLS ciphers and authentication tokens between themselves would, in all probability, like to keep the connection open for as long as possible. Thus, another heuristic could be the nature (i.e. TLS over TCP) of the TCP connection.

And finally, it could be that a heirarchy of heuristics is needed instead of just one rule of thumb. The heirarchy may dictate that LRU connections be reclaimed first, followed by those connections which have been opened for a long time and do not require the use of emergency called routing, followed by TLS connections, and so on.

2.4 How to impart neediness of a connection

To fill in. Point to consider: a UAC behind a firewall may want to tell the SIP peer beyond the firewall to not close the connection after the transaction is over, but instead, keep it open for as long as possible.

2.5 Keeping a connection warm (or redundant connection to a proxy)

To fill in. Some points to consider: use the SO_KEEPALIVE option on the socket or an application layer mechainsm (say, sending a CRLF every so often). Many problems with SO_KEEPALIVE mechanism: long time out; to the order of two hours. On some systems, the keep alives may impact all sockets, not just the one on which it was set. And finally, the SO_KEEPALIVE mechanism may inadverdently indicate a lost peer if there was a router or routing-related problem in the network, irrespective of the health of the communicating entities themselves.

For an application-based solution, one or both of the communicating entities will send CRLF over the socket after a random interval. While it is possible for only one entity to send a CRLF, having both entities do so allows the surviving entity to reclaim socket resources when its peer goes down without any notification (for example, a UAC running on a personal computer simply vanished because the computer crashed or was abruptly powered down; in this scenario, the normal TCP FIN will not occur. Thus the surviving entity will think the socket is still connected. If the surviving entity is a proxy, it may be important to reclaim socket resources as soon as a peer vanishes).

Note that some SIP phones already keep a connection warm by sending empty packets (CRLF) to the SIP ports.

2.6 Operating system specific information

To fill in. Some points to consider: Use of select() versus /dev/poll; TCP tuning - which TCP parameters, if any, can be tuned programmatically, ...

3. Guidelines for UAC to proxy connections

A UAC wishing to send and receive SIP signaling to a proxy server using TCP has to create and manage a connection. The 'Connection re-use draft[2]Mahy, R., Connection Reuse in the Session Initiation Protocol (SIP), August 2004.' provides guidelines specifying that, once created, not only should TCP connections be used for SIP transactional exchanges (including both request and response), they should also be used for subsequent SIP request/response exchanges. This includes bi-directional SIP transactions initiated by either SIP element involved in the TCP connection. It is not restricted to the initiating UAC but also covers subsequent dialogs initiated in the opposite direction. See connection re-use draft[2]Mahy, R., Connection Reuse in the Session Initiation Protocol (SIP), August 2004. for more information regarding re-use of TCP connections for SIP dialogs using a previously created TCP socket.

The primary focus of this section is to provide guidelines for management of TCP connections from a User Agent Client (UAC) to Proxy Server connection. The procedures outlined in this document vastly improve the resource management of TCP connections and also help network architectures that are required to traverse non-SIP aware Network Address Translators (NAT) and firewalls.

3.1 UAC Behavior

On constructing a SIP request that is to be sent to a proxy server using TCP, a UAC will determine a remote destination IP address and port from the SIP message. This information will either be deduced explicitly or derived by performing DNS queries, as detailed in RFC 3263Rosenberg, J. and H. Schulzrinne, Session Initiation Protocol (SIP): Locating SIP Servers, June 2002.[4]. Once an IP address and port have been identified, the UAC MUST check the cache for an existing connection. If an existing connection exists and is still in a connected state (i.e. not stale), it MUST be used for transporting the SIP request.

If an existing connection does not exist, the UAC will open and use a new TCP connection to the proxy server for transporting the SIP request. It MAY save the connection in the cache. Once the SIP transaction is complete, a UAC MAY choose not to close the connection. The connection MAY remain 'open' for the duration of the UAC instance and be available for use by subsequent request/response exchanges, including those received in the reverse direction, as specified in the 'connection re-use[2]Mahy, R., Connection Reuse in the Session Initiation Protocol (SIP), August 2004.' draft.

Guidelines for negotiating a persistent connection between SIP entities can be found in the 'Persistent Connection Management [3]Jain, R. and V. Gurbani, Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP), May 2004.' draft. A UAC adhering to the guidelines discussed in this specification MAY be required, during it's life-cycle, to reclaim TCP connection resources if demand exists. The method a UAC uses to 'close' and reclaim TCP connection resources are subject to local policy, as discussed earlier. The connection resource associated with the previously identified connection SHOULD be reclaimed and re-used for the new connection.

3.2 Proxy Behavior

A SIP proxy server listens for, and receives incoming connections from clients, which can either be UACs or other proxies. SIP transactional responses will use the same connection created for the incoming request, as specified in RFC 3261Rosenberg, J. and H. Schulzrinne, Session Initiation Protocol (SIP): Locating SIP Servers, June 2002.[4]. On completion of a SIP transaction exchange, the proxy server SHOULD NOT close the connection, and it SHOULD keep the connection 'open' for the duration of the Proxy Server instance. This connection would then be available for use by subsequent request/response exchanges, including those sent in the reverse direction as specified in the 'connection re-use[2]Mahy, R., Connection Reuse in the Session Initiation Protocol (SIP), August 2004.' draft. Guidelines for negotiating a persistent connection between SIP entities can be found in the 'Persistent Connection Management [3]Jain, R. and V. Gurbani, Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP), May 2004.' draft. A Proxy Server adhering to the guidelines discussed in this specification MAY be required, during it's life-cycle, to reclaim TCP connection resources if demand exists. The method a Proxy Server uses to 'close' and reclaim TCP connection resources is subject to local policy, as discussed earlier. The connection resource associated with the selected connection SHOULD be reclaimed and re-used by the new connection.

The 'Persistent Connection Management [3]Jain, R. and V. Gurbani, Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP), May 2004.' draft also includes a mechanism that allows Proxy Servers to negotiate a heart beat mechanism with the client that can detect client failure at the other end of a connection. Connections identified as being failed MUST be recalimed and returned to the pool of available connection resources.

In the interest of minimizing the delay it takes to set up and tear down a session between two user agents, it is RECOMMENDED that proxies keep connections open to their upstream UACs beyond the initial transaction that establishes the session. SIP makes it possible that a proxy may not be involved in subsequent signaling once a session is set up, nonetheless, if the proxy is involved, subsequent messages will experience less delay if the connection is already set up. Proxies, as SIP intermediaries, should be more resilient and fast in comparison to the UAC, which may only be serving one user and thus can absorb session setup and teardown delays exhibited by establishing new connections.

4. Guidelines for proxy to UAS connections

On receivnig a SIP request, a Proxy Server might be responsible for routing the SIP message to a specified downstream destination which can either be a Proxy Server or a UAS. This section will specifically detail guidelines for the Proxy Server to UAS scenario using a reliable transport protocol such as TCP.

4.1 Proxy Behavior

When a Proxy Server is connecting to a UAS it can be seen as acting in the role of a client. The guidelines in this sction are similar to those specified in section 3.1 for a UAC.

On constructing a SIP request that is to be sent to a UAS using TCP, a Proxy Server will determine a remote destination IP address and port from the SIP message. This information will either be deduced explicitly or derived by performing DNS queries, as detailed in RFC 3263Rosenberg, J. and H. Schulzrinne, Session Initiation Protocol (SIP): Locating SIP Servers, June 2002.[4]. Once an IP address and port have been identified, the proxy MUST check the cache for an existing connection. If an existing connection exists and is still in a connected state (i.e. not stale), it MUST be used for transporting the SIP request.

If an existing connection does not exist, the Proxy Server will open and use a new TCP connection to the UAS for transporting the SIP request. It SHOULD save the connection in the cache for subsequent use. Once the SIP transaction is complete, a Proxy Server SHOULD NOT close the connection. The connection SHOULD remain 'open' for the duration of the Proxy Server instance and be available for use by subsequent request/response exchanges, including those received in the reverse direction, as specified in the connection re-use [2]Mahy, R., Connection Reuse in the Session Initiation Protocol (SIP), August 2004. draft.

Guidelines for negotiating a persistent connection between SIP entities can be found in the Persistent Connection Management[3]Jain, R. and V. Gurbani, Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP), May 2004. draft. A Proxy Server adhering to the guidelines discussed in this specification MAY be required, during it's life-cycle, to reclaim TCP connection resources if demand exists. The method a Proxy Server uses to 'close' and reclaim TCP connection resources are subject to local policy, as discussed earlier. The connection resource associated with the previously identified connection MUST be reclaimed and re-used by the new connection. The 'Persistent Connection Management [3]Jain, R. and V. Gurbani, Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP), May 2004.' draft also includes a mechanism that allows Proxy Servers to negotiate a heart beat mechanism with the client that can detect client failure at the other end of a connection. Connections identified as being failed MUST be recalimed and returned to the pool of available connection resources.

In the interest of minimizing the delay it takes to set up and tear down a session between two user agents, it is RECOMMENDED that proxies keep connections open to their downstream UASs beyond the initial transaction that establishes the session. SIP makes it possible that a proxy may not be involved in subsequent signaling once a session is set up, nonetheless, if the proxy is involved, subsequent messages will experience less delay if the connection is already set up. Proxies, as SIP intermediaries, should be more resilient and fast in comparison to the UAS, which may only be serving one user and thus can absorb session setup and teardown delays exhibited by establishing new connections.

4.2 UAS Behavior

A SIP UAS listens for, and receives incoming connections from clients, which can either be UACs or other proxies. SIP transactional responses will use the same connection created for the incoming request, as specified in RFC3261[1]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, SIP: Session Initiation Protocol, June 2002.. On completion of a SIP transaction exchange, the UAS MAY choose to not close the connection, and it MAY keep the connection 'open' for the duration of the UAS instance. This connection would then be available for use by subsequent request/response exchanges, including those sent in the reverse direction as specified in the 'connection re-use[2]Mahy, R., Connection Reuse in the Session Initiation Protocol (SIP), August 2004.' draft. Guidelines for negotiating a persistent connection between SIP entities can be found in the 'Persistent Connection Management[3]Jain, R. and V. Gurbani, Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP), May 2004.' draft. A UAS adhering to the guidelines discussed in this specification MAY be required, during it's life-cycle, to reclaim TCP connection resources if demand exists. The method a UAS uses to 'close' and reclaim TCP connection resources is subject to local policy, as discussed earlier. The connection resource associated with the selected connection SHOULD be reclaimed and re-used for the new connection.

5. Guidelines for proxy to proxy connections

To fill in. Some points to consider: if this is a heavily used connection, it should be kept open as long as possible. Subsequent messages between these proxies must be sent over this connection.

6. Guidelines for UAC to UAS connections

To fill in

7. Guidelines for UAC to registrar connections

To fill in

8. Guidelines for UAC to redirect server connections

To fill in

9. Extensions to SIP

To fill in

10. Security considerations

To fill in

11. Acknowledgements

The race condition presented in Figure 1 was documented by Yosuke Itoh <itoh.yosuke@lab.ntt.co.jp>.

12. References

12.1 Normative References

12.2 Informative References

Authors' Addresses

Intellectual Property Statement

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.

Disclaimer of Validity

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.

Copyright Statement

Copyright (C) The Internet Society (2004). 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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.