Internet DRAFT - draft-sijeon-mext-dmm-mc
draft-sijeon-mext-dmm-mc
Network working group Seil Jeon
Internet Draft Younghan Kim
Intended status: Informational Track Soongsil University
Expires: April 23, 2012 October 24, 2011
Multicast services support for distributed mobility architecture
draft-sijeon-mext-dmm-mc-00.txt
Abstract
IP multicasting is expected to become essential technique for mobile
video services. As the mobility management is being covered with
distributed manner, corresponding IP multicasting is also required to
fit the distributed manner. This document specifies IP multicasting
support method and procedures for distributed mobility architecture.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 23, 2012.
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
Seil Jeon et al. Expires April 23, 2012 [Page 1]
Internet-Draft Multicast services in DMM October 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Overview .................................................... 3
4. Protocol operation .......................................... 4
4.1. Initial attach ......................................... 4
4.2. Handover ............................................... 5
5. Security Considerations ..................................... 6
6. IANA Considerations ......................................... 6
7. References .................................................. 6
7.1. Normative References ................................... 6
7.2. Informative References ................................. 7
1. Introduction
As mobile traffic greatly increases, the distributed mobility
management (DMM) is highly being in the spotlight as a next-
generation mobility solution.
IP multicasting is essential technique to facilitate real-time
streaming services e.g. mobile IPTV, hence it should also be
available under the DMM.
Anchor node in DMM becomes changed for the mobile nodes (MNs)
whenever they are moving towards another access router, while the
anchor node is dedicated in centralized mobility management. This
difference should be reflected for designing IP multicast into DMM.
In other words, which router should provide multicast stream to
anchor node the MN currently attach to e.g. multicast router or
previous anchor node and who does decide.
In this document, we offer basic multicast support method in
distributed mobility management by using mobility information server
managing multicast channel for each anchor node.
Seil Jeon et al. Expires April 23, 2012 [Page 2]
Internet-Draft Multicast services in DMM October 2011
2. Terminology
o MMAA (Mobility Anchor and Access Agent): access router to which a
mobile node connects. MLD proxy function defined in [RFC 4605] is
operated on the MMAA.
o MIS (Mobility Information Server): it stores the information of an
MN at which is attached and what channel it is receiving if the MN
gets IP multicasting serviced. The MMIS has a decision engine for
each MMAA to support efficient multicast traffic delivery.
o MTD (Multicast Traffic Distributor): for receiving multicast data,
each MMAA should be connected to the one among a multicast router or
a MMAA depending on the decision of MMIS.
o Proxy Channel Registration (PCR): it is transmitted to the MMIS by
a MMAA and used to report multicast information on the MMAA in use.
Specifically, it is {channel, multicast traffic distributor
connected}.
o Proxy Channel Acknowledgement (PCA): it is transmitted to the MMAA
by the MMIS and used to.
3. Overview
+------+
| MTD |
+------+
|
********************
+----+ * *
|MIS |-----* Fixed Internet *
+----+ * *
********************
| |
+----+ +----+
|MMAA| |MMAA|
+----+ +----+
Figure 1 Proposed architecture for DMM multicast
Seil Jeon et al. Expires April 23, 2012 [Page 3]
Internet-Draft Multicast services in DMM October 2011
To support IP multicasting in DMM, all MMAAs are required to have MLD
proxy function so they need to connect to multicast traffic
distributor (MTD) defined in this document. The MTD may be multicast
router (MR) or the multicast source directly. In the case of mobile
node (MN)'s handoff, the MMAA where the MN attach connects to the MR
or previous MMAA using tunneling mechanism for seamless multicast
handoff. DMM multicasting requires the method how and where current
MMAA will retrieve multicast stream from.
4. Protocol operation
4.1. Initial attach
MN MMAA MIS MTD
| | | |
| MN attach | |
| | | |
| |----- PBU ---->| |
| | | |
| |<---- PBA -----| |
| | | |
| | | |
|<-MLD Query---| | |
| | | |
|--MLD Report->| | |
| | | |
| |-----Aggregated MLD Report--->|
| | | |
| | | |
| |--- PC Req.--->| |
| |{"G1",MTD-Addr}| |
| | | |
| |<---PC Ack.----| |
| |{"G1",MTD-Addr}| |
| | | |
Figure 2 Initial attach
Once MMAA detect MN's attachment, it transmits PBU message on behalf
of the MN to MIS that manages all the MN's information. The MIS sends
back PBA message to current MMAA. The MMAA sends General MLD Query to
Seil Jeon et al. Expires April 23, 2012 [Page 4]
Internet-Draft Multicast services in DMM October 2011
the MN. The MN transmits MLD Report message to the MMAA. Then, the
MMAA sends aggregated MLD Report to the MTD. If the MMAA has no
multicast listener, the MTD is MR or content source natively. After
the MMAA starts multicast services, it SHOULD register and report its
service status including what kind of channel is serviced and its
corresponding MTD address to the MIS.
4.2. Handover
MMAA1 MIS MMAA2 MR MN
| | | | |
| | | | |
|<--BCE Update---|<---- PBU -----| | |
| Reg. | | | |
| | | | |
|---BCE Update-->|----- PBA ---->| | |
| Ack. |{"G1",MTD-Addr}| | |
| | | | |
| | | | |
| | |-------- MLD Query --------->|
| | | | |
| | |<------- MLD Report----------|
| | | | |
| | |--Aggregated->| |
| | | MLD Report | |
| | | | |
| |<-- PC Reg.----| | |
| |{"G1",MTD-Addr}| | |
| | | | |
| |--- PC Ack.--->| | |
| |{"G1",MTD-Addr}| | |
| | | | |
Figure 3 Handoff procedure
Once the MN moves to MMAA2 from MMAA1, the MMAA2 transmits PBU
message to the MIS. The MIS knowing previous MMAA where the MN stayed
makes the MMAA1's BCE updated and gets multicast information the MN
listened. Through the interaction between the MIS and MMAA1, the MIS
transmits PBA message including channel information "G1" and
corresponding MTD address to the MMAA2. Figure 3 assumed that there
are no multicast listeners in MMAA2 for same multicast group "G1"
Seil Jeon et al. Expires April 23, 2012 [Page 5]
Internet-Draft Multicast services in DMM October 2011
before MN's arrival. So, the MTD for the MN is MR. Through the
interaction of MLD Query/Report message, the MMAA2 sends aggregated
MLD Report message to the MR. If there is a multicast listener for
group "G1", the MIS will give existing MTD address in use to the
MMAA2 to avoid duplicated multicast traffic. This decision is made on
the MIS. If the MTD determined by the MIS is the MMAA1, the MMAA2
establishes the tunnel with the MMAA1 to retrieve multicast data.
After the MMAA2 joins multicast channel complete by sending
aggregated MLD Report, it registers current multicast channel
serviced currently to the MIS with proxy channel registration (PCR)
message. Then, it receives proxy channel acknowledgment (PCA) message.
5. Security Considerations
TBD.
6. IANA Considerations
TBD.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC4605] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet
Group Management Protocol (IGMP) / Multicast Listener
Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD
Proxying")", IETF RFC 4605, August 2006.
[RFC6424] T. Schmidt, M. Waehlisch, and S. Krishnan, "Base Deployment
for Multicast Listener Support in PMIPv6 Domains", IETF RFC
6424, April 2011.
Seil Jeon et al. Expires April 23, 2012 [Page 6]
Internet-Draft Multicast services in DMM October 2011
[RFC3810] R. Vida and L. Costa, "Multicast Listener Discovery Version
2 (MLDv2) for IPv6", RFC 3810, June 2004.
7.2. Informative References
[I-D.chan-distributed-mobility-ps]
A. Chan, "Problem statement for distributed and dynamic
mobility management", draft-chan-distributed-mobility-ps-03
(work in progress), July 2011.
Seil Jeon et al. Expires April 23, 2012 [Page 7]
Internet-Draft Multicast services in DMM October 2011
Authors' Addresses
Seil Jeon
Soongsil University
Email: sijeon@dcn.ssu.ac.kr
URI: http://sites.google.com/site/seiljeon
Younghan Kim
Soongsil University
Email: younghak@ssu.ac.kr
Seil Jeon et al. Expires April 23, 2012 [Page 8]