Internet DRAFT - draft-xia-multimob-hybrid

draft-xia-multimob-hybrid






Network Working Group                                             F. Xia
Internet-Draft                                               B. Sarikaya
Expires: May 9, 2008                                          Huawei USA
                                                        November 6, 2007


      Hybrid Subscription for Multicast Reciever Mobility in MIPv6
                    draft-xia-multimob-hybrid-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.

   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 May 9, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Xia & Sarikaya             Expires May 9, 2008                  [Page 1]

Internet-Draft           Optimization Multicast            November 2007


Abstract

   In MIPv6 specification, there are two basic methods for mobile
   multicast: 1) via a bi-directional tunnel from MN to its Home
   Agent;2) via a local multicast router on the foreign link being
   visited.  In this memo, a hybrid method is introduced.  MN subscribes
   multicast service through Home agent at first.  Then, MN changes its
   subscription router to a local multicast router which can provide the
   same multicast service.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Solution Detail  . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Local Multicast Service Discovery  . . . . . . . . . . . .  6
     4.2.  Multicast Group Membership Management in HA  . . . . . . .  6
   5.  MLDv2 Extension  . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Multicast Listener Hold-Release  . . . . . . . . . . . . .  6
     5.2.  Multicast Listening State Advertisement  . . . . . . . . .  7
       5.2.1.  Type . . . . . . . . . . . . . . . . . . . . . . . . .  8
       5.2.2.  Reserved and Checksum  . . . . . . . . . . . . . . . .  8
       5.2.3.  Nr of Mcast Address Records (M)  . . . . . . . . . . .  8
       5.2.4.  Multicast Address Record . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA consideration . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative references . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12

















Xia & Sarikaya             Expires May 9, 2008                  [Page 2]

Internet-Draft           Optimization Multicast            November 2007


1.  Introduction

   [I-D.irtf-mobopts-mmcastv6-ps] specifies the problem scope for a
   multicast mobility management which is further subdivided into two
   categories: multicast listener mobility and multicast sender
   mobility.  In this memo, only the former is dealt with.

   The problem of achieving seamless multicast listener mobility is then
   further analyzed in three aspects:

   1.  Ensuring multicast reception even in visited networks without
       appropriate multicast support.

   2.  Realizing native multicast forwarding whenever applicable to
       preserve network resources and avoid data redundancy.

   3.  Expediting primary multicast forwarding at handovers.

   Items 1 and 2 are discussed in this document, while item 3 is handled
   in [I-D.xia-mipshop-fmip-multicast].

   MIPv6 [RFC3775] has specified two basic methods for mobile multicast:
   1)via a bi-directional tunnel from MN to its HA (Home Agent), which
   is called Home Subscription; 2) via a local multicast router on the
   foreign link being visited, which is called Remote Subscription.  In
   Home Subscription, MN tunnels its multicast group membership control
   packets to its HA, and the HA forwards multicast packets down the
   tunnel to the MN .  In Remote Subscription, the local multicast
   router MUST terminate MLD messages.  These two basic methods can
   retain multicast communications when MN moves, but some issues still
   exist.

   o  Home Subscription suffers from triangle route which is composed of
      MN- HA tunnel and HA-S (multicast source server) multicast tree
      path.  When the MN is far from its HA, the data forwarding path of
      multicast becomes sub-optimal.

   o  Although the multicast path in Remote Subscription is optimal,
      frequent handoffs of MN among subnets will produce much latency.
      Because when MN handovers, it will leave and re-join multicast
      groups frequently.

   As to unicast traffic, there are two possible modes in [RFC3775] for
   communication between the mobile node and a correspondent node, that
   is, bi-directional tunneling and route optimization.  The former
   provides basic IP connectivity while MN is moving, while the latter
   provides efficient communication.  In optimization mode, routing
   packets directly to the mobile node's care-of address allows the



Xia & Sarikaya             Expires May 9, 2008                  [Page 3]

Internet-Draft           Optimization Multicast            November 2007


   shortest communications path to be used.  It also eliminates
   congestion at the mobile node's home agent and home link.

   Borrowing some ideas from unicast traffic optimization, this document
   proposes an optimized solution for a multicast listener.
   Subscription from home network provides basic multicast service
   availability, while subscription from visited network provides
   optimal multicast traffic delivery.  The combination of two methods
   is a comprehensive solution which is preliminarily referred to in
   [Progress and Challenges].


2.  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 [RFC2119].

   The terminology in this document is based on the definitions in
   [RFC3775], in addition to the ones specified in this section.

   Multicast Services Capability:  multicast traffic forwarding
      capability of a multicast router.  Different multicast routers
      probably have different capability because of different local
      policy, router processing capability and so on.  In this memo, MN
      can receive multicast traffic from HA or local AR.  These two
      entities probably have different capability to provide multicast
      service because of different administrative domain, different
      processing capability and so on.


3.  Solution Overview

   The Home Subscription or bi-directional tunneling relies on Mobile
   IPv6 architectural entities ( HA and MN ) and uses a multicast router
   (which is probably collocated with HA or not) on the home network.
   If the multicast router is physically separated from HA, the HA
   operates as a MLD proxy [RFC4605].  For simplification, this memo
   only considers the situation that HA acts as a multicast router.
   This simplification does not affect the operation defined in the
   document.

   To join a multicast group, MN establishes a bi-directional tunnel
   with its HA and tunnels its membership report message to the HA.
   This is encapsulated within the same tunnel header used for routing
   unicast packets between MN and HA.  HA intercepts the membership
   message and sends a join message to an upstream router using
   multicast control protocols (e.g.  [RFC4601]).  Once the multicast



Xia & Sarikaya             Expires May 9, 2008                  [Page 4]

Internet-Draft           Optimization Multicast            November 2007


   branch is established, the HA forwards the incoming multicast packets
   down the tunnel to the MN.

   When the mobile receiver moves to a new foreign network, it does not
   need to re-join the multicast group since the HA is already informed
   about its membership.  This approach suffers from triangular routing
   across the home network, which may increase join latency.  Moreover,
   tunnel via HA incurs overhead at the home network.

   With the Remote Subscription approach, MN joins a multicast group
   through a local multicast router on a foreign network.  To join a
   multicast group, MN sends its membership report to the local
   multicast router (i.e.  Access Router) located on the visited
   network.  The local multicast router intercepts this membership
   report message and joins the requested multicast group.  After
   handover to a new network, MN sends a new membership report message
   to a new Access Router acting as a multicast router.  The main
   problem with the Remote Subscription is that the multicast services
   capability provided by HA is probably different from AR.  That is, HA
   can join some multicast group while AR can not.

   Multicasting according to current standards (e.g.  MLDv2 [RFC3810])
   has drawbacks compared to unicasting when one applies it to
   commercial services.  Accounting of each user's actions is not
   possible with multicasting as it is with unicasting.
   [I-D.ietf-mboned-maccnt-req] proposes requirements for AAA in well
   managed IP multicasting services.  In MIPv6 scenario, HA is a default
   multicast service provider for MN.  If MN wants to subscribe
   multicast service directly from AR, some AAA operation may be
   performed.  So, when MN in a foreign link wants to subscribe to a
   multicast group, it sends its membership report to HA by default.
   While MN receives multicast traffic from HA, MN initiates a Remote
   Subscription by sending membership report.  After successful Remote
   Subscription, MN notifies HA to stop delivery of corresponding
   multicast traffic, but hold the multicast membership in HA, as will
   be described further in the later.

   During handover, there is a multicast service negotiation between
   Previous Access Router(PAR) and New Access Router (NAR).  That is,
   PAR presents MN's multicast services to NAR, and NAR replies with
   supported multicast services based on its local policy.  If the
   multicast services (multicast group) are not supported by NAR, MN
   then reverts to Home Subscription .


4.  Solution Detail





Xia & Sarikaya             Expires May 9, 2008                  [Page 5]

Internet-Draft           Optimization Multicast            November 2007


4.1.  Local Multicast Service Discovery

   When MN wants to switch from Home Subscription to Remote
   Subscription, MN should learn the multicast service capability
   provided by local multicast routers.  To do so, MN presents its
   existing multicast services to AR, and AR acknowledges the multicast
   services which can be provided locally.

   MN sends its existing multicast services to AR through State Change
   Report [RFC3810] once the IP connectivity with AR is established.  AR
   sends a Multicast Listening State Advertisement which is detailed in
   Section 5.2.  In this message, AR tells MN which multicast services
   can be provided locally, so MN switches corresponding Home
   Subscriptions to Remote Subscriptions.

4.2.  Multicast Group Membership Management in HA

   When MN use Remote Subscription, HA MAY terminate its packet
   forwarding to the MN.  However, to preserve its ability to restart
   fast packet forwarding, it may be desirable for HA to remain part of
   the multicast delivery tree.  The Home Subscription is kept active by
   a new membership message called Multicast Listener Hold defined in
   Section 5.1 sent by MN to its HA.  When MN performs Remote
   Subscription, it sends Multicast Listener Hold message to HA for
   stopping corresponding multicast traffic forwarding while keeping the
   multicast membership.  When MN reverts from Remote Subscription to
   Home Subscription, it sends a message to restart the multicast
   traffic forwarding quickly.

   When MN wishes to leave a multicast group and sends Multicast
   Listener Report to HA, a specific query is supposed to be sent by HA
   to check if other listeners for the same group are present on the
   link.  But because the tunnel is per MN, HA should not send the
   specific query message to relieve traffic.


5.  MLDv2 Extension

5.1.  Multicast Listener Hold-Release

   This message is to notify a multicast router (e.g.  HA) to stop
   forwarding multicast data for the groups specified, but still
   maintain the multicast membership on that interface.  The message has
   twofold functions: stopping forwarding a multicast traffic and
   resuming forwarding.  The following figure is Multicast Listener
   Report format defined in [RFC3810].  Based on this, a code field is
   designed for Multicast Listener Hold-Release message.




Xia & Sarikaya             Expires May 9, 2008                  [Page 6]

Internet-Draft           Optimization Multicast            November 2007


      0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = 143   |      Code     |           Checksum            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Reserved            |Nr of Mcast Address Records (M)|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               Multicast Address Record [1]                    |
       .                                                               .
       .                          ...                                  .
       |               Multicast Address Record [M]                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type and other fields are defined in [RFC3810].

   An 8-bit Code field is defined.  Code value

   1 is used to activate forwarding multicast traffic specified in the
   message,

   2 is used to stop forwarding while hold the membership of the
   specified multicast address records.

5.2.  Multicast Listening State Advertisement

   Multicast Listening State Advertisement is sent by multicast routers
   to advertise available multicast services for MN.  The format of the
   message is similar to Multicast Listener Report Message in [RFC3810].






















Xia & Sarikaya             Expires May 9, 2008                  [Page 7]

Internet-Draft           Optimization Multicast            November 2007


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = 143   |    Reserved   |           Checksum            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Reserved            |Nr of Mcast Address Records (M)|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                  Multicast Address Record [1]                 .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               .                               |
       .                               .                               .
       |                               .                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                  Multicast Address Record [N]                 .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



5.2.1.  Type

   A new message type is defined , and the value SHOULD be allocated by
   IANA.

5.2.2.  Reserved and Checksum

   These fields have the same meaning as the fields define in Multicast
   Listener Report Message [RFC3810].

5.2.3.  Nr of Mcast Address Records (M)

   The Nr of Mcast Address Records (M) field specifies how many
   Multicast Address Records are present in this Report.

5.2.4.  Multicast Address Record

   Each Multicast Address Record is a block of fields that contain
   multicast groups information that MN can subscribe on the link from
   which the advertisement is sent.





Xia & Sarikaya             Expires May 9, 2008                  [Page 8]

Internet-Draft           Optimization Multicast            November 2007


6.  Security Considerations

   Home Subscription shares bi-directional tunnel which is built for
   unicast traffic.  HA and MN has a security association to protect the
   tunnel.  As for Remote Subscription, there is no addition threats
   introduced comparing with MLDv2 [RFC3810].


7.  IANA consideration


8.  Acknowledgements


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

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

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

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

9.2.  Informative references

   [Progress and Challenges]
              Jelger, C. and T. Noel, "Multicast for Mobile Hosts in IP
              Networks: Progress and Challenges",  IEEE Wireless Comm.,
              2002.

   [I-D.irtf-mobopts-mmcastv6-ps]
              Schmidt, T. and M. Waehlisch, "Multicast Mobility in
              MIPv6: Problem Statement and Brief Survey",
              draft-irtf-mobopts-mmcastv6-ps-01 (work in progress),
              July 2007.



Xia & Sarikaya             Expires May 9, 2008                  [Page 9]

Internet-Draft           Optimization Multicast            November 2007


   [I-D.xia-mipshop-fmip-multicast]
              Xia, F. and B. Sarikaya, "FMIPv6 extension for Multicast
              Handover", draft-xia-mipshop-fmip-multicast-01 (work in
              progress), March 2007.

   [I-D.ietf-mboned-maccnt-req]
              He, H., "Requirements for Multicast AAA coordinated
              between Content Provider(s) and  Network Service
              Provider(s)", draft-ietf-mboned-maccnt-req-05 (work in
              progress), October 2007.









































Xia & Sarikaya             Expires May 9, 2008                 [Page 10]

Internet-Draft           Optimization Multicast            November 2007


Authors' Addresses

   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 100
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 100
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: sarikaya@ieee.org

































Xia & Sarikaya             Expires May 9, 2008                 [Page 11]

Internet-Draft           Optimization Multicast            November 2007


Full 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.

   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.


Intellectual Property

   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
   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Xia & Sarikaya             Expires May 9, 2008                 [Page 12]