Internet Draft Jae Sung Park Intended status: Informational Kyungpook National University Expires: November 2007 Seok Joo Koh May 21, 2007 Kyungpook National University MMCP for IP Multicast in Mobile Networks draft-jspark-mmcp-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 only be posted in an Internet-Draft. 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 November 21, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Park and Koh Expires November 21, 2007 [Page 1] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 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. Park and Koh Expires November 21, 2007 [Page 2] Internet Draft Jae Sung Park Intended status: Informational Kyungpook National University Expires: November 2007 Seok Joo Koh May 21, 2007 Kyungpook National University Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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. Table of Contents 1. Introduction...................................................5 2. Terminology....................................................5 2.1. Abbreviations.............................................5 2.2. Conventions...............................................6 3. Protocol Overview..............................................6 4. Design Considerations..........................................7 4.1. Design Principles.........................................7 4.2. Functional Entities.......................................8 4.2.1. Mobile Node (MN).....................................8 4.2.2. Multicast Contents Server (MCS)......................8 4.2.3. Session Manager (SM).................................8 4.2.4. Local Mobility Controller (LMC)......................8 5. Packets........................................................9 5.1. Base Header...............................................9 5.2. Packet Formats...........................................10 6. Procedures....................................................11 6.1. Session Join.............................................11 6.2. User Leave...............................................12 6.3. Status Monitoring........................................12 6.4. Mobility Support.........................................13 7. Security Considerations.......................................13 8. IANA Considerations...........................................13 9. Conclusions...................................................13 10. Acknowledgments..............................................13 APPENDIX A: Timers...............................................14 A.1. JWT (Join Waiting Time)..................................14 A.2. SGT (Status Report Generation Time)......................14 A.3. SPT (Status Probe Time)..................................14 Park and Koh Expires November 21, 2007 [Page 3] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 A.4. HWT (Handover Waiting Time)..............................14 A.5. RXT (Retransmission Time)................................14 11. References...................................................16 11.1. Normative References....................................16 11.2. Informative References..................................16 Author's Addresses...............................................16 Intellectual Property Statement..................................16 Disclaimer of Validity...........................................17 Park and Koh Expires November 21, 2007 [Page 4] Internet Draft Jae Sung Park Intended status: Informational Kyungpook National University Expires: November 2007 Seok Joo Koh May 21, 2007 Kyungpook National University 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. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices. Copyright (C) The IETF Trust (2007). The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html. 2. Terminology 2.1. Abbreviations AAA Authentication, Authorization, and Accounting AP Access Point AS Authentication Server IGMP Internet Group Management Protocol Park and Koh Expires November 21, 2007 [Page 5] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 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 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 | | | +----------------+---------------+ Park and Koh Expires November 21, 2007 [Page 6] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 | | 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 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 Park and Koh Expires November 21, 2007 [Page 7] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 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. 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 Park and Koh Expires November 21, 2007 [Page 8] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 interworking with the MNs. The monitored status information on the session and MNs will be delivered to the SM. 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) Park and Koh Expires November 21, 2007 [Page 9] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 Handover Error (000100) N (1bit) 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. 5.2. Packet Formats MMCP defines the total 15 packet types. The following table summarizes the packets used in MMCP. 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 | Park and Koh Expires November 21, 2007 [Page 10] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 +-------------------------------------------------------------------+ | 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 | | | | | +-------------------------------------------------------------------+ 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 Park and Koh Expires November 21, 2007 [Page 11] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 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 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. Park and Koh Expires November 21, 2007 [Page 12] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 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. Security Considerations TBD 8. IANA Considerations TBD 9. 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. 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Park and Koh Expires November 21, 2007 [Page 13] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 APPENDIX A: Timers This appendix summarizes the timers used for MMCP for information. A.1. JWT (Join Waiting Time) The JWT timer is used for session join procedures. When session starts, MN will send a SJR packet to the SM. and the MN waits for the SJC packet until the JWT timer expires. If LMC exist, MN will send a LJR packet to the LMC. And the MN waits for the LJC packet until the JWT timer expires. When the timer expires and the corresponding packet has not arrived until then, it may consider that session join procedure is failed. A specific value of JWT timer depends on the implementation. A.2. SGT (Status Report Generation Time) Each MN or LMC transmits the USR packet to its upper system every SGT timer. If upper system does not receive the USR packet, upper system will send an USP packet to the lower system. A specific value of SGT timer depends on the implementation. A.3. SPT (Status Probe Time) An USP packet is message that LMC or SM checks MN or LMC alive. If the USR packet does not receive until SPT timer expires, USP packet sends. A specific value of SPT timer depends on the implementation. A.4. HWT (Handover Waiting Time) The HWT timer is used by handover packet: HIR. When handover starts, MN will send HIR packet to LMC or SM. And the MN waits for the HIC packet until the HWT timer expires. When the timer expires and the corresponding packet has not arrived until then, it may send the HIR packet again. A specific value of HWT timer depends on the implementation. A.5. RXT (Retransmission Time) The RXT timer is used by the packet initiator to wait for the corresponding confirm packet or ACK packet. For example, a joiner MN sends SJR packet to SM and the MN waits for the SJC packet until the Park and Koh Expires November 21, 2007 [Page 14] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 RXT timer expires. When the timer expires and the confirm packet has not arrived until then, it may send the request packet again. A specific value of RXT timer depends on the implementation. Park and Koh Expires November 21, 2007 [Page 15] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.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 Jae Sung Park Kyungpook National University, KOREA 1370 Sankyuk-dong, Buk-gu, Daegu 702-701, Korea Email: knucsid@gmail.com Seok Joo Koh Kyungpook National University, KOREA 1370 Sankyuk-dong, Buk-gu, Daegu 702-701, Korea Email: sjkoh@knu.ac.kr Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in Park and Koh Expires November 21, 2007 [Page 16] Internet-Draft MMCP for IP Multicast in Mobile Networks May 2007 this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Park and Koh Expires November 21, 2007 [Page 17]