Skip to main content

Context Transfer Protocol Extension for Multicast
draft-vonhugo-multimob-cxtp-extension-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Dirk Von Hugo , Hitoshi Asaeda
Last updated 2012-08-15
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-vonhugo-multimob-cxtp-extension-02
MULTIMOB Group                                               D. von Hugo
Internet-Draft                           Telekom Innovation Laboratories
Expires: February 16, 2013                                     H. Asaeda
                                                         Keio University
                                                         August 15, 2012

           Context Transfer Protocol Extension for Multicast
                draft-vonhugo-multimob-cxtp-extension-02

Abstract

   This document describes an extension of the Context Transfer Protocol
   (CXTP) to support seamless IP multicast services with Proxy Mobile
   IPv6 (PMIPv6).

Status of this Memo

   This Internet-Draft is submitted 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 February 16, 2013.

Copyright Notice

   Copyright (c) 2012 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
   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.

von Hugo & Asaeda       Expires February 16, 2013               [Page 1]
Internet-Draft        CXTP Extension for Multicast           August 2012

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  4
   3.  Handover Process . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Multicast Context Transfer Data Format . . . . . . . . . .  5
     3.2.  Multicast Context Transfer with MLD Proxy  . . . . . . . .  6
     3.3.  Multicast Context Transfer with PIM-SM . . . . . . . . . .  9
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

von Hugo & Asaeda       Expires February 16, 2013               [Page 2]
Internet-Draft        CXTP Extension for Multicast           August 2012

1.  Introduction

   This document describes an extension of the Context Transfer Protocol
   (CXTP) [9] to provide seamless handover for multicast communications
   operated with Proxy Mobile IPv6 (PMIPv6) [2].  When a mobile node
   receiving multicast data detaches from the current MAG and attaches
   to a new MAG, the node should be able to continuously receive the
   multicast data through the new MAG just after the node completed
   handover without any MLD signaling on the new wireless link.  This
   procedure is multicast context transfer that provides multicast
   session continuity and avoids extra packet loss and session
   disruption.  Multicast context transfer will be the required function
   to support seamless handover, while for its effective procedure,
   interaction with multicast communication protocols should be taken
   into account.

   The Context Transfer Protocol (CXTP) specification [9] describes the
   mechanism that allows better support for minimizing service
   disruption during handover.  In this document, CXTP is extended for
   the multicast context transfer protocol in PMIPv6.  "Multicast-
   Context Transfer Data (M-CTD)" is defined for transferring multicast
   membership state from a previously attached MAG (p-MAG) to a newly
   attached MAG (n-MAG) for PMIPv6.  The context transfer is either
   started from the n-MAG on its own after attachment of the mobile node
   or initiated by the p-MAG after being informed by the access network
   of the planned handover.  For data exchange between p-MAG and n-MAG a
   dedicated tunnel is assumed to be in place.  Whether this p-MAG -
   n-MAG tunnel has already been set up in advance or will be initiated
   during handover by either p-MAG or n-MAG will impact the overall
   session delay.  Details of this set-up procedure are out of scope of
   this document.

   An approach to apply CXTP to multicast for client-based mobile IPv6
   had been proposed in [13].

von Hugo & Asaeda       Expires February 16, 2013               [Page 3]
Internet-Draft        CXTP Extension for Multicast           August 2012

2.  Conventions and Terminology

   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 [1].

   The following terms used in this document are to be interpreted as
   defined in the Proxy Mobile IPv6 specification [2]; Mobile Access
   Gateway (MAG), Local Mobility Anchor (LMA), Mobile Node (MN), Proxy
   Mobile IPv6 Domain (PMIPv6-Domain), LMA Address (LMAA), Proxy Care-of
   Address (Proxy-CoA), Mobile Node's Home Network Prefix (MN-HNP),
   Mobile Node Identifier (MN-Identifier), Proxy Binding Update (PBU),
   and Proxy Binding Acknowledgement (PBA).

von Hugo & Asaeda       Expires February 16, 2013               [Page 4]
Internet-Draft        CXTP Extension for Multicast           August 2012

3.  Handover Process

   MAG is responsible for detecting the mobile node's movements to and
   from the access link and for initiating binding registrations to the
   mobile node's LMA.  MAG tracks the mobile node's movements to and
   from the access link and performs signaling of the status to the
   mobile node's LMA.  In PMIPv6, it SHOULD NOT be required for mobile
   nodes to initiate re-subscription to multicast channels, and MAG
   SHOULD keep multicast membership state for mobile nodes even if they
   attach a different MAG in PMIPv6-Domain.

   For multicast context transfer, an IGMP/MLD-based explicit membership
   tracking function [11] MUST be enabled on MAG (whether the MAG
   behaves as a router or proxy).  The explicit tracking function
   enables a router to keep track of downstream multicast membership
   state created by downstream hosts attached on the router's link.
   When a mobile node attaches to a new network, thanks to the explicit
   tracking function, the p-MAG extracts the mobile node's multicast
   membership state from complete multicast membership state the p-MAG
   has maintained and transmits it to the n-MAG.

3.1.  Multicast Context Transfer Data Format

   Multicast Context Transfer Data (M-CTD) is a message used with CXTP
   to transfer multicast membership state from p-MAG to n-MAG.  The
   following information is included in M-CTD to recognize mobile node's
   membership state.

   1.   Receiver address - indicates the address of the MN sending the
        Current-State Report.

   2.   Filter mode - indicates either INCLUDE or EXCLUDE as defined in
        [4].

   3.   Source addresses and multicast addresses - indicates the address
        pairs the MN has joined.

   The M-CTD message MUST contain the 'A' bit set as defined for the CTD
   message format in [9] for to initiate the transmission of a reply
   message by the new MAG.

   The following information included in a reply to M-CTD (similar to
   the CTDR message defined in [9]) is used to request the old MAG to
   store still incoming multicast data, to forward them to the new MAG,
   and finally to leave the multicast group after successful handover
   from n-MAG to p-MAG.

von Hugo & Asaeda       Expires February 16, 2013               [Page 5]
Internet-Draft        CXTP Extension for Multicast           August 2012

   1.   Receiver address - indicates the address of the MN sending the
        Current-State Report.

   2.   Flag indicating the p-MAG to start (B) buffering the received
        multicast data (in case the new connection is not yet fully set
        up), to forward (F) the buffered data after successful handover,
        or to leave (L) the multicast groups unless there are still
        other active subscriptions for the corresponding groups on the
        p-MAG.

   3.   Source addresses and multicast addresses - indicates the address
        pairs the MN has joined.

   The M-CTDR message MUST contain the 'S' bit set as defined for the
   CTD message format in [9] for to indicate the successful reception of
   context data at the new MAG.

   The explicit tracking function [11] does not maintain information of
   an (S,G) join request with EXCLUDE filter mode.  Therefore, when the
   "Filter mode" for a multicast session is EXCLUDE, "Source address"
   for the session MUST be set "Null".

3.2.  Multicast Context Transfer with MLD Proxy

   This section describes the case that MAG operates as an MLD proxy, as
   defined in [6] and specified in the base MultiMob solution [10].

   The MLD listener handover with CXTP and MLD proxy shown in Figure 1
   is defined as follows.

   1.   After attaching a new MAG, a mobile node sends a Router
        Solicitation (RS) as specified in [7].  As the MN shall remain
        unaware of any change in connectivity the n-MAG has to identify
        the p-MAG address during proxy binding registration process with
        the mobile node's LMA. n-MAG then sends a request for context
        transfer (CT-Req) to the p-MAG as defined in [9].  Since the MN
        cannot initiate the related Context Transfer Activate Request
        (CTAR) message that may be sent by the LMA.  In case the mobile
        node has the capability and the chance to signal to the p-MAG
        the link status and the potential new MAG address (e.g. as is
        specified in terms of Event Services by [8]) the p-MAG will send
        a CTAR message to n-MAG on behalf of the mobile node.
        Alternatively the p-MAG or the n-MAG may have information on
        potential MAGs in their vicinity to which such a CTAR or CT-Req
        message may be multicasted.

von Hugo & Asaeda       Expires February 16, 2013               [Page 6]
Internet-Draft        CXTP Extension for Multicast           August 2012

   2.   p-MAG provides together with the other feature data the
        multicast states corresponding to the moving MN-Identifier to
        n-MAG. p-MAG utilizes a context transfer protocol to deliver
        MN's Policy Profile to n-MAG, and sends Multicast Context
        Transfer Data (M-CTD) (defined in Section 3.1) to n-MAG.

   3.   If there are multicast channels the MN has subscribed but the
        n-MAG has not yet subscribed, n-MAG subscribes via sending
        (potentially aggregated) MLD [4][5] Membership Report messages
        (i.e.  Join) to the corresponding LMA.

   4.   n-MAG requests from p-MAG to store still incoming multicast data
        for transfer to MN after successful handover completion.  For
        this purpose a newly defined B-flag in the Multicast Context
        Transfer Response message is sent from n-MAG to p-MAG, denoted
        as M-CTDR(B).

   5.   After successful completion of MN attachment to n-MAG the
        forwarding of the stored Multicast data from p-MAG to n-MAG is
        initiated via sending a Multicast Context Transfer Response
        message with a newly defined F-flag from n-MAG to p-MAG, denoted
        as M-CTDR(F).

   6.   LMA forwards requested multicast data to the n-MAG which
        subsequently delivers them to MN.

   7.   n-MAG may request from p-MAG to leave those multicast groups it
        had subscribed to on behalf of the MN where MN had been the last
        member.  This is done via sending a Multicast Context Transfer
        Response message from n-MAG to p-MAG with a newly defined L-flag
        set, denoted as M-CTDR(L).

von Hugo & Asaeda       Expires February 16, 2013               [Page 7]
Internet-Draft        CXTP Extension for Multicast           August 2012

          MN           p-MAG               n-MAG                LMA
           |             |                   |                   |
           |-MLD Report->|==== MLD Report (aggregated Join) ====>|
           |             |                   |                   |
           |<------------|<=========== Multicast data ===========|
           |             |                   |                   |
         Detach          |                   |                   |
           |             |                   |                   |
         Attach          |                   |                   |
           |             |                   |                   |
           |------------- RS --------------->|                   |
           |             |                   |------- PBU ------>|
           |             |                   |                   |
           |             |                   |<-------PBA--------|
           |             |                   |                   |
           |             |<----- CT-Req -----|                   |
           |             |                   |                   |
           |             |------ CXTP ------>|                   |
           |             |      M-CTD        |                   |
           |             |                   |=== MLD Report ===>|
           |             |<------ CXTP ------|                   |
           |             |      M-CTDR(B)    |                   |
           |             |                   |                   |
           |<----------- RA -----------------|                   |
           |             |                   |<= Multicast data =|
           |             |<------ CXTP ------|                   |
           |             |     M-CTDR(F)     |                   |
           |             |                   |                   |
           |             |= Multicast data =>|                   |
           |             |<------ CXTP ------|                   |
           |             |     M-CTDR(L)     |                   |
           |             |                   |                   |
           |<-------- Multicast data --------|                   |
           |             |                   |                   |
           |             |========= MLD Report (leave) =========>|
           |             |                   |                   |

          Figure 1: MLD listener handover with CXTP and MLD proxy

   After MN attaches to n-MAG, the forwarded multicast data from p-MAG
   will be delivered to the MN immediately.  Afterwards the current
   multicast data are delivered as received from LMA and the MN's
   multicast membership state at the p-MAG is cancelled.

von Hugo & Asaeda       Expires February 16, 2013               [Page 8]
Internet-Draft        CXTP Extension for Multicast           August 2012

3.3.  Multicast Context Transfer with PIM-SM

   This section describes the case that MAG operates as a PIM-SM [3]
   router, as described in a proposed solution [12].

   The MLD listener handover with CXTP and PIM-SM shown in Figure 2 is
   defined as follows.

   1.   The first and second procedures are the same ones as described
        in Section 3.2.

   2.   If there are multicast channels the MN has subscribed but the
        n-MAG has not yet subscribed, n-MAG joins the multicast tree via
        sending PIM Join messages to the upstream router (Figure 2 shows
        the example that the upstream router is the corresponding LMA).

   3.   The remaining steps for completion of the context transfer are
        the same ones as described in Section 3.2 with the only
        exception being that p-MAG sends a PIM Prune message to LMA
        instead of a MLD Report (leave) message if there are no attached
        mobile nodes listening the multicast channels.

von Hugo & Asaeda       Expires February 16, 2013               [Page 9]
Internet-Draft        CXTP Extension for Multicast           August 2012

          MN           p-MAG               n-MAG                LMA
           |             |                   |                   |
           |-MLD Report->|=============== PIM Join =============>|
           |             |                   |                   |
           |<------------|<=========== Multicast data ===========|
           |             |                   |                   |
         Detach          |                   |                   |
           |             |                   |                   |
         Attach          |                   |                   |
           |             |                   |                   |
           |------------- RS --------------->|                   |
           |             |                   |------- PBU ------>|
           |             |                   |                   |
           |             |                   |<-------PBA--------|
           |             |                   |                   |
           |             |<----- CT-Req -----|                   |
           |             |                   |                   |
           |             |------ CXTP ------>|                   |
           |             |      M-CTD        |                   |
           |             |                   |===== PIM Join ===>|
           |             |<------ CXTP ------|                   |
           |             |      M-CTDR(B)    |                   |
           |             |                   |                   |
           |<----------- RA -----------------|                   |
           |             |                   |<= Multicast data =|
           |             |<------ CXTP ------|                   |
           |             |     M-CTDR(F)     |                   |
           |             |                   |                   |
           |             |= Multicast data =>|                   |
           |             |<------ CXTP ------|                   |
           |             |     M-CTDR(L)     |                   |
           |             |                   |                   |
           |<-------- Multicast data --------|                   |
           |             |                   |                   |
           |             |============== PIM Prune =============>|
           |             |                   |                   |
           |             |                   |                   |

           Figure 2: MLD listener handover with CXTP and PIM-SM

von Hugo & Asaeda       Expires February 16, 2013              [Page 10]
Internet-Draft        CXTP Extension for Multicast           August 2012

4.  IANA Considerations

   TBD.

von Hugo & Asaeda       Expires February 16, 2013              [Page 11]
Internet-Draft        CXTP Extension for Multicast           August 2012

5.  Security Considerations

   TBD.

von Hugo & Asaeda       Expires February 16, 2013              [Page 12]
Internet-Draft        CXTP Extension for Multicast           August 2012

6.  Acknowledgements

   Many of the specifications described in this document are discussed
   and provided by the MultiMob mailing-list.  Detailed comments by Luis
   Miguel Contreras Murillo are gratefully acknowledged.

von Hugo & Asaeda       Expires February 16, 2013              [Page 13]
Internet-Draft        CXTP Extension for Multicast           August 2012

7.  References

7.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to indicate requirement
         levels", RFC 2119, March 1997.

   [2]   Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K.,
         and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [3]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
         "Protocol Independent Multicast - Sparse Mode (PIM-SM):
         Protocol Specification (Revised)", RFC 4601, August 2006.

   [4]   Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
         (MLDv2) for IPv6", RFC 3810, June 2004.

   [5]   Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and MLDv2
         Protocols", RFC 5790, February 2010.

   [6]   Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
         Group Management Protocol (IGMP) / Multicast Listener Discovery
         (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")",
         RFC 4605, August 2006.

   [7]   Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The
         Relationship between Links and Subnet Prefixes", RFC 5942,
         July 2010.

   [8]   "IEEE Standard for Local and Metropolitan Area Networks - Part
         21: Media Independent Handover Services, IEEE LAN/MAN Std
         802.21-2008", January 2009.

7.2.  Informative References

   [9]   Loughney, Ed., J., Nakhjiri, M., Perkins, C., and R. Koodli,
         "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.

   [10]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment
         for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6)
         Domains", RFC 6224, April 2011.

   [11]  Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership
         Tracking Function for Multicast Routers",
         draft-ietf-pim-explicit-tracking-01.txt (work in progress),
         April 2012.

   [12]  Asaeda, H. and P. Seite, "Multicast Routing Optimization by

von Hugo & Asaeda       Expires February 16, 2013              [Page 14]
Internet-Draft        CXTP Extension for Multicast           August 2012

         PIM-SM with PMIPv6",
         draft-asaeda-multimob-pmip6-extension-10.txt (work in
         progress), March 2012.

   [13]  Miloucheva, I. and K. Jonas, "Multicast Context Transfer in
         mobile IPv6", draft-miloucheva-mldv2-mipv6-00.txt (work in
         progress), June 2005.

von Hugo & Asaeda       Expires February 16, 2013              [Page 15]
Internet-Draft        CXTP Extension for Multicast           August 2012

Authors' Addresses

   Dirk von Hugo
   Telekom Innovation Laboratories
   Deutsche-Telekom-Allee 7
   D-64295 Darmstadt
   Germany

   Phone:
   Email: Dirk.von-Hugo@telekom.de
   URI:

   Hitoshi Asaeda
   Keio University
   Graduate School of Media and Governance
   5322 Endo
   Fujisawa, Kanagawa  252-0882
   Japan

   Email: asaeda@wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~asaeda/

von Hugo & Asaeda       Expires February 16, 2013              [Page 16]