Internet Engineering Task Force                               Qian. Wang
Internet-Draft                                                Qiong. Sun
Intended status: Standards Track                           China Telecom
Expires: April 11, 2011                                       Jacni. Qin
                                                               Peng. Sun
                                                                     ZTE
                                                         October 8, 2010


             Extensions to DS-Lite for Multicast Deployment
                 draft-qin-softwire-dslite-multicast-00

Abstract

   DS-Lite enables broadband service providers to provide IPv4 unicast
   service following IPv4 exhaustion by combining two mechanisms: NAT
   (for IPv4 address sharing) and IPv4-in-IPv6 tunnel(a bridging link,
   for carrying IPv4 traffic).  Meanwhile, native IPv6 services, both
   unicast and multicast can be provided.  This document describes
   extensions to DS-Lite to support IPv4 multicast.

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 April 11, 2011.

Copyright Notice

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



Wang, et al.             Expires April 11, 2011                 [Page 1]


Internet-Draft              DS-Lite Multicast               October 2010


   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.

   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.



































Wang, et al.             Expires April 11, 2011                 [Page 2]


Internet-Draft              DS-Lite Multicast               October 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 4
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.1.  Tunnel encapsulation for Multicast  . . . . . . . . . . . . 5
     2.2.  IPv4-embedded IPv6 address prefixes . . . . . . . . . . . . 5
     2.3.  Multicast Distribution Tree . . . . . . . . . . . . . . . . 6
     2.4.  Multicast Forwarding  . . . . . . . . . . . . . . . . . . . 6
     2.5.  BNG with AFTR integrated  . . . . . . . . . . . . . . . . . 7
   3.  Operation Details . . . . . . . . . . . . . . . . . . . . . . . 7
     3.1.  B4  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     3.2.  AFTR  . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   4.  Multicast Traffic Optimization  . . . . . . . . . . . . . . . . 7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9






























Wang, et al.             Expires April 11, 2011                 [Page 3]


Internet-Draft              DS-Lite Multicast               October 2010


1.  Introduction

   If DS-Lite is used for IPv4 multicast, there will be some problems.
   AFTR MUST work as the multicast replication point where all the IGMP
   reports are terminated.  Especially when centralized AFTR is
   implemented, it will be a great challenge for AFTR to process the
   protocol messages and data forwarding.  Meanwhile, the downstream
   bandwidth will be vastly consumed.

   In practice, similar issue exists in native IPv4 networks for
   multicast.  To deal with it, mechanisms like IGMP snooping, multicast
   VLAN, are introduced into distributed Access Network Nodes (e.g.
   Aggregation Switches, xPON devices) which then occupy the role of
   terminating IGMP requests and replicating multicast traffic.  In this
   way, the multicast replication point can be moved downward and closer
   to the subscribers, so the bandwidth consumption and the great
   pressure of the layer 3 gateway is reduced substantially.

   While in DS-Lite, IGMP snooping does NOT work on Access Network Nodes
   due to the current tunnel encapsulation.

   In this document, we try to extend DS-Lite and make it more feasible
   for IPv4 multicast.  While the key characteristic of this proposal is
   exactly the same as DS-Lite: communications stay within their address
   family.

1.1.  Requirements Language

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


2.  Overview

   The overall process is described in this section based on the example
   below where AFTR is a standalone box apart from the IPv6 BNG(there
   may be multiple hops in between), and PIM Sparse Mode is used for
   multicast routing.












Wang, et al.             Expires April 11, 2011                 [Page 4]


Internet-Draft              DS-Lite Multicast               October 2010


                       +----------+     +-----------+
                -------|   AFTR   |     | v6 Router |-------
                       +----------+     +-----------+
                            |   \         /   |
                            |    \       /    |
                            |     \     /     |
                            |  +-----------+  |
                            |  |   v6 BNG  |  |
                            |  +-----------+  |
              IPv4-embedded |        |        |    Native
             IPv6 Multicast |        |        | IPv6 Multicast
                            |        |        |
                            |  +----------+   |
                            |  |    B4    |   |
                            |  +----------+   |
                            |    /      \     |
                            V   /        \    V
                          +------+      +------+
                          |  v4  |      |  v6  |
                          | Host |      | Host |
                          +------+      +------+

                                 Figure 1

2.1.  Tunnel encapsulation for Multicast

   In the original DS-Lite, IPv4-in-IPv6 tunnel encapsulation is used to
   carry the bidirectional IPv4 unicast traffic between B4 and AFTR.
   Here we would like to use IPv6 Multicast address(IPv4-embedded) as
   the destination of tunnel encapsulation to carry the unidirectional
   IPv4 multicast from AFTR to B4.  The IPv4 address of multicast source
   will be mapped to IPv6 address using special IPv6 prefix.

2.2.  IPv4-embedded IPv6 address prefixes

   One special IPv6 multicast prefix(here we name it, Dedicated mPrefix)
   is needed for constructing IPv6 multicast addresses, with IPv4
   multicast address embedded.  Meanwhile, the addresses of IPv4
   multicast source(also RP of shared tree) should be mapped to IPv6
   addresses, so an IPv6 unicast prefix(here we name it Dedicated
   uPrefix) is needed for constructing IPv6 unicast addresses with IPv4
   unicast address embedded(the multicast source or RP's address).

   The length of the IPv6 prefixes should be less than 96, with no other
   restrictions(except for the source-specific multicast, since IANA has
   assigned special ranges of group addresses for that).  The exact
   policy of address format is controlled by service provider.




Wang, et al.             Expires April 11, 2011                 [Page 5]


Internet-Draft              DS-Lite Multicast               October 2010


   These two prefixes can be configured onto B4 through DHCPv6 options
   or some out-of-band mechanism.

2.3.  Multicast Distribution Tree

   Suppose that an IPv4 host has acquired the address of IPv4 multicast
   group which it is interested in, then the host will send an IGMP
   Report to B4 joining that group.  After receiving IGMP message from
   the host, B4 performs the "IGMP Proxying" function similarly as
   described in [RFC4605], but translates the IGMP message to MLD
   message when sending upwards this membership report.  In the MLD
   message, the IPv6 address of multicast group to be joined is
   constructed using Dedicated mPrefix, and with IPv4 multicast address
   embedded.  If the source-specific multicast is deployed, the IPv6
   address of the multicast source can be constructed in the same way
   (using Dedicated uPrefix, with IPv4 multicast source embedded).

   Receiving this MLD membership report on the BNG may trigger the PIM
   join up to RP or the multicast source.  Make sure the calculated RPF
   interface for sending PIM join be on the path up to AFTR.  This can
   be easily achieved by making AFTR advertise the route of Dedicated
   uPrefix throughout the service provider's IPv6 Network.  To send PIM
   join triggered by native IPv6 MLD membership report, the RPF
   interface calculation can be done based on native IPv6 unicast
   routing information.

   After receiving the PIM join, AFTR will add the IPv6 interface
   receiving the join message to the Out Interface List of corresponding
   entry in the IPv4 multicast routing table(indicated by the IPv4
   multicast address embedded).  If the entry for this IPv4 multicast
   group doesn't exist, a new entry will be created and a PIM join
   message will be sent up further towards the source.

   Till now, the multicast distribution tree from B4 up to AFTR is
   established in service provider's IPv6 network.

2.4.  Multicast Forwarding

   Whenever a IPv4 multicast packet is received on AFTR, a search of
   multicast routing table is performed, and probably an IPv6 interface
   will be found in the Out-Interface-List of the matching entry, this
   IPv6 interface was added into Out-Interface-List in the process of
   multicast distribution tree establishment as described previously.

   Then AFTR should encapsulate the IPv4 multicast packet into IPv6
   tunnel using the "IPv4-embedded" multicast address as the destination
   of the IPv6 tunnel.  The new IPv6 multicast packet will then be sent
   out of the IPv6 interface and flow down the multcast distribution



Wang, et al.             Expires April 11, 2011                 [Page 6]


Internet-Draft              DS-Lite Multicast               October 2010


   tree to B4 through service provider's IPv6 network.

   When receiving the IPv6 multicast packet sent to this special group,
   B4 should decapsulate the IPv6 tunnel and pass the original IPv4
   multicast packet to the IPv4 host in LAN.

   ?? to trigger the tunnel decapsulation operation, should B4 join this
   special IPv6 group itself?

2.5.  BNG with AFTR integrated

   If the AFTR function is integrated into BNGs(have to be dual stack),
   the multicast distribution tree will be much simpler, and the
   multicast forwarding is the same as described above.


3.  Operation Details

3.1.  B4

   To be added...

3.2.  AFTR

   To be added...


4.  Multicast Traffic Optimization

   To be added...


5.  Acknowledgements

   The authors would like to thank Dan Wing for his guidance during the
   discussions which initiated this work.  We also appreciate Jie Hu,
   Lizhong Jin for their valuable input.


6.  IANA Considerations

   This document includes no request to IANA.


7.  Security Considerations


8.  References



Wang, et al.             Expires April 11, 2011                 [Page 7]


Internet-Draft              DS-Lite Multicast               October 2010


8.1.  Normative References

   [I-D.ietf-behave-address-format]
              Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
              draft-ietf-behave-address-format-10 (work in progress),
              August 2010.

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
              in progress), August 2010.

   [I-D.venaas-behave-mcast46]
              Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
              IPv4 - IPv6 multicast translator",
              draft-venaas-behave-mcast46-01 (work in progress),
              July 2009.

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

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [TR-101]   Broadband Forum, "TR-101: Migration to Ethernet-Based DSL
              Aggregation", 2006.

8.2.  Informative References

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,



Wang, et al.             Expires April 11, 2011                 [Page 8]


Internet-Draft              DS-Lite Multicast               October 2010


              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, August 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4608]  Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific
              Protocol Independent Multicast in 232/8", BCP 120,
              RFC 4608, August 2006.


Authors' Addresses

   Qian Wang
   China Telecom
   No.118, Xizhimennei
   Beijing,   100035
   China

   Phone: +86 10 5855 2177
   Email: wangqian@ctbri.com.cn


   Qiong Sun
   China Telecom
   No.118, Xizhimennei
   Beijing,   100035
   China

   Phone: +86 10 5855 2116
   Email: sunqiong@ctbri.com.cn


   Jacni Qin
   ZTE
   Shanghai,
   China

   Phone: +86 1391 8619 913
   Email: jacniq@gmail.com






Wang, et al.             Expires April 11, 2011                 [Page 9]


Internet-Draft              DS-Lite Multicast               October 2010


   Peng Sun
   ZTE
   Shanghai,
   China

   Phone: +86 21 6889 7101
   Email: sun.peng@zte.com.cn












































Wang, et al.             Expires April 11, 2011                [Page 10]