Internet DRAFT - draft-xu-softwire-4over6multicast

draft-xu-softwire-4over6multicast





Network Working Group                                              M. Xu
Internet-Draft                                                    Y. Cui
Expires: September 8, 2010                           Tsinghua University
                                                             Chris. Metz
                                                           Cisco Systems
                                                           March 7, 2010


                        Softwire Mesh Multicast
                  draft-xu-softwire-4over6multicast-02

Abstract

   The client networks could be of different address family with the
   core network during IPv6 transition period.  The client networks may
   need to run IP multicast applications across the transit core while
   it's not well supported currently.  This memo provides a AFBR-based
   softwire mesh multicast framework for IPv6 transition.

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), 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 September 8, 2010.

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



Xu, et al.              Expires September 8, 2010               [Page 1]

Internet-Draft          softwire mcast framework              March 2010


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































Xu, et al.              Expires September 8, 2010               [Page 2]

Internet-Draft          softwire mcast framework              March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Softwire Mesh Multicast  . . . . . . . . . . . . . . . . . . .  6
     3.1.  Schemes for Unicast core . . . . . . . . . . . . . . . . .  6
     3.2.  Schemes for Multicast core . . . . . . . . . . . . . . . .  6
       3.2.1.  Many to one mapping  . . . . . . . . . . . . . . . . .  6
       3.2.2.  One to one mapping . . . . . . . . . . . . . . . . . .  6
   4.  RPF-Vector-Based Address Translation . . . . . . . . . . . . .  8
   5.  Inter-AFBR(Address Family Border Router) signaling . . . . . . 10
     5.1.  Address Mapping  . . . . . . . . . . . . . . . . . . . . . 10
     5.2.  Data Plane . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.3.  Control Plane  . . . . . . . . . . . . . . . . . . . . . . 11
     5.4.  SPT Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.5.  Shared Tree Scheme . . . . . . . . . . . . . . . . . . . . 14
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19




























Xu, et al.              Expires September 8, 2010               [Page 3]

Internet-Draft          softwire mcast framework              March 2010


1.  Introduction

   The Internet will need to support IPv4 and IPv6 packets.  Both
   address families and their attendent protocol suites support
   multicast of the single-source and any-source varieties.  As part of
   the transition to IPv6, there will be scenarios where a backbone
   network running one IP address family internally (referred to as
   internal IP or I-IP) will provide transit services to attached client
   networks running another IP address family (referred to as external
   IP or E-IP).  It is expected that the I-IP core will offer unicast
   and multicast transit services to the client E-IP client
   networks.[I-D.draft-metz-softwires-multicast-problem-statement-00]

   The multicast framework for IPv6 transition can be described like
   this: As the multicast group members and multicast sources(or RP) of
   the group may be scattered in different client networks.  In order to
   transfer multicast traffic to the group members, softwire can be
   used.  In the control layer, the distribution trees must cover both
   the transit core and client networks, so we need to connect the
   transit core and client distribution trees together for a multicast
   group in AFBRs.

   It doesn't need any changes to construct the client distribution
   trees, but a distribution tree needs to be constructed by the core
   network, which could support multicast or not.  If the core supports
   multicast, a core tree can be constructed to help transfer multicast
   traffic efficiently.  However, if not, the AFBRs have to replicate
   the multicast data and transfer them to other AFBRs in mVPN-like
   mode..

   After giving the detailed scenario in the next section, we will give
   an overview of softwire mesh multicast.  Then a detailed introduction
   of one to one mapping will be given, as many to one or all to one has
   been realized by mVPN[I-D.ietf-l3vpn-2547bis-mcast].  Here mapping
   means the relation between multicast groups in client networks and
   multicast groups in the core network.

   We mainly talk about PIM-SM(SSM) here as it's a representative
   multicast protocol.












Xu, et al.              Expires September 8, 2010               [Page 4]

Internet-Draft          softwire mcast framework              March 2010


2.  Scenario

                                               --------
                                              |Receiver|
                                               --------
                                                 |
                         ._._._._.            ._._._._.
                        |         |          |         |   --------
                        |  E-IP   |          |  E-IP   |--|Source S|
                        | network |          | network |   --------
                         ._._._._.            ._._._._.
                            |                    |
                           AFBR             upstream AFBR
                        Dual-Stack           Dual-Stack
                            |                    |
                          __+____________________+__
                         /   :   :           :   :  \
                        |    :      :      :     :   |  E-IP Multicast
                        |    : I-IP transit core :   |  message should
                        |    :     :       :     :   |  get across the
                        |    :   :            :  :   | I-IP transit core
                         \_._._._._._._._._._._._._./
                             +                   +
                        downstream AFBR    downstream AFBR
                         Dual-Stack          Dual-Stack
                             |                    |
                          ._._._._            ._._._._
             --------    |        |          |        |   --------
            |Receiver|-- |  E-IP  |          |  E-IP #|--|Receiver|
             --------    |network |          |network |   --------
                          ._._._._            ._._._._



   Figure 1: Softwire Multicast Scenario

   The softwire multicast framework is illustrated in Figure 1.
   Multicast source S is in one client network, while its receivers may
   be in the same or different networks.  When they are not in the same
   client network, they have to communicate with each other through the
   I-IP transit core.  There may be several sources at the same time,
   and they can also reside in different client networks.  What's more,
   when considering about RP, it may be in a different network with any
   sources.

   Some terminology is defined as follows:

   o Softwire (SW) - A "tunnel" that is created on the basis of a



Xu, et al.              Expires September 8, 2010               [Page 5]

Internet-Draft          softwire mcast framework              March 2010


   control protocol setup between softwire endpoints with a shared
   point-to- point, multipoint-to-point, point-to-multipoint or
   multipoint-to-multipoing state.  Softwires are generally dynamic in
   nature (they may be initiated and terminated on demand), but may be
   very long-lived.

   o Address Family Border Router (AFBR) - The dual-stack router that
   interconnects two networks that use different address families.  In
   the context of softwires multicast, the AFBR runs E-IP and I-IP
   control planes to maintain E-IP and I-IP multicast state respectively
   and performs the appropriate encapsulation/decapsultion client E-IP
   multicast packets for transport across the I-IP core.

   o I-IP ("Internal IP").  This refers to the form of IP (i.e., either
   IPv4 or IPv6) that is supported by the transit (or backbone) network.

   o E-IP ("External IP") This refers to the form of IP (i.e. either
   IPv4 or IPv6) that is supported by the client networks.

   o I-IP core Tree.  A single-source or multi-source distribution tree
   rooted at one or more AFBR source nodes and branching out to one or
   more AFBR leaf nodes.  An I-IP core Tree is built using standard IP
   or MPLS multicast signaling protocols operating exclusively inside
   the I-IP core network.  An I-IP core Tree is used to tunnel E-IP
   multicast packets belonging to E-IP trees across the I-IP core.
   Another name for an I-IP core Tree is multicast or multipoint
   softwire.

   o E-IP client tree.  A single-source or multi-source distribution
   tree rooted at one or more hosts or routers located inside a client
   E-IP network and branching out to one or more leaf nodes located in
   the same or different client E-IP networks.

   o upstream AFBR: The AFBR router that located at the upstream of
   multicast data flow, which connects the transit core and the client
   network the RP/source S belongs to.

   o downstream AFBR: The AFBR router that located at the downstream of
   multicast data flow, which connects the transit core and the client
   network which a group member of RP/source belongs to while the RP/
   source doesn't belongs to.










Xu, et al.              Expires September 8, 2010               [Page 6]

Internet-Draft          softwire mcast framework              March 2010


3.  Softwire Mesh Multicast

   We face all kinds of scenarios, the I-IP transit core may support
   multicast, or not.  We have multiple choices if it does.  However, we
   have to make use of unicast to transfer the multicast traffic.

3.1.  Schemes for Unicast core

   In some scenarios, the I-IP transit core does not run multicast
   protocols, and thus AFBRs can not construct multicast distribution
   trees in the I-IP transit core.  Under this condition the multicast
   control messages and data traffic from client networks are
   encapsulated and decapsulated as common packets to get across the
   core.

   There are two alternative schemes in this scenario.  One is the
   ingress AFBR will replicate the packets to all the other AFBRs, which
   is an easy solution as the AFBR knows the information of the other
   AFBRs throught MP-BGP using softwire.  The other one is the ingress
   AFBR will replicate the packets to the necessary AFBRs, that is, the
   AFBRs behind which have group members.  The latter one is more
   complex because the group members' location must be known.

3.2.  Schemes for Multicast core

   When the I-IP transit core supports multicast, we can build a
   multicast tree or several multicast trees in the core so as to
   transfer the traffic from the client network.  According to the
   number of groups in the core corresponding to the groups in the
   client networks, there are many to one mapping and one to one mapping
   to construct the multicast trees in the core.

3.2.1.  Many to one mapping

   Using this mapping method, many groups in client networks will be
   mapped into the same group in the core.  Under some conditions, all
   groups in client networks will be mapped into the same group, as it's
   the simplest mapping method.

   Many to one mapping has been well realized by mVPN[I-D.ietf-l3vpn-
   2547bis-mcast], where traffic from multiple MVPNs will be aggregated
   into a single multicast distribution tree.  Thus many groups are
   mapped into the same group in the core.

3.2.2.  One to one mapping

   Using many to one mapping, the management could be easier, but
   members of different groups may be scattered in different client



Xu, et al.              Expires September 8, 2010               [Page 7]

Internet-Draft          softwire mcast framework              March 2010


   networks and when they are mapped into the same group, some AFBRs may
   receive unnecessary packets of some group when it doesn't belong to
   the group.

   For examle, group A and B which belong to client networks are mapped
   into the same group C in the core.  Assume that in a client network,
   there are members of A while no member of B. But group C must
   transfer the traffic whenever it belongs to group A or B of the
   client networks.  So the AFBR of this client network may receive
   unnecessary packets(like packets of group B) if nothing is done in
   the upstream.

   There are several ways to realize one to one mapping.  Here we will
   introduce two of them.  One is based on RPF-Vector and the other is
   through inter-AFBR signaling.




































Xu, et al.              Expires September 8, 2010               [Page 8]

Internet-Draft          softwire mcast framework              March 2010


4.  RPF-Vector-Based Address Translation

   The main idea of address translation is to translate E-IP addresses
   of the Join/Prune messages to I-IP addresses.  Therefore, E-IP
   multicast messages can be translated to corresponding I-IP multicast
   messages at ingress AFBRs, and then back to E-IP multicast messages
   after arriving at egress AFBRs.  The translation procedure should
   follow some predefined rules, so that ingress AFBR and egress AFBR
   can finish the translation and retranslation procedure correctly
   without negotiation.  For example, if E-IP is IPv4 and I-IP is IPv6,
   the ingress AFBR uses a predefined IPv6 prefix for any case to
   translate an IPv4 address to an IPv6 address, and the predefined IPv6
   prefix combined with the IPv4 address makes up the new IPv6 address
   in the IPv6 transit core.  Then the egress AFBR can easily
   retranslate it to the original IPv4 address by simply removing the
   predefined IPv6 prefix.

   Since the source and group addresses in the I-IP Join/Prune message
   are translated from E-IP by adding a predefined I-IP prefix, they can
   not be recognized by P routers to reach the corresponding egress
   AFBRs.  We use an RPF Vector in the Join/Prune message to route them
   in the I-IP transit core.  The RPF Vector is an optional extended PIM
   attribution, which designates the routers which router the Join/Prune
   message must pass by. i.e., AFBR A fills the I-IP address of AFBR B
   in the RPF Vector of Join/Prune message to help it find a route to
   AFBR B in the transit core.  Then the Join/Prune message builds a
   multicast tree in the transit core and finally arrives at AFBR B.

   When some multicast data packet arrives at AFBR B, it will be
   translated to an I-IP packet, and delivered along the I-IP core Tree
   constructed by the former Join/Prune message in core and arrive at
   AFBR A. Then AFBR A will translate it back and forward it to the E-IP
   client network.

   The address translation scheme is only available when E-IP is IPv4
   and I-IP is IPv6.  As IPv6 addresses are 128bit long, it is possible
   to translate an IPv4 address to an IPv6 address by making IPv4
   address part of the IPv6 address algorithmically.  AFBRs can
   translate the IPv4 S and G into corresponding IPv4-mapped IPv6
   addresses [RFC4291], and then be translated back.  The precise
   circumstances under which these translations are done would be a
   matter of policy.  But if E-IP is IPv6 and I-IP is IPv4, the
   translation can't be achieved easily, more research is needed to fit
   this condition.  Also, an additional RPF Vector must be applied to
   help to construct the I-IP core Tree in the transit core.  To sum up,
   the address translation method is virtually the same multicast
   message taking on different appearances in different IP address
   family networks and the I-IP core Tree is part of the E-IP client



Xu, et al.              Expires September 8, 2010               [Page 9]

Internet-Draft          softwire mcast framework              March 2010


   tree while presenting an I-IP feature.


















































Xu, et al.              Expires September 8, 2010              [Page 10]

Internet-Draft          softwire mcast framework              March 2010


5.  Inter-AFBR(Address Family Border Router) signaling

   It's called inter-AFBR signaling because unlike the RPF-Vector-Based
   address translation, here AFBRs has to send signals to the other
   AFBRs to construct the whole multicast tree.

5.1.  Address Mapping

   There are two kinds of address associated with multicast: source
   address and group address.  Group address will be discussed in this
   section and source address later when associated with SPT and shared
   tree scheme.

   For softwire mesh multicast, there are two different scenarios when
   talking about address translation, which is also called address
   mapping here: IPv4-IPv6-IPv4 scenario and IPv6-IPv4-IPv6 scenario.
   The previous one is easier to implement one to one mapping as the
   IPv6 address is longer than the IPv4 one.  We can simply add a prefix
   before the IPv4 address when mapping an E-IP address to an I-IP
   address, just like figure 2 shows.

                0  8  16                            96        127
                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                |FF XX|      ISP Assigned Prefix    | v4 address|
                +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


   Figure 2: Mapping from IPv4 to IPv6 address

   The first two octets must be in accordance with the IPv6 multicast
   address format defined in section 2.7 of [RFC2373].  The following 10
   octets are assigned by administrators of ISP and the last 4 octets
   are the IPv4 address.

   But for the IPv6-IPv4-IPv6 scenario, due to the shorter length of
   IPv4 address, it's not that simple to realize one to one mapping.

   A feasible solution is partial mapping, which maps only part of IPv6
   addresses into IPv4 addresses, like the IPv6 address with a fixed
   prefix.  We won't talk about it here as it prohibits the use of some
   IPv6 group addresses.

   We will talk about another solution: an IPv6 address will be hashed
   into another IPv4 address using some hash function.  In this manner,
   two or more IPv6 addresses may be mapped into the same IPv4 address.
   But at the same time, only part of the IPv6 addresses are in use, so
   with a proper hash function, we can achieve one to one mapping
   approximately.  For example, we could use the last three octets of



Xu, et al.              Expires September 8, 2010              [Page 11]

Internet-Draft          softwire mcast framework              March 2010


   IPv6 address to fill in the last three octets of IPv4 address, while
   the first octet is determined by the administrator.

5.2.  Data Plane

   Assume that group source S wants to send packets to a group member in
   different client network with S. S will send the packets along the
   multicast tree of client network(where S locates) to the upstream
   AFBR first.  Then AFBR will encapsulate the packets with a header
   whose destination is an I-IP multicast address.  Thus the packets
   will flow along the multicast tree of transit core to the downstream
   AFBR.

   Having received the packets, the downstream AFBR will first
   decapsulate the packets, and then judge whether the packets are
   necessary, which means whether it has group members behind it.  If
   not, it will just discard them, else it will send them along the
   multicast tree of client network(where D locates) to the receivers.
   Finally, D will receiver these packets.

5.3.  Control Plane

   There are many control messages in PIM protocol.  How to deal with
   them when they are received by routers, especially AFBR routers is
   really an important problem.

   When AFBR receives multicast control messages whose destination is in
   another client network, it has to maintain the multicast tree in the
   core, in the mean while, it's responsible to send some of them, like
   Join or Prune messages, to the client network on the other side of
   the core.  Usually, the messages are tunneled to the other side of
   the core.  The tunneling technology can be GRE, IP-in-IP, MPLS etc.
   Here we use IP-in-IP, other tunneling method is alike.

   The upstream AFBR treats the downstream AFBRs as the neighbors on the
   multicast tree when they send tunneled control messages to it.  But
   unlike native PIM protocol, different neighbors are distinguished by
   their IP addresses but not by interfaces, because tunneled control
   messages sent by different downstream AFBRs can arrive at the
   upstream AFBR through the same interface.  Usually, for every group,
   AFBR will keep a table recording which downstream AFBRs have joined
   it.

   The key part is how to maintain the multicast tree in the core.
   Unlike RPF-Vector-Based scheme, it's not just a process of
   translation, it's more complicate than that.  When AFBR receive E-IP
   Join messages, the AFBR will judge whether it has already joined the
   multicast group in the core, if not, then it will send I-IP Join



Xu, et al.              Expires September 8, 2010              [Page 12]

Internet-Draft          softwire mcast framework              March 2010


   messages upstream.  Note that the multicast group is not the group of
   the Join message AFBR has received, it's the group which is mapped
   from the group of the Join message.  When AFBR receive E-IP Prune
   messages, it will judge whether there are any group members in the
   client network, if not, it will send I-IP Prune messages upstream.

                                       ._._._._.
                                      |         |   --------
                                      |  E-IP   |--|Source S|
                                      | network |   --------
                                       ._._._._.
                                          |
                                      upstream AFBR
                                      Dual-Stack
                                          |
                             __ __________+_________ _
                            /   :   :           :   :  \
                           |    :      :      :     :   |
                           |    : I-IP transit core :   |
                           |    :     :       :     :   |
                           |    :   :            :  :   |
                            \_._._._._._._._._._._._._./
                                          +
                                     downstream AFBR
                                      Dual-Stack
                                          |
                                       ._._._._
                        ----------    |        |    ----------
                       |Receiver a|-- |  E-IP  | --|Receiver b|
                        ----------    |network |    ----------
                                       ._._._._



   Figure 3: Maintain the multicast tree in the core

   For example as in figure 3, receiver a belongs to group A while b
   belongs to group B, A and B will be mapped into group C in the core.
   Firstly, a sends a Join(S,A) message to source S(here we only
   consider about PIM-SSM for the sake of simplicity), when the message
   arrives at the downstream AFBR, the AFBR find that it hasn't yet
   joined group C, so it will send a Join(S',C)(S' will be defined in
   the next sections) to the core and send an encapsulated packet
   E(Join(S,A)) to the upstream AFBR.

   But when b sends a Join(S,B) message to S, when the AFBR receives it,
   it finds that it has joined group C. Thus it just sends an
   encapsulated packet E(Join(S,B)) to the upstream AFBR.  Then b wants



Xu, et al.              Expires September 8, 2010              [Page 13]

Internet-Draft          softwire mcast framework              March 2010


   to quit group B, it will send a Prune(S,G), when downstream AFBR
   receives it, it finds there are still members of group C, then it
   just sends an encapsulated packet E(Prune(S,B)) to the upstream AFBR.
   After that, a also wants to quit, it sends a Prune(S,A) message, when
   downstream receives it, it finds no member of C exists, so it sends a
   Prune(S',C) message to the core while sending an encapsulated packet
   E(Prune(S,A)) to the upstream AFBR.

   In order to maintain the multicast tree in the core, besides sending
   messages to the core and upstream AFBRs invoked by messages received
   from client network, AFBR also has to send some messages
   periodically, like hello and Join messages, etc.

5.4.  SPT Scheme

   SPT means we will construct a source specific tree in the core where
   the source will be a AFBR.  We use PIM-SSM as the technology to
   construct the source specific tree in the core.  The data traffic
   will flow along the multicast tree of the client network to the
   upstream AFBR, then the upstream AFBR will act as the source of the
   SPT in the core.  In this way, data will flow to the other AFBR where
   receivers locate behind, finnaly data traffic comes back to the
   multicast tree of another client network and arrives at the
   receivers.

   So E-IP Join/Prune(S,G) messages will be mapped into I-IP Join/
   Prune(S',G') messages, where S' is the address of the upstream AFBR
   and G' is the mapped group address which we talked about previously.
   In this way, all the routers in the core recognize this I-IP address
   and the I-IP control messages will be sent to the right AFBR.  And
   E-IP Join/Prune(*,G) messages will also be mapped into I-IP Join/
   Prune(S',G') messages where S' is the address of AFBR where RP
   locates behind.  E(Join/Prune(S,G)) or E(Join/Prune(*,G)) will be
   tunneled to the upstream AFBR while Join/Prune(S',G') will be sent to
   the core.

   But for dealing with Join/Prune(S,G,rpt), the downstream AFBR just
   have to tunnel the E(Join/Prune(S,G,rpt)) to the upstream AFBR, there
   won't be any Join/Prune(S',G',rpt) sent to the core as we use PIM-SSM
   in the core.

   If there are many sources of one group in the same client network.
   Then they will share the same multicast tree in the core.  This will
   cause some data redundancy, but it's less serious than many to one
   mapping.






Xu, et al.              Expires September 8, 2010              [Page 14]

Internet-Draft          softwire mcast framework              March 2010


5.5.  Shared Tree Scheme

   Compared with SPT scheme, shared tree scheme constructs a shared tree
   in the core.  The data traffic will flow to the upstream AFBR, then
   the upstream AFBR will send the data traffic the the RP of the shared
   tree in the core.  The RP in the core will distribute the traffic to
   the necessary AFBRs, throught which the traffic will arrive at the
   receivers.

   Both E-IP Join/Prune(S,G) and Join/Prune(*,G) will be mapped into
   Join/Prune(*,G') where G' is a mapped group address.  The Join/
   Prune(*,G') messages will be sent to the core and the core routers
   will pass them to RP of group G' in the core.  The core routers need
   to know the information(the address) of the RP in the core.  The RP
   in the core is discovered according to [RFC4601].

   At the same time, E(Join/Prune(S,G)) or E(Join/Prune(*,G)) will be
   tunneled to the upstream AFBR.  Thus data traffic will flow to the
   upstream AFBR.  When AFBR receives data of group G, it will take
   those data, unicast-encapsulates them, and sends them directly to the
   RP of G' in the core.  The RP receives these encapsulated data
   packets, decapsulates them, and forwards them onto the shared tree.
   This is just like the register process of [RFC4601].

   Also like [RFC4601], RP in the core will switch to native forwarding
   as register-encapsulation of data packets is inefficient.  RP will
   send an Join(S',G') towards S' and in this way packets from S' starts
   to arrive natively at the RP.  Then RP will send register-stop
   message to S' when it receives two copies of each of data packets.

   Like the SPT scheme, when dealing with Join/Prune(S,G,rpt), the
   downstream AFBR just have to tunnel E(Join/Prune(S,G,rpt)) to the
   upstream AFBR but not send Join/Prune(S',G',rpt) to the core, as the
   routers in the core can't distinguish between the packets from RP(of
   client network) with the packets from source.

   For each group, there is only one shared tree in the core which is
   less than SPT scheme.  If there are many sources in the group, their
   packets will follow the same multicast tree when they flow through
   the core.  That means it will cause more serious data redundancy than
   SPT scheme.  But it's still less serious than many to one mapping.

   For both of SPT Scheme and Shared Tree Scheme, we don't have to worry
   about assert messages, because it can be done with locally.  At the
   AFBRs, the timers that associated with the other AFBRs must be
   prolonged, as the control messages or the data may have to travel
   through the core network for quite a long time.




Xu, et al.              Expires September 8, 2010              [Page 15]

Internet-Draft          softwire mcast framework              March 2010


6.  Summary

   There are a lot of schemes talked above.  To some schemes, several
   mapping methods exist.  Which one to choose depends on the actual
   situation.

   When the core network only supports unicast, we have to decided
   whether to transfer the replication to all the other AFBRs or the
   necessary AFBRs.  The former one is simple but may cause higher
   redundancy while more AFBRs will receive data they haven't asked for.

   When the core network supports multicast, we have many choices.  Many
   to one mapping has been realized by mVPN, but it may cause serious
   data redundancy.  RPF-Vector-Based scheme provides a translation
   scheme and can achieve one-to-one mapping between client networks and
   the core network.  But it only adapts to IPv4-IPv6-IPv4 scenario and
   has to make use of RPF Vector which is an optional extended
   attribution of PIM, which many networks can't satisfy.  Inter-AFBR
   signaling is another choice to realize one to one mapping which
   adapts to both IPv4-IPv6-IPv4 and IPv6-IPv4-IPv6 scenarios.  Both SPT
   and shared multicast tree can be used in the core to transfer
   multicast traffic, and usually, shared tree scheme creates less trees
   in the core than SPT scheme.

   Whether more trees or less trees exist in the core is better, it also
   depends.  More trees can reduce data redundancy while increasing the
   overhead for managing the trees, that is, there will be more states
   in the router and more resources will be wasted on processing
   multicast control message.

   Thus choosing different schemes always means choosing data redundancy
   or overhead.  If you consider that data redundancy is more important,
   you can choose a scheme that creates more trees, and vice versa.


















Xu, et al.              Expires September 8, 2010              [Page 16]

Internet-Draft          softwire mcast framework              March 2010


7.  Security Considerations

   The AFBR routers could maintain secure communications through the use
   of Security Architecture for the Internet Protocol as described
   in[RFC4301].  But when adopting some schemes whose data redundancy is
   serious, some attacker may use it as a tool for DDoS attack.













































Xu, et al.              Expires September 8, 2010              [Page 17]

Internet-Draft          softwire mcast framework              March 2010


8.  IANA Considerations

   For Inter-AFBR signaling, address mapping is applied, and it should
   follow some predefined rule, especially the format of IPv6 prefix for
   address mapping should be predefined, so that ingress AFBR and egress
   AFBR can finish the mapping procedure correctly.  The format of IPv6
   prefix for translation can be unified within only the transit core,
   or within global area.  In the later condition, the format should be
   assigned by IANA.










































Xu, et al.              Expires September 8, 2010              [Page 18]

Internet-Draft          softwire mcast framework              March 2010


9.  References

9.1.  Normative References

   [1]  Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", RFC 4301, December 2005.

   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

   [3]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 4291, February 2006.

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

   [5]  Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem
        Statement", RFC 4925, July 2007.

   [6]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
        Framework", RFC 5565, June 2009.

9.2.  Informative References

   [7]  Wijnands, I., Boers, A., and E. Rosen, "The RPF Vector TLV",
        draft-ietf-pim-rpf-vector-08 (work in progress), January 2009.

   [8]  Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen,
        E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/BGP IP
        VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work in progress),
        January 2010.

   [9]  Metz, C., Cui, Y., and M. Xu, "Softwires Mesh Multicast Problem
        Statement", draft-metz-softwires-multicast-problem-statement-00
        (work in progress), February 2008.















Xu, et al.              Expires September 8, 2010              [Page 19]

Internet-Draft          softwire mcast framework              March 2010


Authors' Addresses

   Mingwei Xu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: xmw@csnet1.cs.tsinghua.edu.cn


   Yong Cui
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084
   P.R.China

   Phone: +86-10-6278-5822
   Email: cuiyong@tsinghua.edu.cn


   Chris Metz
   Cisco Systems
   170 West Tasman Drive
   San Jose, California  95134-1706
   USA

   Phone: +1-408-525-3275
   Email: chmetz@cisco.com





















Xu, et al.              Expires September 8, 2010              [Page 20]