draft-ietf-teas-p2mp-loose-path-reopt-04.txt   draft-ietf-teas-p2mp-loose-path-reopt-05.txt 
TEAS Working Group T. Saad, Ed. TEAS Working Group T. Saad, Ed.
Internet-Draft R. Gandhi, Ed. Internet-Draft R. Gandhi, Ed.
Intended status: Standards Track Z. Ali Intended status: Standards Track Z. Ali
Expires: May 19, 2016 Cisco Systems, Inc. Expires: September 12, 2016 Cisco Systems, Inc.
R. Venator R. Venator
Defense Information Systems Agency Defense Information Systems Agency
Y. Kamite Y. Kamite
NTT Communications Corporation NTT Communications Corporation
November 16, 2015 March 11, 2016
RSVP Extensions For Re-optimization of Loosely Routed RSVP Extensions For Re-optimization of Loosely Routed
Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)
draft-ietf-teas-p2mp-loose-path-reopt-04 draft-ietf-teas-p2mp-loose-path-reopt-05
Abstract Abstract
For a Traffic Engineered (TE) Point-to-Multipoint (P2MP) Label For a Traffic Engineered (TE) Point-to-Multipoint (P2MP) Label
Switched Path (LSP), it is preferable in some cases to re-evaluate Switched Path (LSP), it is preferable in some cases to re-evaluate
and re-optimize the entire P2MP-TE LSP by re-signaling all its and re-optimize the entire P2MP-TE LSP by re-signaling all its
Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism
for an ingress Label Switched Router (LSR) to trigger a new path for an ingress Label Switched Router (LSR) to trigger a new path
re-evaluation request and a mechanism for a mid-point LSR to notify re-evaluation request and a mechanism for a mid-point LSR to notify
an availability of a preferred path, operate on an individual or a an availability of a preferred path, operate on an individual or a
sub-group of S2L sub-LSP(s) basis only. sub-group of S2L sub-LSP(s) basis only.
This document defines Resource Reservation Protocol (RSVP) signaling This document defines Resource Reservation Protocol (RSVP) signaling
extensions to allow an ingress node of a P2MP-TE LSP to request the extensions to allow an ingress node of a P2MP-TE LSP to request the
re-evaluation of the entire LSP tree containing one or more S2L 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 sub-LSPs whose paths are loose (or abstract) hop expanded, and for a
mid-point LSR to notify to the ingress node that a preferable tree mid-point LSR to notify to the ingress node that a preferable tree
exists for the entire P2MP-TE LSP. For re-optimizing a group of S2L exists for the entire P2MP-TE LSP. For re-optimizing a group of S2L
sub-LSP(s) in a tree, an S2L sub-LSP descriptor list can be used to sub-LSP(s) in a tree, an S2L sub-LSP descriptor list can be used to
signal one or more S2L sub-LSPs in an RSVP message. This document signal one or more S2L sub-LSPs in an RSVP message. This document
defines markers to indicate beginning and end of an S2L sub-LSP defines fragment identifier for the S2L sub-LSP descriptor list when
descriptor list when the RSVP message needs to be fragmented due to the RSVP message needs to be fragmented due to large number of S2L
large number of S2L sub-LSPs in the message when performing sub-group sub-LSPs in the message when performing sub-group based
based re-optimization. re-optimization.
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."
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 20 skipping to change at page 3, line 20
Re-optimization . . . . . . . . . . . . . . . . . . . . . 5 Re-optimization . . . . . . . . . . . . . . . . . . . . . 5
1.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP 1.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP
Re-optimization . . . . . . . . . . . . . . . . . . . . . 6 Re-optimization . . . . . . . . . . . . . . . . . . . . . 6
2. Conventions Used in This Document . . . . . . . . . . . . . . 7 2. Conventions Used in This Document . . . . . . . . . . . . . . 7
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 7 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 7
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Nomenclatures . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Nomenclatures . . . . . . . . . . . . . . . . . . . . . . 8
3. Signaling Procedure For Loosely Routed P2MP-TE LSP 3. Signaling Procedure For Loosely Routed P2MP-TE LSP
Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 8 Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 8 3.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 8
3.2. Sub-Group-Based Re-optimization Using Markers . . . . . . 9 3.2. Sub-Group-Based Re-optimization Using Fragment
Identifier . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Message and Object Definitions . . . . . . . . . . . . . . . . 10 4. Message and Object Definitions . . . . . . . . . . . . . . . . 10
4.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 10 4.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 10
4.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 10 4.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 10
4.3. Markers For S2L sub-LSP Descriptor . . . . . . . . . . . . 11 4.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 11
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 12 6.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 12
6.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 12 6.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 12
6.3. BEGIN and END Markers For S2L sub-LSP Descriptor . . . . . 13 6.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document defines Resource Reservation Protocol - Traffic This document defines Resource Reservation Protocol - Traffic
skipping to change at page 7, line 23 skipping to change at page 7, line 23
using the same LSP-ID or tree based re-optimization using a different using the same LSP-ID or tree based re-optimization using a different
LSP-ID. LSP-ID.
o An LSR may fragment a large RSVP message (when a combined message o An LSR may fragment a large RSVP message (when a combined message
may not be large enough to fit all S2L sub-LSPs). In this case, the may not be large enough to fit all S2L sub-LSPs). In this case, the
ingress node may receive multiple PathErrs with sub-sets of S2L ingress node may receive multiple PathErrs with sub-sets of S2L
sub-LSPs in each (either due to the combined Path message got sub-LSPs in each (either due to the combined Path message got
fragmented or combined PathErr message got fragmented) and would fragmented or combined PathErr message got fragmented) and would
require additional logic to infer to re-optimize the LSP tree (for require additional logic to infer to re-optimize the LSP tree (for
example, waiting for some time to aggregate all possible PathErr example, waiting for some time to aggregate all possible PathErr
messages before taking an action). messages before taking an action). When fragmented, RSVP messages
may arrive out of order, and the receiver has no way of knowing the
beginning and end of the S2L sub-LSP list.
In order to address the above mentioned issue due to the RSVP message In order to address the above mentioned issues due to the RSVP
fragmentation, this document defines markers to indicate beginning message fragmentation, this document defines fragment identifier for
and end of an S2L sub-LSP descriptor list when combining large number the S2L sub-LSP descriptor list when combining large number of S2L
of S2L sub-LSPs in an RSVP message. sub-LSPs in an RSVP message.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Key Word Definitions 2.1. Key Word Definitions
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]. document are to be interpreted as described in [RFC2119].
2.2. Abbreviations 2.2. Abbreviations
skipping to change at page 9, line 27 skipping to change at page 9, line 29
one or more S2L sub-LSP path(s) SHOULD select one of the S2L sub- one or more S2L sub-LSP path(s) SHOULD select one of the S2L sub-
LSP(s) of the P2MP-TE LSP tree to send this PathErr message to the LSP(s) of the P2MP-TE LSP tree to send this PathErr message to the
ingress node. ingress node.
The sending of an RSVP PathErr Notify message "Preferable P2MP-TE The sending of an RSVP PathErr Notify message "Preferable P2MP-TE
Tree Exists" to the ingress node SHALL notify the ingress node of the Tree Exists" to the ingress node SHALL notify the ingress node of the
existence of a preferable P2MP-TE LSP tree and upon receiving this existence of a preferable P2MP-TE LSP tree and upon receiving this
PathErr, the ingress node MAY trigger re-optimization of the LSP PathErr, the ingress node MAY trigger re-optimization of the LSP
using a different LSP-ID. using a different LSP-ID.
3.2. Sub-Group-Based Re-optimization Using Markers 3.2. Sub-Group-Based Re-optimization Using Fragment Identifier
It might be preferable, as per [RFC4875], to re-optimize the entire It might be preferable, as per [RFC4875], to re-optimize the entire
P2MP-TE LSP by re-signaling all of 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 to re-optimize individual or group of S2L "Make-before-Break") or to re-optimize individual or group of S2L
sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2 sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2
"Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same "Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same
LSP-ID. For loosely routed S2L sub-LSPs, this can be achieved by LSP-ID. For loosely routed S2L sub-LSPs, this can be achieved by
using the procedures defined in [RFC4736] to re-optimize one or more using the procedures defined in [RFC4736] to re-optimize one or more
S2L sub-LSP(s) of the P2MP-TE LSP. S2L sub-LSP(s) of the P2MP-TE LSP.
skipping to change at page 10, line 4 skipping to change at page 10, line 6
[RFC4875]. An S2L sub-LSP descriptor list is created using a series [RFC4875]. An S2L sub-LSP descriptor list is created using a series
of S2L_SUB_LSP Objects as defined in [RFC4875]. Similarly, a mid- of S2L_SUB_LSP Objects as defined in [RFC4875]. Similarly, a mid-
point LSR may send a PathErr message (with Error code 25, sub-code 6, point LSR may send a PathErr message (with Error code 25, sub-code 6,
Preferable Path Exists) containing a list of S2L sub-LSPs transiting Preferable Path Exists) containing a list of S2L sub-LSPs transiting
through the LSR using an S2L sub-LSP descriptor list to notify the through the LSR using an S2L sub-LSP descriptor list to notify the
ingress node of preferable paths available. ingress node of preferable paths available.
As per [RFC4875] (Section 5.2.3, "Transit Fragmentation of Path State As per [RFC4875] (Section 5.2.3, "Transit Fragmentation of Path State
Information"), when a Path message is not large enough to fit all S2L Information"), when a Path message is not large enough to fit all S2L
sub-LSPs in the descriptor list, an LSR may fragment the message. In sub-LSPs in the descriptor list, an LSR may fragment the message. In
this case, the LSR MAY add S2L_SUB_LSP_MARKER_BEGIN and this case, the LSR MAY add S2L_SUB_LSP_FRAG Object defined in this
S2L_SUB_LSP_MARKER_END Objects defined in this document at the document in the S2L sub-LSP descriptor list to be able to rebuild the
beginning and at the end of the S2L sub-LSP descriptor list, list from the received fragments that may arrive out of order.
respectively.
Both S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Objects The S2L_SUB_LSP_FRAG Object defined in this document is optional.
defined in this document are optional. However, a node MUST add the However, a node MUST add the S2L_SUB_LSP_FRAG Object for each
S2L_SUB_LSP_MARKER_END Object if it has added fragment in S2L sub-LSP descriptor list when the RSVP message needs
S2L_SUB_LSP_MARKER_BEGIN Object in the S2L sub-LSP descriptor list. to be fragmented.
A mid-point LSR SHOULD wait to accumulate all S2L sub-LSPs before A mid-point LSR SHOULD wait to accumulate all S2L sub-LSPs before
attempting to re-evaluate preferable path when a Path message for attempting to re-evaluate preferable path when a Path message for
"Path Re-evaluation Request" is received with "Path Re-evaluation Request" is received with S2L_SUB_LSP_FRAG
S2L_SUB_LSP_MARKER_BEGIN Object. An ingress node SHOULD wait to Object. An ingress node SHOULD wait to accumulate all S2L sub-LSPs
accumulate all S2L sub-LSPs before attempting to trigger before attempting to trigger re-optimization when a PathErr message
re-optimization when a PathErr message with "Preferable Path Exists" with "Preferable Path Exists" is received with a S2L_SUB_LSP_FRAG
is received with S2L_SUB_LSP_MARKER_BEGIN Object. Object.
New objects S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END The new object S2L_SUB_LSP_FRAG defined in this document has a wider
defined in this document have a wider applicability other than the applicability other than the P2MP-TE LSP re-optimization but it is
P2MP-TE LSP re-optimization but it is outside the scope of this outside the scope of this document.
document.
4. Message and Object Definitions 4. Message and Object Definitions
4.1. P2MP-TE Tree Re-evaluation Request Flag 4.1. P2MP-TE Tree Re-evaluation Request Flag
In order to trigger a tree re-evaluation request, a new flag is In order to trigger a tree re-evaluation request, a new flag is
defined in Attributes Flags TLV of the LSP_ATTRIBUTES Object defined in Attributes Flags TLV of 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
skipping to change at page 11, line 9 skipping to change at page 11, line 9
tree exists, the 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 exists, the mid-point LSR When a preferable path for P2MP-TE LSP tree exists, the mid-point LSR
sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists"
PathErr notification to the ingress node of the P2MP-TE LSP. PathErr notification to the ingress node of the P2MP-TE LSP.
4.3. Markers For S2L sub-LSP Descriptor 4.3. Fragment Identifier For S2L sub-LSP Descriptor
An S2L_SUB_LSP Object [RFC4875] identifies a particular S2L sub-LSP An S2L_SUB_LSP Object [RFC4875] identifies a particular S2L sub-LSP
belonging to the P2MP-TE LSP. An S2L sub-LSP descriptor list is belonging to the P2MP-TE LSP. An S2L sub-LSP descriptor list is
created using a series of S2L_SUB_LSP Objects as defined in created using a series of S2L_SUB_LSP Objects as defined in
[RFC4875]. In order to indicate the beginning and end of the S2L [RFC4875]. The RSVP message may need to be fragmented due to large
sub-LSP descriptor list when the RSVP message needs to be fragmented number of S2L sub-LSPs added in the descriptor list, and such
due to large number of S2L sub-LSPs, the following new types are fragments may be received our of order. To be able to rebuild the
defined for the S2L_SUB_LSP Object [RFC4875]. fragmented S2L sub-LSP descriptor list correctly, the following new
type is defined for the S2L_SUB_LSP Object [RFC4875].
S2L_SUB_LSP_MARKER_BEGIN :
Class-Num 50, C-Type TBA by IANA S2L_SUB_LSP_FRAG: Class-Num 50, C-Type TBA by IANA
+-----------------+---------------+--------------------------+ +---------------+---------------+---------------+---------------+
| Length (4 bytes)| Class_Num 50 | S2L_SUB_LSP_MARKER_BEGIN | | Len (12 bytes)| Reserved | Class_Num 50 | SUB_LSP_FRAG |
+-----------------+---------------+--------------------------+ +---------------+---------------+---------------+---------------+
| Reserved | Fragment ID |
+---------------+---------------+---------------+---------------+
| Fragments Total | Fragment Number |
+---------------+---------------+---------------+---------------+
S2L_SUB_LSP_MARKER_END : Fragment ID: 16-bit integer in the range of 1 to 65535. This value
is incremented for each new RSVP message that needs to be
fragmented.
Class-Num 50, C-Type TBA by IANA Fragments Total: 16-bit integer in the range of 1 to 65535. This
value indicates the number of fragments sent for the given RSVP
message.
+-----------------+---------------+--------------------------+ Fragment Number: 16-bit integer in the range of 1 to 65535. This
| Length (4 bytes)| Class_Num 50 | S2L_SUB_LSP_MARKER_END | value indicates the position of this fragment in the given RSVP
+-----------------+---------------+--------------------------+ message.
The S2L_SUB_LSP_MARKER_BEGIN Object is added before adding the first The S2L_SUB_LSP_FRAG Object is added before adding the
S2L_SUB_LSP_IPv4 or S2L_SUB_LSP_IPv6 Object and the S2L_SUB_LSP_IPv4 or S2L_SUB_LSP_IPv6 Object in the fragmented
S2L_SUB_LSP_MARKER_END Object is added after adding the last message.
S2L_SUB_LSP_IPv4 or S2L_SUB_LSP_IPv6 Object in the S2L sub-LSP
descriptor list.
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.
The S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Objects have The S2L_SUB_LSP_FRAG Object has been defined with class numbers in
been defined with class numbers in the form 11bbbbbb, which ensures the form 11bbbbbb, which ensures compatibility with non-supporting
compatibility with non-supporting nodes. Per [RFC2205], nodes not nodes. Per [RFC2205], nodes not supporting new S2L_SUB_LSP_FRAG
supporting new S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Object will ignore them but forward it without modification.
Objects will ignore them but forward it without modification.
6. IANA Considerations 6. IANA Considerations
IANA is requested to administer assignment of new values for IANA is requested to administer assignment of new values for
namespace defined in this document and summarized in this section. namespace defined in this document and summarized in this section.
6.1. P2MP-TE Tree Re-evaluation Request Flag 6.1. P2MP-TE Tree Re-evaluation Request Flag
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" (see Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" (see
skipping to change at page 13, line 15 skipping to change at page 13, line 22
o Preferable P2MP-TE Tree Exists sub-code: o Preferable P2MP-TE Tree Exists sub-code:
+----------+--------------------+---------+---------+-----------+ +----------+--------------------+---------+---------+-----------+
| Sub-code | Sub-code | PathErr | PathErr | Reference | | Sub-code | Sub-code | PathErr | PathErr | Reference |
| value | Description | Code | Name | | | value | Description | Code | Name | |
+----------+--------------------+---------+---------+-----------+ +----------+--------------------+---------+---------+-----------+
| TBA by | Preferable P2MP-TE | 25 | Notify | This | | TBA by | Preferable P2MP-TE | 25 | Notify | This |
| IANA | Tree Exists | | Error | document | | IANA | Tree Exists | | Error | document |
+----------+--------------------+---------+---------+-----------+ +----------+--------------------+---------+---------+-----------+
6.3. BEGIN and END Markers For S2L sub-LSP Descriptor 6.3. Fragment Identifier For S2L sub-LSP Descriptor
IANA maintains a name space for RSVP protocol parameters "Resource IANA maintains a name space for RSVP protocol parameters "Resource
Reservation Protocol (RSVP) Parameters" (see Reservation Protocol (RSVP) Parameters" (see
http://www.iana.org/assignments/rsvp-parameters). From the http://www.iana.org/assignments/rsvp-parameters). From the
sub-registry "Class Types or C-Types 50 S2L_SUB_LSP" in registry sub-registry "Class Types or C-Types 50 S2L_SUB_LSP" in registry
"Class Names, Class Numbers, and Class Types", allocation of new "Class Names, Class Numbers, and Class Types", allocation of new
C-Types is requested (Section 4.3). C-Types is requested (Section 4.3).
As defined in [RFC4875], S2L_SUB_LSP Object is defined with As defined in [RFC4875], S2L_SUB_LSP Object is defined with
Class-Number 50 to identify a particular S2L sub-LSP belonging to the Class-Number 50 to identify a particular S2L sub-LSP belonging to the
P2MP-TE LSP. This document adds two new object types for this object P2MP-TE LSP. This document adds one new object type for this object
as follows: as follows:
o S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Object types: o S2L_SUB_LSP_FRAG Object type:
+---------------+---------------------------+-----------------+ +-----------------+---------------------------+-----------------+
| C-Type value | Description | Reference | | C-Type value | Description | Reference |
+---------------+---------------------------+-----------------+ +-----------------+---------------------------+-----------------+
| TBA by IANA | S2L_SUB_LSP_MARKER_BEGIN | This document | | TBA by IANA | S2L_SUB_LSP_FRAG | This document |
+---------------+---------------------------+-----------------+ +-----------------+---------------------------+-----------------+
| TBA by IANA | S2L_SUB_LSP_MARKER_END | This document |
+---------------+---------------------------+-----------------+
7. Security Considerations 7. Security Considerations
This document defines RSVP-TE signaling extensions to allow an This document defines RSVP-TE signaling extensions to allow an
ingress node of a P2MP-TE LSP to request the re-evaluation of the ingress node of a P2MP-TE LSP to request the re-evaluation of the
entire LSP tree, and for a mid-point LSR to notify the ingress node entire LSP tree, and for a mid-point LSR to notify the ingress node
of the existence of a preferable tree by sending a PathErr. As per of the existence of a preferable tree by sending a PathErr. As per
[RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning multiple [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning multiple
domains, it may be desirable for a mid-point LSR to modify the RSVP domains, it may be desirable for a mid-point LSR to modify the RSVP
PathErr message defined in this document to preserve confidentiality PathErr message defined in this document to preserve confidentiality
across domains. Furthermore, an ingress node may decide to ignore across domains. Furthermore, an ingress node may decide to ignore
this PathErr message coming from a mid-point LSR residing in another this PathErr message coming from a mid-point LSR residing in another
domain. Similarly, a mid-point LSR may decide to ignore the P2MP-TE domain. Similarly, a mid-point LSR may decide to ignore the P2MP-TE
tree re-evaluation request originating from another ingress domain. tree re-evaluation request originating from another ingress domain.
This document also defines markers to indicate beginning and end of This document also defines fragment identifier for the S2L sub-LSP
an S2L sub-LSP descriptor list when combining large number of S2L descriptor list when combining large number of S2L sub-LSPs in an
sub-LSPs in an RSVP message and the message needs to be fragmented. RSVP message and the message needs to be fragmented. The
The introduction of these markers, by themselves, introduce no introduction of the fragment identifier, by itself, introduce no
additional information to signaling. For a general discussions on additional information to signaling. For a general discussions on
MPLS and GMPLS related security issues, see the MPLS/GMPLS security MPLS and GMPLS related security issues, see the MPLS/GMPLS security
framework [RFC5920]. framework [RFC5920].
8. References 8. References
8.1. Normative References 8.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.
skipping to change at page 16, line 8 skipping to change at page 16, line 8
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. March 2009.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
Acknowledgments Acknowledgments
The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis
Villamizar, Dimitri Papadimitriou and Nobo Akiya for reviewing this Villamizar, Dimitri Papadimitriou, Nobo Akiya and Vishnu Pavan Beeram
document. The authors would also like to thank Ling Zeng for for reviewing this document. The authors would also like to thank
implementing mechanisms defined in this document. Ling Zeng for implementing mechanisms defined in this document.
Author's Addresses Author's Addresses
Tarek Saad (editor) Tarek Saad (editor)
Cisco Systems Cisco Systems
EMail: tsaad@cisco.com EMail: tsaad@cisco.com
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems Cisco Systems
 End of changes. 30 change blocks. 
78 lines changed or deleted 81 lines changed or added

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