draft-ietf-softwire-mesh-multicast-02.txt   draft-ietf-softwire-mesh-multicast-03.txt 
Network Working Group M. Xu Network Working Group M. Xu
Internet-Draft Y. Cui Internet-Draft Y. Cui
Expires: October 20, 2012 S. Yang Expires: January 15, 2013 J. Wu
J. Wu S. Yang
Tsinghua University Tsinghua University
C. Metz C. Metz
G. Shepherd G. Shepherd
Cisco Systems Cisco Systems
April 18, 2012 July 14, 2012
Softwire Mesh Multicast Softwire Mesh Multicast
draft-ietf-softwire-mesh-multicast-02 draft-ietf-softwire-mesh-multicast-03
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 attendant protocol suites support multicast of the families and their attendant 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
expected that the I-IP backbone will offer unicast and multicast expected that the I-IP backbone will offer unicast and multicast
transit services to the client E-IP networks. transit services to the client E-IP networks.
Softwires Mesh is a solution to E-IP unicast and multicast support Softwire Mesh is a solution to E-IP unicast and multicast support
across an I-IP backbone. This document describes the mechanisms for across an I-IP backbone. This document describes the mechanisms for
supporting Internet-style multicast across a set of E-IP and I-IP supporting Internet-style multicast across a set of E-IP and I-IP
networks supporting softwires mesh. networks supporting softwire mesh.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 20, 2012. This Internet-Draft will expire on January 15, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scenarios of Interest . . . . . . . . . . . . . . . . . . . . 7 3. Scenarios of Interest . . . . . . . . . . . . . . . . . . . . 7
3.1. IPv4-over-IPv6 . . . . . . . . . . . . . . . . . . . . . . 7 3.1. IPv4-over-IPv6 . . . . . . . . . . . . . . . . . . . . . . 7
3.2. IPv6-over-IPv4 . . . . . . . . . . . . . . . . . . . . . . 8 3.2. IPv6-over-IPv4 . . . . . . . . . . . . . . . . . . . . . . 8
4. IPv4-over-IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 10 4. IPv4-over-IPv6 Mechanism . . . . . . . . . . . . . . . . . . . 10
4.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . . 10
4.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 10 4.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 10
4.3. Source Address Mapping . . . . . . . . . . . . . . . . . . 11 4.3. Source Address Mapping . . . . . . . . . . . . . . . . . . 11
4.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 12 4.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 12
4.5. Actions performed by AFBR . . . . . . . . . . . . . . . . 12 5. IPv6-over-IPv4 Mechanism . . . . . . . . . . . . . . . . . . . 14
5. IPv6-over-IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . . 14
5.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 14
5.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 16 5.3. Source Address Mapping . . . . . . . . . . . . . . . . . . 14
5.3. Source Address Mapping . . . . . . . . . . . . . . . . . . 16 5.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 15
5.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 17 6. Actions performed by AFBR . . . . . . . . . . . . . . . . . . 17
5.5. Actions performed by AFBR . . . . . . . . . . . . . . . . 18 6.1. E-IP (*,G) state maintenance . . . . . . . . . . . . . . . 17
6. Other Consideration . . . . . . . . . . . . . . . . . . . . . 21 6.2. E-IP (S,G) state maintenance . . . . . . . . . . . . . . . 17
6.1. Selecting a Tunneling Technology . . . . . . . . . . . . . 21 6.3. I-IP (S',G') state maintenance . . . . . . . . . . . . . . 17
6.2. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 21 6.4. E-IP (S,G,rpt) state maintenance . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.5. Inter-AFBR signaling . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6.6. Process and forward multicast data . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.7. SPT switchover . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 7. Other Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 24 7.1. Other PIM Message Types . . . . . . . . . . . . . . . . . 21
7.2. Selecting a Tunneling Technology . . . . . . . . . . . . . 21
7.3. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
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 attendant protocol suites support multicast of the families and their attendant 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). IP address family (referred to as external IP or E-IP).
The preferred solution is to leverage the multicast functions, The preferred solution is to leverage the multicast functions
inherent in the I-IP backbone, to efficiently and scalably tunnel inherent in the I-IP backbone, to efficiently and scalably forward
encapsulated client E-IP multicast packets inside an I-IP core tree, client E-IP multicast packets inside an I-IP core tree, which roots
which roots at one or more ingress AFBR nodes and branches out to one at one or more ingress AFBR nodes and branches out to one or more
or more egress AFBR leaf nodes. egress AFBR leaf nodes.
[6] outlines the requirements for the softwires mesh scenario [6] 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 [10]. MVPN-like schemes can support the softwire mesh outlined in [10]. MVPN-like schemes can support the softwire mesh
scenario and achieve a "many-to-one" mapping between the E-IP client scenario and achieve a "many-to-one" mapping between the E-IP client
multicast trees and transit core multicast trees. The advantage of multicast trees and the transit core multicast trees. The advantage
this approach is that the number of trees in the I-IP backbone 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 client network scales less than linearly with the number of E-IP client
trees. Corporate enterprise networks and by extension multicast VPNs trees. Corporate enterprise networks and by extension multicast VPNs
have been known to run applications that create a large amount of have been known to run applications that create a large amount of
(S,G) states. Aggregation at the edge contains the (S,G) states that (S,G) states. Aggregation at the edge contains the (S,G) states that
need to be maintained by the network operator supporting the customer need to be maintained by the network operator supporting the customer
VPNs. The disadvantage of this approach is the possible inefficient VPNs. The disadvantage of this approach is the possible inefficient
bandwidth and resource utilization when multicast packets are bandwidth and resource utilization when multicast packets are
delivered to a receiver AFBR with no attached E-IP receiver. delivered to a receiver AFBR with no attached E-IP receivers.
Internet-style multicast is somewhat different in that the trees Internet-style multicast is somewhat different in that the trees tend
tends to be relatively sparse and source-rooted. The need for to be relatively sparse and source-rooted. The need for multicast
multicast aggregation at the edge (where many customer multicast aggregation at the edge (where many customer multicast trees are
trees are mapped into a few or one backbone multicast trees) does not mapped into a few or one backbone multicast trees) does not exist and
exist and to date has not been identified. Thus the need for a basic to date has not been identified. Thus the need for a basic or closer
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 [8]. In A framework on how to support such methods is described in [8]. In
this document, a more detailed discussion supporting the "one-to-one" this document, a more detailed discussion supporting the "one-to-one"
mapping schemes for the IPv6 over IPv4 and IPv4 over IPv6 scenarios mapping schemes for the IPv6 over IPv4 and IPv4 over IPv6 scenarios
will be discussed. 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 the 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 : | message 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 | --------
skipping to change at page 6, line 30 skipping to change at page 6, line 30
o E-IP (External IP): This refers to the form of IP (i.e. either IPv4 o E-IP (External IP): This refers to the form of IP (i.e. either IPv4
or IPv6) that is supported by the client network(s) attached to the or IPv6) that is supported by the client network(s) attached to the
I-IP transit core. An E-IPv6 client network runs IPv6 and an E-IPv4 I-IP transit core. An E-IPv6 client network runs IPv6 and an E-IPv4
client network runs IPv4. client network runs IPv4.
o I-IP core tree: A distribution tree rooted at one or more AFBR o I-IP core tree: A distribution tree rooted at one or more AFBR
source nodes and branched out to one or more AFBR leaf nodes. An source nodes and branched out to one or more AFBR leaf nodes. An
I-IP core tree is built using standard IP or MPLS multicast signaling I-IP core tree is built using standard IP or MPLS multicast signaling
protocols operating exclusively inside the I-IP core network. An protocols operating exclusively inside the I-IP core network. An
I-IP core tree is used to tunnel E-IP multicast packets belonging to I-IP core tree is used to forward E-IP multicast packets belonging to
E-IP trees across the I-IP core. Another name for an I-IP core tree E-IP trees across the I-IP core. Another name for an I-IP core tree
is multicast or multipoint softwire. is multicast or multipoint softwire.
o E-IP client tree: A distribution tree rooted at one or more hosts o E-IP client tree: A distribution tree rooted at one or more hosts
or routers located inside a client E-IP network and branched out to or routers located inside a client E-IP network and branched out to
one or more leaf nodes located in the same or different client E-IP one or more leaf nodes located in the same or different client E-IP
networks. networks.
o uPrefix64: The /96 unicast IPv6 prefix for constructing IPv4- o uPrefix64: The /96 unicast IPv6 prefix for constructing IPv4-
embedded IPv6 source address. embedded IPv6 source address.
skipping to change at page 7, line 18 skipping to change at page 7, line 18
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(A) AFBR upstream AFBR
| | | |
__+____________________+__ __+____________________+__
/ : : : : \ / : : : : \
| : : : : | | : : : : |
| : IPv6 transit core : | | : IPv6 transit core : |
| : : : : | | : : : : |
| : : : : | | : : : : |
\_._._._._._._._._._._._._./ \_._._._._._._._._._._._._./
+ + + +
downstream AFBR(C) downstream AFBR(D) 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
skipping to change at page 10, line 5 skipping to change at page 10, line 5
This clear mismatch in IPv6 and IPv4 group address lengths means that This clear mismatch in IPv6 and IPv4 group address lengths means that
it will not be possible to perform a one-to-one mapping between IPv6 it will not be possible to perform a one-to-one mapping between IPv6
and IPv4 group addresses unless the IPv6 group address is scoped. and IPv4 group addresses unless the IPv6 group address is scoped.
As mentioned earlier, this scenario is common in the MVPN As mentioned earlier, this scenario is common in the MVPN
environment. As native IPv6 deployments and multicast applications environment. As native IPv6 deployments and multicast applications
emerge from the outer reaches of the greater public IPv4 Internet, it emerge from the outer reaches of the greater public IPv4 Internet, it
is envisaged that the IPv6 over IPv4 softwire mesh multicast scenario is envisaged that the IPv6 over IPv4 softwire mesh multicast scenario
will be a necessary feature supported by network operators. will be a necessary feature supported by network operators.
4. IPv4-over-IPv6 4. IPv4-over-IPv6 Mechanism
4.1. Mechanism 4.1. Mechanism Overview
Routers in the client E-IPv4 networks contain routes to all other Routers in the client E-IPv4 networks contain routes to all other
client E-IPv4 networks. Through the set of known and deployed client E-IPv4 networks. Through the set of known and deployed
mechanisms, E-IPv4 hosts and routers have discovered or learned of mechanisms, E-IPv4 hosts and routers have discovered or learnt of
(S,G) or (*,G) IPv4 addresses. Any I-IPv6 multicast state (S,G) or (*,G) IPv4 addresses. Any I-IPv6 multicast state
instantiated in the core is referred to as (S',G') or (*,G') and is instantiated in the core is referred to as (S',G') or (*,G') and is
certainly separated from E-IP multicast state. certainly separated from E-IPv4 multicast state.
Suppose a downstream AFBR receives an E-IPv4 PIM Join/Prune message Suppose a downstream AFBR receives an E-IPv4 PIM Join/Prune message
from the E-IPv4 network for either an (S,G) tree or a (*,G) tree. from the E-IPv4 network for either an (S,G) tree or a (*,G) tree.
The AFBR can translate the E-IPv4 PIM message into an I-IPv6 PIM The AFBR can translate the E-IPv4 PIM message into an I-IPv6 PIM
message with the latter being directed towards I-IP IPv6 address of message with the latter being directed towards I-IP IPv6 address of
the upstream AFBR. When the I-IPv6 PIM message arrives at the the upstream AFBR. When the I-IPv6 PIM message arrives at the
upstream AFBR, it should be translated back into an E-IPv4 PIM upstream AFBR, it should be translated back into an E-IPv4 PIM
message. The result of these actions is the construction of E-IPv4 message. The result of these actions is the construction of E-IPv4
trees and a corresponding I-IP tree in the I-IP network. trees and a corresponding I-IP tree in the I-IP network.
skipping to change at page 10, line 38 skipping to change at page 10, 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.
[11] has already defined an applicable format. Figure 4 is the [11] has already defined an applicable format. Figure 4 is the
reminder of the format: reminder of the format:
| 8 | 4 | 4 | 16 | 4 | 60 | 32 | | 8 | 4 | 4 | 16 | 4 | 60 | 32 |
+--------+----+----+-----------+----+------------------+----------+ +--------+----+----+-----------+----+------------------+----------+
|11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| |11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address|
+--------+----+----+-----------+----+------------------+----------+ +--------+----+----+-----------+----+------------------+----------+
+-+-+-+-+ +-+-+-+-+
IPv4-IPv6 Interconnection bits (64IX): |M|r|r|r| IPv4-IPv6 Interconnection bits (64IX): |M|resvd|
+-+-+-+-+ +-+-+-+-+
"resvd" are reserved bits.
Figure 4: IPv4-Embedded IPv6 Multicast Address Format: SSM Mode Figure 4: IPv4-Embedded IPv6 Multicast Address Format: SSM Mode
The high order bits of the I-IPv6 address range will be fixed for The high order bits of the I-IPv6 address range will be fixed for
mapping purposes. With this scheme, each IPv4 multicast address can mapping purposes. With this scheme, each IPv4 multicast address can
be mapped into an IPv6 multicast address(with the assigned prefix), be mapped into an IPv6 multicast address(with the assigned prefix),
and each IPv6 multicast address with the assigned prefix can be and each IPv6 multicast address with the assigned prefix can be
mapped into IPv4 multicast address. mapped into IPv4 multicast address.
4.3. Source Address Mapping 4.3. Source Address Mapping
skipping to change at page 11, line 44 skipping to change at page 12, line 4
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 [9]; "v4" field is the IP address is 64:ff9b, which is defined in [9]; "v4" field is the IP address
of one of upstream AFBR's E-IPv4 interfaces; "u" field is defined of one of upstream AFBR's E-IPv4 interfaces; "u" field is defined
in [4], and MUST be set to zero; "suffix" field is reserved for in [4], and MUST be set to zero; "suffix" field is reserved for
future extensions and SHOULD be set to zero; "source address" future extensions and SHOULD be set to zero; "source address"
field stores the original S. We call the overall /96 prefix field stores the original S. We call the overall /96 prefix
("prefix" field and "v4" field and "u" field and "suffix" field ("prefix" field and "v4" field and "u" field and "suffix" field
altogether) "uPrefix64". 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
ASM and SSM have simalar PIM message format. The main differences differ in that the latter have both the WC and RPT bits of the
between ASM and SSM are RP and (*,G) messages. To make this Encoded-Source-Address set, while the former all cleared (See
scenario feasible, we must be able to translate (*,G) messages Section 4.9.5.1 of [5]). So we can translate source list entries
into (S',G') messages at downstream AFBRs, and translate it back in (*,G) messages into source list entries in (S'G') messages by
at upstream AFBRs. applying the format specified in Figure 5 and setting both the WC
and RPT bits at upstream AFBRs, and translate them back at
upstream AFBRs vice-versa.
4.4. Routing Mechanism 4.4. Routing Mechanism
In the mesh multicast scenario, routing information is required to In the mesh multicast scenario, routing information is required to be
distribute among AFBRs to make sure that PIM messages a downstream distributed among AFBRs to make sure that PIM messages that a
AFBR send 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. As uPrefix64 be different either, and uniquely identifies each AFBR. "uPrefix64"
is an IPv6 prefix, the distribution of uPrefix64 is the same as the is an IPv6 prefix, and the distribution of it is the same as the
distribution in mesh unicast scenario. But since "v4" field is an distribution in the traditional mesh unicast scenario. But since
E-IPv4 address, and BGP messages are NOT tunneled through softwires "v4" field is an E-IPv4 address, and BGP messages are NOT tunneled
or through any other mechanism as specified in [8], AFBRs MUST be through softwires or through any other mechanism as specified in [8],
able to transport and encode/decode BGP messages that are carried AFBRs MUST be able to transport and encode/decode BGP messages that
over I-IPv6, whose NLRI and NH are of E-IPv4 address family. are carried over I-IPv6, whose NLRI and NH are of 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 it into (S',G') by looking up the IP message, it can translate this message into (S',G') by looking up the
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 setting to *(the IPv4 in Figure 4, with "source address" field set to *(the IPv4 address of
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 [5]), when this upstream AFBR checks the same RP (see Section 4.7 of [5]), when this upstream AFBR checks
the "source address" field of the message, it'll find the IPv4 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.
4.5. Actions performed by AFBR 5. IPv6-over-IPv4 Mechanism
The following actions are performed by AFBRs:
o E-IPv4 (*,G) state maintenance
When an AFBR wishes to propagate a (*,G) Join/Prune message to an
I-IPv6 upstream router, the AFBR MUST translate (*,G) Join/Prune
messages into (S',G') Join/Prune messages following the rules
specified above, then send the latter.
o E-IPv4 (S,G) state maintenance
When an AFBR wishes to propagate a (S,G) Join/Prune message to an
I-IPv6 upstream router, the AFBR MUST translate (S,G) Join/Prune
messages into (S',G') Join/Prune messages following the rules
specified above, then send the latter.
o I-IPv6 (S',G') state maintenance
It is possible that there runs a pure I-IPv6 PIM-SSM in the I-IPv6
transit core. Since the translated souce address starts with the
unique "Well-Known" prefix or the ISP-defined prefix that should
not be used otherwise, mash multicast won't influnce pure PIM-SM
multicast at all. When one AFBR receives a I-IPv6 (S',G')
message, it should check S'. If S' starts with the unique prefix,
it means that this message is actually a translated E-IPv4 (S,G)
or (*,G) message, then the AFBR should translate this message back
to E-IPv4 PIM message and process it.
o E-IPv4 (S,G,rpt) state maintenance
When an AFBR wishes to propagate a (S,G,rpt) Join/Prune message to
an I-IPv6 upstream router, the AFBR MUST do as follows.
o Inter-AFBR signaling
(S,G,rpt) messages are not supported by I-IPv6 transit core since
I-IPv6 transit core only works in SSM. As a result, we're unable
to stop receiving data from any given S along the RP tree even if
downstream AFBR has already switched over to the SPT, which may
bring about a lot of redundancy. In order to solve this problem,
we introduce a new mechanism for downstream AFBR to inform
upstream AFBR to prune a given S from RPT, in order to reduce
redundancy.
When a downstream AFBR wishes to propagate a (S,G,rpt) message to
I-IPv6 upstream router, it should encapsulate the (S,G,rpt)
message, then unicast the encapsulated message to the
corresponding upstream AFBR, which we call it "RP'".
The encapsulated message will evevtually arrive at RP', but the
incoming interface of it may be different from the outcoming
interface along the RP tree to the corresponding downstream AFBR
that send this message, so RP' is unable to determine the
(S,G,rpt) state of each I-IPv6 outgoing interface. To solve this
problem, and keep the solution as simple as possible, we
conceptually treat all the I-IPv6 outgoing interfaces as equal,
and introduce a "virtual interface" as the representative of all
the I-IPv6 outgoing interfaces, which is specified in Figure 6.
+----------------------------------------+
| |
| +-----------+----------+ |
| | PIM-SSM | UDP | |
| +-----------+----------+ |
| ^ | |
| | | |
| | v |
| +----------------------+ |
| | Virtual I/F | |
| +----------------------+ |
| PIM ^ | multicast |
| messages | | data |
| | +-------------+---+ |
| +--+--|-----------+ | |
| | v | v |
| +--------- + +----------+ |
| | I-IP I/F | | I-IP I/F | |
| +----------+ +----------+ |
| ^ | ^ | |
| | | | | |
+--------|-----|----------|-----|--------+
| v | v
Figure 6: upstream AFBR virtual interface
The virtual interface has two responsibilities: On control plane,
it should process the encapsulated (S,G,rpt) messages received
from all the I-IPv6 interfaces, and work as a real interface that
has joint (*,G). Since all the I-IPv6 interfaces are treated
equal, the virtual interface only send (S,G,rpt) Prune messages to
PIM-SSM module when every received encapsulated message has a
(S,G,rpt) Prune inside, which means that no downstream AFBR want
to receive data from source S of group G along the RPT; On data
plane, upon receiving a multicast data packet, the virtual
interface should encapsulate it at first, then send to every
I-IPv6 interface a copy of the encapsulated data.In this way,
downstream AFBRS may receive some redundant data, but avoid black
holes.
NOTICE: There may exist an E-IPv4 neighbor of RP' that has joint
the RP tree, so the per-interface state machine for receiving
E-IPv4 (S,G,rpt) Join/Prune messages should still take effect.
o Process and forward multicast data
On receiving multicast data from upstream routers, the AFBR looks
up its forwarding table to check the IP address of each outgoing
interface. If there exists at least one outgoing interface whose
IP address family is different from the incoming interface, the
AFBR should encapsulate/decapsulate this packet and forward it to
the outgoing interface(s), then forward the data to other outgoing
interfaces without encapsulation/decapsulation.
Since all I-IP interfaces of upstream AFBR are treated equal, a
AFBR may receive encapsulated data from S along the RP tree even
if it has already switched over to SPT of S. At this time, the
AFBR should silently drop this data.
o SPT switchover
When a new AFBR expresses its interest in receiving traffic
destined for a multicast group, it needs to receive all the data
along the RP tree at first. But since downstream AFBRs in fact
receive the union set of data needed by every downstream AFBR, RP'
has to forward all the data from RP to all the downstream AFBRs.
As a result, the downstream AFBRs that have already switched to
the shortest-path tree will receive two copies of the same data,
namely redundancy.
To reduce the redundancy, we recommend every AFBR's
SwitchToSptDesired(S,G) function employ the "switch on first
packet" policy. In this way, the delay of switchover to SPT is
kept as little as possible, so is the redundancy.
5. IPv6-over-IPv4
5.1. Mechanism 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
client E-IPv6 networks. Through the set of known and deployed client E-IPv6 networks. Through the set of known and deployed
mechanisms, E-IPv6 hosts and routers have discovered or learned of mechanisms, E-IPv6 hosts and routers have discovered or learnt of
(S,G) or (*,G) IPv6 addresses. Any I-IP multicast state instantiated (S,G) or (*,G) IPv6 addresses. Any I-IP multicast state instantiated
in the core is referred to as (S',G') or (*,G') and is certainly in the core is referred to as (S',G') or (*,G') and is certainly
separated from E-IP multicast state. separated from E-IP multicast state.
This particular scenario introduces unique challenges. Unlike the This particular scenario introduces unique challenges. Unlike the
IPv4-over-IPv6 scenario, it's impossible to map all of the IPv6 IPv4-over-IPv6 scenario, it's impossible to map all of the IPv6
multicast address space into the IPv4 address space to address the multicast address space into the IPv4 address space to address the
one-to-one Softwire Multicast requirement. To coordinate with the one-to-one Softwire Multicast requirement. To coordinate with the
"IPv4-over-IPv6" scenario and keep the solution as simple as "IPv4-over-IPv6" scenario and keep the solution as simple as
possible, one possible solution to this problem is to limit the scope possible, one possible solution to this problem is to limit the scope
skipping to change at page 17, line 10 skipping to change at page 15, line 10
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 [9]. problem. A recommended source address format is defined in [9].
Figure 7 is the reminder of the format: 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 7: 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 [9]; "source address" prefix is 64:ff9b/32, which is defined in [9]; "source address"
field is the corresponding I-IPv4 source address. field is the corresponding I-IPv4 source address.
o E-IP network supports ASM o E-IP network supports ASM
ASM and SSM have similar PIM message format. The main differences The (S,G) source list entry and the (*,G) source list entry only
between ASM and SSM are RP and (*,G) messages. To make this differ in that the latter have both the WC and RPT bits of the
scenario feasible, we must be able to translate (*,G) messages Encoded-Source-Address set, while the former all cleared (See
into (S',G') messages at downstream AFBRs and translate it back at Section 4.9.5.1 of [5]). So we can translate source list entries
upstream AFBRs. Here, the E-IPv6 address of RP MUST follow the in (*,G) messages into source list entries in (S'G') messages by
format specified in Figure 7. Assume RP' is the upstream AFBR applying the format specified in Figure 5 and setting both the WC
and RPT bits at upstream AFBRs, and translate them 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 AFBR
that locates between RP and the downstream 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 In the mesh multicast scenario, routing information is required to be
distribute among AFBRs to make sure that PIM messages a downstream distributed among AFBRs to make sure that PIM messages that a
AFBR send reach the right upstream AFBR. downstream AFBR propagates reach the right upstream AFBR.
To make it feasible, the /96 uPrefix64 must be known to every AFBR, To make it feasible, the /96 uPrefix64 must be known to every AFBR,
every E-IPv6 address of sources that support mesh multicast MUST every E-IPv6 address of sources that support mesh multicast MUST
follow the format specified in Figure 7, and the corresponding follow the format specified in Figure 6, and the corresponding
upstream AFBR should announce the I-IPv4 address in "source address" upstream AFBR of this source should announce the I-IPv4 address in
field to the I-IPv4 network. Since uPrefix64 is static and unique in "source address" field of this source's IPv6 address to the I-IPv4
IPv6-over-IPv4 scenario, there is no need to distribute it using BGP. network. Since uPrefix64 is static and unique in IPv6-over-IPv4
scenario, there is no need to distribute it using BGP. The
The distribution of "source address" field of multicast source distribution of "source address" field of multicast source addresses
addresses is a pure I-IPv4 process and no more specification is is a pure I-IPv4 process and no more specification is needed.
needed.
In this way, when a downstream AFBR receives a (S,G) message, it can In this way, when a downstream AFBR receives a (S,G) message, it can
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 [5]), RP' knows that S' is the mapped the same RP (see Section 4.7 of [5]), RP' knows that S' is the mapped
I-IPv4 address of RP, so RP' will translate the message back to (*,G) 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. by appending the prefix to S' and propagate it towards RP.
5.5. Actions performed by AFBR 6. Actions performed by AFBR
The following actions are performed by AFBRs: The following actions are performed by AFBRs:
o E-IPv6 (*,G) state maintenance 6.1. E-IP (*,G) state maintenance
When an AFBR wishes to propagate a (*,G) Join/Prune message to an When an AFBR wishes to propagate a Join/Prune(*,G) message to an I-IP
I-IPv4 upstream router, the AFBR MUST translate (*,G) Join/Prune upstream router, the AFBR MUST translate Join/Prune(*,G) messages
messages into (S',G') Join/Prune messages following the rules into Join/Prune(S',G') messages following the rules specified above,
specified above, then send the latter. then send the latter.
o E-IPv6 (S,G) state maintenance 6.2. E-IP (S,G) state maintenance
When an AFBR wishes to propagate a (S,G) Join/Prune message to an When an AFBR wishes to propagate a Join/Prune(S,G) message to an I-IP
I-IPv4 upstream router, the AFBR MUST translate (S,G) Join/Prune upstream router, the AFBR MUST translate Join/Prune(S,G) messages
messages into (S',G') Join/Prune messages following the rules into Join/Prune(S',G') messages following the rules specified above,
specified above, then send the latter. then send the latter.
o I-IPv4 (S',G') state maintenance 6.3. I-IP (S',G') state maintenance
It is possible that there runs a pure I-IPv4 PIM-SSM in the I-IPv4 It is possible that there runs a non-transit I-IP PIM-SSM in the I-IP
transit core. Since the translated souce address is known to the transit core. Since the translated source address starts with the
corresponding upstream AFBR, mash multicast won't influnce pure unique "Well-Known" prefix or the ISP-defined prefix that should not
PIM-SM multicast at all. When one AFBR receives a (S',G') message be used otherwise, mesh multicast won't influence non-transit PIM-SM
whose S' is the "source address" field of an E-IPv6 source, which multicast at all. When one AFBR receives an I-IP (S',G') message, it
means that this message is actually a translated E-IPv6 (S,G) or should check S'. If S' starts with the unique prefix, it means that
(*,G) message, it should translate this message back to E-IPv6 PIM this message is actually a translated E-IP (S,G) or (*,G) message,
message and process it. then the AFBR should translate this message back to E-IP PIM message
and process it.
o E-IPv6 (S,G,rpt) state maintenance 6.4. E-IP (S,G,rpt) state maintenance
When an AFBR wishes to propagate a (S,G,rpt) Join/Prune message to When an AFBR wishes to propagate a Join/Prune(S,G,rpt) message to an
an I-IPv4 upstream router, the AFBR MUST do as follows. I-IP upstream router, the AFBR MUST do as specified in Section 6.5
and Section 6.6.
o Inter-AFBR signaling 6.5. Inter-AFBR signaling
(S,G,rpt) messages are not supported by I-IPv4 transit core since Assume that one downstream AFBR has joined a RPT of (*,G) and a SPT
I-IPv4 transit core only works in SSM. As a result, we're unable of (S,G), and decide to perform a SPT switchover. According to [5],
to stop receiving data from any given S along the RP tree even if it should propagate a Prune(S,G,rpt) message along with the
downstream AFBR has already switched over to the SPT, which may periodical Join(*,G) message upstream towards RP. Unfortunately,
bring about a lot of redundancy. In order to solve this problem, routers in I-IP transit core are not supposed to understand (S,G,rpt)
we introduce a new mechanism for downstream AFBR to inform messages since I-IP transit core is treated as SSM-only. As a
upstream AFBR to prune a given S from RPT, in order to reduce result, this downstream AFBR is unable to prune S from this RPT, then
redundancy. 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
to inform upstream AFBRs of pruning any given S from RPT.
When a downstream AFBR wishes to propagate a (S,G,rpt) message to When a downstream AFBR wishes to propagate a (S,G,rpt) message
I-IPv4 upstream router, it should encapsulate the (S,G,rpt) upstream router, it should encapsulate the (S,G,rpt) message, then
message, then unicast the encapsulated message to the unicast the encapsulated message to the corresponding upstream AFBR,
corresponding upstream AFBR, which we call it "RP'". which we call "RP'".
The encapsulated message will evevtually arrive at RP', but the When RP' receives this encapsulated message, it should decapsulate
incoming interface of it may be different from the outcoming this message as what it does in the unicast scenario, and get the
interface along the RP tree to the corresponding downstream AFBR original (S,G,rpt) message. The incoming interface of this message
that send this message, so RP' is unable to determine the may be different from the outgoing interface which propagates
(S,G,rpt) state of each I-IPv4 outgoing interface. To solve this multicast data to the corresponding downstream AFBR, and there may be
problem, and keep the solution as simple as possible, we other downstream AFBRs that need to receive multicast data of (S,G)
conceptually treat all the I-IPv4 outgoing interfaces as equal, from this incoming interface, so RP' should not simply process this
and introduce a "virtual interface" as the representative of all message as specified in [5] on the incoming interface.
the I-IPv4 outgoing interfaces, which is specified in Figure 6.
The virtual interface has two responsibilities: On control plane, To solve this problem, and keep the solution as simple as possible,
it should process the encapsulated (S,G,rpt) messages received we introduce an "interface agent" to process all the encapsulated
from all the I-IPv4 interfaces, and work as a real interface that (S,G,rpt) messages the upstream AFBR receives, and prune S from the
has joint (*,G). Since all the I-IPv4 interfaces are treated RPT of group G when no downstream AFBR wants to receive multicast
equal, the virtual interface only send (S,G,rpt) Prune messages to data of (S,G) along the RPT. In this way, we do insure that
PIM-SSM module when every received encapsulated message has a downstream AFBRs won't miss any multicast data that they needs, at
(S,G,rpt) Prune inside, which means that no downstream AFBR want the cost of duplicated multicast data of (S,G) along the RPT received
to receive data from source S of group G along the RPT; On data by SPT-switched-over downstream AFBRs, if there exists at least one
plane, upon receiving a multicast data packet, the virtual downstream AFBR that hasn't yet sent Prune(S,G,rpt) messages to the
interface should encapsulate it at first, then send to every upstream AFBR. The following diagram shows an example of how an
I-IPv4 interface a copy of the encapsulated data.In this way, "interface agent" may be implemented:
downstream AFBRS may receive some redundant data, but avoid black
holes.
NOTICE: There may exist an E-IPv6 neighbor of RP' that has joint +----------------------------------------+
the RP tree, so the per-interface state machine for receiving | |
E-IPv6 (S,G,rpt) Join/Prune messages should still take effect. | +-----------+----------+ |
| | PIM-SM | UDP | |
| +-----------+----------+ |
| ^ | |
| | | |
| | v |
| +----------------------+ |
| | I/F Agent | |
| +----------------------+ |
| PIM ^ | multicast |
| messages | | data |
| | +-------------+---+ |
| +--+--|-----------+ | |
| | v | v |
| +--------- + +----------+ |
| | I-IP I/F | | I-IP I/F | |
| +----------+ +----------+ |
| ^ | ^ | |
| | | | | |
+--------|-----|----------|-----|--------+
| v | v
o Process and forward multicast data Figure 7: Interface Agent Implementation Example
On receiving multicast data from upstream routers, the AFBR looks In this example, the interface agent has two responsibilities: In the
up its forwarding table to check the IP address of each outgoing control plane, it should work as a real interface that has joined
interface. If there exists at least one outgoing interface whose (*,G) in representative of all the I-IP interfaces who should have
IP address family is different from the incoming interface, the been outgoing interfaces of (*,G) state machine, and process the
AFBR should encapsulate/decapsulate this packet and forward it to (S,G,rpt) messages received from all the I-IP interfaces. The
the outgoing interface(s), then forward the data to other outgoing interface agent maintains downstream (S,G,rpt) state machines of
interfaces without encapsulation/decapsulation. every downstream AFBR, and submits Prune(S,G,rpt) messages to the
PIM-SM module only when every (S,G,rpt) state machine is at Prune(P)
or PruneTmp(P') state, which means that no downstream AFBR wants to
receive multicast data of (S,G) along the RPT of G. Once a (S,G,rpt)
state machine changes to NoInfo(NI) state, which means that the
corresponding downstream AFBR has changed it mind to receive
multicast data of (S,G) along the RPT again, the interface agent
should send a Join(S,G,rpt) to PIM-SM module immediately; In the data
plane, upon receiving a multicast data packet, the interface agent
should encapsulate it at first, then propagate the encapsulated
packet onto every I-IP interface.
Since all I-IP interfaces of upstream AFBR are treated equal, a NOTICE: There may exist an E-IP neighbor of RP' that has joined the
AFBR may receive encapsulated data from S along the RP tree even RPT of G, so the per-interface state machine for receiving E-IP Join/
if it has already switched over to SPT of S. At this time, the Prune(S,G,rpt) messages should still take effect.
AFBR should silently drop this data.
o SPT switchover 6.6. Process and forward multicast data
When a new AFBR expresses its interest in receiving traffic On receiving multicast data from upstream routers, the AFBR looks up
destined for a multicast group, it needs to receive all the data its forwarding table to check the IP address of each outgoing
along the RP tree at first. But since downstream AFBRs in fact interface. If there exists at least one outgoing interface whose IP
receive the union set of data needed by every downstream AFBR, RP' address family is different from the incoming interface, the AFBR
has to forward all the data from RP to all the downstream AFBRs. should encapsulate/decapsulate this packet and forward it to such
As a result, the downstream AFBRs that have already switched to outgoing interface(s), then forward the data to other outgoing
the shortest-path tree will receive two copies of the same data, interfaces without encapsulation/decapsulation.
namely redundancy.
To reduce the redundancy, we recommend every AFBR's When a downstream AFBR that has already switched over to SPT of S
SwitchToSptDesired(S,G) function employ the "switch on first receives an encapsulated multicast data packet of (S,G) along the
packet" policy. In this way, the delay of switchover to SPT is RPT, it should silently drop this packet.
kept as little as possible, so is the redundancy.
6. Other Consideration 6.7. SPT switchover
6.1. Selecting a Tunneling Technology After a new AFBR expresses its interest in receiving traffic destined
for a multicast group, it will receive all the data from the RPT at
first. At this time, every downstream AFBR will receive multicast
data from any source from this RPT, in spit of whether they have
switched over to SPT of some source(s) or not.
To minimize this redundancy, it's recommended that every AFBR's
SwitchToSptDesired(S,G) function employs the "switch on first packet"
policy. In this way, the delay of switchover to SPT is kept as
little as possible, and after the moment that every AFBR has
performed the SPT switchover for every S of group G, no data will be
forwarded in the RPT of G, thus no more redundancy will be produced.
7. Other Considerations
7.1. Other PIM Message Types
Apart from Join or Prune, there exists other message types including
Register, Register-Stop, Hello and Assert. Register and Register-
Stop messages are sent by unicast, while Hello and Assert messages
are only used between routers on a link to negotiate with each other.
They don't need to be translated for forwarding, thus the process of
these messages is out of scope for this document.
7.2. Selecting a Tunneling Technology
The choice of tunneling technology is a matter of policy configured The choice of tunneling technology is a matter of policy configured
at AFBRs. at AFBRs. It's recommended that all AFBRs use the same technology,
otherwise some AFBRs may not be able to decapsulate encapsulated
packets from other AFBRs that use a different tunneling technology.
In most cases, the policy of choosing tunneling technologies will be 7.3. TTL
very simple, such as all AFBRs use the same technology. But it's
possible that there doesn't exist one technique that all AFBRs
support. A recommended solution is described in [8], which divides
AFBRs into one or more classes, and each of these classes is assigned
a technology that every AFBR in this class supports. In this way,
all the AFBRs in the same class can choose the right technology to
communicate with each other.
6.2. Fragmentation The process of TTL depends on the tunneling technology, and is out of
scope for this document.
7.4. Fragmentation
The encapsulation performed by upstream AFBR will increase the size The encapsulation performed by upstream AFBR will increase the size
of packets. As a result, the outgoing I-IP link MTU may not of packets. As a result, the outgoing I-IP link MTU may not
accommodate the extra size. As it's not always possible for core accommodate the extra size. As it's not always possible for core
operators to increase every link's MTU, fragmentation and operators to increase every link's MTU, fragmentation and
reassembling of encapsulated packets MUST be supported by AFBRs. reassembling of encapsulated packets MUST be supported by AFBRs.
7. Security Considerations 8. Security Considerations
The AFBR routers could maintain secure communications through the use The AFBR routers could maintain secure communications through the use
of Security Architecture for the Internet Protocol as described of Security Architecture for the Internet Protocol as described in
in[RFC4301]. But when adopting some schemes that will cause heavy [RFC4301]. But when adopting some schemes that will cause heavy
burden on routers, some attacker may use it as a tool for DDoS burden on routers, some attacker may use it as a tool for DDoS
attack. attack.
8. IANA Considerations 9. IANA Considerations
When AFBRs perform address mapping, they should follow some When AFBRs perform address mapping, they should follow some
predefined rules, especially the IPv6 prefix for source address predefined rules, especially the IPv6 prefix for source address
mapping should be predefined, so that ingress AFBR and egress AFBR mapping should be predefined, so that ingress AFBR and egress AFBR
can finish the mapping procedure correctly. The IPv6 prefix for can finish the mapping procedure correctly. The IPv6 prefix for
translation can be unified within only the transit core, or within translation can be unified within only the transit core, or within
global area. In the later condition, the prefix should be assigned global area. In the later condition, the prefix should be assigned
by IANA. by IANA.
9. References 10. References
9.1. Normative References 10.1. Normative References
[1] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, [1] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[2] Foster, B. and F. Andreasen, "Media Gateway Control Protocol [2] Foster, B. and F. Andreasen, "Media Gateway Control Protocol
(MGCP) Redirect and Reset Package", RFC 3991, February 2005. (MGCP) Redirect and Reset Package", RFC 3991, February 2005.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing [3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
skipping to change at page 24, line 38 skipping to change at page 24, line 38
[7] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [7] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[8] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh [8] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009. Framework", RFC 5565, June 2009.
[9] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, [9] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li,
"IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
9.2. Informative References [10] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs",
RFC 6513, February 2012.
[10] Aggarwal, R. and E. Rosen, "Multicast in MPLS/BGP IP VPNs", 10.2. Informative References
draft-ietf-l3vpn-2547bis-mcast-10 (work in progress),
January 2010.
[11] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, [11] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu,
"IPv4-Embedded IPv6 Multicast Address Format", "IPv6 Multicast Address Format With Embedded IPv4 Multicast
draft-ietf-mboned-64-multicast-address-format-01 (work in Address", draft-ietf-mboned-64-multicast-address-format-02
progress), February 2012. (work in progress), May 2012.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Wenlong Chen, Xuan Chen, Alain Durand, Yiu Lee, Jacni Qin and Stig Wenlong Chen, Xuan Chen, Alain Durand, Yiu Lee, Jacni Qin and Stig
Venaas provided useful input into this document. Venaas provided useful input into this document.
Authors' Addresses Authors' Addresses
Mingwei Xu Mingwei Xu
Tsinghua University Tsinghua University
skipping to change at page 26, line 25 skipping to change at page 26, line 25
Yong Cui Yong Cui
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: cuiyong@tsinghua.edu.cn Email: cuiyong@tsinghua.edu.cn
Shu Yang Jianping Wu
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5983
Email: yangshu@csnet1.cs.tsinghua.edu.cn Email: jianping@cernet.edu.cn
Jianping Wu Shu Yang
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R. China P.R. China
Phone: +86-10-6278-5983 Phone: +86-10-6278-5822
Email: jianping@cernet.edu.cn Email: yangshu@csnet1.cs.tsinghua.edu.cn
Chris Metz Chris Metz
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1-408-525-3275 Phone: +1-408-525-3275
Email: chmetz@cisco.com Email: chmetz@cisco.com
Greg Shepherd Greg Shepherd
 End of changes. 73 change blocks. 
349 lines changed or deleted 276 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/