draft-tsaad-mpls-p2mp-loose-path-reopt-02.txt   draft-tsaad-mpls-p2mp-loose-path-reopt-03.txt 
MPLS Working Group Tarek Saad, Ed. MPLS Working Group Tarek Saad, Ed.
Internet-Draft Rakesh Gandhi, Ed. Internet-Draft Rakesh Gandhi, Ed.
Intended status: Standards Track Zafar Ali Intended status: Standards Track Zafar Ali
Expires: October 24, 2014 Cisco Systems, Inc. Expires: January 22, 2015 Cisco Systems, Inc.
Robert H. Venator Robert H. Venator
Defense Information Systems Agency Defense Information Systems Agency
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT Communications Corporation
April 22, 2014 July 21, 2014
Reoptimization of Point-to-Multipoint Traffic Engineering Reoptimization of Point-to-Multipoint Traffic Engineering
Loosely Routed LSPs Loosely Routed LSPs
draft-tsaad-mpls-p2mp-loose-path-reopt-02 draft-tsaad-mpls-p2mp-loose-path-reopt-03
Abstract Abstract
This document defines Resource Reservation Protocol - Traffic For a Traffic Engineered (TE) point-to-multipoint (P2MP) Label
Engineering (RSVP-TE) signaling extensions for reoptimizing loosely Switched Path (LSP), it is preferable in some cases to re-evaluate
routed Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label and re-optimize the entire P2MP-TE LSP by re-signaling all its S2L
Switched Paths (LSPs) in an Multi-Protocol Label Switching (MPLS) sub-LSP(s). Existing mechanisms allow the path re-evaluation and the
and/or Generalized MPLS (GMPLS) networks. signaling of a the notification of preferred path exists for a single
S2L sub-LSP only.
This document defines RSVP-TE signaling extensions to allow an
ingress Label Switching Router (LSR) of a P2MP-TE LSP to trigger the
re-evaluation of the entire LSP tree containing one or more S2L sub-
LSPs whose paths are loose (or abstract) hop expanded, and for a mid-
point LSR to signal to the ingress LSR that a better tree exists for
the entire P2MP-TE LSP.
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/.
skipping to change at page 3, line 9 skipping to change at page 3, line 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document defines Resource Reservation Protocol - Traffic This document defines Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for
reoptimizing loosely routed Point-to-Multipoint (P2MP) Traffic re-optimizing loosely routed Point-to-Multipoint (P2MP) Traffic
Engineered (TE) Label Switched Paths (LSPs) [RFC4875] in an Engineered (TE) Label Switched Paths (LSPs) [RFC4875] in an
Multi-Protocol Label Switching (MPLS) and/or Generalized MPLS (GMPLS) Multi-Protocol Label Switching (MPLS) and/or Generalized MPLS (GMPLS)
networks. networks.
A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L) A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L)
sub-LSPs. A loosely routed P2MP-TE S2L sub-LSP is defined as one sub-LSPs. A loosely routed P2MP-TE S2L sub-LSP is defined as one
whose path does not contain the full explicit route identifying each whose path does not contain the full explicit route identifying each
node along the path to the egress node at the time of its signaling node along the path to the egress node at the time of its signaling
by the ingress node. Such an S2L sub-LSP is signaled with no by the ingress node. Such an S2L sub-LSP is signaled with no
Explicit Route Object (ERO) [RFC3209], or with an ERO that contains Explicit Route Object (ERO) [RFC3209], or with an ERO that contains
at least one loose hop, or with an ERO that contains an abstract node at least one loose hop, or with an ERO that contains an abstract node
that is not a simple abstract node (that is, an abstract node that that is not a simple abstract node (that is, an abstract node that
identifies more than one node). This is often the case with identifies more than one node). This is often the case with
inter-domain P2MP-TE LSPs where Path Computation Element (PCE) is not inter-domain P2MP-TE LSPs where Path Computation Element (PCE) is not
used [RFC5440]. used [RFC5440].
As per [RFC4875], an ingress node may reoptimize the entire P2MP-TE As per [RFC4875], an ingress node may re-optimize the entire P2MP-TE
LSP by resignaling all its S2L sub-LSP(s) or may reoptimize LSP by re-signaling all its S2L sub-LSP(s) or may re-optimize
individual S2L sub-LSP(s) i.e. individual destination(s). individual S2L sub-LSP(s) i.e. individual destination(s).
[RFC4736] defines RSVP signaling extensions for reoptimizing loosely [RFC4736] defines RSVP signaling extensions for re-optimizing loosely
routed P2P TE LSP(s) as follows. routed P2P TE LSP(s) as follows.
- An egress border node MAY send a solicited or unsolicited PathErr - A mid-point LSR that expands loose next-hop(s) MAY send a solicited
with the Notify error code (25 as defined in [RFC3209]) with sub-code or unsolicited PathErr with the Notify error code (25 as defined in
6 to indicate "Preferable Path Exists" to the ingress node. [RFC3209]) with sub-code 6 to indicate "Preferable Path Exists" to
the ingress node.
- An ingress node MAY solicit a PathErr that indicates "Preferable - An ingress node MAY trigger a path re-evaluation request at all
Path Exists" by sending a "Path Re-evaluation Request" to an egress mid-point LSR(s) that expands loose next-hop(s) by setting the "Path
border node by setting a flag (0x20) in SESSION_ATTRIBUTES object in Re-evaluation Request" flag (0x20) in SESSION_ATTRIBUTES object in
the Path message. the Path message.
- The ingress node upon receiving this PathErr either solicited or - The ingress node upon receiving this PathErr either solicited or
unsolicited initiates reoptimization of the LSP. unsolicited initiates re-optimization of the LSP.
[RFC4736] does not define signaling extensions specific for [RFC4736] does not define signaling extensions specific for re-
reoptimizing entire P2MP-TE LSP tree. Mechanisms defined in optimizing entire P2MP-TE LSP tree. Mechanisms defined in [RFC4736]
[RFC4736] can be used for signaling the reoptimization of individual can be used for signaling the re-optimization of individual S2L sub-
S2L sub- LSP(s). However, to use [RFC4736] mechanisms for LSP(s). However, to use [RFC4736] mechanisms for re-optimizing an
reoptimizing an entire P2MP-TE LSP tree, an ingress node needs to entire P2MP-TE LSP tree, an ingress node needs to send the path re-
send the query on all (typically 100s of) S2L sub-LSPs and an egress evaluation requests on all (typically 100s of) S2L sub-LSPs and the
border node needs to notify PathErrs for all S2L sub-LSPs. Such a mid-point LSR to notify PathErrs for all S2L sub-LSPs. Such a
procedure may lead to the following issues. procedure may lead to the following issues:
- An egress border node has to accumulate the received queries on all - A mid-point LSR that expands loose next-hop(s) may have to
S2L sub-LSPs (using a wait timer) and interpret them as a accumulate the received path re-evaluation request(s) for all S2L
reoptimization request for the P2MP-TE LSP tree. An egress border sub-LSPs (e.g, by using a wait timer) and interpret them as a re-
node may prematurely notify "Preferable Path Exists" for one or a optimization request for the whole P2MP-TE LSP tree. Otherwise, A
sub-set of S2L sub-LSPs. mid-point LSR may prematurely notify "Preferable Path Exists" for one
or a sub-set of S2L sub-LSPs.
- When the ingress node gradually receives unsolicited PathErr - The ingress LSR that receives (un)solicited PathErr notification(s)
notifications for individual S2L sub-LSPs, it may prematurely start for individual S2L sub-LSP(s), may prematurely start re-optimizing
reoptimizing a sub-set of S2L sub-LSPs. However, as mentioned in the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875]
[RFC4875] Section 14.2, such reoptimization procedure may result in Section 14.2, such re-optimization procedure may result in data
data duplication that can be avoided if the entire P2MP-TE LSP tree duplication that can be avoided if the entire P2MP-TE LSP tree is re-
is reoptimized, especially if the ingress node eventually receives optimized, especially if the ingress node eventually receives PathErr
PathErr notifications for all S2L sub-LSPs of the P2MP-TE LSP tree. notifications for all S2L sub-LSPs of the P2MP-TE LSP tree.
- The ingress node may have to heuristically determine when to - The ingress node may have to heuristically determine when to
perform entire P2MP-TE LSP tree reoptimization versus per S2L sub-LSP perform entire P2MP-TE LSP tree re-optimization versus per S2L sub-
reoptimization, for example, to delay reoptimization long enough to LSP re-optimization, for example, to delay re-optimization long
allow all PathErr(s) to be received. Once all PathErr(s) are enough to allow all PathErr(s) to be received. Once all PathErr(s)
received, the ingress node has to accumulate them to see if are received, the ingress node has to accumulate them to see if re-
reoptimization of the entire P2MP-TE is necessary. Such procedures optimization of the entire P2MP-TE is necessary. Such procedures may
may produce undesired results due to timing related issues. This may produce undesired results due to timing related issues. This may be
be easily avoided by the RSVP signaling messages defined in this easily avoided by the RSVP signaling messages defined in this
document. document.
This document defines RSVP-TE signaling extensions to query and This document defines RSVP-TE signaling extensions for the head-end
notify the existance of a preferable path for reoptimizing loosely LSR of a P2MP-TE LSP to trigger the re-evaluation of the P2MP tree on
routed P2MP-TE LSP tree. every hop that has a next hop defined as a loose or abstract hop for
one or more S2L sub-LSP path, and a mid-point LSR to signal to the
head-end LSR that a better tree exists (compared to the current path)
or that the whole P2MP-TE LSP must be re-optimized (because of
maintenance required on the TE LSP path).
2. Terminology 2. Terminology
2.1. Abbreviations 2.1. Abbreviations
ABR: Area Border Router. ABR: Area Border Router.
AS: Autonomous System. AS: Autonomous System.
ERO: Explicit Route Object. ERO: Explicit Route Object.
skipping to change at page 5, line 29 skipping to change at page 6, line 29
S2L sub-LSP: Source-to-leaf sub Label Switched Path. S2L sub-LSP: Source-to-leaf sub Label Switched Path.
2.3. Conventions used in this document 2.3. 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 [RFC2119]. The reader document are to be interpreted as described in [RFC2119]. The reader
is assumed to be familiar with the terminology in [RFC4875] and is assumed to be familiar with the terminology in [RFC4875] and
[RFC4736]. [RFC4736].
3. Signaling Procedure For Loosely Routed P2MP-TE LSP Reoptimization 3. Signaling Procedure For Loosely Routed P2MP-TE LSP Re-Optimization
It might be preferable, as per [RFC4875], to reoptimize the entire It might be preferable, as per [RFC4875], to re-optimize the entire
P2MP-TE LSP by resignaling all its S2L sub-LSP(s) (Section 14.1, P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1,
"Make-before- Break") or reoptimize individual S2L sub-LSP(s) i.e. "Make-before- Break") or re-optimize individual S2L sub-LSP(s) i.e.
individual destination(s) (Section 14.2 "Sub-Group-Based Re- individual destination(s) (Section 14.2 "Sub-Group-Based Re-
Optimization"). Optimization"). This can be achieved by using the procedures defined
in [RFC4736] to individually re-optimize the S2L sub-LSP(s) of a
It might be preferable to use the procedures defined in [RFC4736] to P2MP-TE LSP.
individually reoptimize the S2L sub-LSP(s) of a P2MP-TE LSP.
To reoptimize an entire P2MP-TE LSP tree, in order to query egress To evaluate an entire P2MP-TE LSP tree on mid-point LSRs that expand
border nodes to check if a preferable P2MP-TE LSP tree exists, an loose next-hop(s), an ingress node may send a Path message with
ingress node sends a Path message with "P2MP-TE Tree Re-evaluation "P2MP-TE Tree Re-evaluation Request" defined in this document. An
Request" defined in this document. An ingress node may select one or ingress node may select one or more S2L sub-LSP of the P2MP-TE LSP
more S2L sub-LSP of the P2MP-TE LSP tree transiting through the tree to trigger the re-evaluation request(s).
egress border node to send the query to that egress border node.
An egress border node receiving the "P2MP-TE Tree Re-evaluation A mid-point LSR that expands loose next-hop(s) for one or more S2L
Request" checks for a preferable P2MP-TE LSP tree by re-evaluating sub-LSP path(s), and that receives a Path message with the "P2MP-TE
loosely expanded paths for all S2L sub-LSP(s) of the P2MP-TE LSP. If Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE
a preferable P2MP-TE LSP tree is found, the egress border node LSP tree by re-evaluating all S2L sub-LSP(s) expanded paths of the
immediately sends an RSVP PathErr to the ingress node with Error code P2MP-TE LSP. If a preferable P2MP-TE LSP tree is found, the mid-
point LSR sends an RSVP PathErr to the ingress node with Error code
25 (Notify defined in [RFC3209] and Error sub-code defined in this 25 (Notify defined in [RFC3209] and Error sub-code defined in this
document "Preferable P2MP-TE Tree Exists". At this point, the egress document "Preferable P2MP-TE Tree Exists". The mid-point LSR, in
border node does not propagate this bit in subsequent RSVP Path turn, does not propagate the "P2MP-TE Tree Re-evaluation Request" bit
messages sent downstream for the re-evaluated P2MP-TE LSP. The in subsequent RSVP Path messages sent downstream for the re-evaluated
sending of an RSVP PathErr Notify message "Preferable P2MP-TE Tree P2MP-TE LSP. The sending of an RSVP PathErr Notify message
Exists" to the ingress node will notify the ingress node of the "Preferable P2MP-TE Tree Exists" to the ingress node will notify the
existence of a preferable P2MP-TE LSP tree. ingress node of the existence of a preferable P2MP-TE LSP tree. In
addition, a mid-point LSR may send an unsolicited PathErr message
If no preferable path for P2MP-TE LSP tree can be found, the with "Preferable P2MP-TE Tree Exists" PathErr code 25 to the ingress
recommended mode is for the egress border node to relay the request node to notify of a preferred the P2MP-TE LSP tree when it determines
downstream by setting the "P2MP-TE Tree Re-evaluation Request" bit in it exists. In this case, the mid-point LSR that expands loose next-
the LSP_ATTRIBUTES object of RSVP Path message. hop(s) for one or more S2L sub-LSP path(s) may select one or more S2L
sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to
the ingress node.
An egress border node may send "Preferable P2MP-TE Tree Exists" with If no preferable tree for P2MP-TE LSP can be found, the recommended
PathErr code 25 to the ingress node to notify an existence of a mode is for the mid-point LSR that expands loose next-hop(s) for one
preferred path for the P2MP-TE LSP tree with an unsolicited PathErr or more S2L sub-LSP path(s) to propagate the request downstream by
message. The egress border node may select one or more S2L sub- setting the "P2MP-TE Tree Re-evaluation Request" bit in the
LSP(s) of the P2MP-TE LSP tree to send this PathErr message to the LSP_ATTRIBUTES object of RSVP Path message.
ingress node.
4. RSVP Signaling Extensions 4. RSVP Signaling Extensions
4.1. P2MP-TE Tree Re-evaluation Request Flag 4.1. P2MP-TE Tree Re-evaluation Request Flag
In order to query egress border nodes to check if a preferable P2MP- In order to trigger a tree re-evaluation request, a new flag is
TE LSP tree exists, a new flag is defined in Attributes Flags TLV of defined in Attributes Flags TLV of the LSP_ATTRIBUTES object
the LSP_ATTRIBUTES object [RFC5420] as follows: [RFC5420] as follows:
Bit Number (to be assigned by IANA): P2MP-TE Tree Re-evaluation Bit Number (to be assigned by IANA): P2MP-TE Tree Re-evaluation
Request flag Request flag
The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path
message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node. message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node.
4.2. Preferable P2MP-TE Tree Exists Path Error sub-code 4.2. Preferable P2MP-TE Tree Exists Path Error sub-code
In order to indicate to an ingress node that a preferable P2MP-TE LSP In order to indicate to an ingress node that a preferable P2MP-TE LSP
tree is available, following new sub-code for PathErr code 25 (Notify tree exists, the following new sub-code for PathErr code 25 (Notify
Error) [RFC3209] is defined: Error) [RFC3209] is defined:
Sub-code (to be assigned by IANA): Preferable P2MP-TE Tree Exists Sub-code (to be assigned by IANA): Preferable P2MP-TE Tree Exists
sub-code sub-code
When a preferable path for P2MP-TE LSP tree is found, the egress When a preferable path for P2MP-TE LSP tree exists, the mid-point LSR
border node sends a solicited or unsolicited "Preferable P2MP-TE Tree sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists"
Exists" PathErr notification to the ingress node of the P2MP-TE LSP. PathErr notification to the ingress node of the P2MP-TE LSP.
5. Compatibility 5. Compatibility
The LSP_ATTRIBUTES object has been defined in [RFC5420] with class The LSP_ATTRIBUTES object has been defined in [RFC5420] with class
numbers in the form 11bbbbbb, which ensures compatibility with numbers in the form 11bbbbbb, which ensures compatibility with
non-supporting nodes. Per [RFC2205], nodes not supporting this non-supporting nodes. Per [RFC2205], nodes not supporting this
extension will ignore the new flag defined in this document but extension will ignore the new flag defined in this document but
forward it without modification. forward it without modification.
6. Security Considerations 6. Security Considerations
This document defines a mechanism for an egress border node to notify This document defines a mechanism for a mid-point LSR to notify the
the ingress node of the existence of a preferable path. As per ingress node of a P2MP-TE LSP of the existence of a preferable tree.
[RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning multiple As per [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning
domains, it may be desirable for a border node to modify the RSVP multiple domains, it may be desirable for a a mid-point LSR to modify
PathErr message defined in this document to maintain confidentiality the RSVP PathErr message defined in this document to maintain
across different domains. Furthermore, an ingress node may decide to confidentiality across different domains. Furthermore, an ingress
ignore this PathErr message coming from an egress border node node may decide to ignore this PathErr message coming from a mid-
residing in another domain. Similarly, an egress border node may point LSR residing in another domain. Similarly, an mid-point LSR
decide to ignore the path re-evaluation request originating from may decide to ignore the tree re-evaluation request originating from
another ingress domain. another ingress domain.
7. IANA Considerations 7. IANA Considerations
IANA maintains a name space for RSVP-TE TE parameters "Resource IANA maintains a name space for RSVP-TE TE parameters "Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters". From Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters". From
the registries in this name space "Attribute Flags" allocation of new the registries in this name space "Attribute Flags" allocation of new
flag is requested (Section 4.1). flag is requested (Section 4.1).
IANA also maintains a name space for RSVP protocol parameters IANA also maintains a name space for RSVP protocol parameters
 End of changes. 26 change blocks. 
101 lines changed or deleted 115 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/