INTERNET-DRAFT Dae Young Kim Intended status: Informational Chungnam National University Expires: February 2010 Jae Wan Park, Seok Joo Koh Kyungpook National University August 20, 2009 Mobile Multicast Control Protocol in Wireless/Mobile Networks draft-dykim-mmcp-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 This Internet-Draft will expire on February 20, 2009. Kim, Park and Koh Expires February 20, 2010 [Page 1] Internet-Draft August 2009 Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document is a part of the ITU-T Recommendation and ISO/IEC International Standard, named the Mobile Multicast Communications Protocol (MMCP). The MMCP is a protocol that can be used to support a variety of multimedia multicasting services in the IP-based wireless mobile networks. The MMCP is targeted at the real-time one-to-many multicast services and applications over mobile communications networks. Kim, Park and Koh Expires February 20, 2010 [Page 2] Internet-Draft <Title> August 2009 Table of Contents 1. Introduction...................................................4 2. Terminology....................................................4 2.1. Abbreviations.............................................4 2.2. Conventions...............................................5 3. Protocol Overview..............................................5 4. Design Considerations..........................................6 4.1. Design Principles.........................................6 4.2. Functional Entities.......................................6 4.2.1. Mobile Node (MN).....................................6 4.2.2. Multicast Contents Server (MCS)......................6 4.2.3. Session Manager (SM).................................7 4.2.4. Local Mobility Controller (LMC)......................7 5. Packets........................................................8 5.1. Base Header...............................................8 5.2. Packet Formats...........................................10 6. Procedures....................................................11 6.1. Session Join.............................................11 6.2. User Leave...............................................11 6.3. Status Monitoring........................................11 6.4. Mobility Support.........................................12 7. Conclusions...................................................12 8. References....................................................13 8.1. Normative References.....................................13 8.2. Informative References...................................13 Author's Addresses...............................................13 Kim, Park and Koh Expires February 20, 2010 [Page 3] Internet-Draft <Title> August 2009 1. Introduction This document is a part of the ITU-T Recommendation and ISO/IEC International Standard, named the Mobile Multicast Communications Protocol (MMCP). The MMCP is a protocol that can be used to support a variety of multimedia multicasting services in the IP-based wireless mobile networks. The MMCP is targeted at the real-time one-to-many multicast services and applications over mobile communications networks. In MMCP, Session Manager is at the heart of multicast communications. It is responsible for overall control by governing the session join and handover support operations. The MMCP has a characteristic as follows. The MMCP operates on the IP-based network. The MMCP easy integrates the existing IP-based schemes and protocols required for realization of the MMC services. And MMCP has separation of the control channel from the data channel. 2. Terminology 2.1. Abbreviations AP Access Point AS Authentication Server IGMP Internet Group Management Protocol IP Internet Protocol LMC Local Mobility Controller MCS Multicast Contents Server MLD Multicast Listener Discovery MMC Mobile Multicast Communications MMCF MMC Framework MN Mobile Node PoA Point of Attachment Kim, Park and Koh Expires February 20, 2010 [Page 4] Internet-Draft <Title> August 2009 SM Session Manager WiBro Wireless Broadband WLAN Wireless Local Area Network 2.2. Conventions In this document, the capital characters are used to represent a packet of MMCP (e.g., SJR for Session Join Request packet), and the capital and italic characters are used for timer used in MMCP (e.g., JWT for Join Waiting Timer). 3. Protocol Overview The MMCP is Mobile Multicast Control Protocol, which is based on the Mobile Multicast Communications Framework (MMCF). MMCP designed to support one-to-many multicast applications running over multicast- capable networks. MMCP operates over IPv4/IPv6 networks that have the IP multicast forwarding capability with the help of IGMP and IP multicast routing protocols. MMCP considers real-time service and handover schemes. MMCP could possibly be provisioned over UDP or TCP. + + +--------------------------------+ | | Multicast Applications | | +----------------+ + | | MMCP | | | +----------------+---------------+ | | UDP | | +--------------------------------+ | | IP | | +--------------------------------+ | | Control Channel Data Transport Channel Figure 1. MMCP Protocol Model A Multicast Contents Server (MCS) transmits multicast data to many Mobile Nodes (MNs) using the legacy UDP/IP multicasting. For the control purpose of the multicast data transport, a MMCP session is Kim, Park and Koh Expires February 20, 2010 [Page 5] Internet-Draft <Title> August 2009 established between a Session Manager (SM) and MNs, possibly with one or more Local Mobility Controllers (LMCs) between SM and MNs. The SM is used to perform the overall control operations for the MMCP session, and it shall be interworking with MCS. The LMC is used to locally control a part of MNs participating in the session, which is for scalability enhancement of the MMCP operations. Each MN represents a receiving user for mobile multicast applications. 4. Design Considerations This section describes some considerations for the design of MMCP. 4.1. Design Principles This section describes the design of the MMCP for MMC services and applications over wireless mobile networks as well as the fixed communications networks. For this purpose, the MMCP shall be designed with the following design principles: - Generic IP-based control schemes for MMC - Easy integration of legacy multicast applications with MMCP - Separation of the control channel from the data channel - Interworking with the conventional protocols for security and authentication/authorization 4.2. Functional Entities 4.2.1. Mobile Node (MN) A Mobile Node represents a multicast receiving user for the mobile multicast application in the MMC networks. A MN will receive the MMC services from the Multicast Contents Server (MCS) in the network using the MMCP. Each MN may connect to the MMC session from the wireless or wired access networks. In either case, the identical MMC services will be provided. 4.2.2. Multicast Contents Server (MCS) The Multicast Contents Server is a single multicast data sender in a MMC session. When a MMC session starts, the MCS will begin to send the multicast data to the promising MNs in the network, using IP multicast. Kim, Park and Koh Expires February 20, 2010 [Page 6] Internet-Draft <Title> August 2009 4.2.3. Session Manager (SM) The Session Manager is a functional entity that performs the overall control operations for a MMC session. The SM shall be interworking with the corresponding MCS for the MMC session. The authentication and authorization step for a newly joining MN will possibly be implemented by interworking with an appropriate AAA server. The SM may be implemented either on the same machine with MCS or separately on the different machine. It is noted that the SM and MCS perform the different functionality. SM manages the overall control functionality for the MMC session, whereas the MCS is the multicast sender in the data transport plane. 4.2.4. Local Mobility Controller (LMC) For scalability of the MMC functional operations and also for any reason of deployment of MMC services, one or more Local Mobility Controller may be used for the session. From the functionality point of view, the SM and LMC are identical during the session. When a MN contacts with the SM to join a MMC session, the SM may assign an appropriate LMC to the MN, after processing the session join procedure. After that, the MN will now contact with the LMC instead of the SM for all of the MMC control operations. That is, during the session, the LMC is responsible for the control operations (status monitoring and mobility support) through interworking with the MNs. The monitored status information on the session and MNs will be delivered to the SM. Kim, Park and Koh Expires February 20, 2010 [Page 7] Internet-Draft <Title> August 2009 5. Packets A MMCP packet contains a 12-byte base header together with body packets. In this section, we describe a brief sketch of the MMCP packet format. 5.1. Base Header The base header contains the following information: Packet Type (8bits) It indicates the type of this MMCP packet. The encoding values of the MMCP packets are described in Table 1. MMCP Version (4bits) This field indicates the version of MMCP. At present, the value is v.1 (0001). MN Length (4bits) This value indicates the length of the MMC user identification in word. Unit of word is 4-bytes. Payload Length (16bits) This value indicates the total length of the body in byte, following the base header. Error Code (6bits) It is an error code bit for representation of the MMCP protocol error: No Error (000000) Session Join Reject (000001) Monitoring Error (000010) Handover Error (000100) N (1bit) Kim, Park and Koh Expires February 20, 2010 [Page 8] Internet-Draft <Title> August 2009 It is a flag bit for new LMC address. The use of this flag depends on the packet types: For the SJC (Session Join Confirm), the HIC (Handover Initiation Confirm) packets, the N is set to 1 indicates that new Local Mobility Controller address is exist. N is set to 0, otherwise. F (1bit) It is a flag bit for confirm message. The use of this flag depends on the packet types: For the SJC (Session Join Confirm), LJC (Local Join Confirm), ULC (User Leave Confirm), HIC (Handover Initiation Confirm) packets, the F is set to 1 indicates that each of the corresponding request is accepted. F is set to 0, otherwise. Reserved (24bits) This field is reserved for future use. Session ID (32bits) This field is used to identify a MMCP session by the Mobile Node. It may also be used to verify the session. In the session setup phase, this information must first be informed by Session Manager. Kim, Park and Koh Expires February 20, 2010 [Page 9] Internet-Draft <Title> August 2009 5.2. Packet Formats MMCP defines the total 15 packet types, as follows. Table 1. MMCP Packets +-------------------------------------------------------------------+ | Full Name |Acronym | Encoding | From | To | | | | Value | | | +-------------------------------------------------------------------+ | Session Join Request | SJR | 0000 0001 | MN | SM | +-------------------------------------------------------------------+ | Session Join Confirm | SJC | 0000 0010 | SM | MN | +-------------------------------------------------------------------+ | Local Join Request | LJR | 0000 0011 | MN | LMC | +-------------------------------------------------------------------+ | Local Join Confirm | LJC | 0000 0100 | LMC | MN | +-------------------------------------------------------------------+ | User Leave Request | ULR | 0000 0101 | MN | LMC | +-------------------------------------------------------------------+ | User Leave Confirm | ULC | 0000 0110 | LMC | MN | +-------------------------------------------------------------------+ | User Status Report | USR | 0000 0111 | MN | LMC or SM | +-------------------------------------------------------------------+ | Aggregation Status | ASR | 0000 1000 | LMC | SM | | Report | | | | | +-------------------------------------------------------------------+ | Status Report ACK | SRA | 0000 1001 | LMC | MN | | | | | SM | LMC or MN | +-------------------------------------------------------------------+ | User Status Probe | USP | 0000 1010 | LMC | MN | | | | | SM | LMC or MN | +-------------------------------------------------------------------+ | Handover Initiation | HIR | 0000 1011 | MN | LMC or SM | | Request | | | | | +-------------------------------------------------------------------+ | Handover Initiation | HIP | 0000 1100 | LMC | MN | | Progress | | | | | +-------------------------------------------------------------------+ | Handover Context | HCT | 0000 1101 | Old LMC | New LMC | | Transfer | | | | | +-------------------------------------------------------------------+ | Handover Transfer ACK| HTA | 0000 1110 | New LMC | Old LMC | +-------------------------------------------------------------------+ | Handover Initiation | HIC | 0000 1111 | LMC or SM | MN | | Confirm | | | | | +-------------------------------------------------------------------+ Kim, Park and Koh Expires February 20, 2010 [Page 10] Internet-Draft <Title> August 2009 6. Procedures 6.1. Session Join Session Join is procedure that MN receives multicast content from MCS. After Session Join procedure is divided into two scenarios. It is that either LMC exist or not. First of all, the scenario is that LMC exist as follow. MN sends a SJR message to the SM for Session Join. When the SM receives the SJR message, the SM identifies an authenticated user from Authentication Server (AS) and database. Authentication processing is used by AS and DB, which is out of scope. If MN is an authenticated user, the SM sends a SJC message that includes setting f flag to 1 at base header of packet and MCS, LMC information at body of packet. The MN sends a LJR message to address of received LMC. After join processing, the LMC sends corresponding LJC message to MN. This procedure finishes a Session Join. If MN is not an authenticated user, the SM sends a SJC message that includes setting f flag to 0 at base header packet only. The Session Join procedure is operating Join Waiting Time (JWT). The Session Join procedures shall be finished until JWT timer is expired. If JWT timer is expired, MN considers that Session Join procedure is failed. 6.2. User Leave User Leave is procedure that user leave session when receives content. MN sends an ULR message to LMC. After leave processing, the LMC sends an ULC message to MN. 6.3. Status Monitoring Status Monitoring is procedure for identifying status of the MNs or LMCs and checking the handover information. And it sends QoS information to upper controller. Status Monitoring is classified two scenarios, LMC exist and LMC does not exist. First of all, the scenario is that LMC exist as follow. MN sends an USR message to the LMC for Status Monitoring. The MN sends periodically the USR message to the LMC by Status Report Generation Time (SCT) of the MN. When the LMC receives the USR message, the LMC sends a SRA message to the MN for response. In order to SM has information of MNs, the LMC sends an ASR message to the SM. The ASR message is aggregated with information of MNs. The LMC also sends periodically the ASR message to the SM by SGT timer of Kim, Park and Koh Expires February 20, 2010 [Page 11] Internet-Draft <Title> August 2009 the LMC. When the SM receives the ASR message, the SM sends a SRA message to the LM for response. The LMC and SM operate Status Probe Time (SPT). If the LMC does not receive an USR message from the MN or the SM does not receive an ASR message from the LMC by expired SPT timer, the LMC or SM will send the USP message to the MN or LMC. If the responding USR or ASR message has not arrived until RXT timer expires, the LMC or SM retransmit USR or ASR message. The MN or LMC regards termination, if MN or LMC does not response for four sending USR or ASR message. 6.4. Mobility Support In handover operation, the MN will send a HIR message to old LMC and waits for the HIC message until the Handover Waiting Time (HWT) expires. The old LMC sends a HIP message to the MN and finds new LMC for the information of the MN to transmit. The old LMC sends a HCT message to new LMC and waits for the HTA message until the RXT timer expires. The new LMC updates transmitted information of the MN from old LMC, and then sends a HTA message to old LMC. The old LMC receives the HTA message, then sends the HIC message to the MN if the responding HIC message has not arrived until HWT timer expires, the MN may send the HIR message again. And if the responding HTA message has not arrived until RXT timer expires, the old LMC may send the HCT message again. The MN will send a LJR message to the new LMC and waits for the LJC message until the RXT timer expires. When the new LMC received the LJR message, the new LMC sends an ASR message to the SM at next transmission time. The SM updates modified information of the new LMC, and then sends a SPA message to the new LMC. 7. Conclusions This document describes the Mobile Multicast Communications Protocol (MMCP). The MMCP is a protocol that can be used to support a variety of multimedia multicasting services in the IP-based wireless mobile networks. The MMCP is targeted at the real-time one-to-many multicast services and applications over mobile communications networks. The MMCP benefits are that the MMCP is integrated with legacy multicast applications and used for separation the control channel from the data channel. Kim, Park and Koh Expires February 20, 2010 [Page 12] Internet-Draft <Title> August 2009 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [1] ITU-T Recommendation X.603 (2004) | ISO/IEC 16512-1:2004, Information Technology - Relayed Multicast Protocol (RMCP): Framework [2] ITU-T Recommendation X.603.1 | ISO/IEC 16512-2, Information Technology - Relayed Multicast Protocol (RMCP): Specification for Simplex Group Applications [3] ITU-T Recommendation X.606 (2001) | ISO/IEC 14476-1:2002, Information Technology - Enhanced Communications Transport Protocol (ECTP): Specification of Simplex Multicast Transport [4] ITU-T Recommendation X.606.1 (2002) | ISO/IEC 14476-2:2003, Information Technology - Enhanced Communications Transport Protocol (ECTP): Specification of QoS Management for Simplex Multicast Transport Author's Addresses Dae Young Kim Chungnam National University, KOREA Email: dykim@cnu.ac.kr Jae Wand Park and Seok Joo Koh Kyungpook National University, KOREA Email: sjkoh@knu.ac.kr Kim, Park and Koh Expires February 20, 2010 [Page 13]