Internet DRAFT - draft-hlj-l3vpn-mvpn-mrsvp-te
draft-hlj-l3vpn-mvpn-mrsvp-te
L3VPN Working Group L. Han, Ed.
Internet-Draft R. Li
Intended status: Standards Track Huawei Technologies
Expires: January 31, 2013 July 30, 2012
Multicast VPN Support by Receiver-Driven Multicast Extensions to RSVP-TE
draft-hlj-l3vpn-mvpn-mrsvp-te-01
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 31, 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
described in the Simplified BSD License.
Han & Li Expires January 31, 2013 [Page 1]
Internet-Draft mVPN support by mRSVP-TE July 2012
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
5.3.2. Scenario 2: The multicast source and RP are behind
the different PE . . . . . . . . . . . . . . . . . . . 19
Han & Li Expires January 31, 2013 [Page 2]
Internet-Draft mVPN support by mRSVP-TE July 2012
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) . . . . . . 27
8.5. mLSP TLV Message format for IPv4 . . . . . . . . . . . . . 27
8.6. mLSP TLV Message format for IPv6 . . . . . . . . . . . . . 28
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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 & Li Expires January 31, 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]. Both use UDP to encapsulate the join
TLV message, and the IP destination address are also same, it is ALL-
PIM-ROUTERS (224.0.0.13) for IPv4 and ALL-PIM-ROUTERS (ff02::d) for
IPv6. But there are some difference for MDT and mLSP. The 1st
difference is that we have to use a value (mLSP ID) other than "P
Group" for MPLS case since we do not have "P Group" for MPLS core
network. The 2nd difference is that we have to use different port
number instead of 3232 assigned to mGRE based MDT. The exact UDP
port number is TBD.
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
Han & Li Expires January 31, 2013 [Page 24]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ VPN ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 1 mVPN mRSVP-TE path session object for PIM-SSM option 1 (IPv4)
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
Han & Li Expires January 31, 2013 [Page 25]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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
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
Han & Li Expires January 31, 2013 [Page 26]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Han & Li Expires January 31, 2013 [Page 27]
Internet-Draft mVPN support by mRSVP-TE July 2012
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.
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
Han & Li Expires January 31, 2013 [Page 28]
Internet-Draft mVPN support by mRSVP-TE July 2012
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.
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Han & Li Expires January 31, 2013 [Page 29]
Internet-Draft mVPN support by mRSVP-TE July 2012
Switched Paths (LSPs)", RFC 4875, May 2007.
[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.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol Independent
Multicast (PIM)", RFC 5059, January 2008.
[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.
[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-01 (work
in progress), 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
Han & Li Expires January 31, 2013 [Page 30]
Internet-Draft mVPN support by mRSVP-TE July 2012
Renwei Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone:
Email: renwei.li@huawei.com
Han & Li Expires January 31, 2013 [Page 31]
