draft-ietf-softwire-mesh-multicast-03.txt   draft-ietf-softwire-mesh-multicast-04.txt 
Network Working Group M. Xu Network Working Group M. Xu
Internet-Draft Y. Cui Internet-Draft Y. Cui
Expires: January 15, 2013 J. Wu Expires: July 16, 2013 J. Wu
S. Yang S. Yang
Tsinghua University Tsinghua University
C. Metz C. Metz
G. Shepherd G. Shepherd
Cisco Systems Cisco Systems
July 14, 2012 January 12, 2013
Softwire Mesh Multicast Softwire Mesh Multicast
draft-ietf-softwire-mesh-multicast-03 draft-ietf-softwire-mesh-multicast-04
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
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 January 15, 2013. This Internet-Draft will expire on July 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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 Mechanism . . . . . . . . . . . . . . . . . . . 10 4. IPv4-over-IPv6 Mechanism . . . . . . . . . . . . . . . . . . . 10
4.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . . 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
5. IPv6-over-IPv4 Mechanism . . . . . . . . . . . . . . . . . . . 14 5. IPv6-over-IPv4 Mechanism . . . . . . . . . . . . . . . . . . . 13
5.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . . 14 5.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . . 13
5.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 14 5.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 13
5.3. Source Address Mapping . . . . . . . . . . . . . . . . . . 14 5.3. Source Address Mapping . . . . . . . . . . . . . . . . . . 13
5.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 15 5.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 14
6. Actions performed by AFBR . . . . . . . . . . . . . . . . . . 17 6. Control Plane Functions of AFBR . . . . . . . . . . . . . . . 16
6.1. E-IP (*,G) state maintenance . . . . . . . . . . . . . . . 17 6.1. E-IP (*,G) State Maintenance . . . . . . . . . . . . . . . 16
6.2. E-IP (S,G) state maintenance . . . . . . . . . . . . . . . 17 6.2. E-IP (S,G) State Maintenance . . . . . . . . . . . . . . . 16
6.3. I-IP (S',G') state maintenance . . . . . . . . . . . . . . 17 6.3. I-IP (S',G') State Maintenance . . . . . . . . . . . . . . 16
6.4. E-IP (S,G,rpt) state maintenance . . . . . . . . . . . . . 17 6.4. E-IP (S,G,rpt) State Maintenance . . . . . . . . . . . . . 16
6.5. Inter-AFBR signaling . . . . . . . . . . . . . . . . . . . 17 6.5. Inter-AFBR Signaling . . . . . . . . . . . . . . . . . . . 16
6.6. Process and forward multicast data . . . . . . . . . . . . 19 6.6. SPT Switchover . . . . . . . . . . . . . . . . . . . . . . 18
6.7. SPT switchover . . . . . . . . . . . . . . . . . . . . . . 19 6.7. Other PIM Message Types . . . . . . . . . . . . . . . . . 19
7. Other Considerations . . . . . . . . . . . . . . . . . . . . . 21 6.8. Other PIM States Maintenance . . . . . . . . . . . . . . . 19
7.1. Other PIM Message Types . . . . . . . . . . . . . . . . . 21 7. Data Plane Functions of AFBR . . . . . . . . . . . . . . . . . 20
7.2. Selecting a Tunneling Technology . . . . . . . . . . . . . 21 7.1. Process and Forward Multicast Data . . . . . . . . . . . . 20
7.3. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Selecting a Tunneling Technology . . . . . . . . . . . . . 20
7.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 21 7.3. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
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).
skipping to change at page 7, line 5 skipping to change at page 6, line 42
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.
o Inter-AFBR signaling: A mechanism used by downstream AFBRs to send
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|
skipping to change at page 7, line 45 skipping to change at page 7, line 45
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
._._._._. ._._._._. ._._._._. ._._._._.
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 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+--------+----+----+-----------+----+------------------+----------+ | 0-------------32--40--48--56--64--72--80--88--96-----------127|
|11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+--------+----+----+-----------+----+------------------+----------+ | MPREFIX64 |source address |
+-+-+-+-+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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
The high order bits of the I-IPv6 address range will be fixed for The MPREFIX64 for SSM mode is also defined in [11] :
mapping purposes. With this scheme, each IPv4 multicast address can
be mapped into an IPv6 multicast address(with the assigned prefix), o ff3x:0:8000::/96 ('x' is any valid scope)
and each IPv6 multicast address with the assigned prefix can be
mapped into IPv4 multicast address. With this scheme, each IPv4 multicast address can be mapped into an
IPv6 multicast address(with the assigned prefix), and each IPv6
multicast address with the assigned prefix can be mapped into IPv4
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 [5], we can with a strict subset of the PIM-SM protocol mechanisms [5], we can
treat I-IP core as SSM-only to make it as simple as possible, then 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: there remains only two scenarios to be discussed in detail:
skipping to change at page 12, line 4 skipping to change at page 11, line 45
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 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 [5]). So we can translate source list entries Section 4.9.5.1 of [5]). So we can translate source list entries
in (*,G) messages into source list entries in (S'G') messages by in (*,G) messages into source list entries in (S'G') messages by
applying the format specified in Figure 5 and setting both the WC applying the format specified in Figure 5 and setting both the WC
and RPT bits at upstream AFBRs, and translate them back at and RPT bits at upstream AFBRs, and translate them back at
upstream AFBRs vice-versa. 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
skipping to change at page 15, line 34 skipping to change at page 14, line 34
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 [5]). So we can translate source list entries Section 4.9.5.1 of [5]). So we can translate source list entries
in (*,G) messages into source list entries in (S'G') messages by in (*,G) messages into source list entries in (S'G') messages by
applying the format specified in Figure 5 and setting both the WC applying the format specified in Figure 5 and setting both the WC
and RPT bits at upstream AFBRs, and translate them back at and RPT bits at upstream AFBRs, and translate them back at
upstream AFBRs vice-versa. Here, the E-IPv6 address of RP MUST upstream AFBRs vice versa. Here, the E-IPv6 address of RP MUST
follow the format specified in Figure 6. RP' is the upstream AFBR 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 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 /96 uPrefix64 must be known to every AFBR, To make it feasible, the /96 uPrefix64 must be known to every AFBR,
skipping to change at page 17, line 5 skipping to change at page 16, line 5
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.
6. Actions performed by AFBR 6. Control Plane Functions of AFBR
The following actions are performed by AFBRs: 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
upstream router, the AFBR MUST translate Join/Prune(*,G) messages upstream router, the AFBR MUST translate Join/Prune(*,G) messages
into Join/Prune(S',G') messages following the rules specified above, into Join/Prune(S',G') messages following the rules specified above,
then send the latter. then send the latter.
6.2. E-IP (S,G) state maintenance 6.2. E-IP (S,G) State Maintenance
When an AFBR wishes to propagate a Join/Prune(S,G) message to an I-IP When an AFBR wishes to propagate a Join/Prune(S,G) message to an I-IP
upstream router, the AFBR MUST translate Join/Prune(S,G) messages upstream router, the AFBR MUST translate Join/Prune(S,G) messages
into Join/Prune(S',G') messages following the rules specified above, into Join/Prune(S',G') messages following the rules specified above,
then send the latter. then send the latter.
6.3. I-IP (S',G') state maintenance 6.3. I-IP (S',G') State Maintenance
It is possible that there runs a non-transit I-IP PIM-SSM in the I-IP It is possible that there runs a non-transit I-IP PIM-SSM in the I-IP
transit core. Since the translated source address starts with the transit core. Since the translated source address starts with the
unique "Well-Known" prefix or the ISP-defined prefix that should not unique "Well-Known" prefix or the ISP-defined prefix that should not
be used otherwise, mesh multicast won't influence non-transit PIM-SM be used otherwise, mesh multicast won't influence non-transit PIM-SM
multicast at all. When one AFBR receives an I-IP (S',G') message, it multicast at all. When one AFBR receives an I-IP (S',G') message, it
should check S'. If S' starts with the unique prefix, it means that should check S'. If S' starts with the unique prefix, it means that
this message is actually a translated E-IP (S,G) or (*,G) message, this message is actually a translated E-IP (S,G) or (*,G) message,
then the AFBR should translate this message back to E-IP PIM message then the AFBR should translate this message back to E-IP PIM message
and process it. and process it.
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 [5], of (S,G), and decide to perform a SPT switchover. According to [5],
it should propagate a Prune(S,G,rpt) message along with the it should propagate a Prune(S,G,rpt) message along with the
periodical Join(*,G) message upstream towards RP. Unfortunately, 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
skipping to change at page 19, line 32 skipping to change at page 18, line 32
multicast data of (S,G) along the RPT again, the interface agent 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 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 plane, upon receiving a multicast data packet, the interface agent
should encapsulate it at first, then propagate the encapsulated should encapsulate it at first, then propagate the encapsulated
packet onto every I-IP interface. packet onto every I-IP interface.
NOTICE: There may exist an E-IP neighbor of RP' that has joined the NOTICE: There may exist an E-IP neighbor of RP' that has joined the
RPT of G, so the per-interface state machine for receiving E-IP Join/ RPT of G, so the per-interface state machine for receiving E-IP Join/
Prune(S,G,rpt) messages should still take effect. Prune(S,G,rpt) messages should still take effect.
6.6. Process and forward multicast data 6.6. SPT Switchover
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 such
outgoing interface(s), then forward the data to other outgoing
interfaces without encapsulation/decapsulation.
When a downstream AFBR that has already switched over to SPT of S
receives an encapsulated multicast data packet of (S,G) along the
RPT, it should silently drop this packet.
6.7. SPT switchover
After a new AFBR expresses its interest in receiving traffic destined 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 for a multicast group, it will receive all the data from the RPT at
first. At this time, every downstream AFBR will receive multicast first. At this time, every downstream AFBR will receive multicast
data from any source from this RPT, in spit of whether they have data from any source from this RPT, in spit of whether they have
switched over to SPT of some source(s) or not. switched over to SPT of some source(s) or not.
To minimize this redundancy, it's recommended that every AFBR's To minimize this redundancy, it's recommended that every AFBR's
SwitchToSptDesired(S,G) function employs the "switch on first packet" SwitchToSptDesired(S,G) function employs the "switch on first packet"
policy. In this way, the delay of switchover to SPT is kept as policy. In this way, the delay of switchover to SPT is kept as
little as possible, and after the moment that every AFBR has 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 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. forwarded in the RPT of G, thus no more redundancy will be produced.
7. Other Considerations 6.7. Other PIM Message Types
7.1. Other PIM Message Types
Apart from Join or Prune, there exists other message types including Apart from Join or Prune, there exists other message types including
Register, Register-Stop, Hello and Assert. Register and Register- Register, Register-Stop, Hello and Assert. Register and Register-
Stop messages are sent by unicast, while Hello and Assert messages Stop messages are sent by unicast, while Hello and Assert messages
are only used between routers on a link to negotiate with each other. are only used between dierctly linked routers to negotiate with each
They don't need to be translated for forwarding, thus the process of other. It's no necessary to translate them for forwarding, thus the
these messages is out of scope for this document. process of these messages is out of scope for this document.
6.8. Other PIM States Maintenance
Apart from states mentioned above, there exists other states
including (*,*,RP) and I-IP (*,G') state. Since we treat I-IP core
as SSM-only, the maintenance of these states is out of scope for this
document.
7. Data Plane Functions of AFBR
7.1. 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 such
outgoing interface(s), then forward the data to other outgoing
interfaces without encapsulation/decapsulation.
When a downstream AFBR that has already switched over to SPT of S
receives an encapsulated multicast data packet of (S,G) along the
RPT, it should silently drop this packet.
7.2. Selecting a Tunneling Technology 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. It's recommended that all AFBRs use the same technology, at AFBRs. It's recommended that all AFBRs use the same technology,
otherwise some AFBRs may not be able to decapsulate encapsulated otherwise some AFBRs may not be able to decapsulate encapsulated
packets from other AFBRs that use a different tunneling technology. packets from other AFBRs that use a different tunneling technology.
7.3. TTL 7.3. TTL
The process of TTL depends on the tunneling technology, and is out of The processing of TTL depends on the tunneling technology, and is out
scope for this document. of scope for this document.
7.4. Fragmentation 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.
8. Security Considerations 8. Security Considerations
skipping to change at page 24, line 44 skipping to change at page 23, line 44
[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.
[10] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", [10] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs",
RFC 6513, February 2012. RFC 6513, February 2012.
10.2. Informative References 10.2. Informative References
[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,
"IPv6 Multicast Address Format With Embedded IPv4 Multicast "IPv6 Multicast Address With Embedded IPv4 Multicast Address",
Address", draft-ietf-mboned-64-multicast-address-format-02 draft-ietf-mboned-64-multicast-address-format-04 (work in
(work in progress), May 2012. progress), August 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
 End of changes. 26 change blocks. 
80 lines changed or deleted 92 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/