One document matched: draft-ietf-mpls-mp-ldp-reqs-06.xml
<?xml version="1.0"?>
<?rfc toc="yes"?><?rfc tocompact="yes"?><?rfc tocdepth="2"?><?rfc tocindent="yes"?><?rfc symrefs="yes"?><?rfc sortrefs="yes"?><?rfc comments="yes"?><?rfc inline="yes"?><?rfc compact="yes"?><?rfc subcompact="no"?><rfc category="info" docName="draft-ietf-mpls-mp-ldp-reqs-06" ipr="pre5378Trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="Reqs for P2MP extensions to LDP">Requirements for
Point-To-Multipoint Extensions to the Label Distribution Protocol</title>
<author fullname="Jean-Louis" initials="J.-L." role="editor" surname="Le Roux">
<organization>France Telecom - Orange</organization>
<address>
<email>jeanlouis.leroux@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Thomas Morin" initials="T." surname="Morin">
<organization>France Telecom - Orange</organization>
<address>
<email>thomas.morin@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Vincent Parfait" initials="V." surname="Parfait">
<organization abbrev="France Telecom - Orange">France Telecom - Orange,
Orange Business Services</organization>
<address>
<email>vincent.parfait@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Luyuan Fang" initials="L." surname="Fang">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<email>lufang@cisco.com</email>
</address>
</author>
<author fullname="Lei Wang" initials="L." surname="Wang">
<organization>Telenor</organization>
<address>
<email>lei.wang@telenor.com</email>
</address>
</author>
<author fullname="Yuji Kamite" initials="Y." surname="Kamite">
<organization abbrev="NTT">NTT Communications Corporation</organization>
<address>
<email>y.kamite@ntt.com</email>
</address>
</author>
<author fullname="Shane Amante" initials="S." surname="Amante">
<organization abbrev="Level3">Level 3 Communications, LLC</organization>
<address>
<email>shane@level3.net</email>
</address>
</author>
<date day="01" month="December" year="2010"/>
<area>Routing Area</area>
<workgroup>MPLS</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>This document lists a set of functional requirements for Label
Distribution Protocol (LDP) extensions for setting up
point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to
deliver point-to-multipoint applications over a Multi Protocol Label
Switching (MPLS) infrastructure. It is intended that solutions that
specify LDP procedures for setting up P2MP LSP satisfy these
requirements.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119" pageno="false" format="default"/>.</t>
</note>
</front>
<middle>
<section title="Definitions" toc="default">
<section title="Acronyms" toc="default">
<t><list style="hanging">
<t hangText="P2P:">Point-To-Point</t>
<t hangText="P2MP:">Point-To-MultiPoint</t>
<t hangText="MP2MP:">MultiPoint-To-Multipoint</t>
<t hangText="PE:">Provider Edge router</t>
<t hangText="P:">Provider router</t>
<t hangText="IGP:">Interior Gateway Protocol</t>
<t hangText="AS:">Autonomous System</t>
</list></t>
</section>
<section title="Terminology" toc="default">
<t>The reader is assumed to be familiar with the terminology in <xref target="RFC3031" pageno="false" format="default"/>, <xref target="RFC5036" pageno="false" format="default"/>, and <xref target="RFC4026" pageno="false" format="default"/>.</t>
<t><list style="hanging">
<t hangText="Ingress LSR:"><vspace blankLines="0"/>Router acting
as a sender of an LSP</t>
<t hangText="Egress LSR:"><vspace blankLines="0"/>Router acting
as a receiver of an LSP</t>
<t hangText="P2P LSP:"><vspace blankLines="0"/>A LSP that has one
unique Ingress LSR and one unique Egress LSR</t>
<t hangText="MP2P LSP:"><vspace blankLines="0"/>A LSP that has
one or more Ingress LSRs and one unique Egress LSR</t>
<t hangText="P2MP LSP:"><vspace blankLines="0"/>A LSP that has
one unique Ingress LSR and one or more Egress LSRs</t>
<t hangText="MP2MP LSP:"><vspace blankLines="0"/>A LSP that as
one or more Leaf LSRs acting indifferently as Ingress or Egress
LSR</t>
<t hangText="Leaf LSR:"><vspace blankLines="0"/>Egress LSR of a
P2MP LSP or Ingress/Egress LSR of a MP2MP LSP</t>
<t hangText="Transit LSR:"><vspace blankLines="0"/>A LSR of a
P2MP or MP2MP LSP that has one or more Downstream LSRs</t>
<t hangText="Branch LSR:"><vspace blankLines="0"/>A LSR of a P2MP
or MP2MP LSP that has more than one downstream LSR</t>
<t hangText="Bud LSR:"><vspace blankLines="0"/>A LSR of a P2MP or
MP2MP LSP that is an egress but also has one or more directly
connected downstream LSR(s)</t>
<t hangText="P2MP tree:"><vspace blankLines="0"/>The ordered set
of LSRs and links that comprise the path of a P2MP LSP from its
ingress LSR to all of its egress LSRs.</t>
</list></t>
</section>
</section>
<section title="Introduction" toc="default">
<t>LDP <xref target="RFC5036" pageno="false" format="default"/> has been deployed for setting up
point-to-point (P2P) and multipoint-to-point (MP2P) LSPs, in order to
offer point-to-point services in MPLS backbones.</t>
<t>There are emerging requirements for supporting delivery of
point-to-multipoint applications in MPLS backbones, such as those
defined in <xref target="RFC4834" pageno="false" format="default"/> and <xref target="RFC5501" pageno="false" format="default"/>.</t>
<t>This requires mechanisms for setting up point-to-multipoint LSPs
(P2MP LSP), i.e. LSPs with one Ingress LSR, a set of Egress LSRs, and
with MPLS traffic replication at some Branch LSRs.</t>
<t>RSVP-TE extensions for setting up Point-To-Multipoint Traffic
Engineered LSPs (P2MP TE LSPs), have been defined in <xref target="RFC4875" pageno="false" format="default"/>. They meet requirements expressed in <xref target="RFC4461" pageno="false" format="default"/>. This approach is useful, in network
environments where P2MP Traffic Engineering capabilities are needed
(Optimization, QoS, Fast recovery).</t>
<t>However for operators who want to support point-to-multipoint traffic
delivery on an MPLS backbone, without Traffic Engineering needs, and
have already deployed LDP for P2P traffic, an interesting and useful
approach would be to rely on LDP extensions in order to setup
point-to-multipoint (P2MP) LSPs. This would bring consistency with P2P
MPLS applications and would ease the delivery of point-to-multipoint
services in an MPLS backbone.</t>
<t>This document focuses on the LDP approach for setting up P2MP LSPs.
It lists a detailed set of requirements for P2MP extensions to LDP, so
as to deliver P2MP traffic over a LDP-enabled MPLS infrastructure. These
requirements should be used as guidelines when specifying LDP
extensions. It is intended that solutions that specify LDP procedures
for P2MP LSP setup, satisfy these requirements.</t>
<t>Note that generic requirements for P2MP extensions to MPLS are out of
the scope of this document. Rather this document describes solution
specific requirements related to LDP extensions in order to set up P2MP
LSPs.</t>
<t>Note also that other mechanisms could be used for setting up P2MP
LSPs, such as for instance PIM extensions, but these are out of the
scope of this document. The objective is not to compare these mechanisms
but rather to focus on the requirements for an LDP extension
approach.</t>
<t>The document is structured as follows:<list style="symbols">
<t>Section <xref format="counter" target="pbstatement" pageno="false"/>
points out the problem statement;</t>
<t>Section <xref format="counter" target="appscenario" pageno="false"/>
illustrates an application scenario;</t>
<t>Section <xref format="counter" target="detailedreqs" pageno="false"/>
addresses detailed requirements for P2MP LSPs;</t>
<t>Section <xref target="sharedtrees" pageno="false" format="default"/> finally discusses
requirements for shared trees and MultiPoint-to-MultiPoint (MP2MP)
LSPs.</t>
</list></t>
</section>
<section anchor="pbstatement" title="Problem Statement and Requirements Overview" toc="default">
<section title="Problem Statement" toc="default">
<t>LDP <xref target="RFC5036" pageno="false" format="default"/> has been deployed for setting up
P2P and MP2P MPLS LSPs as PE-to-PE tunnels so as to carry
point-to-point traffic essentially in Layer 3 and Layer 2 VPN
networks. There are emerging requirements for supporting multicast
traffic delivery within these VPN infrastructures (<xref target="RFC4834" pageno="false" format="default"/> and <xref target="RFC5501" pageno="false" format="default"/>). For
various reasons, including consistency with P2P applications, and
taking full advantages of MPLS network infrastructure, it would be
highly desirable to use MPLS LSPs for the delivery of multicast
traffic. This could be implemented by setting up a group of P2P or
MP2P LSPs, but such an approach may be sub-optimal since it would
result in data replication at the ingress LSR, and bandwidth
inefficiency (duplicate data traffic within the network). Hence new
mechanisms are required that would allow traffic from an Ingress LSR
to be efficiently delivered to a number of Egress LSRs in an MPLS
backbone, avoiding duplicate copies of a packet on a given link.</t>
<t>Such efficient traffic delivery requires setting up P2MP LSPs. A
P2MP LSP is an LSP starting at an Ingress LSR, and ending on a set of
one or more Egress LSRs. Traffic sent by the Ingress LSR is replicated
on one or more Branch LSRs down to Egress LSRs.</t>
<t>RSVP-TE extensions for setting up P2MP TE LSPs, which meet
requirements expressed in <xref target="RFC4461" pageno="false" format="default"/>, have been
defined in <xref target="RFC4875" pageno="false" format="default"/>. This approach is useful, in
network environments where Traffic Engineering capabilities are
required. However, for operators that deployed LDP for setting up
PE-to-PE unicast MPLS LSPs, and without the need for traffic
engineering, an interesting approach would be using LDP extensions for
setting up P2MP LSPs.</t>
<t>The following gives a set of guidelines that a specification of LDP
extensions for setting up P2MP LSPs should follow.</t>
</section>
<section title="Requirements overview" toc="default">
<t>The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs
with one Ingress LSR and one or more Egress LSRs, with traffic
replication at some Branch LSRs.</t>
<t>The P2MP LDP mechanism MUST allow the addition or removal of leaves
associated with a P2MP LSP.</t>
<t>The P2MP LDP mechanism MUST co-exist with current LDP mechanisms
and inherit its capability sets from <xref target="RFC5036" pageno="false" format="default"/>.
It is of paramount importance that the P2MP LDP mechanism MUST NOT
impede the operation of existing P2P/MP2P LDP LSPs. Also the P2MP LDP
mechanism MUST co-exist with P2P and P2MP RSVP-TE mechanisms <xref target="RFC3209" pageno="false" format="default"/>, <xref target="RFC4875" pageno="false" format="default"/>. It</t>
<t>is of paramount importance that the P2MP LDP mechanism MUST NOT
impede the operation of existing P2P and P2MP RSVP-TE LSPs.</t>
<t>The P2MP LDP mechanism MAY also allow setting up
multipoint-to-multipoint (MP2MP) LSPs connecting a group of Leaf LSRs
acting indifferently as Ingress LSR or Egress LSR. This may allow a
reduction in the amount of LDP state that needs to be maintained by a
LSR.</t>
</section>
</section>
<section anchor="appscenario" title="Application scenario" toc="default">
<t><xref target="fig1" pageno="false" format="default"/> below illustrates an LDP enabled MPLS
provider network, used to carry both unicast and multicast traffic of
VPN customers following for instance the architecture defined in <xref target="I-D.ietf-l3vpn-2547bis-mcast" pageno="false" format="default"/> for BGP/MPLS VPNs, or the
one defined in <xref target="I-D.ietf-l2vpn-vpls-mcast" pageno="false" format="default"/>.</t>
<t>In this example, a set of MP2P LDP LSPs are setup between Provider
Edge (PE) routers to carry unicast VPN traffic within the MPLS
backbone.</t>
<t>And in this example a set of P2MP LDP LSPs are setup between PE
routers acting as Ingress LSRs and PE routers acting as Egress LSRs, so
as to support multicast VPN traffic delivery within the MPLS
backbone.</t>
<t>For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and
Egress LSRs PE2, PE3, and PE4. It is used to transport multicast traffic
from PE1 to PE2, PE3 and PE4. P1 is a Branch LSR, it replicates MPLS
traffic sent by PE1 to P2, P3 and PE2. P2 and P3 are non-branch transit
LSRs, they forward MPLS traffic sent by P1 to PE3 and PE4
respectively.</t>
<figure align="center" anchor="fig1" title="P2MP LSP from PE1 to PE2, PE3, PE4." suppress-title="false" alt="" width="" height="">
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
PE1
*| *** P2MP LDP LSP
*|*****
P1-----PE2
*/ \*
*/ \*
*****/ \******
PE3----P2 P3----PE4
| |
| |
| |
PE5 PE6
</artwork>
</figure>
<t>If later there are new receivers attached to PE5 and PE6, then PE5
and PE6 join the P2MP LDP LSP. P2 and P3 become Branch LSRs and
replicate traffic received from P1, to PE3 and PE5, and to PE4 and PE6
respectively (see <xref target="fig2" pageno="false" format="default"/> below).</t>
<figure align="center" anchor="fig2" title="Attachment of PE5 and PE6." suppress-title="false" alt="" width="" height="">
<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
PE1
*| *** P2MP LDP LSP
*|*****
P1-----PE2
*/ \*
*/ \*
*****/ \******
PE3----P2 P3----PE4
*| |*
*| |*
*| |*
PE5 PE6
</artwork>
</figure>
<t>The above example is provided for the sake of illustration. Note that
P2MP LSPs ingress and egress LSRs may not necessarily be PE routers.
Also branch LSRs may not necessarily be P routers.</t>
</section>
<section anchor="detailedreqs" title="Detailed Requirements" toc="default">
<section title="P2MP LSPs" toc="default">
<t>The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data
plane aspects related to P2MP LSPs are those already defined in <xref target="RFC4461" pageno="false" format="default"/>. That is, a P2MP LSP has one Ingress LSR and
one or more Egress LSRs. Traffic sent by the Ingress LSR is received
by all Egress LSRs. The specific aspects related to P2MP LSPs is the
action required at a Branch LSR, where data replication occurs.
Incoming labelled data is appropriately replicated to several outgoing
interfaces which may use different labels. Only one copy of a packet
MUST be sent on a given link of a P2MP LSP.</t>
<t>A P2MP LSP MUST be identified by a constant and unique identifier
within the whole LDP domain, whatever the number of leaves, which may
vary dynamically. This identifier will be used so as to add/remove
leaves to/from the P2MP tree.</t>
</section>
<section title="P2MP LSP FEC" toc="default">
<t>As with P2P MPLS technology <xref target="RFC5036" pageno="false" format="default"/>, traffic
MUST be classified into a FEC in this P2MP extension. All packets
which belong to a particular P2MP FEC and which travel from a
particular node MUST use the same P2MP LSP.</t>
<t>As such, a new LDP FEC that is suitable for P2MP forwarding MUST be
specified.</t>
</section>
<section title="P2MP LDP routing" toc="default">
<t>As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support
hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the
information maintained in LSR Routing Information Bases (RIB).</t>
<t>It is RECOMMENDED that the P2MP LSP routing rely upon a shortest
path to the Ingress LSR so as to setup an MPLS shortest path tree.</t>
</section>
<section title="Setting up, tearing down and modifying P2MP LSPs" toc="default">
<t>The P2MP LDP mechanism MUST support the establishment, maintenance
and teardown of P2MP LSPs in a scalable manner. This MUST include both
the existence of a large amount of P2MP LSPs within a single network
and a large amount of leaf LSRs for a single P2MP LSP (see also
section 5.17 for scalability considerations and figures).</t>
<t>In order to scale well with a large number of leaves it is
RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For
that purpose, leaves will have to be aware of the P2MP LSP identifier.
The ways a Leaf LSR discovers P2MP LSPs identifiers rely on the
applications that will use P2MP LSPs, and are out of the scope of this
document.</t>
<t>The P2MP LDP mechanism MUST allow the dynamic addition and removal
of leaves to and from a P2MP LSP, without any restriction (provided
there is network connectivity). It is RECOMMENDED that these
operations be leaf-initiated. These operations MUST NOT impact the
data transfer (packet loss, duplication, delay) towards other leaves.
It is RECOMMENDED that these operations do not cause any additional
processing except on the path from the added/removed Leaf LSR to the
Branch LSR.</t>
</section>
<section title="Label Advertisement" toc="default">
<t>The P2MP LDP mechanism MUST support downstream unsolicited label
advertisement mode. This is well suited to a leaf-initiated approach
and is consistent with P2P/MP2P LDP operations.</t>
<t>Other advertisement modes MAY also be supported.</t>
</section>
<section title="Data Duplication" toc="default">
<t>Data duplication refers to the receipt of multiple copies of a
packet by any leaf. Although this may be a marginal situation, it may
also be detrimental for certain applications. Hence, data duplication
SHOULD as much as possible be avoided, and limited to (hopefully rare)
transitory conditions.</t>
<t>Note, in particular, that data duplication might occur if P2MP LSP
rerouting is being performed (See also section 6.8).</t>
</section>
<section title="Detecting and Avoiding Loops" toc="default">
<t>The P2MP LDP extension MUST have a mechanism to detect routing
loops. This may rely on extensions to the LDP Loop detection mechanism
defined in <xref target="RFC5036" pageno="false" format="default"/>. A loop detection mechanism
may require recording the set of LSRs traversed on the P2MP Tree. The
P2MP loop avoidance mechanism MUST NOT impact the scalability of the
P2MP LDP solution.</t>
<t>The P2MP LDP mechanism SHOULD have a mechanism to avoid routing
loops in the data plane even during transient events.</t>
<t>Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the
data plane, that may trigger unexpected non-localized exponential
growth of traffic.</t>
</section>
<section title="P2MP LSP Re-routing" toc="default">
<t>The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in
the following cases:<list style="symbols">
<t>Network failure (link or node);</t>
<t>A better path exists (e.g. new link, metric change);</t>
<t>Planned maintenance.</t>
</list></t>
<t>Given that P2MP LDP routing should rely on the RIB, the achievement
of the following requirements also implies the underlying routing
protocols (IGP, etc.).</t>
<section title="Rerouting upon Network Failure" toc="default">
<t>The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in
case of link or node failure(s), by relying upon update of the
routes in the RIB. The rerouting time SHOULD be minimized as much as
possible so as to reduce traffic disruption.</t>
<t>A mechanism MUST be defined to prevent constant P2MP LSP teardown
and rebuild which may be caused by the instability of a specific
link/node in the network. This will rely on IGP dampening but may be
completed by specific dampening at the LDP level.</t>
</section>
<section title="Rerouting on a Better Path" toc="default">
<t>The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in
case a better path is created in the network, for instance as a
result of a metric change, a link repair, or the addition of links
or nodes. This will rely on update of the routes in the RIB.</t>
</section>
<section title="Rerouting upon Planned Maintenance" toc="default">
<t>The P2MP LDP mechanism MUST support planned maintenance
operations. It MUST be possible to reroute a P2MP LSP before a
link/node is deactivated for maintenance purposes. Traffic
disruption and data duplication SHOULD be minimized as much as
possible during such planned maintenance. P2MP LSP rerouting upon
planned maintenance MAY rely on a make before break procedure.</t>
</section>
</section>
<section title="Support for LAN interfaces" toc="default">
<t>The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to
send a single copy of the data onto an Ethernet LAN interface and
reach multiple adjacent downstream nodes. This requires that the same
label be negotiated with all downstream LSRs for the LSP.</t>
<t>When there are several candidate upstream LSRs on a LAN interface,
the P2MP LDP mechanism SHOULD provide a way for all downstream LSRs of
a given P2MP LSP to select the same upstream LSR, so as to avoid
traffic replication. In addition, the P2MP LDP mechanism SHOULD allow
for an efficient balancing of a set of P2MP LSPs among a set of
candidate upstream LSRs on a LAN interface.</t>
</section>
<section title="Support for encapsulation in P2P and P2MP TE tunnels" toc="default">
<t>The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and
P2MP TE tunnels.</t>
<t>The P2MP LDP mechanism MUST provide a way for a Branch LSR of a
P2MP LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a
single copy of the data onto the tunnel and reach all downstream LSRs
on the P2MP LSP, which are also Egress LSRs of the tunnel. As with LAN
interfaces, this requires that the same label be negotiated with all
downstream LSRs of the P2MP LDP LSP.</t>
</section>
<section title="Label spaces" toc="default">
<t>Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared
or dedicated label spaces.</t>
<t>Note that dedicated label spaces will require the establishment of
separate P2P and P2MP LDP sessions.</t>
</section>
<section title="IPv4/IPv6 support" toc="default">
<t>The P2MP LDP mechanism MUST support the establishment of LDP
sessions over both IPv4 and IPv6 control planes.</t>
</section>
<section title="Multi-Area/AS LSPs" toc="default">
<t>The P2MP LDP mechanism MUST support the establishment of multi-area
P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP
area as the Ingress LSR. This SHOULD be possible without requiring the
advertisement of Ingress LSRs' addresses across IGP areas.</t>
<t>The P2MP LDP mechanism MUST also support the establishment of
inter-AS P2MP LSPs, i.e. LSPs whose leaves do not all reside in the
same AS as the Ingress LSR. This SHOULD be possible without requiring
the advertisement of Ingress LSRs' addresses across ASes.</t>
</section>
<section title="OAM" toc="default">
<t>LDP management tools (<xref target="RFC3815" pageno="false" format="default"/>, etc.) will
have to be enhanced to support P2MP LDP extensions. This may yield a
new MIB module, which may possibly be inherited from the LDP MIB.</t>
<t>Built-in diagnostic tools MUST be defined to check the
connectivity, trace the path and ensure fast detection of data plane
failures on P2MP LDP LSPs.</t>
<t>Further and precise requirements and mechanisms for P2MP MPLS OAM
purpose are out of the scope of this document and are addressed in
<xref target="RFC4687" pageno="false" format="default"/>.</t>
</section>
<section title="Graceful Restart and Fault Recovery" toc="default">
<t>LDP Graceful Restart mechanisms <xref target="RFC3478" pageno="false" format="default"/> and
Fault Recovery mechanisms <xref target="RFC3479" pageno="false" format="default"/> SHOULD be
enhanced to support P2MP LDP LSPs.</t>
</section>
<section title="Robustness" toc="default">
<t>A solution MUST avoid single points of failures provided there is
enough network connectivity.</t>
</section>
<section title="Scalability" toc="default">
<t>Scalability is a key requirement for the P2MP LDP mechanism. It
MUST be designed to scale well with an increase in the number of any
of the following: <list style="symbols">
<t>number of Leaf LSRs per P2MP LSP;</t>
<t>number of Downstream LSRs per Branch LSR;</t>
<t>number of P2MP LSPs per LSR.</t>
</list></t>
<t>In order to scale well with an increase in the number of leaves, it
is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one
particular LSP, depend only on the number of adjacent LSRs on the
LSP.</t>
<section title="Orders of magnitude expected in operational networks" toc="default">
<t>Typical orders of magnitude that we expect should be supported
are: <list style="symbols">
<t>tens of thousands of P2MP trees spread out across core
network routers;</t>
<t>hundreds, or a few thousands, of leaves per tree;</t>
</list></t>
<t>See also section 4.2 of <xref target="RFC4834" pageno="false" format="default"/>.</t>
</section>
</section>
<section title="Backward Compatibility" toc="default">
<t>In order to allow for a smooth migration, the P2MP LDP mechanism
SHOULD offer as much backward compatibility as possible. In
particular, the solution SHOULD allow the setup of a P2MP LSP along
non-Branch Transit LSRs that do not support P2MP LDP extensions.</t>
<t>Also, the P2MP LDP solution MUST co-exist with current LDP
mechanisms and inherit its capability sets from <xref target="RFC5036" pageno="false" format="default"/>. The P2MP LDP solution MUST NOT impede the
operation of P2P/MP2P LSPs. A P2MP LDP solution MUST be designed in
such a way that it allows P2P/MP2P and P2MP LSPs to be signalled on
the same interface.</t>
</section>
</section>
<section anchor="sharedtrees" title="Shared Trees" toc="default">
<t>For traffic delivery between a group of N Leaf LSRs which are acting
indifferently as Ingress or Egress LSRs, it may be useful to setup a
shared tree connecting all these LSRs, instead of having N P2MP LSPs.
This would reduce the amount of control and forwarding state that has to
be maintained on a given LSR.</t>
<t>There are actually two main options for supporting such shared
trees:<list style="symbols">
<t>This could rely on the applications protocols that use LDP LSPs.
A shared tree could consist of the combination of a MP2P LDP LSP
from Leafs LSRs to a given root node, with a P2MP LSP from this root
to Leaf LSRs. For instance with Multicast L3 VPN applications, it
would be possible to build a shared tree by combining (see <xref target="I-D.ietf-l3vpn-2547bis-mcast" pageno="false" format="default"/>):<list style="symbols">
<t>a MP2P unicast LDP LSP, from each PE of the group to a
particular root PE acting as tree root,</t>
<t>with a P2MP LDP LSP from this root PE to each PE of the
group.</t>
</list></t>
<t>Or this could rely on a specific LDP mechanism allowing to setup
multipoint-to-multipoint MPLS LSPs (MP2MP LSPs).</t>
</list>The former approach (Combination of MP2P and P2MP LSPs at the
application level) is out of the scope of this document while the latter
(MP2MP LSPs) belong to the scope of this document. Requirements for the
set up of MP2MP LSPs are listed below.</t>
<section title="Requirements for MP2MP LSPs" toc="default">
<t>A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting
indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf LSR
is received by all other Leaf LSRs of the group.</t>
<t>Procedures for setting up MP2MP LSPs with LDP SHOULD be specified.
An implementation that support P2MP LDP LSPs MAY also support MP2MP
LDP LSP.</t>
<t>The MP2MP LDP procedures MUST NOT impede the operations of P2MP
LSP.</t>
<t>Requirements for P2MP LSPs, set forth in section 6, apply equally
to MP2MP LSPs. Particular attention should be given on the below
requirements:<list style="symbols">
<t>The solution MUST support recovery upon link and transit node
failure and there MUST NOT be any single point of failure
(provided network connectivity is redundant);</t>
<t>The size of MP2MP state on a LSR, for one particular MP2MP LSP,
SHOULD only depend on the number of adjacent LSRs on the LSP;</t>
<t>Furthermore, the MP2MP LDP mechanism MUST avoid routing loops
that may trigger exponential growth of traffic. Note that this
requirement is more challenging with MP2MP LSPs as a LSR can
receive traffic for a given LSP on multiple interfaces.</t>
</list></t>
<t>There are additional requirements specific to MP2MP LSPs:<list style="symbols">
<t>It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths
to a specific LSR called root LSR;</t>
<t>It is RECOMMENDED to define several root LSRs (e.g. a primary
and a backup) to ensure redundancy upon root LSR failure;</t>
<t>The receiver SHOULD NOT receive back a packet it has sent on
the MP2MP LSP;</t>
<t>The solution SHOULD avoid that all traffic between any pair of
leaves is traversing a root LSR, and SHOULD as much as possible
minimize the distance between two leaves (similarly to PIM-Bidir
trees);</t>
<t>It MUST be possible to check connectivity of a MP2MP LSP in
both directions.</t>
</list></t>
</section>
</section>
<section anchor="evalcriteria" title="Evaluation criteria" toc="default">
<section title="Performances" toc="default">
<t>The solution will be evaluated with respect to the following
criteria:<list style="format (%d)">
<t>Time to add or remove a Leaf LSR;</t>
<t>Time to repair a P2MP LSP in case of link or node failure;</t>
<t>Scalability (state size, number of messages, message size).</t>
</list></t>
<t>Particularly the P2MP LDP mechanism SHOULD be designed with as key
objective to minimize the additional amount of state and additional
processing required in the network.</t>
<t>Also, the P2MP LDP mechanism SHOULD be designed so that convergence
times in case of link or node failure are minimized, in order to limit
traffic disruption.</t>
</section>
<section title="Complexity and Risks" toc="default">
<t>The proposed solution SHOULD NOT introduce complexity to the
current LDP operations to such a degree that it would affect the
stability and diminish the benefits of deploying such solution.</t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>This document does not introduce any new security issue beyond those
inherent to LDP, and a P2MP LDP solution will rely on the security
mechanisms defined in <xref target="RFC5036" pageno="false" format="default"/> (e.g. TCP MD5
Signature).</t>
<t>An evaluation of the security features for MPLS networks may be found
in <xref target="RFC5920" pageno="false" format="default"/>, and where issues or further work is
identified by that document, new security features or procedures for the
MPLS protocols will need to be developed.</t>
</section>
<section title="IANA Considerations" toc="include">
<t>This informational document makes no requests to IANA for action.</t>
</section>
<section title="Acknowledgments" toc="default">
<t>We would like to thank Christian Jacquenet (France Telecom), Hitoshi
Fukuda (NTT), Ina Minei (Juniper), Dean Cheng (Cisco), and Benjamin
Niven-Jenkins (BT), for their highly useful comments and
suggestions.</t>
<t>We would also like to thank authors of <xref target="RFC4461" pageno="false" format="default"/>
from which some text of this document has been inspired.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- Begin inclusion reference.RFC.2119.xml. --><reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt"/>
<format type="HTML" octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference><!-- End inclusion reference.RFC.2119.xml. -->
<!-- Begin inclusion reference.RFC.3031.xml. --><reference anchor="RFC3031">
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization/></author>
<author initials="A." surname="Viswanathan" fullname="A. Viswanathan">
<organization/></author>
<author initials="R." surname="Callon" fullname="R. Callon">
<organization/></author>
<date year="2001" month="January"/>
<abstract>
<t>This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="3031"/>
<format type="TXT" octets="147175" target="http://www.rfc-editor.org/rfc/rfc3031.txt"/>
</reference><!-- End inclusion reference.RFC.3031.xml. -->
<!-- Begin inclusion reference.RFC.5036.xml. --><reference anchor="RFC5036">
<front>
<title>LDP Specification</title>
<author initials="L." surname="Andersson" fullname="L. Andersson">
<organization/></author>
<author initials="I." surname="Minei" fullname="I. Minei">
<organization/></author>
<author initials="B." surname="Thomas" fullname="B. Thomas">
<organization/></author>
<date year="2007" month="October"/>
<abstract>
<t>The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="5036"/>
<format type="TXT" octets="287101" target="http://www.rfc-editor.org/rfc/rfc5036.txt"/>
</reference><!-- End inclusion reference.RFC.5036.xml. -->
<!-- Begin inclusion reference.RFC.3815.xml. --><reference anchor="RFC3815">
<front>
<title>Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)</title>
<author initials="J." surname="Cucchiara" fullname="J. Cucchiara">
<organization/></author>
<author initials="H." surname="Sjostrand" fullname="H. Sjostrand">
<organization/></author>
<author initials="J." surname="Luciani" fullname="J. Luciani">
<organization/></author>
<date year="2004" month="June"/>
<abstract>
<t>This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="3815"/>
<format type="TXT" octets="215916" target="http://www.rfc-editor.org/rfc/rfc3815.txt"/>
</reference><!-- End inclusion reference.RFC.3815.xml. -->
<!-- Begin inclusion reference.RFC.3478.xml. --><reference anchor="RFC3478">
<front>
<title>Graceful Restart Mechanism for Label Distribution Protocol</title>
<author initials="M." surname="Leelanivas" fullname="M. Leelanivas">
<organization/></author>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization/></author>
<author initials="R." surname="Aggarwal" fullname="R. Aggarwal">
<organization/></author>
<date year="2003" month="February"/>
<abstract>
<t>This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart. The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="3478"/>
<format type="TXT" octets="29248" target="http://www.rfc-editor.org/rfc/rfc3478.txt"/>
</reference><!-- End inclusion reference.RFC.3478.xml. -->
<!-- Begin inclusion reference.RFC.3479.xml. --><reference anchor="RFC3479">
<front>
<title>Fault Tolerance for the Label Distribution Protocol (LDP)</title>
<author initials="A." surname="Farrel" fullname="A. Farrel">
<organization/></author>
<date year="2003" month="February"/>
<abstract>
<t>Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations. The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="3479"/>
<format type="TXT" octets="115778" target="http://www.rfc-editor.org/rfc/rfc3479.txt"/>
</reference><!-- End inclusion reference.RFC.3479.xml. -->
</references>
<references title="Informative References">
<!-- Begin inclusion reference.RFC.4834.xml. --><reference anchor="RFC4834">
<front>
<title abbrev="L3VPN Mcast Reqs">Requirements for Multicast in Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)</title>
<author fullname="Thomas Morin" initials="T" role="editor" surname="Morin">
<organization abbrev="France Telecom R&D">France Telecom
R&D</organization>
<address>
<postal>
<street>2, avenue Pierre Marzin</street>
<code>22307</code>
<city>Lannion</city>
<country>France</country></postal>
<email>thomas.morin@orange-ftgroup.com</email></address></author>
<date year="2007" month="April"/>
<workgroup>l3vpn Working Group</workgroup>
<abstract>
<t>This document presents a set of functional requirements for network
solutions that allow the deployment of IP multicast within Layer 3 (L3)
Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies
requirements both from the end user and service provider standpoints. It
is intended that potential solutions specifying the support of IP
multicast within such VPNs will use these requirements as
guidelines.</t></abstract></front>
<seriesInfo name="RFC" value="4834"/>
<format type="TXT" octets="80341" target="http://www.rfc-editor.org/rfc/rfc4834.txt"/>
<format type="HTML" octets="135344" target="http://xml.resource.org/public/rfc/html/rfc4834.html"/>
<format type="XML" octets="159945" target="http://xml.resource.org/public/rfc/xml/rfc4834.xml"/>
</reference><!-- End inclusion reference.RFC.4834.xml. -->
<!-- Begin inclusion reference.I-D.ietf-l3vpn-2547bis-mcast.xml. --><reference anchor="I-D.ietf-l3vpn-2547bis-mcast">
<front>
<title>Multicast in MPLS/BGP IP VPNs</title>
<author initials="R" surname="Aggarwal" fullname="Rahul Aggarwal">
<organization/>
</author>
<author initials="S" surname="Bandi" fullname="Sarveshwar Bandi">
<organization/>
</author>
<author initials="Y" surname="Cai" fullname="Yiqun Cai">
<organization/>
</author>
<author initials="T" surname="Morin" fullname="Thomas Morin">
<organization/>
</author>
<author initials="Y" surname="Rekhter" fullname="Yakov Rekhter">
<organization/>
</author>
<author initials="E" surname="Rosen" fullname="Eric Rosen">
<organization/>
</author>
<author initials="I" surname="Wijnands" fullname="IJsbrand Wijnands">
<organization/>
</author>
<author initials="S" surname="Yasukawa" fullname="Seisho Yasukawa">
<organization/>
</author>
<date month="January" day="28" year="2010"/>
<abstract><t>In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-l3vpn-2547bis-mcast-10"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-2547bis-mcast-10.txt"/>
</reference><!-- End inclusion reference.I-D.ietf-l3vpn-2547bis-mcast.xml. -->
<!-- Begin inclusion reference.I-D.ietf-l2vpn-vpls-mcast.xml. --><reference anchor="I-D.ietf-l2vpn-vpls-mcast">
<front>
<title>Multicast in VPLS</title>
<author initials="R" surname="Aggarwal" fullname="Rahul Aggarwal">
<organization/>
</author>
<author initials="Y" surname="Kamite" fullname="Yuji Kamite">
<organization/>
</author>
<author initials="L" surname="Fang" fullname="Luyuan Fang">
<organization/>
</author>
<author initials="Y" surname="Rekhter" fullname="Yakov Rekhter">
<organization/>
</author>
<date month="October" day="25" year="2010"/>
<abstract><t>This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSes are also described.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-l2vpn-vpls-mcast-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-08.txt"/>
</reference><!-- End inclusion reference.I-D.ietf-l2vpn-vpls-mcast.xml. -->
<!-- Begin inclusion reference.RFC.4687.xml. --><reference anchor="RFC4687">
<front>
<title>Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks</title>
<author initials="S." surname="Yasukawa" fullname="S. Yasukawa">
<organization/></author>
<author initials="A." surname="Farrel" fullname="A. Farrel">
<organization/></author>
<author initials="D." surname="King" fullname="D. King">
<organization/></author>
<author initials="T." surname="Nadeau" fullname="T. Nadeau">
<organization/></author>
<date year="2006" month="September"/>
<abstract>
<t>Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.</t><t> For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.</t><t> This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name="RFC" value="4687"/>
<format type="TXT" octets="30486" target="http://www.rfc-editor.org/rfc/rfc4687.txt"/>
</reference><!-- End inclusion reference.RFC.4687.xml. -->
<!-- Begin inclusion reference.RFC.4461.xml. --><reference anchor="RFC4461">
<front>
<title>Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)</title>
<author initials="S." surname="Yasukawa" fullname="S. Yasukawa">
<organization/></author>
<date year="2006" month="April"/>
<abstract>
<t>This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).</t><t> There is no intent to specify solution-specific details or application-specific requirements in this document.</t><t> The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name="RFC" value="4461"/>
<format type="TXT" octets="64542" target="http://www.rfc-editor.org/rfc/rfc4461.txt"/>
</reference><!-- End inclusion reference.RFC.4461.xml. -->
<!-- Begin inclusion reference.RFC.4875.xml. --><reference anchor="RFC4875">
<front>
<title>Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)</title>
<author initials="R." surname="Aggarwal" fullname="R. Aggarwal">
<organization/></author>
<author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou">
<organization/></author>
<author initials="S." surname="Yasukawa" fullname="S. Yasukawa">
<organization/></author>
<date year="2007" month="May"/>
<abstract>
<t>This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.</t><t> There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="4875"/>
<format type="TXT" octets="125394" target="http://www.rfc-editor.org/rfc/rfc4875.txt"/>
</reference><!-- End inclusion reference.RFC.4875.xml. -->
<!-- Begin inclusion reference.RFC.4026.xml. --><reference anchor="RFC4026">
<front>
<title>Provider Provisioned Virtual Private Network (VPN) Terminology</title>
<author initials="L." surname="Andersson" fullname="L. Andersson">
<organization/></author>
<author initials="T." surname="Madsen" fullname="T. Madsen">
<organization/></author>
<date year="2005" month="March"/>
<abstract>
<t>The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services.</t><t> To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name="RFC" value="4026"/>
<format type="TXT" octets="42124" target="http://www.rfc-editor.org/rfc/rfc4026.txt"/>
</reference><!-- End inclusion reference.RFC.4026.xml. -->
<!-- Begin inclusion reference.RFC.3209.xml. --><reference anchor="RFC3209">
<front>
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
<author initials="D." surname="Awduche" fullname="D. Awduche">
<organization/></author>
<author initials="L." surname="Berger" fullname="L. Berger">
<organization/></author>
<author initials="D." surname="Gan" fullname="D. Gan">
<organization/></author>
<author initials="T." surname="Li" fullname="T. Li">
<organization/></author>
<author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
<organization/></author>
<author initials="G." surname="Swallow" fullname="G. Swallow">
<organization/></author>
<date year="2001" month="December"/>
<abstract>
<t>This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="3209"/>
<format type="TXT" octets="132264" target="http://www.rfc-editor.org/rfc/rfc3209.txt"/>
</reference><!-- End inclusion reference.RFC.3209.xml. -->
<!-- Begin inclusion reference.RFC.5920.xml. --><reference anchor="RFC5920">
<front>
<title>Security Framework for MPLS and GMPLS Networks</title>
<author initials="L." surname="Fang" fullname="L. Fang">
<organization/></author>
<date year="2010" month="July"/>
<abstract>
<t>This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name="RFC" value="5920"/>
<format type="TXT" octets="152830" target="http://www.rfc-editor.org/rfc/rfc5920.txt"/>
</reference><!-- End inclusion reference.RFC.5920.xml. -->
<!-- Begin inclusion reference.RFC.5501.xml. --><reference anchor="RFC5501">
<front>
<title>Requirements for Multicast Support in Virtual Private LAN Services</title>
<author initials="Y." surname="Kamite" fullname="Y. Kamite">
<organization/></author>
<author initials="Y." surname="Wada" fullname="Y. Wada">
<organization/></author>
<author initials="Y." surname="Serbest" fullname="Y. Serbest">
<organization/></author>
<author initials="T." surname="Morin" fullname="T. Morin">
<organization/></author>
<author initials="L." surname="Fang" fullname="L. Fang">
<organization/></author>
<date year="2009" month="March"/>
<abstract>
<t>This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name="RFC" value="5501"/>
<format type="TXT" octets="71507" target="http://www.rfc-editor.org/rfc/rfc5501.txt"/>
</reference><!-- End inclusion reference.RFC.5501.xml. -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 22:12:26 |