Internet Engineering Task Force Radhika R. Roy Internet Draft AT&T draft-roy-iptel-gw-server-registration-00.txt August 31, 2001 Expires: March 3, 2002 Gateway and Server Registration Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft 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 intra-ITAD communications 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. Abstract This contribution describes a registration protocol that can be used between gateways (GWs) and severs as well as among servers in intra- ITAD communications environment. The registration protocol is used by a GW just to inform its transport address and reachable alias addresses including telephone numbers through it along with other information (e.g., capacity, cost, traffic, usage, QoS, GoS) to the Server and does not deal with any routes or path attributes. The registration protocol is also used to negotiate capabilities between the peers. The registration protocol will be a part for building a single unified intra-ITAD protocol described in a following contribution. The proposed message formats of the intra- Radhika R. Roy [Page 1] Internet Draft Registration Protocol August 31, 2001 ITAD protocol including the registration message are similar to TRIP. We have also analyzed that the proposed registration protocol is superior to the existing registration protocols (SIP, TRIP and H.323) meeting all requirements to provide scalable solution. Table of Contents 1. Introduction 3 2. Conventions used in this document 3 3. Registration Protocol Description 3 3.1 SIP Server/LS Registration by the GW 4 3.1.1 Alternate Peers 5 3.1.2 Registration Time (RT) 5 3.1.3 Registration Time Extension (RTE) 6 3.1.4 Alternate GW 6 3.1.5 Capacity/Performance/Services Attributes 6 3.2 Registration Cancellation 6 3.3 SIP Server/LS and GW Registration Message Flows 8 3.4 Behavior of SIP Server/LS and GW for Registration Messages 8 3.5 ITAD Topology and Registration Mechanism 9 3.6 Registration Protocol Semantics 10 3.6.1 Common Message Elements 11 3.6.2 Transport for Registration Protocol 11 3.7 Registration Protocol Syntax 12 4. Issues with the Registration Protocol 12 5. Analysis of the Registration Protocol in view of its Requirements 12 6. Policy 13 7. Security 13 8. GW Registration using Other Methods 13 8.1 SIP 13 8.2 TRIP-GW 14 8.3 H.323 14 9. Conclusion 15 10. References 16 Acknowledgments 16 Author's Addresses 16 Full Copyright Statement 18 Radhika R. Roy [Page 2] Internet Draft Registration Protocol August 31, 2001 1. Introduction In IP-PSTN interworking environment, a SIP [2] call from the IP network may traverse to the PSTN network via a gateway (GW). A telephony or SIP-H.323 GW connected to the IP network needs to bind with the location server (LS) [3] a set of telephone numbers/prefixes or aliases to its address that can be reachable for SIP calls. Similarly, a SIP server also requires to find telephony or H.323 GWs to route SIP calls with PSTN or H.323 destinations. In TRIP [3], a Location Server (LS) takes the routing decision and, a LS can be co-located with a call signaling server like SIP. A LS can also be called a Route Server (RS). For simplicity, a LS (or RS) is also referred as server in this contribution. Like TRIP, it is also assumed that a location server (or router server) is co-located with a call signaling server like SIP. However, a LS (or RS) will have the intelligence for routing. The proposed discovery protocol will be used between GWs and Servers as well as among the Servers. A GW [4, 5] connected to the IP network needs registration with the SIP Server/location server (LS) a set of telephone numbers/prefixes or other aliases to its address that can be reachable for SIP calls. However, a GW does not have the routing capacity to make any decision and does not deal with any path or route attributes. In this scenario, a GW needs to discover [6] a SIP Server/LS for registration through which it can advertise the reachable destination addresses so that a SIP call can be routed through it. In another scenario, a SIP Sever/LS needs to discover [6] a GWs and initiates the registration of the GWs through which it can route calls if the GWs are not registered. 2. Conventions used in this document 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 RFC-2119 [7]. 3. Registration Protocol Description The registration protocol provides the actual information about the peers for ongoing communications. A registration protocol is needed to inform the SIP Server/LS by a GW of its transport and alias addresses. Similar is the case for a SIP Server/LS where it can also register with all its SIP Servers/LSs peers. However, a GW (or SIP Server/LS) needs to know the SIP Server/LS before registration. A GW Radhika R. Roy [Page 3] Internet Draft Registration Protocol August 31, 2001 (or SIP server/LS) will know its Server/LS through auto-discovery [6] process. Registration needs to occur before the call setup so that a SIP Server/LS can route the SIP call to the appropriate GWs knowing the destination addresses provided within the call and may occur periodically as necessary (e.g., its power-up after maintenance). A GW may register a single or multiple transport and/or alias addresses. The use of the multiple transport addresses may simplify the routing of calls to specific ports. However, a GW shall register with one SIP Server/LS while a SIP Server/LS can register with all its SIP Servers/LSs peers. The reason for registering of a GW with only one SIP Server/LS because of better management, but there is no limitation from the protocol point of view. It is also assumed that all SIP Servers/LSs will be communicating exchanging information among themselves and synchronize their information about all registered GWs. Should a SIP call arrive to the SIP Server/LS and the said server does not have the information about the GW(s), the sever can discover [6] the GW(s) for initiating registration with it. After registration of the information of the GW(s), the server can take decision which GW needs to be contacted to route a call. In this scenario, the call setup time will be little more that of the earlier case described above. 3.1 SIP Server/LS Registration by the GW All peers can register with one another using the _REGISTER_ message. A GW (or SIP Server/LS) shall send a _REGISTER_ request message to a SIP Server/LS. This message is sent to the Server's/LS's transport address. The GW (or SIP Server/LS) has the network address of the SIP Server/LS known from the discovery [6] process and uses the well-known port. The SIP Server/LS will respond with either _CONFIRM_ or _REJECT_ message. The rejection of the registration message may include many reasons including security, policy, and others. A GW shall only register with a single SIP Server/LS, but a SIP Server/LS can register with all its SIP servers/LSs peers. This is done for better management of the system. However, in the confirmation message, a SIP Server/LS may send a list of alternate SIP Servers/LSs in accordance to priority because a GW (or SIP server/LS) may need to register with the alternate Servers/LSs should the primary Server/LS fails. Similarly, a GW may also provide the information about the alternate GWs where the SIP Server/LS can communicate should the primary GW fail. It will increase the reliability of the system. Radhika R. Roy [Page 4] Internet Draft Registration Protocol August 31, 2001 The _REGISTER_ message may be repeated periodically (i.e., at GW power-up after maintenance), so the Server/LS shall be able to handle multiple requests from the same GW. However, a SIP Server/LS may receive the registration message with different combinations of the alias and the transport address and, it will respond in those conditions as follows: . If a SIP Server/LS receives a _REGISTER_ request message having the same alias address and the same transport address as a previous _REGISTER_, it shall respond with the _CONFRIM_ message. . If a SIP Server/LS receives a _REGISTER_ request message having the same alias address as a previous _REGISTER_ request message and a different transport address, it may confirm the request, if it conforms the request with the SIP Server's/LS's security policy. Otherwise, it should reject the registration indicating a duplicate registration. . If the SIP Server/LS receives a _REGISTER_ request message having the same transport address as a previous REGISTER request and a different alias address, it should replace the translation table entries. The SIP Server/LS may have a method to authenticate these changes. Similar is the case for the SIP Server/LS when it registers with its SIP Servers/LSs peers. 3.1.1 Alternate Peers Alternate peers can also be associated using the discovery [6] message. In order to enhance reliability in the system which uses a Server/LS, the Server/LS may indicate alternate Servers/LSs that may be used in the event of a primary Server/LS failure. The list of alternate Servers/LSs can be provided in the _Alternate-Server_ structure of the _CONFIRM_ and _REJECT_ messages. Similarly, the alternate GW addresses can also be provided by the _REGISTER_ request message. When a SIP Server/LS discover other peers, they can also provide the list alternate peers to which it can register if the primary one fails. 3.1.2 Registration Time (RT) The registration of the GW with the SIP Server/LS may have a finite lifetime. A GW (or SIP Server/LS) may request a _Time-To-Live_ in the _REGISTER_ request message to the SIP Server/LS and, the SIP Server/LS may respond with a _CONFIRM_ response message containing the same registration time or a shorter registration time. After this time, the registration shall be expired. Radhika R. Roy [Page 5] Internet Draft Registration Protocol August 31, 2001 3.1.3 Registration Time Extension (RTE) Prior to the expiration of the registration time, a GW (or SIP Server/LS) may send the _KEEP-ALIVE-MESSAGE_ requesting for extension of the registration time._ This shall reset the _Time-To- Live_ parameter in the SIP Server/LS, allowing the registration to be extended. After the expiration time, the GW (or SIP Server/LS) must re-register with the SIP Server/LS. If a GW (or SIP Server/LS) does not include the registration time value in _Time-To-Live_ field of its _CONFIRM_ message, the registered GW (or SIP Server/LS) shall consider that the SIP Server/LS is not supporting the RTE mechanism and no indication for the RTE shall be provided in the subsequent messages indicating that the SIP Server/LS is not supporting the RTE mechanism. 3.1.4 Alternate GW It has been explained earlier to deal with alternate peers. The SIP Server/LS shall ensure that each alias address translate into a single transport address. However, a GW may be able to indicate a backup, redundant, or alternate transport address using the _Alternate GW_ field. This will allow a GW to have a secondary network interface or a secondary GW as a backup. In any case, any ambiguous registration will be rejected by the SIP Server/LS. 3.1.5 Capacity/Performance/Services Attributes A GW will be able to send all the attributes related to capacity, performance and services for registration. For example, the parameters like number of calls [total, spare], number of ports [total, spare], number of circuits and speeds [total, spare], etc.), QoS, GoS, codecs, bridging capabilities, and others parameters that a GW likes to send for registration. A SIP Server/LS will then be able to advertise these parameters. 3.2 Registration Cancellation A GW may cancel its registration by sending the _REGISTER_ message using the NULL value (or *) in the alias address field or address structure. The registration cancellation request can be confirmed or rejected using _CONFIRM_ or _REJECT_ message, respectively. In the case of rejection, the reject reason needs to be sent. Radhika R. Roy [Page 6] Internet Draft Registration Protocol August 31, 2001 Radhika R. Roy [Page 7] Internet Draft Registration Protocol August 31, 2001 3.3 SIP Server/LS and GW Registration Message Flows A simple high-level message flows is shown in Figure 1. In this scenario, a GW sends the RREGISTER message to the SIP Server/LS whose address is known by the GW at the time of discovery [6]. GW SIP Server/LS | REGISTER | |----------------------->| | CONFIRM or REJECT | |<-----------------------| | | Figure 1: Registration with a SIP Server/LS by a GW Figure 2 shows the registration cancellation with the SIP Server/LS by the GW. GW SIP Server/LS | REGISTER* | |----------------------->| | CONFIRM or REJECT | |<-----------------------| | | * REGISTER message with NULL value (*) in the address field Figure 2: Registration cancellation with a SIP Server/LS by a GW The registration is also cancelled at the expiration of the registration time and no extension of the registration time is made before expiration. 3.4 Behavior of SIP Server/LS and GW for Registration Messages All GWs shall register with the SIP Server/LS in an ITAD identified through the discovery process [6] as a part of their configuration. As a result, every GW is required to implement the REGISTER, CONFIRM, and REJECT message. These messages will be sent to the SIP Server/LS or GW to the known addresses when association is made during the discovery process [6]. Once the SIP Server/LS is discovered, a GW proceeds for the initiation of the call or a GW prepares for receiving the call. A GW which is not registered with the SIP Server/LS cannot request any services from the SIP Server/LS and so cannot participate in Radhika R. Roy [Page 8] Internet Draft Registration Protocol August 31, 2001 advertisement of reachability of destination addresses through it, its capacity, and other functions performed by the SIP Server/LS. 3.5 ITAD Topology and Registration Mechanism An ITAD topology is expected to have at least a single SIP Server/LS or multiple SIP Servers/LSs. In the case of a single SIP Server/LS, the network configuration is straight forward. All GWs will be able to auto-discover [6] the SIP Server/LS and, shall register with the SIP Server/LS whose address will be known during the discovery process [6]. A GW may also be able to register the backup GW(s) during the registration process to enhance the reliability. A single SIP Server/LS is likely to become an increasingly critical single point of failure eventually. A desire to have SIP Servers/LSs to back each other (e.g., alternate Servers as explained earlier) up or to serve different regions of very large networks characterizes the next level. However, a network (e.g., intranet) needs not be truly large before it may become convenient to use multiple SIP Servers/LSs. Radhika R. Roy [Page 9] Internet Draft Registration Protocol August 31, 2001 3.6 Registration Protocol Semantics The REGISTER message needs to have the following information: . Protocol Identifier: The protocol that is being used for the registration request (REGISTER) message. For example, REGISTER messages can be a part of the intra-ITAD protocol. . Transport Address: The transport address of the GW that is used for the registration message by the GW. . Entity Type: The entity (e.g., GW) that is sending the registration message. For example, it can be GW (POTS/PSTN/ISDN, SIP-H.323, MEGACO/H.248), SIP Server/LS, etc. . Entity Identifier: An identifier that is provided by the SIP Server/LS after confirming the registration that may need to be used in the subsequent REGISTER messages for extension of registration time for example. . Discovery Complete: This field shall be set to TRUE or FALSE. If the discovery of the SIP Server/LS is already done, this field should be set to TRUE. This field will be set to FALSE, if it is done only for registration without performing the discovery of the SIP Server/LS, but the GW will get the response from the Server/LS that the GW should perform the discovery [dynamic or static]. . Server/LS Identifier: The Server/LS identity to which the GW would like register. . Entity Alias: A list of alias addresses, by which other entities (e.g., SIP Servers/LSs) may identify this entity (e.g. GW) that is sending the registration request message. . Alternate Entities: A sequence of prioritized GW alternatives for transport address, entity type, or entity alias. . Registration Time: The duration of the validity of the registration, in seconds. After this time, the SIP Server/LS may consider the registration stale. . Registration Time Extension: It is set either as TRUE or as FALSE. If this field is set TRUE, it indicates that the GW has sent the REGISTER message for extending the registration time. . Capacity/Performance/Services Attributes: The parameters like number of calls [total, spare], number of ports [total, spare], number of circuits and speeds [total, spare], etc.), QoS, GoS, Radhika R. Roy [Page 10] Internet Draft Registration Protocol August 31, 2001 codecs, bridging capabilities, and others that a GW likes to send for registration. . Security Parameters: Authentication mechanisms, encryption algorithms, integrity mechanisms, token, etc. may be specified, if needed. The confirmation and cancellation of the registration Request shall be done using CONFIRM and REJECT message, respectively. The information elements of these messages are shown in contribution [6]. However, the registration cancellation can be made by sending the REGISTER message with NULL value (or *) in the alias address information field. 3.6.1 Common Message Elements The above analysis shows that the common message elements for all messages can be as follows: . Message Sequence Number . Protocol Identifier . Transport Address . Entity Type . Entity Alias Similarly, the request and response discovery [6] messages will also have the common message elements. 3.6.2 Transport for Registration Protocol Either reliable (e.g., TCP) or unreliable (e.g., UDP) can be used as the transport protocol for the registration protocol. Radhika R. Roy [Page 11] Internet Draft Registration Protocol August 31, 2001 3.7 Registration Protocol Syntax The messages that need to be used by GWs and SIP Servers/LSs for registration are RGISTER, CONFIRM, REJECT. Again, any updates are made by any GWs, the same also need to be propagated to all SIP Servers/LSs. The most important thing is that, unlike TRIP [3], none of these messages require route selection and route aggregation. Like TRIP [3], a _KeepAlive-Message_ may also be needed for both GW- Server/LS and Server/LS-Server-LS communications to detect failures. The detail of the REGISTER, CONFIRM [6], and REJECT [6] messages have been described. Like TRIP [3], a MESSAGE-UPDATE request also needs to be defined for the intra-ITAD protocol. Finally, the syntax of the Intra-ITAD protocol can also be written in accordance to TRIP [3] protocol. The proposed message formats of the discovery message can be seen in another contribution as a part of the a single unified intra-ITAD protocol. 4. Issues with the Registration Protocol The issues that we need to resolve with the discovery protocol can be summarized as follows: . Do we include email and other alias addresses in addition to telephone addresses (E.164)? . Do we allow a GW to register with the alternate SIP Servers/LSs for increasing reliability in order of priority in case of the primary SIP Server/LS fails? . Should we rely on alternative mechanisms such as TLS, IPsec, etc. instead of considering for individual messages? 5. Analysis of the Registration Protocol in view of its Requirements The proposed registration protocol uses RGISTER, CONFIRM, REJECT messages as a part of the overall intra-ITAD (or domain) protocol. This protocol messages are not tied to the call control messages directly because it is assumed that the registration us performed before any initiation is made. Radhika R. Roy [Page 12] Internet Draft Registration Protocol August 31, 2001 Therefore, it allows to proceed the calls fast as the registration is done independent before the call setup. The features like reliability, security, timeliness, efficient, Server control, and independent policy control for both the GW and the SIP Server/LS are also the inherent property of the said registration protocol. Therefore, the proposed registration protocol meets all the requirements that have been envisioned. 6. Policy One of the requirements has been that each SIP Server/LS and each GW be allowed to apply its policy independently although the SIP Server/LS should have the control whether a GW can register with a SIP Server/LS or a call to be routed through a particular GW. The proposed registration protocol meets this requirement. However, like discovery protocol [6], we have not specified a particular standard mechanism for policy either for the SIP Server/LS or for the GW. We believe that the standardization of policy may be addressed separately. 7. Security Like discovery protocol [6], we have not proposed any particular security scheme for the registration protocol. We like to address the security mechanism in the context of the overall intra-domain protocol. 8. GW Registration using Other Methods 8.1 SIP The other registration schemes like SIP's REGISTER method [2] can also do the registration. However, The REGISTER mechanism is used to bind a single incoming URI to one or more outgoing URIs. In the case of a telephony gateway, the binding is between a set of telephone prefixes to the address of a gateway. This is a significantly different binding, and cannot be represented with the syntax or semantics of a SIP REGISTER request [8]. However, there is no discovery mechanism for the SIP Server/LS and, as such, there is no clear relationship between the association of the SIP Server/LS during discovery and the registration process. Radhika R. Roy [Page 13] Internet Draft Registration Protocol August 31, 2001 Therefore, SIP's registration mechanism does not satisfy the requirement for the intra-ITAD communications. 8.2 TRIP-GW TRIP-GW's [8] messages (e.g., OPEN) can also be used what is being done by the REGISTER message as described in this contribution. However, registration needs to proceed after discovery and, TRIP-GW does not have any discovery mechanisms. TRIP's TCP-based connection- oriented transport seems to be good for point-to-point communication where topology is priori known. TRIP [3] does not provide any mechanism for discovery of its peers _ SIP Servers/LSs and, thereby, cannot associate the addresses of the SIP Servers/LSs to the GWs for registration dynamically. It appears that a new protocol is needed for discovery in TRIP. Updates of the information need to be sent among the servers and, GWs also need to send updates to Servers. Both discovery and updates mechanisms are efficient for multicasting and, auto-discovery is not possible without multicasting in one-to- many communications environment. For this, reason, UDP transport is needed. But TRIP uses flooding with limited broadcast with TCP-based transport assuming a pre-provisioned configuration. Considering the overall requirements of the intra-ITAD communications, it would better to optimize all messages along with the use of transport for the intra-ITAD communications. A single unified intra-ITAD protocol that includes discovery, registration, update, keep-alive, confirmation, and error-notification appears to be the most efficient solution. 8.3 H.323 H.323 [9] also has a method for registration as a part of H.225.0 RAS signaling messages. All endpoints in a given zone need to register with a gatekeeper of that zone and, a zone is controlled by a gatekeeper. In our case, there is no concept of zone or similar to this for registration with a SIP Server/LS by a GW. Again, a server may also be allowed to registered with many other servers in an ITAD and, this concept is not allowed in H.323. Many semantics are also not the same based on our requirements. Finally, our syntaxes are also different. Radhika R. Roy [Page 14] Internet Draft Registration Protocol August 31, 2001 9. Conclusion We have proposed a registration protocol that meets all requirements for the intra-ITAD communications. The proposed registration protocol is efficient and scalable considering the large-scale network in comparison with other existing registration protocols. The semantics of the protocol have also been defined. We have also described briefly the similarity and differences of the registration process described in this contribution with others such as SIP's REGISTER method [2] and H.323's REGISTRATION REQUEST [9]. Although TRIP's OPEN message can meet the registration requirements only for the pre-provisioned configurations or once the discovery is done. That is, a new protocol is needed for discovery in TRIP-GW [8]. Moreover, the flooding mechanism is also not efficient where multicasting can be used. Either a reliable (e.g., TCP) or a unreliable (e.g., UDP) transport protocol can be used for registration process. However, we believe that the syntax of the protocol be defined using the TRIP {3] protocol. We have proposed that a complete set of intra-ITAD protocol can be defined using _DISCOVER, CONFIRM, REJECT, REGISTER, MESSAGE-UPDATE, and KEEP-ALIVE-MESSAGE._ This combine set of protocol can be termed as Intra-ITAD protocol as described in another contribution [10]. The security of the discovery protocol will be addressed in the light of the overall security of the Intra-ITAD protocol. The standardization of the policy protocol will be addressed separately. There are some issues related to the security and the overall approach of the Intra-ITAD protocol. We have provided some suggestions how these issues can be addressed. Radhika R. Roy [Page 15] Internet Draft Registration Protocol August 31, 2001 10. References [1] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. [2] Handley, Schulzrinne, H., Schooler, J. Rosenberg, J., _SIP: Session Initiation Protocol,_ RFC 2543, Internet Engineering Task Force, March 1999. [3] Rosenberg, J., H. Salama, H., and Squire, M., "Telephony routing over IP (TRIP)," Internet Draft, Internet Engineering Task Force, November 2000. Work in progress. [4] Agrawal, H., Roy, R. R., Palawat, V., Johnston, A., Agboh, C., Wang, D., Singh, K., and Schulzrinne, H., "SIP-H.323 Interworking ", draft-agrawal-roy-palawat-sip-h323-interworking-reqs- 00.txt, IETF, April 2000. Work in progress. [5] Cuervo, N., Greene, N., Huitema, C., Rayhan, A., Rosen, B., Segers, J., _MEGACO Protocol version 0.8,_ RFC 2885, Internet Engineering Task Force, August 2000. [6] Roy, R. R., _Gateway and Server Discovery Protocol,_ draft-roy- iptel-gw-server-discovery-00.txt, IETF, August 2001 - Work in progress. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [8] Rosenberg, J., Salama, H., _Usage of TRIP in Gateways for Exporting Phone Routes,_ draft-rs-trip-gw-02.txt, IETF, July 2001 - Work in progress. [9]"Packet based multimedia communication systems", Recommendation H.323,ITU-T, Geneva, Switzerland, February 1998. [10] Roy, R. R, _IP Telephony Routing Protocol (IPRT),_ Internet Draft, draft-roy-iptel-itrp-00.txt, IETF, August 2001 _ Work in Progress. Acknowledgments TBD Author's Addresses Radhika R. Roy AT&T Room D3_3C09 200 S. Laurel Avenue Middletown, NJ 07748, USA Radhika R. Roy [Page 16] Internet Draft Registration Protocol August 31, 2001 Phone: +1 732 420 1580 Email: rrroy@att.com Radhika R. Roy [Page 17] Internet Draft Registration Protocol August 31, 2001 Full Copyright Statement 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. Radhika R. Roy [Page 18]