[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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


   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

   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


6. IANA Considerations


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


         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]