Receiver-Driven Multicast Traffic Engineered Label Switched Paths
draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Richard Li , Quintin Zhao , Christian Jacquenet | ||
| Last updated | 2012-03-05 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00
Network Working Group R. Li
Internet-Draft Q. Zhao
Intended status: Standards Track Huawei Technologies
Expires: August 30, 2012 C. Jacquenet
France Telecom
March 4, 2012
Receiver-Driven Multicast Traffic Engineered Label Switched Paths
draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00.txt
Abstract
This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for the setup of Receiver-Driven Traffic
Engineered(TE) point-to-multipoint (P2MP) and multipoint-to-multipoint
(MP2MP)Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS)
and Generalized MPLS (GMPLS)networks.
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 August 30, 2012.
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
Li, et al. Expires August 30, 2012 [Page 1]
Internet-Draft RD Multicast RSVP-TE February 2012
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 August 30, 2012 [Page 2]
Internet-Draft RD Multicast RSVP-TE February 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Receiver-Driven mRSVP-TE LSP Exampls . . . . . . . . . . . 8
2. Signaling Protocol Extensions . . . . . . . . . . . . . . . . 10
2.1. L2S Sub-LSPs . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Explicit Routing . . . . . . . . . . . . . . . . . . . . . 12
2.3. L2S Sub-LSPs and Path Messages . . . . . . . . . . . . . . 12
2.4. Resv Message Extensions . . . . . . . . . . . . . . . . . 13
2.5. PathErr Message Extensions . . . . . . . . . . . . . . . . 14
2.6. ResvErr Message Extensions . . . . . . . . . . . . . . . . 14
2.7. PathTear Message Extensions . . . . . . . . . . . . . . . 14
2.8. SESSION Object . . . . . . . . . . . . . . . . . . . . . . 15
2.8.1. mRSVP-TE LSP Tunnel IPv4 SESSION Object . . . . . . . 16
2.8.2. mRSVP-TE LSP Tunnel IPv6 SESSION Object . . . . . . . 16
2.9. SENDER_TEMPLATE Object . . . . . . . . . . . . . . . . . . 17
2.9.1. mRSVP-TE LSP Tunnel IPv4 SENDER_TEMPLATE Object . . . 17
2.9.2. mRSVP-TE LSP Tunnel IPv6 SENDER_TEMPLATE Object . . . 17
2.10. L2S_SUB_LSP Object . . . . . . . . . . . . . . . . . . . . 18
2.10.1. L2S_SUB_LSP IPv4 Object . . . . . . . . . . . . . . . 18
2.10.2. L2S_SUB_LSP IPv6 Object . . . . . . . . . . . . . . . 19
2.11. FILTER_SPEC Object . . . . . . . . . . . . . . . . . . . . 19
2.11.1. P2MP LSP_IPv4 FILTER_SPEC Object . . . . . . . . . . . 19
2.11.2. mRSVP-TE LSP_IPv6 FILTER_SPEC Object . . . . . . . . . 19
2.11.3. mRSVP-TE SECONDARY_EXPLICIT_ROUTE Object (SERO) . . . 20
2.11.4. mRSVP-TE SECONDARY_RECORD_ROUTE Object (SRRO) . . . . 20
3. In-Band and Out-Band Signalling . . . . . . . . . . . . . . . 20
3.1. In-Band Signalling . . . . . . . . . . . . . . . . . . . . 20
3.2. Out-Band Signalling . . . . . . . . . . . . . . . . . . . 20
4. Broadcast Interfaces . . . . . . . . . . . . . . . . . . . . . 21
5. Fast Re-Route Considerations . . . . . . . . . . . . . . . . . 21
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Li, et al. Expires August 30, 2012 [Page 3]
Internet-Draft RD Multicast RSVP-TE February 2012
1. Introduction
Multiparty multimedia applications are getting greater attention in
the telecom world. Such applications are QoS-demanding and can
therefore benefit from the activation of MPLS traffic engineering
capabilities that lead to the dynamic computation and establishment
of MPLS LSPs whose characteristics comply with application-specific
QoS requirements. P2MP-TE [RFC4875] defines a procedure to set up
point-to-multipoint LSPs from sender to receivers. This document
extends RSVP-TE for the dynamic computation of receiver-driven P2MP
and MP2MP LSP tree structures.
1.1. Motivation
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, and the LSP signalling is initiated and driven by
the data sender(headend).
Receiver-driven MPLS P2MP/MP2MP tree structures do not require sender
to maintain/discover receiver information a priori, and their design
should better accommodate the receiver-specific QoS conditions, such as
network access capabilities.
1.2. Terminology
The following terms are used in this document:
o Sender: Sender refers to the Originator (and hence) 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].
Li, et al. Expires August 30, 2012 [Page 4]
Internet-Draft RD Multicast RSVP-TE February 2012
o Path-Sender: The sender of RSVP PATH messages, with NO correlation
to the direction of content/payload flows. Its flow direction is
irrelevant to that of Sender defined above. All other control
messages discussed in this document will use this as the
reference.
o Path-Receiver: The receiver of RSVP PATH messages, with NO
correlation to the direction of content/payload flows.
o Path-Initiator: The Path-Sender that originated a RSVP PATH
message. This is different from Path-Sender in that an
intermediate node can be a Path-Sender, but such an intermediate
node cannot create and initiate the RSVP PATH message.
o Path-Terminator: The Path-Receiver that does NOT propagate the
Path message any further. This is different from 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 multcast LSP is rooted at. Data enters the
root and then is distributed to leaves along the P2MP/MP2MP LSP
1.3. Overview
Although receiver-driven P2MP LSPs as defined in this document use
existing sender-driven syntax, there are important semantic
differences that need to be defined for correct interpretation and
interoperability. In the receiver-driven approach, we inverted the
semantics of P2MP-TE RSVP [RFC4875] messages, while keeping the
syntax unchanged.
Following are some key differences that are specific to the receiver-
driven paradigm:
o The leaf router the receiver is connected to: that is, upon receipt
of an IGMP/MLD Report message, the router that embeds the IGMP/MLD Querier
would typically trigger a RSVP_PATH message towards the source.
We keep the same convention with respect to data flows, which are opposite
to control flows.
o L2S (Leaf-to-Source) Destinations (the sender or root) are routers where
user data payload traffic enters the LSP.
o RSVP P2MP PATH messages traverse from receivers to the root.
o RSVP P2MP RESV messages traverse from the root to the leaf routers of the
P2MP tree strcuture.
Li, et al. Expires August 30, 2012 [Page 5]
Internet-Draft RD Multicast RSVP-TE March , 2012
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
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 a MP2MP tree structure.
o Label allocation on incoming interfaces is done prior to sending
RSVP PATH messages upstream for P2MP tree structures.
o Label allocation on incoming interfaces is done prior to sending
RSVP RESV messages upstream for MP2MP tree structures.
o For 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,
then it will, before sending the RSVP PATH message upstream,
allocate required bandwidth 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 before it receives
the PATH message, then it will allocate required 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
P2MP LSPs, a label is carried by the PATH message and should be
used by the upstream node when distributing the data from
upstream to downstream.
o For MP2MP LSP tree structures, a node will allocate required 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, then it will allocate
required bandwidth on the interface on which the RSVP PATH message
is received and will allocate required bandwidth 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 a already a branch or
a transit node before it receives the PATH message, then it will
allocate required resources on the interface on which the RSVP
PATH message is received, and send the RESV message to the node
Li, et al. Expires August 30, 2012 [Page 6]
Internet-Draft RD Multicast RSVP-TE March , 2012
which sends 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 deliver data from the Path-
Sender node to the Path-Receiver node.
o For the sake of readability, from now on, all mRSVP-TE messages will be
used to represent all the RSVP-TE messages which are used for the
computation of receiver-driven P2MP/MP2MP tree structures.
o For the sake of readability, from now on all mRSVP-TE LSPs will be used
to represent all P2MP and/or MP2MP LSPs in receiver-driven (RD) multicast
P2MP/MP2MP MPLS environments. We will sometimes use RD P2MP TE LSP
or RD MP2MP TE LSP to represent such receiver-driven multicast LSPs.
Li, et al. Expires August 30, 2012 [Page 7]
Internet-Draft RD Multicast RSVP-TE March , 2012
1.4. Receiver-Driven mRSVP-TE LSP Exampls
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: P2MP EXAMPLE
Figure 1 shows that R5 is added as the first leaf of the RD P2MP TE
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 the RD P2MP LSP has
already been set up for R5: therefore, R3 finds itself a branch node for
leaf R4 and R5, so it will terminate the PATH message and 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 on the processing of the session object
from the mRSVP-TE message. This session object is further documented in Section 2
of this draft.
Li, et al. Expires August 30, 2012 [Page 8]
Internet-Draft RD Multicast RSVP-TE March , 2012
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 \ \ \ w/ Label OBJECT
(msg6) / / / \ \ \
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: MP2MP Example
Figure 2 shows that R5 is added as the first leaf
(as both a sender and a receiver) of the RD MP2MP TE LSP, the message
flow goes from R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. When the
leaf R4 (both receiver and sender)is added, the message flow goes
from R4->msg5->R3->msg6. In this case, when R3 receives msg5, R3
finds out that the RD MP2MP LSP has already been set up for R5, and R3
will become the branch LSR for the leaf R4 and R5, so it will
terminate the PATH message, build a RESV message and send the RESV
message back to R4. The association of the LSP initiated by R4 to
Li, et al. Expires August 30, 2012 [Page 9]
Internet-Draft RD Multicast RSVP-TE March , 2012
the existing MP2MP LSP is determined based on the processing of the
session object from the mRSVP-TE message. This session object is further
documented in Section 2 of this draft.
2. Signaling Protocol Extensions
mRSVP-TE is similar to the RSVP-TE protocol as specified in [RFC4875],
[RFC3473] and [RFC3209], but differs in that the receivers (or the leaf
routers they are connected to)
initiate the RSVP PATH messages toward the sender. Compared with
[RFC4875], mRSVP-TE to be specified in this document can also be used
to set up MP2MP LSPs.
Within RD P2MP/MP2MP LSP tree structure environments, the Receiver is the
Path-Originator. The RSVP RESV messages flow in the opposite direction as
compared to the RSVP PATH messages, i.e. RSVP RESV messages are generated
by the Sender or a branch LSR.
Within this receiver-driven context, the processing of receiver-
initiated mRSVP-TE P2MP messages is different from that of the
other RSVP messages. Following the method used by RSVP-TE and P2MP
RSVP-TE, this draft documents the use of new SESSION C-Type 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.
The new SESSION C-Type MUST be used in all receiver-driven P2MP
RSVP-TE messages.
The following sections describe the receiver-driven P2MP RSVP-TE
extensions to the P2MP RSVP-TE protocol. When there is no difference
in the protocol, usage of [RFC4875] is assumed.
Li, et al. Expires August 30, 2012 [Page 10]
Internet-Draft RD Multicast RSVP-TE March , 2012
2.1. L2S Sub-LSPs
A RD P2MP or MP2MP LSP is composed of one or more L2S sub-LSPs, which
are merged together at the branch nodes.
An L2S sub-LSP exists within the context of a RD P2MP or MP2MP LSP.
There are two ways to identify each 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 [RFC 4875]. The SESSION object encodes
P2MP ID, which is unique within the scope of the sender (ingress
LSR) and remains constant throughout the lifetime of the P2MP
tree structure. The Extended Tunnel ID, which remains constant
throughout the lifetime of the P2MP tree structure, and which should
contain the sender's address to make sure the identifier is globally
unique identifier. Finally, the Tunnel ID, also remains constant
throughout the lifetime of the P2MP tree structure. The
SENDER_TEMPLATE object contains the ingress LSR source address.
The S2L_SUB_LSP contains the destination address of the sub-LSP.
o From the Receiver's perspective, each sub-LSP is identified
by a new SESSION object specified in this document, the
SENDER_TEMPLATE object and L2S_SUB_LSP. The SESSION object,
different from the one used in typical sender-driven environments,
contains some opaque values to be used as the key to associate
different PATH messages originated from different leaves. The
SENDER_TEMPLATE object contains the Path-Sender's address, which
is actually the Data Receiver. The L2S_SUB_LSP contains the
source address of the sub-LSP, i.e. the data Sender's address.
This document takes the approach from the Receiver's perspective.
The approach from the Sender's perspective is documented in [RFC 4875].
In this draft, the SESSION object will encode multicast
information such as multicast source and group addresses as the opaque
value.
Once either the Sender LSR, a transit LSR, or a branch LSR receives
a PATH message containing SESSION object, the LSR should be able to use
the opaque values encoded in the SESSION object to determine whether the
sub-LSP signaled by this PATH message should be merged with existing
LSPs.
An EXPLICIT_ROUTE Object (ERO) or mRSVP-TE_SECONDARY_EXPLICIT_ROUTE
Object (SERO) is used to optionally specify the explicit route of a
L2S sub-LSP. Each ERO or SERO that is signaled corresponds to a
particular L2S_SUB_LSP object. Details of explicit route encoding
are specified in section 4.5 of [RFC4875]. The
Li, et al. Expires August 30, 2012 [Page 11]
Internet-Draft RD Multicast RSVP-TE March , 2012
SECONDARY_EXPLICIT_ROUTE Object is defined in [RFC4873], the mRSVP-TE
SECONDARY_EXPLICIT_ROUTE Object C-type and the matching mRSVP-
TE_SECONDARY_RECORD_ROUTE Object C-type is defined in this docuemnt.
2.2. Explicit Routing
When a 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 the ERO should be interpreted as requiring hop-by-hop
routing for the sub-LSP based on the L2S sub-LSP root address field
of the L2S_SUB_LSP object.
2.3. L2S Sub-LSPs and Path Messages
The mechanism specified in this document allows a RD P2MP/MP2MP LSP to
be signaled using one or more Path messages. Each Path message may
signal one L2S sub-LSPs.
Receiver-driven P2MP MPLS-TE LSP uses the Path message to carry the
LABEL object upstream towards the Sender. With a receiver-driven usage
of the RSVP PATH message, the LABEL_REQUEST object carried by the
PATH message is no longer mandatory, it becomes optional for
receiver-driven PATH messages, as mentioned in Figure 4:
<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 descriptor list>]
Figure 4: PATH Message Extensions.
The SESSION object encodes an opaque value which is used as a key to
associate different PATHs to the same RD P2MP/MP2MP tree structure.
Li, et al. Expires August 30, 2012 [Page 12]
Internet-Draft RD Multicast RSVP-TE March , 2012
Using [RFC4875] as the base specification, with the LABEL object
being added to the SENDER DESCRIPTOR object (Figure 5):
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
[ <SUGGESTED_LABEL> ]
[ <RECOVERY_LABEL> ]
<LABEL>
Figure 5: SENDER DESCRIPTOR Object.
The LABEL object is defined in section 4.1 of [RFC3209].
Please note that receiver-driven PATH messages convey the
LABEL_REQUEST as an optional object. When the receiver-driven P2MP
LSP is uni-directional, the LABEL_REQUEST in the PATH message is not
used. When bi-directional receiver-driven P2MP LSP (MP2MP) are used, the
LABEL_REQUEST will operate as described in [RFC4875], providing the
label allocation operation in the other direction.
2.4. Resv Message Extensions
Receiver-driven P2MP RSVP-TE does not need any change to the basic
RESV message, as illustrated in section 6.1 of [RFC4875], as long as the
SESSION object is using one of the new C-Types to be assigned by
IANA. In this document, we specify four new C-Types for RD
P2MP/MP2MP tree structures: IPv4 P2MP tunnels, IPv4 MP2MP tunnels, IPv6
P2MP tunnels, IPv6 MP2MP tunnels.
For receiver-driven P2MP tree structures, the PATH message carries the LABEL
object, and thus the RESV message doesn't have to carry the LABEL object anymore.
But for MP2MP LSP tree structures, as indicated by the new C-Type of the SESSION
object, both PATH and RESV messages will carry LABEL objects for
sending and receiving purposes, respectively. Within the context of MP2MP
tree structures, one of the directions is established as per
[RFC3209]. Thus, this document is changing the use of the LABEL
object in the FF Flow Descriptor and SE Filter Spec from mandatory to
optional. As indicated in Figure 6:
Li, et al. Expires August 30, 2012 [Page 13]
Internet-Draft RD Multicast RSVP-TE March , 2012
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> [ <LABEL> ]
[ <RECORD_ROUTE> ]
[ <L2S sub-LSP flow descriptor list> ]
<SE filter spec> ::= <FILTER_SPEC> [ <LABEL> ] [ <RECORD_ROUTE> ]
[ <L2S sub-LSP flow descriptor list> ]
Figure 6 : RESV Message Extensions.
2.5. PathErr Message Extensions
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 object carried by the PathErr
message. The receiver-driven PathErr message will use the SENDER
DESCRIPTOR object defined in Section 2.1 of this document, the same
SENDER DESCRIPTOR object carried by the Path message the PathErr
message corresponds to, allowing the indication of the LABEL object
in the SENDER DESCRIPTOR. With the ERROR_SPEC object being able to
indicate Label errors with Error Code 24 for Routing Problems and
Error Value sub-code of 9 for MPLS label allocation failure as
defined in section 7.3 of [RFC3209].
2.6. ResvErr Message Extensions
The receiver-driven ResvErr messages have the same syntax and
utilization as the ResvErr message described in [RFC4875]. But this
ResvErr message will be processed as per Section 2.2 of this document,
given that the FF FLOW DESCRIPTOR object and the SE FILTER SPEC object
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 P2MP tree structure, either uni-
directional (P2MP) or bi-directional (MP2MP).
2.7. PathTear Message Extensions
The receiver-driven PathTear message have the same syntax and
utilization as the PathTear message described in [RFC4875], assuming a
difference in the SENDER DESCRIPTOR object carried by the PathTear
message. The receiver-driven PathTear message will use the SENDER
DESCRIPTOR object defined in Section 2.1 of this document, the same
SENDER DESCRIPTOR object carried by the Path message the PathTear
message corresponds to, allowing the indication of the LABEL object
Li, et al. Expires August 30, 2012 [Page 14]
Internet-Draft RD Multicast RSVP-TE March , 2012
in the SENDER DESCRIPTOR.
2.8. SESSION Object
An mRSVP-TE LSP SESSION object is used to implicitly represent a RD P2MP
or an MP2MP tree strcuture. The opaque values encoded in such SESSION
objects are used by Path-Receivers to determine whether or not to
associate different PATH messages from different leaves to the same
P2MP/MP2MP tree structure. The SESSION object has the following general
format, whose length is determined by the C-type (Figure 7):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Opaque Values ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Format of the mRSVP-TE-LSP SESSION-Object.
The SESSION object uses the existing SESSION C-Num. New C-Types are
defined to accommodate different lengths of opaque values. For
native IPv4/IPv6 multicast, the opaque values should encode IPv4/IPv6
(S, G) or (*, G, RP) for P2MP or MP2MP LSPs. For IPv4/IPv6 multicast VPNs,
the opaque values should encode a VPN ID. For tunnel aggregation where
multiple multicast streams are sharing a same LSP tunnel, the
opaque values are TBD.
The combination of the SESSION object, the SENDER_TEMPLATE object and
the L2S_SUB_LSP object identifies each L2S sub-LSP. This follows the
existing P2P RSVP-TE notion of using the SESSION object for
identifying a P2P Tunnel, which in turn can contain multiple LSPs,
each distinguished by a unique SENDER_TEMPLATE object.
The mechanism for propagating the values defined in the SESSION
object is outside the scope of this document.
The mechanism for setting the values defined in the SESSION object is
TBD.
Li, et al. Expires August 30, 2012 [Page 15]
Internet-Draft RD Multicast RSVP-TE March , 2012
2.8.1. mRSVP-TE LSP Tunnel IPv4 SESSION Object
Class = SESSION, mRSVP_TE_P2MP_LSP_TUNNEL_IPv4 C-Type = TBD,
mRSVP_TE_MP2MP_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Source or LSR Root Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: mRSVP-TE-LSP-Tunnel-IPv4-SESSION-Object.
2.8.2. mRSVP-TE LSP Tunnel IPv6 SESSION Object
This is the same as the mRSVP-TE IPv4 LSP SESSION object with the
difference that the multicast source and group addresses are 16-byte
long (Figure 8).
Class = SESSION, mRSVP_TE_P2MP_LSP_TUNNEL_IPv6 C-Type = TBD,
mRSVP_TE_MP2MP_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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Source or Root Address (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: mRSVP-TE-LSP-Tunnel-IPv6-SESSION-Object.
Li, et al. Expires August 30, 2012 [Page 16]
Internet-Draft RD Multicast RSVP-TE March , 2012
2.9. SENDER_TEMPLATE Object
The SENDER_TEMPLATE object contains the Path-Initiator LSR address.
In this document, the Path-Initiator is the same as the Leaf Router
The LSP ID can be changed to allow a sender to do a certain level of
aggregation. Thus, multiple instances of the P2MP tunnel 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.
2.9.1. mRSVP-TE LSP Tunnel IPv4 SENDER_TEMPLATE Object
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-LSP-Tunnel-IPv4-SENDER_TEMPLATE-Object.
IPv4 tunnel receiver address: the IPv4 address of the Leaf Router IPv4
address.
LSP ID
See [RFC3209].
2.9.2. mRSVP-TE LSP Tunnel IPv6 SENDER_TEMPLATE Object
Class = SENDER_TEMPLATE, mRSVP-TE_LSP_TUNNEL_IPv6 C-Type = TBD.
Li, et al. Expires August 30, 2012 [Page 17]
Internet-Draft RD Multicast RSVP-TE March , 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Leaf Router address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: mRSVP-TE-LSP-Tunnel-IPv6-SENDER_TEMPLATE-Object.
IPv6 tunnel receiver address: the IPv6
Address of the Leaf Router.
LSP ID
See [RFC3209].
2.10. L2S_SUB_LSP Object
An L2S_SUB_LSP object identifies a particular L2S sub-LSP belonging
to the mRSVP-TE LSP.
2.10.1. L2S_SUB_LSP IPv4 Object
L2S_SUB_LSP Class = 50, 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: L2S_SUB_LSP_IPv4_Object.
Li, et al. Expires August 30, 2012 [Page 18]
Internet-Draft RD Multicast RSVP-TE March , 2012
IPv4 L2S Sub-LSP Root Address: IPv4 address of the L2S sub-LSP
sender.
2.10.2. L2S_SUB_LSP IPv6 Object
L2S_SUB_LSP Class = TBD, L2S_SUB_LSP_IPv6 C-Type = TBD
It is the same as the IPv4 L2S Sub-LSP object, with the difference
that the root address is a 16-byte IPv6 address.
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.
2.11. FILTER_SPEC Object
The FILTER_SPEC object is canonical to the P2MP SENDER_TEMPLATE
object.
2.11.1. P2MP LSP_IPv4 FILTER_SPEC Object
Class = FILTER_SPEC, P2MP LSP_IPv4 C-Type = TBD.
The format of the P2MP LSP_IPv4 FILTER_SPEC object is identical to
the P2MP LSP_IPv4 SENDER_TEMPLATE object.
2.11.2. mRSVP-TE LSP_IPv6 FILTER_SPEC Object
The mRSVP-TE LSP_IPv6 FILTER_SPEC Object uses the P2MP LSP_IPv6
SENDER_TEMPLATE object defined in [RFC4875].
Li, et al. Expires August 30, 2012 [Page 19]
Internet-Draft RD Multicast RSVP-TE March , 2012
2.11.3. mRSVP-TE SECONDARY_EXPLICIT_ROUTE Object (SERO)
The mRSVP-TE SECONDARY_EXPLICIT_ROUTE Object (SERO) used the The P2MP
SECONDARY_EXPLICIT_ROUTE Object (SERO) defined in [RFC4875].
2.11.4. mRSVP-TE SECONDARY_RECORD_ROUTE Object (SRRO)
The mRSVP-TE SECONDARY_RECORD_ROUTE Object (SRRO) uses the P2MP
SECONDARY_RECORD_ROUTE Object (SRRO)defined in [RFC4875].
3. In-Band and Out-Band Signalling
3.1. In-Band Signalling
In typical Live TV broadcasting environments where the corresponding IP
multicast distribution trees usually computed and established by
means of the Protocol Independent Multicast (PIM), need to be deployed over
an MPLS domain, Receiver-Driven P2MP LSP tree structures can be
created. The part of the IP multicast tree that traverses the MPLS
domain can be instantiated as a RD P2MP LSP. When a PIM Join
message is received at the border of the MPLS domain, information
from that message will be encoded into RSVP-TE P2MP
messages. When the RSVP-TE P2MP messages reach the border of
the next IP multicast domain, the encoded information will be able to be used
to generate PIM messages that can be sent through this IP multicast domain.
The result will be an IP multicast tree consisting of a set of IP
multicast sub-trees that can be spliced together with a RD P2MP
RSVP-TE based LSP.
The detailed protocol extensions and procedures are TBD.
3.2. Out-Band Signalling
In the case that In-Band Signalling is not used, whenever a PIM Join
message is received at the border of the MPLS domain, information
from that message can also be encoded into BGP messages.
When the BGP messages reach the border of the next IP multicast domain,
the encoded information should be used to generate PIM
messages that can be sent through the said IP multicast domain. The result
should be an IP multicast tree consisting of a set of IP multicast sub-trees
that can be spliced together with a RD P2MP LSP tree structure.
Li, et al. Expires August 30, 2012 [Page 20]
Internet-Draft RD Multicast RSVP-TE March , 2012
4. Broadcast Interfaces
The receiver-driven approach interoperates with the RSVP upstream
label allocation mechanism [I-D.ietf-mpls-rsvp-upstream]. Path-
Senders SHOULD detect the presence of such P2MP-LSP over broadcast
interfaces for each Path-Receiver. Instead of labels carried by PATH
messages, the upstream-assigned labels are carried by RESV messages.
The considerations for MP2MP is TBD.
5. Fast Re-Route Considerations
TBD.
6. Backward Compatibility
A receiver-driven P2MP LSP mechanism uses a unique C-Type. LSRs that
do not support receiver-driven P2MP-TE LSP, send Path Error [TBD]
back to the Path Initiator.
The complete discussion on the Backward Compatibility will be provided in
the Next version of the document.
7. Acknowledgements
We would like to thank authors of [RFC4461], [RFC4875] and the
authors of draft-ietf-mpls-mp-ldp-reqs from which some text of this
document has been inspired.
8. IANA Considerations
This section is TBD.
9. Security Considerations
How a receiver is authenticated is outside the scope of this
document. But we briefly summarize the requirements which are
detailed in the requirements draft.
It is a requirement 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:
Li, et al. Expires August 30, 2012 [Page 21]
Internet-Draft RD Multicast RSVP-TE March , 2012
o A receiver MUST be authenticated before it is allowed to establish
mRSVP-TE LSP with source, in addition to hop-by-hop security
issues identified by in RFC 3209 and RFC 4206.
o mechanisms to ensure that the ingress LSR of a P2MP LSP is
identified;
o mechanisms to ensure that communicating signaling entities can
verify each other's identities;
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
added to the mRSVP-TE LSP; and
o mechanisms to protect signaling messages from snooping.
o Note that mRSVP-TE signaling mechanisms built on P2P RSVP-TE
signaling are likely to inherit all the security techniques and
problems associated with RSVP-TE. These problems may be
exacerbated in mRSVP-TE situations where security relationships
may need to maintained 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.
[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.
Li, et al. Expires August 30, 2012 [Page 22]
Internet-Draft RD Multicast RSVP-TE March , 2012
[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.
[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.
[I-D.ietf-mpls-rsvp-upstream]
Aggarwal, R. and J. Roux, "MPLS Upstream Label Assignment
for RSVP-TE", draft-ietf-mpls-rsvp-upstream-05 (work in
progress), March 2010.
[I-D.ietf-mpls-mp-ldp-reqs]
Roux, J. and T. Morin, "Requirements for Point-To-
Multipoint Extensions to the Label Distribution Protocol",
draft-ietf-mpls-mp-ldp-reqs-08 (work in progress),
May 2011.
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.
Li, et al. Expires August 30, 2012 [Page 23]
Internet-Draft RD Multicast RSVP-TE March , 2012
[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.
Authors' Addresses
Renwei Li
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone:
Email: renwei.li@huawei.com
Quintin Zhao
Huawei Technologies
Boston, MA
USA
Phone:
Email: quintin.zhao@huawei.com
Christian Jacquenet
France Telecom Orange
4 rue du Clos Courtel
35512 Cesson Sevigne,
France
Phone: +33 2 99 12 43 82
Email: christian.jacquenet@orange.com
Li, et al. Expires August 30, 2012 [Page 24]
Internet-Draft RD Multicast RSVP-TE March , 2012