Receiver-Driven Multicast Traffic-Engineered Label-Switched PathsHuawei Technologies2330 Central ExpresswaySanta ClaraCA95050USArenwei.li@huawei.comHuawei TechnologiesBostonMAUSAquintin.zhao@huawei.comFrance Telecom Orange4 rue du Clos Courtel35512 Cesson Sevigne,Francechristian.jacquenet@orange-ftgroup.com
Routing
MPLS Working Group
This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for the setup 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.
Multiparty multimedia applications are getting greater attention in
the telecom and datacom 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. Sometimes multicast data
streams are required to get transported over both IP networks and MPLS
networks, which require PIM must interwork with RSVP-TE. On other times, PIM
bootstraping messages need to transport over an intermediate MPLS domain.
This document
extends RSVP-TE for the dynamic computation of receiver-driven P2MP
and MP2MP LSP tree structures. 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). The priori knowledge of receiver locations
is obtained either through
static configuration or by using another protocol to discover such receivers.
On the other hand, there is no straightfoward way to support MP2MP applications
by 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
sender to know all the receivers' locations a priori. The protocols
for discovery of receivers are not needed. It provides a natural mechanism to
interwork with PIM dynamically.
The following terms are used in this document:
Sender: Sender refers to the Originator (and hence the Sender) of the
content/payload, as defined in [RFC2205].
Receiver: Receiver refers to the Receiver of the
content/payload, as defined in [RFC2205].
Upstream: The direction of flow from content Receiver toward
content Sender, as defined in [RFC2205].
Downstream: The direction of flow from content Sender toward
content Receiver, as defined in [RFC2205].
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.
Path-Receiver: The receiver of RSVP PATH messages, with no
correlation to the direction of content/payload flows.
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. A Path-Initator
is a Path-Sender, but a Path-Sender doesn't have to be a Path-Initiator.
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.
Root: A router where a multcast LSP tree is rooted at. Data enters the
root and then is distributed to leaves along the P2MP/MP2MP LSP.
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. In the receiver-driven context, we inverted the
semantics of RSVP-TE messages, while keeping the
syntax unchanged as much as possible. We will use mRSVP-TE to represent the RSVP-TE with
receiver-driven extensions described in this document.
The following are some key differences that are specific to the
receiver-driven paradigm: The leaf router: the router that receives data/content/payload. In this
document, the leaf router will initiate PATH messages. In some sense, the leaf
router and the receiver mean the same thing. The term "receiver-driven" also
means "leaf-driven".
L2S Destinations: routers where
user data payload traffic enters the LSP. L2S means Leaf-to-Source. The
source is the sender or root of a multicast stream.
RSVP P2MP PATH messages traverse from receivers to the root.
RSVP P2MP RESV messages traverse from the root to the leaf routers of the
P2MP tree strcuture.
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.
A RSVP RESV message received by a router is interpreted as successful
resource reservation made by the downstream node for the establishment
of an MP2MP tree structure.
Label allocation on incoming interfaces is done prior to sending
RSVP PATH messages upstream for P2MP tree structures.
Label allocation on incoming interfaces is done prior to sending
RSVP RESV messages upstream for MP2MP tree structures.
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,
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.
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 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
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 send data from the Path-Sender node
to the Path-Receiver node.
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.
In what follows we describe two examples to show how P2MP and MP2MP are set up,
respectively. In both of such examples, Path messages are initiated by
data receivers.
For the P2MP example, a Path message carries a label for the use of sending
data downstream. And for the MP2MP example, both Path message and Resv message
carries a label for sending data downstream and upstream.
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 multicast LSP has
already been set up for the same session and the same source. 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 multicast LSP is determined
based on the processing of the SESSION object and L2S_SUB_LSP object from the mRSVP-TE
message. The SESSION object and the L2S_SUB_LSP objects are documented later
in this draft. In Figure 2, when R5 is added as the first leaf
(as both a sender and a receiver) of an MP2MP multicast LSP, the message
flow goes from R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5.
When the
leaf R4 ( as both a sender and a receiver)is added, the message flow goes
from R4->msg5->R3->msg6->R4. In this case, when R3 receives msg5, R3
finds out that an MP2MP mulitcast LSP has already been set up for the same
session and the same root 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
the existing MP2MP LSP is determined based on the processing of the
SESSION object and the S2L_SUB_LSP from the mRSVP-TE message. The SESSION
objects and the L2S_SUB_LSP objects are further
documented later in this draft.
The RSVP-TE with receiver-driven extensions (mRSVP-TE) is similar to the
RSVP-TE protocol as specified in [RFC4875],
[RFC3473] and [RFC3209], but differs in that the data receivers of an LSP tunnel
initiate the Path messages toward the data sender (or the root of a mulitcast
LSP). Compared with [RFC4875], mRSVP-TE can also be used
to set up MP2MP LSPs.In the context of the receiver-driven RSVP-TE, the Receiver is the
Path-Originator. The Path messages go from the Receivers towards the Sender.
The Resv messages flow in the opposite direction as
compared to the Path messages, i.e. Resv messages are generated
by the Sender or a branch LSR. Path messages flow in opposite directions
as cmpared with those of the multicast stream distributions, while Resv messages
flow in the same directions as the multicast streams. In the context of the receiver-driven RSVP-TE, a Path message will be
terminated at the "root" of the multicast distribution tree (multicast LSP) or at an
intermediate node if the intermediate node has received another Path message
from another receiver for the same multicast distribution tree. When an
intermediate node receives two or more Path messages for the same multicast
distribution tree, 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.
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 P2MP
source or MP2MP root.
For the sake of reliability, two or more sources/roots may be deployed
to distribute the same multicast streams. A mulitcast stream is often
represented by a mulitcast group address. In this document, we will encode
the mulitcast group address in the SESSION object and the mulitcast
source/root address in the leaf-to-source sub-LSP object. Note that the
same session can have different sources/roots, and the same sources/roots
can have different sessions.
In the context of the receiver-driven mRSVP-TE, the processing of
SESSION objects is different from that of
SESSION objects in sender-driven RSVP-TE [RFC4875]. In order to distinguish them,
we will employ different C-Types of SESSIONs. In this document we
will document SESSION objects for native IPv4/IPv6 multicast applications.
For new and more applications, new types of SESSION objects will be added.
Following the method used by RSVP-TE and P2MP
RSVP-TE, this draft documents the use of some new SESSION C-Type as
follows:The new SESSION C-Type MUST be used in all receiver-driven P2MP
RSVP-TE messages. A multicast LSP is composed of one or more leaf-to-source sub-LSPs, which
are merged together at the branch nodes.
There are two ways to identify each such sub-LSP:
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, 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 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. 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.
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 Data Receiver. The L2S_SUB_LSP 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 all together will identify
the multicast stream, the multicast stream's source, and a mulitcast
stream's receiver
This document takes the approach from the Receiver's perspective.
The approach from the Sender's perspective is documented in [RFC 4875].Once an LSR receives a receiver-driven Path message with the SESSION
object and L2S_SUB_LSP object, the LSR should be able to use
the SESSION object and L2S_SUB_LSP object to determine whether the
sub-LSP signaled by this Path message should be merged with existing
multicast LSPs.
In the context of the receiver-driven RSVP-TE, a Path Originator is also a Data
Receiver. This document will document a new type of SENDER_TEMPLATE object,
which contains the Path-Originator's IP address
and describes the identity of the Path Originator.
In [RFC 2205] and [RFC 4875], the "sender" is both a path originator and
a data sender. In the receiver-driven context, path originators and data senders
may be different. For P2MP, path originators are actually the data receivers.
For MP2MP, path originators are also both the data senders and data receivers.
In this document, we will use the same Object Class SENDER_TEMPLATE with a
different C-Type to represent and identify Path Originator. In the case of
P2MP LSP, the SENDER_TEMPLATE describes the identify of a data receiver. In
the case of MP2MP, the SENDER_TEMPLATE describes the identify of an LSR which
work as both a data sender and a data receiver.
All of the SESSION object, L2S_SUB_LSP object and SENDER_TEMPLATE object
together contained in a Path message will uniquely identify a leaf-to-source
sub-LSP.
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 explicit route encoding
are specified in section 4.5 of [RFC4875], but they are encoded in a reverse
order in the receiver-driven context.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 reverse-forwarding for the sub-LSP based on the
root address field of the L2S_SUB_LSP object.
The mechanism specified in this document allows a multicast P2MP/MP2MP LSP to
be signaled using one or more Path messages. Each Path message may
signal one L2S sub-LSPs.A receiver-driven P2MP MPLS-TE LSP uses the Path message to carry the
LABEL object upstream from the Receiver 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: The SESSION object encodes information about the being-signalled multicast
stream. The SESSION object together with L2S_SUB_LSP will be used as the key to
associate different sub-LSPs to the same multicast LSP.Using [RFC4875] as the base specification, the LABEL object is added to the
<sender descriptor> as specified in Figure 5:
The LABEL object is defined in section 4.1 of [RFC3209]Note that the receiver-driven Path messages convey the
LABEL_REQUEST as an optional object. If the Path message
signals a P2MP LSP, the LABEL_REQUEST in the Path message is not
used. If the Path message signals an MP2MP, the
LABEL_REQUEST is needed to ask for labels from its upstream LSR. Receiver-driven P2MP RSVP-TE does not need any change to the basic
RESV messages specified in section 6.1 of [RFC4875], as long as the
receiver-driven 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 MP2MP LSPs, both Path and Resv messages will carry LABEL objects for
sending and receiving purposes, respectively. Within the context of MP2MP
LSPs, 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 specified in Figure 6:
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.
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 multicast LSP, either uni-directional
(P2MP) or bi-directional (MP2MP).
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. An mRSVP-TE LSP SESSION object is used to represent a multicast stream
whose traffic will be carried by the multicast LSP being set up by the
mRSVP-TE. The object still
uses the existing SESSION C-Num assigned for RSVP-TE, but new C-Types are
defined for the new purposes. Different from the values in the existing
point-to-point or point-to-multipoint RSVP-TE SESSION object, the new objects
defined by the new C-Types will encode "multicasting" information.
The new SESSION object will have enough information so that the Path-Receivers
can use the SESSION objects together with L2S_SUB_LSP to determine whether or not to
associate different Path messages from different leaves to the same
P2MP/MP2MP LSP. The
combination of the SESSION object, the SENDER_TEMPLATE object and the
L2S_SUB_LSP object will uniquely identify a single L2S sub-LSP.
For
native IPv4/IPv6 multicast, IPv4/IPv6 (S, G) or (*, G, RP) will be encoded
in the SESSION object for P2MP or MP2MP LSPs. In what follows we specify
such session objects for IPv4/IPv6 P2MP and MP2MP applications in the
context of receiver-driven RSVP-TE. Other SESSION objects in the
receiver-driven context are defined in other documents.
Class = SESSION, mRSVP_TE_P2MP_LSP_TUNNEL_IPv4 C-Type = TBD.Class = SESSION,
mRSVP_TE_MP2MP_LSP_TUNNEL_IPv4 C-Type = TBD. The MP2MP LSP for IPv4 SESSION objects are of the same format as P2MP
LSP for IPv4 SESSION objects, but their C-Types are different.
This is the same as the P2MP LSP for IPv4 SESSION object with the
difference that the IPv6 multicast group addresses are 16-byte long. Class = SESSION, mRSVP_TE_P2MP_LSP_TUNNEL_IPv6 C-Type = TBD. Class = SESSION, mRSVP_TE_MP2MP_LSP_TUNNEL_IPv6 C-Type = TBD. The SENDER_TEMPLATE object contains the Path-Initiator LSR address.
In this document, the Path-Initiator is the same as the Leaf Router or
Data Receiver.
The LSP ID can be changed to allow a sender to do a certain level of
resource sharing. Thus, multiple instances of the same mutlicast 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.
Class = SENDER_TEMPLATE, mRSVP_TE_LSP_TUNNEL_IPv4 C-Type = TBD.IPv4 Leaf Router Address: The IPv4 address of the Data Receiver. 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].Class = SENDER_TEMPLATE, mRSVP-TE_LSP_TUNNEL_IPv6 C-Type = TBD.IPv6 Leaf Router Address: The IPv6 address of the Data Receiver. 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].An L2S_SUB_LSP object identifies a particular L2S sub-LSP belonging
to a multicast LSP, as explained earlier in this document. L2S_SUB_LSP Class = TBD, L2S_SUB_LSP_IPv4 C-Type = TBD. IPv4 L2S Sub-LSP Root Address: IPv4 address of the L2S sub-LSP sender.L2S_SUB_LSP Class = TBD, L2S_SUB_LSP_IPv6 C-Type = TBDThe FILTER_SPEC object is canonical to the SENDER_TEMPLATE
object.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. The format of the mRSVP-TE LSP_IPv6 FILTER_SPEC object is identical to
the mRSVP_TE_LSP_TUNNEL_IPv6 SENDER_TEMPLATE object.
There are two basic applications for receiver-driven RSVP-TE: inter-work with
PIM and Multicast VPN.
Some multicast applications may involve several domains, some of which
are operated with PIM while others are enabled with RSVP-TE. This requires
the multicast distribution trees to be computed and set up across different
domains with PIM and MPLS configured in different domains.
When a PIM Join
message is received at the border of the MPLS domain, information encoded
from the PIM Join message can be encoded as a receiver-driven RSVP-TE Path
message which will set up a multicast distribution LSP across the MPLS domain.
The root of such a multicast LSP can encode a PIM Join message by using
the information encoded in the RSVP-TE Path message. The result of doing so
will enable to build a mulitcast distribution tree across both IP and MPLS
domains. The multicast tree will consist of a set of IP multicast sub-trees
built by PIM and a set of MPLS multicast LSPs built by the receiver-driven
RSVP-TE.
In PIM, there is a bootstrapping mechanism about the RP. For bootstrap messages,
an MP2MP LSP can be used.
The detailed protocol extensions and procedures for such in-band
signaling applications are described in other documents.
A L3VPN service that supports multicast is known as a Multicast VPN, or MVPN
for short. There have been different proposed messages, procedures and
mechanisms to support MVPN. These methods differ in protocols used in the
service provider's network, for example, the mGRE-based MVPN, BGP extensions
to transport customer's PIM signaling and P2MP RSVP-TE extensions to transport
multicast data streams, and mLDP-based MVPN.
The receiver-driven multicast extensions to RSVP-TE can be used to support
multicast VPN. Such an approach will greatly reduce the number of trees and
multicast states in the core compared with the P2MP RSVP-TE approach.
The detailed procedures and mechanisms are described in [I-D.hlj-l3vpn-mvpn-mrsvp-te].
The Fast Re-Route mechanisms and procedures specified in [RFC 4090] will
not be applicable to the receiver-driven extension to RSVP-TE described in
this document, since their Path/Resv messages are sent in different directions.
Extensions to mRSVP-TE to support Fast Re-Route are described in the document
[I-D.zlj-mpls-mpls-mrsvp-te-frr].
A receiver-driven P2MP LSP mechanism uses different C-Types than those in
the sender-driven P2MP RSVP-TE. 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 receiver-driven P2MP-TE LSP, send Path Error [TBD]
back to the Path Originator. The complete discussion on the backward compatibility will be provided in
the Next version of the document.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 on our presentation
of this work in Paris. This section is TBD.How a receiver is
authenticated is outside the scope of this document. But we will 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: A receiver MUST be authenticated before it is allowed to establish
mRSVP-TE LSP with its source, in addition to hop-by-hop security issues
identified by in RFC 3209 and RFC 4206.mechanisms to ensure that the ingress LSR of a P2MP LSP is
identified; mechanisms to ensure that communicating signaling entities can
verify each other's identities;mechanisms to ensure that control plane messages are protected
against spoofing and tampering;mechanisms to ensure that unauthorized leaves or branches are not
added to the mRSVP-TE LSP; and 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 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.It is a requirement that documents offering solutions for P2MP LSPs
MUST have detailed security sections.