INTERNET-DRAFT SIPPING WG November 2003 Rajnish Jain Expires: May 2004 Vijay K. Gurbani Lucent Technologies Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP) draft-jain-sipping-persistent-conn-reqs-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 in May 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Jain Expires - May 2004 [Page 1] Internet-Draft Persistent Connection Reqs November 2003 Abstract SIP over connection-oriented transport protocol based systems are likely to face certain distinct performance and behavioral issues that are not manifest when SIP is transported over connectionless protocols. Allowing SIP entities to mutually conserve connections over a predictable, extended period of time is one of the leading requirements to help SIP entities deliver their optimal performance in the network. Overall, this document contemplates transport layer connection management issues relating to SIP. Requirements and potential solutions for introducing a backward compatible notion of persistent connections in SIP are presented. Applicability Statement The means and procedures described in this Internet-Draft are most applicable in scenarios where there is a high volume of signaling traffic between two SIP entities, or the need to maintain a long-term trusted, peering relationship between them. Examples of such scenarios are much-used signaling paths between two proxies belonging to different service providers, or the signaling path between a SIP User Agent Client (UAC) and its default outbound proxy. Table of Contents 1. Conventions used in this document.............................3 2. Introduction..................................................3 3. Connection utilization aspects of SIP RFC 3261 [1]............4 4. Connection utilization aspects of connect-reuse draft[2]......6 5. SIP Transport Layer Connection Management.....................7 6. Advantages of Persistent Connections.........................10 6.1 Performance Efficiency...................................10 6.2 Resources Efficiency.....................................10 6.3 Application Behavior Enabling............................10 7. Requirements.................................................11 8. Proposed Solutions...........................................11 8.1 New Via header field parameter...........................12 8.2 New SIP header...........................................12 8.3 New transport token......................................13 9. Security Considerations......................................13 10. IANA Considerations.........................................14 11. Acknowledgements............................................14 Jain Expires - May 2004 [Page 2] Internet-Draft Persistent Connection Reqs November 2003 1. Conventions used in this document 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[2] and indicate requirement levels for compliant SIP implementations. 2. Introduction SIP [1] being an application layer protocol is stacked above the transport layer in the Internet Protocol model. Although SIP tends to be loosely coupled with transport layer, certain aspects of SIP entities are somewhat influenced by (or can benefit from) the workings of vastly diverse transport layer protocols. For instance, connection-oriented transport protocols (such as TCP, SCTP, and TLS over TCP) demand more systemic resources and introduce latencies to provide their salient features in contrast with their connectionless counterparts (such as UDP). As a result, the dynamics of a connection oriented transport protocol are likely to produce somewhat of a ripple effect on the entire SIP entity. Evidently, in order to minimize the negative performance and scaling impact caused by excessive connections, SIP implementers may benefit from standardized mechanisms to expend connections cautiously. In general, SIP is currently quite liberal in setting up and tearing down transport layer connections. Per [1], transport layer connections should be opened, closed, and recycled at the discretion of individual implementations. To prevent lingering of low traffic connections, section 18 of [1] guides implementers to close connections after an implementation-defined amount of idle time. Depending on the interpretation of [1] by the implementer, the idle time can range from 32s (T1*64) to infinity (thereby keeping the connection open forever; however, there are problems with this interpretation of "infinity", as will be discussed later). In a multi-vendor SIP network, diverse SIP entities will thus vastly differ in their discretion of connection idle timeout periods and connection reuse policies. Such discrepancies will manifest themselves into inter-operability chaos and inefficient network performance. The connect-reuse Internet-Draft[2] presents a few scenarios where performance degradation is evident. Typically, connections between SIP entities frequently age out due to sporadic traffic patterns, if they are maintained at all beyond a transaction’s lifetime. Connections are always deemed ephemeral in nature and are shut down without any consensus Jain Expires - May 2004 [Page 3] Internet-Draft Persistent Connection Reqs November 2003 between interacting SIP entities. To that end, several opportunities are missed where SIP entities would best serve the network if they communicate over persistent connections that are setup and torn down predictably. Unfortunately, connections are currently torn down by either side due to lack of communication of such intent from one entity to another using a SIP construct. The need for persistent connections has been recognized by other IETF protocols as well. The HTTP protocol provides a good foundation for the need for persistent connections (see section 8.1 of [5]). In fact, an argument can be made that in HTTP, once the client has downloaded a page with inline images and other associated data from a server, subsequent requests may not go back to the same server. This is not true in SIP, where once a client has established a dialog with a server, subsequent requests always go to the same server (or an intermediary proxy if the proxy Record-Route’d or is the default outbound proxy). Thus it appears that just as HTTP benefited from persistent connections, so can SIP. 3. Connection utilization aspects of SIP RFC 3261 [1] SIP currently supports a few scenarios that facilitate connection conservation. Figure 1. below shows a typical SIP trapezoid arrangement with end-points Ea and Eb and their default out-bound proxy servers Pa and Pb, respectively. --Ca2b--> Pa . . . . . .Pb . . . . Ea . . . . . . . . . Eb Figure 1: Typical SIP trapezoid. For illustration purpose it is assumed that Pa and Pb are in a peering relationship and communicate over a connection-oriented transport protocol. The call flow begins with Pa receiving an INVITE from Ea (for Eb). As a result, Pa originates a transport layer connection to Pb called Ca2b and puts call request to Pb over that connection. Per SIP [1], the following message exchanges will likely recycle connection Ca2b further down the call flow: 1. Responses from Pb to Pa 2. New requests from Pa to Pb Jain Expires - May 2004 [Page 4] Internet-Draft Persistent Connection Reqs November 2003 It is worth noting that new requests from Pa to Pb will have the opportunity to recycle connection Ca2b, only if the connection is found active at the time new requests arrive. If there is a significant time gap between two requests from Pa to Pb, it is likely that connection Ca2b would age out and be closed before the later request arrives. In this case, a new request from Pa to Pb will have to trigger a new connection. This problem can be alleviated by making Pa’s implementation-defined timer substantially large. However, that approach manifests a bigger scaling issue, as Pa would then tend to exhibit that behavior universally with every SIP entity (including end-points) it initiates a connection to. Furthermore, Pa and Pb may vastly differ in their discretion of transport layer idle timeouts. Assuming that Pa tends to be “liberal” (smaller timeout) and Pb “conservative” (larger timeout), when it comes to cycling through transport connections, Pa can swamp Pb with transport layer connection setup and tear down requests. This may negatively influence overall functioning of Pb. Likewise, numerous under utilized lingering connections may lend themselves to scaling and performance issues. Therefore, some technique is required for selectively making the implementation-defined timer large on a per entity pair relationship basis. Apart from transactions from Pa to Pb, new transactions initiated from Pb to Pa are most unlikely to recycle connection Ca2b despite of it being active. The reason is that normally SIP treats connections as ephemeral, as indicated in the following text from section 18 of [1]: “Note that, because the source port is often ephemeral, but it cannot be known whether it is ephemeral or selected through procedures in [4], connections accepted by the transport layer will frequently not be reused. The result is that two proxies in a "peering" relationship using a connection-oriented transport frequently will have two connections in use, one for transactions initiated in each direction.” Given the method described in [1], proxy server Pb is faced with two subtly distinct dilemmas in recycling connection Ca2b. Firstly, Pb cannot rely on the availability of the Ca2b connection for a required time period as the connection was originally created by Pa, and therefore can be preempted (torn down) by Pa at Pa’s own discretion. Pb has no idea whether Pa’s Ca2b connection is meant to be persistent or ephemeral. Giving the benefit of doubt to the ephemeral case, Pb will be unable to recycle connection Ca2b for transporting its transactions to Pa (unless the implementer is willing to take the risk of mid- transaction connection closure and handle consequences thereafter). Jain Expires - May 2004 [Page 5] Internet-Draft Persistent Connection Reqs November 2003 Secondly, Pb has no way to know from Pa if it is welcome to (or forced to) use the Ca2b connection for requests from Pb to Pa. It is quite likely that an implementation of Pa may not be set up to accept new requests within an existing dialog on any other port than the standard SIP port numbers (5060 for UDP, TCP and SCTP, 5061 for TLS over TCP, or TLS over SCTP). If Pb were to use the Ca2b connection for requests to Pa, the requests will arrive at Pa’s source port for Ca2b connection, which may not necessarily be a standard SIP port number. Given that [1] does not provide a way for Pa and Pb to communicate their connection usage methods, Pb will most likely originate a new transport layer connection to Pa called Cb2a for transport of Pb to Pa transactions. Figure 2 below shows simultaneous existence of Ca2b and Cb2a connections. --Ca2b--> Pa . . . . . .Pb . <--Cb2a-- . . . Ea . . . . . . . . . Eb Figure 2. Two connections for SIP messages. 4. Connection utilization aspects of connect-reuse draft[2] Quite likely, the Cb2a connection, as mentioned in previous section, is unnecessary when Ca2b connection is active. Reference [2] acknowledges this issue. It presents requirements and proposes a mechanism for Ca2b connection reuse for transactions initiated from Pb to Pa. It recommends that a new Via header field parameter (called “alias”) be added in a request from Pa to Pb, to imply that Pb is allowed to (and should) reuse the Ca2b connection. The technique presented in [2] is quite efficient and flexible in eliminating the need for a Cb2a connection when Ca2b connection is active. However, the technique tends to solve only the second dilemma mentioned in section 3. While it enables Pa to tell Pb that Pb is welcome to (and perhaps should) use the Ca2b connection for Pb to Pa requests, it leaves out the connection longevity aspect. Pb, under conformance to [2], still cannot rely on the availability of Ca2b connection for a required time period. Furthermore, the technique presented in [2] ignores a potential hint/forced aspect for connection reuse request. That is, does Pa simply desire a connection reuse or absolutely require it when it Jain Expires - May 2004 [Page 6] Internet-Draft Persistent Connection Reqs November 2003 puts out the “alias” field in the Via header. On one hand, Pa may want to hint Pb to reuse Ca2b connection (for performance optimization e.g.). In this scenario Pb can somewhat leverage its’ own judgment to honor or deny the request. On other hand, Pa may want to force request Pb to reuse Ca2b connection (when Pa is behind a NAT e.g.). A forced request may not guarantee that a persistent connection will be granted. However, any notion and/or vocabuluary for indicating hint/forced request would likely be useful. Evidently, a scheme that allows SIP entities to communicate their transport layer connection reuse policy (including longevity and hint/forced aspects) with each other is necessary. Such a scheme would not only allow SIP implementations to cautiously expend transport layer connections to provide optimal performance, but also accomplish certain application layer requirements. Accordingly, this draft goes beyond [2] and presents requirements and proposals for introducing needful vocabulary in SIP the management of persistent transport layer connections. 5. SIP Transport Layer Connection Management Management of transport layer connections can be premised on diverse stimuli and policies. Typically such discretions arise from SIP traffic profiles, SIP entity relationships, application behaviors, underlying platform support, etc. For instance, two high throughput proxy servers in a peering relationship will greatly benefit if they cautiously conserve intermediary connections. Whereas, a SIP phone that occasionally places or receives call is perhaps best suited to liberally expend connections. The tradeoff between expending new connections versus persisting and resusing connections will likely be driven by the utilization rate of the connections. In connection-oriented transport layer protocols, a connection instance is somewhat mutually owned by both client and server sides. Both sides commit their resources and maintain per connection finite state machines. Therefore, broadly speaking, connection management should be considered and allowed to be a cooperative onus of the connected entities. Application entities on the two sides of a connection should be allowed to communicate their connection management information of mutual interest over an application layer protocol. In SIP based networks with diverse SIP entities, the connection management behaviors cannot be base- lined; however, given that the roles of SIP entities are well defined, a few broad classes of connection management can be defined that represent every SIP entity in the network. Jain Expires - May 2004 [Page 7] Internet-Draft Persistent Connection Reqs November 2003 Based on SIP traffic profiles and application behaviors, diverse requirements for connection management are expected to fall into the following three classes: 1. Uni-directional ephemeral connections 2. Bi-directional ephemeral connections 3. Persistent connections Uni-directional ephemeral connections carry transactions initiated by one side only (the side that actively sought out the connection). They age out at the isolated discretion of individual implementations. Typically, connections that become idle for an implementation-defined period of time are closed. Either party is allowed to close such type of connections once a transaction has completed and another one is not in progress. Choosing a large connection idle time period on the originator side alone does not guarantee that these connections will be long-lived. Accordingly, SIP entities should inherently assume these connections to be ephemeral in nature. These are essentially the type of connections described in section 18 of [1]. Connections Ca2b and Cb2a in figure 2 of this draft are unidirectional ephemeral connections. Bi-directional ephemeral connections carry transactions initiated by both sides. These connections further leverage upon the fact that at the transport layer, connections are inherently unbiased (peer-to-peer) during data transfer phase. These connections (also) age out at the isolated discretion of individual implementations. Typically, connections that become idle for an implementation-defined period of time are closed. Either party is allowed to close such type of connections once a transaction has completed and another one is not in progress. Choosing a large connection idle time period on one side alone does not guarantee that these connections will be long-lived. Since SIP does not allow peering entities to communicate their connection idle time periods, each SIP entity should, therefore, inherently assume these connections to be ephemeral in nature. These are essentially the “alias” parameter driven connections described in [2]. Bi-directional ephemeral connections essentially start out as uni-directional connections, but on solicitation from the original uni-directional side to another they become bi- directional. Bi-directional connections do not occur automatically. They arise from a 2-way handshake, such that they are firstly solicited by one side and succeed upon acceptance from the other side. For instance, in the Pa/Pb example, Pb should not generally deem Ca2b connection bi-directional unless Pa requests it. Upon request, Pb is allowed to accept or deny the Jain Expires - May 2004 [Page 8] Internet-Draft Persistent Connection Reqs November 2003 request to reuse the connection. Figure 3 below shows a bi- directional ephemeral connection between Pa and Pb called Ca+b. <-Ca+b-> Pa . . . . . .Pb . . . . Ea . . . . . . . . . Eb Figure 3. Bi-directional ephemeral connections. Persistent connections, in contrast with ephemeral connections, do not age out due to connection idle timeouts typically caused by sporadic SIP traffic patterns. Persistent connections are driven by the application logic above SIP and therefore are most predictable. Once established between two SIP entities as a result of a dialog-initiating transaction, these connections persist beyond the transaction's lifetime, and in fact, even beyond the dialog's lifetime. Their closure may be expected (scheduled downtime, TLS certificate expiration) or unexpected (system crash), however, the remaining peer should construe any such closure as an indication to release resources on its side of the connection. Neither side explicitly closes these connections under normal circumstances. These connections are expected to endure regardless of SIP message traffic patterns. Their typical usage would be between two SIP entities that are kind of “hard wired” together based on the network architecture. Figure 4 below shows a persistent connection between Pa and Pb called Ca&b. <-Ca&b-> Pa . . . . . .Pb . . . . Ea . . . . . . . . . Eb Figure 4. Persistent Connections. Note: Is there any need to further sub-divide persistent connections into 2: uni-directional persistent connections and bi-directional persistent connections? As a prelude to a discussion, consider that a TCP socket, once opened, is bi- directional. Thus, it would seem appropriate to carry over the same semantics to a persistent connection. On the other hand, certain SIP clients may want to assure the downstream server that they will keep the connection persistent and not close it down after the transaction is over (uni-directional persistent), but Jain Expires - May 2004 [Page 9] Internet-Draft Persistent Connection Reqs November 2003 if the downstream entity wants to send a new request, it can open up a new uni-directional persistent connection on its own, which will be honored. 6. Advantages of Persistent Connections Persistent connections can potentially be advantageous in many ways. This section presents some of their evident advantages. 6.1 Performance Efficiency As mentioned earlier, connection establishment takes time, contributes extra RTTs, and is subject to slow-start. TCP itself requires a 3-way handshake to agree on window sizes and sequence numbers before the first byte of payload data is exchanged between peers. TLS over TCP endures an even longer delay as both parties are authenticated. Such delays can vary from being mildly irritable to causing signaling and media to become out of lockstep (for example, subjecting a re-INVITE putting media on hold to re-establish credentials between two or more intervening proxies can add several round-trip times between the time a user presses the "Hold" button to when the media is actually put on hold). A persistent connection between signaling entities along the path would alleviate the need to establish a new ephemeral connection for such services. 6.2 Resources Efficiency Every connection entails precious system resources. Each time a socket is opened between peers, the hosts allocate control blocks, buffers, descriptors and other resources in the kernel for the subsequent exchange of data. Simultaneously, implementation of TCP and SCTP layers instantiate and maintain per connection finite state machines. Every active connection entails processor cycles for connection state management for maintaing timers etc. Additionally, connections closed by application layer linger in TIME-WAIT state in transport layer, and therefore consume resources. As the number of simultaneously active connections rise, so does the burden on the transport layer and therefore the entire entity. It would appear that in peering arrangements (or in cases of a UAC and its default outbound proxy), these machinations could be avoided since the intent is to reuse the connection between the peers. 6.3 Application Behavior Enabling Apart from facilitating efficiencies, persistent connections can possibly enable certain application behaviors. For instance, if Pa is behind a NAT, persistent connections (or even bi- Jain Expires - May 2004 [Page 10] Internet-Draft Persistent Connection Reqs November 2003 directional ephemeral connections) allow Pb to place calls to Pa on the connection established by Pa. Additionally, active persistent connections allow SIP entities to somewhat rely on up-and-running state of their peers and relative prompt delivery of messages. This aspect can be considered by a SIP entity that intends to route an emergency call. Evidently, preference can be given to active persistent connections among other alternatives that all lead to the intended destination. Upon realizing graceless closure of a persistent connection, a SIP entity can perhaps take certain proactive measures. For instance, ingress calls arriving during new connection establishment phase can promptly be egressed via other paths allowed by the network. 7. Requirements The following items present requirements on the SIP protocol for connection management between two interacting SIP entities: 1. The mechanism provided for persistent connection management should accommodate needs for diverse kinds of SIP entities. 2. The mechanism provided should allow SIP entities to utilize persistent connections at their own discretion. 3. The mechanism provided should allow SIP entities to manage connections in consultation with their peers. 4. The mechanism provided should allow SIP entities to request unidirectional ephemeral, bi-directional ephemeral or persistent connections. 5. The mechanism provided should prevent a SIP entity that liberally expends connections from swamping another peer entity. 6. The mechanism provided should be such that a SIP entity that supports this Internet-Draft automatically honors requests from entities supporting [2] and [1]. 8. Proposed Solutions This section presents three potential solutions to connection management information exchange between two SIP entities. The intent is to have one solution; however, such a solution would Jain Expires - May 2004 [Page 11] Internet-Draft Persistent Connection Reqs November 2003 benefit from a discussion involving a larger audience as represented by the IETF SIPPING WG. 8.1 New Via header field parameter The first solution is to extend the via-params parameter of the Via header as follows: via-params = via-ttl / via-maddr / via-received / via-branch / via-connection via-connection = "persistent" The advantage of this solution is that the presence of the "persistent" Via parameter serves as a hint to the server on the intention of the originator of the connection. The originator guarantees to leave the connection up beyond the transaction's and the dialog’s lifetime. It is now up to the server to either honor the persistency and send subsequent requests (in the same dialog or on separate dialogs) on the same socket, or to close the socket after the transaction is over. In the event that the server closes the socket after the transaction, the client reverts to existing behavior by freeing up any resources and attempting a new connection to the same downstream server on subsequent requests. The disadvantage of this solution is that it does not provide for a negotiation on the time frame that the socket remains open. The next solution addresses this very disadvantage. 8.2 New SIP header The second solution is to implement an extension that allows for negotiation for the acquiescence and longevity of a persistent connection. Under this solution, a client that seeks a persistent connection will: (1) Insert a "Supported" header (to provide a hint) or a “Required”/“Proxy-Required” header (goes beyond a hint) with the option tag "persistence", indicating support for this extension. (2) Insert a "persistent" Via parameter as described in the previous section. The client MAY also include a header called "Persistent-Timeout" to indicate an upper bound on the time it will allow for the socket to remain open. If this header is not present, a value of infinity is assumed (i.e. the client will not, under normal operations, close the socket). Jain Expires - May 2004 [Page 12] Internet-Draft Persistent Connection Reqs November 2003 A receiving server, if it supports the extension in this Internet-Draft, can honor the request depending on its policies with respect to persistent connections and the presence (or absence) of the "Persistent-Timeout" header. If a server wants to decrease (or increase) the timeout value, it will send a 4xx response (exact number to be determined) along with a "Min- Persistence" header that indicates its desire on the longevity of the persistent connection. The client is expected to retry the request again with the "Persistent-Timeout" parameter containing a value of MIN("Persistence-Timeout", "Min-Persistence"). The advantage of this solution is that it allows the client to force the server into accepting a persistence connection (through the use of the “Required” or “Proxy-Required” header). A server can also simply provide a hint (by using “Supported”) and leave it to the client to further use the persistent connection. The client and server can also negotiate an upper bound on the time the connection will be left persistence. The disadvantage of this solution is that it goes beyond the "hint" nature of a transparent solution. At this point, some more discussion would be helpful to understand if such a offer/counter-offer/answer mechanism is desired. . 8.3 New transport token A third option is to use a new token called “PTCP” for persistent TCP in the transport position of the Via header: Via: SIP/2.0/PTCP somehost.example.com The advantage of this option is that clients can actively seek out servers that support persistence connections by querying DNS SRV records using the new transport designator. The disadvantage is that no negotiation is provided for negotiating longevity of the persistent connection; once opened, it remains so until the server or client are brought down normally (TLS certificate expiration, scheduled downtime), or abnormally (system crash). 9. Security Considerations Persistent connections provide more opportunities for denial-of- service class of attacks if the server blindly accepts every such connection request. As this I-D matures, some guidelines will need to be established for accepting such connections. Obviously authentication is not the only requiste for acceptance; a server Jain Expires - May 2004 [Page 13] Internet-Draft Persistent Connection Reqs November 2003 may successfully authenticate many downstream clients, but will only want to establish persistent connections with a small subset of these. Other possible security aspects include session hi-jacking. This section is thus a work in progress as the I-D matures. 10. IANA Considerations 11. Acknowledgements Thanks to Eric Colasanto, James Ford, Cullen Jennings, Aby Kuriakose, Sarit Galanos Mekler, Sean Olson, and Victor Saverino for providing valuable input on the issues addressed in this draft. Thanks to Rohan Mahy for writing connect-reuse Internet-Draft, which provides foundation for this draft. Normative References [1] 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. [2] Mahy, R., "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sipping-connect-reuse-reqs00 (work in progress), October 2002. [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Informational References [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [5] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.Leach and T. Berners-Lee, “HyperText Transfer Protocol – HTTP 1.1”, IETF RFC 2616, June 1999. Jain Expires - May 2004 [Page 14] Internet-Draft Persistent Connection Reqs November 2003 Author's Addresses Rajnish Jain Lucent Technologies, Inc. 75 Perseverance Way, Hyannis, MA 02601, US Email: rajnishjain@lucent.com Vijay K. Gurbani Lucent Technologies, Inc. 2000 Lucent Lane Rm 6G-440 Naperville, IL 60566, US Email: vkg@lucent.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Jain Expires - May 2004 [Page 15]