Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6513

Multicast in MPLS/BGP IP VPNs

Pages: 88
Proposed Standard
Errata
Updated by:  758279007988
Part 1 of 5 – Pages 1 to 13
None   None   Next

Top   ToC   RFC6513 - Page 1
Internet Engineering Task Force (IETF)                     E. Rosen, Ed.
Request for Comments: 6513                           Cisco Systems, Inc.
Category: Standards Track                               R. Aggarwal, Ed.
ISSN: 2070-1721                                         Juniper Networks
                                                           February 2012


                     Multicast in MPLS/BGP IP VPNs

Abstract

In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6513. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Top   ToC   RFC6513 - Page 2
   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

1. Introduction ....................................................5 2. Overview .......................................................5 2.1. Optimality vs. Scalability .................................5 2.1.1. Multicast Distribution Trees ........................7 2.1.2. Ingress Replication through Unicast Tunnels .........8 2.2. Multicast Routing Adjacencies ..............................8 2.3. MVPN Definition ............................................9 2.4. Auto-Discovery ............................................10 2.5. PE-PE Multicast Routing Information .......................11 2.6. PE-PE Multicast Data Transmission .........................11 2.7. Inter-AS MVPNs ............................................12 2.8. Optionally Eliminating Shared Tree State ..................13 3. Concepts and Framework .........................................13 3.1. PE-CE Multicast Routing ...................................13 3.2. P-Multicast Service Interfaces (PMSIs) ....................14 3.2.1. Inclusive and Selective PMSIs ......................15 3.2.2. P-Tunnels Instantiating PMSIs ......................16 3.3. Use of PMSIs for Carrying Multicast Data ..................18 3.4. PE-PE Transmission of C-Multicast Routing .................20 3.4.1. PIM Peering ........................................20 3.4.1.1. Full per-MVPN PIM Peering across an MI-PMSI ................................20 3.4.1.2. Lightweight PIM Peering across an MI-PMSI .20 3.4.1.3. Unicasting of PIM C-Join/Prune Messages ...21 3.4.2. Using BGP to Carry C-Multicast Routing .............22 4. BGP-Based Auto-Discovery of MVPN Membership ....................22 5. PE-PE Transmission of C-Multicast Routing ......................25 5.1. Selecting the Upstream Multicast Hop (UMH) ................25 5.1.1. Eligible Routes for UMH Selection ..................26 5.1.2. Information Carried by Eligible UMH Routes .........26 5.1.3. Selecting the Upstream PE ..........................27 5.1.4. Selecting the Upstream Multicast Hop ...............29 5.2. Details of Per-MVPN Full PIM Peering over MI-PMSI .........29 5.2.1. PIM C-Instance Control Packets .....................29
Top   ToC   RFC6513 - Page 3
           5.2.2. PIM C-Instance Reverse Path Forwarding
                  (RPF) Determination ................................30
      5.3. Use of BGP for Carrying C-Multicast Routing ...............31
           5.3.1. Sending BGP Updates ................................31
           5.3.2. Explicit Tracking ..................................32
           5.3.3. Withdrawing BGP Updates ............................32
           5.3.4. BSR ................................................33
   6. PMSI Instantiation .............................................33
      6.1. Use of the Intra-AS I-PMSI A-D Route ......................34
           6.1.1. Sending Intra-AS I-PMSI A-D Routes .................34
           6.1.2. Receiving Intra-AS I-PMSI A-D Routes ...............35
      6.2. When C-flows Are Specifically Bound to P-Tunnels ..........35
      6.3. Aggregating Multiple MVPNs on a Single P-Tunnel ...........35
           6.3.1. Aggregate Tree Leaf Discovery ......................36
           6.3.2. Aggregation Methodology ............................36
           6.3.3. Demultiplexing C-Multicast Traffic .................37
      6.4. Considerations for Specific Tunnel Technologies ...........38
           6.4.1. RSVP-TE P2MP LSPs ..................................39
           6.4.2. PIM Trees ..........................................41
           6.4.3. mLDP P2MP LSPs .....................................42
           6.4.4. mLDP MP2MP LSPs ....................................42
           6.4.5. Ingress Replication ................................42
   7. Binding Specific C-Flows to Specific P-Tunnels .................44
      7.1. General Considerations ....................................45
           7.1.1. At the PE Transmitting the C-Flow on the P-Tunnel ..45
           7.1.2. At the PE Receiving the C-flow from the P-Tunnel ...46
      7.2. Optimizing Multicast Distribution via S-PMSIs .............48
      7.3. Announcing the Presence of Unsolicited Flooded Data .......49
      7.4. Protocols for Binding C-Flows to P-Tunnels ................50
           7.4.1. Using BGP S-PMSI A-D Routes ........................50
                  7.4.1.1. Advertising C-Flow Binding to P-Tunnel ....50
                  7.4.1.2. Explicit Tracking .........................51
           7.4.2. UDP-Based Protocol .................................52
                  7.4.2.1. Advertising C-Flow Binding to P-Tunnel ....52
                  7.4.2.2. Packet Formats and Constants ..............53
           7.4.3. Aggregation ........................................55
   8. Inter-AS Procedures ............................................55
      8.1. Non-Segmented Inter-AS P-Tunnels ..........................56
           8.1.1. Inter-AS MVPN Auto-Discovery .......................56
           8.1.2. Inter-AS MVPN Routing Information Exchange .........56
           8.1.3. Inter-AS P-Tunnels .................................57
                  8.1.3.1. PIM-Based Inter-AS P-Multicast Trees ......57
                  8.1.3.2. The PIM MVPN Join Attribute ...............58
                           8.1.3.2.1. Definition .....................58
                           8.1.3.2.2. Usage ..........................59
      8.2. Segmented Inter-AS P-Tunnels ..............................60
   9. Preventing Duplication of Multicast Data Packets ...............60
      9.1. Methods for Ensuring Non-Duplication ......................61
Top   ToC   RFC6513 - Page 4
           9.1.1. Discarding Packets from Wrong PE ...................62
           9.1.2. Single Forwarder Selection .........................63
           9.1.3. Native PIM Methods .................................63
      9.2. Multihomed C-S or C-RP ....................................63
      9.3. Switching from the C-RP Tree to the C-S Tree ..............63
           9.3.1. How Duplicates Can Occur ...........................63
           9.3.2. Solution Using Source Active A-D Routes ............65
   10. Eliminating PE-PE Distribution of (C-*,C-G) State .............67
      10.1. Co-Locating C-RPs on a PE ................................68
           10.1.1. Initial Configuration .............................68
           10.1.2. Anycast RP Based on Propagating Active Sources ....68
                  10.1.2.1. Receiver(s) within a Site ................69
                  10.1.2.2. Source within a Site .....................69
                  10.1.2.3. Receiver Switching from Shared to
                            Source Tree ..............................69
      10.2. Using MSDP between a PE and a Local C-RP .................69
   11. Support for PIM-BIDIR C-Groups ................................71
      11.1. The VPN Backbone Becomes the RPL .........................72
           11.1.1. Control Plane .....................................72
           11.1.2. Data Plane ........................................73
      11.2. Partitioned Sets of PEs ..................................73
           11.2.1. Partitions ........................................73
           11.2.2. Using PE Distinguisher Labels .....................74
           11.2.3. Partial Mesh of MP2MP P-Tunnels ...................75
   12. Encapsulations ................................................75
      12.1. Encapsulations for Single PMSI per P-Tunnel ..............75
           12.1.1. Encapsulation in GRE ..............................75
           12.1.2. Encapsulation in IP ...............................76
           12.1.3. Encapsulation in MPLS .............................77
      12.2. Encapsulations for Multiple PMSIs per P-Tunnel ...........78
           12.2.1. Encapsulation in GRE ..............................78
           12.2.2. Encapsulation in IP ...............................78
      12.3. Encapsulations Identifying a Distinguished PE ............78
           12.3.1. For MP2MP LSP P-Tunnels ...........................78
           12.3.2. For Support of PIM-BIDIR C-Groups .................79
      12.4. General Considerations for IP and GRE Encapsulations .....79
           12.4.1. MTU (Maximum Transmission Unit) ...................79
           12.4.2. TTL (Time to Live) ................................80
           12.4.3. Avoiding Conflict with Internet Multicast .........80
      12.5. Differentiated Services ..................................81
   13. Security Considerations .......................................81
   14. IANA Considerations ...........................................83
   15. Acknowledgments ...............................................83
   16. References ....................................................84
      16.1. Normative References .....................................84
      16.2. Informative References ...................................85
Top   ToC   RFC6513 - Page 5

1. Introduction

[RFC4364] specifies the set of procedures that a Service Provider (SP) must implement in order to provide a particular kind of VPN service ("BGP/MPLS IP VPN") for its customers. The service described 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 travel from one customer site to another. This document extends the service defined in [RFC4364] so that it also includes the capability of handling IP multicast traffic. This requires a number of different protocols to work together. The document provides a framework describing how the various protocols fit together, and it also provides a detailed specification of some of the protocols. The detailed specification of some of the other protocols is found in preexisting documents or in companion documents. A BGP/MPLS IP VPN service that supports multicast is known as a "Multicast VPN" or "MVPN". Both this document and its companion document [MVPN-BGP] discuss the use of various BGP messages and procedures to provide MVPN support. While every effort has been made to ensure that the two documents are consistent with each other, it is possible that discrepancies have crept in. In the event of any conflict or other discrepancy with respect to the use of BGP in support of MVPN service, [MVPN-BGP] is to be considered to be the authoritative document. Throughout this document, we will use the term "VPN-IP route" to mean a route that is either in the VPN-IPv4 address family [RFC4364] or in the VPN-IPv6 address family [RFC4659]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Overview

2.1. Optimality vs. Scalability

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 the SP's network (the "P routers"). Routing information from a particular VPN is maintained only by the Provider Edge routers (the "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 another (usually MPLS Label Switched Paths, LSPs), so to support the
Top   ToC   RFC6513 - Page 6
   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
   in the P routers depends only on the number of PEs, not on the number
   of VPNs.

   However, in order to provide optimal multicast routing for a
   particular multicast flow, the P routers through which that flow
   travels have to hold state that is specific to that flow.  A
   multicast flow is identified by the (source, group) tuple where the
   source is the IP address of the sender and the group is the IP
   multicast group address of the destination.  Scalability would be
   poor if the amount of state in the P routers were proportional to the
   number of multicast flows in the VPNs.  Therefore, when supporting
   multicast service for a BGP/MPLS IP VPN, the optimality of the
   multicast routing must be traded off against the scalability of the P
   routers.  We explain this below in more detail.

   If a particular VPN is transmitting "native" multicast traffic over
   the backbone, we refer to it as an "MVPN".  By "native" multicast
   traffic, we mean packets that a Customer Edge router (a "CE router"
   or "CE") sends to a PE, such that the IP destination address of the
   packets is a multicast group address, the packets are multicast
   control packets addressed to the PE router itself, or the packets are
   IP multicast data packets encapsulated in MPLS.

   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
   following conditions hold:

     - When a PE router receives a multicast data packet of that group
       from a CE router, it transmits the packet in such a way that the
       packet is received by every other PE router that is on the path
       to a receiver of that group;

     - The packet is not received by any other PEs;

     - While in the backbone, no more than one copy of the packet ever
       traverses any link.

     - While in the backbone, if bandwidth usage is to be optimized, the
       packet traverses minimum cost trees rather than shortest path
       trees.

   Optimal routing for a particular multicast group requires that the
   backbone maintain one or more source trees that are specific to that
   flow.  Each such tree requires that state be maintained in all the P
   routers that are in the tree.
Top   ToC   RFC6513 - Page 7
   Potentially, this would require an unbounded amount of state in the P
   routers, since the SP has no control of the number of multicast
   groups in the VPNs that it supports.  The SP also doesn't have any
   control over the number of transmitters in each group, nor over the
   distribution of the receivers.

   The procedures defined in this document allow an SP to provide
   multicast VPN service, without requiring the amount of state
   maintained by the P routers to be proportional to the number of
   multicast data flows in the VPNs.  The amount of state is traded off
   against the optimality of the multicast routing.  Enough flexibility
   is provided so that a given SP can make his own trade-offs between
   scalability and optimality.  An SP can even allow some multicast
   groups in some VPNs to receive optimal routing, while others do not.
   Of course, the cost of this flexibility is an increase in the number
   of options provided by the protocols.

   The basic technique for providing scalability is to aggregate a
   number of customer multicast flows onto a single multicast
   distribution tree through the P routers.  A number of aggregation
   methods are supported.

   The procedures defined in this document also accommodate the SP that
   does not want to build multicast distribution trees in his backbone
   at all; the ingress PE can replicate each multicast data packet and
   then unicast each replica through a tunnel to each egress PE that
   needs to receive the data.

2.1.1. Multicast Distribution Trees

This document supports the use of a single multicast distribution tree in the backbone to carry all the multicast traffic from a specified set of one or more MVPNs. Such a tree is referred to as an "Inclusive Tree". An Inclusive Tree that carries the traffic of more than one MVPN is an "Aggregate Inclusive Tree". An Inclusive Tree contains, as its members, all the PEs that attach to any of the MVPNs using the tree. With this option, even if each tree supports only one MVPN, the upper bound on the amount of state maintained by the P routers is proportional to the number of VPNs supported rather than to the number of multicast flows in those VPNs. If the trees are unidirectional, it would be more accurate to say that the state is proportional to the product of the number of VPNs and the average number of PEs per VPN. The amount of state maintained by the P routers can be further reduced by aggregating more MVPNs onto a single tree. If each such tree supports a set of MVPNs, (call it an "MVPN aggregation set"), the state maintained by the P routers is
Top   ToC   RFC6513 - Page 8
   proportional to the product of the number of MVPN aggregation sets
   and the average number of PEs per MVPN.  Thus, the state does not
   grow linearly with the number of MVPNs.

   However, as data from many multicast groups is aggregated together
   onto a single Inclusive Tree, it is likely that some PEs will receive
   multicast data for which they have no need, i.e., some degree of
   optimality has been sacrificed.

   This document also provides procedures that enable a single multicast
   distribution tree in the backbone to be used to carry traffic
   belonging only to a specified set of one or more multicast groups,
   from one or more MVPNs.  Such a tree is referred to as a "Selective
   Tree" and more specifically as an "Aggregate Selective Tree" when the
   multicast groups belong to different MVPNs.  By default, traffic from
   most multicast groups could be carried by an Inclusive Tree, while
   traffic from, e.g., high bandwidth groups could be carried in one of
   the Selective Trees.  When setting up the Selective Trees, one should
   include only those PEs that need to receive multicast data from one
   or more of the groups assigned to the tree.  This provides more
   optimal routing than can be obtained by using only Inclusive Trees,
   though it requires additional state in the P routers.

2.1.2. Ingress Replication through Unicast Tunnels

This document also provides procedures for carrying MVPN data traffic through unicast tunnels from the ingress PE to each of the egress PEs. The ingress PE replicates the multicast data packet received from a CE and sends it to each of the egress PEs using the unicast tunnels. This requires no multicast routing state in the P routers at all, but it puts the entire replication load on the ingress PE router and makes no attempt to optimize the multicast routing.

2.2. Multicast Routing Adjacencies

In BGP/MPLS IP VPNs [RFC4364], each CE (Customer Edge) router is a unicast routing adjacency of a PE router, but CE routers at different sites do not become unicast routing adjacencies of each other. This important characteristic is retained for multicast routing -- a CE router becomes a multicast routing adjacency of a PE router, but CE routers at different sites do not become multicast routing adjacencies of each other. We will use the term "C-tree" to refer to a multicast distribution tree whose nodes include CE routers. (See Section 3.1 for further explication of this terminology.)
Top   ToC   RFC6513 - Page 9
   The multicast routing protocol on the PE-CE link is presumed to be
   PIM (Protocol Independent Multicast) [PIM-SM].  Both the ASM (Any-
   Source Multicast) and the SSM (Source-Specific Multicast) service
   models are supported.  Thus, both shared C-trees and source-specific
   C-trees are supported.  Shared C-trees may be unidirectional or
   bidirectional; in the latter case, the multicast routing protocol is
   presumed to be the BIDIR-PIM [BIDIR-PIM] "variant" of PIM-SM.  A CE
   router exchanges "ordinary" PIM control messages with the PE router
   to which it is attached.

   Support for PIM-DM (Dense Mode) is outside the scope of this
   document.

   The PEs attaching to a particular MVPN then have to exchange the
   multicast routing information with each other.  Two basic methods for
   doing this are defined: (1) PE-PE PIM and (2) BGP.  In the former
   case, the PEs need to be multicast routing adjacencies of each other.
   In the latter case, they do not.  For example, each PE may be a BGP
   adjacency of a route reflector (RR) and not of any other PEs.

   In order to support the "Carrier's Carrier" model of [RFC4364], mLDP
   (Label Distribution Protocol Extensions for Multipoint Label Switched
   Paths) [MLDP] may also be supported on the PE-CE interface.  The use
   of mLDP on the PE-CE interface is described in [MVPN-BGP].  The use
   of BGP on the PE-CE interface is not within the scope of this
   document.

2.3. MVPN Definition

An MVPN is defined by two sets of sites: the Sender Sites set and the Receiver Sites set, with the following properties: - Hosts within the Sender Sites set could originate multicast traffic for receivers in the Receiver Sites set. - Receivers not in the Receiver Sites set should not be able to receive this traffic. - Hosts within the Receiver Sites set could receive multicast traffic originated by any host in the Sender Sites set. - Hosts within the Receiver Sites set should not be able to receive multicast traffic originated by any host that is not in the Sender Sites set.
Top   ToC   RFC6513 - Page 10
   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
   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
   could originate and receive multicast traffic from each other.

   Sites within a given MVPN may be either within the same organization
   or in different organizations, which implies that an MVPN can be
   either an Intranet or an Extranet.

   A given site may be in more than one MVPN, which implies that MVPNs
   may overlap.

   Not all sites of a given MVPN have to be connected to the same
   service provider, which implies that an MVPN can span multiple
   service providers.

   Another way to look at MVPN is to say that an MVPN is defined by a
   set of administrative policies.  Such policies determine both the
   Sender Sites set and Receiver Sites set.  Such policies are
   established by MVPN customers, but implemented/realized by MVPN
   Service Providers using the existing BGP/MPLS VPN mechanisms, such as
   Route Targets (RTs), with extensions, as necessary.

2.4. Auto-Discovery

In order for the PE routers attaching to a given MVPN to exchange MVPN control information with each other, each one needs to discover all the other PEs that attach to the same MVPN. (Strictly speaking, a PE in the Receiver Sites set need only discover the other PEs in the Sender Sites set, and a PE in the Sender Sites set need only discover the other PEs in the Receiver Sites set.) This is referred to as "MVPN Auto-Discovery". This document discusses two ways of providing MVPN auto-discovery: - BGP can be used for discovering and maintaining MVPN membership. The PE routers advertise their MVPN membership to other PE routers using BGP. A PE is considered to be a "member" of a particular MVPN if it contains a VRF (Virtual Routing and Forwarding table, see [RFC4364]) that is configured to contain the multicast routing information of that MVPN. This auto- discovery option does not make any assumptions about the methods used for transmitting MVPN multicast data packets through the backbone.
Top   ToC   RFC6513 - Page 11
     - If it is known that the PE-PE multicast control packets (i.e.,
       PIM packets) of a particular MVPN are to be transmitted through a
       non-aggregated Inclusive Tree supporting the ASM service model
       (e.g., through a tree that is created by non-SSM PIM-SM or by
       BIDIR-PIM), and if the PEs attaching to that MVPN are configured
       with the group address corresponding to that tree, then the PEs
       can auto-discover each other simply by joining the tree and then
       multicasting PIM Hellos over the tree.

2.5. PE-PE Multicast Routing Information

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 peering is used to exchange VPN routing information. The use of route reflectors further reduces the number of BGP adjacencies maintained by a PE to exchange VPN routing information with other PEs. This document describes various options for exchanging MVPN control information between PE routers based on the use of PIM or BGP. These options have different overheads with respect to the number of routing adjacencies that a PE router needs to maintain to exchange MVPN control information with other PE routers. Some of these options allow the retention of the unicast BGP/MPLS VPN model letting a PE maintain, at most, one BGP routing adjacency with other PE routers to exchange MVPN control information. BGP also provides reliable transport and uses incremental updates. Another option is the use of the currently existing "soft state" PIM standard [PIM-SM] that uses periodic complete updates.

2.6. PE-PE Multicast Data Transmission

Like [RFC4364], this document decouples the procedures for exchanging routing information from the procedures for transmitting data traffic. Hence, a variety of transport technologies may be used in the backbone. For Inclusive Trees, these transport technologies include unicast PE-PE tunnels, using encapsulation in MPLS, IP, or GRE (Generic Routing Encapsulation), multicast distribution trees created by PIM (either unidirectional in the SSM or ASM service models or bidirectional) using IP/GRE encapsulation, point-to- multipoint LSPs created by RSVP - Traffic Engineering (RSVP-TE) or mLDP, and multipoint-to-multipoint LSPs created by mLDP. In order to aggregate traffic from multiple MVPNs onto a single multicast distribution tree, it is necessary to have a mechanism to enable the egresses of the tree to demultiplex the multicast traffic received over the tree and to associate each received packet with a particular MVPN. This document specifies a mechanism whereby upstream label assignment [MPLS-UPSTREAM-LABEL] is used by the root of the tree to assign a label to each flow. This label is used by
Top   ToC   RFC6513 - Page 12
   the receivers to perform the demultiplexing.  This document also
   describes procedures based on BGP that are used by the root of an
   Aggregate Tree to advertise the Inclusive and/or Selective binding
   and the demultiplexing information to the leaves of the tree.

   This document also describes the data plane encapsulations for
   supporting the various SP multicast transport options.

   The specification for aggregating traffic of multiple MVPNs onto a
   single multipoint-to-multipoint LSP or onto a single bidirectional
   multicast distribution tree is outside the scope of this document.

   The specifications for using, as Selective Trees, multicast
   distribution trees that support the ASM service model are outside the
   scope of this document.  The specification for using multipoint-to-
   multipoint LSPs as Selective Trees is outside the scope of this
   document.

   This document assumes that when SP multicast trees are used, traffic
   for a particular multicast group is transmitted by a particular PE on
   only one SP multicast tree.  The use of multiple SP multicast trees
   for transmitting traffic belonging to a particular multicast group is
   outside the scope of this document.

2.7. Inter-AS MVPNs

[RFC4364] describes different options for supporting BGP/MPLS IP unicast VPNs whose provider backbones contain more than one Autonomous System (AS). These are known 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. This document also specifies a model where inter-AS MVPN service can be offered without requiring a single SP multicast tree to span multiple ASes. In this model, an inter-AS multicast tree consists of a number of "segments", one per AS, that are stitched together at AS boundary points. These are known as "segmented inter-AS trees". Each segment of a segmented inter-AS tree may use a different multicast transport technology. It is also possible to support inter-AS MVPNs with non-segmented source trees that extend across AS boundaries.
Top   ToC   RFC6513 - Page 13

2.8. Optionally Eliminating Shared Tree State

This document also discusses some options and protocol extensions that can be used to eliminate the need for the PE routers to distribute to each other the (*,G) and (*,G,rpt) states that occur when the VPNs are creating unidirectional C-trees to support the ASM service model.


(page 13 continued on part 2)

Next Section