[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
 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]