Internet Draft Seok Joo Koh/ETRI Document: draft-koh-omcp-00.txt Juyoung Park/ETRI October 2002 Shin Gak Kang/ETRI Expires April 2003 Dae Young KIM/CNU An Architecture of Overlay Multicast Control Protocol <draft-koh-omcp-00.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. 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. 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. 1. Introduction The design of OMCP has been motivated from the following observations: S.Koh, et al. draft-koh-omcp-00.txt [Page 1]
INTERNET-DRAFT Expires: April 2003 October 2002 - 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. - 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. - 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. - 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 simmple 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, which 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 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 S.Koh, et al. draft-koh-omcp-00.txt [Page 2]
INTERNET-DRAFT Expires: April 2003 October 2002 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; Parent and Child: Parent represents an upstream entity directly attached in the tree hierarchy, and Child represents a downstream entity directly attached in the tree hierarchy. 3. Data Transport Model in Overlay Multicast S.Koh, et al. draft-koh-omcp-00.txt [Page 3]
INTERNET-DRAFT Expires: April 2003 October 2002 In the conventional approach, a sender communicates directly with receivers by using IP unicast or IP multicast. In the scheme, if there exists any non- multicast regions between the sender and receivers, the multicast transport is not allowed. In the overlay multicast transport, a new entity named Relayed 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. S.Koh, et al. draft-koh-omcp-00.txt [Page 4]
INTERNET-DRAFT Expires: April 2003 October 2002 Sender <========> Session Manager | | /-------------------------\ | | v v Relay Agent Relay Agent | | | | /-----------\ /------------\ | | | | v v v v Receiver Receiver Relay agent Receiver | | v Receiver Figure 2. Tree Hierarchy in Overlay Multicast 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. One of the important points to be considered in the implementations of Overlay Multicast is how to make Relay Agents store or cache the application data received from Sender (or upstream Relay Agent) and relay them to their downstream receivers. In cases that an IP unicast or IP multicast channel is used, a Relay Agent will store the data in the application-level buffer. When its child requests the data relay, it will send the buffered data to the concerned child by IP unicast or IP multicast. On the other hand, if the multicast-in- unicast channel is used with the upstream entity, after reception of the data, the Relay Agent will forward the multicast data directly to the downstream entity by exchanging the outer unicast header with a new unicast header destined to the concerned receiver (in the unicast network), or by using IP multicast (in the multicast network). S.Koh, et al. draft-koh-omcp-00.txt [Page 5]
INTERNET-DRAFT Expires: April 2003 October 2002 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. Conceptual Model of OMCP 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. S.Koh, et al. draft-koh-omcp-00.txt [Page 6]
INTERNET-DRAFT Expires: April 2003 October 2002 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. 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 S.Koh, et al. draft-koh-omcp-00.txt [Page 7]
INTERNET-DRAFT Expires: April 2003 October 2002 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. 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 S.Koh, et al. draft-koh-omcp-00.txt [Page 8]
INTERNET-DRAFT Expires: April 2003 October 2002 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 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. S.Koh, et al. draft-koh-omcp-00.txt [Page 9]
INTERNET-DRAFT Expires: April 2003 October 2002 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). 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 S.Koh, et al. draft-koh-omcp-00.txt [Page 10]
INTERNET-DRAFT Expires: April 2003 October 2002 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 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. S.Koh, et al. draft-koh-omcp-00.txt [Page 11]
INTERNET-DRAFT Expires: April 2003 October 2002 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 with the joiner among the data channel types indicated in the Relay Request message. IP multicast channel is preferred if supported and S.Koh, et al. draft-koh-omcp-00.txt [Page 12]
INTERNET-DRAFT Expires: April 2003 October 2002 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 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 S.Koh, et al. draft-koh-omcp-00.txt [Page 13]
INTERNET-DRAFT Expires: April 2003 October 2002 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 S.Koh, et al. draft-koh-omcp-00.txt [Page 14]
INTERNET-DRAFT Expires: April 2003 October 2002 7. References [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 Shin Gak Kang Email: sgkang@etri.re.kr Protocol Engineering Center Electronics Telecommunications Research Institute, KOREA Dae Young Kim dykim@cnu.ac.kr Department of Information Communication Enginnering Chung Nam National University, KOREA S.Koh, et al. draft-koh-omcp-00.txt [Page 15]
INTERNET-DRAFT Expires: April 2003 October 2002 Full Copyright Statement "Copyright (C) The Internet Society (2000). 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." S.Koh, et al. draft-koh-omcp-00.txt [Page 16]