tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6513

 Errata 
Proposed STD
Pages: 88
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: L3VPN

Multicast in MPLS/BGP IP VPNs

Part 1 of 5, p. 1 to 13
None       Next RFC Part

Updated by:    7582    7900    7988


Top       ToC       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.

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       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       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       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       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       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       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       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       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       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       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       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 RFC Part