< draft-ietf-l3vpn-2547bis-mcast-04.txt   draft-ietf-l3vpn-2547bis-mcast-05.txt >
Network Working Group Eric C. Rosen (Editor) Network Working Group Eric C. Rosen (Editor)
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Expiration Date: October 2007 Expiration Date: January 2008
Rahul Aggarwal (Editor) Rahul Aggarwal (Editor)
Juniper Networks Juniper Networks
April 2007 July 2007
Multicast in MPLS/BGP IP VPNs Multicast in MPLS/BGP IP VPNs
draft-ietf-l3vpn-2547bis-mcast-04.txt draft-ietf-l3vpn-2547bis-mcast-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Abstract Abstract
In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual
Private Network) to travel from one VPN site to another, special Private Network) to travel from one VPN site to another, special
protocols and procedures must be implemented by the VPN Service protocols and procedures must be implemented by the VPN Service
Provider. These protocols and procedures are specified in this Provider. These protocols and procedures are specified in this
document. document.
Table of Contents Table of Contents
1 Specification of requirements ...................... 4 1 Specification of requirements ......................... 5
2 Introduction ....................................... 4 2 Introduction .......................................... 5
2.1 Optimality vs Scalability .......................... 5 2.1 Optimality vs Scalability ............................. 5
2.1.1 Multicast Distribution Trees ....................... 7 2.1.1 Multicast Distribution Trees .......................... 7
2.1.2 Ingress Replication through Unicast Tunnels ........ 8 2.1.2 Ingress Replication through Unicast Tunnels ........... 8
2.2 Overview ........................................... 8 2.2 Overview .............................................. 8
2.2.1 Multicast Routing Adjacencies ...................... 8 2.2.1 Multicast Routing Adjacencies ......................... 8
2.2.2 MVPN Definition .................................... 8 2.2.2 MVPN Definition ....................................... 9
2.2.3 Auto-Discovery ..................................... 9 2.2.3 Auto-Discovery ........................................ 10
2.2.4 PE-PE Multicast Routing Information ................ 10 2.2.4 PE-PE Multicast Routing Information ................... 10
2.2.5 PE-PE Multicast Data Transmission .................. 11 2.2.5 PE-PE Multicast Data Transmission ..................... 11
2.2.6 Inter-AS MVPNs ..................................... 11 2.2.6 Inter-AS MVPNs ........................................ 12
2.2.7 Optional Deployment Models ......................... 12 2.2.7 Optionally Eliminating Shared Tree State .............. 12
3 Concepts and Framework ............................. 12 3 Concepts and Framework ................................ 12
3.1 PE-CE Multicast Routing ............................ 12 3.1 PE-CE Multicast Routing ............................... 12
3.2 P-Multicast Service Interfaces (PMSIs) ............. 13 3.2 P-Multicast Service Interfaces (PMSIs) ................ 14
3.2.1 Inclusive and Selective PMSIs ...................... 14 3.2.1 Inclusive and Selective PMSIs ......................... 15
3.2.2 Tunnels Instantiating PMSIs ........................ 15 3.2.2 Tunnels Instantiating PMSIs ........................... 16
3.3 Use of PMSIs for Carrying Multicast Data ........... 17 3.3 Use of PMSIs for Carrying Multicast Data .............. 18
3.3.1 MVPNs with Default MI-PMSIs ........................ 18 3.3.1 MVPNs with Default MI-PMSIs ........................... 18
3.3.2 When MI-PMSIs are Required ......................... 18 3.3.2 When MI-PMSIs are Required ............................ 19
3.3.3 MVPNs That Do Not Use MI-PMSIs ..................... 18 3.3.3 MVPNs That Do Not Use MI-PMSIs ........................ 19
4 BGP-Based Autodiscovery of MVPN Membership ......... 19 3.4 PE-PE Transmission of C-Multicast Routing ............. 19
5 PE-PE Transmission of C-Multicast Routing .......... 21 3.4.1 PIM Peering ........................................... 19
5.1 RPF Information for Unicast VPN-IP Routes .......... 21 3.4.1.1 Full Per-MVPN PIM Peering Across a MI-PMSI ............ 19
5.2 PIM Peering ........................................ 23 3.4.1.2 Lightweight PIM Peering Across a MI-PMSI .............. 20
5.2.1 Full Per-MVPN PIM Peering Across a MI-PMSI ......... 23 3.4.1.3 Unicasting of PIM C-Join/Prune Messages ............... 21
5.2.2 Lightweight PIM Peering Across a MI-PMSI ........... 23 3.4.2 Using BGP to Carry C-Multicast Routing ................ 21
5.2.3 Unicasting of PIM C-Join/Prune Messages ............ 24 4 BGP-Based Autodiscovery of MVPN Membership ............ 21
5.2.4 Details of Per-MVPN PIM Peering over MI-PMSI ....... 24 5 PE-PE Transmission of C-Multicast Routing ............. 24
5.2.4.1 PIM C-Instance Control Packets ..................... 25 5.1 Selecting the Upstream Multicast Hop (UMH) ............ 25
5.2.4.2 PIM C-instance RPF Determination ................... 25 5.1.1 Eligible Routes for UMH Selection ..................... 25
5.3 Use of BGP for Carrying C-Multicast Routing ........ 27 5.1.2 Information Carried by Eligible UMH Routes ............ 26
5.3.1 Sending BGP Updates ................................ 27 5.1.3 Selecting the Upstream PE ............................. 26
5.3.2 Explicit Tracking .................................. 29 5.1.4 Selecting the Upstream Multicast Hop .................. 28
5.3.3 Withdrawing BGP Updates ............................ 29 5.2 Details of Per-MVPN Full PIM Peering over MI-PMSI ..... 28
6 I-PMSI Instantiation ............................... 30 5.2.1 PIM C-Instance Control Packets ........................ 29
6.1 MVPN Membership and Egress PE Auto-Discovery ....... 30 5.2.2 PIM C-instance RPF Determination ...................... 29
6.1.1 Auto-Discovery for Ingress Replication ............. 30 5.2.3 Backwards Compatibility ............................... 30
6.1.2 Auto-Discovery for P-Multicast Trees ............... 31 5.3 Use of BGP for Carrying C-Multicast Routing ........... 30
6.2 C-Multicast Routing Information Exchange ........... 31 5.3.1 Sending BGP Updates ................................... 30
6.3 Aggregation ........................................ 31 5.3.2 Explicit Tracking ..................................... 32
6.3.1 Aggregate Tree Leaf Discovery ...................... 32 5.3.3 Withdrawing BGP Updates ............................... 32
6.3.2 Aggregation Methodology ............................ 32 6 I-PMSI Instantiation .................................. 32
6.3.3 Encapsulation of the Aggregate Tree ................ 33 6.1 MVPN Membership and Egress PE Auto-Discovery .......... 33
6.3.4 Demultiplexing C-multicast traffic ................. 33 6.1.1 Auto-Discovery for Ingress Replication ................ 33
6.4 Mapping Received Packets to MVPNs .................. 34 6.1.2 Auto-Discovery for P-Multicast Trees .................. 34
6.4.1 Unicast Tunnels .................................... 35 6.2 C-Multicast Routing Information Exchange .............. 34
6.4.2 Non-Aggregated P-Multicast Trees ................... 35 6.3 Aggregation ........................................... 34
6.4.3 Aggregate P-Multicast Trees ........................ 36 6.3.1 Aggregate Tree Leaf Discovery ......................... 35
6.5 I-PMSI Instantiation Using Ingress Replication ..... 36 6.3.2 Aggregation Methodology ............................... 35
6.6 Establishing P-Multicast Trees ..................... 37 6.3.3 Encapsulation of the Aggregate Tree ................... 36
6.7 RSVP-TE P2MP LSPs .................................. 38 6.3.4 Demultiplexing C-multicast traffic .................... 36
6.7.1 P2MP TE LSP Tunnel - MVPN Mapping .................. 38 6.4 Mapping Received Packets to MVPNs ..................... 37
6.7.2 Demultiplexing C-Multicast Data Packets ............ 39 6.4.1 Unicast Tunnels ....................................... 38
7 Optimizing Multicast Distribution via S-PMSIs ...... 39 6.4.2 Non-Aggregated P-Multicast Trees ...................... 38
7.1 S-PMSI Instantiation Using Ingress Replication ..... 40 6.4.3 Aggregate P-Multicast Trees ........................... 39
7.2 Protocol for Switching to S-PMSIs .................. 41 6.5 I-PMSI Instantiation Using Ingress Replication ........ 39
7.2.1 A UDP-based Protocol for Switching to S-PMSIs ...... 41 6.6 Establishing P-Multicast Trees ........................ 40
7.2.1.1 Binding a Stream to an S-PMSI ...................... 41 6.7 RSVP-TE P2MP LSPs ..................................... 41
7.2.1.2 Packet Formats and Constants ....................... 42 6.7.1 P2MP TE LSP Tunnel - MVPN Mapping ..................... 41
7.2.2 A BGP-based Protocol for Switching to S-PMSIs ...... 44 6.7.2 Demultiplexing C-Multicast Data Packets ............... 42
7.2.2.1 Advertising C-(S, G) Binding to a S-PMSI using BGP . 44 7 Optimizing Multicast Distribution via S-PMSIs ......... 42
7.2.2.2 Explicit Tracking .................................. 46 7.1 S-PMSI Instantiation Using Ingress Replication ........ 43
7.2.2.3 Switching to S-PMSI ................................ 46 7.2 Protocol for Switching to S-PMSIs ..................... 44
7.3 Aggregation ........................................ 47 7.2.1 A UDP-based Protocol for Switching to S-PMSIs ......... 44
7.4 Instantiating the S-PMSI with a PIM Tree ........... 47 7.2.1.1 Binding a Stream to an S-PMSI ......................... 44
7.5 Instantiating S-PMSIs using RSVP-TE P2MP Tunnels ... 48 7.2.1.2 Packet Formats and Constants .......................... 45
8 Inter-AS Procedures ................................ 48 7.2.2 A BGP-based Protocol for Switching to S-PMSIs ......... 47
8.1 Non-Segmented Inter-AS Tunnels ..................... 49 7.2.2.1 Advertising C-(S, G) Binding to a S-PMSI using BGP .... 47
8.1.1 Inter-AS MVPN Auto-Discovery ....................... 49 7.2.2.2 Explicit Tracking ..................................... 49
8.1.2 Inter-AS MVPN Routing Information Exchange ......... 49 7.2.2.3 Switching to S-PMSI ................................... 49
8.1.3 Inter-AS I-PMSI .................................... 50 7.3 Aggregation ........................................... 50
8.1.4 Inter-AS S-PMSI .................................... 51 7.4 Instantiating the S-PMSI with a PIM Tree .............. 50
8.2 Segmented Inter-AS Tunnels ......................... 51 7.5 Instantiating S-PMSIs using RSVP-TE P2MP Tunnels ...... 51
8.2.1 Inter-AS MVPN Auto-Discovery Routes ................ 51 8 Inter-AS Procedures ................................... 51
8.2.1.1 Originating Inter-AS MVPN A-D Information .......... 52 8.1 Non-Segmented Inter-AS Tunnels ........................ 52
8.2.1.2 Propagating Inter-AS MVPN A-D Information .......... 53 8.1.1 Inter-AS MVPN Auto-Discovery .......................... 52
8.2.1.2.1 Inter-AS Auto-Discovery Route received via EBGP .... 53 8.1.2 Inter-AS MVPN Routing Information Exchange ............ 52
8.2.1.2.2 Leaf Auto-Discovery Route received via EBGP ........ 54 8.1.3 Inter-AS P-Tunnels .................................... 53
8.2.1.2.3 Inter-AS Auto-Discovery Route received via IBGP .... 55 8.1.4 PIM-Based Inter-AS P-Multicast Trees .................. 53
8.2.2 Inter-AS MVPN Routing Information Exchange ......... 56 8.2 Segmented Inter-AS Tunnels ............................ 54
8.2.3 Inter-AS I-PMSI .................................... 56 8.2.1 Inter-AS MVPN Auto-Discovery Routes ................... 54
8.2.3.1 Support for Unicast VPN Inter-AS Methods ........... 57 8.2.1.1 Originating Inter-AS MVPN A-D Information ............. 55
8.2.4 Inter-AS S-PMSI .................................... 57 8.2.1.2 Propagating Inter-AS MVPN A-D Information ............. 56
9 Duplicate Packet Detection and Single Forwarder PE . 58 8.2.1.2.1 Inter-AS Auto-Discovery Route received via EBGP ....... 56
10 Deployment Models .................................. 62 8.2.1.2.2 Leaf Auto-Discovery Route received via EBGP ........... 57
10.1 Co-locating C-RPs on a PE .......................... 62 8.2.1.2.3 Inter-AS Auto-Discovery Route received via IBGP ....... 57
10.1.1 Initial Configuration .............................. 62 8.2.2 Inter-AS MVPN Routing Information Exchange ............ 59
10.1.2 Anycast RP Based on Propagating Active Sources ..... 62 8.2.3 Inter-AS I-PMSI ....................................... 59
10.1.2.1 Receiver(s) Within a Site .......................... 63 8.2.3.1 Support for Unicast VPN Inter-AS Methods .............. 60
10.1.2.2 Source Within a Site ............................... 63 8.2.4 Inter-AS S-PMSI ....................................... 60
10.1.2.3 Receiver Switching from Shared to Source Tree ...... 63 9 Duplicate Packet Detection and Single Forwarder PE .... 61
10.2 Using MSDP between a PE and a Local C-RP ........... 64 9.1 Multihomed C-S or C-RP ................................ 62
11 Encapsulations ..................................... 65 9.1.1 Single forwarder PE selection ......................... 63
11.1 Encapsulations for Single PMSI per Tunnel .......... 65 9.2 Switching from the C-RP tree to C-S tree .............. 64
11.1.1 Encapsulation in GRE ............................... 65 10 Eliminating PE-PE Distribution of (C-*,C-G) State ..... 65
11.1.2 Encapsulation in IP ................................ 66 10.1 Co-locating C-RPs on a PE ............................. 66
11.1.3 Encapsulation in MPLS .............................. 67 10.1.1 Initial Configuration ................................. 66
11.2 Encapsulations for Multiple PMSIs per Tunnel ....... 68 10.1.2 Anycast RP Based on Propagating Active Sources ........ 67
11.2.1 Encapsulation in GRE ............................... 68 10.1.2.1 Receiver(s) Within a Site ............................. 67
11.2.2 Encapsulation in IP ................................ 68 10.1.2.2 Source Within a Site .................................. 67
11.3 Encapsulations for Unicasting PIM Control Messages . 68 10.1.2.3 Receiver Switching from Shared to Source Tree ......... 68
11.4 General Considerations for IP and GRE Encaps ....... 69 10.2 Using MSDP between a PE and a Local C-RP .............. 68
11.4.1 MTU ................................................ 69 11 Encapsulations ........................................ 69
11.4.2 TTL ................................................ 69 11.1 Encapsulations for Single PMSI per Tunnel ............. 69
11.4.3 Differentiated Services ............................ 70 11.1.1 Encapsulation in GRE .................................. 69
11.4.4 Avoiding Conflict with Internet Multicast .......... 70 11.1.2 Encapsulation in IP ................................... 71
12 Security Considerations ............................ 70 11.1.3 Encapsulation in MPLS ................................. 71
13 IANA Considerations ................................ 70 11.2 Encapsulations for Multiple PMSIs per Tunnel .......... 72
14 Other Authors ...................................... 70 11.2.1 Encapsulation in GRE .................................. 72
15 Other Contributors ................................. 70 11.2.2 Encapsulation in IP ................................... 72
16 Authors' Addresses ................................. 71 11.3 Encapsulations Identifying a Distinguished PE ......... 73
17 Normative References ............................... 72 11.3.1 For MP2MP LSP P-tunnels ............................... 73
18 Informative References ............................. 73 11.3.2 For Support of PIM-BIDIR C-Groups ..................... 73
19 Full Copyright Statement ........................... 74 11.4 Encapsulations for Unicasting PIM Control Messages .... 74
20 Intellectual Property .............................. 74 11.5 General Considerations for IP and GRE Encaps .......... 74
11.5.1 MTU ................................................... 74
11.5.2 TTL ................................................... 75
11.5.3 Differentiated Services ............................... 75
11.5.4 Avoiding Conflict with Internet Multicast ............. 75
12 Support for PIM-BIDIR C-Groups ........................ 76
12.1 The VPN Backbone Becomes the RPL ...................... 77
12.1.1 Control Plane ......................................... 77
12.1.2 Data Plane ............................................ 78
12.2 Partitioned Sets of PEs ............................... 78
12.2.1 Partitions ............................................ 78
12.2.2 Using PE Labels ....................................... 79
12.2.3 Mesh of MP2MP P-Tunnels ............................... 80
13 Security Considerations ............................... 80
14 IANA Considerations ................................... 80
15 Other Authors ......................................... 80
16 Other Contributors .................................... 80
17 Authors' Addresses .................................... 80
18 Normative References .................................. 82
19 Informative References ................................ 83
20 Full Copyright Statement .............................. 83
21 Intellectual Property ................................. 84
1. Specification of requirements 1. Specification of requirements
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. Introduction 2. Introduction
[RFC4364] specifies the set of procedures which a Service Provider [RFC4364] specifies the set of procedures which a Service Provider
(SP) must implement in order to provide a particular kind of VPN (SP) must implement in order to provide a particular kind of VPN
service ("BGP/MPLS IP VPN") for its customers. The service described service ("BGP/MPLS IP VPN") for its customers. The service described
therein allows IP unicast packets to travel from one customer site to therein allows IP unicast packets to travel from one customer site to
another, but it does not provide a way for IP multicast traffic to another, but it does not provide a way for IP multicast traffic to
travel from one customer site to another. travel from one customer site to another.
This document extends the service defined in [RFC4364] so that it This document extends the service defined in [RFC4364] so that it
also includes the capability of handling IP multicast traffic. This also includes the capability of handling IP multicast traffic. This
requires a number of different protocols to work together. The requires a number of different protocols to work together. The
document provides a framework describing how the various protocols document provides a framework describing how the various protocols
fit together, and also provides detailed specification of some of the fit together, and also provides detailed specification of some of the
protocols. The detailed specification of some of the other protocols. The detailed specification of some of the other protocols
protocols is found in pre-existing documents or in companion is found in pre-existing documents or in companion documents.
documents.
2.1. Optimality vs Scalability 2.1. Optimality vs Scalability
In a "BGP/MPLS IP VPN" [RFC4364], unicast routing of VPN packets is In a "BGP/MPLS IP VPN" [RFC4364], unicast routing of VPN packets is
achieved without the need to keep any per-VPN state in the core of achieved without the need to keep any per-VPN state in the core of
the SP's network (the "P routers"). Routing information from a the SP's network (the "P routers"). Routing information from a
particular VPN is maintained only by the Provider Edge routers (the particular VPN is maintained only by the Provider Edge routers (the
"PE routers", or "PEs") that attach directly to sites of that VPN. "PE routers", or "PEs") that attach directly to sites of that VPN.
Customer data travels through the P routers in tunnels from one PE to Customer data travels through the P routers in tunnels from one PE to
another (usually MPLS Label Switched Paths, LSPs), so to support the another (usually MPLS Label Switched Paths, LSPs), so to support the
skipping to change at page 5, line 22 skipping to change at page 6, line 4
2.1. Optimality vs Scalability 2.1. Optimality vs Scalability
In a "BGP/MPLS IP VPN" [RFC4364], unicast routing of VPN packets is In a "BGP/MPLS IP VPN" [RFC4364], unicast routing of VPN packets is
achieved without the need to keep any per-VPN state in the core of achieved without the need to keep any per-VPN state in the core of
the SP's network (the "P routers"). Routing information from a the SP's network (the "P routers"). Routing information from a
particular VPN is maintained only by the Provider Edge routers (the particular VPN is maintained only by the Provider Edge routers (the
"PE routers", or "PEs") that attach directly to sites of that VPN. "PE routers", or "PEs") that attach directly to sites of that VPN.
Customer data travels through the P routers in tunnels from one PE to Customer data travels through the P routers in tunnels from one PE to
another (usually MPLS Label Switched Paths, LSPs), so to support the another (usually MPLS Label Switched Paths, LSPs), so to support the
VPN service the P routers only need to have routes to the PE routers. VPN service the P routers only need to have routes to the PE routers.
The PE-to-PE routing is optimal, but the amount of associated state The PE-to-PE routing is optimal, but the amount of associated state
in the P routers depends only on the number of PEs, not on the number in the P routers depends only on the number of PEs, not on the number
of VPNs. of VPNs.
However, in order to provide optimal multicast routing for a However, in order to provide optimal multicast routing for a
particular multicast flow, the P routers through which that flow particular multicast flow, the P routers through which that flow
travels have to hold state which is specific to that flow. travels have to hold state which is specific to that flow.
Scalability would be poor if the amount of state in the P routers Scalability would be poor if the amount of state in the P routers
were proportional to the number of multicast flows in the VPNs. were proportional to the number of multicast flows in the VPNs.
Therefore, when supporting multicast service for a BGP/MPLS IP VPN, Therefore, when supporting multicast service for a BGP/MPLS IP VPN,
the optimality of the multicast routing must be traded off against the optimality of the multicast routing must be traded off against
the scalability of the P routers. We explain this below in more the scalability of the P routers. We explain this below in more
detail. detail.
If a particular VPN is transmitting "native" multicast traffic over If a particular VPN is transmitting "native" multicast traffic over
the backbone, we refer to it as an "MVPN". By "native" multicast the backbone, we refer to it as an "MVPN". By "native" multicast
traffic, we mean packets that a CE sends to a PE, such that the IP traffic, we mean packets that a CE sends to a PE, such that the IP
destination address of the packets is a multicast group address, or destination address of the packets is a multicast group address, or
the packets are multicast control packets addressed to the PE router the packets are multicast control packets addressed to the PE router
itself, or the packets are IP multicast data packets encapsulated in itself, or the packets are IP multicast data packets encapsulated in
MPLS. MPLS.
We say that the backbone multicast routing for a particular multicast We say that the backbone multicast routing for a particular multicast
group in a particular VPN is "optimal" if and only if all of the group in a particular VPN is "optimal" if and only if all of the
following conditions hold: following conditions hold:
skipping to change at page 9, line 5 skipping to change at page 9, line 24
To support the "Carrier's Carrier" model of [RFC4364], mLDP or BGP To support the "Carrier's Carrier" model of [RFC4364], mLDP or BGP
can be used on the PE-CE interface. This will be described in can be used on the PE-CE interface. This will be described in
subsequent versions of this document. subsequent versions of this document.
2.2.2. MVPN Definition 2.2.2. MVPN Definition
An MVPN is defined by two sets of sites, Sender Sites set and An MVPN is defined by two sets of sites, Sender Sites set and
Receiver Sites set, with the following properties: Receiver Sites set, with the following properties:
- Hosts within the Sender Sites set could originate multicast - Hosts within the Sender Sites set could originate multicast
traffic for receivers in the Receiver Sites set. traffic for receivers in the Receiver Sites set.
- Receivers not in the Receiver Sites set should not be able to - Receivers not in the Receiver Sites set should not be able to
receive this traffic. receive this traffic.
- Hosts within the Receiver Sites set could receive multicast - Hosts within the Receiver Sites set could receive multicast
traffic originated by any host in the Sender Sites set. traffic originated by any host in the Sender Sites set.
- Hosts within the Receiver Sites set should not be able to - Hosts within the Receiver Sites set should not be able to receive
receive multicast traffic originated by any host that is not in multicast traffic originated by any host that is not in the
the Sender Sites set. Sender Sites set.
A site could be both in the Sender Sites set and Receiver Sites set, A site could be both in the Sender Sites set and Receiver Sites set,
which implies that hosts within such a site could both originate and which implies that hosts within such a site could both originate and
receive multicast traffic. An extreme case is when the Sender Sites receive multicast traffic. An extreme case is when the Sender Sites
set is the same as the Receiver Sites set, in which case all sites set is the same as the Receiver Sites set, in which case all sites
could originate and receive multicast traffic from each other. could originate and receive multicast traffic from each other.
Sites within a given MVPN may be either within the same, or in Sites within a given MVPN may be either within the same, or in
different organizations, which implies that an MVPN can be either an different organizations, which implies that an MVPN can be either an
Intranet or an Extranet. Intranet or an Extranet.
skipping to change at page 10, line 20 skipping to change at page 10, line 39
particular MVPN if it contains a VRF (Virtual Routing and particular MVPN if it contains a VRF (Virtual Routing and
Forwarding table, see [RFC4364]) which is configured to contain Forwarding table, see [RFC4364]) which is configured to contain
the multicast routing information of that MVPN. This auto- the multicast routing information of that MVPN. This auto-
discovery option does not make any assumptions about the methods discovery option does not make any assumptions about the methods
used for transmitting MVPN multicast data packets through the used for transmitting MVPN multicast data packets through the
backbone. backbone.
- If it is known that the multicast data packets of a particular - If it is known that the multicast data packets of a particular
MVPN are to be transmitted (at least, by default) through a non- MVPN are to be transmitted (at least, by default) through a non-
aggregated Inclusive Tree which is to be set up by PIM-SM or aggregated Inclusive Tree which is to be set up by PIM-SM or
PIM-Bidir, and if the PEs attaching to that MVPN are configured BIDIR-PIM, and if the PEs attaching to that MVPN are configured
with the group address corresponding to that tree, then the PEs with the group address corresponding to that tree, then the PEs
can auto-discover each other simply by joining the tree and then can auto-discover each other simply by joining the tree and then
multicasting PIM Hellos over the tree. multicasting PIM Hellos over the tree.
2.2.4. PE-PE Multicast Routing Information 2.2.4. PE-PE Multicast Routing Information
The BGP/MPLS IP VPN [RFC4364] specification requires a PE to maintain The BGP/MPLS IP VPN [RFC4364] specification requires a PE to maintain
at most one BGP peering with every other PE in the network. This at most one BGP peering with every other PE in the network. This
peering is used to exchange VPN routing information. The use of Route peering is used to exchange VPN routing information. The use of Route
Reflectors further reduces the number of BGP adjacencies maintained Reflectors further reduces the number of BGP adjacencies maintained
skipping to change at page 11, line 12 skipping to change at page 11, line 27
use of BGP, providing reliable transport. Another option is the use use of BGP, providing reliable transport. Another option is the use
of the currently existing, "soft state" PIM standard [PIM-SM]. of the currently existing, "soft state" PIM standard [PIM-SM].
2.2.5. PE-PE Multicast Data Transmission 2.2.5. PE-PE Multicast Data Transmission
Like [RFC4364], this document decouples the procedures for exchanging Like [RFC4364], this document decouples the procedures for exchanging
routing information from the procedures for transmitting data routing information from the procedures for transmitting data
traffic. Hence a variety of transport technologies may be used in the traffic. Hence a variety of transport technologies may be used in the
backbone. For inclusive trees, these transport technologies include backbone. For inclusive trees, these transport technologies include
unicast PE-PE tunnels (using MPLS or IP/GRE encapsulation), multicast unicast PE-PE tunnels (using MPLS or IP/GRE encapsulation), multicast
distribution trees created by PIM-SSM, PIM-SM, or PIM-Bidir (using distribution trees created by PIM-SSM, PIM-SM, or BIDIR-PIM (using
IP/GRE encapsulation), point-to-multipoint LSPs created by RSVP-TE or IP/GRE encapsulation), point-to-multipoint LSPs created by RSVP-TE or
mLDP, and multipoint-to-multipoint LSPs created by mLDP. (However, mLDP, and multipoint-to-multipoint LSPs created by mLDP. (However,
techniques for aggregating the traffic of multiple MVPNs onto a techniques for aggregating the traffic of multiple MVPNs onto a
single multipoint-to-multipoint LSP or onto a single bidirectional single multipoint-to-multipoint LSP or onto a single bidirectional
multicast distribution tree are for further study.) For selective multicast distribution tree are for further study.) For selective
trees, only unicast PE-PE tunnels (using MPLS or IP/GRE trees, only unicast PE-PE tunnels (using MPLS or IP/GRE
encapsulation) and unidirectional single-source trees are supported, encapsulation) and unidirectional single-source trees are supported,
and the supported tree creation protocols are PIM-SSM (using IP/GRE and the supported tree creation protocols are PIM-SSM (using IP/GRE
encapsulation), RSVP-TE, and mLDP. encapsulation), RSVP-TE, and mLDP.
skipping to change at page 11, line 46 skipping to change at page 12, line 14
supporting the various SP multicast transport options. supporting the various SP multicast transport options.
This document assumes that when SP multicast trees are used, traffic This document assumes that when SP multicast trees are used, traffic
for a particular multicast group is transmitted by a particular PE on for a particular multicast group is transmitted by a particular PE on
only one SP multicast tree. The use of multiple SP multicast trees only one SP multicast tree. The use of multiple SP multicast trees
for transmitting traffic belonging to a particular multicast group is for transmitting traffic belonging to a particular multicast group is
for further study. for further study.
2.2.6. Inter-AS MVPNs 2.2.6. Inter-AS MVPNs
[RFC4364] describes different options for supporting Inter-AS [RFC4364] describes different options for supporting BGP/MPLS IP
BGP/MPLS unicast VPNs. This document describes how Inter-AS MVPNs can unicast VPNs whose provider backbones contain more than one
Autonomous System (AS). These are know as Inter-AS VPNs. In an
Inter-AS VPN, the ASes may belong to the same provider or to
different providers. This document describes how Inter-AS MVPNs can
be supported for each of the unicast BGP/MPLS VPN Inter-AS options. be supported for each of the unicast BGP/MPLS VPN Inter-AS options.
This document also specifies a model where Inter-AS MVPN service can This document also specifies a model where Inter-AS MVPN service can
be offered without requiring a single SP multicast tree to span be offered without requiring a single SP multicast tree to span
multiple ASes. In this model, an inter-AS multicast tree consists of multiple ASes. In this model, an inter-AS multicast tree consists of
a number of "segments", one per AS, which are stitched together at AS a number of "segments", one per AS, which are stitched together at AS
boundary points. These are known as "segmented inter-AS trees". Each boundary points. These are known as "segmented inter-AS trees". Each
segment of a segmented inter-AS tree may use a different multicast segment of a segmented inter-AS tree may use a different multicast
transport technology. transport technology.
It is also possible to support Inter-AS MVPNs with non-segmented It is also possible to support Inter-AS MVPNs with non-segmented
source trees that extend across AS boundaries. source trees that extend across AS boundaries.
2.2.7. Optional Deployment Models 2.2.7. Optionally Eliminating Shared Tree State
The document also discusses an optional MVPN deployment model in The document also discusses some options and protocol extensions
which PEs take on all or part of the role of a PIM RP (Rendezvous which can be used to eliminate the need for the PE routers to
Point). The necessary protocol extensions to support this are distribute to each other the (*, G) and (*, G, RPT-bit) states when
defined. there are PIM Sparse Mode multicast groups in the VPNs.
3. Concepts and Framework 3. Concepts and Framework
3.1. PE-CE Multicast Routing 3.1. PE-CE Multicast Routing
Support of multicast in BGP/MPLS IP VPNs is modeled closely after Support of multicast in BGP/MPLS IP VPNs is modeled closely after
support of unicast in BGP/MPLS IP VPNs. That is, a multicast routing support of unicast in BGP/MPLS IP VPNs. That is, a multicast routing
protocol will be run on the PE-CE interfaces, such that PE and CE are protocol will be run on the PE-CE interfaces, such that PE and CE are
multicast routing adjacencies on that interface. CEs at different multicast routing adjacencies on that interface. CEs at different
sites do not become multicast routing adjacencies of each other. sites do not become multicast routing adjacencies of each other.
skipping to change at page 12, line 39 skipping to change at page 13, line 13
If a PE attaches to n VPNs for which multicast support is provided If a PE attaches to n VPNs for which multicast support is provided
(i.e., to n "MVPNs"), the PE will run n independent instances of a (i.e., to n "MVPNs"), the PE will run n independent instances of a
multicast routing protocol. We will refer to these multicast routing multicast routing protocol. We will refer to these multicast routing
instances as "VPN-specific multicast routing instances", or more instances as "VPN-specific multicast routing instances", or more
briefly as "multicast C-instances". The notion of a "VRF" ("Virtual briefly as "multicast C-instances". The notion of a "VRF" ("Virtual
Routing and Forwarding Table"), defined in [RFC4364], is extended to Routing and Forwarding Table"), defined in [RFC4364], is extended to
include multicast routing entries as well as unicast routing entries. include multicast routing entries as well as unicast routing entries.
Each multicast routing entry is thus associated with a particular Each multicast routing entry is thus associated with a particular
VRF. VRF.
Whether a particular VRF belongs to an MVPN or not is determined by Whether a particular VRF belongs to an MVPN or not is determined by
configuration. configuration.
In this document, we will not attempt to provide support for every In this document, we will not attempt to provide support for every
possible multicast routing protocol that could possibly run on the possible multicast routing protocol that could possibly run on the
PE-CE link. Rather, we consider multicast C-instances only for the PE-CE link. Rather, we consider multicast C-instances only for the
following multicast routing protocols: following multicast routing protocols:
- PIM Sparse Mode (PIM-SM) - PIM Sparse Mode (PIM-SM)
- PIM Single Source Mode (PIM-SSM) - PIM Single Source Mode (PIM-SSM)
- PIM Bidirectional Mode (PIM-Bidir) - PIM Bidirectional Mode (BIDIR-PIM)
- PIM Dense Mode (PIM-DM) - PIM Dense Mode (PIM-DM)
In order to support the "Carrier's Carrier" model of [RFC4364], mLDP In order to support the "Carrier's Carrier" model of [RFC4364], mLDP
or BGP will also be supported on the PE-CE interface; however, this or BGP will also be supported on the PE-CE interface; however, this
is not described in this revision. is not described in this revision.
As the document only supports PIM-based C-instances, we will As the document only supports PIM-based C-instances, we will
generally use the term "PIM C-instances" to refer to the multicast generally use the term "PIM C-instances" to refer to the multicast C-
C-instances. instances.
A PE router may also be running a "provider-wide" instance of PIM, (a A PE router may also be running a "provider-wide" instance of PIM, (a
"PIM P-instance"), in which it has a PIM adjacency with, e.g., each "PIM P-instance"), in which it has a PIM adjacency with, e.g., each
of its IGP neighbors (i.e., with P routers), but NOT with any CE of its IGP neighbors (i.e., with P routers), but NOT with any CE
routers, and not with other PE routers (unless another PE router routers, and not with other PE routers (unless another PE router
happens to be an IGP adjacency). In this case, P routers would also happens to be an IGP adjacency). In this case, P routers would also
run the P-instance of PIM, but NOT a C-instance. If there is a PIM run the P-instance of PIM, but NOT a C-instance. If there is a PIM
P-instance, it may or may not have a role to play in support of VPN P-instance, it may or may not have a role to play in support of VPN
multicast; this is discussed in later sections. However, in no case multicast; this is discussed in later sections. However, in no case
will the PIM P-instance contain VPN-specific multicast routing will the PIM P-instance contain VPN-specific multicast routing
skipping to change at page 15, line 32 skipping to change at page 16, line 7
[The "Data MDTs" of earlier drafts provide the transport service [The "Data MDTs" of earlier drafts provide the transport service
of "Selective PMSIs" in the terminology of this draft.] of "Selective PMSIs" in the terminology of this draft.]
We will see in later sections the role played by these different We will see in later sections the role played by these different
kinds of PMSI. We will use the term "I-PMSI" when we are not kinds of PMSI. We will use the term "I-PMSI" when we are not
distinguishing between "MI-PMSIs" and "UI-PMSIs". distinguishing between "MI-PMSIs" and "UI-PMSIs".
3.2.2. Tunnels Instantiating PMSIs 3.2.2. Tunnels Instantiating PMSIs
A number of different tunnel setup techniques can be used to create The tunnels which are used to instantiate PMSIs will be referred to
the tunnels that instantiate the PMSIs. Among these are: as "P-tunnels". A number of different tunnel setup techniques can be
used to create the P-tunnels that instantiate the PMSIs. Among these
are:
- PIM - PIM
A PMSI can be instantiated as (a set of) Multicast Distribution A PMSI can be instantiated as (a set of) Multicast Distribution
Trees created by the PIM P-instance ("P-trees"). Trees created by the PIM P-instance ("P-trees").
PIM-SSM, PIM-Bidir, or PIM-SM can be used to create P-trees. PIM-SSM, BIDIR-PIM, or PIM-SM can be used to create P-trees.
(PIM-DM is not supported for this purpose.) (PIM-DM is not supported for this purpose.)
A single MI-PMSI can be instantiated by a single shared P-tree, A single MI-PMSI can be instantiated by a single shared P-tree,
or by a number of source P-trees (one for each PE of the MI- or by a number of source P-trees (one for each PE of the MI-
PMSI). P-trees may be shared by multiple MVPNs (i.e., a given PMSI). P-trees may be shared by multiple MVPNs (i.e., a given P-
P-tree may be the instantiation of multiple PMSIs), as long as tree may be the instantiation of multiple PMSIs), as long as the
the encapsulation provides some means of demultiplexing the data encapsulation provides some means of demultiplexing the data
traffic by MVPN. traffic by MVPN.
Selective PMSIs are most instantiated by source P-trees, and are Selective PMSIs are most instantiated by source P-trees, and are
most naturally created by PIM-SSM, since by definition only one most naturally created by PIM-SSM, since by definition only one
PE is the source of the multicast data on a Selective PMSI. PE is the source of the multicast data on a Selective PMSI.
[The "Default MDTs" of [rosen-08] are MI-PMSIs instantiated as [The "Default MDTs" of [rosen-08] are MI-PMSIs instantiated as
PIM trees. The "data MDTs" of [rosen-08] are S-PMSIs PIM trees. The "data MDTs" of [rosen-08] are S-PMSIs
instantiated as PIM trees.] instantiated as PIM trees.]
skipping to change at page 18, line 41 skipping to change at page 19, line 16
MI-PMSIs are required under the following conditions: MI-PMSIs are required under the following conditions:
- The MVPN is using PIM-DM, or some other protocol (such as BSR) - The MVPN is using PIM-DM, or some other protocol (such as BSR)
which relies upon flooding. Only with an MI-PMSI can the C-data which relies upon flooding. Only with an MI-PMSI can the C-data
(or C-control-packets) received from any CE be flooded to all (or C-control-packets) received from any CE be flooded to all
PEs. PEs.
- If the procedure for carrying C-multicast routes from PE to PE - If the procedure for carrying C-multicast routes from PE to PE
involves the multicasting of P-PIM control messages among the PEs involves the multicasting of P-PIM control messages among the PEs
(see sections 5.2.1, 5.2.2, and 5.2.4). (see sections 3.4.1.1, 3.4.1.2, and 5.2).
3.3.3. MVPNs That Do Not Use MI-PMSIs 3.3.3. MVPNs That Do Not Use MI-PMSIs
If a particular MVPN does not use a default MI-PMSI, then its If a particular MVPN does not use a default MI-PMSI, then its
multicast data may be sent by default on a UI-PMSI. multicast data may be sent by default on a UI-PMSI.
It is also possible to send all the multicast data on an S-PMSI, It is also possible to send all the multicast data on an S-PMSI,
omitting any usage of I-PMSIs. This prevents PEs from receiving data omitting any usage of I-PMSIs. This prevents PEs from receiving data
which they don't need, at the cost of requiring additional tunnels. which they don't need, at the cost of requiring additional tunnels.
However, cost-effective instantiation of S-PMSIs is likely to require However, cost-effective instantiation of S-PMSIs is likely to require
Aggregate P-trees, which in turn makes it necessary for the Aggregate P-trees, which in turn makes it necessary for the
transmitting PE to know which PEs need to receive which multicast transmitting PE to know which PEs need to receive which multicast
streams. This is known as "explicit tracking", and the procedures to streams. This is known as "explicit tracking", and the procedures to
enable explicit tracking may themselves impose a cost. This is enable explicit tracking may themselves impose a cost. This is
further discussed in section 7.2.2.2. further discussed in section 7.2.2.2.
3.4. PE-PE Transmission of C-Multicast Routing
As a PE attached to a given MVPN receives C-Join/Prune messages from
its CEs in that MVPN, it must convey the information contained in
those messages to other PEs that are attached to the same MVPN.
There are several different methods for doing this. As these methods
are not interoperable, the method to be used for a particular MVPN
must either be configured, or discovered as part of the auto-
discovery process.
3.4.1. PIM Peering
3.4.1.1. Full Per-MVPN PIM Peering Across a MI-PMSI
If the set of PEs attached to a given MVPN are connected via a MI-
PMSI, the PEs can form "normal" PIM adjacencies with each other.
Since the MI-PMSI functions as a broadcast network, the standard PIM
procedures for forming and maintaining adjacencies over a LAN can be
applied.
As a result, the C-Join/Prune messages which a PE receives from a CE
can be multicast to all the other PEs of the MVPN. PIM "join
suppression" can be enabled and the PEs can send Asserts as needed.
This procedure is fully specified in section 5.2.
[This is the procedure specified in [rosen-08].]
3.4.1.2. Lightweight PIM Peering Across a MI-PMSI
The procedure of the previous section has the following
disadvantages:
- Periodic Hello messages must be sent by all PEs.
Standard PIM procedures require that each PE in a particular MVPN
periodically multicast a Hello to all the other PEs in that MVPN.
If the number of MVPNs becomes very large, sending and receiving
these Hellos can become a substantial overhead for the PE
routers.
- Periodic retransmission of C-Join/Prune messages.
PIM is a "soft-state" protocol, in which reliability is assured
through frequent retransmissions (refresh) of control messages.
This too can begin to impose a large overhead on the PE routers
as the number of MVPNs grows.
The first of these disadvantages is easily remedied. The reason for
the periodic PIM Hellos is to ensure that each PIM speaker on a LAN
knows who all the other PIM speakers on the LAN are. However, in the
context of MVPN, PEs in a given MVPN can learn the identities of all
the other PEs in the MVPN by means of the BGP-based auto-discovery
procedure of section 4. In that case, the periodic Hellos would
serve no function, and could simply be eliminated. (Of course, this
does imply a change to the standard PIM procedures.)
When Hellos are suppressed, we may speak of "lightweight PIM
peering".
The periodic refresh of the C-Join/Prunes is not as simple to
eliminate. If and when "refresh reduction" procedures are specified
for PIM, it may be useful to incorporate them, so as to make the
lightweight PIM peering procedures even more lightweight.
Lightweight PIM peering is not specified in this document.
3.4.1.3. Unicasting of PIM C-Join/Prune Messages
PIM does not require that the C-Join/Prune messages which a PE
receives from a CE to be multicast to all the other PEs; it allows
them to be unicast to a single PE, the one which is upstream on the
path to the root of the multicast tree mentioned in the Join/Prune
message. Note that when the C-Join/Prune messages are unicast, there
is no such thing as "join suppression". Therefore PIM Refresh
Reduction may be considered to be a pre-requisite for the procedure
of unicasting the C-Join/Prune messages.
When the C-Join/Prunes are unicast, they are not transmitted on a
PMSI at all. Note that the procedure of unicasting the C-Join/Prunes
is different than the procedure of transmitting the C-Join/Prunes on
an MI-PMSI which is instantiated as a mesh of unicast tunnels.
If there are multiple PEs that can be used to reach a given C-source,
procedures described in section 9 MUST be used to ensue that, at
least within a single AS, all PEs choose the same PE to reach the C-
source.
Procedures for unicasting the PIM control messages are not further
specified in this document.
3.4.2. Using BGP to Carry C-Multicast Routing
It is possible to use BGP to carry C-multicast routing information
from PE to PE, dispensing entirely with the transmission of C-
Join/Prune messages from PE to PE. This is specified in section 5.3.
Inter-AS procedures are described in section 8.
4. BGP-Based Autodiscovery of MVPN Membership 4. BGP-Based Autodiscovery of MVPN Membership
BGP-based autodiscovery is done by means of a new address family, the BGP-based autodiscovery is done by means of a new address family, the
MCAST-VPN address family. (This address family also has other uses, MCAST-VPN address family. (This address family also has other uses,
as will be seen later.) Any PE which attaches to an MVPN must issue as will be seen later.) Any PE which attaches to an MVPN must issue
a BGP update message containing an NLRI in this address family, along a BGP update message containing an NLRI in this address family, along
with a specific set of attributes. In this document, we specify the with a specific set of attributes. In this document, we specify the
information which must be contained in these BGP updates in order to information which must be contained in these BGP updates in order to
provide auto-discovery. The encoding details, along with the provide auto-discovery. The encoding details, along with the
complete set of detailed procedures, are specified in a separate complete set of detailed procedures, are specified in a separate
document [MVPN-BGP]. document [MVPN-BGP].
This section specifies the intra-AS BGP-based autodiscovery This section specifies the intra-AS BGP-based autodiscovery
procedures. When segmented inter-AS trees are used, additional procedures. When segmented inter-AS trees are used, additional
procedures are needed, as specified in section 8. Further detail may procedures are needed, as specified in section 8. Further detail may
be found in [MVPN-BGP]. (When segmented inter-AS trees are not used, be found in [MVPN-BGP]. (When segmented inter-AS trees are not used,
the inter-AS procedures are almost identical to the intra-AS the inter-AS procedures are almost identical to the intra-AS
procedures.) procedures.)
BGP-based autodiscovery uses a particular kind of MCAST-VPN route BGP-based autodiscovery uses a particular kind of MCAST-VPN route
known as an "auto-discovery routes", or "A-D route". known as an "auto-discovery routes", or "A-D route". In particular,
it uses two kinds of "A-D routes", the "Intra-AS A-D Route" and the
"Inter-AS A-D Route". (There are also additional kinds of A-D
routes, such as the Source Active A-D routes which are used for
purposes that go beyond auto-discovery. These are discussed in
subsequent sections.)
An "intra-AS A-D route" is a particular kind of A-D route that is The Inter-AS A-D Route is used only when segmented inter-AS tunnels
never distributed outside its AS of origin. Intra-AS A-D routes are are used, as specified in section 8.
originated by the PEs that are (directly) connected to the site(s) of
that MVPN.
For the purpose of auto-discovery, each PE attached to a site in a The "Intra-AS A-D route" is originated by the PEs that are (directly)
given MVPN must originate an intra-AS auto-discovery route. The NLRI connected to the site(s) of an MVPN. It is distributed to other PEs
of that route must the following information: that attach to sites of the MVPN. If segmented Inter-AS Tunnels are
used, then the Intra-AS A-D routes are not distributed outside the AS
where they originate; if segmented Inter-AS Tunnels are not used,
then the Intra-AS A-D routes are, despite their name, distributed to
all PEs attached to the VPN, no matter what AS the PEs are in.
- The route type (i.e., intra-AS A-D route) The NLRI of an Intra-AS A-D route must contain the following
information:
- IP address of the originating PE - The route type (i.e., Intra-AS A-D route)
- The IP address of the originating PE
- An RD configured locally for the MVPN. This is an RD which can - An RD configured locally for the MVPN. This is an RD which can
be prepended to that IP address to form a globally unique VPN-IP be prepended to that IP address to form a globally unique VPN-IP
address of the PE. address of the PE.
The A-D route must also carry the following attributes: The A-D route must also carry the following attributes:
- One or more Route Target attributes. If any other PE has one of - One or more Route Target attributes. If any other PE has one of
these Route Targets configured for import into a VRF, it treats these Route Targets configured for import into a VRF, it treats
the advertising PE as a member in the MVPN to which the VRF the advertising PE as a member in the MVPN to which the VRF
skipping to change at page 20, line 21 skipping to change at page 23, line 11
given MVPN. More specifically it allows a PE in the receiver given MVPN. More specifically it allows a PE in the receiver
sites set to discover the PEs in the sender sites set of the MVPN sites set to discover the PEs in the sender sites set of the MVPN
and the PEs in the sender sites set of the MVPN to discover the and the PEs in the sender sites set of the MVPN to discover the
PEs in the receiver sites set of the MVPN. The PEs in the PEs in the receiver sites set of the MVPN. The PEs in the
receiver sites set would be configured to import the Route receiver sites set would be configured to import the Route
Targets advertised in the BGP Auto-Discovery routes by PEs in the Targets advertised in the BGP Auto-Discovery routes by PEs in the
sender sites set. The PEs in the sender sites set would be sender sites set. The PEs in the sender sites set would be
configured to import the Route Targets advertised in the BGP configured to import the Route Targets advertised in the BGP
Auto-Discovery routes by PEs in the receiver sites set. Auto-Discovery routes by PEs in the receiver sites set.
* PMSI tunnel attribute. This attribute is present if and only if - PMSI tunnel attribute. This attribute is present if and only if
a default MI-PMSI is to be used for the MVPN. It contains the a default MI-PMSI is to be used for the MVPN. It contains the
following information: following information:
whether the MI-PMSI is instantiated by * whether the MI-PMSI is instantiated by
+ A PIM-Bidir tree, + A BIDIR-PIM tree,
+ a set of PIM-SSM trees, + a set of PIM-SSM trees,
+ a set of PIM-SM trees + a set of PIM-SM trees
+ a set of RSVP-TE point-to-multipoint LSPs + a set of RSVP-TE point-to-multipoint LSPs
+ a set of mLDP point-to-multipoint LSPs + a set of mLDP point-to-multipoint LSPs
+ an mLDP multipoint-to-multipoint LSP + an mLDP multipoint-to-multipoint LSP
skipping to change at page 21, line 13 skipping to change at page 23, line 51
encapsulation to use. encapsulation to use.
Note that a default tunnel can be identified at discovery Note that a default tunnel can be identified at discovery
time only if the tunnel already exists (e.g., it was time only if the tunnel already exists (e.g., it was
constructed by means of configuration), or if it can be constructed by means of configuration), or if it can be
constructed without each PE knowing the the identities of all constructed without each PE knowing the the identities of all
the others (e.g., it is constructed by a receiver-initiated the others (e.g., it is constructed by a receiver-initiated
join technique such as PIM or mLDP). join technique such as PIM or mLDP).
In other cases, a default tunnel cannot be identified until In other cases, a default tunnel cannot be identified until
the PE has discovered one or more of the other PEs. This the PE has discovered one or more of the other PEs. This
will be the case, for example, if the tunnel is an RSVP-TE will be the case, for example, if the tunnel is an RSVP-TE
P2MP LSP, which must be set up from the head end. In these P2MP LSP, which must be set up from the head end. In these
cases, a PE will first send an A-D route without a tunnel cases, a PE will first send an A-D route without a tunnel
identifier, and then will send another one with a tunnel identifier, and then will send another one with a tunnel
identifier after discovering one or more of the other PEs. identifier after discovering one or more of the other PEs.
All the PEs attaching to a given MVPN must be configured with
information specifying the encapsulation to use.
* Whether the tunnel used to instantiate the I-PMSI for this * Whether the tunnel used to instantiate the I-PMSI for this
MVPN is aggregating I-PMSIs from multiple MVPNs. This will MVPN is aggregating I-PMSIs from multiple MVPNs. This will
affect the encapsulation used. If aggregation is to be used, affect the encapsulation used. If aggregation is to be used,
a demultiplexor value to be carried by packets for this a demultiplexor value to be carried by packets for this
particular MVPN must also be specified. The demultiplexing particular MVPN must also be specified. The demultiplexing
mechanism and signaling procedures are described in section mechanism and signaling procedures are described in section
6. 6.
Further details of the use of this information are provided in Further details of the use of this information are provided in
subsequent sections. subsequent sections.
Sometimes it is necessary for one PE to advertise an upstream-
assigned MPLS label that identifies another PE. Under certain
circumstances to be discussed later, a PE which is the root of a
multicast P-tunnel will bind an MPLS label value to one or more
of the PEs that belong to the P-tunnel, and will distribute these
label bindings using A-D routes. The precise details of this
label distribution will be included in the next revision of this
document. We will refer to these as "PE Labels". A packet
traveling on the P-tunnel may carry one of these labels as an
indication that the PE corresponding to that label is special.
See section 11.3 for more details.
5. PE-PE Transmission of C-Multicast Routing 5. PE-PE Transmission of C-Multicast Routing
As a PE attached to a given MVPN receives C-Join/Prune messages from As a PE attached to a given MVPN receives C-Join/Prune messages from
its CEs in that MVPN, it must convey the information contained in its CEs in that MVPN, it must convey the information contained in
those messages to other PEs that are attached to the same MVPN. those messages to other PEs that are attached to the same MVPN. This
is known as the "PE-PE transmission of C-multicast routing
information".
There are several different methods for doing this. As these methods This section specifies the procedures used for PE-PE transmission of
are not interoperable, the method to be used for a particular MVPN C-multicast routing information. Not every procedure mentioned in
must either be configured, or discovered as part of the BGP-based section 3.4 is specified here. Rather, this section focuses on two
auto-discovery process. particular procedures:
5.1. RPF Information for Unicast VPN-IP Routes - Full PIM Peering.
This procedure is fully specified herein.
- Use of BGP to distribute C-multicast routing
This procedure is described herein, but the full specification
appears in [MVPN-BGP].
Those aspect of the procedures which apply to both of the above are
also specified fully herein.
Specification of other procedures is for future study.
5.1. Selecting the Upstream Multicast Hop (UMH)
When a PE receives a C-Join/Prune message from a CE, the message When a PE receives a C-Join/Prune message from a CE, the message
identifies a particular multicast flow as belong either to a source identifies a particular multicast flow as belonging either to a
tree (S,G) or to a shared tree (*,G). We use the term C-source to source tree (S,G) or to a shared tree (*,G). We use the term C-
refer to S, in the case of a source tree, or to the Rendezvous Point source to refer to S, in the case of a source tree, or to the
(RP) for G, in the case of (*,G). The PE needs to find the "upstream Rendezvous Point (RP) for G, in the case of (*,G). If the route to
multicast hop" for the (S,G) or (*,G) flow, and it does this by the C-source is across the VPN backbone, then the PE needs to find
the "upstream multicast hop" (UMH) for the (S,G) or (*,G) flow. The
"upstream multicast hop" is either the PE at which (S,G) or (*,G)
data packets enter the VPN backbone, or else is the Autonomous System
Border Router (ASBR) at which those data packets enter the local AS
when traveling through the VPN backbone. The process of finding the
upstream multicast hop for a given C-source is known as "upstream
multicast hop selection".
5.1.1. Eligible Routes for UMH Selection
In the simplest case, the PE does the upstream hop selection by
looking up the C-source in the unicast VRF associated with the PE-CE looking up the C-source in the unicast VRF associated with the PE-CE
interfaces over which the C-Join/Prune was received. To facilitate interface over which the C-Join/Prune was received. The route that
this, all unicast VPN-IP routes from an MVPN will carry RPF matches the C-source will contain the information needed to select
information, which identifies the PE that originated the route, as the upstream multicast hop.
well as identifying the Autonomous System containing that PE. This
information is consulted when a PE does an "RPF lookup" of the C-
source as part of processing the C-Join/Prune messages. This RPF
information contains the following:
- Source AS Extended Community However, in some cases, the CEs may be distributing to the PEs a
special set of routes that are to be used exclusively for the purpose
of upstream multicast hop selection, and not used for unicast routing
at all. For example, when BGP is the CE-PE unicast routing protocol,
the CEs may be using SAFI 2 to distribute a special set of routes
that are to be used for, and only for, upstream multicast hop
selection. When OSPF is the CE-PE routing protocol, the CE may use
an MT-ID of 1 to distribute a special set of routes that are to be
used for, and only for, upstream multicast hop selection . When a CE
uses one of these mechanisms to distribute to a PE a special set of
routes to be used exclusively for upstream multicast hop selection,
these routes are distributed among the PEs using SAFI 129, as
described in [MVPN-BGP].
To support MVPN a PE that originates a (unicast) route to VPN- Whether the routes used for upstream multicast hop selection are (a)
IPv4 addresses MUST include in the BGP Update message that the "ordinary" unicast routes or (b) a special set of routes that are
carries this route the Source AS extended community, except if it used exclusively for upstream multicast hop selection, is a matter of
is known a priori that none of these addresses will act as policy. How that policy is chosen, deployed, or implemented is
multicast sources and/or RP, in which case the (unicast) route outside the scope of this document. In the following, we will simply
need not carry the Source AS extended community. The Global refer to the set of routes that are used for upstream multicast hop
Administrator field of this community MUST be set to the selection, the "Eligible UMH routes", with no presumptions about the
autonomous system number of the PE. The Local Administrator field policy by which this set of routes was chosen.
of this community SHOULD be set to 0. This community is described
further in [MVPN-BGP].
- Route Import Extended Community 5.1.2. Information Carried by Eligible UMH Routes
To support MVPN in addition to the import/export Route Target(s) Every route which is eligible for UMH selection MUST carry a VRF
used by the unicast routing, each VRF on a PE MUST have an import Route Import Extended Community [MVPN-BGP]. This attribute
Route Target that is unique to this VRF, except if it is known a identifies the PE that originated the route.
priori that none of the (local) MVPN sites associated with the
VRF contain multicast source(s) and/or RP, in which case the VRF
need not have this import Route Target. This Route Target MUST be
IP address specific, and is constructed as follows:
+ The Global Administrator field of the Route Target MUST be set to If BGP is used for carrying C-multicast routes, OR if "Segmented
an IP address of the PE. This address MUST be a routable IP Inter-AS Tunnels" (see section 8.2) are used, then every UMH route
address. This address MAY be common for all the VRFs on the PE MUST also carry a Source AS Extended Community [MVPN-BGP].
(e.,g., this address may be PE's loopback address).
+ The Local Administrator field of the Route Target associated with These two attributes are used in the upstream multicast hop selection
a given VRF contains a 2 octets long number that uniquely procedures described below.
identifies that VRF within the PE that contains the VRF
(procedures for assigning such numbers are purely local to the
PE, and outside the scope of this document).
A PE that originates a (unicast) route to VPN-IPv4 addresses MUST 5.1.3. Selecting the Upstream PE
include in the BGP Updates message that carries this route the Route
Import extended community that has the value of this Route Target,
except if it is known a priori that none of these addresses will act
as multicast sources and/or RP, in which case the (unicast) route
need not carry the Route Import extended community.
The Route Import Extended Community is described further in [MVPN- The first step in selecting the upstream multicast hop for a given C-
BGP]. source is to select the upstream PE router for that C-source.
5.2. PIM Peering The PE that received the C-Join message from a CE looks in the VRF
corresponding to the interfaces over which the C-Join was received.
It finds the Eligible UMH route which is the best match for the C-
source specified in that C-Join. Call this the "Installed UMH
Route".
5.2.1. Full Per-MVPN PIM Peering Across a MI-PMSI Note that the outgoing interface of the Installed UMH Route may be
one of the interfaces associated with the VRF, in which case the
upstream multicast hop is a CE and the route to the C-source is not
across the VPN backbone.
If the set of PEs attached to a given MVPN are connected via a MI- Consider the set of all VPN-IP routes that are: (a) eligible to be
PMSI, the PEs can form "normal" PIM adjacencies with each other. imported into the VRF (as determined by their Route Targets), (b) are
Since the MI-PMSI functions as a broadcast network, the standard PIM eligible to be used for upstream multicast hop selection, and (c)
procedures for forming and maintaining adjacencies over a LAN can be have exactly the same IP prefix (not necessarily the same RD) as the
applied. installed UMH route.
As a result, the C-Join/Prune messages which a PE receives from a CE For each route in this set, determine the corresponding upstream PE
can be multicast to all the other PEs of the MVPN. PIM "join and upstream RD. If a route has a VRF Route Import Extended
suppression" can be enabled and the PEs can send Asserts as needed. Community, the route's upstream PE is determined from it. If a route
does not have a VRF Route Import Extended Community, the route's
upstream PE is determined from the route's BGP next hop attribute.
In either case, the upstream RD is taken from the route's NLRI.
[This is the procedure specified in [rosen-08].] This results in a set of pairs of <route, upstream PE, upstream RD>.
If the Installed UMH Route is not already in this set, it is added to
the set. Call this the "UMH Route Candidate Set." Then the PE MUST
select a single route from the set to be the "Selected UMH Route".
The corresponding upstream PE is known as the "Selected Upstream PE",
and the corresponding upstream RD is known as the "Selected Upstream
RD".
5.2.2. Lightweight PIM Peering Across a MI-PMSI There are several possible procedures that can be used by a PE to
select a single route from the candidate set.
The procedure of the previous section has the following The default procedure, which MUST be implemented, is to select the
disadvantages: route whose corresponding upstream PE address is numerically highest,
where a 32-bit IP address is treated as a 32 bit unsigned integer.
Call this the "default upstream PE selection". For a given C-source,
provided that the routing information used to create the candidate
set is stable, all PEs will have the same default upstream PE
selection. (Though different default upstream PE selections may be
chosen during a routing transient.)
- Periodic Hello messages must be sent by all PEs. An alternative procedure which MUST be implemented, but which is
disabled by default, is the following. This procedure ensures that,
except during a routing transient, each PE chooses the same upstream
PE for a given combination of C-source and C-G.
Standard PIM procedures require that each PE in a particular MVPN 1. The PEs in the candidate set are numbered from lower to higher
periodically multicast a Hello to all the other PEs in that MVPN. IP address, starting from 0.
If the number of MVPNs becomes very large, sending and receiving
these Hellos can become a substantial overhead for the PE
routers.
- Periodic retransmission of C-Join/Prune messages. 2. The following hash is performed:
PIM is a "soft-state" protocol, in which reliability is assured - A bytewise exclusive-or of all the bytes in the C-source
through frequent retransmissions (refresh) of control messages. address and the C-G address is performed.
This too can begin to impose a large overhead on the PE routers
as the number of MVPNs grows.
The first of these disadvantages is easily remedied. The reason for - The result is taken modulo n, where n is the number of PEs
the periodic PIM Hellos is to ensure that each PIM speaker on a LAN in the candidate set. Call this result N.
knows who all the other PIM speakers on the LAN are. However, in the
context of MVPN, PEs in a given MVPN can learn the identities of all
the other PEs in the MVPN by means of the BGP-based auto-discovery
procedure of section 4. In that case, the periodic Hellos would
serve no function, and could simply be eliminated. (Of course, this
does imply a change to the standard PIM procedures.)
When Hellos are suppressed, we may speak of "lightweight PIM The selected upstream PE is then the one that appears in position N
peering". in the list of step 1.
The periodic refresh of the C-Join/Prunes is not as simple to Other hashing algorithms are allowed as well, but not required.
eliminate. The L3VPN WG has asked the PIM WG to specify "refresh
reduction" procedures for PIM, so as to eliminate the need for the
periodic refreshes. If and when such procedures have been specified,
it will be very useful to incorporate them, so as to make the
lightweight PIM peering procedures even more lightweight.
5.2.3. Unicasting of PIM C-Join/Prune Messages The alternative procedure allows a form of "equal cost load
balancing". Suppose, for example, that from egress PEs PE3 and PE4,
source C-S can be reached, at equal cost, via ingress PE PE1 or
ingress PE PE2. The load balancing procedure makes it possible for
PE1 to be the ingress PE for (C-S, C-G1) data traffic while PE2 is
the ingress PE for (C-S, C-G2) data traffic.
PIM does not require that the C-Join/Prune messages which a PE 5.1.4. Selecting the Upstream Multicast Hop
receives from a CE to be multicast to all the other PEs; it allows
them to be unicast to a single PE, the one which is upstream on the
path to the root of the multicast tree mentioned in the Join/Prune
message. Note that when the C-Join/Prune messages are unicast, there
is no such thing as "join suppression". Therefore PIM Refresh
Reduction may be considered to be a pre-requisite for the procedure
of unicasting the C-Join/Prune messages.
When the C-Join/Prunes are unicast, they are not transmitted on a In certain cases, the selected upstream multicast hop is the same as
PMSI at all. Note that the procedure of unicasting the C-Join/Prunes the selected upstream PE. In other cases, the selected upstream
is different than the procedure of transmitting the C-Join/Prunes on multicast hop is the ASBR which is the "BGP next hop" of the Selected
an MI-PMSI which is instantiated as a mesh of unicast tunnels. UMH Route.
If there are multiple PEs that can be used to reach a given C-source, If the selected upstream PE is in the local AS, then the selected
procedures described in section 9 MUST be used to ensue that, at upstream PE is also the selected upstream multicast hop. This is the
least within a single AS, all PEs choose the same PE to reach the C- case if any of the following conditions holds:
source.
5.2.4. Details of Per-MVPN PIM Peering over MI-PMSI - The selected UMH route has a Source AS Extended Community, and
the Source AS is the same as the local AS,
- The selected UMH route does not have a Source AS Extended
Community, but the route's BGP next hop is the same as the
upstream PE.
Otherwise, the selected upstream multicast hop is an ASBR. The
method of determining just which ASBR it is depends on the particular
inter-AS signaling method being used (PIM or BGP), and on whether
segmented or non-segmented inter-AS tunnels are used. These details
are presented in later sections.
5.2. Details of Per-MVPN Full PIM Peering over MI-PMSI
In this section, we assume that inter-AS MVPNs will be supported by In this section, we assume that inter-AS MVPNs will be supported by
means of non-segmented inter-AS trees. Support for segmented inter- means of non-segmented inter-AS trees. Support for segmented inter-
AS trees with PIM peering is for further study. AS trees with PIM peering is for further study.
When an MVPN uses an MI-PMSI, the C-instances of that MVPN can treat When an MVPN uses an MI-PMSI, the C-instances of that MVPN can treat
the MI-PMSI as a LAN interface, and form either full PIM adjacencies the MI-PMSI as a LAN interface, and form either full PIM adjacencies
or lightweight PIM adjacencies with each other over that "LAN with each other over that "LAN interface".
interface".
To form a full PIM adjacency, the PEs execute the PIM LAN procedures, To form a full PIM adjacency, the PEs execute the PIM LAN procedures,
including the generation and processing of PIM Hello, Join/Prune, including the generation and processing of PIM Hello, Join/Prune,
Assert, DF election and other PIM control packets. These are Assert, DF election and other PIM control packets. These are
executed independently for each C-instance. PIM "join suppression" executed independently for each C-instance. PIM "join suppression"
SHOULD be enabled. SHOULD be enabled.
If it is known that all C-instances of a particular MVPN can support 5.2.1. PIM C-Instance Control Packets
lightweight adjacencies, then lightweight adjacencies MUST be used.
If it is not known that all such C-instances support lightweight
instances, then full adjacencies MUST be used. Whether all the C-
instances support lightweight adjacencies is known by virtue of the
BGP-based auto-discovery procedures (combined with configuration).
This knowledge might change over time, so the PEs must be able to
switch in real time between the use of full adjacencies and
lightweight adjacencies.
The difference between a lightweight adjacency and a full adjacency
is that no PIM Hellos are sent or received on a lightweight
adjacency. The function which Hellos usually provide in PIM can be
provided in MVPN by the BGP-based auto-discovery procedures, so the
Hellos become superfluous.
Whether or not Hellos are sent, if PIM Refresh Reduction procedures
are available, and all the PEs supporting the MVPN are known to
support these procedures, then the refresh reduction procedures MUST
be used.
5.2.4.1. PIM C-Instance Control Packets
All PIM C-Instance control packets of a particular MVPN are addressed All PIM C-Instance control packets of a particular MVPN are addressed
to the ALL-PIM-ROUTERS (224.0.0.13) IP destination address, and to the ALL-PIM-ROUTERS (224.0.0.13) IP destination address, and
transmitted over the MI-PMSI of that MVPN. While in transit in the transmitted over the MI-PMSI of that MVPN. While in transit in the
P-network, the packets are encapsulated as required for the P-network, the packets are encapsulated as required for the
particular kind of tunnel that is being used to instantiate the MI- particular kind of tunnel that is being used to instantiate the MI-
PMSI. Thus the C-instance control packets are not processed by the P PMSI. Thus the C-instance control packets are not processed by the P
routers, and MVPN-specific PIM routes can be extended from site to routers, and MVPN-specific PIM routes can be extended from site to
site without appearing in the P routers. site without appearing in the P routers.
5.2.4.2. PIM C-instance RPF Determination As specified in section 5.1.2, when a PE distributes VPN-IP routes
which are eligible for use as UMH routes, the PE MUST include a VRF
Route Import Extended Community with each route. For a given MVPN, a
single such IP address MUST be used, and that same IP address MUST be
used as the source address in all PIM control packets for that MVPN.
5.2.2. PIM C-instance RPF Determination
Although the MI-PMSI is treated by PIM as a LAN interface, unicast Although the MI-PMSI is treated by PIM as a LAN interface, unicast
routing is NOT run over it, and there are no unicast routing routing is NOT run over it, and there are no unicast routing
adjacencies over it. It is therefore necessary to specify special adjacencies over it. It is therefore necessary to specify special
procedures for determining when the MI-PMSI is to be regarded as the procedures for determining when the MI-PMSI is to be regarded as the
"RPF Interface" for a particular C-address. "RPF Interface" for a particular C-address.
When a PE needs to determine the RPF interface of a particular C- The PE follows the procedures of section 5.1 to determine the
address, it looks up the C-address in the VRF. If the route matching selected UMH route. If that route is NOT a VPN-IP route learned from
it (call this the "RPF route") is not a VPN-IP route learned from BGP as described in [RFC4364], or if that route's outgoing interface
MP-BGP as described in [RFC4364], or if that route's outgoing is one of the interfaces associated with the VRF, then ordinary PIM
interface is one of the interfaces associated with the VRF, then procedures for determining the RPF interface apply.
ordinary PIM procedures for determining the RPF interface apply.
However, if the RPF route is a VPN-IP route whose outgoing interface However, if the selected UMH route is a VPN-IP route whose outgoing
is not one of the interfaces associated with the VRF, then PIM will interface is not one of the interfaces associated with the VRF, then
consider the outgoing interface to be the MI-PMSI associated with the PIM will consider the RPF interface to be the MI-PMSI associated with
VPN-specific PIM instance. the VPN-specific PIM instance.
Once PIM has determined that the RPF interface for a particular C- Once PIM has determined that the RPF interface for a particular C-
address is the MI-PMSI, it is necessary for PIM to determine the RPF source is the MI-PMSI, it is necessary for PIM to determine the "RPF
neighbor for that C-address. This will be one of the other PEs that neighbor" for that C-source. This will be one of the other PEs that
is a PIM adjacency over the MI-PMSI. is a PIM adjacency over the MI-PMSI. In particular, it will be the
"selected upstream PE" as defined in section 5.1.
When a PE distributes a given VPN-IP route via BGP, the PE must 5.2.3. Backwards Compatibility
determine whether that route might possibly be regarded, by another
PE, as an RPF route. (If a given VRF is part of an MVPN, it may be
simplest to regard every route exported from that VRF to be a
potential RPF route.) If the given VPN-IP route is a potential RPF
route, then when the VPN-IP route is distributed by BGP, it SHOULD be
accompanied by a VRF Route Import Extended Community (see [MVPN-
BGP]).
The VRF Route Import Extended Community contains an embedded IP There are older implementations which do not use the VRF Route Import
address. If a PE advertises a route with a VRF Route Import Extended Extended Community or any explicit mechanism for carrying information
Community, then the PE MUST use that the IP address embedded therein to identify the originating PE of a selected UMH route.
as its Source IP address in any PIM control messages which it
transmits to other PEs in the same MVPN. If a VRF Route Import
Extended Community is not present, then the source IP address in any
PIM control messages which it transmits to other PEs in the same MVPN
MUST be be the same as the address carried in the BGP Next Hop of the
route.
When a PE has determined that the RPF interface for a particular C- For backwards compatibility, when the selected UMH route does not
address is the MI-PMSI, it must look up the RPF information that was have any such mechanism, the IP address from the "BGP Next Hop" field
distributed along with the VPN-IP address corresponding to that C- of the selected UMH route will be used as the selected UMH address,
address. The IP address in this RPF information will be considered and will be treated as the address of the upstream PE. There is no
to be the IP address of the RPF adjacency for the C-address. selected upstream RD in this case. However, use of this backwards
compatibility technique presupposes that:
If the RPF information is not present, but the "BGP Next Hop" for the - The PE which originated the selected UMH route placed the same IP
C-address is one of the PEs that is a PIM adjacency over the MI-PMSI, address in the BGP Next Hop field that it is using as the source
then that PE should be treated as the RPF adjacency for that C- address of the PE-PE PIM control packets for this MVPN.
address. However, if the MVPN spans multiple Autonomous Systems, the
BGP Next Hop might not be a PIM adjacency, and if that is the case - The MVPN is not an Inter-AS MVPN that uses option b from section
the RPF check will not succeed unless the RPF information is used. 10 of [RFC4364].
Should either of these conditions fail, interoperability with the
older implementations will not be achieved.
5.3. Use of BGP for Carrying C-Multicast Routing 5.3. Use of BGP for Carrying C-Multicast Routing
It is possible to use BGP to carry C-multicast routing information It is possible to use BGP to carry C-multicast routing information
from PE to PE, dispensing entirely with the transmission of C- from PE to PE, dispensing entirely with the transmission of C-
Join/Prune messages from PE to PE. This section describes the Join/Prune messages from PE to PE. This section describes the
procedures for carrying intra-AS multicast routing information. procedures for carrying intra-AS multicast routing information.
Inter-AS procedures are described in section 8. Inter-AS procedures are described in section 8. The complete
specification of both sets of procedures and of the encodings can be
found in [MVPN-BGP].
5.3.1. Sending BGP Updates 5.3.1. Sending BGP Updates
The MCAST-VPN address family is used for this purpose. MCAST-VPN The MCAST-VPN address family is used for this purpose. MCAST-VPN
routes used for the purpose of carrying C-multicast routing routes used for the purpose of carrying C-multicast routing
information are distinguished from those used for the purpose of information are distinguished from those used for the purpose of
carrying auto-discovery information by means of a "route type" field carrying auto-discovery information by means of a "route type" field
which is encoded into the NLRI. The following information is which is encoded into the NLRI. The following information is
required in BGP to advertise the MVPN routing information. The NLRI required in BGP to advertise the MVPN routing information. The NLRI
contains: contains:
- The type of C-multicast route. - The type of C-multicast route.
There are two types: There are two types:
* source tree join * source tree join
* shared tree join * shared tree join
- The RD configured, for the MVPN, on the PE that is advertising - The RD configured, for the MVPN, on the PE that is advertising
the information. This is required to uniquely identify the <C- the information. The RD is required in order to uniquely
Source, C-Group> as the addresses could overlap between different identify the <C-Source, C-Group> when different MVPNs have
MVPNs. overlapping address spaces.
- The C-Source address. (Omitted if the route type is "shared tree
join")
- The C-Group address. - The C-Group address.
- The RD from the VPN-IP route to the C-source. - The C-Source address.
That is, the route to the C-source is looked up in the local
unicast VRF associated with the CE-PE interface over which the
C-multicast control packet arrived. The corresponding VPN-IP
route is then examined, and the RD from that route is placed into
the C-multicast route.
Note that this RD is NOT necessarily one which is configured on
the local PE. Rather it is one which is configured on the remote
PE that is on the path to the C-source.
The following attribute must also be included:
- The upstream multicast hop.
If a PE receives a C-Join (*, G) from a CE, the C-source is
considered to be the C-RP for the particular C-G. When the C-
multicast route represents a "shared tree join", it is presumed
that the root of the tree (e.g., the RP) is determined by some
means outside the scope of this specification.
When the PE processes a C-PIM Join/Prune message, the route to
the C-source is looked up in the local unicast VRF associated
with the CE-PE interface over which the C-multicast control
packet arrived. The corresponding VPN-IP route is then examined.
If the AS specified therein is the local AS, or if no AS is
specified therein, then the PE specified therein becomes the
upstream multicast hop. If the AS specified therein is a remote
AS, the BGP next hop on the route to the MVPN Auto-Discovery
route advertised by the remote AS, becomes the upstream multicast
hop.
N.B.: It is possible that here is more than one unicast VPN-IP
route to the C-source. In this case, the route that was
installed in the VRF is not necessarily the route that must be
chosen by the PE. In order to choose the proper route, the
procedures followed in section 9 MUST be followed.
The upstream multicast hop is identified in an Extended Communities This field is omitted if the route type is "shared tree join".
attribute to facilitate the optional use of filters which can prevent In the case of a shared tree join, the C-source is a C-RP. The
the distribution of the update to BGP speakers other than the address of the C-RP corresponding to the C-group address is
upstream multicast hop. presumed to be already known (or automatically determinable) be
the other PEs, though means that are outside the scope of this
specification.
When a PE distributes this information via BGP, it must include a - The Selected Upstream RD corresponding to the C-source address
Route Import Extended Communities attribute learned from the RPF (determined by the procedures of section 5.1).
information.
Note that for these procedures to work the VPN-IP route MUST contain Whenever a C-multicast route is sent, it must also carry, in a Route
the RPF information. Target Extended Community, the Selected Upstream Multicast Hop
corresponding to the C-source address (determined by the procedures
of section 5.1). The selected upstream multicast hop is identified in
an Extended Community attribute to facilitate the optional use of
filters which can prevent the distribution of the update to BGP
speakers other than the upstream multicast hop. See section 10.1.3
of [MVPN-BGP] for the details.
Note that there is no C-multicast route corresponding to the PIM There is no C-multicast route corresponding to the PIM function of
function of pruning a source off the shared tree when a PE switches pruning a source off the shared tree when a PE switches from a <C-*,
from a <C-*, C-G> tree to a <C-S, C-G> tree. Section 9 of this C-G> tree to a <C-S, C-G> tree. Section 9 of this document specifies
document specifies a mandatory procedure that ensures that if any PE a mandatory procedure that ensures that if any PE joins a <C-S, C-G>
joins a <C-S, C-G> source tree, all other PEs that have joined or source tree, all other PEs that have joined or will join the <C-*, C-
will join the <C-*, C-G> shared tree will also join the <C-S, C-G> G> shared tree will also join the <C-S, C-G> source tree. This
source tree. This eliminates the need for a C-multicast route that eliminates the need for a C-multicast route that prunes C-S off the
prunes C-S off the <C-*, C-G> shared tree when switching from <C-*, <C-*, C-G> shared tree when switching from <C-*, C-G> to <C-S, C-G>
C-G> to <C-S, C-G> tree. tree.
5.3.2. Explicit Tracking 5.3.2. Explicit Tracking
Note that the upstream multicast hop is NOT part of the NLRI in the Note that the upstream multicast hop is NOT part of the NLRI in the
C-multicast BGP routes. This means that if several PEs join the same C-multicast BGP routes. This means that if several PEs join the same
C-tree, the BGP routes they distribute to do so are regarded by BGP C-tree, the BGP routes they distribute to do so are regarded by BGP
as comparable routes, and only one will be installed. If a route as comparable routes, and only one will be installed. If a route
reflector is being used, this further means that the PE which is used reflector is being used, this further means that the PE which is used
to reach the C-source will know only that one or more of the other to reach the C-source will know only that one or more of the other
PEs have joined the tree, but it won't know which one. That is, this PEs have joined the tree, but it won't know which one. That is, this
skipping to change at page 30, line 8 skipping to change at page 32, line 45
A PE removes itself from a C-multicast tree (shared or source) by A PE removes itself from a C-multicast tree (shared or source) by
withdrawing the corresponding BGP update. withdrawing the corresponding BGP update.
If a PE has pruned a C-source from a shared C-multicast tree, and it If a PE has pruned a C-source from a shared C-multicast tree, and it
needs to "unprune" that source from that tree, it does so by needs to "unprune" that source from that tree, it does so by
withdrawing the route that pruned the source from the tree. withdrawing the route that pruned the source from the tree.
6. I-PMSI Instantiation 6. I-PMSI Instantiation
This section describes how tunnels in the SP network can be used to This section describes how tunnels in the SP network can be used to
instantiate an I-PMSI for an MVPN on a PE. When C-multicast data is instantiate an I-PMSI for an MVPN on a PE. When C-multicast data is
delivered on an I-PMSI, the data will go to all PEs that are on the delivered on an I-PMSI, the data will go to all PEs that are on the
path to receivers for that C-group, but may also go to PEs that are path to receivers for that C-group, but may also go to PEs that are
not on the path to receivers for that C-group. not on the path to receivers for that C-group.
The tunnels which instantiate I-PMSIs can be either PE-PE unicast The tunnels which instantiate I-PMSIs can be either PE-PE unicast
tunnels or P-multicast trees. When PE-PE unicast tunnels are used the tunnels or P-multicast trees. When PE-PE unicast tunnels are used the
PMSI is said to be instantiated using ingress replication. The PMSI is said to be instantiated using ingress replication. The
instantiation of a tunnel for an I-PMSI is a matter of local policy instantiation of a tunnel for an I-PMSI is a matter of local policy
decision and is not mandatory. Even for a site attached to multicast decision and is not mandatory. Even for a site attached to multicast
sources, transport of customer multicast traffic can be accommodated sources, transport of customer multicast traffic can be accommodated
with S-PMSI-bound tunnels only with S-PMSI-bound tunnels only
[Editor's Note: MD trees described in [ROSEN-8, MVPN-BASE] are an [Editor's Note: MD trees described in [ROSEN-8, MVPN-BASE] are an
example of P-multicast trees. Also Aggregate Trees described in example of P-multicast trees. Also Aggregate Trees described in
[RAGGARWA-MCAST] are an example of P-multicast trees.] [RAGGARWA-MCAST] are an example of P-multicast trees.]
6.1. MVPN Membership and Egress PE Auto-Discovery 6.1. MVPN Membership and Egress PE Auto-Discovery
As described in section 4 a PE discovers the MVPN membership As described in section 4 a PE discovers the MVPN membership
skipping to change at page 33, line 48 skipping to change at page 36, line 44
packet must also carry some demultiplexing information to allow the packet must also carry some demultiplexing information to allow the
egress PEs to determine the MVPN to which the packet belongs. Since egress PEs to determine the MVPN to which the packet belongs. Since
the packet has been multicast through the P network, any given the packet has been multicast through the P network, any given
demultiplexing value must have the same meaning to all the egress demultiplexing value must have the same meaning to all the egress
PEs. The demultiplexing value is a MPLS label that corresponds to PEs. The demultiplexing value is a MPLS label that corresponds to
the multicast VRF to which the packet belongs. This label is placed the multicast VRF to which the packet belongs. This label is placed
by the ingress PE immediately beneath the P-Multicast tree header. by the ingress PE immediately beneath the P-Multicast tree header.
Each of the egress PEs must be able to associate this MPLS label with Each of the egress PEs must be able to associate this MPLS label with
the same MVPN. If downstream label assignment were used this would the same MVPN. If downstream label assignment were used this would
require all the egress PEs in the MVPN to agree on a common label for require all the egress PEs in the MVPN to agree on a common label for
the MVPN. Instead the MPLS label is upstream assigned [MPLS- the MVPN. Instead the MPLS label is upstream assigned [MPLS-UPSTREAM-
UPSTREAM-LABEL]. The label bindings are advertised via BGP updates LABEL]. The label bindings are advertised via BGP updates originated
originated the ingress PEs. the ingress PEs.
This procedure requires each egress PE to support a separate label This procedure requires each egress PE to support a separate label
space for every other PE. The egress PEs create a forwarding entry space for every other PE. The egress PEs create a forwarding entry
for the upstream assigned MPLS label, allocated by the ingress PE, in for the upstream assigned MPLS label, allocated by the ingress PE, in
this label space. Hence when the egress PE receives a packet over an this label space. Hence when the egress PE receives a packet over an
Aggregate Tree, it first determines the tree that the packet was Aggregate Tree, it first determines the tree that the packet was
received over. The tree identifier determines the label space in received over. The tree identifier determines the label space in
which the upstream assigned MPLS label lookup has to be performed. which the upstream assigned MPLS label lookup has to be performed.
The same label space may be used for all P-multicast trees rooted at The same label space may be used for all P-multicast trees rooted at
the same ingress PE, or an implementation may decide to use a the same ingress PE, or an implementation may decide to use a
skipping to change at page 34, line 46 skipping to change at page 37, line 41
aggregation, there be at least one upstream-assigned label per MVPN. aggregation, there be at least one upstream-assigned label per MVPN.
It does not require that there be only one. For example, an ingress It does not require that there be only one. For example, an ingress
PE could assign a unique label to each C-(S,G). (This could be done PE could assign a unique label to each C-(S,G). (This could be done
using the same technique this is used to assign a particular C-(S,G) using the same technique this is used to assign a particular C-(S,G)
to an S-PMSI, see section 7.3.) to an S-PMSI, see section 7.3.)
6.4. Mapping Received Packets to MVPNs 6.4. Mapping Received Packets to MVPNs
When an egress PE receives a C-multicast data packet over a P- When an egress PE receives a C-multicast data packet over a P-
multicast tree, it needs to forward the packet to the CEs that have multicast tree, it needs to forward the packet to the CEs that have
receivers in the packet's C-multicast group. It also needs to receivers in the packet's C-multicast group. In order to do this the
determine the RPF interface for the C-multicast data packet. In order egress PE needs to determine the tunnel that the packet was received
to do this the egress PE needs to determine the tunnel that the on. The PE can then determine the MVPN that the packet belongs to and
packet was received on. The PE can then determine the MVPN that the if needed do any further lookups that are needed to forward the
packet belongs to and if needed do any further lookups that are packet.
needed to forward the packet.
6.4.1. Unicast Tunnels 6.4.1. Unicast Tunnels
When ingress replication is used, the MVPN to which the received C- When ingress replication is used, the MVPN to which the received C-
multicast data packet belongs can be determined by the MPLS label multicast data packet belongs can be determined by the MPLS label
that was allocated by the egress. This label is distributed by the that was allocated by the egress. This label is distributed by the
egress. This also determines the RPF interface for the C-multicast egress.
data packet.
6.4.2. Non-Aggregated P-Multicast Trees 6.4.2. Non-Aggregated P-Multicast Trees
If a P-multicast tree is associated with only one MVPN, determining If a P-multicast tree is associated with only one MVPN, determining
the P-multicast tree on which a packet was received is sufficient to the P-multicast tree on which a packet was received is sufficient to
determine the packet's MVPN. All that the egress PE needs to know is determine the packet's MVPN. All that the egress PE needs to know is
the MVPN the P-multicast tree is associated with. the MVPN the P-multicast tree is associated with.
There are different ways in which the egress PE can learn this There are different ways in which the egress PE can learn this
association: association:
a) Configuration. The P-multicast tree that a particular MVPN a) Configuration. The P-multicast tree that a particular MVPN
belongs to is configured on each PE. belongs to is configured on each PE.
[Editor's Note: PIM-SM Default MD trees in [ROSEN-8] and [Editor's Note: PIM-SM Default MD trees in [ROSEN-8] and [MVPN-
[MVPN-BASE] are examples of configuring the P-multicast tree BASE] are examples of configuring the P-multicast tree and MVPN
and MVPN association] association]
b) BGP based advertisement of the P-multicast tree - MPVN mapping b) BGP based advertisement of the P-multicast tree - MPVN mapping
after the root of the tree discovers the leaves of the tree. after the root of the tree discovers the leaves of the tree.
The root of the tree sets up the tree after discovering each of The root of the tree sets up the tree after discovering each of
the PEs that belong to the MVPN. It then advertises the P- the PEs that belong to the MVPN. It then advertises the P-
multicast tree - MVPN mapping to each of the leaves. This multicast tree - MVPN mapping to each of the leaves. This
mechanism can be used with both source initiated trees [e.g. mechanism can be used with both source initiated trees [e.g.
RSVP-TE P2MP LSPs] and receiver initiated trees [e.g. PIM RSVP-TE P2MP LSPs] and receiver initiated trees [e.g. PIM
trees]. trees].
skipping to change at page 37, line 20 skipping to change at page 40, line 18
to each of the remote PEs in the MVPN that support ingress to each of the remote PEs in the MVPN that support ingress
replication. Hence a remote PE may receive C-multicast data packets replication. Hence a remote PE may receive C-multicast data packets
for a group even if it doesn't have any receivers in that group. for a group even if it doesn't have any receivers in that group.
Ingress replication can also be used to instantiate a MI-PMSI. In Ingress replication can also be used to instantiate a MI-PMSI. In
this case each PE has a mesh of unicast tunnels to every other PE in this case each PE has a mesh of unicast tunnels to every other PE in
that MVPN. that MVPN.
However when ingress replication is used it is recommended that only However when ingress replication is used it is recommended that only
S-PMSIs be used. Instantiation of S-PMSIs with ingress replication is S-PMSIs be used. Instantiation of S-PMSIs with ingress replication is
described in section 7.2. Note that this requires the use of described in section 7.1. Note that this requires the use of
explicit tracking, i.e., a PE must know which of the other PEs have explicit tracking, i.e., a PE must know which of the other PEs have
receivers for each C-multicast tree. receivers for each C-multicast tree.
6.6. Establishing P-Multicast Trees 6.6. Establishing P-Multicast Trees
It is believed that the architecture outlined in this document places It is believed that the architecture outlined in this document places
no limitations on the protocols used to instantiate P-multicast no limitations on the protocols used to instantiate P-multicast
trees. However, the only protocols being explicitly considered are trees. However, the only protocols being explicitly considered are
PIM-SM, PIM-SSM, PIM-Bidir, RSVP-TE, and mLDP. PIM-SM, PIM-SSM, BIDIR-PIM, RSVP-TE, and mLDP.
A P-multicast tree can be either a source tree or a shared tree. A A P-multicast tree can be either a source tree or a shared tree. A
source tree is used to carry traffic only for the multicast VRFs that source tree is used to carry traffic only for the multicast VRFs that
exist locally on the root of the tree i.e. for which the root has exist locally on the root of the tree i.e. for which the root has
local CEs. The root is a PE router. Source P-multicast trees can be local CEs. The root is a PE router. Source P-multicast trees can be
instantiated using PIM-SM, PIM-SSM, RSVP-TE P2MP LSPs, and mLDP P2MP instantiated using PIM-SM, PIM-SSM, RSVP-TE P2MP LSPs, and mLDP P2MP
LSPs. LSPs.
A shared tree on the other hand can be used to carry traffic A shared tree on the other hand can be used to carry traffic
belonging to VRFs that exist on other PEs as well. The root of a belonging to VRFs that exist on other PEs as well. The root of a
shared tree is not necessarily one of the PEs in the MVPN. All PEs shared tree is not necessarily one of the PEs in the MVPN. All PEs
that use the shared tree will send MVPN data packets to the root of that use the shared tree will send MVPN data packets to the root of
the shared tree; if PIM is being used as the control protocol, PIM the shared tree; if PIM is being used as the control protocol, PIM
control packets also get sent to the root of the shared tree. This control packets also get sent to the root of the shared tree. This
may require an unicast tunnel between each of these PEs and the root. may require an unicast tunnel between each of these PEs and the root.
The root will then send them on the shared tree and all the PEs that The root will then send them on the shared tree and all the PEs that
are leaves of the shared tree will receive the packets. For example a are leaves of the shared tree will receive the packets. For example a
RP based PIM-SM tree would be a shared tree. Shared trees can be RP based PIM-SM tree would be a shared tree. Shared trees can be
instantiated using PIM-SM, PIM-SSM, PIM-Bidir, RSVP-TE P2MP LSPs, instantiated using PIM-SM, PIM-SSM, BIDIR-PIM, RSVP-TE P2MP LSPs,
mLDP P2MP LSPs, and mLDP MP2MP LSPs.. Aggregation support for mLDP P2MP LSPs, and mLDP MP2MP LSPs.. Aggregation support for
bidirectional P-trees (i.e., PIM-Bidir trees or mLDP MP2MP trees) is bidirectional P-trees (i.e., BIDIR-PIM trees or mLDP MP2MP trees) is
for further study. Shared trees require all the PEs to discover the for further study. Shared trees require all the PEs to discover the
root of the shared tree for a MVPN. To achieve this the root of a root of the shared tree for a MVPN. To achieve this the root of a
shared tree advertises as part of the BGP based MVPN membership shared tree advertises as part of the BGP based MVPN membership
discovery: discovery:
- The capability to setup a shared tree for a specified MVPN. - The capability to setup a shared tree for a specified MVPN.
- A downstream assigned label that is to be used by each PE to - A downstream assigned label that is to be used by each PE to
encapsulate a MVPN data packet, when they send this packet to the encapsulate a MVPN data packet, when they send this packet to the
root of the shared tree. root of the shared tree.
- A downstream assigned label that is to be used by each PE to - A downstream assigned label that is to be used by each PE to
encapsulate a MVPN control packet, when they send this packet to encapsulate a MVPN control packet, when they send this packet to
the root of the shared tree. the root of the shared tree.
Both a source tree and a shared tree can be used to instantiate an Both a source tree and a shared tree can be used to instantiate an I-
I-PMSI. If a source tree is used to instantiate an UI-PMSI for a PMSI. If a source tree is used to instantiate an UI-PMSI for a MVPN,
MVPN, all the other PEs that belong to the MVPN, must be leaves of all the other PEs that belong to the MVPN, must be leaves of the
the source tree. If a shared tree is used to instantiate a UI-PMSI source tree. If a shared tree is used to instantiate a UI-PMSI for a
for a MVPN, all the PEs that are members of the MVPN must be leaves MVPN, all the PEs that are members of the MVPN must be leaves of the
of the shared tree. shared tree.
6.7. RSVP-TE P2MP LSPs 6.7. RSVP-TE P2MP LSPs
This section describes procedures that are specific to the usage of This section describes procedures that are specific to the usage of
RSVP-TE P2MP LSPs for instantiating a UI-PMSI. The RSVP-TE P2MP LSP RSVP-TE P2MP LSPs for instantiating a UI-PMSI. The RSVP-TE P2MP LSP
can be either a source tree or a shared tree. Procedures in [RSVP- can be either a source tree or a shared tree. Procedures in [RSVP-
P2MP] are used to signal the LSP. The LSP is signaled after the root P2MP] are used to signal the LSP. The LSP is signaled after the root
of the LSP discovers the leaves. The egress PEs are discovered using of the LSP discovers the leaves. The egress PEs are discovered using
the MVPN membership procedures described in section 4. RSVP-TE P2MP the MVPN membership procedures described in section 4. RSVP-TE P2MP
LSPs can optionally support aggregation. LSPs can optionally support aggregation.
skipping to change at page 39, line 8 skipping to change at page 42, line 4
using either option (a) or option (b) described in section 6.4.2. using either option (a) or option (b) described in section 6.4.2.
Option (b) i.e. BGP based advertisements of the P2MP TE LSP Tunnel - Option (b) i.e. BGP based advertisements of the P2MP TE LSP Tunnel -
MPVN mapping require that the root of the tree include the P2MP TE MPVN mapping require that the root of the tree include the P2MP TE
LSP Tunnel identifier as the tunnel identifier in the BGP LSP Tunnel identifier as the tunnel identifier in the BGP
advertisements. This identifier contains the following information advertisements. This identifier contains the following information
elements: elements:
- The type of the tunnel is set to RSVP-TE P2MP Tunnel - The type of the tunnel is set to RSVP-TE P2MP Tunnel
- RSVP-TE P2MP Tunnel's SESSION Object - RSVP-TE P2MP Tunnel's SESSION Object
- Optionally RSVP-TE P2MP LSP's SENDER_TEMPLATE Object. This object - Optionally RSVP-TE P2MP LSP's SENDER_TEMPLATE Object. This object
is included when it is desired to identify a particular P2MP TE is included when it is desired to identify a particular P2MP TE
LSP. LSP.
6.7.2. Demultiplexing C-Multicast Data Packets 6.7.2. Demultiplexing C-Multicast Data Packets
Demultiplexing the C-multicast data packets at the egress PE follow Demultiplexing the C-multicast data packets at the egress PE follow
procedures described in section 6.3.4. The RSVP-TE P2MP LSP Tunnel procedures described in section 6.3.4. The RSVP-TE P2MP LSP Tunnel
must be signaled with penultimate-hop-popping (PHP) off. Signaling must be signaled with penultimate-hop-popping (PHP) off. Signaling
the P2MP TE LSP Tunnel with PHP off requires an extension to RSVP-TE the P2MP TE LSP Tunnel with PHP off requires an extension to RSVP-TE
which will be described later. which will be described later.
7. Optimizing Multicast Distribution via S-PMSIs 7. Optimizing Multicast Distribution via S-PMSIs
Whenever a particular multicast stream is being sent on an I-PMSI, it Whenever a particular multicast stream is being sent on an I-PMSI, it
is likely that the data of that stream is being sent to PEs that do is likely that the data of that stream is being sent to PEs that do
not require it. If a particular stream has a significant amount of not require it. If a particular stream has a significant amount of
traffic, it may be beneficial to move it to an S-PMSI which includes traffic, it may be beneficial to move it to an S-PMSI which includes
only those PEs that are transmitters and/or receivers (or at least only those PEs that are transmitters and/or receivers (or at least
includes fewer PEs that are neither). includes fewer PEs that are neither).
If explicit tracking is being done, S-PMSI creation can also be If explicit tracking is being done, S-PMSI creation can also be
triggered on other criteria. For instance there could be a "pseudo triggered on other criteria. For instance there could be a "pseudo
wasted bandwidth" criteria: switching to an S-PMSI would be done if wasted bandwidth" criteria: switching to an S-PMSI would be done if
the bandwidth multiplied by the number of uninterested PEs (PE that the bandwidth multiplied by the number of uninterested PEs (PE that
are receiving the stream but have no receivers) is above a specified are receiving the stream but have no receivers) is above a specified
threshold. The motivation is that (a) the total bandwidth wasted by threshold. The motivation is that (a) the total bandwidth wasted by
many sparsely subscribed low-bandwidth groups may be large, and (b) many sparsely subscribed low-bandwidth groups may be large, and (b)
skipping to change at page 40, line 19 skipping to change at page 43, line 12
PEs that have receivers for multicast groups that are mapped onto PEs that have receivers for multicast groups that are mapped onto
the tree. the tree.
The above two cases require that explicit tracking be done for the The above two cases require that explicit tracking be done for the
(C-S, C-G) stream. The root of the S-PMSI MAY decide to do explicit (C-S, C-G) stream. The root of the S-PMSI MAY decide to do explicit
tracking of this stream only after it has determined to move the tracking of this stream only after it has determined to move the
stream to an S-PMSI, or it MAY have been doing explicit tracking all stream to an S-PMSI, or it MAY have been doing explicit tracking all
along. along.
If the S-PMSI is instantiated by a P-multicast tree, the PE at the If the S-PMSI is instantiated by a P-multicast tree, the PE at the
root of the tree must signal the leaves of the tree that the (C-S, root of the tree must signal the leaves of the tree that the (C-S, C-
C-G) stream is now bound to the to the S-PMSI. Note that the PE could G) stream is now bound to the to the S-PMSI. Note that the PE could
create the identity of the P-multicast tree prior to the actual create the identity of the P-multicast tree prior to the actual
instantiation of the tunnel. instantiation of the tunnel.
If the S-PMSI is instantiated by a source-initiated P-multicast tree If the S-PMSI is instantiated by a source-initiated P-multicast tree
(e.g., an RSVP-TE P2MP tunnel), the PE at the root of the tree must (e.g., an RSVP-TE P2MP tunnel), the PE at the root of the tree must
establish the source-initiated P-multicast tree to the leaves. This establish the source-initiated P-multicast tree to the leaves. This
tree MAY have been established before the leaves receive the S-PMSI tree MAY have been established before the leaves receive the S-PMSI
binding, or MAY be established after the leaves receives the binding. binding, or MAY be established after the leaves receives the binding.
The leaves MUST not switch to the S-PMSI until they receive both the The leaves MUST not switch to the S-PMSI until they receive both the
binding and the tree signaling message. binding and the tree signaling message.
skipping to change at page 41, line 39 skipping to change at page 44, line 37
When a PE which attaches to a transmitter for a particular multicast When a PE which attaches to a transmitter for a particular multicast
stream notices that the conditions for moving the stream to an S-PMSI stream notices that the conditions for moving the stream to an S-PMSI
are met, it begins to periodically send an "S-PMSI Join Message" on are met, it begins to periodically send an "S-PMSI Join Message" on
the MI-PMSI. The S-PMSI Join is a UDP-encapsulated message whose the MI-PMSI. The S-PMSI Join is a UDP-encapsulated message whose
destination address is ALL-PIM-ROUTERS (224.0.0.13), and whose destination address is ALL-PIM-ROUTERS (224.0.0.13), and whose
destination port is 3232. destination port is 3232.
The S-PMSI Join Message contains the following information: The S-PMSI Join Message contains the following information:
- An identifier for the particular multicast stream which is to be - An identifier for the particular multicast stream which is to be
bound to the S-PMSI. This can be represented as an (S,G) pair. bound to the S-PMSI. This can be represented as an (S,G) pair.
- An identifier for the particular S-PMSI to which the stream is to - An identifier for the particular S-PMSI to which the stream is to
be bound. This identifier is a structured field which includes be bound. This identifier is a structured field which includes
the following information: the following information:
* The type of tunnel used to instantiate the S-PMSI * The type of tunnel used to instantiate the S-PMSI
* An identifier for the tunnel. The form of the identifier * An identifier for the tunnel. The form of the identifier
will depend upon the tunnel type. The combination of tunnel will depend upon the tunnel type. The combination of tunnel
identifier and tunnel type should contain enough information identifier and tunnel type should contain enough information
to enable all the PEs to "join" the tunnel and receive to enable all the PEs to "join" the tunnel and receive
messages from it. messages from it.
* Any demultiplexing information needed by the tunnel * Any demultiplexing information needed by the tunnel
encapsulation protocol to identify the particular S-PMSI. encapsulation protocol to identify the particular S-PMSI.
This allows a single tunnel to aggregate multiple S-PMSIs. This allows a single tunnel to aggregate multiple S-PMSIs.
If a particular tunnel is not aggregating multiple S-PMSIs, If a particular tunnel is not aggregating multiple S-PMSIs,
skipping to change at page 45, line 21 skipping to change at page 48, line 14
c) The C-Source address. This address can be a prefix in order to c) The C-Source address. This address can be a prefix in order to
allow a range of C-Source addresses to be mapped to an allow a range of C-Source addresses to be mapped to an
Aggregate Tree. Aggregate Tree.
d) The C-Group address. This address can be a range in order to d) The C-Group address. This address can be a range in order to
allow a range of C-Group addresses to be mapped to an Aggregate allow a range of C-Group addresses to be mapped to an Aggregate
Tree. Tree.
e) A PE MAY aggregate two or more S-PMSIs originated by the PE e) A PE MAY aggregate two or more S-PMSIs originated by the PE
onto the same P-Multicast tree. If the PE already advertises onto the same P-Multicast tree. If the PE already advertises S-
S-PMSI auto-discovery routes for these S-PMSIs, then PMSI auto-discovery routes for these S-PMSIs, then aggregation
aggregation requires the PE to re-advertise these routes. The requires the PE to re-advertise these routes. The re-advertised
re-advertised routes MUST be the same as the original ones, routes MUST be the same as the original ones, except for the
except for the PMSI tunnel attribute. If the PE has not PMSI tunnel attribute. If the PE has not previously advertised
previously advertised S-PMSI auto-discovery routes for these S-PMSI auto-discovery routes for these S-PMSIs, then the
S-PMSIs, then the aggregation requires the PE to advertise aggregation requires the PE to advertise (new) S-PMSI auto-
(new) S-PMSI auto-discovery routes for these S-PMSIs. The PMSI discovery routes for these S-PMSIs. The PMSI Tunnel attribute
Tunnel attribute in the newly advertised/re-advertised routes in the newly advertised/re-advertised routes MUST carry the
MUST carry the identity of the P- Multicast tree that identity of the P- Multicast tree that aggregates the S-PMSIs.
aggregates the S-PMSIs. If at least some of the S-PMSIs If at least some of the S-PMSIs aggregated onto the same P-
aggregated onto the same P-Multicast tree belong to different Multicast tree belong to different MVPNs, then all these routes
MVPNs, then all these routes MUST carry an MPLS upstream MUST carry an MPLS upstream assigned label [MPLS-UPSTREAM-
assigned label [MPLS-UPSTREAM-LABEL, section 6.3.4]. If all LABEL, section 6.3.4]. If all these aggregated S-PMSIs belong
these aggregated S-PMSIs belong to the same MVPN, then the to the same MVPN, then the routes MAY carry an MPLS upstream
routes MAY carry an MPLS upstream assigned label [MPLS- assigned label [MPLS-UPSTREAM-LABEL]. The labels MUST be
UPSTREAM-LABEL]. The labels MUST be distinct on a per MVPN distinct on a per MVPN basis, and MAY be distinct on a per
basis, and MAY be distinct on a per route basis. route basis.
When a PE distributes this information via BGP, it must include the When a PE distributes this information via BGP, it must include the
following: following:
1. An identifier for the particular S-PMSI to which the stream is 1. An identifier for the particular S-PMSI to which the stream is
to be bound. This identifier is a structured field which to be bound. This identifier is a structured field which
includes the following information: includes the following information:
* The type of tunnel used to instantiate the S-PMSI * The type of tunnel used to instantiate the S-PMSI
skipping to change at page 46, line 45 skipping to change at page 49, line 41
received or wait for a preconfigured timer to do so. received or wait for a preconfigured timer to do so.
A source PE may use one of two approaches to decide when to start A source PE may use one of two approaches to decide when to start
transmitting data on the S-PMSI. In the first approach once the transmitting data on the S-PMSI. In the first approach once the
source PE instantiates the S-PMSI, it starts sending multicast source PE instantiates the S-PMSI, it starts sending multicast
packets for <C-S, C-G> entries mapped to the S-PMSI on both that as packets for <C-S, C-G> entries mapped to the S-PMSI on both that as
well as on the I-PMSI, which is currently used to send traffic for well as on the I-PMSI, which is currently used to send traffic for
the <C-S, C-G>. After some preconfigured timer the PE stops sending the <C-S, C-G>. After some preconfigured timer the PE stops sending
multicast packets for <C-S, C-G> on the I-PMSI. In the second multicast packets for <C-S, C-G> on the I-PMSI. In the second
approach after a certain pre-configured delay after advertising the approach after a certain pre-configured delay after advertising the
<C-S, C-G> entry bound to a S-PMSI, the source PE begins to send <C-S, C-G> entry bound to a S-PMSI, the source PE begins to send
traffic on the S-PMSI. At this point it stops to send traffic for the traffic on the S-PMSI. At this point it stops to send traffic for the
<C-S, C-G> on the I-PMSI. This traffic is instead transmitted on the <C-S, C-G> on the I-PMSI. This traffic is instead transmitted on the
S-PMSI. S-PMSI.
7.3. Aggregation 7.3. Aggregation
S-PMSIs can be aggregated on a P-multicast tree. The S-PMSI to C-(S, S-PMSIs can be aggregated on a P-multicast tree. The S-PMSI to C-(S,
G) binding advertisement supports aggregation. Furthermore the G) binding advertisement supports aggregation. Furthermore the
aggregation procedures of section 6.3 apply. It is also possible to aggregation procedures of section 6.3 apply. It is also possible to
aggregate both S-PMSIs and I-PMSIs on the same P-multicast tree. aggregate both S-PMSIs and I-PMSIs on the same P-multicast tree.
skipping to change at page 47, line 27 skipping to change at page 50, line 27
provide the procedures to be used when the S-PMSI is instantiated as provide the procedures to be used when the S-PMSI is instantiated as
a PIM tree. The PIM tree is created by the PIM P-instance. a PIM tree. The PIM tree is created by the PIM P-instance.
If a single PIM tree is being used to aggregate multiple S-PMSIs, If a single PIM tree is being used to aggregate multiple S-PMSIs,
then the PIM tree to which a given stream is bound may have already then the PIM tree to which a given stream is bound may have already
been joined by a given receiving PE. If the tree does not already been joined by a given receiving PE. If the tree does not already
exist, then the appropriate PIM procedures to create it must be exist, then the appropriate PIM procedures to create it must be
executed in the P-instance. executed in the P-instance.
If the S-PMSI for a particular multicast stream is instantiated as a If the S-PMSI for a particular multicast stream is instantiated as a
PIM-SM or PIM-Bidir tree, the S-PMSI identifier will specify the RP PIM-SM or BIDIR-PIM tree, the S-PMSI identifier will specify the RP
and the group P-address, and the PE routers which have receivers for and the group P-address, and the PE routers which have receivers for
that stream must build a shared tree toward the RP. that stream must build a shared tree toward the RP.
If the S-PMSI is instantiated as a PIM-SSM tree, the PE routers build If the S-PMSI is instantiated as a PIM-SSM tree, the PE routers build
a source tree toward the PE router that is advertising the S-PMSI a source tree toward the PE router that is advertising the S-PMSI
Join. The IP address root of the tree is the same as the source IP Join. The IP address root of the tree is the same as the source IP
address which appears in the S-PMSI Join. In this case, the tunnel address which appears in the S-PMSI Join. In this case, the tunnel
identifier in the S-PMSI Join will only need to specify a group P- identifier in the S-PMSI Join will only need to specify a group P-
address. address.
The above procedures assume that each PE router has a set of group The above procedures assume that each PE router has a set of group P-
P-addresses that it can use for setting up the PIM-trees. Each PE addresses that it can use for setting up the PIM-trees. Each PE must
must be configured with this set of P-addresses. If PIM-SSM is used be configured with this set of P-addresses. If PIM-SSM is used to
to set up the tunnels, then the PEs may be with overlapping sets of set up the tunnels, then the PEs may be with overlapping sets of
group P-addresses. If PIM-SSM is not used, then each PE must be group P-addresses. If PIM-SSM is not used, then each PE must be
configured with a unique set of group P-addresses (i.e., having no configured with a unique set of group P-addresses (i.e., having no
overlap with the set configured at any other PE router). The overlap with the set configured at any other PE router). The
management of this set of addresses is thus greatly simplified when management of this set of addresses is thus greatly simplified when
PIM-SSM is used, so the use of PIM-SSM is strongly recommended PIM-SSM is used, so the use of PIM-SSM is strongly recommended
whenever PIM trees are used to instantiate S-PMSIs. whenever PIM trees are used to instantiate S-PMSIs.
If it is known that all the PEs which need to receive data traffic on If it is known that all the PEs which need to receive data traffic on
a given S-PMSI can support aggregation of multiple S-PMSIs on a a given S-PMSI can support aggregation of multiple S-PMSIs on a
single PIM tree, then the transmitting PE, may, at its discretion, single PIM tree, then the transmitting PE, may, at its discretion,
decide to bind the S-PMSI to a PIM tree which is already bound to decide to bind the S-PMSI to a PIM tree which is already bound to one
one or more other S-PMSIs, from the same or from different MVPNs. In or more other S-PMSIs, from the same or from different MVPNs. In
this case, appropriate demultiplexing information must be signaled. this case, appropriate demultiplexing information must be signaled.
7.5. Instantiating S-PMSIs using RSVP-TE P2MP Tunnels 7.5. Instantiating S-PMSIs using RSVP-TE P2MP Tunnels
RSVP-TE P2MP Tunnels can be used for instantiating S-PMSIs. RSVP-TE P2MP Tunnels can be used for instantiating S-PMSIs.
Procedures described in the context of I-PMSIs in section 6.7 apply. Procedures described in the context of I-PMSIs in section 6.7 apply.
8. Inter-AS Procedures 8. Inter-AS Procedures
If an MVPN has sites in more than one AS, it requires one or more If an MVPN has sites in more than one AS, it requires one or more
skipping to change at page 49, line 11 skipping to change at page 52, line 11
point in the tunnel to the next, so all ASes through which the point in the tunnel to the next, so all ASes through which the
tunnel passes must support that technology. In essence, AS tunnel passes must support that technology. In essence, AS
boundaries are of no significance to a non-segmented inter-AS boundaries are of no significance to a non-segmented inter-AS
tunnel. tunnel.
[Editor's Note: This is the model in [ROSEN-8] and [MVPN- [Editor's Note: This is the model in [ROSEN-8] and [MVPN-
BASE].] BASE].]
Section 10 of [RFC4364] describes three different options for Section 10 of [RFC4364] describes three different options for
supporting unicast Inter-AS BGP/MPLS IP VPNs, known as options A, B, supporting unicast Inter-AS BGP/MPLS IP VPNs, known as options A, B,
and C. We describe below how both segmented and non-segmented and C. We describe below how both segmented and non-segmented inter-
inter-AS trees can be supported when option B or option C is used. AS trees can be supported when option B or option C is used. (Option
(Option A does not pass any routing information through an ASBR at A does not pass any routing information through an ASBR at all, so no
all, so no special inter-AS procedures are needed.) special inter-AS procedures are needed.)
8.1. Non-Segmented Inter-AS Tunnels 8.1. Non-Segmented Inter-AS Tunnels
In this model, the previously described discovery and tunnel setup In this model, the previously described discovery and tunnel setup
mechanisms are used, even though the PEs belonging to a given MVPN mechanisms are used, even though the PEs belonging to a given MVPN
may be in different ASes. The ASBRs play no special role, but may be in different ASes.
function merely as P routers.
8.1.1. Inter-AS MVPN Auto-Discovery 8.1.1. Inter-AS MVPN Auto-Discovery
The previously described BGP-based auto-discovery mechanisms work "as The previously described BGP-based auto-discovery mechanisms work "as
is" when an MVPN contains PEs that are in different Autonomous is" when an MVPN contains PEs that are in different Autonomous
Systems. Systems. However, please note that, if non-segmented Inter-AS
Tunnels are to be used, then the "Intra-AS" A-D routes MUST be
distributed across AS boundaries!
8.1.2. Inter-AS MVPN Routing Information Exchange 8.1.2. Inter-AS MVPN Routing Information Exchange
MVPN routing information exchange can be done by PIM peering (either When non-segmented inter-AS tunnels are used, MVPN C-multicast
lightweight or full) across an MI-PMSI, or by unicasting PIM routing information may be exchanged by means of PIM peering across
messages. The method of using BGP to send MVPN routing information an MI-PMSI, or by means of BGP carrying C-multicast routes.
can also be used.
If any form of PIM peering is used, a PE that sends C-PIM Join/Prune
messages for a particular C-(S,G) must be able to identify the PE
which is its PIM adjacency on the path to S. The identity of the PIM
adjacency is determined from the RPF information associated with the
VPN-IP route to S.
If no RPF information is present, then the identity of the PIM When PIM peering is used to distribute the C-multicast routing
adjacency is taken from the BGP Next Hop attribute of the VPN-IP information, a PE that sends C-PIM Join/Prune messages for a
route to S. Note that this will not give the correct result if particular C-(S,G) must be able to identify the PE which is its PIM
option b of section 10 of [RFC4364] is used. To avoid this adjacency on the path to S. This is the "selected upstream PE"
possibility of error, the RPF information SHOULD always be present if described in section 5.1.
MVPN routing information is to be distributed by PIM.
If BGP (rather than PIM) is used to distribute the MVPN routing If BGP (rather than PIM) is used to distribute the C-multicast
information, and if option b of section 10 of [RFC4364] is in use, routing information, and if option b of section 10 of [RFC4364] is in
then the MVPN routes will be installed in the ASBRs along the path use, then the C-multicast routes will be installed in the ASBRs along
from each multicast source in the MVPN to each multicast receiver in the path from each multicast source in the MVPN to each multicast
the MVPN. If option b is not in use, the MVPN routes are not receiver in the MVPN. If option b is not in use, the C-multicast
installed in the ASBRs. The handling of MVPN routes in either case routes are not installed in the ASBRs. The handling of the C-
is thus exactly analogous to the handling of unicast VPN-IP routes in multicast routes in either case is thus exactly analogous to the
the corresponding case. handling of unicast VPN-IP routes in the corresponding case.
8.1.3. Inter-AS I-PMSI 8.1.3. Inter-AS P-Tunnels
The procedures described earlier in this document can be used to The procedures described earlier in this document can be used to
instantiate an I-PMSI with inter-AS tunnels. Specific tunneling instantiate either an I-PMSI or an S-PMSI with inter-AS P-tunnels.
techniques require some explanation: Specific tunneling techniques require some explanation.
1. If ingress replication is used, the inter-AS PE-PE tunnels will If ingress replication is used, the inter-AS PE-PE tunnels will use
use the inter-AS tunneling procedures for the tunneling the inter-AS tunneling procedures for the tunneling technology used.
technology used.
2. Inter-AS PIM-SM or PIM-SSM based trees rely on a PE joining a Procedures in [RSVP-P2MP] are used for inter-AS RSVP-TE P2MP P-
(P-S, P-G) tuple where P-S is the address of a PE in another Tunnels.
AS. This (P-S, P-G) tuple is learned using the MVPN membership
and BGP MVPN-tunnel binding procedures described earlier.
However, if the source of the tree is in a different AS than a
particular P router, it is possible that the P router will not
have a route to the source. For example, the remote AS may be
using BGP to distribute a route to the source, but a particular
P router may be part of a "BGP-free core", in which the P
routers are not aware of BGP-distributed routes.
In such a case it is necessary for a PE to to tell PIM to Procedures for using PIM to set up the P-tunnels are discussed in
construct the tree through a particular BGP speaker, the "BGP the next section.
next hop" for the tree source. This can be accomplished with a
PIM extension, in which the P-PIM Join/Prune messages carry a
new "proxy" field which contains the address of that BGP next
hop. As the P-multicast tree is constructed, it is built
towards the proxy (the BGP next hop) rather than towards P-S,
so the P routers will not need to have a route to P-S.
Support for inter-AS trees using PIM-Bidir are for further 8.1.4. PIM-Based Inter-AS P-Multicast Trees
study.
When the BGP-based discovery procedures for MVPN are in place, When PIM is used to set up an inter-AS P-multicast tree, the PIM
one can distinguish two different inter-AS routes to a Join/Prune messages used to join the tree contain the IP address of
particular P-S: the upstream PE. However, there are two special considerations that
must be taken into account:
- BGP will install a unicast route to P-S along a particular - It is possible that the P routers within one or more of the ASes
path, using the IP AFI/SAFI ; will not have routes to the upstream PE. For example, if an AS
has a "BGP-free core", the P routers in an AS will not have
routes to addresses outside the AS.
- A PE's MVPN auto-discovery information is advertised by - If the PIM Join/Prune message must travel through several ASes,
sending a BGP update whose NLRI is in a special address it is possible that the ASBRs will not have routes to he PE
family (AFI/SAFI) used for this purpose. The NLRI of the routers. For example, in an inter-AS VPN constructed according
address family contains the IP address of the PE, as well to "option b" of section 10 of [RFC4364], the ASBRs do not
as an RD. If the NLRI contains the IP address of P-S, this necessarily have routes to the PE routers.
in effect creates a second route to P-S. This route might
follow a different path than the route in the unicast IP
family.
When building a PIM tree towards P-S, it may be desirable to If either of these two conditions obtains, then "ordinary" PIM
build it along the route on which the MVPN auto-discovery Join/Prune messages cannot be routed to the upstream PE. Thus the
AFI/SAFI is installed, rather than along the route on which the following information needs to be added to the PIM Join/Prune
IP AFI/SAFI is installed. This enables the inter-AS portion of messages: a "Proxy Address", which contains the address of the next
the tree to follow a path which is specifically chosen for ASBR on the path to the upstream PE. When the PIM Join/Prune arrives
multicast (i.e., it allows the inter-AS multicast topology to at the ASBR which is identified by the "proxy address", that ASBR
be "non-congruent" to the inter-AS unicast topology). must change the proxy address to identify the next hop ASBR.
In order for P routers to send P-Join/Prune messages along this This information allows the PIM Join/Prune to be routed through an AS
path, they need to make use of the "proxy" field extension even if the P routers of that AS do not have routes to the upstream
discussed above. The PIM message must also contain the full PE. However, this information is not sufficient to enable the ASBRs
NLRI in the MVPN auto-discovery family, so that the BGP to route the Join/Prune if the ASBRs themselves do not have routes to
speakers can look up that NLRI to find the BGP next hop. the upstream PE.
3. Procedures in [RSVP-P2MP] are used for inter-AS RSVP-TE P2MP However, even if the ASBRs do not have routes to the upstream PE, the
Tunnels. procedures of this draft ensure that they will have A-D routes that
lead to the upstream PE. If non-segmented inter-AS MVPNs are being
used, the ASBRs (and PEs) will have Intra-AS A-D routes which have
been distributed inter-AS.
8.1.4. Inter-AS S-PMSI So rather than having the PIM Join/Prune messages routed by the ASBRs
along a route to the upstream PE, the PIM Join/Prune messages MUST
be routed along the path determined by the intra-AS A-D routes.
The leaves of the tunnel are discovered using the MVPN routing If the only intra-AS A-D route for a given MVPN is the "Intra-AS I-
information. Procedures for setting up the tunnel are similar to the PMSI Route", the PIM Join/Prunes will be routed along that. However,
ones described in section 8.2.3 for an inter-AS I-PMSI. if the PIM Join/Prune message is for a particular P-group address,
and there is an "Intra-AS S-PMSI Route" specifying that particular P-
group address as the P-tunnel for a particular S-PMSI, then the PIM
Join/Prunes MUST be routed along the path determined by those intra-
AS A-D routes.
The next revision of this document will provide the following
details:
- encoding of the proxy address in the PIM message (the PIM Join
Attribute [PIM-ATTRIB] will be used)
- encoding of any other information which may be needed in order to
enable the correct intra-AS route to be chosen.
Support for non-segmented inter-AS trees using BIDIR-PIM is for
further study.
8.2. Segmented Inter-AS Tunnels 8.2. Segmented Inter-AS Tunnels
8.2.1. Inter-AS MVPN Auto-Discovery Routes 8.2.1. Inter-AS MVPN Auto-Discovery Routes
The BGP based MVPN membership discovery procedures of section 4 are The BGP based MVPN membership discovery procedures of section 4 are
used to auto-discover the intra-AS MVPN membership. This section used to auto-discover the intra-AS MVPN membership. This section
describes the additional procedures for inter-AS MVPN membership describes the additional procedures for inter-AS MVPN membership
discovery. It also describes the procedures for constructing discovery. It also describes the procedures for constructing
segmented inter-AS tunnels. segmented inter-AS tunnels.
skipping to change at page 52, line 28 skipping to change at page 55, line 25
8.2.1.1. Originating Inter-AS MVPN A-D Information 8.2.1.1. Originating Inter-AS MVPN A-D Information
A PE in a given AS advertises its MVPN membership to all its IBGP A PE in a given AS advertises its MVPN membership to all its IBGP
peers. This IBGP peer may be a route reflector which in turn peers. This IBGP peer may be a route reflector which in turn
advertises this information to only its IBGP peers. In this manner advertises this information to only its IBGP peers. In this manner
all the PEs and ASBRs in the AS learn this membership information. all the PEs and ASBRs in the AS learn this membership information.
An Autonomous System Border Router (ASBR) may be configured to An Autonomous System Border Router (ASBR) may be configured to
support a particular MVPN. If an ASBR is configured to support a support a particular MVPN. If an ASBR is configured to support a
particular MVPN, the ASBR MUST participate in the intra-AS MVPN particular MVPN, the ASBR MUST participate in the intra-AS MVPN auto-
auto-discovery/binding procedures for that MVPN within the AS that discovery/binding procedures for that MVPN within the AS that the
the ASBR belongs to, as defined in this document. ASBR belongs to, as defined in this document.
Each ASBR then advertises the "AS MVPN membership" to its neighbor Each ASBR then advertises the "AS MVPN membership" to its neighbor
ASBRs using EBGP. This inter-AS auto-discovery route must not be ASBRs using EBGP. This inter-AS auto-discovery route must not be
advertised to the PEs/ASBRs in the same AS as this ASBR. The advertised to the PEs/ASBRs in the same AS as this ASBR. The
advertisement carries the following information elements: advertisement carries the following information elements:
a. A Route Distinguisher for the MVPN. For a given MVPN each ASBR a. A Route Distinguisher for the MVPN. For a given MVPN each ASBR
in the AS must use the same RD when advertising this in the AS must use the same RD when advertising this
information to other ASBRs. To accomplish this all the ASBRs information to other ASBRs. To accomplish this all the ASBRs
within that AS, that are configured to support the MVPN, MUST within that AS, that are configured to support the MVPN, MUST
skipping to change at page 58, line 34 skipping to change at page 61, line 23
PE. When it reaches an ASBR that is on the spanning tree, it is PE. When it reaches an ASBR that is on the spanning tree, it is
delivered to local receivers, if any, and is also forwarded to the delivered to local receivers, if any, and is also forwarded to the
neighbor ASBR after being encapsulated in the label advertised by the neighbor ASBR after being encapsulated in the label advertised by the
neighbor. The neighbor ASBR either transports this packet on the S- neighbor. The neighbor ASBR either transports this packet on the S-
PMSI for the multicast stream or an I-PMSI, delivering it to the PMSI for the multicast stream or an I-PMSI, delivering it to the
ASBRs in its own AS. These ASBRs in turn repeat the procedures of the ASBRs in its own AS. These ASBRs in turn repeat the procedures of the
origin AS ASBRs and the multicast packet traverses the spanning tree. origin AS ASBRs and the multicast packet traverses the spanning tree.
9. Duplicate Packet Detection and Single Forwarder PE 9. Duplicate Packet Detection and Single Forwarder PE
An egress PE may receive duplicate multicast data packets, from more Consider the case of an egress PE that receives packets of a customer
than one ingress PE, for a MVPN when a a site that contains C-S or multicast stream (C-S, C-G) over a non-aggregated S-PMSI. The
C-RP is multihomed to more than one PE. An egress PE may also receive procedures described so far will never cause the PE to receive
duplicate data packets for a MVPN, from two different ingress PEs, duplicate copies of any packet in that stream. It is possible that
when the CE-PE routing protocol is PIM-SM and a router or a CE in a the (C-S, C-G) stream is carried in more than one S-PMSI; this may
site switches from the C-RP tree to C-S tree. happen when the site that contains C-S is multihomed to more than one
PE. However, a PE that needs to receive (C-S, C-G) packets only
joins one of these S-PMSIs, and so only receives one copy of each
packet.
For a given <C-S, C-G> a PE, say PE1, expects to receive C-data However, if the data packets of stream (C-S, C-G) are carried in
packets from the upstream PE, say PE2, which PE1 identified as the either an I-PMSI or in an aggregated S-PMSI, then it the procedures
upstream multicast hop in the C-Multicast Routing Update that PE1 specified so far make it possible for an egress PE to receive more
sent in order to join <C-S, C-G>. If PE1 can determine that a data than one copy of each data packet. In this section, we define
packet for <C-S, C-G> was received from the expected upstream PE, additional procedures to that an MVPN customer sees no multicast data
PE2, PE1 will accept the packet. Otherwise, PE1 will drop the packet duplication.
packet. (But see section 10 for an exception case where PE1 will
accept a packet even if it is from an unexpected upstream PE.) This
determination can be performed only if the PMSI on which the packets
are being received and the tunneling technology used to instantiate
the PMSI allows the PE to determine the source PE that sent the
packet. However this determination may not always be possible.
Therefore, procedures are needed to ensure that packets are received This section covers the situation where the customer multicast tree
at a PE only from a single upstream PE. This is called single is unidirectional, i.e. with the C-G is either a "Sparse Mode" or a
forwarder PE selection. "Single Source Mode" group. The case where the customer multicast
tree is bidirectional (the C-G is a BIDIR-PIM group) is considered
separately in section 12.
Single forwarder PE selection is achieved by the following set of The first case when an egress PE may receive duplicate multicast data
procedures: packets, is the case where both (a) an MVPN site that contains C-S or
C-RP is multihomed to more than one PE, and (b) either an I-PMSI, or
an aggregated S-PMSI is used for carrying the packets originated by
C-S. In this case, an egress PE may receive one copy of the packet
from each PE to which the site is homed.
a. If there is more than one PE within the same AS through which The second case when an egress PE may receive duplicate multicast
C-S or C-RP of a given MVPN could be reached, and in the case data packets is when all of the following is true: (a) the IP
of C-S not every such PE advertises an S-PMSI for <C-S, C-G>, destination address of the customer packet is a C-G that is operating
all PEs that have this MVPN MUST send the MVPN routing in ASM mode, and whose C-multicast tree is set up using PIM-SM, (b)
information update for <C-S, C-G> or <C-*, C-G> to the same an MI-PMSI is used for carrying the packets, and (c) a router or a CE
upstream PE. This is achieved using the following procedure: in a site connected to the egress PE switches from the C-RP tree to
C-S tree. In this case, it is possible to get one copy of a given
packet from the ingress PE attached to the C-RP's site, and one from
the ingress PE attached to the C-S's site.
Using the procedure for "RPF determination" specified in 9.1. Multihomed C-S or C-RP
section 5.1, find (a) the upstream multicast hop for the C-S or
C-RP, and (b) the route used to reach the upstream multicast
hop. Call this route the "installed RPF route" for C-S or C-
RP.
If the next-hop interface of the installed RPF route for C-S or In the first case for a given <C-S, C-G> an egress PE, say PE1,
C-RP is a VRF interface of the PE, then the PE uses that route expects to receive C-data packets from the upstream PE, say PE2,
to reach the C-S or C-RP. which PE1 identified as the upstream multicast hop in the C-Multicast
Routing Update that PE1 sent in order to join <C-S, C-G>. If PE1 can
determine that a data packet for <C-S, C-G> was received from the
expected upstream PE, PE2, PE1 will accept and forward the packet.
Otherwise, PE1 will drop the packet; this means that the PE will see
a duplicate, but the duplicate will not get forwarded. (But see
section 10 for an exception case where PE1 will accept a packet even
if it is from an unexpected upstream PE.)
Otherwise, consider the set of all VPN-IP routes that are (a) The method used by an egress PE to determine the ingress PE for a
eligible to be imported into the VRF (as determined by their particular packet, received over a particular PMSI, depends on the P-
Route Targets), (b) are eligible to be used for RPF tunnel technology that is used to instantiate the PMSI. If the P-
determination (i.e., if RPF determination is done via a non- tunnel is a P2MP LSP, a PIM-SM or PIM-SSM tree, or a unicast tunnel,
congruent multicast topology, this would include only the then the tunnel encapsulation contains information which can be used
routes that are part of that topology), and (c) have exactly (possibly along with other state information in the PE) to determine
the same IP prefix as the installed RPF route. the ingress PE, as long as the P-tunnel is instantiating an intra-AS
PMSI, or an inter-AS PMSI which is supported by a non-segmented
inter-AS tunnel.
For each route in this set, determine the corresponding Even when inter-AS segmented tunnels are used, if a UI-PMSI or an
upstream PE. If a route has a VRF Route Import Extended aggregated S-PMSI is used for carrying the packets, the P-tunnel
Community, the route's upstream PE is determined from it. If a encapsulation must have some information which can be used to
route does not have a VRF Route Import Extended Community, the identify the PMSI, and that in turn implicitly identifies the ingress
route's upstream PE is determined from the route's BGP next hop PE.
attribute.
This results in a set of pairs of <route, upstream PE>. The PE If an MI-PMSI is used for carrying the packets, the MI-PMSI spans
will select the route whose corresponding upstream PE address multiple ASes, and the MI-PMSI is realized via segmented inter-AS
is numerically highest, where a 32-bit IP address is treated as tunnels, if C-S or C-RP is multi-homed to different PEs, as long as
a 32-bit unsigned integer. Call this the "selected RPF route". each such PE is in a different AS, the egress PE can detect duplicate
The PE will use the selected RPF route to reach the C-S or C- traffic as such duplicate traffic will arrive on a different (inter-
RP. AS) tunnel. Specifically, if the PE was expecting the traffic on an
particular inter-AS tunnel, duplicate traffic will arrive either on
an intra-AS tunnel [this is not an intra-AS tunnel segment, of an
inter-AS tunnel], or on some other inter-AS tunnel. Therefore, to
detect duplicates the PE has to keep track of which (inter-AS) auto-
discovery route the PE uses for sending MVPN multicast routing
information towards C-S/C-RP. Then the PE should receive (multicast)
traffic originated by C-S/C-RP only from the (inter-AS) tunnel that
was carried in the best Inter-AS auto-discovery route for the MVPN
and was originated by the AS that contains C-S/C-RP (where "the best"
is determined by the PE). The PE should discard, as duplicated, all
other multicast traffic originated by C-S/C-RP, but received on any
other tunnel.
b. The above procedure ensures that if C-S or C-RP is multi-homed 9.1.1. Single forwarder PE selection
to PEs within a single AS, a PE will not receive duplicate
traffic as long as all the PEs in that AS are on either the C-S
or C-RP tree.
However the PE may receive duplicate traffic if C-S or C-RP is When for a given MVPN (a) MI-PMSI is used for carrying multicast data
multi-homed to different ASes. In this case the PE can detect packets, (b) C-S or C-RP is multi-homed to different PEs, and (c) at
duplicate traffic as such duplicate traffic will arrive on a least two of such PEs are in the same AS, then depending on the
different tunnel - if the PE was expecting the traffic on an tunneling technology used by the MI-PMSI it may not always be
inter-AS tunnel, duplicate traffic will arrive on an intra-AS possible for the egress PE to determine the upstream PE. Therefore,
tunnel [this is not an intra-AS tunnel segment, of an inter-AS when this determination may not be possible procedures are needed to
tunnel] and vice-versa. ensure that packets are received on an MI-PMSI at an egress PE only
from a single upstream PE. Furthermore, even if the determination is
possible, it may be preferable to send only one copy of each packet
to each egress PE, rather than sending multiple copies and having the
egress PE discard all but one.
To achieve the above the PE has to keep track of which (inter- Section 5.1 specifies a procedure for choosing a "default upstream PE
AS) auto-discovery route the PE uses for sending MVPN multicast selection", such that (except during routing transients) all PEs will
routing information towards C-S/C-RP. Then the PE should choose the same default upstream PE. To ensure that duplicate
receive (multicast) traffic originated by C-S/C-RP only from packets are not sent through the backbone (except during routing
the (inter-AS) tunnel that was carried in the best source transients), an ingress PE does not forward to the backbone any (C-S,
auto-discovery route for the MVPN and was originated by the AS C-G) multicast data packet it receives from a CE, unless the PE is
that contains C-S/C-RP (where "the best" is determined by the the default upstream PE selection.
PE). All other multicast traffic originated by C-S/C-RP, but
received on any other tunnel should be discarded as duplicated.
The PE may also receive duplicate traffic during a <C-*, C-G> This procedure is optional whenever the P-tunnel technology that is
to <C-S, C-G> switch. The issue and the solution are described being used to carry the multicast stream in question allows the
next. egress PEs to determine the identity of the ingress PE. This
procedure is mandatory if the P-tunnel technology does not make this
determination possible.
c. If the tunneling technology in use for a particular MVPN does The above procedure ensures that if C-S or C-RP is multi-homed to PEs
not allow the egress PEs to identify the ingress PE, then within a single AS, a PE will not receive duplicate traffic as long
having all the PEs select the same PE to be the upstream as all the PEs are on either the C-S or C-RP tree. If some PEs are on
multicast hop is not sufficient to prevent packet duplication. the C-S tree and some on the C-RP tree, however, packet duplication
The reason is that a single tunnel may be carrying traffic on is still possible. This is discussed in the next section.
both the (C-*, C-G) tree and the (C-S, C-G) tree. If some of
the egress PEs have joined the source tree, but others expect
to receive (S,G) packets from the shared tree, then two copies
of data packet will travel on the tunnel, and the egress PEs
will have no way to determine that only one copy should be
accepted.
To avoid this, it is necessary to ensure that once any PE joins 9.2. Switching from the C-RP tree to C-S tree
the (C-S, C-G) tree, any other PE that has joined the (C-*, C-
G) tree also switches to the (C-S, C-G) tree (selecting, of
course, the same upstream multicast hop, as specified above).
Whenever a PE creates an <C-S,C-G> state as a result of If some PEs are on the C-S tree and some on the R-RP tree then a PE
receiving a C-multicast route for <C-S, C-G> from some other may also receive duplicate traffic during a <C-*, C-G> to <C-S, C-G>
PE, and the C-G group is a Sparse Mode group, the PE that switch. The issue and the solution are described next.
creates the state MUST originate an auto-discovery route as
specified below. The route is being advertised using the same
procedures as the MVPN auto-discovery/binding (both intra-AS
and inter-AS) specified in this document with the following
modifications:
1. The Multicast Source field MUST be set to C-S. The When for a given MVPN (a) MI-PMSI is used for carrying multicast data
Multicast Source Length field is set appropriately to packets, (b) C-S and C-RP are connected to PEs within the same AS,
reflect this. and (c) the MI-PMSI tunneling technology in use does not allow the
egress PEs to identify the ingress PE, then having all the PEs select
the same PE to be the upstream multicast hop for C-S or C-RP is not
sufficient to prevent packet duplication.
2. The Multicast Group field MUST be set to C-G. The The reason is that a single tunnel used by MI-PMSI may be carrying
Multicast Group Length field is set appropriately to traffic on both the (C-*, C-G) tree and the (C-S, C-G) tree. If some
reflect this. of the egress PEs have joined the source tree, but others expect to
receive (C-S, C-G) packets from the shared tree, then two copies of
data packet will travel on the tunnel, and since due to the choice of
the tunneling technology the egress PEs have no way to identify the
ingress PE, the egress PEs will have no way to determine that only
one copy should be accepted.
The route goes to all the PEs of the MVPN. When a PE receives To avoid this, it is necessary to ensure that once any PE joins the
this route, it checks whether there are any receivers in the (C-S, C-G) tree, any other PE that has joined the (C-*, C- G) tree
MVPN sites attached to the PE for the group carried in the also switches to the (C-S, C-G) tree (selecting, of course, the same
route. If yes, then it generates a C-multicast route indicating upstream multicast hop, as specified above).
Join for <C-S, C-G>. This forces all the PEs (in all ASes) to
switch to the C-S tree for <C-S, C-G> from the C-RP tree.
This is the same type of A-D route used to report active Whenever a PE creates an <C-S, C-G> state as a result of receiving a
sources in the scenarios described in section 10. C-multicast route for <C-S, C-G> from some other PE, and the C-G
group is a Sparse Mode group, the PE that creates the state MUST
originate an auto-discovery route as specified below. The route is
being advertised using the same procedures as the MVPN auto-
discovery/binding (both intra-AS and inter-AS) specified in this
document with the following modifications:
Note that when a PE thus joins the <C-S, C-G> tree, it may need 1. The Multicast Source field MUST be set to C-S. The Multicast
to send a PIM (S,G,RPT-bit) prune to one of its CE PIM Source Length field is set appropriately to reflect this.
neighbors, as determined by ordinary PIM procedures..
Whenever the PE deletes the <C-S, C-G> state that was 2. The Multicast Group field MUST be set to C-G. The Multicast
previously created as a result of receiving a C-multicast route Group Length field is set appropriately to reflect this.
for <C-S, C-G> from some other PE, the PE that deletes the
state also withdraws the auto-discovery route that was
advertised when the state was created.
N.B.: SINCE ALL PES WITH RECEIVERS FOR GROUP C-G WILL JOIN THE The route goes to all the PEs of the MVPN. When a PE receives this
C-S SOURCE TREE IF ANY OF THEM DO, IT IS NEVER NECESSARY TO route, it checks whether there are any receivers in the MVPN sites
DISTRIBUTE A BGP C-MULTICAST ROUTE FOR THE PURPOSE OF PRUNING attached to the PE for the group carried in the route. If yes, then
SOURCES FROM THE SHARED TREE. it generates a C-multicast route indicating Join for <C-S, C-G>.
In summary when the CE-PE routing protocol for all PEs that belong to This forces all the PEs (in all ASes) to switch to the C-S tree for
a MVPN is not PIM-SM, selection of a consistent upstream PE to reach <C-S, C-G> from the C-RP tree.
C-S is sufficient to eliminate duplicates when C-S is multi-homed to
a single AS. When C-S is multi-homed to multiple ASes, duplicate
packet detection can be performed as the receiver PE can always
determine whether packets arrived on the wrong tunnel. When the CE-PE
routing protocol is PIM-SM, additional procedures as described above
are required to force all PEs within all ASes to switch to the C-S
tree from the C-RP tree when any PE switches to the C-S tree.
10. Deployment Models This is the same type of A-D route used to report active sources in
the scenarios described in section 10.
This section describes some optional deployment models and specific Note that when a PE thus joins the <C-S, C-G> tree, it may need to
procedures for those deployment models. send a PIM (S,G,RPT-bit) prune to one of its CE PIM neighbors, as
determined by ordinary PIM procedures. Whenever the PE deletes the
<C-S, C-G> state that was previousely created as a result of
receiving a C-multicast route for <C-S, C-G> from some other PE, the
PE that deletes the state also withdraws the auto-discovery route
that was advertised when the state was created.
N.B.: SINCE ALL PEs WITH RECEIVERS FOR GROUP C-G WILL JOIN THE C-S
SOURCE TREE IF ANY OF THEM DO, IT IS NEVER NECESSARY TO DISTRIBUTE A
BGP C-MULTICAST ROUTE FOR THE PURPOSE OF PRUNING SOURCES FROM THE
SHARED TREE.
10. Eliminating PE-PE Distribution of (C-*,C-G) State
In sparse mode PIM, a node that wants to become a receiver for a
particular multicast group G first joins a shared tree, rooted at a
rendezvous point. When the receiver detects traffic from a
particular source it has the option of joining a source tree, rooted
at that source. If it does so, it has to prune that source from the
shared tree, to ensure that it receives packets from that source on
only one tree.
Maintaining the shared tree can require considerable state, as it is
necessary not only to know who the upstream and downstream nodes are,
but to know which sources have been pruned off which branches of the
share tree.
The BGP-based signaling procedures defined in this document and in
[MVPN-BGP] eliminate the need for PEs to distribute to each other any
state having to do with which sources have been pruned off a shared
C-tree. Those procedures do still allow multicast data traffic to
travel on a shared C-tree, but they do not allow a situation in which
some CEs receive (S,G) traffic on a shared tree and some on a source
tree. This results in a considerable simplification of the PE-PE
procedures with minimal change to the multicast service seen within
the VPN. However, shared C-trees are still supported across the VPN
backbone. That is, (C-*, C-G) state is distributed PE-PE, but (C-*,
C-G, RPT-bit) state is not.
In this section, we specify a number of optional procedures which go
further, and which completely eliminate the support for shared C-
trees across the VPN backbone. In these procedures, the PEs keep
track of the active sources for each C-G. As soon as a CE tries to
join the (*,G) tree, the PEs instead join the (S,G) trees for all the
active sources. Thus all distribution of (C-*,C-G) state is
eliminated. These procedures are optional because they require some
additional support on the part of the VPN customer, and because they
are not always appropriate. (E.g., a VPN customer may have his own
policy of always using shared trees for certain multicast groups.)
There are several different options, described in the following sub-
sections.
10.1. Co-locating C-RPs on a PE 10.1. Co-locating C-RPs on a PE
[MVPN-REQ] describes C-RP engineering as an issue when PIM-SM (or [MVPN-REQ] describes C-RP engineering as an issue when PIM-SM (or
bidir-PIM) is used in ASM mode on the VPN customer site. To quote BIDIR-PIM) is used in "Any Source Multicast (ASM) mode" [RFC4607] on
from [MVPN-REQ]: the VPN customer site. To quote from [MVPN-REQ]:
"In some cases this engineering problem is not trivial: for instance, "In some cases this engineering problem is not trivial: for instance,
if sources and receivers are located in VPN sites that are different if sources and receivers are located in VPN sites that are different
than that of the RP, then traffic may flow twice through the SP than that of the RP, then traffic may flow twice through the SP
network and the CE-PE link of the RP (from source to RP, and then network and the CE-PE link of the RP (from source to RP, and then
from RP to receivers) ; this is obviously not ideal. A multicast VPN from RP to receivers) ; this is obviously not ideal. A multicast VPN
solution SHOULD propose a way to help on solving this RP engineering solution SHOULD propose a way to help on solving this RP engineering
issue." issue."
One of the C-RP deployment models is for the customer to outsource One of the C-RP deployment models is for the customer to outsource
the RP to the provider. In this case the provider may co-locate the the RP to the provider. In this case the provider may co-locate the
RP on the PE that is connected to the customer site [MVPN-REQ]. This RP on the PE that is connected to the customer site [MVPN-REQ]. This
model is introduced in [RP-MVPN]. This section describes how model is introduced in [RP-MVPN]. This section describes how anycast-
anycast-RP can be used for achieving this by advertising active RP can be used for achieving this by advertising active sources. This
sources. This is described below. is described below.
10.1.1. Initial Configuration 10.1.1. Initial Configuration
For a particular MVPN, at least one or more PEs that have sites in For a particular MVPN, at least one or more PEs that have sites in
that MVPN, act as an RP for the sites of that MVPN connected to these that MVPN, act as an RP for the sites of that MVPN connected to these
PEs. Within each MVPN all these RPs use the same (anycast) address. PEs. Within each MVPN all these RPs use the same (anycast) address.
All these RPs use the Anycast RP technique. All these RPs use the Anycast RP technique.
10.1.2. Anycast RP Based on Propagating Active Sources 10.1.2. Anycast RP Based on Propagating Active Sources
skipping to change at page 65, line 47 skipping to change at page 70, line 23
++=============++ ++=============++ ++=============++ ++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header || || C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++ ++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload || || C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++ ++=============++ ++=============++ ++=============++
The IP Protocol Number field in the P-IP Header must be set to 47. The IP Protocol Number field in the P-IP Header must be set to 47.
The Protocol Type field of the GRE Header must be set to 0x800. The Protocol Type field of the GRE Header must be set to 0x800.
When an encapsulated packet is transmitted by a particular PE, the When an encapsulated packet is transmitted by a particular PE, the
source IP address in the P-IP header must be the same address as is source IP address in the P-IP header must be the same address that
advertised by that PE in the RPF information. the PE uses to identify itself in the VRF Route Import Extended
Communities that it attaches to any of VPN-IP routes eligible for UMH
determination that it advertises via BGP (see section 5.1).
If the PMSI is instantiated by a PIM tree, the destination IP address If the PMSI is instantiated by a PIM tree, the destination IP address
in the P-IP header is the group P-address associated with that tree. in the P-IP header is the group P-address associated with that tree.
The GRE key field value is omitted. The GRE key field value is omitted.
If the PMSI is instantiated by unicast tunnels, the destination IP If the PMSI is instantiated by unicast tunnels, the destination IP
address is the address of the destination PE, and the optional GRE address is the address of the destination PE, and the optional GRE
Key field is used to identify a particular MVPN. In this case, each Key field is used to identify a particular MVPN. In this case, each
PE would have to advertise a key field value for each MVPN; each PE PE would have to advertise a key field value for each MVPN; each PE
would assign the key field value that it expects to receive. would assign the key field value that it expects to receive.
skipping to change at page 67, line 17 skipping to change at page 71, line 24
provider network provider network
+---------------+ +---------------+
| P-IP Header | | P-IP Header |
++=============++ ++=============++ ++=============++ ++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header || || C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++ ++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload || || C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++ ++=============++ ++=============++ ++=============++
When an encapsulated packet is transmitted by a particular PE, the
source IP address in the P-IP header must be the same address that
the PE uses to identify itself in the VRF Route Import Extended
Communities that it attaches to any of VPN-IP routes eligible for UMH
determination that it advertises via BGP (see section 5.1).
11.1.3. Encapsulation in MPLS 11.1.3. Encapsulation in MPLS
If the PMSI is instantiated as a P2MP MPLS LSP, MPLS encapsulation is If the PMSI is instantiated as a P2MP MPLS LSP, MPLS encapsulation is
used. Penultimate-hop-popping must be disabled for the P2MP MPLS LSP. used. Penultimate-hop-popping must be disabled for the P2MP MPLS LSP.
If the PMSI is instantiated as an RSVP-TE P2MP LSP, additional MPLS If the PMSI is instantiated as an RSVP-TE P2MP LSP, additional MPLS
encapsulation procedures are used, as specified in [RSVP-P2MP]. encapsulation procedures are used, as specified in [RSVP-P2MP].
If other methods of assigning MPLS labels to multicast distribution If other methods of assigning MPLS labels to multicast distribution
trees are in use, these multicast distribution trees may be used as trees are in use, these multicast distribution trees may be used as
appropriate to instantiate PMSIs, and any additional MPLS appropriate to instantiate PMSIs, and any additional MPLS
skipping to change at page 68, line 33 skipping to change at page 73, line 5
[MPLS-MCAST-ENCAPS]. [MPLS-MCAST-ENCAPS].
11.2.2. Encapsulation in IP 11.2.2. Encapsulation in IP
Rather than the IP-in-IP encapsulation discussed in section 12.1.2, Rather than the IP-in-IP encapsulation discussed in section 12.1.2,
we use the MPLS-in-IP encapsulation. This is specified in [MPLS-IP]. we use the MPLS-in-IP encapsulation. This is specified in [MPLS-IP].
The IP protocol number MUST be set to the value identifying the The IP protocol number MUST be set to the value identifying the
payload as an MPLS unicast packet. [There is no "MPLS multicast payload as an MPLS unicast packet. [There is no "MPLS multicast
packet" protocol number.] packet" protocol number.]
11.3. Encapsulations for Unicasting PIM Control Messages 11.3. Encapsulations Identifying a Distinguished PE
11.3.1. For MP2MP LSP P-tunnels
As discussed in section 9, if a multicast data packet belongs to a
Sparse Mode or Single Source Mode multicast group, it is highly
desirable for the PE that receives the packet from a PMSI to be able
to determine the identity of the PE that transmitted the data packet
onto the PMSI. The encapsulations of the previous sections all
provide this information, except in one case. If a PMSI is being
instantiated by a MP2MP LSP, then the encapsulations discussed so far
do not allow one to determine the identity of the PE that transmitted
the packet onto the PMSI.
Therefore, when a packet that belongs to a Sparse Mode or Single
Source Mode multicast group is traveling on a MP2MP LSP P-tunnel, it
MUST carry, as its second label, a label which has been bound to the
packet's ingress PE. This label is an upstream-assigned label that
the LSP's root node has bound to the ingress PE and has distributed
via an A-D Route (see section 4; precise details of this distribution
procedure will be included in the next revision of this document).
This label will appear immediately beneath the labels that are
discussed in sections 11.1.3 and 11.2.
11.3.2. For Support of PIM-BIDIR C-Groups
As will be discussed in section 12, when a packet belongs to a PIM-
BIDIR multicast group, the set of PEs of that packet's VPN can be
partitioned into a number of subsets, where exactly one PE in each
partition is the upstream PE for that partition. When such packets
are transmitted on a PMSI, then unless the procedures of section
12.2.3 are being used, it is necessary for the packet to carry
information identifying a particular partition. This is done by
having the packet carry the PE label corresponding to the upstream PE
of one partition. For a particular P-tunnel, this label will have
been advertised by the node which is the root of that P-tunnel.
(Details of the procedure by which the PE labels are advertised will
be included in the next revision of this document.)
This label needs to be used whenever a packet belongs to a PIM-BIDIR
C-group, no matter what encapsulation is used by the P-tunnel. Hence
the encapsulations of section 11.2 MUST be used. If the tunnel
contains only one PMSI, the PE label replaces the label discussed in
section 11.2 If the tunnel contains multiple PMSIs, the PE label
follows the label discussed in section 11.2
11.4. Encapsulations for Unicasting PIM Control Messages
When PIM control messages are unicast, rather than being sent on an When PIM control messages are unicast, rather than being sent on an
MI-PMSI, the the receiving PE needs to determine the particular MVPN MI-PMSI, the the receiving PE needs to determine the particular MVPN
whose multicast routing information is being carried in the PIM whose multicast routing information is being carried in the PIM
message. One method is to use a downstream-assigned MPLS label which message. One method is to use a downstream-assigned MPLS label which
the receiving PE has allocated for this specific purpose. The label the receiving PE has allocated for this specific purpose. The label
would be distributed via BGP. This can be used with an MPLS, MPLS- would be distributed via BGP. This can be used with an MPLS, MPLS-
in-GRE, or MPLS-in-IP encapsulation. in-GRE, or MPLS-in-IP encapsulation.
A possible alternative to modify the PIM messages themselves so that A possible alternative to modify the PIM messages themselves so that
they carry information which can be used to identify a particular they carry information which can be used to identify a particular
MVPN, such as an RT. MVPN, such as an RT.
This area is still under consideration. This area is still under consideration.
11.4. General Considerations for IP and GRE Encaps 11.5. General Considerations for IP and GRE Encaps
These apply also to the MPLS-in-IP and MPLS-in-GRE encapsulations. These apply also to the MPLS-in-IP and MPLS-in-GRE encapsulations.
11.4.1. MTU 11.5.1. MTU
It is the responsibility of the originator of a C-packet to ensure It is the responsibility of the originator of a C-packet to ensure
that the packet small enough to reach all of its destinations, even that the packet small enough to reach all of its destinations, even
when it is encapsulated within IP or GRE. when it is encapsulated within IP or GRE.
When a packet is encapsulated in IP or GRE, the router that does the When a packet is encapsulated in IP or GRE, the router that does the
encapsulation MUST set the DF bit in the outer header. This ensures encapsulation MUST set the DF bit in the outer header. This ensures
that the decapsulating router will not need to reassemble the that the decapsulating router will not need to reassemble the
encapsulating packets before performing decapsulation. encapsulating packets before performing decapsulation.
skipping to change at page 69, line 44 skipping to change at page 75, line 14
If the router discards a packet as too large, it should maintain OAM If the router discards a packet as too large, it should maintain OAM
information related to this behavior, allowing the operator to information related to this behavior, allowing the operator to
properly troubleshoot the issue. properly troubleshoot the issue.
Note that if the entire path of the tunnel does not support an MTU Note that if the entire path of the tunnel does not support an MTU
which is large enough to carry the a particular encapsulated C- which is large enough to carry the a particular encapsulated C-
packet, and if the encapsulating router does not do fragmentation, packet, and if the encapsulating router does not do fragmentation,
then the customer will not receive the expected connectivity. then the customer will not receive the expected connectivity.
11.4.2. TTL 11.5.2. TTL
The ingress PE should not copy the TTL field from the payload IP The ingress PE should not copy the TTL field from the payload IP
header received from a CE router to the delivery IP or MPLS header. header received from a CE router to the delivery IP or MPLS header.
The setting of the TTL of the delivery header is determined by the The setting of the TTL of the delivery header is determined by the
local policy of the ingress PE router. local policy of the ingress PE router.
11.4.3. Differentiated Services 11.5.3. Differentiated Services
The setting of the DS field in the delivery IP header should follow The setting of the DS field in the delivery IP header should follow
the guidelines outlined in [RFC2983]. Setting the EXP field in the the guidelines outlined in [RFC2983]. Setting the EXP field in the
delivery MPLS header should follow the guidelines in [RFC3270]. An SP delivery MPLS header should follow the guidelines in [RFC3270]. An SP
may also choose to deploy any of the additional mechanisms the PE may also choose to deploy any of the additional mechanisms the PE
routers support. routers support.
11.4.4. Avoiding Conflict with Internet Multicast 11.5.4. Avoiding Conflict with Internet Multicast
If the SP is providing Internet multicast, distinct from its VPN If the SP is providing Internet multicast, distinct from its VPN
multicast services, and using PIM based P-multicast trees, it must multicast services, and using PIM based P-multicast trees, it must
ensure that the group P-addresses which it used in support of MPVN ensure that the group P-addresses which it used in support of MPVN
services are distinct from any of the group addresses of the Internet services are distinct from any of the group addresses of the Internet
multicasts it supports. This is best done by using administratively multicasts it supports. This is best done by using administratively
scoped addresses [ADMIN-ADDR]. scoped addresses [ADMIN-ADDR].
The group C-addresses need not be distinct from either the group P- The group C-addresses need not be distinct from either the group P-
addresses or the Internet multicast addresses. addresses or the Internet multicast addresses.
12. Security Considerations 12. Support for PIM-BIDIR C-Groups
In BIDIR-PIM, each multicast group is associated with an RPA
(Rendezvous Point Address). The Rendezvous Point Link (RPL) is the
link that attaches to the RPA. Usually it's a LAN where the RPA is
in the IP subnet assigned to the LAN. The root node of a BIDIR-PIM
tree is a node which has an interface on the RPL.
On any LAN (other than the RPL) which is a link in a PIM-bidir tree,
there must be a single node that has been chosen to be the DF. (More
precisely, for each RPA there is a single node which is the DF for
that RPA.) A node which receives traffic from an upstream interface
may forward it on a particular downstream interface only if the node
is the DF for that downstream interface. A node which receives
traffic from a downstream interface may forward it on an upstream
interface only if that node is the DF for the downstream interface.
If, for any period of time, there is a link on which each of two
different nodes believes itself to be the DF, data forwarding loops
can form. Loops in a bidirectional multicast tree can be very
harmful. However, any election procedure will have a convergence
period. The BIDIR-PIM DF election procedures is very complicated,
because it goes to great pains to ensure that if convergence is not
extremely fast, then there is no forwarding at all until convergence
has taken place.
Other variants of PIM also have a DF election procedure for LANs.
However, as long as the multicast tree is unidirectional,
disagreement about who the DF is can result only in duplication of
packets, not in loops. Therefore the time taken to converge on a
single DF is of much less concern for unidirectional trees and it is
for bidirectional trees.
In the MVPN environment, if PIM signaling is used among the PEs, the
can use the standard LAN-based DF election procedure can be used.
However, election procedures that are optimized for a LAN may not
work as well in the MVPN environment. So an alternative to DF
election would be desirable.
If BGP signaling is used among the PEs, an alternative to DF election
is necessary. One might think that use the "single forwarder
selection" procedures described in sections 5 and 9 coudl be used to
choose a single PE "DF" for the backbone (for a given RPA in a given
MVPN). However, that is still likely to leave a convergence period
of at least several seconds during which loops could form, and there
could be a much longer convergence period if there is anything
disrupting the smooth flow of BGP updates. So a simple procedure
like that is not sufficient.
The remainder of this section describes two different methods that
can be used to support BIDIR-PIM while eliminating the DF election.
12.1. The VPN Backbone Becomes the RPL
On a per MVPN basis, this method treats the whole service provider(s)
infrastructure as a single RPL (RP Link). We refer to such an RPL as
an "MVPN-RPL". This eliminates the need for the PEs to engage in any
"DF election" procedure, because PIM-bidir does not have a DF on the
RPL.
However, this method can only be used if the customer is
"outsourcing" the RPL/RPA functionality to the SP.
An MVPN-RPL could be realized either via an I-PMSI (this I-PMSI is on
a per MVPN basis and spans all the PEs that have sites of a given
MVPN), or via a collection of S-PMSIs, or even via a combination of
an I-PMSI and one or more S-PMSIs.
12.1.1. Control Plane
Associated with each MVPN-RPL is an address prefix that is
unambiguous within the context of the MVPN associated with the MVPN-
RPL.
For a given MVPN, each VRF connected to an MVPN-RPL of that MVPN is
configured to advertise to all of its connected CEs the address
prefix of the MVPN-RPL.
Since in PIM Bidir there is no Designated Forwarder on an RPL, in the
context of MVPN-RPL there is no need to perform the Designated
Forwarder election among the PEs (note there is still necessary to
perform the Designated Forwarder election between a PE and its
directly attached CEs, but that is done using plain PIM Bidir
procedures).
For a given MVPN a PE connected to an MVPN-RPL of that MVPN should
send multicast data (C-S,C-G) on the MVPN-RPL only if at least one
other PE connected to the MVPN-RPL has a downstream multicast state
for C-G. In the context of MVPN this is accomplished by requring a PE
that has a downstream state for a particular C-G of a particular VRF
present on the PE to originate a C-multicast route for (*, C-G). The
RD of this route should be the same as the RD associated with the
VRF. The RT(s) carried by the route should be the same as the one(s)
used for VPN-IPv4 routes. This route will be distributed to all the
PEs of the MVPN.
12.1.2. Data Plane
A PE that receives (C-S,C-G) multicast data from a CE should forward
this data on the MVPN-RPL of the MVPN the CE belongs to only if the
PE receives at least one C-multicast route for (*, C-G). Otherwise,
the PE should not forward the data on the RPL/I-PMSI.
When a PE receives a multicast packet with (C-S,C-G) on an MVPN-RPL
associated with a given MVPN, the PE forwards this packet to every
directly connected CE of that MVPN, provided that the CE sends Join
(*,C-G) to the PE (provided that the PE has the downstream (*,C-G)
state). The PE does not forward this packet back on the MVPN-RPL. If
a PE has no downstream (*,C-G) state, the PE does not forward the
packet.
12.2. Partitioned Sets of PEs
This method does not require the use of the MVPN-RPL, and does not
require the customer to outsource the RPA/RPL functionality to the
SP.
12.2.1. Partitions
Consider a particular C-RPA, call it C-R, in a particular MVPN.
Consider the set of PEs that attach to sites that have senders or
receivers for a BIDIR-PIM group C-G, where C-R is the RPA for C-G.
(As always we sue the "C-" prefix to indicate that we are referring
to an address in the VPN's address space rather than in the
provider's address space.)
Following the procedures of section 5.1, each PE in the set
independently chooses some other PE in the set to be its "upstream
PE" for those BIDIR-PIM groups with RPA C-R. Optionally, they can
all choose the "default selection" (described in section 5.1), to
ensure that each PE to choose the same upstream PE. Note that if a
PE has a route to C-R via a VRF interface, then the PE may choose
itself as the upstream PE.
The set of PEs can now be partitioned into a number of subsets.
We'll say that PE1 and PE2 are in the same partition if and only if
there is some PE3 such that PE1 and PE2 have each chosen PE3 as the
upstream PE for C-R. Note that each partition has exactly one
upstream PE. So it is possible to identify the partition by
identifying its upstream PE.
Consider packet P, and let PE1 be its ingress PE. PE1 will send the
packet on a PMSI so that it reaches the other PEs that need to
receive it. This is done by encapsulating the packet and sending it
on a P-tunnel. If the original packet is part of a PIM-BIDIR group
(its ingress PE determines this from the packet's destination address
C-G), and if the VPN backbone is not the RPL, then the encapsulation
MUST carry information that can be used to identify the partition to
which the ingress PE belongs.
When PE2 receives a packet from the PMSI, PE2 must determine, by
examining the encapsulation, whether the packet's ingress PE belongs
to the same partition (relative to the C-RPA of the packet's C-G)
that PE2 itself belongs to. If not, PE2 discards the packet.
Otherwise PE2 performs the normal BIDIR-PIM data packet processing.
With this rule in place, harmful loops cannot be introduced by the
PEs into the customer's bidirectional tree.
Note that if there is more than one partition, the VPN backbone will
not carry a packet from one partition to another. The only way for a
packet to get from one partition to another is for it to go up
towards the RPA and then to go down another path to the backbone. If
this is not considered desirable, then all PEs should choose the same
upstream PE for a given C-RPA. Then multiple partitions will only
exist during routing transients.
12.2.2. Using PE Labels
If a given P-tunnel is to be used to carry packets belonging to a
bidirectional C-group, then, EXCEPT for the case described in section
12.2.3 the packets that travel on that P-tunnel MUST carry a PE label
(defined in section 4), using the encapsulation discussed in section
11.3.
When a given PE transmits a given packet of a bidirectional C-group
to the P-tunnel, the packet will carry the PE label corresponding to
the partition, for the C-group's C-RPA, that contains the
transmitting PE. This is the PE label that has been bound to the
upstream PE of that partition; it is not necessarily the label that
has been bound to the transmitting PE.
Recall that the PE labels are upstream-assigned labels that are
assigned and advertised by the node which is at the root of the P-
tunnel. (Procedures for PE label assignment when the P-tunnel is not
a multicast tree will be given is later revisions of this document.)
When a PE receives a packet with a PE label that does not identify
the partition of the receiving PE, then the receiving PE discards the
packet.
Note that this procedure does not require the root of a P-tunnel to
assign a PE label for every PE that belongs to the tunnel, but only
for those PEs that might become the upstream PEs of some partition.
12.2.3. Mesh of MP2MP P-Tunnels
There is one case in which support for BIDIR-PIM C-groups does not
require the use of a PE label. For a given C-RPA, suppose a distinct
MP2MP LSP is used as the P-tunnel serving that partition. Then for a
given packet, a PE receiving the packet from a P-tunnel can be infer
the partition from the tunnel. So PE labels are not needed in this
case.
13. Security Considerations
To be supplied. To be supplied.
13. IANA Considerations 14. IANA Considerations
To be supplied. To be supplied.
14. Other Authors 15. Other Authors
Sarveshwar Bandi, Yiqun Cai, Thomas Morin, Yakov Rekhter, IJsbrands Sarveshwar Bandi, Yiqun Cai, Thomas Morin, Yakov Rekhter, IJsbrands
Wijnands, Seisho Yasukawa Wijnands, Seisho Yasukawa
15. Other Contributors 16. Other Contributors
Significant contributions were made Arjen Boers, Toerless Eckert, Significant contributions were made Arjen Boers, Toerless Eckert,
Adrian Farrel, Luyuan Fang, Dino Farinacci, Lenny Guiliano, Shankar Adrian Farrel, Luyuan Fang, Dino Farinacci, Lenny Guiliano, Shankar
Karuna, Anil Lohiya, Tom Pusateri, Ted Qian, Robert Raszuk, Tony Karuna, Anil Lohiya, Tom Pusateri, Ted Qian, Robert Raszuk, Tony
Speakman, Dan Tappan. Speakman, Dan Tappan.
16. Authors' Addresses 17. Authors' Addresses
Rahul Aggarwal (Editor)
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Sarveshwar Bandi Rahul Aggarwal (Editor)
Motorola Juniper Networks
Vanenburg IT park, Madhapur, 1194 North Mathilda Ave.
Hyderabad, India Sunnyvale, CA 94089
Email: sarvesh@motorola.com Email: rahul@juniper.net
Sarveshwar Bandi
Motorola
Vanenburg IT park, Madhapur,
Hyderabad, India
Email: sarvesh@motorola.com
Yiqun Cai Yiqun Cai
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA, 95134 San Jose, CA, 95134
E-mail: ycai@cisco.com E-mail: ycai@cisco.com
Thomas Morin Thomas Morin
France Telecom R & D France Telecom R & D
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
Email: thomas.morin@francetelecom.com Email: thomas.morin@francetelecom.com
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: yakov@juniper.net Email: yakov@juniper.net
Eric C. Rosen (Editor)
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
E-mail: erosen@cisco.com
IJsbrand Wijnands Eric C. Rosen (Editor)
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 1414 Massachusetts Avenue
San Jose, CA, 95134 Boxborough, MA, 01719
E-mail: ice@cisco.com E-mail: erosen@cisco.com
Seisho Yasukawa IJsbrand Wijnands
NTT Corporation Cisco Systems, Inc.
9-11, Midori-Cho 3-Chome 170 Tasman Drive
Musashino-Shi, Tokyo 180-8585, San Jose, CA, 95134
Japan E-mail: ice@cisco.com
Phone: +81 422 59 4769 Seisho Yasukawa
Email: yasukawa.seisho@lab.ntt.co.jp NTT Corporation
9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585,
Japan
Phone: +81 422 59 4769
Email: yasukawa.seisho@lab.ntt.co.jp
17. Normative References 18. Normative References
[MVPN-BGP], R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C. [MVPN-BGP], R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C.
Kodeboniya, "BGP Encodings for Multicast in MPLS/BGP IP VPNs", Kodeboniya, "BGP Encodings for Multicast in MPLS/BGP IP VPNs", draft-
draft-ietf-l3vpn-2547bis-mcast-bgp-02.txt, March 2007 ietf-l3vpn-2547bis-mcast-bgp-03.txt, July 2007
[MPLS-IP] T. Worster, Y. Rekhter, E. Rosen, "Encapsulating MPLS in IP [MPLS-IP] T. Worster, Y. Rekhter, E. Rosen, "Encapsulating MPLS in IP
or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005 or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005
[MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter,
"MPLS Multicast Encapsulations", draft-ietf-mpls-multicast-encaps- "MPLS Multicast Encapsulations", draft-ietf-mpls-multicast-
04.txt, April 2007 encaps-06.txt, July 2007
[MPLS-UPSTREAM-LABEL] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS [MPLS-UPSTREAM-LABEL] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS
Upstream Label Assignment and Context Specific Label Space", draft- Upstream Label Assignment and Context Specific Label Space", draft-
ietf-mpls-upstream-label-02.txt, March 2007 ietf-mpls-upstream-label-02.txt, March 2007
[PIM-ATTRIB], A. Boers, IJ. Wijnands, E. Rosen, "Format for Using
TLVs in PIM Messages", draft-ietf-pim-join-attributes-03, May 2007
[PIM-SM] "Protocol Independent Multicast - Sparse Mode (PIM-SM)", [PIM-SM] "Protocol Independent Multicast - Sparse Mode (PIM-SM)",
Fenner, Handley, Holbrook, Kouvelas, August 2006, RFC 4601 Fenner, Handley, Holbrook, Kouvelas, August 2006, RFC 4601
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997 Levels.", Bradner, March 1997
[RFC4364] "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 2006 [RFC4364] "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 2006
[RSVP-P2MP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to [RSVP-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al.,
Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-07.txt, January "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", RFC 4875,
2007 May 2007
18. Informative References 19. Informative References
[ADMIN-ADDR] D. Meyer, "Administratively Scoped IP Multicast", RFC [ADMIN-ADDR] D. Meyer, "Administratively Scoped IP Multicast", RFC
2365, July 1998 2365, July 1998
[MVPN-REQ] T. Morin, Ed., "Requirements for Multicast in L3 [MVPN-REQ] T. Morin, Ed., "Requirements for Multicast in L3 Provider-
Provider-Provisioned VPNs", RFC 4834, April 2007 Provisioned VPNs", RFC 4834, April 2007
[MVPN-BASE] R. Aggarwal, A. Lohiya, T. Pusateri, Y. Rekhter, "Base [MVPN-BASE] R. Aggarwal, A. Lohiya, T. Pusateri, Y. Rekhter, "Base
Specification for Multicast in MPLS/BGP VPNs", draft-raggarwa-l3vpn- Specification for Multicast in MPLS/BGP VPNs", draft-raggarwa-
2547-mvpn-00.txt l3vpn-2547-mvpn-00.txt
[RAGGARWA-MCAST] R. Aggarwal, et. al., "Multicast in BGP MPLS VPNs [RAGGARWA-MCAST] R. Aggarwal, et. al., "Multicast in BGP MPLS VPNs
and VPLS", draft-raggarwa-l3vpn-mvpn-vpls-mcast-01.txt". and VPLS", draft-raggarwa-l3vpn-mvpn-vpls-mcast-01.txt".
[ROSEN-8] E. Rosen, Y. Cai, I. Wijnands, "Multicast in MPLS/BGP IP [ROSEN-8] E. Rosen, Y. Cai, I. Wijnands, "Multicast in MPLS/BGP IP
VPNs", draft-rosen-vpn-mcast-08.txt VPNs", draft-rosen-vpn-mcast-08.txt
[RP-MVPN] S. Yasukawa, et. al., "BGP/MPLS IP Multicast VPNs", draft- [RP-MVPN] S. Yasukawa, et. al., "BGP/MPLS IP Multicast VPNs", draft-
yasukawa-l3vpn-p2mp-mcast-01.txt yasukawa-l3vpn-p2mp-mcast-01.txt
skipping to change at page 74, line 5 skipping to change at page 83, line 40
[RFC2890] G. Dommety, "Key and Sequence Number Extensions to GRE", [RFC2890] G. Dommety, "Key and Sequence Number Extensions to GRE",
September 2000 September 2000
[RFC2983] D. Black, "Differentiated Services and Tunnels", October [RFC2983] D. Black, "Differentiated Services and Tunnels", October
2000 2000
[RFC3270] F. Le Faucheur, et. al., "MPLS Support of Differentiated [RFC3270] F. Le Faucheur, et. al., "MPLS Support of Differentiated
Services", May 2002 Services", May 2002
19. Full Copyright Statement [RFC4607] H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
August 2006
20. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
20. Intellectual Property 21. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 188 change blocks. 
775 lines changed or deleted 1229 lines changed or added

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