Skip to main content

Multicast VPN Support by Receiver-Driven Multicast Extensions to RSVP-TE
draft-hlj-l3vpn-mvpn-mrsvp-te-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Lin Han , Richard Li , Christian Jacquenet
Last updated 2012-07-05
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-hlj-l3vpn-mvpn-mrsvp-te-00
Internet Engineering Task Force                              L. Han, Ed.
Internet-Draft                                                     R. Li
Intended status: Standards Track                     Huawei Technologies
Expires: January 7, 2013                                    C. Jacquenet
                                                   France Telecom Orange
                                                            July 6, 2012

Multicast VPN Support by Receiver-Driven Multicast Extensions to RSVP-TE
                    draft-hlj-l3vpn-mvpn-mrsvp-te-00

Abstract

   This document describes a method to support multicast VPN (MVPN) by a
   receiver-driven multicast extension to RSVP-TE (mRSVP-TE).  This
   method is desirable and applicable to MVPN applications when QoS
   assurance and traffic-engineered tunnels are desired.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 7, 2013.

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

Han, et al.              Expires January 7, 2013                [Page 1]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   described in the Simplified BSD License.

   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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Multicast LSP  . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  PIM States, PIM Interfaces and PMSI  . . . . . . . . . . .  7
     3.3.  Reverse-Path Forwarding  . . . . . . . . . . . . . . . . .  8
     3.4.  Default mLSP . . . . . . . . . . . . . . . . . . . . . . .  9
       3.4.1.  Establishment of Default mLSP  . . . . . . . . . . . .  9
       3.4.2.  Virtual PIM Interface for Default mLSP . . . . . . . . 10
       3.4.3.  PIM signaling over Default mLSP  . . . . . . . . . . . 10
       3.4.4.  PIM state with Default mLSP  . . . . . . . . . . . . . 12
       3.4.5.  Multicast data over default mLSP . . . . . . . . . . . 13
     3.5.  Data mLSP  . . . . . . . . . . . . . . . . . . . . . . . . 13
       3.5.1.  Establishment of Data mLSP . . . . . . . . . . . . . . 13
       3.5.2.  Virtual PIM interface for Data mLSP  . . . . . . . . . 14
       3.5.3.  mLSP ID and data mLSP mapping  . . . . . . . . . . . . 14
       3.5.4.  Switching of Data mLSP . . . . . . . . . . . . . . . . 15
       3.5.5.  PIM Prune Impact to Data mLSP  . . . . . . . . . . . . 15
       3.5.6.  Deletion of Data mLSP  . . . . . . . . . . . . . . . . 16
       3.5.7.  PIM (S,G) signaling after Data mLSP is created . . . . 16
   4.  PIM-SSM Solutions  . . . . . . . . . . . . . . . . . . . . . . 16
     4.1.  Option 1 . . . . . . . . . . . . . . . . . . . . . . . . . 16
     4.2.  Option 2 . . . . . . . . . . . . . . . . . . . . . . . . . 17
     4.3.  Option 3 . . . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  PIM-SM solutions . . . . . . . . . . . . . . . . . . . . . . . 18
     5.1.  RP-PE mLSP . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.2.  Source-PE mLSP . . . . . . . . . . . . . . . . . . . . . . 18
     5.3.  PIM register process . . . . . . . . . . . . . . . . . . . 18
       5.3.1.  Scenario 1: The multicast source and RP are behind
               the same PE  . . . . . . . . . . . . . . . . . . . . . 18

Han, et al.              Expires January 7, 2013                [Page 2]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

       5.3.2.  Scenario 2: The multicast source and RP are behind
               the different PE . . . . . . . . . . . . . . . . . . . 19
     5.4.  SPT switching  . . . . . . . . . . . . . . . . . . . . . . 21
     5.5.  RPT prune  . . . . . . . . . . . . . . . . . . . . . . . . 21
     5.6.  Data mLSP switching  . . . . . . . . . . . . . . . . . . . 21
     5.7.  PIM state at Receiver-PE . . . . . . . . . . . . . . . . . 22
   6.  Aggregation  . . . . . . . . . . . . . . . . . . . . . . . . . 22
     6.1.  Aggregation by Default mLSP  . . . . . . . . . . . . . . . 23
     6.2.  Aggregation by Data mLSP . . . . . . . . . . . . . . . . . 23
   7.  Non-VPN multicast support  . . . . . . . . . . . . . . . . . . 23
   8.  Message Format and Constants . . . . . . . . . . . . . . . . . 24
     8.1.  Path session object for PIM-SSM option 1 (IPv4)  . . . . . 24
     8.2.  Path session object for PIM-SSM option 1 (IPv6)  . . . . . 25
     8.3.  Path session object for other PIM modes (IPv4) . . . . . . 26
     8.4.  Path session object for other PIM modes (IPv6) . . . . . . 26
     8.5.  mLSP TLV Message format for IPv4 . . . . . . . . . . . . . 27
     8.6.  mLSP TLV Message format for IPv6 . . . . . . . . . . . . . 27
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     12.2. Informative References . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30

Han, et al.              Expires January 7, 2013                [Page 3]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

1.  Introduction

   A L3VPN service that supports multicast is known as a Multicast VPN,
   or MVPN for short.  There have been different proposed messages,
   procedures and mechanisms to support MVPN.  These methods differ in
   protocols used in the service provider's network, for example, the
   mGRE-based MVPN, BGP extensions to transport customer's PIM signaling
   and P2MP RSVP-TE extensions to transport multicast data streams, and
   mLDP-based MVPN, as summarized as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type   | Data Plane|        Protocols for core         | Standard|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    1    |   mGRE    |      PIM, BGP(with MDT_SAFI)      | RFC6037 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    2    |   MPLS    | P2MP RSVP-TE, BGP(with extension) | RFC6513 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    3    |   MPLS    |                mLDP               |    No   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Table 1.  Existing mVPN Solutions

   Type 1 solution requires to run PIM in the service provider's
   network.

   Both Type 2 and Type 3 require an MPLS data forwarding plane, but
   they differ in protocols used in the service provider's network.
   Type 2 uses RSVP-TE with a P2MP extension [RFC4875] for multicast
   data streams and BGP extensions with multicast encodings and
   procedures [RFC6514] for PIM signaling, or use mLDP [RFC6388] for
   both control plane signaling and multicast data streams.  Type 3 is
   simpler than type 2 in terms of required protocols and provisioning.

   With Type 2 solution, multicast traffic is carried over MPLS-TE
   tunnels, QoS and traffic engineering are supported for mVPN
   applications.  It is an advantage of Type 2 over Type 3.

   However, for Type 2 solution, BGP has to be extended with seven (7)
   types of MCAST-VPN NLRIs together with four (4) new BGP attributes.
   In some scenarios, multiple P2MP RSVP-TE tunnels are used.  And
   therefore, it requires to upgrade both BGP and RSVP-TE, which brings
   more complexity and operational inconvenience.

   In addition to the above-mentioned three methods, do we have any
   alternative method which is expected to be simpler and more scalable,
   but can still provide QoS assurance and traffic-engineered transport?

   This document specifies a new method to implement multicast VPN by

Han, et al.              Expires January 7, 2013                [Page 4]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   receiver-driven multicast extensions to RSVP-TE (mRSVP-TE) specified
   in [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]. mRSVP-TE is a
   new extension to RSVP-TE for multicast applications in MPLS networks,
   whose behavior is closer to IP PIM since both of them work by sending
   control messages from the data receivers to the data senders.  The
   receiver-driven nature of the mRSVP-TE makes it more adaptive and
   easier to be integrated with PIM for multicast applications including
   multicast VPN.

   As an extension to RSVP-TE, mRSVP-TE inherits all the desirable
   features from RSVP-TE such as QoS assurance and traffic-engineered
   paths, which makes it to distinguish from mLDP used in Type 3.

   By using an MP2MP tunnel created by mRSVP-TE to carry the customer's
   PIM signaling, we do not need to use BGP multicast extension to
   signal customer's multicast information.

   The MVPN method described in the document supports both PIM-SSM and
   PIM-SM.  For PIM-SM, this method supports multicast source, receiver,
   Rendezvous Point (RP) located at any place including PE, CE or any
   device connected to CE.  It can also support Bootstrap Router (BSR)
   Mechanism [RFC5059].

2.  Terminology

   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 RFC 2119 [RFC2119] and
   indicate requirement levels for compliant MVPN implementations.

2.1.  Definitions

   In what follows we describe some terminologies which are widely used
   in this document.

   Source-PE
         Source-PE is a PE which is connected to a MVPN CE and the
         multicast source is on or behind the CE.

   Receiver-PE
         Receiver-PE is a PE which is connected to a MVPN CE and the
         multicast receiver is on or behind the CE

   RP-PE
         RP PE is a PE which is connected to a MVPN CE and the multicast
         Rendezvous Point for PIM-SM is on or behind the CE

Han, et al.              Expires January 7, 2013                [Page 5]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   PE type
         A PE can be either Source-PE, Receiver-PE or RP-PE for
         different MVPN and different (S,G).  Its type can also be the
         mixture of any combination of the three PE type.

   MDT
         Multicast Distribution Tree, introduced in [RFC6037] for the IP
         backbone based MVPN.  MDT is composed of mGRE tunnels.  There
         are default MDT and data MDT

   mLSP
         Multicast-Label-Switched-Path.  It is the equivalent of MDT in
         MPLS networks, and sometimes we will use mLSP and MDT
         interchangeably.  The same as MDT, we also have default mLSP
         and data mLSP.

   Source-PE mLSP
         mLSP whose header-end is a Source-PE.

   RP-PE mLSP
         mLSP whose header-end is a RP-PE.

   MI-PMSI(MVPN_ID)
         It corresponds to the MI-PMSI [RFC6513] for a MVPN (ID is
         MVPN_ID), it is the Multidirectional Inclusive P-Multicast
         Service interface for the default mLSP or the MP2MP tunnel at
         either tail-end or header-end.

   S-PMSI(MVPN_ID, mLSP_ID)
         It corresponds to a S-PMSI [RFC6513] for a MVPN (ID is MVPN_ID)
         and the mLSP ID is mLSP_ID, it is the Selective P-Multicast
         Service interface for the P2MP tunnel for (S,G) at either tail-
         end or header-end.

   OIF
         Outgoing Interface for PIM state

   IIF
         Incoming Interface for PIM state

   Olist
         Outgoing Interface list for PIM state

3.  Overview

Han, et al.              Expires January 7, 2013                [Page 6]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

3.1.  Multicast LSP

   Multicast-Label-Switched-Path (mLSP) is an MPLS tree in MPLS network
   to distribute multicast data to different receivers who are
   interested in particular multicasted data stream(s).  An mLSP is
   composed of multiple Sub-Label-Switched-Paths (sub-LSP) which connect
   different Label Switch Routers (LSRs) to form an MPLS multicast
   network.  There are two basic types of mLSPs: P2MP LSP and MP2MP LSP.
   In the case of P2MP LSP, the header-end of an mLSP is the Source-PE
   which connects the source device of multicast traffic, and its tail-
   ends are the Receiver-PEs which connect the destination device of
   multicast traffic.  The joint points on an mLSP are called "Branch
   LSR" where the MPLS packets are replicated and then forwarded to
   different downstream LSRs.  In the case of MP2MP LSP, there is a
   special LSR which serves as the root of the mLSP, and all the leaf
   nodes are both the Source-PE and Receiver-PEs.

   For mVPN multicast traffic, it travels on a multicast tree which
   spans over two different networks: MPLS network operated by service
   providers and IP network on the customer's sites.  The mVPN multicast
   traffic always starts from one customer's site as IP multicast, and
   then is transported over the MPLS network to other customer's sites.
   The traffic on customer's sites is distributed over a PIM multicast
   distribution tree, while in service provider's MPLS network it is
   distributed by mLSP tunnels.  The mLSP and the PIM distribution tree
   SHOULD be seamlessly integrated.  The IP multicast data received from
   a CE is encapsulated as MPLS packet at the Source-PE of an mLSP tree,
   and then transported over the mLSP.  The MPLS packet is replicated at
   the branch LSRs and delivered to the different Receiver-PEs, where
   the MPLS packet is de-capsulated to IP multicast packet and forwarded
   to the connected IP multicast tree, then it is distributed to the
   particular receivers.

3.2.  PIM States, PIM Interfaces and PMSI

   It is assumed that PIM is used on customer's sites and mRSVP-TE is
   used in service provider's network without PIM being enabled in
   service provider's network.  In order to set up customer's multicast
   distribution trees across a service provider's MPLS network, it is
   desired that the customer's PIM SHOULD inter-work with service
   provider's mRSVP-TE, which brings up some new requirements about PIM
   states and interfaces.

   The most important factors for PIM states are the IIF and OIF, both
   of which are PIM-enabled interfaces.  A PIM interface appearing in an
   PIM state is characterized as follows:

Han, et al.              Expires January 7, 2013                [Page 7]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   o  It has an IP address configured

   o  It has the PIM protocol enabled and running

   o  It has one or more PIM adjacencies

   Since the customer's PIM adjacencies MUST be established between PEs,
   virtual interfaces associated with the MPLS tunnels connecting PEs
   are introduced.  Such virtual interfaces are also called PMSI for
   Provider Multicast Service Interface.  In this document we will use
   two types of PMSI: MI-PMSI and S-PMSI.

3.3.  Reverse-Path Forwarding

   For multicast forwarding by a PIM state (S,G), we need to check if
   the packet is coming from the expected interface which is the egress
   interface to reach the source S based on the unicast routing table.
   The expected interface is called RPF interface, or the IIF (Incoming
   interface).  In this document, we will consider the following two
   modes:

   o  PIM-SSM mode: the state to forward traffic is (S,G), so there is
      only one IIF for a (S,G).

   o  PIM-SM mode: RP will have (*,G) before the traffic is received and
      (S,G) after the register processing is finished.  Other routers
      have (*,G) before the SPT switching and (S,G) after the SPT
      switching.  For the (*,G), the RPF is the interface to reach RP by
      unicast routing.

   In the context of mVPN, PE is the boundary router between customer's
   IP network and service provider's MPLS network, and thus needs to
   handle the RPF issue as follows:

   o  For a Source-PE, the RPF checking for any (S,G) does not have any
      change since the IIF is still a normal IP interface.

   o  For a Receiver-PE, the RPF interface for any (S,G) or (*,G) is not
      derived from the unicast routing table for the multicast source S
      or RP for a multicast stream.  Instead, we MUST force the RPF
      interface to be the PIM interface which is associated with either
      an MI-PMSI or an S-PMSI.

   o  For a RP-PE, before traffic starts, the RPF interface is not set
      for (*,G) since the multicast source is unknown.  After the PIM
      register process is completed, the (S,G) state will be created.
      Then we MUST force the RPF interface to be the PIM interface which
      is associated with the MI-PMSI for the MVPN.

Han, et al.              Expires January 7, 2013                [Page 8]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   RPF does not apply to the multicast forwarding in MPLS network by
   mLSP. mLSP established by mRSVP-TE protocol can guarantee the loop-
   free for packet forwarding which is the whole purpose of RPF
   checking.

3.4.  Default mLSP

   To each mVPN, we associate an mLSP, called its default mLSP.  Given
   an mVPN, its default mLSP is a multi-directional shared tree with all
   the PEs as its leaf nodes.  Default mLSP is a MP2MP tunnel which can
   provide a multi-directional transportation for any data.  The default
   mLSP is used for the following two purposes:

   o  Cusomer's PIM signaling: Cusomer's PIM signaling is transported
      over such default mLSP

   o  Default customer's multicast data distribution: Customer's
      multicast data are transported and distributed over such mLSP by
      default.

3.4.1.  Establishment of Default mLSP

   The construction of default mLSP does not depend on the existence of
   multicast traffic for a MVPN; it is built up before any such
   multicast traffic is seen.

   Default mLSP is established when a VPN attached to a PE enables MVPN
   service.  After the MVPN is enabled, the mRSVP-TE stack MUST send the
   mRSVP-TE path message continuously.  The time interval to send the
   path message at each PE could be default value or configurable.  If
   it is configurable, different PE's interval value MUST be proper to
   guarantee the mLSP state is steady without any flapping.

   To enable MVPN service on a PE, root node(s) IP address MUST be
   given.  Root node is normally a P router inside the backbone network.

   The location of root node may impact the efficiency of a MP2MP
   tunnel.  How to choose a root node to establish a MP2MP tunnel to
   obtain the efficient multicast replication in MPLS network is out of
   scope of the document.

   In addition to the root node, explicit nodes from any PE to the root
   node P MAY be applied as an option if user wants the path from the
   root node P to a PE goes through some expected routers.

   For the details of root node and explicit node in a MP2MP tunnel,
   please refer to the [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te].

Han, et al.              Expires January 7, 2013                [Page 9]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   If the redundancy for the root node is desired to protect the failure
   of root node, multiple root nodes may be given to construct multiple
   default mLSP.  The redundancy for root node is out of scope of this
   document.

   With the method herein, there is only one default mLSP for each MVPN,
   or two for root redundancy case,

3.4.2.  Virtual PIM Interface for Default mLSP

   A MI-MPSI interface SHOULD be created at both Source-PE and
   Receiver-PE when the default mLSP for a MVPN is established.  This is
   a PIM enabled interface for a MVPN.  It is used for PIM adjacency,
   PIM state keeping, and PIM IIF and OIF representation for the MPLS
   packet forwarding over MPLS network.

   MI-PMSI is a joint point of IP multicast tree and mLSP.  If a MI-PMSI
   is one OIF in the Olist for a multicast forwarding entry (S,G), it
   means the IP multicast stream (S,G) will be replicated for the MI-
   PMSI and sent to the interface.  If a MI-PMSI is the IIF for a
   multicast forwarding entry (S,G), it means the MPLS packet received
   from MI-PMSI will be forwarded by the forwarding entry (S,G) if the
   de-capsulated MPLS packet is IP packet, and source and group are S
   and G respectively.

   MI-PMSI is a PIM interface and its IP address will be the address for
   the PIM peering.  This address on one PE MUST be reachable from all
   other PEs.  When PIM adjacency are established between PEs, one PE
   can see all its PIM adjacency's MI-PMSI are up.  For the convenience,
   it is RECOMMENDED to use the BGP source address for the BGP session
   between PEs for MI-PMSI.  The BGP session here refers to the BGP for
   unicast VPN service.

   All PIM hello variables for a virtual interface MI-PMSI, such as
   timer, are default value when the interface is created.  But they
   could be configurable and this is up to the implementation.

3.4.3.  PIM signaling over Default mLSP

   For MVPN attached PE, PIM is enabled for the interfaces connecting
   different CEs which may belong to the same or different VPNs.  Each
   interface has a MVPN instance associated with it.  After a MI-
   PMSI(MVPN_ID) is created for a default mLSP, it MUST join the same
   PIM domain for the particular MVPN.

   The default mLSP SHOULD support all PIM multicast messages:

Han, et al.              Expires January 7, 2013               [Page 10]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   o  HELLO message

   o  JOIN/PRUNE message

   o  ASSERT

   o  BOOTSTRAP

   For the following PIM unicast message, they SHOULD NOT be sent to the
   default mLSP, instead, they SHOULD be sent over a unicast MPLS tunnel
   to the destination PE.

   o  REGISTER message

   o  REGISTER-STOP message

   o  GRAFT

   o  GRAFT-ACK

   o  CANDIDATE-RP-ADV

   For one MVPN at a PE, PIM signaling (multicast) messages SHOULD be
   multicasted to all PIM interfaces for that particular MVPN including
   MI-PMSI.  PIM messages are sent to a MI-PMSI(MVPN_ID) immediately
   after the interface is created.  The messages are encapsulated to
   MPLS packets and will be distributed to all other receiver-PEs in the
   same MVPN through the default mLSP.

   At Receiver-PE, the MPLS packets are de-capsulated and delivered to a
   particular MVPN, the MVPN ID is determined by the MPLS label which
   was allocated locally on Receiver-PE when the PE initializes the
   default mLSP by sending mRSVP-TE path message to the root node.  The
   popped MPLS label from the received MPLS packet can associate the
   packet with a MI-PMSI(MVPN_ID) interface as incoming interface, So,
   the MI-PMSI(MVPN_ID) interface at Receiver-PE can be used for RPF
   checking of multicast forwarding.

   Receiver-PE SHOULD punt PIM signaling message to PIM protocol stack
   for the particular MVPN.  After all PIM HELLO messages are exchanged
   between PEs, PIM adjacencies are established between multiple PEs
   through each PE's MI-PMSI(MVPN_ID) which is associated with a
   particular MVPN.

   As the result of PIM adjacency over the default mLSP, the details of
   MPLS backbone network topology is hidden for PIM.  It will make the
   MVPN PIM virtually run over a virtual muti-access interface which is
   composed of multiple MI-PMSI(MVPN_ID) from different PEs.

Han, et al.              Expires January 7, 2013               [Page 11]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

3.4.4.  PIM state with Default mLSP

   Since the MI-PMSI interface is a PIM enabled interface, all PIM
   multicast messages, Hello, Join, Prune, Bootstrap and Assert, can be
   sent to or received from the MI-PMSI interface.  PIM protocol can
   create and update the appropriate state for a MVPN accordingly.  MI-
   PMSI can behavior as a normal PIM interface to join or exit the Olist
   for PIM state.

   Below is the detail of the PIM processing for different PIM modes and
   join messages.  All behaviors are based on the PIM protocol and some
   PIM changes are required for MVPN solution described in this
   document.

   (S,G) join for PIM-SSM
         When a Receiver-PE receives PIM (S,G) join message from
         attached CE, it SHOULD send the join message through MI-
         PMSI(MVPN_ID) interface to the default mLSP.  Meanwhile, if PIM
         (S,G) state was not created on the Receiver-PE, PIM MUST create
         a (S,G) state for which the MI-PMSI(MVPN_ID) is IIF.  As a
         result of sending PIM join message to MI-PMSI(MVPN_ID)
         interface, the message will be populated to all PEs connected
         to the same default mLSP.  However, only Source-PE SHOULD
         process the PIM join message.  The Source-PE is derived from
         the BGP next hop of source address S. All other PEs SHOULD
         ignore the join message.  After the Source-PE receives the
         (S,G) join from a default mLSP, if the PIM (S,G) state was not
         created, PIM SHOULD create a PIM (S,G) state for multicast
         routing table, the entry SHOULD add MI-PMSI(MVPN_ID) to its
         Olist.  After the 1st PIM join message is processed at both
         Receiver-PE and Source-PE, the subsequent PIM join message will
         only reset the PIM timer and will not change the PIM (S,G)
         state.  This behavior is same as PIM in IP network.

   (*,G,RP) join for PIM-SM
         PIM-SM (*,G) join message will be populated through default
         mLSP to all PEs attached to the same mLSP.  The behavior for
         PIM (*,G) join is the same as PIM-SSM.  The only difference is
         that (*,G) join is sent to RP (Rendezvous Points).  As a
         result, only RP-PE SHOULD process the PIM join message.  The
         RP-PE is derived from the BGP next hop of RP address.  All
         other PEs SHOULD ignore the join message.  After the PIM (*,G)
         join message is sent from Receiver-PE and received by RP-PE.
         PIM SHOULD create a (*,G) state on Receiver-PE, for which the
         MI-PMSI(MVPN_ID) is IIF.  PIM SHOULD create a (*,G) state at
         RP-PE and add the MI-PMSI(MVPN_ID) to its Olist.

   PIM prune message processing has no change on PE, it may lead to the

Han, et al.              Expires January 7, 2013               [Page 12]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   interface state change for a PIM state, or a PIM state deletion.
   When a PIM state is deleted on a receiver-PE, it MUST send the PIM
   prune message to the default mLSP to forward the prune message to
   source-PE or RP-PE.  When a Source-PE or RP-PE receives a prune
   message from the default mLSP, it MUST prune the MI-PMSI from the PIM
   state's Olist.

3.4.5.  Multicast data over default mLSP

   If a default mLSP is used to carry user's multicast data, it will
   send the multicast data to all PEs connected to the default mLSP, no
   matter if a PE is intended or not to receive the particular multicast
   traffic.  The PIM join or prune does not start or stop the traffic
   over the default mLSP.  This is normally used for the beginning of
   the multicast traffic flowing when the traffic rate is low.
   Obviously, there are two drawbacks for it

   o  Some PE may not want to receive some multicast traffic, this will
      be wasteful for the bandwidth and resource for routers.

   o  Too much multicast data shares one tree can congest the MP2MP
      tunnel.

   To overcome above problems, data mLSP is used to offload the data
   traffic from the default mLSP.

3.5.  Data mLSP

   Data mLSP is used to offload some data stream from the default mLSP.
   It is a P2MP tunnel corresponding to a (S,G) entry in a MVPN.  Data
   mLSP is built up either statically or dynamically depending on the
   solutions for different PIM modes.  Section 4 and 5 will discuss
   details.

3.5.1.  Establishment of Data mLSP

   Static data mLSP establishment is triggered by a Receiver-PE to send
   the mRSVP-TE P2MP path message to a Source-PE.  It will be described
   in section 4.1.

   Dynamical data mLSP establishment is driven by the multicast traffic.
   The mechanism is similar to the data MDT described in [RFC6037].

   Source-PE MUST monitor the rate of all multicast streams passing
   through it.  As for how to monitor the traffic rate, it is out of the
   scope of the document.

   When a Source-PE detects the rate of a MVPN multicast stream (S,G)

Han, et al.              Expires January 7, 2013               [Page 13]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   exceeds the pre-configured threshold, it MUST send a data mLSP join
   TLV to the default data mLSP.  The format of data mLSP join TLV is
   defined in section 8.5 and 8.6.

   The data mLSP join TLV will be flooded to all PE connected to the
   same default mLSP.  When a PE receives the data mLSP join TLV and if
   the PE has joined the group G, it MUST initialize the setup of P2MP
   tunnel by sending the mRSVP-TE P2MP path message to the Source-PE for
   (S,G).  Source-PE address is derived from the BGP nexhop of the VPN
   address S.

   The periodically sending of mRSVP-TE path message from receiver-PE to
   Source-PE is driven by the periodically received mLSP join TLV
   message at receiver-PE

   The operation of data mLSP is similar to the operation of data MDT
   for mGRE based mVPN.  It has four timer defined to govern the data
   mLSP: MDT_DATA_DELAY, MDT_DATA_TIMEOUT, MDT_DATA_HOLDDOWN,
   MDT_INTERVAL.  For the detailed definition of those timers and
   operations, please refer to [RFC6037].

   Since the interval to receive mLSP join TLV message will determine
   the interval to send mRSVP-TE path message, we SHOULD make sure the
   interval of mLSP join TLV is less than the timeout value of sub-LSP
   created by the mRSVP-TE path message.

3.5.2.  Virtual PIM interface for Data mLSP

   After a data mLSP is created, the S-PMSI(MVPN_ID,mLSP_ID) MUST be
   instantiated.  S-PMSI(MVPN_ID,mLSP_ID) is only used for Incoming
   Interface (IIF) at Receiver-PE and Outgoing Interface (OIF) at
   Source-PE for the multicast forwarding, it is not used for PIM
   signaling.

   The mLSP_ID is "mLSP ID" shown in Fig.3 which is assigned at
   Source-PE.

   S-PMSI(MVPN_ID,mLSP_ID) points to the same PIM interface as MI-
   PMSI(MVPN_ID).  It only adds extra L2 rewriting information block to
   the PIM interface for the packet forwarding purpose.

3.5.3.  mLSP ID and data mLSP mapping

   Data mLSP is identified by "mLSP ID" which is defined in section 8.3
   and 8.4. mLSP ID is a 4 byte value starting from 1 for data mLSP.
   mLSP ID 0 is reserved for the default mLSP. mLSP ID is to distinguish
   different data mLSP (P2MP tunnel) at Source-PE side.  During the data
   mLSP building, the mLSP ID allocated at a Source-PE MUST be notified

Han, et al.              Expires January 7, 2013               [Page 14]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   to all Receiver-PE by the mLSP join TLV.

   When a Source-PE detects the rate of a MVPN multicast stream (S,G)
   exceeds the pre-configured threshold, it MUST assign a mLSP ID from
   its mLSP pool for the (S,G).  And the mLSP join TLV message binds
   (S,G) with mLSP ID.  The Receiver-PE receiving the mLSP join TLV will
   know the binding relationship.  As a result, both Source-PE and
   Receiver-PE will have a mapping for the mLSP ID and data mLSP, this
   is used for the switching of data MDT for a stream (S,G).

   After a data MLSP is deleted, the associated mLSP ID MUST be returned
   to the mLSP pool.

3.5.4.  Switching of Data mLSP

   The Source-PE SHOULD switch the traffic from default mLSP to data
   mLSP after it created the data mLSP for a multicast stream (S,G).
   The mLSP ID and data mLSP mapping information will tell which data
   mLSP is used for which stream (S,G).  From the PIM state point of
   view, at Source-PE, the PIM state (S,G) SHOULD change the OIF from
   MI-PMSI(MVPN_ID) to S-PMSI(MVPN_ID, mLSP_ID).  Since MI-PMSI(MVPN_ID)
   and S-PMSI(MVPN_ID, mLSP_ID) share the same PIM interface, the
   switching essentially means the MPLS forwarding is switched from the
   MP2MP tunnel to P2MP tunnel.  There is no PIM interface changing for
   PIM signaling during and after the data mLSP switching

   After switching, Receiver-PE MUST use the correct data mLSP
   associated S-PMSI(MVPN_ID, mLSP_ID) for the RPF checking for a stream
   (S,G).

   The data mLSP switching is associated with the change of forwarding
   state for (S,G) as following

   o  Source-PE MUST modify the OIF from MI-PMSI(MVPN_ID) to
      S-PMSI(MVPN_ID, mLSP_ID).

   o  Receiver-PE MUST modify the IIF from MI-PMSI(MVPN_ID) to
      S-PMSI(MVPN_ID, mLSP_ID).

3.5.5.  PIM Prune Impact to Data mLSP

   When the multicast data is transported over a data mLSP, the PIM
   prune may cause the prune of the data mLSP tree.  After a Receiver-PE
   receives PIM prune message and if the prune message leads to the IIF
   prune for a PIM state, it MUST update the PIM state in such that the
   IIF represented by the S-PMSI(MVPN_ID,mLSP_ID) is pruned.  And the
   Receiver-PE MUST send the mRSVP-TE PATHTEAR message to the upstream
   LSR to prune the data mLSP tree.  If a Source-PE receives the

Han, et al.              Expires January 7, 2013               [Page 15]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   mRSVP-TE PATHTEAR message, the whole data mLSP is deleted and
   Source-PE MUST stop flooding the mLSP join TLV to the default mLSP.

3.5.6.  Deletion of Data mLSP

   Data mLSP join TLV will be flooded through default mLSP periodically
   by the interval of MDT_INTERVAL [RFC6037], if during the timeout
   period defined by MDT_DATA_TIMEOUT [RFC6037], there is no mLSP join
   TLV received for a receiver-PE, the receiver-PE will start to delete
   the P2MP leaf from the data mLSP.  This is done by sending mRSVP-TE
   PATHTEAR message to the upstream LSR.  After the whole data mLSP is
   deleted, the traffic will be switched back to the default mLSP.

3.5.7.  PIM (S,G) signaling after Data mLSP is created

   When a data mLSP is created for a particular multicast stream (S,G),
   the PIM signaling is not changed.  PIM join, prune for (S,G) is still
   going through the default mLSP.

4.  PIM-SSM Solutions

   To support PIM-SSM by mRSVP, we have three options.

4.1.  Option 1

   PIM (S,G) join message received at Receiver-PE MUST trigger the data
   mLSP setup by sending a mRSVP-TE P2MP path message to the Source-PE,
   if the data mLSP was not created before.  Source-PE address is the
   BGP next hop of the address S. The mRSVP-TE path message MUST embed
   the (S,G) information as shown in Fig. 1.

   PIM join message is sent to default mLSP and received by the
   Source-PE.  This SHOULD trigger the PIM (S,G) state created at
   Source-PE and Receiver-PE.  The (S,G) state at Source-PE MUST add the
   S-PMSI(MVPN_ID,mLSP_ID) for the data mLSP to its Olist; The (S,G)
   state at reveier-PE SHOULD set the S-PMSI(MVPN_ID,mLSP_ID) as IIF.

   After the PIM (S,G) state created at Source-PE, the traffic can be
   sent to data mLSP immediately.

   The P2MP mRSVP-TE path message for data mLSP MUST include the ERO
   objects when the explicit path is given for the source S.

   There is no default mLSP to data mLSP switching for this option.

Han, et al.              Expires January 7, 2013               [Page 16]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

4.2.  Option 2

   PIM (S,G) join message received at Receiver-PE MUST be sent to the
   default mLSP and received by the Source-PE.  This SHOULD trigger the
   PIM (S,G) state created at Source-PE and Receiver-PE, if the PIM
   state was not created before.  The PIM (S,G) state at Source-PE
   SHOULD add the MI-PMSI(MVPN_ID) as OIF; The (S,G) state at
   receiver-PE SHOULD add the MI-PMSI(MVPN_ID) as IIF.

   After the (S,G) state created at source-PE, the traffic can be sent
   to the default mLSP.

   Source-PE MUST detects the rate for the multicast stream (S,G) in a
   MVPN.  If the traffic rate for (S,G) exceeds the configured
   threshold, the Source-PE MUST flood the mLSP join TLV to all PEs.
   Each PE, if it is interested to receive the traffic for (S,G), MUST
   initialize a mRSVP-TE P2MP path message to the Source-PE.

   The P2MP path message MUST include the ERO objects when the explicit
   path is given for the source S.

   After the Source-PE creates a data mLSP for (S,G), it MUST switch the
   traffic from default mLSP to data mLSP.

4.3.  Option 3

   PIM (S,G) join message received at Receiver-PE MUST be sent to the
   default mLSP and received by the Source-PE.  This SHOULD trigger the
   PIM (S,G) state created at Source-PE and Receiver-PE, if the PIM
   state was not created before.  Unlike the option 2, PIM does not add
   the default mLSP interface MI-PMSI(MVPN_ID) as the IIF and OIF for
   (S,G) state.  In stead, Source-PE MUST trigger a mLSP join TLV
   flooded to all PEs.  Each PE, if it is interested to receive the
   traffic for (S,G), MUST initialize a mRSVP-TE P2MP path message to
   the Source-PE to build up a data mLSP.

   As the result of data mLSP setup, The PIM (S,G) state at receiver-PE
   MUST add the S-PMSI(MVPN_ID, mLSP_ID) as IIF.  At the Source-PE,
   after the data mLSP is created.  The PIM (S,G) state MUST add the
   S-PMSI(MVPN_ID, mLSP_ID) as OIF;

   The P2MP path message MUST include the ERO objects when the explicit
   path is given for the source S.

   There is no default mLSP to data mLSP switching for this option.

Han, et al.              Expires January 7, 2013               [Page 17]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

5.  PIM-SM solutions

   PIM-SM supporting is different to the PIM-SSM.  It involves some
   extra process like PIM register, register stop, RPT and SPT
   switching, etc [RFC4601].  Following describes the details of
   different scenarios for MVPN PIM-SM.

5.1.  RP-PE mLSP

   RP-PE mLSP is a mLSP whose header-end is at the RP-PE, and multiple
   tail-ends at different Receiver-PEs.  RP-PE mLSP is the equivalence
   of RPT (RP tree or shared tree) of IP PIM in MPLS network.  RP-PE
   mLSP will use the default mLSP in the method specified in this
   document.

   PIM (*,G,RP) join message received at Receiver-PE MUST be sent to the
   default mLSP and finally reach the RP-PE.  Then, the Source-PE and
   RP-PE can create the PIM state for (*,G).  The (*, G) state at RP-PE
   MUST have the MI-PMSI(MVPN_ID) as its OIF, and the (*, G) state at
   Receiver-PE MUST have the MI-PMSI(MVPN_ID) as its IIF.

5.2.  Source-PE mLSP

   Source-PE mLSP is a mLSP whose header-end is at a Source-PE.
   Depending on the location of tail-end, we have Source-PE to RP-PE
   mLSP, and Source-PE to Receiver-PE mLSP.  Source-PE to RP-PE mLSP is
   the tree whose header-end is at the source-PE, and the tail-ends at
   RP-PE.  It is constructed after the PIM register process is finished
   but before the PIM SPT switching or data mLSP switching.  Source-PE
   to receiver-PE mLSP is the tree whose header-end is at the source-PE,
   and the tail-ends at receiver-PEs.  It is built after SPT switching
   or data mLSP switching.  By the method specified in this document,
   Source-PE to RP-PE mLSP also use the default mLSP like RP-PE mLSP.
   source-PE to receiver-PE mLSP will use the data mLSP.

   When the Source-PE and RP-PE are same (scenario 1 in section 6.3.1),
   there is no Source-PE to RP-PE mLSP.

5.3.  PIM register process

   PIM register process is between multicast source and RP.  Depending
   on the PR location, we can have different scenarios.

5.3.1.  Scenario 1: The multicast source and RP are behind the same PE

   For this scenario, both RP and the multicast source are behind the
   same PE for the same MVPN.  In another words, the unicast path from
   the multicast source to the multicast RP for a particular MVPN does

Han, et al.              Expires January 7, 2013               [Page 18]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   not need to go through one PE to another PE and cross the MPLS
   network.  So, the RP-PE is also the Source-PE.  The PIM register
   process does not cross different PEs in the core MPLS network.  Both
   RP-PE and source-PE are not aware of the PIM register process.  There
   is no particular design consideration for MPLS tunnels.

   Before PIM register process, the PIM (*,G) join message from
   different Receiver-PE MUST be forwarded to the RP-PE.  As a result,
   the PIM (*,G) state MUST be created on both RP-PE and Receiver-PE.
   The state (*,G) at RP-PE has the MI-PMSI(MVPN_ID) as its OIF, and the
   state (*,G) at Receiver-PE has the MI-PMSI(MVPN_ID) as its IIF.

   After the PIM register process is finished, PIM state on RP-PE will
   be changed to (S,G) which inherits all OIF from its parent (*,G).
   There is no change for PIM state for (*,G) at Receiver-PE.  The
   multicast traffic will be flooded to all Receiver-PE through the RP-
   mLSP, or default mLSP. the Receiver-PE SHOULD drop the traffic if it
   does not have the (*,G) state created before.

5.3.2.  Scenario 2: The multicast source and RP are behind the different
        PE

   For this scenario, RP and the multicast source are behind the
   different PEs for the same MVPN.  The unicast path from the multicast
   source to the multicast RP MUST go through source-PE to RP-PE and
   cross the MPLS network.

   After the PIM(*,G) join is forwarded to the RP-PE through the default
   mLSP from different Receiver-PE, Only the RP-PE and receiver-PE have
   the state (*,G) created.  The state at RP-PE has the default mLSP as
   its OIF, and the interface connecting to a CE as the IIF, which CE is
   the nexthop to reach RP from the RP-PE.  The state at receiver-PE has
   the default mLSP as IIF.

   At Source-PE, there is no forwarding state.  Multicast source S MUST
   start the register process by sending data packet to RP.  The PIM
   register message is IP unicast message (encapsulated multicast data)
   which destination is to RP from source S, it SHOULD go through a
   unicast MPLS tunnel from Source-PE to RP-PE.  The creation of unicast
   MPLS tunnel is out of scope of this document.

   When RP-PE receives register message which is encapsulated in MPLS
   format, following things SHOULD happen:

   o  RP-PE MUST de-capsulate the MPLS packet and forward the PIM
      register message to RP behind the RP-PE.  RP then MUST forward the
      multicast packet (de-capsulated from PIM register message) to all
      Receiver-PE.  This is done through the (*,G) state created before

Han, et al.              Expires January 7, 2013               [Page 19]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

      PIM register process.  The traffic from RP will be forwarded back
      to RP-PE from the interface connecting to CE, and then RP-PE will
      forward the traffic to RP-mLSP, or the default mLSP.

   o  All PEs attached to the default mLSP SHOULD receive the traffic.
      Source-PE and receiver-PE which did not join the group G SHOULD
      drop the traffic.

   o  RP initialize a PIM (S,G) join to source S. S address is retrieved
      from the received data traffic from PIM register message.  The
      (S,G) join message MUST be forwarded from RP to RP-PE, and then
      RP-PE MUST forward the join through the default mLSP to the
      Source-PE.  The address of Source-PE is determined by the BGP next
      hop of the VPN address S.

   o  The Source-PE and RP-PE MUST create a PIM (S,G) state as a result
      of PIM (S,G) join message processing, PIM (S,G) state at Source-PE
      MUST have the MI-PMSI(MVPN_ID) as OIF, PIM (S,G) state at RP-PE
      MUST inherit all OIF from the previous (*,G) state, and adds the
      MI-PMSI(MVPN_ID) as IIF.  Note, the OIF for old (*,G) state has
      had the MI-PMSI(MVPN_ID) as OIF, this OIF MUST NOT be inherited
      for (S,G).

   o  At Source-PE, the multicast traffic received from a multicast
      source behind Source-PE, MUST be forwarded through the source-PE
      to RP-PE mLSP represented by the OIF of MI-PMSI(MVPN_ID).  The
      "source-PE to RP-PE mLSP" is the default mLSP.  Meanwhile,
      multicast source S still embeds the traffic as the PIM register
      message and send it to RP through the unicast MPLS tunnel.

   o  After the RP-PE receives the traffic from the source-PE to RP-PE
      mLSP (default mLSP) during the PIM register process, following
      events SHOULD happen

      1.  RP-PE SHOULD forward the traffic to RP.

      2.  After RP receives the native multicast traffic from the
          interface which was used to forward the PIM (S,G) join message
          to multicast source S, RP SHOULD stop de-capsulating the PIM
          register message.  All received PIM register message will be
          discarded.

      3.  RP Sends a PIM register-stop (unicast) message to multicast
          source S.

   o  After the multicast source receives register-stop message, it MUST
      stop to send PIM register message to RP, and all multicast data is
      natively forwarded by the (S,G) state to flood to the source-PE to

Han, et al.              Expires January 7, 2013               [Page 20]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

      RP-PE mLSP, or the default mLSP.

5.4.  SPT switching

   After Receiver-PE receive multicast traffic from the default mLSP.
   Each Receiver-PE SHOULD forward the traffic to some attached CEs by
   the PIM state (*,G) created when the PIM (*,G) join was received from
   the attached CEs.

   After the traffic reaches the Last Hop Router (LHR), LHR can
   initialize the Shortest Path Tree (SPT) switching by checking the
   traffic rate.  If the rate exceeds the pre-configured threshold, LHR
   SHOULD send the PIM (S,G) join to the multicast source.

   With the above solution for SPT switching, the Receiver-PE MUST still
   forward the PIM (S,G) join to the default mLSP.  And the PIM (S,G)
   state SHOULD be created at the Receiver-PE and the state SHOULD
   inherit all Olist from the previously created (*,G) state.

   As a result of this SPT switching solution, only Receiver-PE has the
   PIM state change.  The traffic will be forwarded by (S,G) instead of
   (*,G).  Source-PE has no change to the PIM state (S,G).  There is no
   MPLS LSP changes for the traffic forwarding path in MPLS core
   network.  The traffic is still forwarded to the default mLSP at
   source-PE.

5.5.  RPT prune

   Using the above method, the SPT switching does not lead to the
   traffic receiving interface change on the receiver PE, so, there is
   no RPT prune message triggered.

5.6.  Data mLSP switching

   As described in above section, the SPT switching does not change the
   MPLS path for multicast forwarding.  Some receiver-PEs still receive
   the traffic even there is no intention to join the specific group G.
   We will use data mLSP switching to serve the similar purpose for MPLS
   network as SPT switching in IP network.  By data mLSP switching, the
   multicast forwarding path in MPLS network can be changed from a
   shared tree (default mLSP) to a

   o  Shortest MPLS path from receiver to source, if the explicit path
      is not configured for the source S, and the QoS is not required.

   o  User defined path, if the explicit path is configured for the
      source S, or the QoS reservation is required.

Han, et al.              Expires January 7, 2013               [Page 21]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   If the traffic rate for the stream (S,G) exceeds the threshold, the
   Source-PE MUST flood the mLSP join TLV to all PEs.  Each PE, if it
   has already created the PIM state for group G, MUST initialize a
   mRSVP-TE P2MP path message to the Source-PE.  The Source-PE is found
   by the BGP next hop address for S.

   The Receiver-PE MUST update its IIF for state (S,G) from MI-
   PMSI(MVPN_ID) to S-PMSI(MVPN_ID, mLSP_ID).

   After the data mLSP is constructed at Source-PE, the PIM state (S,G)
   MUST add S-PMSI(MVPN_ID, mLSP_ID) to its Olist and prune the old OIF
   MI-PMSI(MVPN_ID).  Note, at this moment, the traffic is still sent to
   the default mLSP from the Source-PE.

   As a result of OIF updating for (S,G) at Source-PE, the traffic is
   switched from the default mLSP to the data mLSP for (S,G).

5.7.  PIM state at Receiver-PE

   PIM state at Receiver-PE may be different due to the rate threshold
   configuration of SPT switching and data mLSP switching.

   o  If the rate threshold for mLSP data switching is less than the
      rate threshold for SPT switching, the data mLSP will be switched
      earlier than the SPT switching in IP.  The multicast distribution
      tree in MPLS could be switched to a shortest path tree but the
      tree in IP network is still a shared tree.  As a result, the
      traffic is carried by a P2MP tunnel in MPLS network.  But at the
      receiver-PE, the de-capsulated MPLS traffic MUST be still
      forwarded by a PIM state (*,G) which is corresponding to a shared
      tree.

   o  If the rate threshold for mLSP data switching is greater than the
      rate threshold for SPT switching, the data mLSP will be switched
      later than the SPT switching in IP.  The tree in IP network is
      switched to a shortest path tree but the multicast distribution
      tree in MPLS is still a default mLSP.  So, the traffic is carried
      by a MP2MP tunnel in MPLS network, and at the receiver-PE, the de-
      capsulated MPLS traffic will be forwarded by a PIM state (S,G)
      which is corresponding to a shortest path tree.

6.  Aggregation

   With the method described above, there is one data mLSP per multicast
   stream (S,G).  This may not be feasible if the stream number is big,
   or, there is limit for MPLS label for multicast in a network.  Under
   those scenarios, traffic aggregation in MPLS network is desired.

Han, et al.              Expires January 7, 2013               [Page 22]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   Aggregation can save the MPLS tunnel, but always with trade off.
   When multiple MPLS multicast trees are not completely overlapped, to
   aggregate them will lead to some sub-LSP waste the bandwidth.  For
   example, if two trees have different set of receiver-PEs, some
   traffic has to be dropped on a PE if it does not have the (S,G) state
   created before.

6.1.  Aggregation by Default mLSP

   The aggregation by the default mLSP is straightforward.  If we do not
   set the data mLSP for any (S,G), the traffic of (S,G) will be kept in
   the default mLSP forever.  The aggregation for selective (S,G) can be
   done at CLI level by ACL (Access List) or any other kind of tool to
   make the streams which satisfy some conditions to stay in the default
   mLSP.

6.2.  Aggregation by Data mLSP

   The aggregation by the data mLSP can be achieved by the following
   ways

   o  Source-PE assigns the same mLSP ID for the streams expected to be
      aggregated, and keeps the mapping for the mLSP ID to different
      (S,G).

   o  Source-PE floods the mLSP join TLV for each (S,G) with the same
      mLSP ID to default mLSP.

   o  Receiver-PE receives the mLSP join TLV and checks if the data mLSP
      corresponding to the mLSP ID is created already.  If yes,
      receiver-PE SHOULD only update its mapping for the mLSP ID to an
      new (S,G) but SHOULD NOT initialize the new path message to
      source-PE.

   o  Source-PE SHOULD switch multiple streams which were assigned with
      the same mLSP ID to the same data mLSP after it is created.

   The aggregation by data mLSP essentially aggregates multicast streams
   which share the same source-PE even they have different multicast
   source.

7.  Non-VPN multicast support

   The method specified in this document can also apply to the non-VPN
   multicast support.

   For the non-VPN multicast case, we will take the same approach as VPN

Han, et al.              Expires January 7, 2013               [Page 23]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   multicast case.  Basically, we will treat the public table with a
   special VPN ID = 0 (see section 9 for VPN ID).  By such treatment,
   the multicast in public domain becomes the multicast in a special
   table, and it can be supported as normal mVPN.

8.  Message Format and Constants

   Two types of new message format have to be introduced to support mVPN
   by mRSVP-TE.  One is the SESSION-object message format for mRSVP-TE.
   Another is the mLSP join TLV message format.

   The SESSION-object defined in mRSVP-TE is a opaque value (Fig. 7 in
   [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]).  So, we can define
   the details of the opaque value based on the mVPN requirement.  For
   the PIM-SSM support option 1 (Fig. 1, Fig. 2), we can embed the
   "c-source" and "c-group" directly into the SESSION-object.  But for
   PIM-SM support, and PIM-SSM support option 2/3, we can embed the
   "mLSP ID" into the SESSION-object (Fig. 3). "mLSP ID" can map to
   different "c-source" and "c-group" at PEs.

   The mLSP join TLV message format is similar to the MDT defined in
   section 7.2 and 7.3 [RFC6037].  The difference is that we have to use
   a value other than "P Group" for MPLS case since we do not have "P
   Group" for MPLS core network.

8.1.  Path session object for PIM-SSM option 1 (IPv4)

   The MVPN mRSVP path message for PIM-SSM option 1 for IPv4 has the
   following format.

   Class = SESSION, mRSVP_TE_MVPN_IPv4 C-Type = TBD

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                            VPN ID                             +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           C-source                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           C-group                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fig. 1 mVPN mRSVP-TE path session object for PIM-SSM option 1 (IPv4)

Han, et al.              Expires January 7, 2013               [Page 24]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   VPN ID:
         This is the ID for MVPN, it MUST be same for the same VPN cross
         a MPLS network.  VRF RD (Route Distinguisher) or any other
         unique value in a MPLS network can be used for VPN ID. 0 is
         reserved for the global MPLS multicast or non MVPN case

   C-source (32 bits):
         the IPv4 address of the traffic source in the VPN.

   C-group (32 bits):
         the IPv4 address of the multicast traffic destination address
         in the VPN.

8.2.  Path session object for PIM-SSM option 1 (IPv6)

   The MVPN mRSVP path message for PIM-SSM option 1 for IPv6 has the
   following format.

   Class = SESSION, mRSVP_TE_MVPN_IPv6 C-Type = TBD

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                            VPN ID                             +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                           C-source                            |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                           C-group                             |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fig. 2 mVPN mRSVP-TE path session object for PIM-SSM option 1 (IPv6)

   VPN ID:
         Same definition as in Fig. 1

Han, et al.              Expires January 7, 2013               [Page 25]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

   C-source (128 bits):
         the IPv6 address of the traffic source in the VPN.

   C-group (128 bits):
         the IPv6 address of the multicast traffic destination address
         in the VPN.

8.3.  Path session object for other PIM modes (IPv4)

   The MVPN mRSVP-TE path message for PIM-SM, PIM-SSM (Option 2 and 3)
   for IPv4 has the following format.

   Class = SESSION, mRSVP_TE_MVPN_IPv4 C-Type = TBD

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                            VPN ID                             +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           mLSP ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fig. 3 mVPN mRSVP-TE path session object for PIM-SM, PIM-SSM (Option
                                 2 and 3)

   VPN ID:
         Same definition as in Fig. 1

   mLSP ID:
         the mLSP ID corresponding to a tunnel, 0 is reserved for
         default mLSP.  For all non-zero mLSP ID, it SHOULD come from
         the mLSP join TLV message, see Fig. 4 and Fig. 5

8.4.  Path session object for other PIM modes (IPv6)

   The MVPN mRSVP-TE path message for PIM-SM, PIM-SSM (Option 2 and 3)
   for IPv6 has the following format.

   Class = SESSION, mRSVP_TE_MVPN_IPv6 C-Type = TBD

   The session object format is the same as for IPv4 shown in Fig 3.

Han, et al.              Expires January 7, 2013               [Page 26]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

8.5.  mLSP TLV Message format for IPv4

   The mLSP Join TLV for IPv4 streams has the following format.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |           Length            |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           C-source                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           C-group                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           mLSP ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Fig. 4 mLSP join TLV message format for IPv4

   Type (8 bits):
         MUST be set to 1.

   Length (16 bits):
         MUST be set to 16.

   Reserved (8 bits):
         for future use.

   C-source (32 bits):
         the IPv4 address of the traffic source in the VPN.

   C-group (32 bits):
         the IPv4 address of the multicast traffic destination address
         in the VPN.

   mLSP ID (32 bits):
         the mLSP ID corresponding to the data mLSP carrying the flow
         (C-source, C-group).

8.6.  mLSP TLV Message format for IPv6

   The mLSP Join TLV for IPv6 streams has the following format.

Han, et al.              Expires January 7, 2013               [Page 27]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |           Length            |    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                           C-source                            |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                           C-group                             |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           mLSP ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Fig. 5 mLSP join TLV message format for IPv6

   Type (8 bits):
         MUST be set to 4.

   Length (16 bits):
         MUST be set to 40.

   Reserved (8 bits):
         for future use.

   C-source (128 bits):
         the IPv6 address of the traffic source in the VPN.

   C-group (128 bits):
         the IPv6 address of the multicast traffic destination address
         in the VPN.

   mLSP ID (32 bits):
         the mLSP ID corresponding to the data mLSP carrying the flow
         (C-source, C-group).

9.  Acknowledgements

   We would like to thank Katherine Zhao and Quintin Zhao for comments
   on early drafts of this work.

Han, et al.              Expires January 7, 2013               [Page 28]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

10.  IANA Considerations

   There is no change with regards to IANA

11.  Security Considerations

   There is no change with regards to the security for PIM protocol and
   mRSVP-TE after the MVPN is provided

12.  References

12.1.  Normative References

   [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]
              Li, R., Zhao, Q., and C. Jacquenet, "Receiver-Driven
              Multicast Traffic Engineered Label Switched Paths",
              draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00 (work
              in progress), March 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4875]  Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
              "Extensions to Resource Reservation Protocol - Traffic
              Engineering (RSVP-TE) for Point-to-Multipoint TE Label
              Switched Paths (LSPs)", RFC 4875, May 2007.

   [RFC5059]  Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
              "Bootstrap Router (BSR) Mechanism for Protocol Independent
              Multicast (PIM)", RFC 5059, January 2008.

   [RFC6388]  Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
              "Label Distribution Protocol Extensions for Point-to-
              Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, November 2011.

   [RFC6513]  Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
              VPNs", RFC 6513, February 2012.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, February 2012.

Han, et al.              Expires January 7, 2013               [Page 29]
Internet-Draft          mVPN support by mRSVP-TE               July 2012

12.2.  Informative References

   [RFC6037]  Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems'
              Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037,
              October 2010.

Authors' Addresses

   Lin Han (editor)
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +10 408 330 4613
   Email: lin.han@huawei.com

   Renwei Li
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone:
   Email: renwei.li@huawei.com

   Christian Jacquenet
   France Telecom Orange
   4 rue du Clos Courtel
   35512 Cesson Sevigne,
   France

   Phone: +33 2 99 12 43 82
   Email: christian.jacquenet@orange.com

Han, et al.              Expires January 7, 2013               [Page 30]