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]