Internet Draft Seok Joo Koh
Internet Engineering Task Force ETRI
February 2003 Juyoung Park
Expires August 2003 ETRI
Framework of Overlay Multicast Control Protocol
<draft-sjkoh-overlay-multicast-framework-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 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]