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 <Title> 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]