draft-ietf-softwire-mesh-multicast-16.txt   draft-ietf-softwire-mesh-multicast-17.txt 
Softwire WG M. Xu Softwire WG M. Xu
Internet-Draft Y. Cui Internet-Draft Y. Cui
Intended status: Standards Track J. Wu Intended status: Standards Track J. Wu
Expires: October 2, 2017 S. Yang Expires: February 4, 2018 S. Yang
Tsinghua University Tsinghua University
C. Metz C. Metz
G. Shepherd G. Shepherd
Cisco Systems Cisco Systems
March 31, 2017 August 3, 2017
Softwire Mesh Multicast Softwire Mesh Multicast
draft-ietf-softwire-mesh-multicast-16 draft-ietf-softwire-mesh-multicast-17
Abstract Abstract
The Internet needs to support IPv4 and IPv6 packets. Both address The Internet needs to support IPv4 and IPv6 packets. Both address
families and their related protocol suites support multicast of the families and their related protocol suites support multicast of the
single-source and any-source varieties. During IPv6 transition, single-source and any-source varieties. During IPv6 transition,
there will be scenarios where a backbone network running one IP 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), while
provide transit services to attached client networks running another the attached client networks running another IP address family
IP address family (referred to as external IP or E-IP). It is (referred to as external IP or E-IP). The I-IP backbone should offer
expected that the I-IP backbone will offer unicast and multicast both unicast and multicast transit services to the client E-IP
transit services to the client E-IP networks. networks.
Softwire Mesh is a solution providing E-IP unicast and multicast Softwire Mesh is a solution providing E-IP unicast and multicast
support across an I-IP backbone. This document describes the support across an I-IP backbone. This document describes the
mechanism for supporting Internet-style multicast across a set of mechanism for supporting Internet-style multicast across a set of
E-IP and I-IP networks supporting softwire mesh. We focus on IPv4- E-IP and I-IP networks supporting softwire mesh. We focus on IPv4-
over-IPv6 scenario in this document, due to lack of real-world use over-IPv6 scenario in this document, due to lack of real-world use
cases for IPv6-over-IPv4 scenario. cases for IPv6-over-IPv4 scenario.
Status of This Memo Status of This Memo
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 2, 2017. This Internet-Draft will expire on February 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 2, line 37 skipping to change at page 2, line 37
4. IPv4-over-IPv6 Mechanism . . . . . . . . . . . . . . . . . . 7 4. IPv4-over-IPv6 Mechanism . . . . . . . . . . . . . . . . . . 7
4.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . 8 4.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . 8
4.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 8 4.2. Group Address Mapping . . . . . . . . . . . . . . . . . . 8
4.3. Source Address Mapping . . . . . . . . . . . . . . . . . 9 4.3. Source Address Mapping . . . . . . . . . . . . . . . . . 9
4.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 10 4.4. Routing Mechanism . . . . . . . . . . . . . . . . . . . . 10
5. Control Plane Functions of AFBR . . . . . . . . . . . . . . . 11 5. Control Plane Functions of AFBR . . . . . . . . . . . . . . . 11
5.1. E-IP (*,G) State Maintenance . . . . . . . . . . . . . . 11 5.1. E-IP (*,G) State Maintenance . . . . . . . . . . . . . . 11
5.2. E-IP (S,G) State Maintenance . . . . . . . . . . . . . . 11 5.2. E-IP (S,G) State Maintenance . . . . . . . . . . . . . . 11
5.3. I-IP (S',G') State Maintenance . . . . . . . . . . . . . 11 5.3. I-IP (S',G') State Maintenance . . . . . . . . . . . . . 11
5.4. E-IP (S,G,rpt) State Maintenance . . . . . . . . . . . . 11 5.4. E-IP (S,G,rpt) State Maintenance . . . . . . . . . . . . 11
5.5. Inter-AFBR Signaling . . . . . . . . . . . . . . . . . . 11 5.5. Inter-AFBR Signaling . . . . . . . . . . . . . . . . . . 12
5.6. SPT Switchover . . . . . . . . . . . . . . . . . . . . . 14 5.6. SPT Switchover . . . . . . . . . . . . . . . . . . . . . 14
5.7. Other PIM Message Types . . . . . . . . . . . . . . . . . 14 5.7. Other PIM Message Types . . . . . . . . . . . . . . . . . 14
5.8. Other PIM States Maintenance . . . . . . . . . . . . . . 14 5.8. Other PIM States Maintenance . . . . . . . . . . . . . . 14
6. Data Plane Functions of the AFBR . . . . . . . . . . . . . . 14 6. Data Plane Functions of the AFBR . . . . . . . . . . . . . . 14
6.1. Process and Forward Multicast Data . . . . . . . . . . . 14 6.1. Process and Forward Multicast Data . . . . . . . . . . . 14
6.2. Selecting a Tunneling Technology . . . . . . . . . . . . 15 6.2. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 15
7. Packet Format and Translation . . . . . . . . . . . . . . . . 15 7. Packet Format and Translation . . . . . . . . . . . . . . . . 15
8. Softwire Mesh Multicast Encapsulation . . . . . . . . . . . . 16 8. Softwire Mesh Multicast Encapsulation . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 related protocol suites support multicast of the families and their related protocol suites support multicast of the
single-source and any-source varieties. During IPv6 transition, single-source and any-source varieties. During IPv6 transition,
there will be scenarios where a backbone network running one IP 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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
The Internet needs to support IPv4 and IPv6 packets. Both address The Internet needs to support IPv4 and IPv6 packets. Both address
families and their related protocol suites support multicast of the families and their related protocol suites support multicast of the
single-source and any-source varieties. During IPv6 transition, single-source and any-source varieties. During IPv6 transition,
there will be scenarios where a backbone network running one IP 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).
One solution is to leverage the multicast functions inherent in the One solution is to leverage the multicast functions inherent in the
I-IP backbone, to efficiently forward client E-IP multicast packets I-IP backbone, to efficiently forward client E-IP multicast packets
inside an I-IP core tree, which is rooted at one or more ingress AFBR inside an I-IP core tree, which is rooted at one or more ingress
nodes and branches out to one or more egress AFBR leaf nodes. Address Family Border Routers (AFBR) and branches out to one or more
egress Address Family Border Routers (AFBR).
[RFC4925] outlines the requirements for the softwires mesh scenario [RFC4925] outlines the requirements for the softwires mesh scenario
and includes support for multicast traffic. It is likely that client and includes support for multicast traffic. It is likely 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 requires E-IP networks connected to an I-IP backbone network. This requires
the client E-IP source-rooted or shared tree to traverse the I-IP the client E-IP source-rooted or shared tree to traverse the I-IP
backbone network. backbone network.
One method of accomplishing this is to re-use the multicast VPN One method of accomplishing this is to re-use the multicast VPN
approach outlined in [RFC6513]. MVPN-like schemes can support the approach outlined in [RFC6513]. MVPN-like schemes can support the
skipping to change at page 4, line 8 skipping to change at page 4, line 8
Internet-style multicast is somewhat different in that the trees are Internet-style multicast is somewhat different in that the trees are
source-rooted and relatively sparse. The need for multicast source-rooted and relatively sparse. The need for multicast
aggregation at the edge (where many customer multicast trees are aggregation at the edge (where many customer multicast trees are
mapped into one or more backbone multicast trees) does not exist and mapped into one or more backbone multicast trees) does not exist and
to date has not been identified. Thus the need for a basic or closer to date has not been identified. Thus the need for a basic or closer
alignment with E-IP and I-IP multicast procedures emerges. alignment with E-IP and I-IP multicast procedures emerges.
[RFC5565] describes the "Softwire Mesh Framework". This document [RFC5565] describes the "Softwire Mesh Framework". This document
provides a more detailed description of how one-to-one mapping provides a more detailed description of how one-to-one mapping
schemes ([RFC5565], Section 11.1) for IPv4 over IPv6 can be achieved. schemes ([RFC5565], Section 11.1) for IPv4 over IPv6 can be achieved.
We focus on IPv4-over-IPv6 scenario in this document, due to lack of
real-world use cases for IPv6-over-IPv4 scenario.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
Figure 1 shows an example of how a softwire mesh network can support Figure 1 shows an example of how a softwire mesh network can support
skipping to change at page 5, line 41 skipping to change at page 5, line 41
Terminology used in this document: Terminology used in this document:
o Address Family Border Router (AFBR) - A router interconnecting two o Address Family Border Router (AFBR) - A router interconnecting two
or more networks using different IP address families. In the context or more networks using different IP address families. In the context
of softwire mesh multicast, the AFBR runs E-IP and I-IP control of softwire mesh multicast, the AFBR runs E-IP and I-IP control
planes to maintain E-IP and I-IP multicast states respectively and planes to maintain E-IP and I-IP multicast states respectively and
performs the appropriate encapsulation/decapsulation of client E-IP performs the appropriate encapsulation/decapsulation of client E-IP
multicast packets for transport across the I-IP core. An AFBR will multicast packets for transport across the I-IP core. An AFBR will
act as a source and/or receiver in an I-IP multicast tree. act as a source and/or receiver in an I-IP multicast tree.
o Upstream AFBR: The AFBR router that is located on the upper reaches o Upstream AFBR: An AFBR router that is located on the upper reaches
of a multicast data flow. of a multicast data flow.
o Downstream AFBR: The AFBR router that is located on the lower o Downstream AFBR: An AFBR router that is located on the lower
reaches of a multicast data flow. reaches of a multicast data flow.
o I-IP (Internal IP): This refers to IP address family (i.e., either o I-IP (Internal IP): This refers to IP address family (i.e., either
IPv4 or IPv6) that is supported by the core (or backbone) network. IPv4 or IPv6) that is supported by the core (or backbone) network.
o E-IP (External IP): This refers to the IP address family (i.e. o E-IP (External IP): This refers to the IP address family (i.e.
either IPv4 or IPv6) that is supported by the client network(s) either IPv4 or IPv6) that is supported by the client network(s)
attached to the I-IP transit core. attached to the I-IP transit core.
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
skipping to change at page 6, line 33 skipping to change at page 6, line 33
IPv4-embedded IPv6 source address in IPv4-over-IPv6 scenario. IPv4-embedded IPv6 source address in IPv4-over-IPv6 scenario.
o mPrefix46: The /96 multicast IPv6 prefix for constructing an o mPrefix46: The /96 multicast IPv6 prefix for constructing an
IPv4-embedded IPv6 multicast address in IPv4-over-IPv6 scenario. IPv4-embedded IPv6 multicast address in IPv4-over-IPv6 scenario.
o Inter-AFBR signaling: A mechanism used by downstream AFBRs to send o Inter-AFBR signaling: A mechanism used by downstream AFBRs to send
PIM messages to the upstream AFBR. PIM messages to the upstream AFBR.
3. Scenarios of Interest 3. Scenarios of Interest
This document focus on IPv4-over-IPv6 scenario, however, the This document focus on IPv4-over-IPv6 scenario, the following diagram
following mechanism offers a reference for IPv6-over-IPv4 scenario if shows the scenario.
needed.
._._._._. ._._._._. ._._._._. ._._._._.
| IPv4 | | IPv4 | -------- | IPv4 | | IPv4 | --------
| Client | | Client |--|Source S| | Client | | Client |--|Source S|
| network | | network | -------- | network | | network | --------
._._._._. ._._._._. ._._._._. ._._._._.
| | | |
AFBR upstream AFBR AFBR upstream AFBR
| | | |
__+____________________+__ __+____________________+__
skipping to change at page 8, line 17 skipping to change at page 8, line 17
E-IPv4 networks. Through PIM messages, E-IPv4 hosts and routers have E-IPv4 networks. Through PIM messages, E-IPv4 hosts and routers have
discovered or learnt of (S,G) or (*,G) IPv4 addresses. Any I-IPv6 discovered or learnt of (S,G) or (*,G) IPv4 addresses. Any I-IPv6
multicast state instantiated in the core is referred to as (S',G') or multicast state instantiated in the core is referred to as (S',G') or
(*,G') and is certainly separated from E-IPv4 multicast state. (*,G') and is 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 the I-IP IPv6 address message with the latter being directed towards the I-IP IPv6 address
of the upstream AFBR. When the I-IPv6 PIM message arrives at the of the upstream AFBR. When the I-IPv6 PIM message arrives at the
upstream AFBR, it MUST be translated back into an E-IPv4 PIM message. upstream AFBR, it is translated back into an E-IPv4 PIM message. The
The result of these actions is the construction of E-IPv4 trees and a result of these actions is the construction of E-IPv4 trees and a
corresponding I-IP tree in the I-IP network. An example of the corresponding I-IP tree in the I-IP network. An example of the
packet format and traslation is provided in Section 8. packet format and traslation is provided in Section 8.
In this case, it is incumbent upon the AFBR routers to perform PIM In this case, it is incumbent upon the AFBR routers to perform PIM
message conversions in the control plane and IP group address message conversions in the control plane and IP group address
conversions or mappings in the data plane. The AFBRs perform an conversions or mappings in the data plane. The AFBRs perform an
algorithmic, one-to-one mapping of IPv4-to-IPv6. algorithmic, one-to-one mapping of IPv4-to-IPv6.
4.2. Group Address Mapping 4.2. Group Address Mapping
skipping to change at page 9, line 9 skipping to change at page 9, line 9
The mPrefix46 for SSM mode is also defined in Section 2 of [RFC8114]. The mPrefix46 for SSM mode is also defined in Section 2 of [RFC8114].
With this scheme, each IPv4 multicast address can be mapped into an With this scheme, each IPv4 multicast address can be mapped into an
IPv6 multicast address (with the assigned prefix), and each IPv6 IPv6 multicast address (with the assigned prefix), and each IPv6
multicast address with the assigned prefix can be mapped into an IPv4 multicast address with the assigned prefix can be mapped into an IPv4
multicast address. The group address translation algorithm can be multicast address. The group address translation algorithm can be
reffered in Section 5.2 of [RFC8114]. reffered in Section 5.2 of [RFC8114].
4.3. Source Address Mapping 4.3. Source Address Mapping
There are two kinds of multicast: ASM and SSM. Considering that I-IP There are two kinds of multicast: ASM and SSM. Considering that the
network and E-IP network may support different kinds of multicast, I-IP network and E-IP network may support different kinds of
the source address translation rules needed to support all possible multicast, the source address translation rules needed to support all
scenarios may become very complex. But since SSM can be implemented possible scenarios may become very complex. But since SSM can be
with a strict subset of the PIM-SM protocol mechanisms [RFC7761], we implemented with a strict subset of the PIM-SM protocol mechanisms
can treat the I-IP core as SSM-only to make it as simple as possible. [RFC7761], we can treat the I-IP core as SSM-only to make it as
There then remain only two scenarios to be discussed in detail: simple as possible. There then remain only two scenarios to be
discussed in detail:
o E-IP network supports SSM o E-IP network supports SSM
One possible way to make sure that the translated I-IPv6 PIM One possible way to make sure that the translated I-IPv6 PIM
message reaches upstream AFBR is to set S' to a virtual IPv6 message reaches upstream AFBR is to set S' to a virtual IPv6
address that leads to the upstream AFBR. Figure 5 is the address that leads to the upstream AFBR. Figure 5 is the
recommended address format based on [RFC6052]: recommended address format based on [RFC6052]:
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0-------------32--40--48--56--64--72--80--88--96-----------127| | 0-------------32--40--48--56--64--72--80--88--96-----------127|
skipping to change at page 11, line 50 skipping to change at page 12, line 8
5.4. E-IP (S,G,rpt) State Maintenance 5.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 operate as specified in I-IP upstream router, the AFBR MUST operate as specified in
Section 6.5 and Section 6.6. Section 6.5 and Section 6.6.
5.5. Inter-AFBR Signaling 5.5. Inter-AFBR Signaling
Assume that one downstream AFBR has joined a RPT of (*,G) and a SPT Assume that one downstream AFBR has joined a RPT of (*,G) and a SPT
of (S,G), and decide to perform a SPT switchover. According to of (S,G), and decide to perform an SPT switchover. According to
[RFC7761], it SHOULD propagate a Prune(S,G,rpt) message along with [RFC7761], it SHOULD propagate a Prune(S,G,rpt) message along with
the periodical Join(*,G) message upstream towards RP. However, the periodical Join(*,G) message upstream towards RP. However,
routers in the I-IP transit core do not process (S,G,rpt) messages routers in the I-IP transit core do not process (S,G,rpt) messages
since the I-IP transit core is treated as SSM-only. As a result, the since the I-IP transit core is treated as SSM-only. As a result, the
downstream AFBR is unable to prune S from this RPT, so it will downstream AFBR is unable to prune S from this RPT, so it will
receive two copies of the same data of (S,G). In order to solve this 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 problem, we introduce a new mechanism for downstream AFBRs to inform
upstream AFBRs of pruning any given S from an RPT. upstream AFBRs of pruning any given S from an RPT.
When a downstream AFBR wishes to propagate a (S,G,rpt) message When a downstream AFBR wishes to propagate a (S,G,rpt) message
skipping to change at page 12, line 28 skipping to change at page 12, line 34
the message as in the unicast scenario, and retrieve the original the message as in the unicast scenario, and retrieve the original
(S,G,rpt) message. The incoming interface of this message may be (S,G,rpt) message. The incoming interface of this message may be
different to the outgoing interface which propagates multicast data different to the outgoing interface which propagates multicast data
to the corresponding downstream AFBR, and there may be other to the corresponding downstream AFBR, and there may be other
downstream AFBRs that need to receive multicast data of (S,G) from downstream AFBRs that need to receive multicast data of (S,G) from
this incoming interface, so RP' SHOULD NOT simply process this this incoming interface, so RP' SHOULD NOT simply process this
message as specified in [RFC7761] on the incoming interface. message as specified in [RFC7761] on the incoming interface.
To solve this problem as simply as possible, we introduce an To solve this problem as simply as possible, we introduce an
"interface agent" to process all the encapsulated (S,G,rpt) messages "interface agent" to process all the encapsulated (S,G,rpt) messages
the upstream AFBR receives, and prune S from the RPT of group G when the upstream AFBR receives, and RP' SHOULD prune S from the RPT of
no downstream AFBR is subscribed to receive multicast data of (S,G) group G when no downstream AFBR is subscribed to receive multicast
along the RPT. In this way, we ensure that downstream AFBRs will not data of (S,G) along the RPT. In this way, we ensure that downstream
miss any multicast data that they need, at the cost of duplicated AFBRs will not miss any multicast data that they need, at the cost of
multicast data of (S,G) along the RPT received by SPT-switched-over duplicated multicast data of (S,G) along the RPT received by SPT-
downstream AFBRs, if at least one downstream AFBR exists that has not switched-over downstream AFBRs, if at least one downstream AFBR
yet sent Prune(S,G,rpt) messages to the upstream AFBR. The following exists that has not yet sent Prune(S,G,rpt) messages to the upstream
diagram shows an example of how an "interface agent" MAY be AFBR. The mechanism used to achieve this is left to the
implemented: implementation, the following diagram provides a possible solution
that "interface agent" MAY be implemented:
+----------------------------------------+ +----------------------------------------+
| | | |
| +-----------+----------+ | | +-----------+----------+ |
| | PIM-SM | UDP | | | | PIM-SM | UDP | |
| +-----------+----------+ | | +-----------+----------+ |
| ^ | | | ^ | |
| | | | | | | |
| | v | | | v |
| +----------------------+ | | +----------------------+ |
skipping to change at page 13, line 36 skipping to change at page 13, line 36
+--------|-----|----------|-----|--------+ +--------|-----|----------|-----|--------+
| v | v | v | v
Figure 7: Interface Agent Implementation Example Figure 7: Interface Agent Implementation Example
Figure 7 shows an example of interface agent implementation using UDP Figure 7 shows an example of interface agent implementation using UDP
encapsulation. The interface agent has two responsibilities: In the encapsulation. The interface agent has two responsibilities: In the
control plane, it SHOULD work as a real interface that has joined control plane, it SHOULD work as a real interface that has joined
(*,G), representing of all the I-IP interfaces which are outgoing (*,G), representing of all the I-IP interfaces which are outgoing
interfaces of the (*,G) state machine, and process the (S,G,rpt) interfaces of the (*,G) state machine, and process the (S,G,rpt)
messages received from all the I-IP interfaces. The interface agent messages received from all the I-IP interfaces.
maintains downstream (S,G,rpt) state machines of every downstream
AFBR, and submits Prune (S,G,rpt) messages to the PIM-SM module only The interface agent maintains downstream (S,G,rpt) state machines of
when every (S,G,rpt) state machine is at Prune(P) or PruneTmp(P') every downstream AFBR, and submits Prune (S,G,rpt) messages to the
state, which means that no downstream AFBR is subscribed to receive PIM-SM module only when every (S,G,rpt) state machine is at Prune(P)
multicast data of (S,G) along the RPT of G. Once a (S,G,rpt) state or PruneTmp(P') state, which means that no downstream AFBR is
machine changes to NoInfo(NI) state, which means that the subscribed to receive multicast data of (S,G) along the RPT of G.
corresponding downstream AFBR has switched to receive multicast data Once a (S,G,rpt) state machine changes to NoInfo(NI) state, which
of (S,G) along the RPT again, the interface agent SHOULD send a Join means that the corresponding downstream AFBR has switched to receive
(S,G,rpt) to the PIM-SM module immediately; In the data plane, upon multicast data of (S,G) along the RPT again, the interface agent
receiving a multicast data packet, the interface agent SHOULD SHOULD send a Join (S,G,rpt) to the PIM-SM module immediately.
encapsulate it at first, then propagate the encapsulated packet from
every I-IP interface. In the data plane, upon receiving a multicast data packet, the
interface agent SHOULD encapsulate it at first, then propagate the
encapsulated packet from every I-IP interface.
NOTICE: It is possible that an E-IP neighbor of RP' that has joined NOTICE: It is possible that an E-IP neighbor of RP' that has joined
the RPT of G, so the per-interface state machine for receiving E-IP the RPT of G, so the per-interface state machine for receiving E-IP
Join/Prune (S,G,rpt) messages SHOULD keep alive. Join/Prune (S,G,rpt) messages SHOULD keep alive.
5.6. SPT Switchover 5.6. SPT Switchover
After a new AFBR expresses its interest in receiving traffic destined After a new AFBR requests the receipt of traffic destined for a
for a multicast group, it will receive all the data from the RPT at multicast group, it will receive all the data from the RPT at first.
first. At this time, every downstream AFBR will receive multicast At this time, every downstream AFBR will receive multicast data from
data from any source from this RPT, in spite of whether they have any source from this RPT, in spite of whether they have switched over
switched over to an SPT of some source(s) or not. to an SPT of some source(s) or not.
To minimize this redundancy, it is recommended that every AFBR's To minimize this redundancy, it is 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 in switchover to SPT is kept as small policy. In this way, the delay in switchover to SPT is kept as small
as possible, and after the moment that every AFBR has performed the 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 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. the RPT of G, thus no more unnecessary duplication will be produced.
5.7. Other PIM Message Types 5.7. Other PIM Message Types
Apart from Join or Prune, other message types exist, including In addition to Join or Prune, other message types exist, 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 directly linked routers to negotiate with each are only used between directly linked routers to negotiate with each
other. It is not necessary to translate these for forwarding, thus other. It is not necessary to translate these for forwarding, thus
the processing of these messages is out of scope for this document. the processing of these messages is out of scope for this document.
5.8. Other PIM States Maintenance 5.8. Other PIM States Maintenance
Apart from states mentioned above, other states exist, including In addition to states mentioned above, other states exist, including
(*,*,RP) and I-IP (*,G') state. Since we treat the I-IP core as SSM- (*,*,RP) and I-IP (*,G') state. Since we treat the I-IP core as SSM-
only, the maintenance of these states is out of scope for this only, the maintenance of these states is out of scope for this
document. document.
6. Data Plane Functions of the AFBR 6. Data Plane Functions of the AFBR
6.1. Process and Forward Multicast Data 6.1. Process and Forward Multicast Data
On receiving multicast data from upstream routers, the AFBR checks On receiving multicast data from upstream routers, the AFBR checks
its forwarding table to find the IP address of each outgoing its forwarding table to find the IP address of each outgoing
interface. If there is at least one outgoing interface whose IP interface. If there is at least one outgoing interface whose IP
address family is different from the incoming interface, the AFBR address family is different from the incoming interface, the AFBR
MUST encapsulate/decapsulate this packet and forward it via the MUST encapsulate/decapsulate this packet and forward it via the
outgoing interface(s), then forward the data via other outgoing outgoing interface(s), then forward the data via other outgoing
interfaces without encapsulation/decapsulation. interfaces without encapsulation/decapsulation.
When a downstream AFBR that has already switched over to the SPT of S When a downstream AFBR that has already switched over to the SPT of S
receives an encapsulated multicast data packet of (S,G) along the receives an encapsulated multicast data packet of (S,G) along the
RPT, it SHOULD silently drop this packet. RPT, it SHOULD silently drop this packet.
6.2. Selecting a Tunneling Technology 6.2. TTL
Choosing tunneling technology depends on the policies configured on
AFBRs. It is REQUIRED that all AFBRs use the same technology,
otherwise some AFBRs SHALL not be able to decapsulate encapsulated
packets from other AFBRs that use a different tunneling technology.
6.3. TTL
Processing of TTL depends on the tunneling technology, and it is out Processing of TTL information in protocol headers depends on the
of scope of this document. tunneling technology, and it is out of scope of this document.
6.4. Fragmentation 6.3. Fragmentation
The encapsulation performed by an upstream AFBR will increase the The encapsulation performed by an upstream AFBR will increase the
size of packets. As a result, the outgoing I-IP link MTU may not size of packets. As a result, the outgoing I-IP link MTU may not
accommodate the larger packet size. As it is not always possible for accommodate the larger packet size. As it is not always possible for
core operators to increase the MTU of every link. Fragmentation core operators to increase the MTU of every link. Fragmentation
after encapsulation and reassembling of encapsulated packets MUST be after encapsulation and reassembling of encapsulated packets MUST be
supported by AFBRs [RFC5565]. supported by AFBRs [RFC5565].
7. Packet Format and Translation 7. Packet Format and Translation
 End of changes. 25 change blocks. 
73 lines changed or deleted 68 lines changed or added

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