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]