draft-ietf-softwire-mesh-multicast-08.txt   draft-ietf-softwire-mesh-multicast-09.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Internet-Draft Y. Cui Internet-Draft Y. Cui
Expires: July 26, 2015 J. Wu Expires: July 26, 2015 J. Wu
S. Yang S. Yang
Tsinghua University Tsinghua University
C. Metz C. Metz
G. Shepherd G. Shepherd
Cisco Systems Cisco Systems
January 22, 2015 January 22, 2015
Softwire Mesh Multicast Softwire Mesh Multicast
draft-ietf-softwire-mesh-multicast-08 draft-ietf-softwire-mesh-multicast-09
Abstract Abstract
The Internet needs to support IPv4 and IPv6 packets. Both address The Internet needs to support IPv4 and IPv6 packets. Both address
families and their related protocol suites support multicast of the families and their related protocol suites support multicast of the
single-source and any-source varieties. As part of the transition to single-source and any-source varieties. As part of the transition to
IPv6, there will be scenarios where a backbone network running one IP IPv6, there will be scenarios where a backbone network running one IP
address family internally (referred to as internal IP or I-IP) will address family internally (referred to as internal IP or I-IP) will
provide transit services to attached client networks running another provide transit services to attached client networks running another
IP address family (referred to as external IP or E-IP). It is IP address family (referred to as external IP or E-IP). It is
skipping to change at page 3, line 46 skipping to change at page 3, line 46
egress AFBR leaf nodes. egress AFBR leaf nodes.
[RFC4925] outlines the requirements for the softwires mesh scenario [RFC4925] outlines the requirements for the softwires mesh scenario
including the multicast. It is straightforward to envisage that including the multicast. It is straightforward to envisage that
client E-IP multicast sources and receivers will reside in different client E-IP multicast sources and receivers will reside in different
client E-IP networks connected to an I-IP backbone network. This client E-IP networks connected to an I-IP backbone network. This
requires that the client E-IP source-rooted or shared tree should requires that the client E-IP source-rooted or shared tree should
traverse the I-IP backbone network. traverse the I-IP backbone network.
One method to accomplish this is to re-use the multicast VPN approach One method to accomplish this is to re-use the multicast VPN approach
outlined in [RFC6513] . MVPN-like schemes can support the softwire outlined in [RFC6513]. MVPN-like schemes can support the softwire
mesh scenario and achieve a "many-to-one" mapping between the E-IP mesh scenario and achieve a "many-to-one" mapping between the E-IP
client multicast trees and the transit core multicast trees. The client multicast trees and the transit core multicast trees. The
advantage of this approach is that the number of trees in the I-IP advantage of this approach is that the number of trees in the I-IP
backbone network scales less than linearly with the number of E-IP backbone network scales less than linearly with the number of E-IP
client trees. Corporate enterprise networks and by extension client trees. Corporate enterprise networks and by extension
multicast VPNs have been known to run applications that create too multicast VPNs have been known to run applications that create too
many (S,G) states. Aggregation at the edge contains the (S,G) states many (S,G) states. Aggregation at the edge contains the (S,G) states
that need to be maintained by the network operator supporting the that need to be maintained by the network operator supporting the
customer VPNs. The disadvantage of this approach is the possible customer VPNs. The disadvantage of this approach is the possible
inefficient bandwidth and resource utilization when multicast packets inefficient bandwidth and resource utilization when multicast packets
are delivered to a receiver AFBR with no attached E-IP receivers. are delivered to a receiver AFBR with no attached E-IP receivers.
Internet-style multicast is somewhat different in that the trees are Internet-style multicast is somewhat different in that the trees are
relatively sparse and source-rooted. The need for multicast relatively sparse and source-rooted. The need for multicast
aggregation at the edge (where many customer multicast trees are aggregation at the edge (where many customer multicast trees are
mapped into a few or one backbone multicast trees) does not exist and mapped into a few or one backbone multicast trees) does not exist and
to date has not been identified. Thus the need for a basic or closer to date has not been identified. Thus the need for a basic or closer
alignment with E-IP and I-IP multicast procedures emerges. alignment with E-IP and I-IP multicast procedures emerges.
A framework on how to support such methods is described in [RFC5565] A framework on how to support such methods is described in [RFC5565].
. In this document, a more detailed discussion supporting the "one- In this document, a more detailed discussion supporting the "one-to-
to-one" mapping schemes for the IPv6 over IPv4 and IPv4 over IPv6 one" mapping schemes for the IPv6 over IPv4 and IPv4 over IPv6
scenarios will be discussed. scenarios will be discussed.
2. Terminology 2. Terminology
An example of a softwire mesh network supporting multicast is An example of a softwire mesh network supporting multicast is
illustrated in Figure 1. A multicast source S is located in one E-IP illustrated in Figure 1. A multicast source S is located in one E-IP
client network, while candidate E-IP group receivers are located in client network, while candidate E-IP group receivers are located in
the same or different E-IP client networks that all share a common the same or different E-IP client networks that all share a common
I-IP transit network. When E-IP sources and receivers are not local I-IP transit network. When E-IP sources and receivers are not local
to each other, they can only communicate with each other through the to each other, they can only communicate with each other through the
I-IP core. There may be several E-IP sources for some multicast I-IP core. There may be several E-IP sources for some multicast
group residing in different client E-IP networks. In the case of group residing in different client E-IP networks. In the case of
shared trees, the E-IP sources, receivers and RPs might be located in shared trees, the E-IP sources, receivers and RPs might be located in
different client E-IP networks. In a simple case the resources of different client E-IP networks. In a simple case the resources of
the I-IP core are managed by a single operator although the inter- the I-IP core are managed by a single operator although the inter-
provider case is not precluded. provider case is not precluded.
._._._._. ._._._._. ._._._._. ._._._._.
| | | | -------- | | | | --------
| E-IP | | E-IP |--|Source S| | E-IP | | E-IP |--|Source S|
| network | | network | -------- | network | | network | --------
._._._._. ._._._._. ._._._._. ._._._._.
| | | |
AFBR upstream AFBR AFBR upstream AFBR
| | | |
__+____________________+__ __+____________________+__
/ : : : : \ / : : : : \
| : : : : | E-IP Multicast | : : : : | E-IP Multicast
| : I-IP transit core : | packets should | : I-IP transit core : | packets should
| : : : : | get across the | : : : : | get across the
| : : : : | I-IP transit core | : : : : | I-IP transit core
\_._._._._._._._._._._._._./ \_._._._._._._._._._._._._./
+ + + +
downstream AFBR downstream AFBR downstream AFBR downstream AFBR
| | | |
._._._._ ._._._._ ._._._._ ._._._._
-------- | | | | -------- -------- | | | | --------
|Receiver|-- | E-IP | | E-IP |--|Receiver| |Receiver|-- | E-IP | | E-IP |--|Receiver|
-------- |network | |network | -------- -------- |network | |network | --------
._._._._ ._._._._ ._._._._ ._._._._
Figure 1: Softwire Mesh Multicast Framework Figure 1: Softwire Mesh Multicast Framework
Terminology used in this document: Terminology used in this document:
o Address Family Border Router (AFBR) - A dual-stack router o Address Family Border Router (AFBR) - A dual-stack router
interconnecting two or more networks using different IP address interconnecting two or more networks using different IP address
families. In the context of softwire mesh multicast, the AFBR runs families. In the context of softwire mesh multicast, the AFBR runs
E-IP and I-IP control planes to maintain E-IP and I-IP multicast E-IP and I-IP control planes to maintain E-IP and I-IP multicast
states respectively and performs the appropriate encapsulation/ states respectively and performs the appropriate encapsulation/
skipping to change at page 7, line 4 skipping to change at page 7, line 4
o Inter-AFBR signaling: A mechanism used by downstream AFBRs to send o Inter-AFBR signaling: A mechanism used by downstream AFBRs to send
PIM messages to the upstream AFBR. PIM messages to the upstream AFBR.
3. Scenarios of Interest 3. Scenarios of Interest
This section describes the two different scenarios where softwires This section describes the two different scenarios where softwires
mesh multicast will apply. mesh multicast will apply.
3.1. IPv4-over-IPv6 3.1. IPv4-over-IPv6
._._._._. ._._._._. ._._._._. ._._._._.
| IPv4 | | IPv4 | -------- | IPv4 | | IPv4 | --------
| Client | | Client |--|Source S| | Client | | Client |--|Source S|
| network | | network | -------- | network | | network | --------
._._._._. ._._._._. ._._._._. ._._._._.
| | | |
AFBR upstream AFBR AFBR upstream AFBR
| | | |
__+____________________+__ __+____________________+__
/ : : : : \ / : : : : \
| : : : : | | : : : : |
| : IPv6 transit core : | | : IPv6 transit core : |
| : : : : | | : : : : |
| : : : : | | : : : : |
\_._._._._._._._._._._._._./ \_._._._._._._._._._._._._./
+ + + +
downstream AFBR downstream AFBR downstream AFBR downstream AFBR
| | | |
._._._._ ._._._._ ._._._._ ._._._._
-------- | IPv4 | | IPv4 | -------- -------- | IPv4 | | IPv4 | --------
|Receiver|-- | Client | | Client |--|Receiver| |Receiver|-- | Client | | Client |--|Receiver|
-------- | network| | network| -------- -------- | network| | network| --------
._._._._ ._._._._ ._._._._ ._._._._
Figure 2: IPv4-over-IPv6 Scenario Figure 2: IPv4-over-IPv6 Scenario
In this scenario, the E-IP client networks run IPv4 and I-IP core In this scenario, the E-IP client networks run IPv4 and I-IP core
runs IPv6. This scenario is illustrated in Figure 2. runs IPv6. This scenario is illustrated in Figure 2.
Because of the much larger IPv6 group address space, it will not be a Because of the much larger IPv6 group address space, it will not be a
problem to map individual client E-IPv4 tree to a specific I-IPv6 problem to map individual client E-IPv4 tree to a specific I-IPv6
core tree. This simplifies operations on the AFBR because it becomes core tree. This simplifies operations on the AFBR because it becomes
possible to algorithmically map an IPv4 group/source address to an possible to algorithmically map an IPv4 group/source address to an
IPv6 group/source address and vice-versa. IPv6 group/source address and vice-versa.
The IPv4-over-IPv6 scenario is an emerging requirement as network The IPv4-over-IPv6 scenario is an emerging requirement as network
operators build out native IPv6 backbone networks. These networks operators build out native IPv6 backbone networks. These networks
naturally support native IPv6 services and applications but it is naturally support native IPv6 services and applications but it is
with near 100% certainty that legacy IPv4 networks handling unicast with near 100% certainty that legacy IPv4 networks handling unicast
and multicast should be accommodated. and multicast should be accommodated.
3.2. IPv6-over-IPv4 3.2. IPv6-over-IPv4
._._._._. ._._._._. ._._._._. ._._._._.
| IPv6 | | IPv6 | -------- | IPv6 | | IPv6 | --------
| Client | | Client |--|Source S| | Client | | Client |--|Source S|
| network | | network | -------- | network | | network | --------
._._._._. ._._._._. ._._._._. ._._._._.
| | | |
AFBR upstream AFBR AFBR upstream AFBR
| | | |
__+____________________+__ __+____________________+__
/ : : : : \ / : : : : \
| : : : : | | : : : : |
| : IPv4 transit core : | | : IPv4 transit core : |
| : : : : | | : : : : |
| : : : : | | : : : : |
\_._._._._._._._._._._._._./ \_._._._._._._._._._._._._./
+ + + +
downstream AFBR downstream AFBR downstream AFBR downstream AFBR
| | | |
._._._._ ._._._._ ._._._._ ._._._._
-------- | IPv6 | | IPv6 | -------- -------- | IPv6 | | IPv6 | --------
|Receiver|-- | Client | | Client |--|Receiver| |Receiver|-- | Client | | Client |--|Receiver|
-------- | network| | network| -------- -------- | network| | network| --------
._._._._ ._._._._ ._._._._ ._._._._
Figure 3: IPv6-over-IPv4 Scenario Figure 3: IPv6-over-IPv4 Scenario
In this scenario, the E-IP Client Networks run IPv6 while the I-IP In this scenario, the E-IP Client Networks run IPv6 while the I-IP
core runs IPv4. This scenario is illustrated in Figure 3. core runs IPv4. This scenario is illustrated in Figure 3.
IPv6 multicast group addresses are longer than IPv4 multicast group IPv6 multicast group addresses are longer than IPv4 multicast group
addresses. It will not be possible to perform an algorithmic IPv6 - addresses. It will not be possible to perform an algorithmic IPv6 -
to - IPv4 address mapping without the risk of multiple IPv6 group to - IPv4 address mapping without the risk of multiple IPv6 group
addresses mapped to the same IPv4 address resulting in unnecessary addresses mapped to the same IPv4 address resulting in unnecessary
skipping to change at page 9, line 38 skipping to change at page 9, line 38
devise an algorithmic one-to-one IPv4-to-IPv6 address mapping at devise an algorithmic one-to-one IPv4-to-IPv6 address mapping at
AFBRs. AFBRs.
4.2. Group Address Mapping 4.2. Group Address Mapping
For IPv4-over-IPv6 scenario, a simple algorithmic mapping between For IPv4-over-IPv6 scenario, a simple algorithmic mapping between
IPv4 multicast group addresses and IPv6 group addresses is supported. IPv4 multicast group addresses and IPv6 group addresses is supported.
[I-D.ietf-mboned-64-multicast-address-format] has already defined an [I-D.ietf-mboned-64-multicast-address-format] has already defined an
applicable format. Figure 4 is the reminder of the format: applicable format. Figure 4 is the reminder of the format:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0-------------32--40--48--56--64--72--80--88--96-----------127| | 0-------------32--40--48--56--64--72--80--88--96-----------127|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| MPREFIX64 |group address | | MPREFIX64 |group address |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 4: IPv4-Embedded IPv6 Multicast Address Format Figure 4: IPv4-Embedded IPv6 Multicast Address Format
The MPREFIX64 for SSM mode is also defined in The MPREFIX64 for SSM mode is also defined in
[I-D.ietf-mboned-64-multicast-address-format] : [I-D.ietf-mboned-64-multicast-address-format] :
o ff3x:0:8000::/96 ('x' is any valid scope) o ff3x:0:8000::/96 ('x' is any valid scope)
With this scheme, each IPv4 multicast address can be mapped into an With this scheme, each IPv4 multicast address can be mapped into an
IPv6 multicast address (with the assigned prefix), and each IPv6 IPv6 multicast address (with the assigned prefix), and each IPv6
multicast address with the assigned prefix can be mapped into IPv4 multicast address with the assigned prefix can be mapped into IPv4
multicast address. multicast address.
4.3. Source Address Mapping 4.3. Source Address Mapping
There are two kinds of multicast --- ASM and SSM. Considering that There are two kinds of multicast --- ASM and SSM. Considering that
I-IP network and E-IP network may support different kind of I-IP network and E-IP network may support different kind of
multicast, the source address translation rules could be very complex multicast, the source address translation rules could be very complex
to support all possible scenarios. But since SSM can be implemented to support all possible scenarios. But since SSM can be implemented
with a strict subset of the PIM-SM protocol mechanisms [RFC4601] , we with a strict subset of the PIM-SM protocol mechanisms [RFC4601], we
can treat I-IP core as SSM-only to make it as simple as possible, can treat I-IP core as SSM-only to make it as simple as possible,
then there remains only two scenarios to be discussed in detail: then there remains only two scenarios to be discussed in detail:
o E-IP network supports SSM o E-IP network supports SSM
One possible way to make sure that the translated I-IPv6 PIM One possible way to make sure that the translated I-IPv6 PIM
message reaches upstream AFBR is to set S' to a virtual IPv6 message reaches upstream AFBR is to set S' to a virtual IPv6
address that leads to the upstream AFBR. Figure 5 is the address that leads to the upstream AFBR. Figure 5 is the
recommended address format based on [RFC6052] : recommended address format based on [RFC6052]:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0-------------32--40--48--56--64--72--80--88--96-----------127| | 0-------------32--40--48--56--64--72--80--88--96-----------127|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| prefix |v4(32) | u | suffix |source address | | prefix |v4(32) | u | suffix |source address |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|<------------------uPrefix64------------------>| |<------------------uPrefix64------------------>|
Figure 5: IPv4-Embedded IPv6 Virtual Source Address Format Figure 5: IPv4-Embedded IPv6 Virtual Source Address Format
In this address format, the "prefix" field contains a "Well-Known" In this address format, the "prefix" field contains a "Well-Known"
prefix or an ISP-defined prefix. An existing "Well-Known" prefix prefix or an ISP-defined prefix. An existing "Well-Known" prefix
is 64:ff9b, which is defined in [RFC6052] ; "v4" field is the IP is 64:ff9b, which is defined in [RFC6052]; "v4" field is the IP
address of one of upstream AFBR's E-IPv4 interfaces; "u" field is address of one of upstream AFBR's E-IPv4 interfaces; "u" field is
defined in [RFC4291] , and MUST be set to zero; "suffix" field is defined in [RFC4291], and MUST be set to zero; "suffix" field is
reserved for future extensions and SHOULD be set to zero; "source reserved for future extensions and SHOULD be set to zero; "source
address" field stores the original S. We call the overall /96 address" field stores the original S. We call the overall /96
prefix ("prefix" field and "v4" field and "u" field and "suffix" prefix ("prefix" field and "v4" field and "u" field and "suffix"
field altogether) "uPrefix64". field altogether) "uPrefix64".
o E-IP network supports ASM o E-IP network supports ASM
The (S,G) source list entry and the (*,G) source list entry only The (S,G) source list entry and the (*,G) source list entry only
differ in that the latter have both the WC and RPT bits of the differ in that the latter have both the WC and RPT bits of the
Encoded-Source-Address set, while the former all cleared (See Encoded-Source-Address set, while the former all cleared (See
Section 4.9.5.1 of [RFC4601] ). So we can translate source list Section 4.9.5.1 of [RFC4601]). So we can translate source list
entries in (*,G) messages into source list entries in (S'G') entries in (*,G) messages into source list entries in (S'G')
messages by applying the format specified in Figure 5 and clearing messages by applying the format specified in Figure 5 and clearing
both the WC and RPT bits at downstream AFBRs, and translate them both the WC and RPT bits at downstream AFBRs, and translate them
back at upstream AFBRs vice-versa. back at upstream AFBRs vice-versa.
4.4. Routing Mechanism 4.4. Routing Mechanism
In the mesh multicast scenario, routing information is required to be In the mesh multicast scenario, routing information is required to be
distributed among AFBRs to make sure that PIM messages that a distributed among AFBRs to make sure that PIM messages that a
downstream AFBR propagates reach the right upstream AFBR. downstream AFBR propagates reach the right upstream AFBR.
To make it feasible, the /32 prefix in "IPv4-Embedded IPv6 Virtual To make it feasible, the /32 prefix in "IPv4-Embedded IPv6 Virtual
Source Address Format" must be known to every AFBR, and every AFBR Source Address Format" must be known to every AFBR, and every AFBR
should not only announce the IP address of one of its E-IPv4 should not only announce the IP address of one of its E-IPv4
interfaces presented in the "v4" field to other AFBRs by MPBGP, but interfaces presented in the "v4" field to other AFBRs by MPBGP, but
also announce the corresponding uPrefix64 to the I-IPv6 network. also announce the corresponding uPrefix64 to the I-IPv6 network.
Since every IP address of upstream AFBR's E-IPv4 interface is Since every IP address of upstream AFBR's E-IPv4 interface is
different from each other, every uPrefix64 that AFBR announces should different from each other, every uPrefix64 that AFBR announces should
be different either, and uniquely identifies each AFBR. "uPrefix64" be different either, and uniquely identifies each AFBR. "uPrefix64"
is an IPv6 prefix, and the distribution of it is the same as the is an IPv6 prefix, and the distribution of it is the same as the
distribution in the traditional mesh unicast scenario. But since distribution in the traditional mesh unicast scenario. But since
"v4" field is an E-IPv4 address, and BGP messages are NOT tunneled "v4" field is an E-IPv4 address, and BGP messages are NOT tunneled
through softwires or through any other mechanism as specified in through softwires or through any other mechanism as specified in
[RFC5565] , AFBRs MUST be able to transport and encode/decode BGP [RFC5565], AFBRs MUST be able to transport and encode/decode BGP
messages that are carried over I-IPv6, whose NLRI and NH are of messages that are carried over I-IPv6, whose NLRI and NH are of
E-IPv4 address family. E-IPv4 address family.
In this way, when a downstream AFBR receives an E-IPv4 PIM (S,G) In this way, when a downstream AFBR receives an E-IPv4 PIM (S,G)
message, it can translate this message into (S',G') by looking up the message, it can translate this message into (S',G') by looking up the
IP address of the corresponding AFBR's E-IPv4 interface. Since the IP address of the corresponding AFBR's E-IPv4 interface. Since the
uPrefix64 of S' is unique, and is known to every router in the I-IPv6 uPrefix64 of S' is unique, and is known to every router in the I-IPv6
network, the translated message will eventually arrive at the network, the translated message will eventually arrive at the
corresponding upstream AFBR, and the upstream AFBR can translate the corresponding upstream AFBR, and the upstream AFBR can translate the
message back to (S,G). When a downstream AFBR receives an E-IPv4 PIM message back to (S,G). When a downstream AFBR receives an E-IPv4 PIM
(*,G) message, S' can be generated according to the format specified (*,G) message, S' can be generated according to the format specified
in Figure 4, with "source address" field set to *(the IPv4 address of in Figure 4, with "source address" field set to *(the IPv4 address of
RP). The translated message will eventually arrive at the RP). The translated message will eventually arrive at the
corresponding upstream AFBR. Since every PIM router within a PIM corresponding upstream AFBR. Since every PIM router within a PIM
domain must be able to map a particular multicast group address to domain must be able to map a particular multicast group address to
the same RP (see Section 4.7 of [RFC4601] ), when this upstream AFBR the same RP (see Section 4.7 of [RFC4601]), when this upstream AFBR
checks the "source address" field of the message, it'll find the IPv4 checks the "source address" field of the message, it'll find the IPv4
address of RP, so this upstream AFBR judges that this is originally a address of RP, so this upstream AFBR judges that this is originally a
(*,G) message, then it translates the message back to the (*,G) (*,G) message, then it translates the message back to the (*,G)
message and processes it. message and processes it.
5. IPv6-over-IPv4 Mechanism 5. IPv6-over-IPv4 Mechanism
5.1. Mechanism Overview 5.1. Mechanism Overview
Routers in the client E-IPv6 networks contain routes to all other Routers in the client E-IPv6 networks contain routes to all other
skipping to change at page 12, line 34 skipping to change at page 12, line 34
of the E-IPv6 source addresses for mapping, such as applying a "Well- of the E-IPv6 source addresses for mapping, such as applying a "Well-
Known" prefix or an ISP-defined prefix. Known" prefix or an ISP-defined prefix.
5.2. Group Address Mapping 5.2. Group Address Mapping
To keep one-to-one group address mapping simple, the group address To keep one-to-one group address mapping simple, the group address
range of E-IP IPv6 can be reduced in a number of ways to limit the range of E-IP IPv6 can be reduced in a number of ways to limit the
scope of addresses that need to be mapped into the I-IP IPv4 space. scope of addresses that need to be mapped into the I-IP IPv4 space.
A recommended multicast address format is defined in A recommended multicast address format is defined in
[I-D.ietf-mboned-64-multicast-address-format] . The high order bits [I-D.ietf-mboned-64-multicast-address-format]. The high order bits
of the E-IPv6 address range will be fixed for mapping purposes. With of the E-IPv6 address range will be fixed for mapping purposes. With
this scheme, each IPv4 multicast address can be mapped into an IPv6 this scheme, each IPv4 multicast address can be mapped into an IPv6
multicast address(with the assigned prefix), and each IPv6 multicast multicast address(with the assigned prefix), and each IPv6 multicast
address with the assigned prefix can be mapped into IPv4 multicast address with the assigned prefix can be mapped into IPv4 multicast
address. address.
5.3. Source Address Mapping 5.3. Source Address Mapping
There are two kinds of multicast --- ASM and SSM. Considering that There are two kinds of multicast --- ASM and SSM. Considering that
I-IP network and E-IP network may support different kind of I-IP network and E-IP network may support different kind of
multicast, the source address translation rules could be very complex multicast, the source address translation rules could be very complex
to support all possible scenarios. But since SSM can be implemented to support all possible scenarios. But since SSM can be implemented
with a strict subset of the PIM-SM protocol mechanisms [RFC4601] , we with a strict subset of the PIM-SM protocol mechanisms [RFC4601], we
can treat I-IP core as SSM-only to make it as simple as possible, can treat I-IP core as SSM-only to make it as simple as possible,
then there remains only two scenarios to be discussed in detail: then there remains only two scenarios to be discussed in detail:
o E-IP network supports SSM o E-IP network supports SSM
To make sure that the translated I-IPv4 PIM message reaches the To make sure that the translated I-IPv4 PIM message reaches the
upstream AFBR, we need to set S' to an IPv4 address that leads to upstream AFBR, we need to set S' to an IPv4 address that leads to
the upstream AFBR. But due to the non-"one-to-one" mapping of the upstream AFBR. But due to the non-"one-to-one" mapping of
E-IPv6 to I-IPv4 unicast address, the upstream AFBR is unable to E-IPv6 to I-IPv4 unicast address, the upstream AFBR is unable to
remap the I-IPv4 source address to the original E-IPv6 source remap the I-IPv4 source address to the original E-IPv6 source
address without any constraints. address without any constraints.
We apply a fixed IPv6 prefix and static mapping to solve this We apply a fixed IPv6 prefix and static mapping to solve this
problem. A recommended source address format is defined in problem. A recommended source address format is defined in
[RFC6052] . Figure 6 is the reminder of the format: [RFC6052]. Figure 6 is the reminder of the format:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0-------------32--40--48--56--64--72--80--88--96-----------127| | 0-------------32--40--48--56--64--72--80--88--96-----------127|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| uPrefix64 |source address | | uPrefix64 |source address |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 6: IPv4-Embedded IPv6 Source Address Format Figure 6: IPv4-Embedded IPv6 Source Address Format
In this address format, the "uPrefix64" field starts with a "Well- In this address format, the "uPrefix64" field starts with a "Well-
Known" prefix or an ISP-defined prefix. An existing "Well-Known" Known" prefix or an ISP-defined prefix. An existing "Well-Known"
prefix is 64:ff9b/32, which is defined in [RFC6052] ; "source prefix is 64:ff9b/32, which is defined in [RFC6052]; "source
address" field is the corresponding I-IPv4 source address. address" field is the corresponding I-IPv4 source address.
o E-IP network supports ASM o E-IP network supports ASM
The (S,G) source list entry and the (*,G) source list entry only The (S,G) source list entry and the (*,G) source list entry only
differ in that the latter have both the WC and RPT bits of the differ in that the latter have both the WC and RPT bits of the
Encoded-Source-Address set, while the former all cleared (See Encoded-Source-Address set, while the former all cleared (See
Section 4.9.5.1 of [RFC4601] ). So we can translate source list Section 4.9.5.1 of [RFC4601]). So we can translate source list
entries in (*,G) messages into source list entries in (S',G') entries in (*,G) messages into source list entries in (S',G')
messages by applying the format specified in Figure 5 and setting messages by applying the format specified in Figure 5 and setting
both the WC and RPT bits at downstream AFBRs, and translate them both the WC and RPT bits at downstream AFBRs, and translate them
back at upstream AFBRs vice-versa. Here, the E-IPv6 address of RP back at upstream AFBRs vice-versa. Here, the E-IPv6 address of RP
MUST follow the format specified in Figure 6. RP' is the upstream MUST follow the format specified in Figure 6. RP' is the upstream
AFBR that locates between RP and the downstream AFBR. AFBR that locates between RP and the downstream AFBR.
5.4. Routing Mechanism 5.4. Routing Mechanism
In the mesh multicast scenario, routing information is required to be In the mesh multicast scenario, routing information is required to be
skipping to change at page 14, line 26 skipping to change at page 14, line 26
translate the message into (S',G') by simply taking off the prefix in translate the message into (S',G') by simply taking off the prefix in
S. Since S' is known to every router in I-IPv4 network, the S. Since S' is known to every router in I-IPv4 network, the
translated message will eventually arrive at the corresponding translated message will eventually arrive at the corresponding
upstream AFBR, and the upstream AFBR can translate the message back upstream AFBR, and the upstream AFBR can translate the message back
to (S,G) by appending the prefix to S'. When a downstream AFBR to (S,G) by appending the prefix to S'. When a downstream AFBR
receives a (*,G) message, it can translate it into (S',G') by simply receives a (*,G) message, it can translate it into (S',G') by simply
taking off the prefix in *(the E-IPv6 address of RP). Since S' is taking off the prefix in *(the E-IPv6 address of RP). Since S' is
known to every router in I-IPv4 network, the translated message will known to every router in I-IPv4 network, the translated message will
eventually arrive at RP'. And since every PIM router within a PIM eventually arrive at RP'. And since every PIM router within a PIM
domain must be able to map a particular multicast group address to domain must be able to map a particular multicast group address to
the same RP (see Section 4.7 of [RFC4601] ), RP' knows that S' is the the same RP (see Section 4.7 of [RFC4601]), RP' knows that S' is the
mapped I-IPv4 address of RP, so RP' will translate the message back mapped I-IPv4 address of RP, so RP' will translate the message back
to (*,G) by appending the prefix to S' and propagate it towards RP. to (*,G) by appending the prefix to S' and propagate it towards RP.
6. Control Plane Functions of AFBR 6. Control Plane Functions of AFBR
The AFBRs are responsible for the following functions: The AFBRs are responsible for the following functions:
6.1. E-IP (*,G) State Maintenance 6.1. E-IP (*,G) State Maintenance
When an AFBR wishes to propagate a Join/Prune(*,G) message to an I-IP When an AFBR wishes to propagate a Join/Prune(*,G) message to an I-IP
skipping to change at page 15, line 21 skipping to change at page 15, line 21
6.4. E-IP (S,G,rpt) State Maintenance 6.4. E-IP (S,G,rpt) State Maintenance
When an AFBR wishes to propagate a Join/Prune(S,G,rpt) message to an When an AFBR wishes to propagate a Join/Prune(S,G,rpt) message to an
I-IP upstream router, the AFBR MUST do as specified in Section 6.5 I-IP upstream router, the AFBR MUST do as specified in Section 6.5
and Section 6.6. and Section 6.6.
6.5. Inter-AFBR Signaling 6.5. Inter-AFBR Signaling
Assume that one downstream AFBR has joined a RPT of (*,G) and a SPT Assume that one downstream AFBR has joined a RPT of (*,G) and a SPT
of (S,G), and decide to perform a SPT switchover. According to of (S,G), and decide to perform a SPT switchover. According to
[RFC4601] , it should propagate a Prune(S,G,rpt) message along with [RFC4601], it should propagate a Prune(S,G,rpt) message along with
the periodical Join(*,G) message upstream towards RP. Unfortunately, the periodical Join(*,G) message upstream towards RP. Unfortunately,
routers in I-IP transit core are not supposed to understand (S,G,rpt) routers in I-IP transit core are not supposed to understand (S,G,rpt)
messages since I-IP transit core is treated as SSM-only. As a messages since I-IP transit core is treated as SSM-only. As a
result, this downstream AFBR is unable to prune S from this RPT, then result, this downstream AFBR is unable to prune S from this RPT, then
it will receive two copies of the same data of (S,G). In order to it will receive two copies of the same data of (S,G). In order to
solve this problem, we introduce a new mechanism for downstream AFBRs solve this problem, we introduce a new mechanism for downstream AFBRs
to inform upstream AFBRs of pruning any given S from RPT. to inform upstream AFBRs of pruning any given S from RPT.
When a downstream AFBR wishes to propagate a (S,G,rpt) message When a downstream AFBR wishes to propagate a (S,G,rpt) message
upstream, it should encapsulate the (S,G,rpt) message, then unicast upstream, it should encapsulate the (S,G,rpt) message, then unicast
skipping to change at page 16, line 8 skipping to change at page 16, line 8
(S,G,rpt) messages the upstream AFBR receives, and prune S from the (S,G,rpt) messages the upstream AFBR receives, and prune S from the
RPT of group G when no downstream AFBR wants to receive multicast RPT of group G when no downstream AFBR wants to receive multicast
data of (S,G) along the RPT. In this way, we do insure that data of (S,G) along the RPT. In this way, we do insure that
downstream AFBRs won't miss any multicast data that they needs, at downstream AFBRs won't miss any multicast data that they needs, at
the cost of duplicated multicast data of (S,G) along the RPT received the cost of duplicated multicast data of (S,G) along the RPT received
by SPT-switched-over downstream AFBRs, if there exists at least one by SPT-switched-over downstream AFBRs, if there exists at least one
downstream AFBR that hasn't yet sent Prune(S,G,rpt) messages to the downstream AFBR that hasn't yet sent Prune(S,G,rpt) messages to the
upstream AFBR. The following diagram shows an example of how an upstream AFBR. The following diagram shows an example of how an
"interface agent" may be implemented: "interface agent" may be implemented:
+----------------------------------------+ +----------------------------------------+
| | | |
| +-----------+----------+ | | +-----------+----------+ |
| | PIM-SM | UDP | | | | PIM-SM | UDP | |
| +-----------+----------+ | | +-----------+----------+ |
| ^ | | | ^ | |
| | | | | | | |
| | v | | | v |
| +----------------------+ | | +----------------------+ |
| | I/F Agent | | | | I/F Agent | |
| +----------------------+ | | +----------------------+ |
| PIM ^ | multicast | | PIM ^ | multicast |
| messages | | data | | messages | | data |
| | +-------------+---+ | | | +-------------+---+ |
| +--+--|-----------+ | | | +--+--|-----------+ | |
| | v | v | | | v | v |
| +--------- + +----------+ | | +--------- + +----------+ |
| | I-IP I/F | | I-IP I/F | | | | I-IP I/F | | I-IP I/F | |
| +----------+ +----------+ | | +----------+ +----------+ |
| ^ | ^ | | | ^ | ^ | |
| | | | | | | | | | | |
+--------|-----|----------|-----|--------+ +--------|-----|----------|-----|--------+
| v | v | v | v
Figure 7: Interface Agent Implementation Example Figure 7: Interface Agent Implementation Example
In this example, the interface agent has two responsibilities: In the In this example, the interface agent has two responsibilities: In the
control plane, it should work as a real interface that has joined control plane, it should work as a real interface that has joined
(*,G) in representative of all the I-IP interfaces who should have (*,G) in representative of all the I-IP interfaces who should have
been outgoing interfaces of (*,G) state machine, and process the been outgoing interfaces of (*,G) state machine, and process the
(S,G,rpt) messages received from all the I-IP interfaces. The (S,G,rpt) messages received from all the I-IP interfaces. The
interface agent maintains downstream (S,G,rpt) state machines of interface agent maintains downstream (S,G,rpt) state machines of
every downstream AFBR, and submits Prune(S,G,rpt) messages to the every downstream AFBR, and submits Prune(S,G,rpt) messages to the
 End of changes. 25 change blocks. 
128 lines changed or deleted 128 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/