draft-zhao-mpls-mldp-protections-04.txt   draft-zhao-mpls-mldp-protections-05.txt 
Network Working Group Quintin Zhao Network Working Group Quintin Zhao
Internet-Draft Tao Chou Internet-Draft Tao Chou
Intended status: Standards Track Huawei Technology Intended status: Standards Track Huawei Technology
Expires: January 1, 2014 Boris Zhang Expires: January 16, 2014 Boris Zhang
Telus Communications Telus Communications
Emily Chen Emily Chen
June 30, 2013 July 15, 2013
P2MP Based mLDP Node Protection Mechanisms for mLDP LSP P2MP Based mLDP Node Protection Mechanisms for mLDP LSP
draft-zhao-mpls-mldp-protections-04.txt draft-zhao-mpls-mldp-protections-05.txt
Abstract Abstract
This document outlines the procedures and protocol extensions for the This document specifies the procedures and protocol extensions for
protection of mLDP nodes within Multi-Protocol Label Switching (MPLS) the protection of mLDP nodes within Multi-Protocol Label Switching
networks using P2MP-based backup LSPs. (MPLS) networks using P2MP backup LSPs.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 1, 2014 . This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirement Language . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirement Language . . . . . . . . . . . . . . . . . . . 5
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. mLDP Node Protection Example . . . . . . . . . . . . . . . . . 5 5. Example of mLDP Node Protection . . . . . . . . . . . . . . . 6
5. Signaling Procedures for P2MP Based Node Protection . . . . . 7 6. Signaling Procedures for P2MP Based Node Protection . . . . . 7
5.1. The Computation of the Backup Path . . . . . . . . . . . . 7 6.1. The Computation of the Backup Path . . . . . . . . . . . . 8
5.2. The Procedures for Merge Point, Protected Node, Pn 6.2. The Procedures for MP, PTN, STN and PLR . . . . . . . . . 8
Node and PLR Node . . . . . . . . . . . . . . . . . . . . 8 6.2.1. MP's Procedures . . . . . . . . . . . . . . . . . . . 8
5.2.1. Merge Point's Procedures . . . . . . . . . . . . . . . 8 6.2.2. PTN's Procedures . . . . . . . . . . . . . . . . . . . 9
5.2.2. Protected Node's Procedures . . . . . . . . . . . . . 8 6.2.3. STN's Procedures . . . . . . . . . . . . . . . . . . . 9
5.2.3. Pn Node's Procedures . . . . . . . . . . . . . . . . . 8 6.2.4. PLR's Procedures . . . . . . . . . . . . . . . . . . . 10
5.2.4. PLR Node's Procdures . . . . . . . . . . . . . . . . . 9 6.3. PLR's Switching Over Considerations . . . . . . . . . . . 10
5.3. PLR Switching Over Considerations . . . . . . . . . . . . 9 6.4. The Procedures after the Reconvergence . . . . . . . . . . 11
5.4. The Procedures after the Reconvergence . . . . . . . . . . 10 6.5. Considerations for MP2MP LSP Node Protection . . . . . . . 11
5.5. Considerations for MP2MP LSP Node Protection . . . . . . . 10 6.5.1. MP's Procedure . . . . . . . . . . . . . . . . . . . . 12
5.5.1. MP Node Procedure . . . . . . . . . . . . . . . . . . 11 6.5.2. PLR's Procedure . . . . . . . . . . . . . . . . . . . 13
5.5.2. PLR Node Procedure . . . . . . . . . . . . . . . . . . 12 6.5.3. Switch over Procedure . . . . . . . . . . . . . . . . 13
5.5.3. Switchover Procedure . . . . . . . . . . . . . . . . . 12 7. Protocol Extensions for mLDP Based Node Protection . . . . . . 13
5.6. Protocol Extensions for mLDP Based Node Protection . . . . 12 7.1. mLDP Based MP Protection Capability Parameter TLV . . . . 13
5.6.1. mLDP Based MP Protection Capability Parameter TLV . . 12 7.2. mLDP Based MP Node Protection Status Elements . . . . . . 14
5.6.2. mLDP Based MP Node Protection Status Elements . . . . 13 7.3. mLDP Backup FEC Element Encoding . . . . . . . . . . . . . 14
5.6.3. mLDP Backup FEC Element Encoding . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5.7. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Terminology 1. Introduction
This document uses terminology discussed in [RFC6388] and [I-D.ietf- To meet user demand, operators and service providers continue to
mpls-ldp-multi-topology]. Additional key terms and terminology are deploy multicast applications using the Multicast Label Distribution
listed here: Protocol (Multicast LDP - mLDP) across MPLS networks. For real-time
applications, such as stock trading, on-line games, and multimedia
teleconference, traditional node protection mechanisms, such as
relying on IGP re-convergence to build the new Label Switched Path
(LSP), fail to achieve a protection switching time less than that
which is required to minimize the interruption of applications.
o PLR: The node upon which traffic is logically redirected onto the Instead of relying on IGP re-convergence to build the new LSP for
preset backup path is called Point of Local Repair (PLR). failure protection, pre-computing and establishing a backup path
before the failure delivers a better solution, allowing a more rapid
switch over to the backup path when the protected node fails .
o MP: The node upon which the backup path and the primary path merge Providing a pre-computed backup path requires solutions to two
is called the Merge Point (MP). complex problems:
o N: The node which is protected by the backup path. o how to compute a completely disjoint backup path for each node in
a multicast tree, and
o Pn: The nodes on the backup path that protect node N. o how to signal and setup the computed backup path.
o MT-ID: A 16 bit value used to represent the Multi-Topology ID. For a primary Point-to-Multipoint (P2MP) Label Switched Path (LSP)
created by LDP, there are several methods that could be chosen for
creating a backup path:
o Default MT Topology: A topology that is built using the MT-ID o The use of an RSVP-TE (Resource Reservation Protocol - RSVP -
default value of 0. Traffic Engineering) point-to-point (P2P) tunnel as a logical out-
going interface, which consequently utilizes the mature high-
availability technology of RSVP-TE.
o MT Topology: A topology that is built using the corresponding o The use of an alternative LDP P2P LSP as a packet encapsulation,
MT-ID. which avoids the complex configuration of P2P RSVP-TE.
o MRT: Maximally Redundant Trees. A pair of trees where the path o Creating a P2MP backup LSP using a loop-free alternative route
from any node X to the root R along the first tree and the path provided by the IGP.
from the same node X to the root along the second tree share the
minimum number of nodes and the minimum number of links.
2. Requirement Language o Using multi-topology technology, wherein the backup topology can
be either statically configured or dynamically computed and
signaled using IP/LDP Fast-Reroute mechanisms
[I-D.ietf-rtgwg-mrt-frr-architecture].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", When the backup path is available, there are two methods for packet
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this forwarding and protection switch over:
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Introduction Method 1 The traffic sender transmits the stream on both the primary
and backup path always. Once the local traffic receiver
detects a failure, the switch over will be relatively fast.
However, the disadvantage of this method is that it
consumes bandwidth because duplicate traffic will be sent
on the primary and backup paths.
To meet user demands, operators and service providers continue to Method 2 The traffic sender transmits only on the primary path
deploy multicast applications using Multicast LDP (mLDP) across MPLS before the failure. Traffic is only forwarded to the MP
networks. For real-time applications, such as stock trading, on-line through the backup path when failure is detected. Although
games, and multimedia teleconferencing, traditional node protection bandwidth resource usage is minimized, cooperation is
mechanisms (such as IGP-mLDP convergence based mechanisms) fail to required to provide adequate switching times and to
adhere to the protection switching time which is required to minimize minimize higher-layer and application impact.
the interruption of applications.
Instead of replying the IGP-mLDP convergenvce for failure protection, Ideally, if the switching time performance can be equal to or better
pre-computing, establishing a backup path before the failure and than that of Method 1, it is reasonable to choose Method 2 to avoid
switching over to the backup path when the protected node fails is a bandwidth wastage. This consideration has been taken into account in
better solution. making the recommendations in this document.
But two major challenges exist with this aforementioned solution. Note that for the computation and configuration of the primary
The first is how to compute an absolutely disjointed backup path for topology, the algorithm used could be the Loop-free Alternate (LFA)
each node in a multicast tree; the second is how to signal and setup based [RFC5286], Maximally Redundant Tree (MRT) based
the backup path. [I-D.ietf-rtgwg-mrt-frr-architecture] , or based on any other
algorithms or methods available including static and offline tools;
any such method can be used in conjunction with the mechanisms
described in this document , which is limited to determining the
nodes that should be spanned by the backup paths for the protection
of a node in the primary multicast tree. In addition, the mechanism
for detecting the node failure that will result in switchover to the
backup pathis also outside the scope of this document.
For a primary LDP P2MP LSP, there are several methods to choose for a Compared to a P2P LSP based solution, this P2MP LSP based solution
backup path: not only uses mLDP mechanisms for both the primary path and backup
paths, but also avoids unnecessary packet duplication where multiple
P2P backup paths for the same node pass through.common nodes.
o The use of an RSVP-TE P2P tunnel as a logical out-going interface, The remainder of this document specifies the signaling procedures and
which consequently utilizes the mature high availability protocol extensions for the P2MP LSP based mLDP node protection
technologies of RSVP-TE. solution which was briefly introduced above.
o The use of an LDP P2P LSP as a packet encapsulation, wherein 2. Terminology
complex configuration of P2P RSVP-TE can be skipped.
o Creating a P2MP backup LSP according to IGP's loop-free This document uses terminology discussed in [RFC6388] and
alternative route. [I-D.ietf-mpls-ldp-multi-topology]. Additional key terms and
terminology are listed here:
o Using multi topology technology, wherein the backup topology can o Point of Local Repair (PLR): The node upon which traffic is
be either statically configured or dynamically computed/ signaled redirected onto the preset backup path.
using mechanisms specified in the draft of [I-D.ietf-rtgwg-mrt-
frr-architecture].
When the backup path is present, there are two options for packet o Merge Point(MP):The node(s) where the primary path and the backup
forwarding and protection switchover: path rejoin and merge. Since the backup path is a multicast tree
there will generally be more than one merge point.
o Option 1 The traffic sender transmits the stream on both the o Primary Transit Node (PTN): The node between the PLR and MP on the
primary and backup path. Once the local traffic receiver detects primary path.
a failure, the switchover will be relatively fast. However, the
disadvantage of this method is that it consumes bandwidth because
duplicate traffic will be sent on the primary and backup paths.
o Option 2 The traffic sender transmits only on the primary path. o Secondary Transit Node (STN): A node on the backup path between
Although bandwidth resource usage is minimized, cooperation is the PLR and MP. There might be more than one STN on the backup
required to provide adequate switching times and to minimize high- path between the PLR and MP nodes.
layer application impact.
Ideally, if the switching time performance can be equal or better 2.1. Requirement Language
than that of Option 1, it is reasonable to choose option 2 to avoid
bandwidth wastage. Some recommendations in this document are based
upon this consideration.
Note that the computation and configuration of the primary topology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
and backup topology are out of the scope of this draft. The "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
algorithm can be LFA based, MRT based, or based off of any other document are to be interpreted as described in RFC 2119 [RFC2119].
algorithms/method available including the static and offline tools.
In addition, detecting failure is also outside the scope of this
document.
Compared to a P2P LSP based solution (specified in the draft of 3. Requirements
I-D.wijnands-mpls-mldp-node-protection), this P2MP LSP based solution
not only uses mLDP mechanisms for both the primary path and backup
paths, but also avoids unnecessary packet duplication.
The remainder of this document specifies the signalling procedures A number of requirements have been identified that will allow the
and protocol extensions for the P2MP LSP based mLDP node protection optimal set of mechanisms to be developed. These are:
solution which was briefly introduced above.
3.1. Requirements o Computation of a possible disjoint (link and node) backup path
within the multicast tree. In the case that there is no backup
path available, there will be no backup path setup using the
solution described in this draft will not be applicable.
A number of requirements have been identified that allow the optimal o Minimize the PLR's switch over time from the primary path to the
set of mechanisms to develop. These currently include: backup path when failure happens;
o Computation of a disjointed (link and node) backup path within the o Minimization of operation and maintenance cost;
multicast tree
o Minimization of protection convergence time o The solution should work without other protocol extensions other
than the protocol extensions specified in this draft.
o Minimization of operation and maintenance cost o The solution should work for all network topologies deployed in
the users' network as long as there is a alternative backup path
available.
o Optimization of bandwidth usage 4. Scope
o More protect scenario coverage This document specifies the signaling procedures and protocol
extensions for the P2MP LSP based mLDP transit node protection
solution.
3.2. Scope The method used for detecting the node failure is out the scope of
this document.
The method to detect failure is outside the scope of this document. Protection of the leaf and root nodes of the multicast tree is also
out of scope of this document.
The protections of leaf and root nodes are also outside the scope of The protection mechanism for the case of multiple failures happening
this document. at the same time is out of scope of this document.
4. mLDP Node Protection Example In the case that there is no backup path computed from the backup
path computation algorithms, then there will be no backup path setup
to protect the transit node failures.
By using IGP-FRR or Multi Topology Routing (including the MRT MT 5. Example of mLDP Node Protection
routing), LDP can build the backup mLDP LSP among PLR, Pn, and MPs
(the downstream nodes of the protected node). In the case of a large By using the procedures introduced in section 5 plus the available
number of downstream nodes, this mechanism can avoid unnecessary backup path computation algorithms, MP can initiate the building of
packet duplication between PLR and the merge points. the backup mLDP LSP starting from the PLR, avoiding the PTN and
reaching the MPs. In the case of a large number of MPs, the solution
introduced in this draft can avoid unnecessary packet duplication
between PLR and the merge points. If a backup multicast tree is
built rather than individual LSPs from the PLR to each MP then common
transit points on the backup tree that would otherwise have multiple
unicast LSPs passing through them will be saved some bandwidth on
their incoming links.
|
V
+------------+ Point of Local Repair/ +------------+ Point of Local Repair/
| R1 | Switchover Point | R1 | Switch over Point
+------------+ (Upstream LSR) +------------+ (Upstream LSR)
/ \ / \
/ \ 10/ \20 (cost)
10/ \20 / \
/ \ V V
/ \ Primary +----------+ +-----------+ Secondary
/ \ Transit Node | R2 | | R3 |Transit Node
+----------+ +-----------+ (PTN) +----------+ +-----------+ (STN)
Protected Node | R2 | | R3 | | \ / |
+----------+ +-----------+ 10| 10\ /20 |20
| \ / | | \ / |
| \ / | | \ |
| \ / | | / \ |
10| 10\ /20 20| V V V V
| \ / | +-----------+ +-----------+ Merge Point
| \ | | R4 | | R5 | (Downstream LSR)
| / \ | +-----------+ +-----------+
| / \ | | |
| / \ | V V
| / \ |
+-----------+ +-----------+ Merge Point
| R4 | | R5 | (Downstream LSR)
+-----------+ +-----------+
Figure 1: mLDP Local Protection using mLDP LSP Example Figure 1: mLDP Local Protection using mLDP LSP Example
In Figure 1, R2 is on the preferential path from R4/5 to R1, and the In Figure 1, R2 is on the preferential signalling/data path from R4/5
secondary path is through R3. In this case, the mLDP LSP will be to R1, and the secondary signalling/data path from R4/R5 to R1 is
established according to the IGP preferential path as R1--R2--R4/R5. through R3. In this case , the mLDP LSP will be established
As an example, this figure takes R2 as the Protected Node though the according to the IGP preferential path as R1--R2--R4/R5. As an
Protected Node can be any Transit node of the mLDP LSP. (We assume example, this figure takes R2 as the PTN though the PTN can be any
that all the nodes in Figure 1 support this mLDP based node Transit Node of the mLDP LSP. (We assume that all the nodes in
protection method, including Pn.) Figure 1 support this mLDP based node protection method.)
The procedure of P2MP Based mLDP Node Protection is as follows:
o As the Protected Node, R2 should announce its selected upstream
node R1 to all its downstream nodes, which are R4 and R5 in this
example. The node to protect can then be decided by local
configuration or by its role(transit) in the mLDP LSP.
o R4 and R5 can consider R1 as the root node of the backup mLDP LSP
and can trigger the backup LSP signaling. In parallel, R4/R5 will
bind the primary NHLFE(s) to both the backup and primary ILM
entries, so that the traffic from the backup mLDP LSP can be
merged locally to the primary LSP.
o PLR can distinguish primary LSP and backup LSP by the signaling
procedure and can feed traffic on the primary path before failure.
When R2 node fails, R1 quickly switches the traffic to the preset
backup path.
In this scenario, if R2 is protected by two P2P LSPs as R1--R3--R4 In this scenario, if R2 is protected by two P2P LSPs as R1--R3--R4
and R1--R3--R5 (similar to the method in the draft of I-D.wijnands- and R1--R3--R5 , the traffic will be duplicated on the link between
mpls-mldp-node-protection), the traffic will be duplicated on R1, and R1 and R3 when the primary traffic is switched into the secondary
R3 will receive two streams. But, if R2 is protected by a mLDP LSP path, and R3 will receive two copies of the multicast packages. But,
instead, R3 will only receive one stream, and thus there will be no if R2 is protected by a mLDP LSP instead, R3 will only receive one
packet duplication on R3. copy of the stream, and thus there will be no packet duplication on
the link between R1 and R3 when the failure happens.
5. Signaling Procedures for P2MP Based Node Protection 6. Signaling Procedures for P2MP Based Node Protection
This section introduces the signaling procedures of P2MP LSP's node This section introduces the signaling procedures of P2MP LSP's node
protection using P2MP-based backup LSP. protection using P2MP-based backup LSP for a Protected Node N.
5.1. The Computation of the Backup Path 6.1. The Computation of the Backup Path
Obviously, the backup path can not go through the protected node N. Obviously, the backup path can not go through the protected node N.
This section discusses how to choose the backup upstream LSR to avoid This section discusses how to choose the backup upstream LSR to avoid
N. N.
Firstly, find the candidate upstream LSRs as below: Firstly, find the candidate upstream LSRs as below:
o MPs should preferentially choose the upstream LSRs on the shortest o MPs should preferentially choose the upstream LSRs on the shortest
path as candidates, except node N. If no other upstream LSRs are path as candidates, except node N. If no other upstream LSRs are
on the shortest path, MPs should choose the next-hop on N's detour on the shortest path, MPs should choose the next-hop on N's detour
path as a candidate. The detour path can be an IGP-FRR path or path as a candidate. The detour path can be an IGP-FRR path or
other topology-based disjoint paths. The IGP-FRR path can be other topology-based disjoint paths. The IGP-FRR path can be
provided by LFA, U-Turn, etc. The disjoint path can be provided provided by LFA, U-Turn [[anchor9: EBD: Needs references.]], etc.
by MT, MRT (see details in the next section), etc. Choosing the The disjoint path can be provided by MT, MRT, etc. Choosing the
candidates is a local decision and can be determined by candidates is a local decision and can be determined by
configuration. configuration.
o The Pn node MUST be chosen from the IGP next-hops on the shortest o The STN node MUST be chosen from the IGP next-hops on the shortest
path toward PLR within the topology specified in the FRR mLDP FEC path toward the PLR within the topology specified in the FRR mLDP
element by MT-ID field. The candidate upstream LSRs MUST not be FEC element by the MT-ID (Multi-Topology Identifier) [[anchor10:
the node N. EBD: Multi-Topology IDs need some explanation - it appears here
without any introduction and I (for one) have no idea why there
might be several and what they might cover.]] field. The
candidate upstream LSRs MUST NOT include the PTN.
Thus, each node can choose one upstream node from the candidate Thus, each node can choose one upstream node from the candidate
upstream LSRs as its backup upstream LSR via the algorithm described upstream LSRs as its backup upstream LSR via the algorithm described
in [RFC6388] section 2.4.1.1. in Section 2.4.1.1 of [RFC6388].
5.2. The Procedures for Merge Point, Protected Node, Pn Node and PLR 6.2. The Procedures for MP, PTN, STN and PLR
Node
[Editors Note - The procedures for P2MP Based Node Protection The procedures for P2MP Based Node Protection described in this
described in this document assumes the PLR is capable of node failure document assumes the PLR is capable of node failure detection. In
detection.] procedures described here covers the scenario where there is only one
PTN between the PLR and MP. The cases where there are more than one
PTNs between PLR and MP is out scope of this document.
We assume all the involved nodes have advertised their corresponding We assume all the involved nodes have advertised their corresponding
protection capabilities. And the following section specifies the protection capabilities. And the following section specifies the
signaling procedures of P2MP Based Node Protection. signaling procedures of P2MP Based Node Protection.
5.2.1. Merge Point's Procedures 6.2.1. MP's Procedures
Each non-Ingress LSR determines its own upstream LSR and sends out a Each non-Ingress LSR determines its own upstream LSR and sends out a
label mapping message, in accordance with the procedures documented label mapping message, in accordance with the procedures documented
in [RFC6388] without any additional extension. And its upstream LSR in [RFC6388] without any additional extension. And its upstream LSR
will propagate a new label mapping message to its upstream LSR. In will propagate a new label mapping message to its upstream LSR. In
such cases, the non-Ingress LSR is the MP node (as R4, R5 in Figure such cases, the non-Ingress LSR is the MP node (as R4, R5 in
1), MP's upstream LSR is the protected node (as R2 in Figure 1), and Figure 1), MP's upstream LSR is the protected node (as R2 in Figure
the protected node's upstream node is PLR (as R1 in Figure 1). 1), and the protected node's upstream node is PLR (as R1 in
Figure 1).
When one MP (as R4/R5 nodes in figure 1) receives the Notification, When one MP (as R4/R5 nodes in Figure 1) receives the Notification
it individually determines its secondary path toward the PLR from the PTN after the MP has sent the label mapping message to the
according to the IGP routes. The algorithms for choosing/computing PTN, based on the PLR and PTN info, the MP individually determines
the backup path can be LFA, MRT or others. After the backup upstream its secondary path toward the PLR according to the IGP routes. The
LSR is chosen, MP will send out a FRR Label mapping message, which algorithms for choosing/computing the backup path can be LFA, MRT or
includes the mLDP backup tree's key <PLR, protected-node, original- others. After the backup upstream LSR is chosen, MP will send out a
mLDP-FEC> and the MT-ID if the backup path is not in the default Label mapping message with the new FRR FEC (see section 7.3 for
topology. Note that the label assigned for the primary path and the details), which includes the mLDP backup tree's key <PLR, protected-
secondary path MUST be different to avoid having the MP feed primary node, original-mLDP-FEC> and the MT-ID if the backup path is not in
traffic to its secondary path's downstream LSRs. In addition, the the default topology. Note that the label assigned for the primary
original-mLDP-FEC of the backup tree key is encoded in a special path and the secondary path MUST be different to avoid having the MP
opaque value as introduced in section 4.2.3. feed primary traffic to its secondary path's downstream LSRs. In
addition, the original-mLDP-FEC of the backup tree key is encoded in
a special opaque value as introduced in section 7.3
5.2.2. Protected Node's Procedures 6.2.2. PTN's Procedures
After the Protected Node (as R2 in Figure 1 ) determines its upstream After the Protected Node (as R2 in Figure 1 ) determines its upstream
LSR (as R1 in figure 1), it will send the information (PLR's LSR (as R1 in Figure 1), it will send the information (PLR's
indentify, mLDP FEC) via Notification messages to all its downstream identify, mLDP FEC) via Notification messages to all its downstream
nodes(MPs) immediately. If other LSRs become its downstream nodes nodes(MPs) immediately. If other LSRs become its downstream nodes
later, it will send such announcements to its new MP(s). later, it will send such announcements to its new MP(s).
5.2.3. Pn Node's Procedures 6.2.3. STN's Procedures
When one node receives such aforementioned FRR label mapping When one node receives such aforementioned label mapping messages
messages, if it is not the PLR, it can consider itself a Pn node and which inlcudes the mLDP FRR type of FECs, if it is not the PLR, it
will choose its backup upstream node toward PLR on the corresponding can consider itself a STN and will choose its backup upstream node
topology's shortest IGP path. To avoid the backup LSP going through toward PLR on the corresponding topology's shortest IGP path. To
the Protected Node, additional path selection rule(s) should be avoid the backup LSP going through the PTN, additional path selection
applied. A simple method is for the transit nodes to not choose the rule(s) should be applied. A simple method is for the transit nodes
specified Protected Node as its upstream LSR for the backup LSP. to not choose the specified PTN as its upstream LSR for the backup
Other methods, such as the not-via policy, are under study and will LSP. Other methods, such as the not-via policy, are under study and
be added in the future. To make the primary and backup topologies will be added in the future. To make the primary and backup
rooted from PLR satisfy the 'maximum disjointed' requirement, they topologies rooted from PLR satisfy the 'maximum disjointed'
can either be configured through static configurations or be signaled requirement, they can either be configured through static
dynamically through other mechanisms such as MRT. configurations or be signaled dynamically through other mechanisms
such as MRT.
5.2.4. PLR Node's Procdures When a STN on the backup mLSP fails before the backup LSP is put into
use, this will trigger a recalculation of the backup LSP(s).
6.2.4. PLR's Procedures
When PLR(R1) receives the FRR label mapping message, it can identify When PLR(R1) receives the FRR label mapping message, it can identify
that it is the PLR by the mLDP backup FEC elements. Thus, it will that it is the PLR by the mLDP backup FEC elements. Thus, it will
decode the special opaque value (which contains the primary mLDP FEC decode the special opaque value (which contains the primary mLDP FEC
element, introduced in section 4.2.3) and generate the backup element, introduced in section 7.3) and generate the backup
forwarding entry for the specific LSP, which is identified by the forwarding entry for the specific LSP, which is identified by the
root address and opaque value in the special opaque value. It will root address and opaque value in the special opaque value. It will
also bind the backup forwarding state to the specific primary entry, also bind the backup forwarding state to the specific primary entry,
which is indicated by the Protected Node address in the message. which is indicated by the Protected Node address in the message.
Note that there might be more than one backup forwarding entry for a Note that there might be more than one backup forwarding entry for a
specific protected node. specific protected node.
When failure is detected by PLR, it will switch the traffic to the When failure is detected by PLR, it will switch the traffic to the
backup paths. MP will also locally choose which traffic to recieve backup paths. MP will also locally choose which traffic to receive
and merge this traffic back to the primary LSP. The switchover and merge this traffic back to the primary LSP. The switch over
manner on PLR is specified in detail in the later section of this manner on PLR is specified in detail in the later section of this
document. document.
5.3. PLR Switching Over Considerations 6.3. PLR's Switching Over Considerations
This section provides two methods for Switchover when failure occurs: This section provides two modes for Switch over when failure occurs
using the Protection Method 2 described in section 1 where there is
only one copy of the traffic sent out from the PLR both before the
PTN fails and after the PTN fails.
o Option 1: If PLR cannot differentiate link and node failure, MP Depending on the capability of the MP node, MP node can set Node
must take the responsibility to drop one of the two duplicate Failure (detection required) Flag in two modes.
traffics when failure is detected. In this case, the Node Failure
Required Flag (in the P2MP Based MP Node Protection Status
Element) must be set as 'N'. PLR will switch the traffic to the
backup path when failure is detected, and MP will drop traffic on
the backup path until it sees N fail.
o Option 2: If PLR can differentiate link and node failure, PLR MUST Mode 1: The MP sets the Node Failure Required Flag (in the P2MP
NOT switch the traffic to the backup path until it detects the Based MP Node Protection Status Element) as 'Y'. This
node N's failure. In this case, the Node Failure Required Flag, means that the MP requires the PLR to have the capability
in the P2MP Based MP Node Protection Status Element, must be set of detecting the PTN's failure. In this case, if the PLR
as 'Y'. doesn't have the node failure detection capability, then
the backup path will not be setup and no protection is
setup for the PTN. If the PLR has the capability of
detecting the PTN's failure, the backup path can be setup
correctly and only after PLR detects that PTN's failure,
there will be backup traffic forwarded through the backup
path to the MP(s).
5.4. The Procedures after the Reconvergence Mode 2: The MP sets the Node Failure Required Flag, in the P2MP
Based MP Node Protection Status Element, set as 'N'. This
means that the MP has the capability of dropping duplicated
multicast packages and doesn't require the PLR to have the
capability of detecting the PTN's failure. In this case,
PLR switches the traffic to the backup path once it detects
the link failure between PLR and PTN no matter it is caused
by the PTN's failure or not. In the case that it is a link
failure case, and the link protection is also deployed,
then the MP will receive two copies of the traffic, one
copy from the normal link protection path, and one copy
from the node protection path through STN. MP must take
the responsibility to drop one of the two duplicate
traffics when link fails between PLR and PTN.
6.4. The Procedures after the Reconvergence
When Merge Point(s) see the next hop to Root changed, it/they will When Merge Point(s) see the next hop to Root changed, it/they will
advertise the new mapping message(s), and the traffic will re- advertise the new mapping message(s), and the traffic will re-
converge to the new primary path. MP will then withdraw the backup converge to the new primary path. MP will then withdraw the backup
label after the re-convergence. Pn will delete the specified backup label after the re-convergence. STN will delete the specified backup
LSP just as in the procedure of deleting normal P2MP LSP. And the LSP just as in the procedure of deleting normal P2MP LSP. And the
entire backup P2MP LSP will be deleted when the node MP leaves the entire backup P2MP LSP will be deleted when the node MP leaves the
backup P2MP LSP. backup P2MP LSP.
5.5. Considerations for MP2MP LSP Node Protection 6.5. Considerations for MP2MP LSP Node Protection
When a MP2MP LSP node needs to be protected, it can be treated with When a MP2MP LSP node needs to be protected, it can be treated with
the same p2mp LSP node protection procedures for each forwarding the same P2MP LSP node protection procedures for each forwarding
direction. direction.
+------------+ Point of Local Repair/ |
| R1 | Switchover Point V
+------------+ (Upstream LSR) +------------+ Point of Local Repair/
/ \ | R1 | Switch over Point
/ \ +------------+ (Upstream LSR for Downstream flow)
10/ \20 / \
/ \ 10/ \20 (cost)
/ \ / \
V V V V
+----------+ +-----------+ Primary +----------+ +-----------+ Secondary
Protected Node | R2 | | R3 | Transit Node | R2 | | R3 |Transit Node
+----------+ +-----------+ (PTN) +----------+ +-----------+ (STN)
| \ / | | \ / |
| \ / | 10| 10\ /20 |20
| \ / | | \ / |
10| 10\ /20 20| | \ |
| \ / | | / \ |
| \ | V V V V
| / \ | +-----------+ +-----------+ Merge Point
| / \ | | R4 | | R5 | (Downstream LSR
| / \ | +-----------+ +-----------+ for Downstream flow)
V V V V | |
+-----------+ +-----------+ Merge Point V V
| R4 | | R5 | (Downstream LSR)
+-----------+ +-----------+
Figure 2: MP2MP Example (R1 is the PLR) Figure 2: MP2MP Example (R1 is the PLR)
+------------+
| R1 | Merge Point ^
+------------+ (downstream LSR) |
^ ^ +------------+ Merge Point
/ \ | R1 | (the downstream LSR for the upstream flow)
10/ \20 +------------+
/ \ ^ ^
/ \ 10/ \20 (cost)
/ \ / \
+----------+ +-----------+ Primary +----------+ +-----------+ Secondary
Protected Node | R2 | | R3 | Transit Node | R2 | | R3 |Transit Node
+----------+ +-----------+ (PTN) +----------+ +-----------+ (STN)
^ ^ ^ ^ ^ ^ ^ ^
| \ / | | \ / |
| \ / | 10| 10\ /20 |20
10| 10\ /20 20| | \ / |
| \ / | | \ |
| \ | | / \ |
| / \ | +-----------+ +-----------+
| / \ | PLR for | R4 | | R5 |
| / \ | the upstream flow +-----------+ +-----------+
| / \ | ^ ^
Point of Local Repair/+-----------+ +-----------+ | |
(upstream LSR) | R4 | | R5 |
+-----------+ +-----------+
Figure 3: MP2MP Example (R4 is the PLR) Figure 3: MP2MP Example (R4 is the PLR)
For each direction flow, the MP, PLR and MP nodes use the P2MP node For each direction of MP2MP traffic flows (downstream in Figure 2 or
upstream in Figure 3, the MP, PLR and MP nodes use the P2MP node
protection procedures with the following additional considerations: protection procedures with the following additional considerations:
5.5.1. MP Node Procedure 6.5.1. MP's Procedure
MP sends a backup label mapping message containing MP2MP downstream MP sends a backup label mapping message containing MP2MP downstream
FRR FEC elements. When PLR receives a backup label mapping message FRR FEC elements. When PLR receives a backup label mapping message
with a MP2MP downstream flag, it sends the backup label mapping with a MP2MP downstream flag, it sends the backup label mapping
message with mp2mp upstream FRR FEC elements to Pn and then finally message with mp2mp upstream FRR FEC elements to Pn and then finally
to MPs. This procedure just follows the normal MP2MP LSP procedure. to MPs. This procedure just follows the normal MP2MP LSP procedure.
For the forwarding entries, MP node binds its primary MP2MP For the forwarding entries, MP node binds its primary MP2MP
downstream NHLFE entry to backup MP2MP downstream ILM entry and binds downstream NHLFE entry to backup MP2MP downstream ILM entry and binds
its backup MP2MP upstream NHLFE entry to primary MP2MP upstream ILM its backup MP2MP upstream NHLFE entry to primary MP2MP upstream ILM
entry. entry.
For the forwarding entries, MP node binds its primary MP2MP For the forwarding entries, MP node binds its primary MP2MP
downstream NHLFE entry to backup MP2MP downstream ILM entry and binds downstream NHLFE entry to backup MP2MP downstream ILM entry and binds
its backup MP2MP upstream NHLFE entry to primary MP2MP upstream ILM its backup MP2MP upstream NHLFE entry to primary MP2MP upstream ILM
entry. entry.
5.5.2. PLR Node Procedure 6.5.2. PLR's Procedure
PLR node binds its backup MP2MP downstream NHLFE entry to primary PLR node binds its backup MP2MP downstream NHLFE entry to primary
MP2MP downstream ILM entry and binds its primary MP2MP upstream NHLFE MP2MP downstream ILM entry, also binds its primary MP2MP upstream
entry to backup MP2MP upstream ILM entry. NHLFE entry to backup MP2MP upstream ILM entry.
5.5.3. Switchover Procedure 6.5.3. Switch over Procedure
When the protected node fails, both the affected downstream and When the protected node fails, both the affected downstream and
upstream nodes function as PLR and switch the downstream flow and upstream nodes function as PLR and switch the downstream flow and
upstream flow to their respective backup paths. upstream flow to their respective backup paths.
5.6. Protocol Extensions for mLDP Based Node Protection 7. Protocol Extensions for mLDP Based Node Protection
5.6.1. mLDP Based MP Protection Capability Parameter TLV Numerical fields in the formats defined in this section are encoded
as unsigned integers in network octet and bit order.
A new Capability Parameter TLV is defined as mLDP Based MP Protection 7.1. mLDP Based MP Protection Capability Parameter TLV
Capability for node protection. The following is the format of this
new Capability Parameter TLV:
0 1 2 3 A new Capability Parameter TLV is defined as mLDP Based MP Protection
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Capability for node protection. The format is illustrated as the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ following:
|1|0| mLDP Based MP Prot.(IANA) | Length (= 2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
S: As specified in [RFC5561] 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| mLDP Based MP Prot.(IANA) | Length (= 2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Figure 4: mLDP Based MP Protection Capability Figure 4: mLDP Based MP Protection Capability
mLDP Based MP Prot.: TBA1 (to be assigned by IANA)
S: As specified in [RFC5561]
This is an unidirectional capability announcement. This is an unidirectional capability announcement.
An LSR, which supports the mLDP based protection procedures, should An LSR, which supports the mLDP based protection procedures, should
advertise this mLDP Based MP Protection Capability TLV to its LDP advertise mLDP Based MP Protection Capability TLV to its LDP
speakers. Without receiving this capability announcement, an LSR speakers. Without receiving this capability announcement, an LSR
MUST NOT send any message including the mLDP Based MP Node Protection MUST NOT send any messages including the mLDP Based MP Node
Status Element and mLDP Backup FEC Element to its peer. Protection Status Element and mLDP Backup FEC Element to its peer.
Capability Data might be needed to distinguish the capabilities of
different nodes, such as PLR, MP, N, Pn and so on.
5.6.2. mLDP Based MP Node Protection Status Elements 7.2. mLDP Based MP Node Protection Status Elements
A new type of LDP MP Status Value Element is introduced for notifying A new type of LDP MP Status Value Element is introduced for notifying
upstream LSR information. It is encoded as follows: upstream LSR information. It is encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|mLDP FRR Type=3| Length | Reserved | |mLDP FRR Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PLR Node Address ~ ~ PLR Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: FRR LDP MP Status Value Element Figure 5: FRR LDP MP Status Value Element
mLDP FRR Type: Type 3 (to be assigned by IANA) mLDP FRR Type: Type TBA2 (to be assigned by IANA)
Length: If the Address Family is IPv4, the Length MUST be 5; Length: If the Address Family is IPv4, the Length MUST be
if the Address Family is IPv6, the Length MUST be 17. 5;
if the Address Family is IPv6, the Length MUST be
17.
PLR Node Address: The host address of the PLR Node. PLR Node Address: The host address of the PLR Node.
5.6.3. mLDP Backup FEC Element Encoding 7.3. mLDP Backup FEC Element Encoding
A new type of mLDP backup FEC Element is introduced for notifying A new type of mLDP backup FEC Element is introduced, it is used for
upstream LSR information. It is encoded as follows: notifying upstream LSR information. It is encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|mLDP FEC T=FRR | Address Family | Address Length| |mLDP FEC T-FRR | Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PLR Node Address ~ ~ PLR Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| Status code | FEC-Type | MT-ID | |N| Status code | FEC-Type | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Node Address | | Protected Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... | | Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~ ~ ~
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: mLDP Backup FEC Element Figure 6: mLDP Backup FEC Element
mLDP FEC Type-FRR: Type 5 (to be assigned by IANA) mLDP FEC Type-FRR: Type TBA3 (to be assigned by IANA)
Length: If the Address Family is IPv4, the Address Length MUST be 9; Address Length: If the Address Family is IPv4, the Address
if the Address Family is IPv6, the Address Length MUST be 33. Length MUST be 9;
if the Address Family is IPv6, the Address
Length MUST be 33.
Status code: 1 = Primary path for traffic forwarding PLR Node Address: The host address of the PLR Node.
2 = Secondary path for traffic forwarding
FEC-Type: 6 = P2MP FEC type Protected Node Address: The host address of the Protected Node.
7 = MP2MP-up FEC type
8 = MP2MP-down FEC type
PLR Node Address: The host address of the PLR Node. Status code: 1 = Primary path for traffic forwarding
2 = Secondary path for traffic forwarding
Protected Node Address: The host address of the Protected Node. FEC-Type: 6 = P2MP FEC type
7 = MP2MP-up FEC type
8 = MP2MP-down FEC type
N Bit: Node Failure Required Flag, the occasion of switching traffic's on PLR MT-ID: Multi-Topology ID. Unsigned 16 bit integer.
1 = 'Y', switch traffic to backup path only when PLR detects the node failure
0 = 'N', switch traffic to backup path when PLR detects failure
Opaque Length: The length of the opaque value, in octets. Opaque Length: The length of the opaque value, in octets.
Opaque Value: One or more MP opaque value elements, which is the same definition in [RFC6388]. Opaque Value: One or more MP opaque value elements, which
For the FRR mLDP FEC element, the Opaque Value MUST be encoded is the same definition in [RFC6388]. For the
as the Recursive Opaque Value, which is defined in [RFC6512]. The value FRR mLDP FEC element, the Opaque Value MUST
fields of the Recursive Opaque Value contain the original primary be encoded as the Recursive Opaque Value,
path's mLDP FEC element. which is defined in [RFC6512]. The value
fields of the Recursive Opaque Value contain
the original primary path's mLDP FEC element.
The encoding for this Recursive Opaque Value, as defined in [RFC6512], is shown in Figure 5. The encoding for the Recursive Opaque Value, as defined in [RFC6512],
is shown in Figure 7.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length | | | Type = 7 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ ~ ~
| P2MP or MP2MP FEC Element | | P2MP or MP2MP FEC Element |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Recursive Opaque Value, defined in [RFC6512] Figure 7: Recursive Opaque Value
The Opaque Value is encoded by MP node and decoded by PLR. Other The Opaque Value is encoded by the MP node and decoded by PLR. Any
nodes MUST NOT interpret the opaque value at all. other nodes on the path MUST NOT interpret the opaque value.
5.7. IANA Considerations 8. IANA Considerations
This memo includes the following requests to IANA: The document introduces following new protocol elements that require
IANA consideration and assignments:
o mLDP Based MP Protection Capability o Code Points for "MP Protection Capability" TLV from the "LDP TLV
Type Name Space" registry within the LDP Parameters
o mLDP FRR types for LDP MP Status Value Element Registry:
Range/Value Description
-------------- ------------------------------
TBA1 MP Protection Capability (defined in section 7.1)
o mLDP FEC FRR Element type Figure 8: New Code Points for MP Protection Capability Extensions
6. Security Considerations o Code Points for mLDP Based MP Node Protection Status Elements from
the "LDP TLV Type Name Space" registry within the LDP Parameters
Registry:
Range/Value Description
-------------- ------------------------------
TBA2 Based MP Node Protection Status (defined in section 7.2)
Figure 9: Based MP Node Protectiin on Status
o Code Points for mLDP FRR Type FEC from the the LDP registry
"Forwarding Equivalence Class (FEC) Type Name Space". within the
LDP Parameters
Registry:
Range/Value Description
-------------- ------------------------------
TBA3 mLDP FRR Type FEC (defined in section 7.3)
Figure 10: mLDP FRR Type FEC
9. Security Considerations
The same security considerations apply as for the base LDP The same security considerations apply as for the base LDP
specification, as described in [RFC5036]. The protocol extensions specification, as described in [RFC5036]. The protocol extensions
specified in this document do not provide any authorization mechanism specified in this document do not provide any authorization mechanism
for controlling the set of LSRs that may attempt to join a mLDP for controlling the set of LSRs that may attempt to join a mLDP
protection session. If such authorization is desirable, additional protection session. If such authorization is desirable, additional
mechanisms outside the scope of this document are needed. mechanisms outside the scope of this document are needed.
Note that authorization policies should be implemented and/or Note that authorization policies should be implemented and/or
configure at all the nodes involved. configured at all the nodes involved.
7. Acknowledgements 10. Acknowledgements
We would like to thank Nicolai Leymann and Daniel King for their We would like to thank Nicolai Leymann and Daniel King for their
valuable suggestions to this draft. We also would like to thank valuable suggestions to this draft. We also would like to thank
Robin Li, Lujun Wan, Kenji fujihira, Martin Vigoureux, Yaacov Robin Li, Lujun Wan, Kenji fujihira, Martin Vigoureux, Yaacov
Weingarten and Eric Osborne for their comments and suggestions to Weingarten, Eric Osborne and Elwyn Davis for their detailed comments
the draft. and suggestions to the draft.
8. References
8.1. Normative References 11. References
11.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] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
skipping to change at page 16, line 43 skipping to change at page 18, line 31
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to- "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011. Paths", RFC 6388, November 2011.
[RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann, [RFC6512] Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann,
"Using Multipoint LDP When the Backbone Has No Route to "Using Multipoint LDP When the Backbone Has No Route to
the Root", RFC 6512, February 2012. the Root", RFC 6512, February 2012.
8.2. Informative References 11.2. Informative References
[I-D.ietf-mpls-ldp-multi-topology] [I-D.ietf-mpls-ldp-multi-topology]
Zhao, Q., Fang, L., Zhou, C., Li, L., and K. Raza, "LDP Zhao, Q., Fang, L., Zhou, C., Li, L., and K. Raza, "LDP
Extensions for Multi Topology Routing", Extensions for Multi Topology Routing",
draft-ietf-mpls-ldp-multi-topology-08 (work in progress), draft-ietf-mpls-ldp-multi-topology-08 (work in progress),
May 2013. May 2013.
[I-D.wijnands-mpls-mldp-node-protection] [I-D.wijnands-mpls-mldp-node-protection]
Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas, Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas,
A., and Q. Zhao, "mLDP Node Protection", A., and Q. Zhao, "mLDP Node Protection",
draft-wijnands-mpls-mldp-node-protection-04 (work in draft-wijnands-mpls-mldp-node-protection-04 (work in
progress), June 2013. progress), June 2013.
[I-D.ietf-rtgwg-mrt-frr-architecture] [I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura, Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura,
J., Konstantynowicz, M., White, R., and M. Shand, "An J., Konstantynowicz, M., and R. White, "An Architecture
Architecture for IP/LDP Fast-Reroute Using Maximally for IP/LDP Fast-Reroute Using Maximally Redundant Trees",
Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-02 draft-ietf-rtgwg-mrt-frr-architecture-03 (work in
(work in progress), February 2013. progress), July 2013.
[I-D.enyedi-rtgwg-mrt-frr-algorithm] [I-D.enyedi-rtgwg-mrt-frr-algorithm]
Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan, Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan,
"Algorithms for computing Maximally Redundant Trees for "Algorithms for computing Maximally Redundant Trees for
IP/LDP Fast- Reroute", IP/LDP Fast- Reroute",
draft-enyedi-rtgwg-mrt-frr-algorithm-02 (work in draft-enyedi-rtgwg-mrt-frr-algorithm-02 (work in
progress), October 2012. progress), October 2012.
Authors' Addresses Authors' Addresses
skipping to change at page 18, line 4 skipping to change at page 19, line 29
Email: quintin.zhao@huawei.com Email: quintin.zhao@huawei.com
Tao Chou Tao Chou
Huawei Technology Huawei Technology
156 Beiqing Rd 156 Beiqing Rd
Haidian District, Beijing 100095 Haidian District, Beijing 100095
China China
Email: tao.chou@huawei.com Email: tao.chou@huawei.com
Boris Zhang Boris Zhang
Telus Communications Telus Communications
200 Consilium Pl Floor 15 200 Consilium Pl Floor 15
Toronto, ON M1H 3J3 Toronto, ON M1H 3J3
Canada Canada
Phone: Phone:
Email: Boris.Zhang@telus.com Email: Boris.Zhang@telus.com
Emily Chen Emily Chen
2717 Seville Blvd, Apt 1205 2717 Seville Blvd, Apt 1205
Clearwater, FL 33764 Clearwater, FL 33764
US US
 End of changes. 127 change blocks. 
402 lines changed or deleted 469 lines changed or added

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