MPLS Working Group R. Li
Internet-Draft Q. Zhao
Intended status: Standards Track Huawei Technologies
Expires: April 26, 2013 C. Jacquenet
France Telecom Orange
R. Tao
Huawei Technologies
B. Zhang
Telus Communications
October 23, 2012
Receiver-Driven Multicast Traffic-Engineered Label-Switched Paths
draft-lzj-mpls-receiver-driven-multicast-rsvp-te-02.txt
Abstract
This document describes the receiver-driven RSVP-TE P2MP LSP
signaling protocol (mRSVP-TE) which is an extension to the Resource
Reservation Protocol - Traffic Engineering (RSVP-TE) for the
computation and establishment of Receiver-Driven Traffic-Engineered
point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label
Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks. The document also describes the
mRSVP-TE extensions and procedures for the interworking between
mRSVP-TE and the Protocol Independent Multicast (PIM) protocol.
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 April 26, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires April 26, 2013 [Page 1]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
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.
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.
Li, et al. Expires April 26, 2013 [Page 2]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. mRSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2. The Need For PIM and mRSVP-TE Interworking . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Receiver-Driven mRSVP-TE LSP Examples . . . . . . . . . . . . 9
2.1. RD P2MP LSP Example . . . . . . . . . . . . . . . . . . . 9
2.2. RD MP2MP LSP Example . . . . . . . . . . . . . . . . . . . 11
3. Signaling Protocol Extensions . . . . . . . . . . . . . . . . 12
3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. L2S Sub-LSPs . . . . . . . . . . . . . . . . . . . . . 13
3.1.3. Path Originator and Data Receiver . . . . . . . . . . 14
3.1.4. Explicit Routing . . . . . . . . . . . . . . . . . . . 14
3.2. PIM-mRSVP TE Interworking Operation . . . . . . . . . . . 15
3.2.1. New M-Flow Spec Types . . . . . . . . . . . . . . . . 15
3.2.2. Signaling An Unidentified Sub-LSP . . . . . . . . . . 16
3.3. Path Messages . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Resv Messages . . . . . . . . . . . . . . . . . . . . . . 18
3.5. PathErr Messages . . . . . . . . . . . . . . . . . . . . . 19
3.6. ResvErr Message . . . . . . . . . . . . . . . . . . . . . 19
3.7. PathTear Messages . . . . . . . . . . . . . . . . . . . . 19
4. New and Updated Objects . . . . . . . . . . . . . . . . . . . 19
4.1. SESSION Object . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1. mRSVP-TE IPv4 LSP Tunnel SESSION Object . . . . . . . 20
4.1.2. mRSVP-TE IPv6 LSP Tunnel SESSION Object . . . . . . . 21
4.2. SENDER_TEMPLATE Object . . . . . . . . . . . . . . . . . . 21
4.2.1. mRSVP-TE LSP IPv4 Tunnel SENDER_TEMPLATE Object . . . 21
4.2.2. SENDER_TEMPLATE Objects . . . . . . . . . . . . . . . 22
4.3. L2S_SUB_LSP Objects . . . . . . . . . . . . . . . . . . . 23
4.3.1. L2S_SUB_LSP IPv4 Objects . . . . . . . . . . . . . . . 23
4.3.2. L2S_SUB_LSP IPv6 Objects . . . . . . . . . . . . . . . 24
4.4. FILTER_SPEC Objects . . . . . . . . . . . . . . . . . . . 24
4.4.1. mRSVP-TE LSP_IPv4 FILTER_SPEC Objects . . . . . . . . 24
4.4.2. mRSVP-TE LSP_IPv6 FILTER_SPEC Objects . . . . . . . . 24
4.5. MFLOW Object . . . . . . . . . . . . . . . . . . . . . . . 24
5. Fast Re-Route Considerations . . . . . . . . . . . . . . . . . 27
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Li, et al. Expires April 26, 2013 [Page 3]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
1. Introduction
The dramatic growth of multicast-based IP services such as live TV
broadcasting raises new challenges for network operators. The sole
use of IP multicast becomes challenging, given the QoS-demanding
nature of the applications. The specification of traffic-engineered,
MPLS-based, Point-to-Multi-Point (P2MP) tree structures ([RFC4875] is
meant to address both quality and robustness issues, but failed to be
massively adopted and deployed so far, mostly because the current
standard assumes a priori knowledge of all the routers involved in
the establishment and the maintenance of the tree structure, at the
cost of extra management complexity.
However, it is possible and intuitively more efficient to start the
signaling of a LSP as soon as a receiver notifies interest about a
multicast content. Thus, the signaling path relies upon a receiver-
initiated paradigm, all the way from the receiver to the source.
This means that the information conveyed in IGMP/MLD Report messages
sent by the receiver towards the IGMP/MLD Querier which is often
embedded in the PIM Designated Router that is located as close to the
receiver as possible and typically at the edge of the PIM network
will be used to compute the receiver-initiated, PIM-derived signaled,
P2MP MPLS LSP.
This document extends RSVP-TE for the dynamic computation of
receiver- driven P2MP and MP2MP LSP tree structures. It also
specifies the mRSVP-TE extenstions and procedures for the
interworking between mRSVP-TE and the Protocol Independent Multicast
PIM protocol [RFC4601].
1.1. Motivation
1.1.1. mRSVP-TE
IP multicast distribution trees are receiver-initiated and dynamic by
nature. IP multicast-enabled applications are also bandwidth savvy,
especially in the area of residential IPTV services, where the
delivery of multicast contents to several hundreds of thousands of
IPTV receivers assumes the appropriate level of quality.
Current source-driven P2MP LSP establishment, as defined as in
[RFC4875], assumes a priori knowledge of receiver locations.
Typically, the LSP signaling is initiated by the MPLS router
connected to the source (headend) in such environments. The a priori
knowledge of receiver locations is obtained either through static
configuration or by using another protocol to discover the receivers
and their Join/Prune states for each data stream. On the other hand,
there is no straightforward way to support MP2MP applications by
Li, et al. Expires April 26, 2013 [Page 4]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
using P2MP LSP unless full-meshed P2MP LSPs are set up.
The receiver-driven extension to RSVP-TE defined in this document
will support both P2MP LSPs and MP2MP LSPs. Moreover, it does not
require the root router to know all the receivers' locations a
priori. A protocol for receiver discovery is therefore not needed.
1.1.2. The Need For PIM and mRSVP-TE Interworking
Service providers use IP multicast for the delivery of live TV
broadcasting services. IP multicast traffic is generally forwarded
over core MPLS infrastructures, along PIM- computed multicast
distribution trees.
For the sake of overall service performance, scalability and
robustness, it is recognized that the PIM machinery should be
restricted to the edge of the MPLS network, while IP multicast
traffic is forwarded along P2MP MPLS LSP paths in the MPLS core
network. Such a design assumes that:
o PIM multicast trees are dynamically computed and established at
PIM edge(s), and
o MPLS P2MP LSPs are dynamically computed and established according
to the information conveyed in PIM signaling messages.
Subsequently, IP multicast traffic is forwarded along a PIM multicast
tree from a source connected somewhere at the edge of the MPLS
network, then forwarded along the corresponding Receiver-Driven P2MP
LSP within the MPLS network so that it ultimately reaches receivers
through PIM Designated Routers connected somewhere at the edge of the
MPLS network.
The purpose of such design that combine the dynamics of PIM signaling
with the robustness of traffic-engineered P2MP MPLS tree structures
is to encourage PIM-free core infrastructures for the sake of
operational simplification and performance optimization.
In this document we describe PIM/mRSVP-TE interworking procedures
derived from the framework documented in
[I-D.tao-mpls-pim-interworking]]. [I-D.tao-mpls-pim-interworking]]
defines a framework for interworking procedures between PIM and an
MPLS P2MP LSP signaling protocol to accommodate all PIM operations
with an MPLS network in an optimal and scalable manner, thereby
avoiding the need for a third protocol to dynamically discover and
propagate PIM multicast states across the MPLS network.
The general interworking mechanisms and procedures are those defined
Li, et al. Expires April 26, 2013 [Page 5]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
in [I-D.tao-mpls-pim-interworking] and MUST be implemented as part of
the interworking solution. Therefore, this document only describes
the mRSVP-TE-specific procedures to be implemented.
1.2. Terminology
The following terms are used in this document:
o Sender: Sender refers to the Originator (and hence the Sender) of
the content/payload, as defined in [RFC2205].
o Receiver: Receiver refers to the Receiver of the content/payload,
as defined in [RFC2205].
o Upstream: The direction of flow from content Receiver toward
content Sender, as defined in [RFC2205].
o Downstream: The direction of flow from content Sender toward
content Receiver, as defined in [RFC2205].
o Path-Sender: The sender of RSVP PATH messages, with no correlation
to the direction of multicast content flows. Its flow direction
is irrelevant to that of the Sender, as defined above.
o Path-Receiver: The receiver of RSVP PATH messages, with no
correlation to the direction of multicast content flows.
o Path-Initiator: The Path-Sender that originated a RSVP PATH
message. A Path-Initiator is different from a Path-Sender in that
an intermediate node can be a Path-Sender, but such an
intermediate node cannot create and initiate RSVP PATH messages.
A Path-Initator is a Path-Sender, but a Path-Sender doesn't have
to be a Path-Initiator.
o Path-Terminator: The Path-Receiver that does NOT propagate the
Path message any further. A Path-Terminator is different from a
Path-Receiver in that an intermediate node can be a Path-Receiver,
but such an intermediate node will propagate the Path message to
the next hop.
o Root: A router where a RD P2MP LSP is rooted at. Multicast
content data enter are forwarded along the RD P2MP LSP from the
root to the leaves.
o mPMBR: MPLS-PIM Multicast Border Router where MPLS-PIM
interworking takes place.
Li, et al. Expires April 26, 2013 [Page 6]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
o Leaf or Leaf mPMBR: In the context of a RD P2MP LSP, it is the
mPMBR acting as a leaf for the said LSP.
o Root or Root mPMBR: In the context of a RD P2MP LSP, it is the
mPMBR acting as the root of the said LSP.
o M-Flow Spec: The Multicast Flow Spec (from a mRSVP TE standpoint)
that corresponds to a PIM forwarding rule
1.3. Overview
Although the receiver-driven extensions to RSVP-TE as defined in this
document use the existing sender-driven syntax, there are important
semantic differences that need to be defined for correct
interpretation and interoperability purposes. In the receiver-driven
context, some semantics of RSVP-TE messages are inverted, but the
syntax remains unchanged as much as possible.
In this document, mRSVP-TE denotes the use of the receiver-driven
multicast extensions to RSVP-TE.
The following are some key differences that are specific to the
receiver-driven paradigm:
o The leaf router: The router that receives multicast contents which
will be eventually delivered to the receiver. In this document,
the leaf router will initiate PATH messages.
o L2S (Leaf-To-Source) Destinations: Routers where multicast content
data enter the RD P2MP LSP.
o RSVP P2MP PATH messages are sent by leaf routers of the RD P2MP
LSP towards the root of the said LSP.
o RSVP P2MP RESV messages are sent by the root towards the leaf
routers of the RD P2MP tree structure.
o A RSVP RESV message received by a router is interpreted as a
successful resource reservation made by the upstream node for the
establishment of the RD P2MP tree structure.
o A RSVP RESV message received by a router is interpreted as
successful resource reservation made by the downstream node for
the establishment of an RD MP2MP tree structure.
o Label allocation on incoming interfaces is done prior to sending
RSVP PATH messages upstream for RD P2MP tree structures.
Li, et al. Expires April 26, 2013 [Page 7]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
o Label allocation on incoming interfaces is done prior to sending
RSVP RESV messages upstream for RD MP2MP tree structures.
o For RD P2MP LSP tree structures, a node receiving a RSVP PATH
message first decides if this RSVP PATH message will make the said
node a branch LSR or not. If it is not a branch LSR, it is a
transit LSR. In the case that it will become a transit LSR
because of this PATH message, it will, before sending the RSVP
PATH message upstream, allocate the requested bandwidth as
signaled in the RSVP PATH message on the interface on which the
RSVP PATH message is received. The upstream node can send traffic
soon after successfully reserving resources on the downstream
link, on which the RSVP PATH message SHOULD be received. In the
case that the node is already a branch or a transit node for a
given multicast group before it receives the PATH message, it will
then allocate the requested bandwidth on the interface on which
the RSVP PATH message is received, and send the RESV message to
the node which sends the PATH message without propagating the PATH
message further to the upstream node. For RD P2MP LSPs, a label
is carried by the PATH message and should be used by the upstream
node to forward multicast content downstream.
o For RD MP2MP LSP tree structures, a node will allocate the
requested bandwidth on the interface through which the RSVP PATH
message is sent before sending the RSVP PATH message upstream. A
node receiving a RSVP PATH message MUST first decide if this RSVP
PATH message will make the said node a branch LSR or not. In the
case it will become a transit LSR because of this PATH message, it
will then allocate the requested bandwidth on the interface on
which the RSVP PATH message is received as well as on the
interface through which the RSVP PATH message is sent, before
sending the RSVP PATH message upstream. The downstream node can
send traffic soon after successfully reserving bandwidth on the
upstream link through which the RSVP PATH message SHOULD be sent.
The upstream node can send traffic soon after successfully
reserving bandwidth on the downstream link on which the RSVP PATH
message SHOULD be received. In the case that the node is already
a branch or a transit node for a given multicast group before it
receives the PATH message, it will then allocate the requested
resources on the interface on which the RSVP PATH message is
received, and send back the RESV message to the node that sent the
PATH message without propagating the PATH message further to the
upstream node. The label carried by the PATH message should be
used by the Path-Receiver node to forward data from the Path-
Receiver node to the Path-Sender node, and the label carried by
RESV messages should be used by its corresponding Path-Sender node
to send data from the Path-Sender node to the Path-Receiver node.
Li, et al. Expires April 26, 2013 [Page 8]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
2. Receiver-Driven mRSVP-TE LSP Examples
This section illustrates by two examples how RD P2MP and RD MP2MP LSP
paths are set up, respectively. In both examples, RSVP PATH messages
are initiated by the leaf routers of the LSP.
For the RD P2MP example, a RSVP PATH message carries a label for
sending multicast data downstream. And for the RD MP2MP example,
both RSVP PATH and RESV messages carry a label for sending data
downstream and upstream.
2.1. RD P2MP LSP Example
Sender/Source/Path Terminator/Ingress Router
+---------+
| R1 |
+-----+---+
_
\ \ /\
\ \ \ Path Message w/ Label OBJECT
Resv \ \ \ (msg2)
Message \ \ \
(msg3) \ \ \
_\/ \ \
+----------------+ Path Remerge
| R3 | Creates Branch Point
+----------------+
_ _
/ / /\ \ \ /\
/ / / \ \ \ Path Message (msg1)
Resv Message / / / msg4 \ \ \ w/ Label OBJECT
(msg6) / / / \ \ \
/ / /Path Msg \ \ \
/ / / (msg5) \ \ \
\/_ / / w/Label OBJ _\/ \ \
+----------+ +---+-----+
| R4 | | R5 |
+----------+ +---------+
Path Initiator Path Initiator
Originator ID = R4 Originator ID = R5
L2S Destination = R1 L2S Destination = R1
Session = S Session = S
Figure 1: RD P2MP LSP Example
Li, et al. Expires April 26, 2013 [Page 9]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
In Figure 1, when R5 is added as the first leaf of a mulitcast
distribution tree (multicast LSP), the message flow goes as follows:
R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5.
When the leaf R4 is added, the message flow goes from
R4->msg5->R3->msg6->R4. In this case, when R3 receives msg5, R3
finds out that a RD P2MP LSP has already been set up for the same
multicast group (and the same source). Therefore, R3 is a branch
node for leaves R4 and R5, and R3 will therefore be the last router
to receive and process the PATH message. R3 will then build the
corresponding RESV message and send it back to R4.
The association of the LSP initiated by R4 to the existing RD P2MP
LSP is determined based upon the processing of the SESSION and
L2S_SUB_LSP objects conveyed in the mRSVP-TE messages. The SESSION
and the L2S_SUB_LSP objects are documented later in this draft.
Li, et al. Expires April 26, 2013 [Page 10]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
2.2. RD MP2MP LSP Example
Root/Path Terminator/Ingress Router
+---------+
| R1 |
+-----+---+
_
\ \ /\
\ \ \ Path-mp2mp Message w/ Label OBJECT
Resv \ \ \ (msg2)
Message \ \ \
(msg3) \ \ \
w/ Label OBJECT _\/ \ \
+----------------+ Path-mp2mp
| R3 | (Branch Point)
+----------------+
_ _
/ / /\ \ \ /\
/ / / \ \ \ Path-mp2mp Message (msg1)
Resv Message / / / msg4 \ \ \ (msg1)
(msg6) / / / \ \ \ w/ Label OBJECT
w/ Label OBJECT/ / /Path-mp2mp \ \ \
/ / / Message \ \ \
/ / / (msg5) \ \ \
\/_ / / w/ Label OBJ _\/ \ \
+----------+ +---+-----+
| R4 | | R5 |
+----------+ +---------+
Path-mp2mp Initiator Path-mp2mp Initiator
Originator ID = R4 Originator ID = R5
L2S Destination = R1 L2S Destination = R1
Session = S Session = S
Figure 2: RD MP2MP LSP Example
In Figure 2, when R5 is added as the first leaf (acting as both a
sender and a receiver of multicast content) of a RD MP2MP LSP, the
message flow goes from R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5.
When the leaf R4 is added, the message flow goes from
R4->msg5->R3->msg6->R4.
In this case, when R3 receives msg5, R3 finds out that a RD MP2MP LSP
has already been set up for the same multicast group, and R3
therefore becomes a branch LSR for leaves R4 and R5. R3 will be the
last router to receive and process the corresponding PATH message, R3
will then build a RESV message accordingly, and send it back to R4.
Li, et al. Expires April 26, 2013 [Page 11]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
The association of the LSP initiated by R4 to the existing RD MP2MP
LSP is determined based upon the processing of the SESSION and the
S2L_SUB_LSP objects conveyed in the mRSVP-TE messages. The SESSION
and the L2S_SUB_LSP objects are documented in this draft.
3. Signaling Protocol Extensions
The mRSVP-TE protocol is similar to RSVP-TE protocol as specified in
[RFC4875], [RFC3473], and [RFC3209]. The main difference is that the
leaf routers of a P2MP LSP initiate the RSVP PATH messages toward the
root of the said LSP. Unlike [RFC4875], mRSVP-TE can also be used to
set up RD MP2MP LSPs.
In the context of the mRSVP-TE, the leaf router is the Path-
Originator. The RSVP RESV messages flow in the opposite direction,
and are generated by the root or a branch LSR. RSVP PATH messages
are forwarded in the opposite direction of the multicast traffic.
A RSVP PATH message will be terminated at the root of the RD P2MP LSP
or at an intermediate node if this intermediate node has already
received another PATH message from another leaf router for the same
multicast group. When an intermediate node receives two or more PATH
messages for the same multicast group, the intermediate node will
merge them together. Whether two PATH messages should be merged
depends on the information encoded in the SESSION and L2S-SUB-LSP
objects. The SESSION object encodes multicast group information and
the L2S-SUB-LSP (leaf-to-source sub-LSP) object encodes the multicast
source or multicast root information.
The following sections describe the receiver-driven extensions to the
RSVP-TE protocol. When there is no difference in the protocol, the
usage of [RFC4875] is assumed.
3.1. Operation
3.1.1. Sessions
As specified in [RFC2205], a session is a data flow with a particular
destination and transport-layer protocol. In the context of
multicast, the data flow is essentially a multicast distribution tree
rooted at the RD P2MP LSP or RD MP2MP LSP sources.
For the sake of reliability, two or more sources/roots may be
deployed to distribute the same multicast streams identified by a
mulitcast group address (and possibly the address of the multicast
source, in typical SSM environments). In this document, the
mulitcast group address is encoded in the SESSION object and the
Li, et al. Expires April 26, 2013 [Page 12]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
mulitcast source/root address in the Leaf-to-Source (L2S) sub-LSP
object. Note that the same session can have different sources/roots,
and the same sources/roots can have different sessions.
The processing of SESSION objects in mRSVP TE is different from that
of SESSION objects in RSVP-TE [RFC4875]. In order to uniquely
identify mRSVP TE SESSION objects, different C-Types of SESSION
objects are introduced. This draft documents SESSION objects for
native IPv4/IPv6 multicast applications. Additional SESSION object
types MAY be added in the future.
The new SESSION C-Types are described as follows:
Class Name = SESSION
C-Type
XX+0 mRSVP_TE_P2MP_LSP_TUNNEL_IPv4 C-Type
XX+1 mRSVP_TE_P2MP_LSP_TUNNEL_IPv6 C-Type
XX+2 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv4 C-Type
XX+3 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv6 C-Type
Where XX is a number to be allocated by IANA.
Figure 3: New SESSION C-Types
The new SESSION C-Type MUST be used in all mRSVP-TE messages.
3.1.2. L2S Sub-LSPs
A RD P2MP LSP is composed of one or more L2S sub-LSPs, which are
merged together at the branch nodes. There are two ways to identify
each L2S sub-LSP:
o From the Sender's perspective, each sub-LSP is identified by the
SESSION object, the SENDER_TEMPLATE object and S2L_SUB_LSP object,
as specified in [RFC4875]. The SESSION object encodes the P2MP
ID, Tunnel ID, and Extended Tunnel ID. The P2MP ID is unique
within the scope of the sender (ingress LSR) and remains constant
throughout the lifetime of the RD P2MP tree structure. The
Extended Tunnel ID, which remains constant throughout the lifetime
of the RD P2MP tree structure, contains the sender's address to
make sure the identifier is globally unique. Finally, the Tunnel
ID also remains constant throughout the lifetime of the RD P2MP
tree structure. The SENDER_TEMPLATE object contains the ingress
LSR source address. The S2L_SUB_LSP object contains the
destination address of the sub-LSP.
Li, et al. Expires April 26, 2013 [Page 13]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
o From the Receiver's perspective, each sub-LSP is identified by a
new SESSION object, a new SENDER_TEMPLATE object and a new
L2S_SUB_LSP object. The SESSION object, different from the one
used in typical sender-driven environments, contains information
to be used as the key to associate different PATH messages
originated from different leaves. The SENDER_TEMPLATE object
contains the Path-Originator's address, which is actually the leaf
router of the corresponding RD P2MP LSP. The L2S_SUB_LSP object
contains the source or root address of the sub-LSP, i.e., the data
Sender's address. The SESSION, SENDER_TEMPLATE and L2S_SUB_LSP
objects all together will identify the multicast group address,
the multicast address source, and a mulitcast leaf router.
This document assumes the receiver-driven approach.
Once an LSR receives a receiver-driven PATH message that contains
both the SESSION and L2S_SUB_LSP objects, the LSR will use these
objects to determine whether the sub-LSP signaled by this PATH
message should be merged with an existing RD P2MP LSP.
3.1.3. Path Originator and Data Receiver
This draft documents a new type of SENDER_TEMPLATE object, which
contains the Path-Originator's IP address and describes the identity
of the Path Originator.
In [RFC2205] and [RFC4875], the sender is a Path Originator that also
forwards multicast data. In the receiver-driven context, Path
Originators and data senders may be different. For RD P2MP LSPs,
Path Originators are actually the leaf routers. For RD MP2MP LSPs,
Path Originators are also both the data senders and leaf routers.
In this document, the same Object Class SENDER_TEMPLATE with a
different C-Type is used to represent and identify a Path Originator.
In the case of RD P2MP LSPs, the SENDER_TEMPLATE object describes the
identify of a leaf router. In the case of RD MP2MP LSPs, the
SENDER_TEMPLATE object describes the identify of an LSR that behaves
as both a data sender and a data receiver.
All the SESSION, L2S_SUB_LSP and SENDER_TEMPLATE objects together
contained in a RSVP PATH message will uniquely identify a L2S sub-
LSP.
3.1.4. Explicit Routing
An EXPLICIT_ROUTE Object (ERO) is used to optionally specify the
explicit route of an L2S sub-LSP. Each signaled ERO corresponds to a
particular L2S_SUB_LSP object. Details of ERO encoding are specified
Li, et al. Expires April 26, 2013 [Page 14]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
in Section 4.5 of [RFC4875]. Within the Receiver-Driven context, ERO
objects are encoded in a reverse order.
When a RSVP PATH message signals a L2S sub-LSP, the EXPLICIT_ROUTE
object encodes the path from the leaf to the root LSR. The PATH
message also includes the L2S_SUB_LSP object for the L2S sub-LSP
being signaled. The < [<EXPLICIT_ROUTE>], <L2S_SUB_LSP>> tuple
represents the L2S sub-LSP and is referred to as the sub-LSP
descriptor.
The absence of an ERO should be interpreted as requiring hop-by-hop
reverse forwarding for the sub-LSP based on the root address field of
the L2S_SUB_LSP object.
3.2. PIM-mRSVP TE Interworking Operation
3.2.1. New M-Flow Spec Types
[I-D.tao-mpls-pim-interworking] introduces four types of M-Flow
specs, each corresponding to a type of PIM forwarding state:
o M-Flow Spec Type-1(value 1) for (*, *, RP);
o M-Flow Spec Type-2(value 2) for (*, G);
o M-Flow Spec Type-3(value 3) for (S, G);
o M-Flow Spec Type-4(value 4) for (S, G, RPT);
These M-Flow Spec types will be signaled in-band across the MPLS
network by mRSVP-TE. Their formats are specified in
[I-D.tao-mpls-pim-interworking]. mRSVP-TE is used to (1) initiate the
signaling of a RD P2MP LSP or a sub-LSP, (2) merge a sub-LSP into an
existing LSP, or (3) delete it when a downstream router does not need
it, based upon the information conveyed in the said M-Flow Specs.
This implies that:
o M-Flow specs are encapsulated into mRSVP-TE PATH messages, and
o M-Flow specs are used to identify a given multicast session so
that a receiver-driven, traffic-engineered P2MP LSP path will be
computed and established accordingly.
When an M-Flow spec is generated and passed to mRSVP-TE based upon
the MPLS-PIM interworking procedures enforced by an mPMBR, mRSVP-TE
first determines if this M-Flow spec leads to the grafting of an
additional sub-LSP, by using the procedure described in
[I-D.tao-mpls-pim-interworking]. If the contents of the signaled
Li, et al. Expires April 26, 2013 [Page 15]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
M-Flow Spec does not mandate the grafting of an additional sub-LSP,
the M-Flow is then bound to an existing RD P2MP LSP.
If a new sub-LSP needs to be grafted to an existing receiver-driven,
traffic engineered P2MP MPLS LSP according to the information
conveyed in the M-Flow spec, the procedures documented in the
following subsections MUST be followed.
3.2.2. Signaling An Unidentified Sub-LSP
When a sub-LSP is signaled from a leaf mPMBR towards the root,
mRSVP-TE may not have determined if this sub-LSP would lead to the
computation and the establishment of a new RD P2MP LSP or the
grafting of an additional sub-LSP to an existing RD P2MP MPLS LSP.
This sub-LSP is denoted as an "Unidentified" sub-LSP.
mRSVP-TE then works as follows to signal an unidentified sub-LSP.
3.2.2.1. Sending A Path Message For An Unidentified Sub-LSP
o Set 0 as the tunnel ID field in the session object
o Set the "Tunnel Identifier with M-Flow Spec Session" attribute
flag to 1
o Encode the M-Flow spec in the mflow spec object list according to
the "Path Message Change and Encoding".
3.2.2.2. Receiving A Path Message For An Unidentified Sub-LSP
When a LSR receives a PATH message with 0 as the tunnel ID and the
"Tunnel Identifier with MFLOW spec" flag set to 1, it processes the
sub-LSP grafting request as an unidentified sub-LSP as follows:
o Use the included M-Flow spec and binding policy to determine which
RD P2MP LSP the sub-LSP belongs to. See Sections 3.1.2 and 3.1.3
of [I-D.tao-mpls-pim-interworking].
o When the sub-LSP does not merge into an existing RD P2MP MPLS LSP,
the PATH message will reach the root, which can then determine if
the sub-LSP assumes the computation of a new RD P2MP MPLS LSP, or
merges into an existing RD P2MP MPLS LSP.
o The sub-LSP is then assigned the tunnel ID. The root sets the
"Tunnel Identifier with MFLOW spec" session attribute flag to 0,
and completes the rest of the signaling using mRSVP-TE procedures.
Li, et al. Expires April 26, 2013 [Page 16]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
o Each LSR merges the M-Flow spec in the mflow spec object list
using mflow_specs_merge(T, F) when the tunnel is identified.
3.3. Path Messages
The mechanism specified in this document allows a RD P2MP/MP2MP LSP
to be signaled using one or more RSVP PATH messages. Each PATH
message MAY signal one or several L2S sub-LSPs.
A receiver-driven P2MP MPLS LSP uses the PATH message to carry the
LABEL object upstream from the leaf router towards the Sender. With
a receiver-driven usage of the RSVP PATH messages, the LABEL_REQUEST
object carried by the PATH message is no longer mandatory. It
becomes optional for receiver-driven PATH messages, as specified in
Figure 4 below.
The PIM/mRSVP-TE inter-working procedures introduce a new session
attribute called "Tunnel Identifier with MFLOW spec". By default, it
is set to 0. For an unidentified sub-LSP, the attribute is set by
the Path Sender to indicate that a router receiving this message must
process the information conveyed in M-Flow specs to identify the
corresponding session and make a decision accordingly (e.g.,
contribute to the grafting of a new sub-LSP to the relevant RD P2MP
MPLS LSP).
The mRSVP-TE PATH message is extended to include a list of M-Flow
Spec Objects:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
[ <LABEL_REQUEST> ]
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[<L2S_SUB_LSP>]
[mflow spec list]
< mflow spec list > ::= <PMSI_MFLOW_SPEC> [< mflow spec list >]
Figure 4: Path Message Extensions
Li, et al. Expires April 26, 2013 [Page 17]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
The SESSION object encodes information about the being-signalled
multicast group address. The SESSION object together with the
L2S_SUB_LSP object will be used as the key to associate different
sub-LSPs to the same RD P2MP LSP.
Using [RFC4875] as the reference specification, the LABEL object is
added to the <sender descriptor> as specified in Figure 5.
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<LABEL>
Figure 5: Sender Descriptor
The LABEL object is defined in section 4.1 of [RFC3209].
Note that the mRSVP-TE PATH messages convey the LABEL_REQUEST object
as an optional object. If the PATH message signals a RD P2MP LSP,
the LABEL_REQUEST object is not used. If the PATH message signals a
RD MP2MP LSP, the LABEL_REQUEST object is required to ask for labels
from the upstream LSR.
3.4. Resv Messages
The mRSVP-TE protocol does not need any change to the basic RESV
messages, as specified in Section 6.1 of [RFC4875], assuming the
receiver-driven-specific SESSION objects of the new C-Types are used.
For receiver-driven P2MP LSPs, the PATH message carries the LABEL
object, and thus, the RESV message doesn't have to carry the LABEL
object anymore. But for RD MP2MP LSPs, both PATH and RESV messages
will carry LABEL objects for sending and receiving multicast content.
Within the context of RD MP2MP LSPs, one of the directions is
established as per [RFC2209] Thus, this document describes how the
use of the LABEL object in the FF Flow Descriptor and SE Filter Spec
is modified from Mandatory to Optional, as described in Figure 6.
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> [ <LABEL> ]
[ <RECORD_ROUTE> ]
[ <L2S_SUB_LSP> ]
<SE filter spec> ::= <FILTER_SPEC> [ <LABEL> ] [ <RECORD_ROUTE> ]
[ <L2S_SUB_LSP> ]
Li, et al. Expires April 26, 2013 [Page 18]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
Figure 6: Resv Message Extensions
3.5. PathErr Messages
The receiver-driven PathErr messages have the same syntax and
utilization as the PathErr message described in [RFC4875] with the
difference in the <sender descriptor> carried by the PathErr message.
The receiver-driven PathErr message will use the <sender descriptor>
defined in this document, the same as that carried by the PATH
messages which the PathErr messages correspond to.
3.6. ResvErr Message
The receiver-driven ResvErr messages have the same syntax and
utilization as the ResvErr message described in [RFC4875] But the
ResvErr messages will be processed as per this document, given that
the <FF flow descriptor> and the <SE filter spec> can optionally
contain the LABEL object instead of mandating the use of the LABEL
object. The optional use of the LABEL object is conditioned by the
nature of the RD P2MP LSP, either uni-directional (P2MP) or bi-
directional (MP2MP).
3.7. PathTear Messages
The receiver-driven PathTear messages have the same syntax and
utilization as the PathTear messages described in [RFC4875], except
for the <sender descriptor> carried by the PathTear messages. The
receiver-driven PathTear messages will use <sender descriptor>
defined in this document, the same as that carried by the PATH
messages which the PathTear messages correspond to.
4. New and Updated Objects
4.1. SESSION Object
A mRSVP-TE LSP SESSION object is used. This object uses the existing
SESSION C-Num. New C-Types are defined to uniquely identify any RD
P2MP LSP. This SESSION object has a similar structure as the
existing point-to-point RSVP-TE SESSION object. However, the
destination address is set to the P2MP ID instead of the unicast
Tunnel Endpoint address. All L2S sub-LSPs that are part of the same
RD P2MP LSP share the same SESSION object. This SESSION object
identifies the RD P2MP LSP.
The combination of the SESSION, the SENDER_TEMPLATE and the
L2S_SUB_LSP objects identifies each L2S sub-LSP. This follows the
existing P2P RSVP-TE notion of using the SESSION object for
Li, et al. Expires April 26, 2013 [Page 19]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
identifying a P2P LSP, which in turn can contain multiple LSPs, each
distinguished by a unique SENDER_TEMPLATE object.
The mechanism for propagating the Tunnel ID value defined in the
SESSION object is outside the scope of this document, the mechanism
for setting the Tunnel ID values defined in the SESSION object, and
the mechanism for associating the values defined in the SESSION
object with PIM-signaled information is defined in
[I-D.tao-mpls-pim-interworking]
4.1.1. mRSVP-TE IPv4 LSP Tunnel SESSION Object
Class = SESSION, mRSVP-TE_LSP_TUNNEL_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mRSVP-TE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
mRSVP-TE-LSP-Tunnel-IPv4-SESSION-Object
Figure 7
mRSVP-TE ID
A 32-bit identifier used in the SESSION object that remains constant
during the lifetime of the RD P2MP LSP. It encodes the mRSVP-TE
Identifier that is unique within the scope of the Root LSR.
Tunnel ID
A 16-bit identifier used in the SESSION object that remains constant
during the lifetime of the RD P2MP LSP.
Extended Tunnel ID
A 32-bit identifier used in the SESSION object that remains constant
during the lifetime of the RD P2MP LSP. Root LSRs that wish to have
a globally unique identifier for the RD P2MP LSP SHOULD place their
Li, et al. Expires April 26, 2013 [Page 20]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
tunnel sender address here. A combination of this address with the
mRSVP-TE ID and Tunnel ID provides a globally unique identifier for
the RD P2MP LSP.
4.1.2. mRSVP-TE IPv6 LSP Tunnel SESSION Object
This is the same as the IPv4 LSP SESSION object with the difference
that the extended tunnel ID is set to a 16-byte identifier [RFC2209].
Class = SESSION, mRSVP-TE_LSP_TUNNEL_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mRSVP-TE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (16 bytes) |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
mRSVP-TE-LSP-Tunnel-IPv6-SESSION-Object
Figure 8
4.2. SENDER_TEMPLATE Object
The SENDER_TEMPLATE object contains the ingress LSR source address.
The LSP ID can be changed to allow a sender to share resources with
itself. Thus, multiple instances of the RD P2MP LSP can be created,
each with a different LSP ID. The instances can share resources with
each other. The L2S sub-LSPs corresponding to a particular instance
use the same LSP ID.
4.2.1. mRSVP-TE LSP IPv4 Tunnel SENDER_TEMPLATE Object
Class = SENDER_TEMPLATE, mRSVP-TE_LSP_TUNNEL_IPv4 C-Type = TBD.
Li, et al. Expires April 26, 2013 [Page 21]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
mRSVP-TE-LSP-Tunnel-IPv4-SENDER_TEMPLATE-Object
Figure 9
IPv4 tunnel sender address
See [RFC2209].
LSP ID
See [RFC2209].
4.2.2. SENDER_TEMPLATE Objects
The SENDER_TEMPLATE object contains the IP address of the Path-
Initiator LSR. The LSP ID can be changed to allow a sender to do a
certain level of resource sharing. Thus, multiple instances of the
same RD P2MP LSP can be created, each with a different LSP ID. The
instances can share resources with each other. The L2S sub-LSPs
corresponding to a particular instance use the same LSP ID.
4.2.2.1. Multicast LSP IPv4 SENDER_TEMPLATE Objects
Class = SENDER_TEMPLATE, mRSVP_TE_LSP_TUNNEL_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Leaf Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: mRSVP-TE Multicast LSP SENDER_TEMPLATE Objects
IPv4 Leaf Router Address: The IPv4 address of the Leaf Router.
Li, et al. Expires April 26, 2013 [Page 22]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
LSP ID: A 2-byte identifier that can be changed to allow it to share
resources with itself. Its usage is the same as that described in
[RFC3209].
4.2.2.2. Multicast LSP IPv6 SENDER_TEMPLATE Objects
Class = SENDER_TEMPLATE, mRSVP-TE_LSP_TUNNEL_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Leaf Router address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: mRSVP-TE LSP IPv6 SENDER_TEMPLATE Objects
IPv6 Leaf Router Address: The IPv6 address of the Leaf Router.
LSP ID: A 2-byte identifier that can be changed to allow it to share
resources with itself. Its usage is the same as that described in
[RFC2209].
4.3. L2S_SUB_LSP Objects
An L2S_SUB_LSP object identifies a particular L2S sub-LSP that is (to
be) grafted to a given RD P2MP LSP, as explained earlier in this
document.
4.3.1. L2S_SUB_LSP IPv4 Objects
L2S_SUB_LSP Class = TBD, L2S_SUB_LSP_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 L2S Sub-LSP Root Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Li, et al. Expires April 26, 2013 [Page 23]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
Figure 12: L2S_SUB_LSP IPv4 Objects
IPv4 L2S Sub-LSP Root Address: IPv4 address of the L2S sub-LSP
sender.
4.3.2. L2S_SUB_LSP IPv6 Objects
L2S_SUB_LSP Class = TBD, L2S_SUB_LSP_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 L2S Sub-LSP Root Address (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: L2S_SUB_LSP IPv6 Object
4.4. FILTER_SPEC Objects
The FILTER_SPEC object is canonical to the SENDER_TEMPLATE object.
4.4.1. mRSVP-TE LSP_IPv4 FILTER_SPEC Objects
Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = TBD.
The format of the mRSVP-TE LSP_IPv4 FILTER_SPEC object is identical
to the mRSVP_TE_LSP_TUNNEL_IPv4 SENDER_TEMPLATE object.
4.4.2. mRSVP-TE LSP_IPv6 FILTER_SPEC Objects
The format of the mRSVP-TE LSP_IPv6 FILTER_SPEC object is identical
to the mRSVP_TE_LSP_TUNNEL_IPv6 SENDER_TEMPLATE object.
4.5. MFLOW Object
New Object: Class = PMSI_MFLOW_SPEC (TBA)
Class = PMSI_MFLOW_SPEC, MCAST_GROUP_SRC_LIST, C-Type = XXX(TBA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Num groups |ACT|M| Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Li, et al. Expires April 26, 2013 [Page 24]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
| Multicast Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address m (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Joined Sources | Number of Pruned Sources |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Joined Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address 1 (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pruned Source Address n (Encoded-Source format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"ACT": 0, 1, or 2 to indicate that the received M-Flow specs are
to replace, be added into, or be removed from the existing
M-FLOW specs, respectively.
'M' bit: If set, it indicates that there are more entries
following. This is to deal with fragmentation issues.
"Policy" - M-Flow aggregation policy.
Li, et al. Expires April 26, 2013 [Page 25]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
Figure 14: MFLOW Object
An Encoded-Source address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Rsvd |S|W|R| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 15: Encoded-Source
An Encoded-Group address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type |B| Reserved |Z| Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 16: Encoded-Group
Other fields are from [RFC4601], and MUST be set according to the PIM
specification.
Li, et al. Expires April 26, 2013 [Page 26]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
The encoding of each M-Flow spec is defined by its type:
For M-Flow Spec Type-1 (*, *, RP):
The Multicast Group Address 1 gives the group range. It is
encoded as the Multicast Group Address + Mask Length.
A one-entry Join or Prune source list is used for the group
range and the source address of the entry is set to the RP address.
(S, G, RPT) list can be encoded in this M-Flow Spec Type by
adding them in Join/Prune source list for the corresponding multicast group.
For M-Flow Spec Type-2 (*, G):
The Multicast Group Address 1 gives the group address. It is
encoded as the Multicast Group Address + full mask length.
A source entry in Join or Prune source list is used for the
group, and the source address of the entry is set to the RP address.
(S, G, RPT) list can be encoded in this M-Flow Spec Type by adding them
in Join/Prune source list for the corresponding multicast group.
For M-Flow Spec Type-3 (S, G):
Multicast Group Address + Full Length Mask Length identify
the multicast group;
Source address is encoded into the source list.
For M-Flow Spec Type-4 (S, G, RPT):
Multicast Group Address + Full Length Mask Length identify
the multicast group.
Source address is encoded into the source list with 'R' bit
set and 'W' bit cleared. See [RFC4601] "Source Address" encoding
for the definition of these bits.
Figure 17: Encoding Spec for M-FLOW
5. Fast Re-Route Considerations
The Fast Re-Route mechanisms and procedures specified in [RFC4090]
will not be applicable to the receiver-driven extension to RSVP-TE
Li, et al. Expires April 26, 2013 [Page 27]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
described in this document, since the PATH and RESV messages are sent
in different directions.
Extensions to mRSVP-TE to support Fast Re-Route are described in
[I-D.zlj-mpls-mrsvp-te-frr].
6. Backward Compatibility
A receiver-driven P2MP LSP mechanism uses different C-Types than
those defined in [RFC4875]. If LSRs do not recognize the receiver-
driven C-Types, they will not support the receiver-driven extensions
described in this document. LSRs that do not support such C-Types
MUSTsend Path Error [TBD] back to the Path Originator.
Elaboration will be provided in the further versions of the draft.
7. Acknowledgements
We would like to thank Lin Han and Katherine Zhao for their comments
on early drafts of this work. In particular we would like to thank
Lou Berger and Eric Osborne for their very helpful questions,
comments and suggestions.
8. IANA Considerations
This section is TBD.
9. Security Considerations
It is a requirement [I-D.jacquenet-mpls-rd-p2mp-te-requirements]that
any mRSVP-TE solution developed to meet some or all of the
requirements expressed in this document MUST include mechanisms to
enable the secure establishment and management of mRSVP-TE MPLS-TE
LSPs. This includes, but is not limited to:
o A receiver MUST be authenticated before it is allowed to establish
a RD P2MP LSP with its source, in addition to hop-by-hop security
issues identified by in [RFC3209] and [RFC4206].
o Mechanisms to provide guarantees about the identity of the ingress
LSR of a RD P2MP LSP;
o Mechanisms to ensure that communicating signaling entities can
verify each other's identities;
Li, et al. Expires April 26, 2013 [Page 28]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
o Mechanisms to ensure that control plane messages are protected
against spoofing and tampering;
o Mechanisms to ensure that unauthorized leaves or branches are not
grafted to a given RD P2MP LSP
o Mechanisms to protect signaling messages from snooping.Note that
mRSVP-TE signaling mechanisms built on P2P RSVP-TE signaling are
likely to inherit all the security issues and solutions associated
with RSVP-TE. These problems may be exacerbated in mRSVP-TE
situations where security associations MAY be required between an
ingress LSR and multiple egress LSRs. Such issues are similar to
security issues for IP multicast.
o It is a requirement that documents offering solutions for P2MP
LSPs MUST have detailed security sections.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol
(RSVP) -- Version 1 Message Processing Rules", RFC 2209,
September 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, April 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.
Li, et al. Expires April 26, 2013 [Page 29]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
[RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A.
Ayyangar, "Encoding of Attributes for Multiprotocol Label
Switching (MPLS) Label Switched Path (LSP) Establishment
Using Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 4420, February 2006.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
10.2. Informative References
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS signaling
protocols", RFC 3468, February 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering",
RFC 3564, July 2003.
[RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J.
Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
Switched Paths (LSPs)", RFC 5467, March 2009.
[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
Li, et al. Expires April 26, 2013 [Page 30]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012.
[RFC6517] Morin, T., Niven-Jenkins, B., Kamite, Y., Zhang, R.,
Leymann, N., and N. Bitar, "Mandatory Features in a Layer
3 Multicast BGP/MPLS VPN Solution", RFC 6517,
February 2012.
[I-D.zlj-mpls-mrsvp-te-frr]
Zhao, K., Li, R., and C. Jacquenet, "Fast Reroute
Extensions to Receiver-Driven RSVP-TE for Multicast
Tunnels", draft-zlj-mpls-mrsvp-te-frr-00 (work in
progress), July 2012.
[I-D.tao-mpls-pim-interworking]
Tao, B., "MPLS PIM Inter-working",
draft-tao-mpls-pim-interworking-00 (work in progress),
July 2012.
[I-D.jacquenet-mpls-rd-p2mp-te-requirements]
Jacquenet, C., Zhao, Q., and B. Zhang, "Requirements for
Receiver-Driven Traffic Engineered Point-to-Multi-Point
(P2MP) MPLS Tree Structures",
draft-jacquenet-mpls-rd-p2mp-te-requirements-02 (work in
progress), October 2012.
Authors' Addresses
Renwei Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: renwei.li@huawei.com
Quintin Zhao
Huawei Technologies
Boston, MA
USA
Email: quintin.zhao@huawei.com
Li, et al. Expires April 26, 2013 [Page 31]
Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012
Christian Jacquenet
France Telecom Orange
4 rue du Clos Courtel
35512 Cesson Sevigne,,
France
Email: christian.jacquenet@orange.com
Robert Tao
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: robert.tao@huawei.com
Boris Zhang
Telus Communications
200 Consilium Pl Floor 15
Toronto, ON M1H 3J3,
Canada
Email: Boris.Zhang@telus.com
Li, et al. Expires April 26, 2013 [Page 32]