Internet Draft Seok Joo Koh Internet Engineering Task Force ETRI February 2003 Juyoung Park Expires August 2003 ETRI Framework of Overlay Multicast Control Protocol 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 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 a "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 document describes Overlay Multicast Control Protocol (OMCP) used for realizing and managing Overlay Multicast, as also known as Application Layer Multicast. Overlay Multicast is a data delivery scheme for multicast applications, in which one or more intermediate relay agents are employed for relaying application data from a sender to many receivers along a pre-configured or automatically configured tree hierarchy. For standardization of Overlay Multicast, it needs to separate the data plane (for packet relaying) and the control plane (for tree configuration and session monitoring). We describe a control protocol for Overlay Multicast, named Overlay Multicast Control Protocol (OMCP). In OMCP, a special-purpose entity, called Session Manager, is used to manage and control the tree configuration and session monitoring. OMCP is designed to ensure that the multicast applications and services can be provided over current Internet environments in which IP multicast has not completely been deployed. sjkoh, et al Expires August 2003 [Page 1] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 1. Introduction The OMCP has been motivated from the following observations: a. In the marketplaces, a large number of multicast applications and services have been provisioned commercially all over the world. Examples of these applications and services include Internet TV, remote education, real-time streaming media applications, live broadcasting of special events such as Victoria Show, stock-tickers, and so on. b. IP multicast has been known as an effective transport technology for providing multicast services. Nevertheless, the IP multicast has not been deployed widely over Internet. Most of the network service providers still have much concern about a high deployment cost along with an uncertain Return-on- Investment model. c. For the present, most of the Contents Providers still provide multicast services by establishing replicated IP unicast channels with the respective receivers. This however incurs degradation of service quality, limitation to the number of service users that can be simultaneously connected, and hence less revenue or profit in the business model. d. Even though IP multicast has not widely deployed all over the global networks, a lot of local networks have already been equipped with IP multicast transport. In addition, Ethernet- based LANs substantially provide the multicast transport capability within their subnetworks. It is also noted that many private networks such as corporate and Campus networks have so far deployed IP multicast by configuring the multicast-capable routers within their administrative domains. Recognizing these observations, it is clear that there is a crucial need to develop an alternative multicast delivery scheme and its associated protocol that can easily be adapted and widely used in the current Internet. Overlay Multicast is a simple scheme to realize the multicast delivery over current Internet. It is not a new transport scheme but just exploits the existing IP unicast/multicast transport schemes effectively. So far, a lot of researches have been made on Overlay Multicast. Those include End System Multicast [ESM], Your Own Internet Distribution [YOID], Scattercast [Scattercast], Application- Level Multicast Infrastructure [ALMI], Hypercast [Hypercast], and Relayed Multicast Control Protocol [RMCP]. This document describes Overlay Multicast Control Protocol, which is application-level control protocol used for realizing and managing the overlay multicast. An OMCP session consists of a sjkoh, et al Expires August 2003 [Page 2] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 Sender, many receivers, one or more Relay Agents, and a Session Manager. In OMCP, overlay multicast data transport is realized simply by combining the sender and receivers via one or more Relay Agents in a pre-configured or dynamically configured tree hierarchy. Relay Agents are used to relay the application data from a sender to receivers. A Relay Agent may be a dedicated server or a receiving client host. Session Manager is used to manage the tree configuration and overall session monitoring during the session. 2. Terminology 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 [RFC2119]. In this document, the following terms are used. Overlay Multicast: It is a multicast data delivery scheme using the relaying functionality of intermediate Relay Agents; Overlay Multicast Control Protocol (OMCP): It is an application-level control protocol for realizing and managing the overlay multicast data transport; Relay Agents: They are used to relay multicast application data from a sender to receivers; Session Manager: It is responsible for and governs the overall RTMP operations. It may be located at the same system with the sender or separately located from the sender; Data Transport and Control modules: The OMCP control operations are performed by the OMCP control module in the system, which is a program that implements the OMCP control operations described in this document. On the other hand, Data Transport module represents a set of programs established in each OMCP system, which include an application media player and an interface with the OMCP module; sjkoh, et al Expires August 2003 [Page 3] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 3. Data Transport Model in Overlay Multicast In the overlay multicast transport, a new entity named Relay Agent is employed along the communication path from a sender and a receiver. Relay Agents are used to relay the application data from a sender to many receivers over unicast or multicast network regions. With help of Relay Agents, multicast data can traverse non-multicast network regions until they reach the end receivers. Traversing the non-multicast regions, the multicast data will be delivered by using IP unicast or IP-in-IP tunneling. Overlay multicast is realized by using Relay Agents. Relay Agents will be located along the end-to-end paths between a sender and receivers. A Relay Agent plays a role to relay application data from a sender to its children (i.e., its downstream entities). The Relay Agent is also used to monitor status of its children. Relay Agents may be dedicated servers deployed in the network for the relaying purpose, or end receivers. In the latter case, some of the receivers may function as Relay Agents. Figure 1 illustrates a tree hierarchy dynamically configured for the overlay multicast. Session Manager is responsible for the tree configuration. Each receiver or Relay Agent will get its associated tree information from the Session Manager by using OMCP. With information given by Session Manager, each entity will establish a data channel with its parent (i.e., its upstream entity). During the session, with help of OMCP, each parent monitors its children status on membership and QoS, and then forwards the aggregated information to its own parent. In this way, Session Manager monitors overall session status. Sender may get the information from Session Manager via an out-of-band dedicated channel. Sender <========> Session Manager | | /--------------------------------\ | | v v Relay Agent Relay Agent | | /---------------\ /---------------\ | | | | v v Receiver Receiver Relay agent Receiver | V Receiver Figure 1. Tree Hierarchy in Overlay Multicast sjkoh, et al Expires August 2003 [Page 4] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 In the overlay multicast, an individual data channel between two upstream and downstream entities is established by exploiting the existing protocol stacks such as UDP, IP and IP-in-IP tunneling. According to the underlying IP transport scheme, the data channels can be classified into three types: IP unicast, IP multicast, and multicast-in-unicast (or IP-in-IP tunneling). In the unicast and multicast cases, UDP/IP will be used. In the multicast-in-unicast case, each of the multicast data packets will be encapsulated into a unicast packet by using IP-in-IP tunneling. 4. Framework of OMCP Overlay Multicast Control Protocol (OMCP) is an application-level control protocol used for realizing and managing the overlay multicast data transport. Session Manager governs overall OMCP control operations by exchanging control messages between OMCP entities in a request-and-confirm fashion. Session Manager will also configure a tree hierarchy for data relay path dynamically. OMCP is also used to monitor session status on membership and QoS. In an OMCP system, the OMCP control module operates cooperatively along with its associated data transport module so as to establish the corresponding data channels. 4.1 OMCP Model An OMCP session consists of a Sender, receivers, a Session Manager, and Relay Agents. Figure 2 shows a conceptual model of OMCP. It is assumed that Sender communicates with Session Manager so as to inform a set of generic session information via an out-of-band signaling channel. It is also required for all the Relay Agents and receivers to get information on location of Session Manager. When a session start is indicated, each of the Relay Agents and receivers will contact with Session Manager by using OMCP operations so as to join the session. Out-of-band channel /------------> Session Manager <-----------\ | | OMCP | OMCP | | | v v v Sender <---------> Relay Agents <----------> Receiver OMCP OMCP Figure 2. OMCP Model sjkoh, et al Expires August 2003 [Page 5] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 4.2 OMCP Messages In OMCP, three pairs of control messages are used. Each pair of control messages will be exchanged between the OMCP peers in the request-and-confirm way. The Join Request and Confirm messages are used for the session join in which each receiver gets information from Session Manager about who is its parent in the tree hierarchy. The Relay Request and Confirm massages are used for a new joining entity to establish and maintain a data channel with its upstream entity. The Status Report and Confirm messages are used for session monitoring in which each child reports the membership dynamics and QoS status to its upstream entity and thus the aggregated session status information will be delivered to the Session Manager. Table 1 lists the OMCP messages according to the associated OMCP operational phases. The Join Request and Confirm messages are used just once for the session join, while the other four messages are periodically exchanged during the session. Table 1. OMCP Messages +---------------+------------+----------+---------+ | Messages | Operation | From | To | +---------------+------------+----------+---------+ | Join Request | Session | R or RA | SM | +---------------+ +----------+---------+ | Join Confirm | Join | SM | R or RA | +---------------+------------+----------+---------+ | Relay Request | Data | R or RA | S or RA | +---------------+ Channel +----------+---------+ | Relay Confirm | Control | S or RA | R or RA | +---------------+------------+----------+---------+ | Status Report | Session | R or RA | SM | +---------------+ +----------+---------+ | Status Confirm| Monitoring | SM | R or RA | +---------------+------------+----------+---------+ All the OMCP messages are encapsulated over TCP. This ensures that all the messages are reliably transferred to the corresponding OMCP modules. Moreover, it is strongly recommended to use the æTransaction for TCPÆ as known as æT/TCPÆ (see RFC 1644. T/TCP is an extension of TCP, which has been used for reliable delivery of the ærequest-and-responseÆ transactions as shown in the existing Web-based applications. Accordingly, an error handling of OMCP messages is not considered. Instead, the systematic or processing errors between OMCP and T/TCP must be considered in the design and implementation of OMCP. sjkoh, et al Expires August 2003 [Page 6] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 4.3 OMCP Operations The OMCP is an application-level control protocol for supporting and managing Overlay Multicast data transport. In each data transport entity the OMCP module operates along with the accompanying data transport modules. Session Manager and Sender may be co-located at the same system or site. In case that those two entities are separately located, it is assumed that there exists an out-of-band dedicated communication channel between them. From the dedicated channel with Session Manager, Sender will be able to monitor overall session status including status information on its children. In the initialization, each OMCP entity gets the session-wide information from Web server or E-mail, etc. Such information includes session identifier (ID) and location of the Session Manager. It is basically assumed that the concerned application software such as a media player has already been distributed to the prospective OMCP entities along with the OMCP control and data transport modules. When Session Start is indicated, Sender is ready to transmit application data and Session Manager waits for the OMCP Join Request messages from the prospective Relay Agents or receivers. In Session Join, each receiver joins the session by sending a Join Request message to Session Manager, based on the session information obtained in the initialization. The Join Request message must contain information whether the new joiner will function as a Relay Agent or not in the session. On reception of the Join Request, the Session Manager enrolls the new joiner into the membership list for the session and then it performs a pre- specified algorithm to find the best suitable upstream Relay Agent (including Sender) to the new joiner among the enrolled Relay Agents in the session. After that, Session Manager sends a Join Confirm message that contains information about who is the best suitable Relay Agent to the new joiner. After Session Join, the joiner requests the establishment of a data channel to its designated upstream Relay Agent (or Sender) by sending a Relay Request message. The upstream entity will record the new joiner into its children list, and respond with a Relay Confirm message. The Relay Confirm message contains information on the protocol stacks used for establishing the data channel. After that, each of the upstream and downstream entities will invoke the respective data transport modules so as to establish a data channel by using IP unicast, IP multicast, or IP-in-IP tunneling. When IP multicast is used, the downstream entity will perform the IGMP join. When IP unicast or multicast-in-unicast is used, the upstream entity initiates the establishment of a unicast channel with the downstream entity. sjkoh, et al Expires August 2003 [Page 7] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 After a data channel is successfully established, the Relay Request and Confirm messages are periodically exchanged between those two entities until the data channel is valid. These periodic messages are used for the upstream entity to maintain its children list during the session and to determine which data channels become invalid for some reasons such as Session Leave or an abnormal failure. Each upstream entity aggregates all the status information reported from its downstream entities and then reports the aggregated information to Session Manager via Status Report messages. Status Report and Confirm messages are periodically exchanged. Status Report and Confirm messages are used for Session Manager to get overall session status information such as total membership for the session and the perceived QoS levels, with help of intermediate Relay Agents. When a downstream entity wants to leave the session, it sends its upstream entity both Status Report and Relay Request messages with indication of æSession LeaveÆ. The Status Report and Relay Request messages are also used for the upstream entity to detect abrupt or abnormal Session Leave of a downstream entity. Sender will stop the session after it has sent all the application data. In turn, Session Stop will be informed to the Session Manager via an out-of-band channel. 4.4 Interworking between OMCP Control and Data Transport Modules The interworking operations may be implemented by using Inter- Process Communications (IPC) techniques. These operations will be invoked for Data Channel Control and Session Monitoring. When necessary, the OMCP module sends a request to the data transport module and then waits for the corresponding response. The request will contain information on the address and port number associated with a data channel, while the response may contain information on the measured QoS status such as data throughput. The necessary information can be recorded into a suitable MIB in the system so that each module can easily access through an appropriate signaling. It is expected that such a signaling or IPC can be done by a request-and-response fashion from the OMCP control module to the data transport module. That is, when the OMCP control module needs to contact with the data transport module (according to the OMCP mechanisms), it will trigger the associated signaling or IPC process. After Session Join, each receiver contacts with its upstream entity to request the establishment of a data channel. After reception of Relay Confirm message from the upstream entity, the receiver sjkoh, et al Expires August 2003 [Page 8] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 invokes its data transport module by delivering the specific information required for establishing a data channel (e.g., IP address and port number used for the data channel) via an address MIB. During the session, the data transport module may continue to measure the perceived QoS in terms of data throughput (bytes per second) or the number of totally received data packets. In response to the request of the OMCP module, the measured QoS is transferred to the OMCP module via a suitable QoS MIB (e.g., in Session Monitoring). Each time a receiver generates the periodic Relay Request or Status Report messages, the OMCP module will contact with the data channel so as to check if the data channel is still valid. At Sender, the OMCP module is used to listen to Relay Request messages from any new joiners. After processing of the Relay Request messages, Sender will invoke its data transport module to establish the corresponding data channels. During the data transport, each child will be recorded and maintained into SenderÆs children list. By the OMCP operations, if a Session Leave or failure is detected for a child, Sender will request the data transport module to stop the corresponding data channel. A Relay Agent functions as both a sending and a receiving entity. Accordingly, it will perform all the interworking operations described above. Session Manager does not perform the data transport module. 5. Functional Procedures 5.1 Initialization In OMCP, it is assumed that the associated OMCP and data transport modules have already been distributed to the OMCP entities. The OMCP module represents a program that implements the OMCP control operations described in this specification. A data transport module includes the concerned application software (e.g., Windows media player or MPEG media player, etc) and an interface program for interworking with the OMCP module. The application may be a commercial application program, which will be made by considering the protocol stacks available according to the reliability requirements (e.g., UDP/IP or TCP/IP) and the media types (video, audio, etc). The data transport module may be made in the fashion that the existing application software is extended for accommodating the OMCP module. A Contents Provider or Sender may distribute a software package with the OMCP-aware application programs including the data transport and OMCP modules to the prospective clients (receivers). sjkoh, et al Expires August 2003 [Page 9] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 When a session starts, Sender and Session Manager will be ready to respond to any OMCP control messages from the prospective entities. When the session stop, Sender and Session Manager will take no more responsive actions to the requests of the OMCP entities. An OMCP session is called æactiveÆ over the time period from session start until session stop. The out-of-band channel between Sender and Session Manager may continue to operate during the active session so that Sender can check the current session status. How to implement such out-of-band channel is outside the scope of this specification. Before an OMCP session begins, the session-wide information will be announced to all the prospective session members by using an out- of-band communication channel (such as Web announcement or E-mail, etc). The session-wide information includes the followings: Session Identifier (ID): In OMCP, Session ID is represented as a 64-bit integer. Session ID should be able to identify an OMCP session uniquely. Location of the Session Manager (IP address and port number): Every receiving entity such as Relay Agent or receiver will first contact with the Session Manager to join a session based on this location information. If a well-known port number is assigned as the OMCP port, then the port number will not be announced. In particular, Session ID and location of Session Manager must also be informed to all the OMCP entities. Per a Session ID, the Session Manager will initialize the OMCP control operations and maintain a list of session membership and QoS. Sender or Relay Agent will also manage its children list for the Session ID. In the initial phase, Sender will be viewed as an active Relay Agent the Session Manager. In case that one or more Relay Agents are strategically deployed as dedicated servers in the network, those Relay Agents will be enrolled to the Session Manager and they will function as initial active Relay Agents before the session starts. 5.2 Session Join Each Relay Agent or receiver must join the session by contacting with the Session Manager. By this the new joiner gets information about the location of its parent (upstream entity) in the tree hierarchy. To join an OMCP session, each receiver or Relay Agent sends a Join Request message to the Session Manager, and waits for the sjkoh, et al Expires August 2003 [Page 10] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 responding Join Confirm message. The Join Request message must contain an indication of whether it function as a receiver or a Relay Agent in the session. On reception of a Join Request message, Session Manager performs a pre-specified tree configuration algorithm to find the best suitable parent to the joiner, which may be based on information on the IP addresses of the entities and the data channel types supported at the entities. For examples, if there is an active Relay Agent who is in the same (multicast-enabled) subnetwork with the new joiner (which may be done by using comparing IP address and the subnet masking), then the Session Manager will assign the Relay Agent as the parent of the new joiner. If there is no Relay Agent located at the same subnetwork, a Relay Agent with a smaller number of children may be first assigned to the new joiner. If the data channel types allowed at the upstream and downstream entities are different, the assignment between them will not occur. Any other additional information such as network topology may be exploited on the tree configuration process, if possible. Notice that the specific algorithm for the tree configuration is implementation- specific. In response to the Join Request, the Session Manager must send a Join Confirm message to the new joiner. The Join Confirm message must include the location of the best suitable upstream Relay Agent (or Sender) that the new joiner will connect to. The Join Confirm message may indicate a rejection of the join request for any abnormal reasons. If the new joiner will receive a successful Join Confirm message, it begins Data Channel Control by sending a Relay Request message to the designated upstream entity. If the Join Confirm message indicates a rejection or there is no response from Session Manager, then the new joiner cannot participate in the seesion. 5.3 Data Channel Control After reception of a successful Join Confirm message from Session Manager, the new joiner sends a Relay Request message to the designated Relay Agent and waits for the responding Relay Confirm message. In response to the Relay Request, the upstream Relay Agent (or sender) sends a Relay Confirm message to the joiner, and then begins the establishment of a data channel with the joiner by invoking its data transport module. After reception of a successful Relay Confirm message, the new joiner begins to receive application data from its upstream entity by invoking its data transport module. After reception of a Relay Request message, the upstream entity enrolls the new joiner into its children list. The upstream entity selects a specific data channel type used for the data transport sjkoh, et al Expires August 2003 [Page 11] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 with the joiner among the data channel types indicated in the Relay Request message. IP multicast channel is preferred if supported and possible. The Relay Request may be rejected for some reasons. After sending the Relay Confirm message over the T/TCP control channel, the upstream OMCP entity invokes its data transport channel to transmit application to the downstream entity. At the downstream entity, if the Relay Confirm message indicates a rejection or there is no response of Relay Confirm from the underlying T/TCP channel, the new joiner closes the OMCP session. Once a data channel is successfully established and maintained, the downstream entity must also send periodic Relay Request messages to the parent (the upstream entity), to ensure that the parent can realize its keep-aliveness. If the parent realizes that a child is failed, the parent will stop transmission of data to the concerned child in the unicast transport. The second or further Relay Request messages are transmitted based on the timer value (RR_TIME) indicated in the previous Request Confirm message. When a child receives a Relay Confirm message, it will send the subsequent Relay Request message when the indicated timer expires. One of the reasons for the parent to determine a time interval for the next Relay Request message is to avoid the so-called implosions of simultaneous Relay Request messages from many children. For this purpose, the parent may determine a different timer value for each child. Notice that Sender is a root of the data path tree for the relay multicast data transport. The periodic Relay Request and Confirm messages are used for the upstream entity to check if the children are active or not. Accordingly, the Relay Request and Confirm messages flow from receivers to Sender, not Session Manager. The status aggregation of the Relay Request message will not be performed at each parent. The status information is just used for the concerned parent to determine whether or not the associated data channel(s) must be maintained. On the other hand, the Session Manager is a root of the control tree for control of OMCP operations. Each Status Report and Confirm messages go upward from receivers to the Session Manager, not Sender. A Status Report message contains information about membership and QoS status for the downstream descendants. Accordingly, each intermediate Relay Agents must perform aggregation of Status Report messages reported from the children. 5.4 Session Monitoring sjkoh, et al Expires August 2003 [Page 12] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 Session monitoring is used for Session Manager to monitor overall status of membership dynamics and measured QoS for a session. For this purpose, Status Report and Confirm messages are exchanged between Session Manager and Relay Agents/receivers. At each Relay Agent or receiver, Session Monitoring begins after establishment of a data channel. Each child sends a Status Report message if the SR_TIME timer expires. A Status Report message will include membership and QoS status. Each receiving entity will measure the QoS values in terms of the number of received data packets and data throughput by manipulating the data packets in the data transport module. The corresponding OMCP module will ask the measure QoS status to the data transport module before it generates a Status Report message. A Status Confirm message may contain information on a new SR_TIME timer value (for the next Status Report to be transmitted). If a new SR_TIME is designated in the Status Confirm message, the subsequent Status Report message will be generated after the new SR_TIME expires. Notice that the two periodic timers, RR_TIME and SR_TIME, are used by different messages with different purposes. Typically the SR_TIME may be set to a larger value than the RR_TIME (e.g., 5 or 10 times). 5.5 Session Leave Session Leave can be classified into a normal or abnormal leave. A normal leave means that the downstream entity sends a Session Leave indication to its parent before it stops the session. An abnormal leave means that an OMCP entity becomes inactive from any failure. In case of the normal leave, a receiving entity generates the Relay Request and Status Report messages indicating æSession LeaveÆ. The parent node and Sessin Manager will update its children or membership list. 6. Security Considerations TBD 7. References sjkoh, et al Expires August 2003 [Page 13] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [ESM] End System Multicast, http://www-2.cs.cmu.edu/~narada/, CMU [YOID] Your Own Internet Distribution, http://www.icir.org/yoid/, ACIRI [Scattercast] Scattercast, http://berkeley.chawathe.com/~yatin/, UCB [ALMI] Application-Level Multicast Infrastructure, http://alminet.org/, Washington University [Hypercast] Hypercast, http://www.cs.virginia.edu/~mngroup/hypercast/, University of Virginia [T/TCP] IETF RFC 1644, T/TCP: TCP Extensions for Transactions Functional Specification, Experimental, July 1994 [IPIP] IETF RFC 1853, IP in IP Tunneling, Informational, October 1995 [RMCP] ITU-T draft Recommendation X.rmcp,öRelayed Multicast Control Protocolö, ITU-T SG17 Question 8, Working in Progress, 2002 8. AuthorÆs Addresses Seok Joo Koh Email: sjkoh@etri.re.kr Juyoung Park Email: jypark@etri.re.kr Protocol Engineering Center Electronics Telecommunications Research Institute, KOREA sjkoh, et al Expires August 2003 [Page 14] INTERNET DRAFT Use of SCTP for Seamless Handover February 2003 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 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." sjkoh, et al Expires August 2003 [Page 15]