draft-ietf-mpls-p2mp-te-bypass-00.txt   draft-ietf-mpls-p2mp-te-bypass-01.txt 
Network Working Group J.L. Le Roux Network Working Group J.L. Le Roux (Ed.)
Internet Draft France Telecom Internet Draft France Telecom
Category: Standard Track Category: Standard Track
Expires: November 2007 R. Aggarwal Expires: January 2008 R. Aggarwal
Juniper Networks Juniper Networks
J.P. Vasseur J.P. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
M. Vigoureux M. Vigoureux
Alcatel-Lucent Alcatel-Lucent
P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels
draft-ietf-mpls-p2mp-te-bypass-00.txt draft-ietf-mpls-p2mp-te-bypass-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 10 skipping to change at page 2, line 10
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines procedures for fast reroute protection of This document defines procedures for fast reroute protection of
Point-To-MultiPoint (P2MP) Traffic Engineering Label Switched Paths Point-To-MultiPoint (P2MP) Traffic Engineering Label Switched Paths
(TE-LSP) in MultiProtocol Label Switching (MPLS) networks, based (TE-LSP) in MultiProtocol Label Switching (MPLS) networks, based
upon Point-To-MultiPoint bypass tunnels. The motivation for using upon Point-To-MultiPoint Bypass Tunnels. The motivation for using
P2MP bypass tunnels is to avoid potentially expensive data P2MP Bypass Tunnels is to avoid potentially expensive data
duplication along the backup path that could occur if point-to-point duplication along the backup path that could occur if Point-To-Point
bypass tunnels where used, i.e. to optimize the bandwidth usage, Bypass Tunnels were used, i.e., to optimize the bandwidth usage,
during fast reroute protection of a link or a node. During link or during fast reroute protection of a link or a node. During link or
node failure the traffic carried onto a protected P2MP TE-LSP is node failure the traffic carried onto a protected P2MP TE-LSP is
tunnelled within one or several P2MP bypass tunnels towards a set of tunnelled within one or several P2MP Bypass Tunnels towards a set of
Merge Points. To avoid data duplication backup labels (i.e. inner Merge Points. To avoid data duplication, backup labels (i.e., inner
labels) are assigned by the Point of Local Repair (PLR) following the labels) are assigned by the Point of Local Repair (PLR) according to
RSVP-TE upstream label assignment procedure. the RSVP-TE upstream label assignment procedure.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119. document are to be interpreted as described in RFC-2119.
Table of Contents Table of Contents
1. Terminology.................................................3 1. Terminology.................................................3
2. Introduction................................................3 2. Introduction................................................3
3. Solution overview...........................................4 3. Solution overview...........................................4
4. PLR procedures..............................................6 4. PLR procedures..............................................6
4.1. Before failure..............................................6 4.1. Before failure..............................................6
4.1.1. P2MP Bypass Tunnel(s) Selection.............................6 4.1.1. P2MP Bypass Tunnel(s) Selection.............................6
4.1.2. P2MP Backup LSP Signalling..................................7 4.1.2. P2MP Backup LSP Signaling over a P2MP Bypass Tunnel.........7
4.2. During failure..............................................8 4.2. During failure..............................................8
5. MP Procedures...............................................8 4.3. After failure...............................................8
6. To be included in future revisions..........................9 5. MP Procedures...............................................9
7. Security Considerations.....................................9 6. Combination of P2P and P2MP Bypass tunnels..................9
8. Acknowledgments.............................................9 7. Partial Protection.........................................10
9. References..................................................9 8. Location of the PLR........................................11
9.1. Normative references........................................9 9. Security Considerations....................................11
10. Authors' Addresses:........................................10 10. IANA Considerations........................................11
11. Intellectual Property Statement............................11 10.1. LSP Attributes Flags.......................................11
11. Acknowledgments............................................11
12. References.................................................11
12.1. Normative references.......................................11
12.2. Informational references...................................12
13. Authors' Addresses:........................................12
14. Intellectual Property Statement............................13
1. Terminology 1. Terminology
This document uses terminologies defined in [RFC3031], [RFC3209], This document uses terminologies defined in [RFC3031], [RFC3209],
[RFC4090] and [RFC4461]. It defines the following new terms: [RFC4090] and [RFC4461]. It defines the following new terms:
P2MP Bypass tunnel: Point-to-Multipoint Bypass Tunnel. A P2MP TE- P2MP Bypass Tunnel: Point-to-Multipoint Bypass Tunnel. A P2MP TE-
LSP that is used to protect a set of P2MP TE-LSPs traversing a LSP that is used to protect a set of P2MP TE-LSPs traversing a
common facility (link or node). common facility (link or node).
P2MP Facility Backup: A local repair method in which a P2MP bypass P2MP Facility Backup: A local repair method in which a P2MP Bypass
tunnel is used to protect one or more P2MP TE-LSPs that Tunnel is used to protect one or more P2MP TE-LSPs that traverse the
traverse the Point of Local Repair (P2MP Bypass Ingress) and the Point of Local Repair (P2MP Bypass Ingress) and the resource being
resource being protected. protected.
Backup P2MP LSP: The LSP that is used to backup up one of the Backup P2MP LSP: The LSP that is used to backup up one of the
many protected P2MP LSPs in P2MP Facility Backup. many protected P2MP LSPs in P2MP Facility Backup.
Backup label: Label of a backup P2MP LSP.
Backup S2L sub-LSP: A S2L sub-LSP of a backup P2MP LSP. Backup S2L sub-LSP: A S2L sub-LSP of a backup P2MP LSP.
PLR: Point of Local Repair: Head-end LSR of the bypass tunnel PLR: Point of Local Repair: Head-end LSR of the bypass tunnel
MP: Merge Point: LSR where a primary LSP and its backup LSP merge. MP: Merge Point: LSR where a primary LSP and its backup LSP merge.
. .
2. Introduction 2. Introduction
[RFC4090] defines fast reroute extensions to RSVP-TE [RFC3209] for [RFC4090] defines Fast ReRoute (FRR) extensions to RSVP-TE [RFC3209]
local protection of Point-To-Point (P2P) Traffic Engineered Label for local protection of Point-To-Point (P2P) Traffic Engineered Label
Switched Paths (TE LSP) in MultiProtocol Label Switching (MPLS) Switched Paths (TE LSP) in MultiProtocol Label Switching (MPLS)
networks. Two techniques are defined: the one-to-one backup method, networks. Two techniques are defined: the one-to-one backup method,
which creates a detour LSP for each protected LSP at each point of which creates a detour LSP for each protected LSP at each point of
local repair (PLR), and the facility backup method, which creates a local repair (PLR), and the facility backup method, which creates a
bypass tunnel that can be used to protect a set of TE LSPs by taking bypass tunnel that can be used to protect a set of TE LSPs by taking
advantage of MPLS label stacking. advantage of MPLS label stacking.
[RSVP-P2MP] defines extensions to RSVP-TE for setting up Point-To- [RFC4875] defines extensions to RSVP-TE for setting up Point-To-
Multipoint (P2MP) TE LSPs. It specifies extensions to one-to-one and Multipoint (P2MP) TE LSPs. It specifies extensions to one-to-one and
facility backup Fast Reroute procedures defined in [RFC4090] so as to facility backup Fast Reroute procedures defined in [RFC4090] so as to
support fast reroute protection of P2MP TE LSPs. support fast reroute protection of P2MP TE LSPs.
The facility backup solution defined in [RSVP-P2MP] only relies on The facility backup solution defined in [RFC4875] only relies on P2P
P2P bypass tunnels for link and node protection. This faces the Bypass Tunnels for link and node protection. This faces the following
following limitations: limitations:
- The protection of a downstream link of a P2MP TE LSP on a - The protection of a downstream link of a P2MP TE LSP on a
branch LSR may require a P2P Bypass LSP that uses another branch LSR may require a P2P Bypass LSP that uses another
downstream link of the P2MP LSP, and this leads to twice the downstream link of the P2MP LSP, and this leads to twice the
traffic on that link during failure, which is inefficient. traffic on that link during failure, which is inefficient.
Finding a bypass path that avoids all downstream links on the Finding a bypass path that avoids all downstream links on the
P2MP LSP would be a solution but this is often not achievable in P2MP LSP would be a solution but this is often not achievable in
lowly meshed topologies. lowly meshed topologies.
- The protection of a P2MP TE LSP against node failures - The protection of a P2MP TE LSP against node failures
requires, when the protected node is a Branch LSR, a set of P2P requires, when the protected node is a Branch LSR, a set of P2P
Next-Next-Hop (NNHOP) Bypass tunnels toward all LSRs downstream Next-Next-Hop (NNHOP) Bypass Tunnels toward all LSRs downstream
to the protected node. During failure the PLR has to replicate to the protected node. During failure the PLR has to replicate
traffic on each P2P NNHOP bypass tunnel. If there are K next- traffic on each P2P NNHOP Bypass Tunnel. If there are K next-
next-hops, this may lead to K times the traffic on some links, next-hops, this may lead to K times the traffic on some links,
which is not acceptable (as K is of the order of magnitude of which is not acceptable.
the squared node degree).
- Similarly the protection of a P2MP TE LSP against the failure - Similarly the protection of a P2MP TE LSP against the failure
of a LAN interface that connects a branch LSR and a set of K of a LAN interface that connects a branch LSR and a set of K
downstream LSRs requires one P2P bypass tunnel per downstream downstream LSRs requires one P2P Bypass Tunnel per downstream
LSR, which may lead to K times the traffic on some links during LSR, which may lead to K times the traffic on some links during
failure. failure.
To overcome these limitations it is highly desirable to define To overcome these limitations it is highly desirable to define
extensions to the fast reroute facility backup solution, so as to extensions to the fast reroute facility backup solution, so as to
support P2MP bypass tunnels. This retains the scalability advantages support P2MP Bypass Tunnels. This retains the scalability advantages
of MPLS label stacking and avoids sending multiple copies of a packet of MPLS label stacking and avoids sending multiple copies of a packet
on some links during failure. on some links during failure.
This draft specifies extensions to the Fast ReRoute (FRR) procedures This draft specifies extensions to the Fast ReRoute (FRR) procedures
defined in [RFC4090] and [RSVP-P2MP] to support local repair of P2MP defined in [RFC4090] and [RFC4875] to support local repair of P2MP TE
TE LSP with P2MP bypass tunnels. LSP with P2MP Bypass Tunnels.
Procedures defined in [RFC3209], [RFC4090] and [RSVP-P2MP] MUST be Procedures defined in [RFC3209], [RFC4090] and [RFC4875] MUST be
followed unless specified below. followed unless specified below.
3. Solution overview 3. Solution overview
The P2MP Facility Backup method defined in this document relies on The P2MP Facility Backup method defined in this document relies on
the use of P2MP bypass tunnels. Similarly to the P2P case, the same the use of P2MP Bypass Tunnels. Similarly to the P2P case, the same
P2MP bypass tunnel can be used to protect a set of P2MP TE LSPs, by P2MP Bypass Tunnel can be used to protect a set of P2MP TE LSPs, by
taking advantage of MPLS label stacking. taking advantage of MPLS label stacking.
A P2MP Bypass tunnel can be used to protect a P2MP TE-LSP against A P2MP Bypass Tunnel can be used to protect a P2MP TE-LSP against
downstream link or node failures. There are various options for the downstream link or node failures.
protection of a downstream link or node:
- Rely on a single P2MP bypass tunnel whose leaf LSRs exactly There are various options for the protection of a downstream link or
matches the set of Merge Points (MP). Merge points are node of a P2MP TE-LSP:
transit or egress LSRs on the protected P2MP LSP downstream
to the PLR or downstream to the protected element (link or - Option 1: Rely on a single P2MP Bypass Tunnel whose set of
node). leaf LSRs exactly matches the set of Merge Points (MP). Merge
- Rely on a single P2MP Bypass tunnel whose set of leaf LSRs is points are transit or egress LSRs on the protected P2MP LSP
a superset of the set of MPs. Leaf LSRs which are not MP have downstream to the PLR or downstream to the protected element
to drop the traffic. (link or node).
- Rely on a combination of P2MP bypass LSPs whose leaf LSRs are - Option 2: Rely on a single P2MP Bypass Tunnel whose set of
a subset of the set of MP but there combination encompass all leaf LSRs is a superset of the set of MPs. Leaf LSRs which
MPs. are not MP have to drop the traffic.
- Option 3: Rely on a combination of P2MP Bypass LSPs whose
leaf LSRs include a subset of the set of MPs but their
combination encompass all MPs (and this combination may be a
superset of the set of MPs).
These three options differ in terms of bandwidth optimization and These three options differ in terms of bandwidth optimization and
control plane state minimization. Option 1 increases the number of control plane state minimization. Option 1 increases the number of
states compared to option 2 (it implies more P2MP bypass LSPs), but states compared to option 2, and, in some cases, to option 3(it
is less expensive in terms of bandwidth (traffic only sent to MPs). implies more P2MP Bypass LSPs), but is less expensive in terms of
With point-to-multipoint hierarchy there is always a tension between bandwidth (traffic only sent to MPs). With point-to-multipoint
minimizing the amount of control plane state and minimizing bandwidth hierarchy there is always a tension between minimizing the amount of
consumption. Choosing one of these options is a decision local to the control plane state and minimizing bandwidth consumption. Choosing
PLR. The choice depends on the desired trade-off between control one of these options is a decision local to the PLR. The choice
plane and data plane optimization, and the operational complexity depends on the desired trade-off between control plane and data plane
associated with the different options. optimization, and the operational complexity associated with the
different options.
When the P2MP facility backup method is used, during failure the PLR When the P2MP Facility Backup method is used, during failure the PLR
MUST send data for each protected P2MP LSP into the set of one or MUST send data for each protected P2MP LSP into the set of one or
more P2MP bypass tunnel. Label stacking is used: the inner label is more P2MP Bypass Tunnels. Label stacking is used: the inner label is
the backup label for the backup P2MP LSP, that will be used on the MP the backup label for the backup P2MP LSP, that will be used on the MP
to forward traffic to the corresponding protected P2MP LSP, and the to forward traffic to the corresponding protected P2MP LSP, and the
outer label is the P2MP bypass tunnel label. outer label is the P2MP Bypass Tunnel label.
To avoid data replication on the PLR, the same backup label MUST be To avoid data replication at the PLR and to avoid traffic mis-routing
used for all S2L sub-LSPs of a given backup P2MP LSP, tunneled within in Merge Points, the same backup label MUST be used for all S2L sub-
the same P2MP bypass tunnel. This backup label will indicate to the LSPs of a given backup P2MP LSP, tunneled within the same P2MP Bypass
Merge Points that packets received with that label should be switched Tunnel. This backup label will indicate to the Merge Points that
along the protected P2MP LSP. packets received with that label should be switched along the
protected P2MP LSP.
For that purpose upstream label assignment procedures defined in For that purpose upstream label assignment procedures defined in
[MPLS-UPSTREAM] and RSVP-TE extensions for upstream label assignment [MPLS-UPSTREAM] and RSVP-TE extensions for upstream label assignment
defined in [RSVP-UP] MUST be used. To signal a backup P2MP LSP, the defined in [RSVP-UP] MUST be used. To signal a backup P2MP LSP, the
same backup label, is distributed by the PLR to all MPs belonging to same backup label, is distributed by the PLR to all MPs belonging to
a same P2MP Bypass tunnel, in the context of this P2MP bypass tunnel. a same P2MP Bypass Tunnel, in the context of this P2MP Bypass Tunnel.
This requires the backup P2MP LSP to be signalled prior to the This requires the backup P2MP LSP to be signaled prior to the failure.
failure.
On the MP, backup S2L sub-LSPs (i.e. S2L sub-LSPs of the backup P2MP At the MP, backup S2L sub-LSPs (i.e., S2L sub-LSPs of the Backup P2MP
LSP) are merged with protected S2L sub-LSPs. A MP (i.e. the bypass LSP) are merged with protected S2L sub-LSPs. A MP (i.e., the bypass
tunnel leaf LSRs), maintains a context specific ILM for the P2MP tunnel leaf LSRs), maintains a context specific Incoming Label Map
Bypass tunnel. This can be implemented by maintaining a different (ILM) for the P2MP Bypass Tunnel. This can be implemented by
context specific ILM for each LSR that is the root of a P2MP Bypass maintaining a different context specific ILM for each LSR that is the
tunnel, or by maintaining a different context specific ILM for each root of a P2MP Bypass Tunnel (per-neighbor), or by maintaining a
P2MP Bypass tunnel. The context of an inner label (i.e a backup label) different context specific ILM for each P2MP Bypass Tunnel (per-
is determined by the underlying P2MP bypass tunnel on which it is tunnel). The context of an inner label (i.e., a backup label) is
received. This requires deactivating PHP on the P2MP bypass tunnel. A determined by the underlying P2MP Bypass Tunnel on which it is
label, in a given Bypass tunnel specific ILM, is mapped to the received (as described in section 5). This requires deactivating
Penultimate Hop Popping (PHP) on the P2MP Bypass Tunnel. A backup
label, in a given P2MP Bypass Tunnel specific ILM, is mapped to the
outgoing interface(s) and label(s) of the corresponding protected outgoing interface(s) and label(s) of the corresponding protected
P2MP LSP. P2MP LSP.
The way in which the MP determines whether the PLR assigns upstream-
assigned labels from a per-tunnel, or per-platform pool (a.k.a label
space) is outside the scope of this document.
4. PLR procedures 4. PLR procedures
4.1. Before failure 4.1. Before failure
4.1.1. P2MP Bypass Tunnel(s) Selection 4.1.1. P2MP Bypass Tunnel(s) Selection
To protect a P2MP TE LSP against a downstream link or node failure, a To protect a P2MP TE LSP against a downstream link or node failure,
PLR MUST select a set of one or more P2MP bypass tunnel(s), denoted using P2MP Facility Backup, a PLR has to select a set of one or more
{B1.Bm}, as follows: P2MP Bypass Tunnel(s), denoted {B1.Bm}, as follows:
- The bypass tunnel(s) MUST NOT traverse the protected - The P2MP Bypass Tunnel(s) MUST NOT traverse the protected
link/node/SRLG. link/node/SRLG.
- The set of leaf LSRs of bypass tunnels {B1.Bm}, denoted {LSR1. - The set of leaf LSRs of P2MP Bypass Tunnels {B1.Bm}, denoted
LSRn} must include a set of Merge Points (MP), on the protected {LSR1.LSRn} must include a set of Merge Points (MP), on the
P2MP LSP. These Merge Points are transit or egress LSRs on the protected P2MP LSP. These Merge Points are transit or egress
protected P2MP LSP downstream to the PLR or downstream to the LSRs on the protected P2MP LSP downstream to the PLR or
protected element (link or node). We will denote this set of downstream to the protected element (link or node). We will
Merge Points as {MP1.MPq}. Note that the case where some MPs are denote this set of Merge Points as {MP1.MPq}. Note that the case
LSRs downstream to the PLR but not downstream to the failed where some MPs are LSRs downstream to the PLR but not downstream
element allows avoiding sending twice the traffic on downstream to the failed element allows avoiding sending twice the traffic
links during failure. on downstream links during failure.
- In the event of failure of the protected link or node, traffic -The set of Merge Points {MP1.MPq} is such that in the event of
received on the protected P2MP LSP by the PLR, can be delivered failure of the protected link or node, traffic received on the
to all the leaves of the protected P2MP LSP downstream to the protected P2MP LSP by the PLR, can be delivered to ALL the
PLR, if it is tunnelled to {MP1.MPq} over the set of one or more leaf LSRs of the protected P2MP LSP downstream to the PLR, if it
P2MP bypass tunnel(s) {B1.Bm}. is tunnelled to {MP1.MPq} over the set of one or more P2MP
Bypass Tunnel(s) {B1.Bm}.
Note: This condition, which provides full protection, does not
apply when partial protection mode is used (as described in
Section 7).
The PLR will assign upstream labels to Merge Points {MP1.MPq} for the The PLR will assign backup labels to Merge Points {MP1.MPq} for the
backup P2MP LSP. The same backup label will be assigned to all Merge backup P2MP LSP. The same label will be assigned to all Merge Points
Points belonging to the same P2MP Bypass tunnel. belonging to the same P2MP Bypass Tunnel, as defined in [MPLS-
UPSTREAM] and [RSVP-UP].
A MP may actually be leaf LSR of multiple bypass tunnels, but will be A MP may actually be the leaf LSR of multiple P2MP Bypass Tunnels
associated to only one bypass tunnel. That is a PLR will signal the used by the PLR to protect a given LSP (using Option 3 as described
P2MP backup LSP to that MP, for a single P2MP bypass tunnel context. in Section 3), but will be associated to only one P2MP Bypass Tunnel
(at a given time for a given protected P2MP LSP). That is, a PLR will
signal the P2MP Backup LSP to that MP, for a single P2MP Bypass
Tunnel context. When a MP is a leaf LSR of multiple P2MP Bypass
Tunnels, and if the PLR assigns the same backup label (i.e., inner
upstream-assigned label) for the backup P2MP LSP on several different
P2MP Backup Tunnels, the MP MUST maintain a per-tunnel ILM (and not a
per-neighbor ILM) to perform contextual lookup of the backup label.
{LSR1.LSRn} may be a superset of {MP1.MPq}, that is some leaf LSRs of {LSR1.LSRn} may be a superset of {MP1.MPq}, that is some leaf LSRs of
a given P2MP bypass tunnel, noted {LSRx.LSRy}, may not belong to a given P2MP Bypass Tunnel, noted {LSRx.LSRy}, may not belong to
{MP1.MPq}. The PLR will not assign upstream labels for the backup {MP1.MPq}. The PLR will not distribute the backup label for the
P2MP LSP to these LSRs {LSRx.LSRy}. During failure packets with a backup P2MP LSP to these LSRs {LSRx.LSRy}.
backup label will also be delivered onto the P2MP bypass tunnel to However due to the nature of the P2MP Bypass Tunnel, during failure,
{LSRx.LSRy} which will discard these packets based on no entry for packets with the backup label will also be delivered onto the P2MP
this label in the context specific ILM for that bypass tunnel. This Bypass Tunnel to {LSRx.LSRy}. {LSRx.LSRy} MUST discard these packets
requires that {LSRx.LSRy} create a context specific ILM for that based on the absence of an entry for this label in the context
bypass tunnel. specific ILM referred to that P2MP Bypass Tunnel. This requires that
{LSRx.LSRy} create a context specific ILM (per-tunnel or per-neighbor)
for that P2MP Bypass Tunnel label.
PHP MUST be deactivated on the P2MP Bypass tunnel, in order to allow PHP MUST be deactivated on the P2MP Bypass Tunnel, in order to allow
MPs to determine the context for the backup labels assigned by the MPs to determine the context for the backup labels assigned by the
PLR. PLR. Hence the P2MP Bypass Tunnel will be signaled with the "non PHP
behavior desired" bit set in the Attribute Flags TLV as specified in
[NO-PHP].
Note that P2MP bypass LSPs may be signalled in advance either Note that P2MP Bypass Tunnels may be signaled in advance, prior to
automatically or via configuration, or may be dynamically setup upon the establishment of any protected P2MP LSP, either automatically or
protected P2MP LSP signalling. Such procedures rely on local via configuration, or may be dynamically setup upon signaling of a
implementation issues and are beyond the scope of this document. protected P2MP LSP. Such procedures rely on local implementation
issues and are beyond the scope of this document.
4.1.2. P2MP Backup LSP Signalling 4.1.2. P2MP Backup LSP Signaling over a P2MP Bypass Tunnel
The same backup label (i.e. the inner label) MUST be used for all The same backup label (i.e., the inner label) MUST be used for all
backup S2L sub-LSPs which are tunneled within the same P2MP Bypass backup S2L sub-LSPs which are tunneled within the same P2MP Bypass
tunnel, so as to avoid traffic replication on the PLR. This label Tunnel, so as to avoid traffic replication at the PLR, and to avoid
MUST be assigned by the PLR using upstream label assignment traffic misrouting in the MPs. This label MUST be assigned by the PLR
procedures. using upstream label assignment procedures as specified in [MPLS-
UPSTREAM] and [RSVP-UP].
Backup P2MP LSPs MUST be signaled prior to the failure. To signal the Backup P2MP LSPs MUST be signaled prior to the failure. To signal the
backup P2MP LSP, the PLR will send one or more Path messages, backup P2MP LSP, the PLR will send one or more Path messages,
referred to as a backup LSP's Path message, to each MP, as specified referred to as a backup LSP's Path message, to each MP, as specified
in [RSVP-P2MP]. A backup LSP's Path message to a given MP comprises in [RFC4875]. A backup LSP's Path message to a given MP comprises one
one or more backup S2L sub-LSPs that transit through this MP. or more backup S2L sub-LSPs that transit through this MP.
A backup Path message MUST be sent to the MP using directed A backup Path message MUST be sent to the MP using directed
signaling; i.e., it is addressed to the MP, without Router Alert signaling, i.e., it is addressed to the MP, without Router Alert
option. option.
As specified in [RSVP-P2MP] it is RECOMMENDED that the PLR use the As specified in [RFC4875] it is RECOMMENDED that the PLR use the
sender template specific method to identify a backup LSP's Path sender template specific method to identify a backup LSP's Path
message, that is, the PLR will set the source address in the sender message, that is, the PLR will set the source address in the sender
template to a local PLR address. template to a local PLR address.
The backup label MUST be assigned by the PLR, in the context of the The backup label MUST be assigned by the PLR, in the context of the
underlying P2MP Bypass tunnel, following upstream label assignment underlying P2MP Bypass Tunnel, following upstream label assignment
and P2MP RSVP-TE context identification procedures defined in [RSVP- [MPLS-UPSTREAM] and P2MP RSVP-TE context identification procedures
UP]. Hence, a backup LSP's Path message sent to a given MP MUST defined in [RSVP-UP]. Hence, a backup LSP's Path message sent to a
include an Upstream Assigned Label object carrying the value of the given MP MUST include an Upstream Assigned Label object carrying the
backup label. It MUST also include an RSVP-TE P2MP LSP TLV within an value of the backup label. It MUST also include an RSVP-TE P2MP LSP
IF_ID RSVP object, that carries the session object of the underlying TLV within an IF_ID_RSVP_HOP object, that carries the session object
P2MP Bypass tunnel. This allows the MP to identify the label space of of the underlying P2MP Bypass Tunnel. This allows the MP to identify
the backup label assigned by the PLR. The same backup label MUST be the label space of the backup label assigned by the PLR. The same
sent to all MPs belonging to a given P2MP Bypass tunnel. backup label MUST be sent to all MPs belonging to a given P2MP Bypass
Tunnel.
Note that the PLR MUST continue to refresh Path messages for the Note that the PLR MUST continue to refresh Path messages for the
protected P2MP TE LSP along the nominal route. protected P2MP TE LSP along the nominal route.
The processing of backup S2L sub-LSP SEROs/SRROs MUST follow The processing of backup S2L sub-LSP SEROs/SRROs MUST follow
backup LSP ERO/RRO processing described in [RFC4090]. backup LSP ERO/RRO processing described in [RFC4090].
4.2. During failure 4.2. During failure
When the PLR detects a link or/and node failure condition, it has to When the PLR detects a link or/and node failure condition, it has to
reroute a protected P2MP LSP onto a set of one or more P2MP bypass reroute a protected P2MP LSP onto a set of one or more P2MP Bypass
tunnels using as inner label(s) the backup label(s) assigned for this Tunnels protecting the failed element, using as inner label(s) the
P2MP LSP. backup label(s) assigned for this P2MP LSP.
The PLR needs to localize the failed elements in order to activate
the P2MP Bypass Tunnel(s) protecting this element. Mechanisms through
which this location is retrieved are out of the scope of this
document.
Note that when some MPs are LSRs downstream to the PLR but not Note that when some MPs are LSRs downstream to the PLR but not
downstream to the failed element, the PLR MUST stop sending traffic downstream to the failed element, the PLR MUST stop sending traffic
directly within the protected P2MP TE LSP towards these MPs. This directly within the protected P2MP TE LSP towards these MPs. This
allows avoiding sending twice the traffic on downstream links during allows avoiding sending twice the traffic on downstream links during
failure. failure.
The PLR MUST continue to send Path messages for the backup P2MP LSP. The processing of backup S2L sub-LSP SEROs/SRROs MUST follow
The RRO/ERO flags MUST be updated as per defined in [RFC4090] backup tunnel ERO/RRO processing described in [RFC4090].
4.3. After failure
Reversion procedures for restoring the P2MP TE LSP to a full working
path after failure MUST follow procedures defined in section 6.5.2 of
[RFC4090], that is there are two basic strategies for restoring the
P2MP TE-LSP: The global revertive mode and the local revertive mode.
5. MP Procedures 5. MP Procedures
A MP receives one or more Path messages for the protected P2MP TE LSP A MP receives one or more Path messages for the protected P2MP TE LSP
and one or more Path messages for the backup P2MP LSP. and one or more Path messages for the backup P2MP LSP.
Note that, as specified in [RFC4090], the reception of a backup LSP's Note that, as specified in [RFC4090], the reception of a backup LSP's
Path message does not indicate that a failure has occurred or that Path message does not indicate that a failure has occurred or that
the incoming protected LSP will no longer be used. the incoming protected LSP will no longer be used.
A S2L sub-LSP is received within a Path message for the protected A S2L sub-LSP is received within a Path message for the protected
P2MP LSP and within a Path message for the backup P2MP LSP. These two P2MP LSP and within a Path message for the backup P2MP LSP. These two
Path messages are distinguished thanks to the sender-template Path messages are distinguished thanks to the sender-template
specific method. As specified in [RFC4090], each of these Path specific method. As specified in [RFC4090], each of these Path
messages will have a different sender address. The protected LSP can messages will have a different sender address. The protected LSP can
be recognized because it will include the FAST_REROUTE object or have be recognized because it will include the FAST_REROUTE object or have
the "local protection desired" flag set in the SESSION_ATTRIBUTE the "local protection desired" flag set in the SESSION_ATTRIBUTE
object, or both. object, or both.
A MP MUST maintain one context specific ILM table per PLR or per P2MP A MP MUST maintain one context specific ILM table per PLR or per P2MP
bypass tunnel for which it is a leaf. Bypass Tunnel for which it is a leaf LSR.
A MP MUST install the upstream assigned label received in a backup A MP MUST install the upstream assigned label received in a backup
LSP's Path message, within an ILM specific to the underlying bypass LSP's Path message (i.e., the backup label), within an ILM either
tunnel, which is identified by its session object, carried within the specific to the underlying P2MP Bypass Tunnel or specific to the PLR,
IF_ID RSVP_HOP object of the backup LSP's Path message. An upstream which is the ingress node of the underlying P2MP Bypass Tunnel. The
assigned label for a backup P2MP LSP MUST be mapped to the outgoing underlying P2MP bypass tunnel is identified by its session object,
interface(s) and label(s) of the corresponding protected P2MP LSP. carried within the IF_ID_RSVP_HOP object of the backup LSP’s Path
message. An upstream assigned label for a backup P2MP LSP MUST be
mapped to the outgoing interface(s) and label(s) of the corresponding
protected P2MP LSP.
As specified in [RSVP-UP], the Resv message sent by a MP to the PLR, As specified in [RSVP-UP], the Resv message sent by a MP to the PLR,
does not carry any Label Object. does not carry any Label Object.
The processing of backup S2L sub-LSP SEROs/SRROs MUST follow The processing of backup S2L sub-LSP SEROs/SRROs MUST follow
backup tunnel ERO/RRO processing described in [RFC4090]. backup tunnel ERO/RRO processing described in [RFC4090].
6. To be included in future revisions 6. Combination of P2P and P2MP Bypass tunnels
The following items will be included in further revisions of this The P2MP Facility Backup method defined in this document and the P2P
document: Facility Backup method defined in [RFC4090] may be used in
conjunction. That is, a P2MP LSP may be protected on a PLR using a
combination of a set of P2P and P2MP Bypass Tunnels.
- Combination of P2P and P2MP bypass tunnels to protect a given In this case S2L sub-LSPs protected by a P2P Bypass Tunnel are
link/node. This will allow backward compatibility with LSRs signalled using procedures defined in [RFC4875] with the backup label
that do not support upstream label assignment. downstream assigned by the MP, while S2L sub-LSPs protected by a
P2MP Bypass Tunnel are signaled using procedures defined in this
document, with the backup label upstream assigned by the PLR.
- Cases where the PLR is not directly upstream to the protected This allows for backward compatibility with LSRs that do not support
element. upstream assigned labels. A P2P Bypass Tunnel MUST be used to tunnel
traffic to a MP that do not support upstream assigned labels.
- Partial protection: that is the case where only a subset of 7. Partial Protection
Merge Points can be covered.
- New RSPV-TE Attribute flags: In some cases, in particular in some networks where bandwidth is a
scarce resource, the PLR may not be able to find a set of P2P and/or
P2MP Bypass Tunnels that cover all merge points. That is, only a
subset of merge points are covered, and upon failure, traffic will
not be delivered to all leaf LSRs downstream to the failed element.
Such a situation is referred to as partial protection as opposed to
full protection where all merge points are covered.
o A flag in the ATTRIBUTE FLAGS TLV to indicate that Hence, on a given PLR, a P2MP LSP may be fully, partially or non
protection with P2MP bypass tunnels is desired, and to protected. The default behavior on a PLR is that when a P2MP LSP
record such protection. cannot be fully protected it is not protected at all. But the ingress
o A flag in the ATTRIBUTE FLAGS TLV to indicate whether LSR may request 'P2MP Partial Protection' such that if a P2MP LSP
partial protection is allowed or not and to record cannot be fully protected it is partially protected.
partial protection.
o A flag in the ATTRIBUTE FLAGS TLV to indicate that PHP
must be deactivated, and to record PHP status (this has
a broader scope so this may belong to a dedicated
draft).
7. Security Considerations In order to request and record "P2MP Partial Protection" behavior,
this document defines a new bit in the Attributes Flags TLV of the
LSP_ATTRIBUTES object and the RRO Attributes sub-object defined in
[RFC4420]:
Bit Number 8 (TBD): P2MP Partial Protection
This bit SHOULD be set by the Ingress node in the Attributes Flags
TLV of the LSP_ATTRIBUTES object in the Path message for the LSP
for which P2MP Partial Protection is desired when full protection
cannot be provided. This bit MUST NOT be modified by any other nodes
along the LSP.
If a PLR supports the P2MP Partial Protection bit, and the bit is set
in a Path message, then it SHOULD setup a partial protection when a
full protection cannot be provided. In all other cases, the default
procedure applies, that is, the PLR MUST not setup any protection if
a full protection cannot be provided.
A PLR that recognizes the partial protection flag, but does not
support it, MUST ignore the request and apply default procedure.
When this bit is set in an RRO Attributes Subobject, this means that
the P2MP LSP is only partially protected on the node. In this case
the local protection available bit in the RRO flags MUST also be set.
A PLR that supports this flag MUST set it in the RRO Attributes
subobject, if it has setup a partial protection for a P2MP LSP.
The way in which a PLR chooses which set of MPs to target, when it
has to setup a partial protection, is out of the scope of this
document.
8. Location of the PLR
The PLR may be directly upstream to the protected link or node or may
also be two or more hops upstream.
In case the PLR is not directly upstream to the failure, rerouting
within the Bypass Tunnel(s) may be triggered by the following events:
-Failure of a BFD session between the PLR and the protected
Element.
-A PathErr message, that indicates the location of the failed
Element.
9. Security Considerations
No new security issues are raised in this document. No new security issues are raised in this document.
8. Acknowledgments 10. IANA Considerations
We would like to thank Kireeti Kompella and Venu Hemige, for the 10.1. LSP Attributes Flags
useful comments and discussions.
9. References IANA has been asked to manage the space of flags in the Attributes
Flags TLV carried in the LSP_ATTRIBUTES object [RFC4420].
9.1. Normative references This document defines a new flag as follows:
Bit Number: 8 (suggested value)
Meaning: P2MP Partial Protection Desired
Used in Attributes Flags on Path: Yes
Used in Attributes Flags on Resv: No
Used in Attributes Flags on RRO: Yes
Referenced Section of this Doc: 7
11. Acknowledgments
We would like to thank Kireeti Kompella, Venu Hemige, Laurent
Ciavaglia, Yannick Bréhon, and Mohamad Chaitou, for the useful
comments and discussions.
12. References
12.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS Architecture", [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS Architecture",
RFC 3031. RFC 3031.
[RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP [RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209. Tunnels", RFC3209.
[RFC4461] S. Yasukawa et al., "Signaling Requirements for Point-to- [RFC4461] S. Yasukawa et al., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)",
RFC4461. RFC4461.
[RFC4090] Pan, Swallow, Atlas, et al., "Fast Reroute Extensions to [RFC4090] Pan, Swallow, Atlas, et al., "Fast Reroute Extensions to
RSVP-TE for LSP Tunnels", RFC4090. RSVP-TE for LSP Tunnels", RFC4090.
[RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa et al. "Extensions to [RFC4875] Aggarwal, Papadimitriou, Yasukawa et al. "Extensions to
RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-mpls-rsvp-te- RSVP-TE for Point to Multipoint TE LSPs", RFC4875, May 2007.
p2mp, work in progress.
[MPLS-UPSTREAM] Aggarwal, Rekhter, Rosen, "MPLS Upstream Label [MPLS-UPSTREAM] Aggarwal, Rekhter, Rosen, "MPLS Upstream Label
Assignment and Context Specific Label Space", draft-ietf-mpls- Assignment and Context Specific Label Space", draft-ietf-mpls-
upstream-label, work in progress. upstream-label, work in progress.
[RSVP-UP] Aggarwal, Le Roux, " MPLS Upstream Label Assignment for [RSVP-UP] Aggarwal, Le Roux, " MPLS Upstream Label Assignment for
RSVP-TE", draft-ietf-mpls-rsvp-upstream, work in progress. RSVP-TE", draft-ietf-mpls-rsvp-upstream, work in progress.
10. Authors' Addresses: [RFC4420] Farrel, A., Ed., et al."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.
12.2. Informational references
[NO-PHP] Ali, Swallow, Aggarwal, "Non PHP Behavior and out-of-band
mapping for RSVP-TE LSPs", draft-ali-mpls-rsvp-te-no-php-oob-mapping,
work in progress
13. Authors' Addresses:
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
FRANCE FRANCE
Email: jeanlouis.leroux@orange-ftgroup.com Email: jeanlouis.leroux@orange-ftgroup.com
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
skipping to change at page 11, line 4 skipping to change at page 13, line 17
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
M. Vigoureux M. Vigoureux
Alcatel-Lucent France Alcatel-Lucent France
Route de Villejust Route de Villejust
91620 Nozay 91620 Nozay
FRANCE FRANCE
Email: martin.vigoureux@alcatel-lucent.fr Email: martin.vigoureux@alcatel-lucent.fr
11. Intellectual Property Statement
14. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 67 change blocks. 
184 lines changed or deleted 312 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/