draft-ietf-pce-pcep-domain-sequence-08.txt   draft-ietf-pce-pcep-domain-sequence-09.txt 
PCE Working Group D. Dhody PCE Working Group D. Dhody
Internet-Draft U. Palle Internet-Draft U. Palle
Intended status: Experimental Huawei Technologies Intended status: Experimental Huawei Technologies
Expires: November 1, 2015 R. Casellas Expires: March 23, 2016 R. Casellas
CTTC CTTC
April 30, 2015 September 20, 2015
Standard Representation of Domain-Sequence Standard Representation of Domain-Sequence
draft-ietf-pce-pcep-domain-sequence-08 draft-ietf-pce-pcep-domain-sequence-09
Abstract Abstract
The ability to compute shortest constrained Traffic Engineering Label The ability to compute shortest constrained Traffic Engineering Label
Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks across multiple domains has been Generalized MPLS (GMPLS) networks across multiple domains has been
identified as a key requirement. In this context, a domain is a identified as a key requirement. In this context, a domain is a
collection of network elements within a common sphere of address collection of network elements within a common sphere of address
management or path computational responsibility such as an Interior management or path computational responsibility such as an Interior
Gateway Protocol (IGP) area or an Autonomous System (AS). This Gateway Protocol (IGP) area or an Autonomous System (AS). This
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 November 1, 2015. This Internet-Draft will expire on March 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 33 skipping to change at page 2, line 33
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Detail Description . . . . . . . . . . . . . . . . . . . . . 6 3. Detail Description . . . . . . . . . . . . . . . . . . . . . 6
3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 6 3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 6
3.3. Domain-Sequence Representation . . . . . . . . . . . . . 7 3.3. Domain-Sequence Representation . . . . . . . . . . . . . 7
3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7 3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7
3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 8 3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 8
3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8 3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8
3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 8 3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Update in IRO specification . . . . . . . . . . . . . 10 3.4.2. Update in IRO specification . . . . . . . . . . . . . 10
3.4.3. IRO for Domain-Sequence . . . . . . . . . . . . . . . 10 3.4.3. IRO for Domain-Sequence . . . . . . . . . . . . . . . 10
3.4.3.1. PCC Procedures . . . . . . . . . . . . . . . . . 11
3.4.3.2. PCE Procedures . . . . . . . . . . . . . . . . . 11
3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 12 3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 12
3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 12 3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 12
3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 12 3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 13
3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 13 3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 13
3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 14 3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 15
3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 15 3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 15
4. Other Considerations . . . . . . . . . . . . . . . . . . . . 15 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 15 4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 16
4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 17 4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 18
4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 18 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 20 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 22 4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 23
4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . 23 4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . 24
4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 23 4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 24
4.7. Relationship to PCE Sequence . . . . . . . . . . . . . . 24
4.8. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 24
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 25
5.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 25 5.1. Relationship to PCE Sequence . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5.2. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 25
7. Manageability Considerations . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7.1. Control of Function and Policy . . . . . . . . . . . . . 25 6.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 26
7.2. Information and Data Models . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 26 8. Manageability Considerations . . . . . . . . . . . . . . . . 26
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 26 8.1. Control of Function and Policy . . . . . . . . . . . . . 26
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 26 8.2. Information and Data Models . . . . . . . . . . . . . . . 27
7.6. Impact On Network Operations . . . . . . . . . . . . . . 26 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 27
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . 27 8.6. Impact On Network Operations . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
A Path Computation Element (PCE) may be used to compute end-to-end A Path Computation Element (PCE) may be used to compute end-to-end
paths across multi-domain environments using a per-domain path paths across multi-domain environments using a per-domain path
computation technique [RFC5152]. The backward recursive path computation technique [RFC5152]. The backward recursive path
computation (BRPC) mechanism [RFC5441] also defines a PCE-based path computation (BRPC) mechanism [RFC5441] also defines a PCE-based path
computation procedure to compute inter-domain constrained path for computation procedure to compute inter-domain constrained path for
(G)MPLS TE LSPs. However, both per-domain and BRPC techniques assume (G)MPLS TE LSPs. However, both per-domain and BRPC techniques assume
that the sequence of domains to be crossed from source to destination that the sequence of domains to be crossed from source to destination
skipping to change at page 3, line 46 skipping to change at page 3, line 49
inter-domain path computation procedure. inter-domain path computation procedure.
The Domain-Sequence (the set of domains traversed to reach the The Domain-Sequence (the set of domains traversed to reach the
destination domain) is either administratively predetermined or destination domain) is either administratively predetermined or
discovered by some means like H-PCE. discovered by some means like H-PCE.
[RFC5440] defines the Include Route Object (IRO) and the Explicit [RFC5440] defines the Include Route Object (IRO) and the Explicit
Route Object (ERO). [RFC5521] defines the Exclude Route Object (XRO) Route Object (ERO). [RFC5521] defines the Exclude Route Object (XRO)
and the Explicit Exclusion Route Subobject (EXRS). The use of and the Explicit Exclusion Route Subobject (EXRS). The use of
Autonomous System (AS) (albeit with a 2-Byte AS number) as an Autonomous System (AS) (albeit with a 2-Byte AS number) as an
abstract node representing a domain is defined in [RFC3209], this abstract node representing a domain is defined in [RFC3209]. In the
document specifies new subobjects to include or exclude domains current document, we specify new subobjects to include or exclude
including IGP area or an Autonomous Systems (4-Byte as per domains including IGP area or an Autonomous Systems (4-Byte as per
[RFC6793]). [RFC6793]).
Further, the domain identifier may simply act as delimiter to specify Further, the domain identifier may simply act as delimiter to specify
where the domain boundary starts and ends in some cases. where the domain boundary starts and ends in some cases.
This document further illustrates how the new subobjects defined in
this document, along with the existing subobjects, are incorporated
in IRO, XRO and ERO to represent a Domain-Sequence.
This is a companion document to Resource ReserVation Protocol - This is a companion document to Resource ReserVation Protocol -
Traffic Engineering (RSVP-TE) extensions for the domain identifiers Traffic Engineering (RSVP-TE) extensions for the domain identifiers
[DOMAIN-SUBOBJ]. [DOMAIN-SUBOBJ].
1.1. Scope 1.1. Scope
The procedures described in this document are experimental. The The procedures described in this document are experimental. The
experiment is intended to enable research for the usage of Domain- experiment is intended to enable research for the usage of Domain-
Sequence at the PCEs for inter-domain paths. For this purpose this Sequence at the PCEs for inter-domain paths. For this purpose this
document specify new domain subobjects as well as how they document specifies new domain subobjects as well as how they
incorporate with existing subobjects to represent a Domain-Sequence. incorporate with existing subobjects to represent a Domain-Sequence.
This document does not change the procedures for handling existing This document does not change the procedures for handling existing
subobjects in PCEP. subobjects in PCEP.
The new subobjects introduced by this document will not be understood The new subobjects introduced by this document will not be understood
by a legacy implementation. If one of the subobjects is received in by a legacy implementation. If one of the subobjects is received in
a PCEP object that does not understand it, it will behave as a PCEP object that does not understand it, it will behave as
described in Section 3.4.3. Therefore, it is assumed that this described in Section 3.4.3. Therefore, it is assumed that this
experiment will be conducted only when both the PCE and the PCC form experiment will be conducted only when both the PCE and the PCC form
skipping to change at page 7, line 13 skipping to change at page 7, line 13
well as the existing subobjects to represent a Domain-Sequence. well as the existing subobjects to represent a Domain-Sequence.
Consequently, a Domain-Sequence can be used: Consequently, a Domain-Sequence can be used:
1. by a PCE in order to discover or select the next PCE in a 1. by a PCE in order to discover or select the next PCE in a
collaborative path computation, such as in BRPC [RFC5441]; collaborative path computation, such as in BRPC [RFC5441];
2. by the Parent PCE to return the Domain-Sequence when unknown; 2. by the Parent PCE to return the Domain-Sequence when unknown;
this can then be an input to the BRPC procedure [RFC6805]; this can then be an input to the BRPC procedure [RFC6805];
3. by a Path Computation Client (PCC) or a PCE, to constraint the 3. by a Path Computation Client (PCC) or a PCE, to constrain the
domains used in inter-domain path computation, explicitly domains used in inter-domain path computation, explicitly
specifying which domains to be expanded or excluded; specifying which domains to be expanded or excluded;
4. by a PCE in the per-domain path computation model [RFC5152] to 4. by a PCE in the per-domain path computation model [RFC5152] to
identify the next domain; identify the next domain.
3.3. Domain-Sequence Representation 3.3. Domain-Sequence Representation
Domain-Sequence appears in PCEP messages, notably in - Domain-Sequence appears in PCEP messages, notably in -
o Include Route Object (IRO): As per [RFC5440], IRO can be used to o Include Route Object (IRO): As per [RFC5440], IRO can be used to
specify a set of network elements to be traversed to reach the specify a set of network elements to be traversed to reach the
destination, which includes subobjects used to specify the Domain- destination, which includes subobjects used to specify the Domain-
Sequence. Sequence.
skipping to change at page 8, line 18 skipping to change at page 8, line 18
[RFC4874], but new subobjects related to Domain-Sequence are needed. [RFC4874], but new subobjects related to Domain-Sequence are needed.
This document extends the support for 4-Byte AS numbers and IGP This document extends the support for 4-Byte AS numbers and IGP
Areas. Areas.
Type Subobject Type Subobject
TBD1 Autonomous system number (4 Byte) TBD1 Autonomous system number (4 Byte)
TBD2 OSPF Area id TBD2 OSPF Area id
TBD3 ISIS Area id TBD3 ISIS Area id
Note: The twins of these subobjects are carried in RSVP-TE messages
as defined in [DOMAIN-SUBOBJ].
3.4.1.1. Autonomous system 3.4.1.1. Autonomous system
[RFC3209] already defines 2 byte AS number. [RFC3209] already defines 2 byte AS number.
To support 4 byte AS number as per [RFC6793] following subobject is To support 4 byte AS number as per [RFC6793] following subobject is
defined: defined:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 50 skipping to change at page 10, line 6
L: The L bit is an attribute of the subobject as defined in [RFC3209] L: The L bit is an attribute of the subobject as defined in [RFC3209]
and usage in IRO subobject updated in [IRO-UPDATE]. and usage in IRO subobject updated in [IRO-UPDATE].
Type: (TBD3 by IANA) indicating IS-IS Area ID. Type: (TBD3 by IANA) indicating IS-IS Area ID.
Length: Variable. The Length MUST be at least 8, and MUST be a Length: Variable. The Length MUST be at least 8, and MUST be a
multiple of 4. multiple of 4.
Area-Len: Variable (Length of the actual (non-padded) IS-IS Area Area-Len: Variable (Length of the actual (non-padded) IS-IS Area
Identifier in octets; Valid values are from 2 to 11 inclusive). Identifier in octets; Valid values are from 1 to 13 inclusive).
Reserved: Zero at transmission, ignored at receipt. Reserved: Zero at transmission, ignored at receipt.
IS-IS Area Id: The variable-length IS-IS area identifier. Padded IS-IS Area Id: The variable-length IS-IS area identifier. Padded
with trailing zeroes to a four-byte boundary. with trailing zeroes to a four-byte boundary.
3.4.2. Update in IRO specification 3.4.2. Update in IRO specification
[RFC5440] describes IRO as an optional object used to specify network [RFC5440] describes IRO as an optional object used to specify network
elements to be traversed by the computed path. It further state that elements to be traversed by the computed path. It further state that
skipping to change at page 10, line 24 skipping to change at page 10, line 29
subobjects. subobjects.
An update to IRO specification [IRO-UPDATE] makes IRO as an ordered An update to IRO specification [IRO-UPDATE] makes IRO as an ordered
list, as well as support for loose bit (L-bit) is added. list, as well as support for loose bit (L-bit) is added.
The use of IRO for Domain-Sequence, assumes the updated specification The use of IRO for Domain-Sequence, assumes the updated specification
for IRO, as per [IRO-UPDATE]. for IRO, as per [IRO-UPDATE].
3.4.3. IRO for Domain-Sequence 3.4.3. IRO for Domain-Sequence
Some subobjects for the IRO are defined in [RFC3209], [RFC3477], and
[RFC4874]; further some new subobjects related to Domain-Sequence are
also added in this document as mentioned in Section 3.4.
The subobject type for IPv4, IPv6, and unnumbered Interface ID can be The subobject type for IPv4, IPv6, and unnumbered Interface ID can be
used to specify Boundary Nodes (ABR/ASBR) and Inter-AS-Links. The used to specify Boundary Nodes (ABR/ASBR) and Inter-AS-Links. The
subobject type for the AS Number (2 or 4 Byte) and the IGP Area are subobject type for the AS Number (2 or 4 Byte) and the IGP Area are
used to specify the domain identifiers in the Domain-Sequence. used to specify the domain identifiers in the Domain-Sequence.
The IRO can incorporate the new domain subobjects with the existing The IRO can incorporate the new domain subobjects with the existing
subobjects in a sequence of traversal. subobjects in a sequence of traversal.
Thus an IRO, comprising of subobjects that represents a Domain- Thus an IRO, comprising subobjects, that represents a Domain-
Sequence, define the domains involved in an inter-domain path Sequence, define the domains involved in an inter-domain path
computation, typically involving two or more collaborative PCEs. computation, typically involving two or more collaborative PCEs.
A Domain-Sequence can have varying degrees of granularity. It is A Domain-Sequence can have varying degrees of granularity. It is
possible to have a Domain-Sequence composed of, uniquely, AS possible to have a Domain-Sequence composed of, uniquely, AS
identifiers. It is also possible to list the involved IGP areas for identifiers. It is also possible to list the involved IGP areas for
a given AS. a given AS.
In any case, the mapping between domains and responsible PCEs is not In any case, the mapping between domains and responsible PCEs is not
defined in this document. It is assumed that a PCE that needs to defined in this document. It is assumed that a PCE that needs to
obtain a "next PCE" from a Domain-Sequence is able to do so (e.g. via obtain a "next PCE" from a Domain-Sequence is able to do so (e.g. via
administrative configuration, or discovery). administrative configuration, or discovery).
3.4.3.1. PCC Procedures
A PCC builds an IRO to encode the Domain-Sequence, so that the A PCC builds an IRO to encode the Domain-Sequence, so that the
cooperating PCEs could compute an inter-domain shortest constrained cooperating PCEs could compute an inter-domain shortest constrained
path across the specified sequence of domains. path across the specified sequence of domains.
For each inclusion, the PCC clears the L-bit to indicate that the PCE A PCC may intersperse Area and AS subobjects with other subobjects
is required to include the domain, or sets the L-bit to indicate that without change to the previously specified processing of those
the PCC simply desires that the domain be included in the Domain- subobjects in the IRO.
Sequence.
3.4.3.2. PCE Procedures
If a PCE receives an IRO in a Path Computation request (PCReq) If a PCE receives an IRO in a Path Computation request (PCReq)
message that contains subobjects defined in this document, that it message that contains the subobjects defined in this document, that
does not recognize, it will respond according to the rules for a it does not recognize, it will respond according to the rules for a
malformed object as per [RFC5440]. The PCE MAY also include the IRO malformed object as per [RFC5440]. The PCE MAY also include the IRO
in the PCErr to indicate in which case the IRO SHOULD be terminated in the PCErr message as per [RFC5440].
immediately after the unrecognized subobject.
PCE MUST act according to the requirements expressed in the The interpretation of Loose bit (L bit) is as per section 4.3.3.1 of
subobject. That is, if the L-bit is clear, the PCE(s) MUST produce a [RFC3209] (as per [IRO-UPDATE]).
path that follows the Domain-Sequence in order identified by the
subobjects in the path. If the L-bit is set, the PCE(s) SHOULD
produce a path along the Domain-Sequence unless it is not possible to
construct a path complying with the other constraints expressed in
the request.
A successful path computation reported in a path computation reply In a Path Computation reply (PCRep), PCE MAY also supply IRO (with
message (PCRep) MUST include an ERO to specify the path that has been Domain-Sequence information) with the NO-PATH object indicating that
computed as specified in [RFC5440] following the sequence of domains. the set of elements (domains) of the request's IRO prevented the PCEs
from finding a path.
In a PCRep, PCE MAY also supply IRO (with Domain-Sequence The following processing rules apply for Domain-Sequence in IRO -
information) with the NO-PATH object indicating that the set of
elements (domains) of the request's IRO prevented the PCEs from
finding a path.
Following processing rules apply for Domain-Sequence in IRO - o When a PCE parses an IRO, it interprets each subobject according
to the AS number associated with the preceding subobject. We call
this the "current AS". Certain subobjects modify the current AS,
as follows.
o The Area subobject is optional. * The current AS is initialized to the AS number of the PCC.
o The AS subobject is optional. * If the PCE encounters an AS subobject, then it updates the
current AS to this new AS number.
o If an Area subobject is present then it changes the Area for all * If the PCE encounters an Area subobject, then it assumes that
subsequent subobjects that do not change the area themselves. the area belongs to the current AS.
Subobjects that may change the Area are:
* IP addresses that are present in another Area (via IPv4/IPv6 * If the PCE encounters an IP address that is globally routable,
subobject) then it updates the current AS to the AS that owns this IP
address. This document does not define how the PCE learns
which AS owns the IP address.
* Area ID (via OSPF/ISIS area subobjects) * If the PCE encounters an IP address that is not globally
routable, then it assumes that it belongs to the current AS.
* AS number of another AS (via AS subobjects) * If the PCE encounters an unnumbered link, then it assumes that
it belongs to the current AS.
o If an Area subobject is not preceded by an AS subobject then the o When a PCE parses an IRO, it interprets each subobject according
receiver MUST act as though there is no change in AS from the to the Area ID associated with the preceding subobject. We call
previous subobject. this the "current Area". Certain subobjects modify the current
Area, as follows.
o If an AS subobject is present then it changes the AS for all * The current Area is initialized to the Area ID of the PCC.
subsequent subobjects that do not change the AS themselves.
Subobjects that may change the AS are:
* IP addresses that are present in another AS (via IPv4/IPv6 * If the current AS is changed, the current Area is reset and
subobject) need to be determined again by current or subsequent subobject.
* Unnumbered interfaces that are present in another AS (via * If the PCE encounters an Area subobject, then it updates the
Unnumbered Interface ID subobject) current Area to this new Area ID.
* AS number (via AS subobjects) * If the PCE encounters an IP address that belongs to a different
area, then it updates the current Area to the Area that has
this IP address. This document does not define how the PCE
learns which Area has the IP address.
o AS and Area subobjects may be interspersed with other subobjects * If the PCE encounters an unnumbered link that belongs to a
without change to the previously specified processing of those different area, then it updates the current Area to the Area
subobjects in the IRO. that has this link.
* Otherwise, it assumes that the subobject belongs to the current
Area.
o In case the current PCE is not responsible for the path
computation in the current AS or Area, then the PCE selects the
"next PCE" in the domain-sequence based on the current AS and
Area.
3.5. Exclude Route Object (XRO) 3.5. Exclude Route Object (XRO)
The Exclude Route Object (XRO) [RFC5521] is an optional object used The Exclude Route Object (XRO) [RFC5521] is an optional object used
to specify exclusion of certain abstract nodes or resources from the to specify exclusion of certain abstract nodes or resources from the
whole path. whole path.
3.5.1. Subobjects 3.5.1. Subobjects
Some subobjects to be used in XRO as defined in [RFC3209], [RFC3477], Some subobjects to be used in XRO as defined in [RFC3209], [RFC3477],
skipping to change at page 12, line 45 skipping to change at page 13, line 10
Sequence are needed. Sequence are needed.
This document extends the support for 4-Byte AS numbers and IGP This document extends the support for 4-Byte AS numbers and IGP
Areas. Areas.
Type Subobject Type Subobject
TBD1 Autonomous system number (4 Byte) TBD1 Autonomous system number (4 Byte)
TBD2 OSPF Area id TBD2 OSPF Area id
TBD3 ISIS Area id TBD3 ISIS Area id
Note: The twins of these subobjects are carried in RSVP-TE messages
as defined in [DOMAIN-SUBOBJ].
3.5.1.1. Autonomous system 3.5.1.1. Autonomous system
The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area The new subobjects to support 4 byte AS and IGP (OSPF / ISIS) Area
MAY also be used in the XRO to specify exclusion of certain domains MAY also be used in the XRO to specify exclusion of certain domains
in the path computation procedure. in the path computation procedure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type | Length | Reserved | |X| Type | Length | Reserved |
skipping to change at page 14, line 36 skipping to change at page 15, line 8
subject to PCE policy and the absence of a viable path that meets subject to PCE policy and the absence of a viable path that meets
the other constraints. the other constraints.
All other fields are consistent with the definition in Section 3.4. All other fields are consistent with the definition in Section 3.4.
All the processing rules are as per [RFC5521]. All the processing rules are as per [RFC5521].
Note that, if a PCE receives an XRO in a PCReq message that contains Note that, if a PCE receives an XRO in a PCReq message that contains
subobjects defined in this document, that it does not recognize, it subobjects defined in this document, that it does not recognize, it
will respond according to the rules for a malformed object as per will respond according to the rules for a malformed object as per
[RFC5440]. The PCE MAY also include the XRO in the PCErr to indicate [RFC5440].
in which case the XRO SHOULD be terminated immediately after the
unrecognized subobject.
3.6. Explicit Exclusion Route Subobject (EXRS) 3.6. Explicit Exclusion Route Subobject (EXRS)
Explicit Exclusion Route Subobject (EXRS) [RFC5521] is used to Explicit Exclusion Route Subobject (EXRS) [RFC5521] is used to
specify exclusion of certain abstract nodes between a specific pair specify exclusion of certain abstract nodes between a specific pair
of nodes. of nodes.
The EXRS subobject can carry any of the subobjects defined for The EXRS subobject can carry any of the subobjects defined for
inclusion in the XRO, thus the new subobjects to support 4 byte AS inclusion in the XRO, thus the new subobjects to support 4 byte AS
and IGP (OSPF / ISIS) Area can also be used in the EXRS. The and IGP (OSPF / ISIS) Area can also be used in the EXRS. The
meanings of the fields of the new XRO subobjects are unchanged when meanings of the fields of the new XRO subobjects are unchanged when
the subobjects are included in an EXRS, except that scope of the the subobjects are included in an EXRS, except that scope of the
exclusion is limited to the single hop between the previous and exclusion is limited to the single hop between the previous and
subsequent elements in the IRO. subsequent elements in the IRO.
All the processing rules are as per [RFC5521]. The EXRS subobject should be interpreted in the context of the
current AS and current Area of the preceding subobject in the IRO.
The EXRS subobject does not change the current AS or current Area.
All other processing rules are as per [RFC5521].
Note that, if a PCE that supports the EXRS in an IRO, parses an IRO, Note that, if a PCE that supports the EXRS in an IRO, parses an IRO,
and encounters an EXRS that contains subobjects defined in this and encounters an EXRS that contains subobjects defined in this
document, that it does not recognize, it will act according to the document, that it does not recognize, it will act according to the
setting of the X-bit in the subobject as per [RFC5521]. setting of the X-bit in the subobject as per [RFC5521].
3.7. Explicit Route Object (ERO) 3.7. Explicit Route Object (ERO)
The Explicit Route Object (ERO) [RFC5440] is used to specify a The Explicit Route Object (ERO) [RFC5440] is used to specify a
computed path in the network. PCEP ERO subobject types correspond to computed path in the network. PCEP ERO subobject types correspond to
skipping to change at page 15, line 31 skipping to change at page 16, line 5
can also be used in the ERO to specify an abstract node (a group of can also be used in the ERO to specify an abstract node (a group of
nodes whose internal topology is opaque to the ingress node of the nodes whose internal topology is opaque to the ingress node of the
LSP). Using this concept of abstraction, an explicitly routed LSP LSP). Using this concept of abstraction, an explicitly routed LSP
can be specified as a sequence of domains. can be specified as a sequence of domains.
In case of Hierarchical PCE [RFC6805], a Parent PCE can be requested In case of Hierarchical PCE [RFC6805], a Parent PCE can be requested
to find the Domain-Sequence. Refer example in Section 4.6. The ERO to find the Domain-Sequence. Refer example in Section 4.6. The ERO
in reply from parent PCE can then be used in Per-Domain path in reply from parent PCE can then be used in Per-Domain path
computation or BRPC. computation or BRPC.
If a PCC receives an ERO in a Path Computation response (PCRep) If a PCC receives an ERO in a PCRep message that contains subobject
message that contains subobject defined in this document, that it defined in this document, that it does not recognize, it will respond
does not recognize, it will respond according to the rules for a according to the rules for a malformed object as per [RFC5440].
malformed object as per [RFC5440]. The PCC MAY also include the ERO
in the PCErr to indicate in which case the ERO SHOULD be terminated
immediately after the unrecognized subobject.
4. Other Considerations 4. Examples
The examples in this section are for illustration purposes only; to The examples in this section are for illustration purposes only; to
highlight how the new subobjects could be encoded. They are not highlight how the new subobjects could be encoded. They are not
meant to be an exhaustive list of all possible usecases and meant to be an exhaustive list of all possible usecases and
combinations. combinations.
4.1. Inter-Area Path Computation 4.1. Inter-Area Path Computation
In an inter-area path computation where the ingress and the egress In an inter-area path computation where the ingress and the egress
nodes belong to different IGP areas within the same AS, the Domain- nodes belong to different IGP areas within the same AS, the Domain-
skipping to change at page 24, line 23 skipping to change at page 25, line 23
or or
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|ERO | |Sub | |Sub | |ERO | |Sub | |Sub |
|Object | |Object | |Object | |Object | |Object | |Object |
|Header | |BN 21 | |Domain 3 | |Header | |BN 21 | |Domain 3 |
| | | | | | | | | | | |
| | | | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
4.7. Relationship to PCE Sequence 5. Other Considerations
5.1. Relationship to PCE Sequence
Instead of a Domain-Sequence, a sequence of PCEs MAY be enforced by Instead of a Domain-Sequence, a sequence of PCEs MAY be enforced by
policy on the PCC, and this constraint can be carried in the PCReq policy on the PCC, and this constraint can be carried in the PCReq
message (as defined in [RFC5886]). message (as defined in [RFC5886]).
Note that PCE-Sequence can be used along with Domain-Sequence in Note that PCE-Sequence can be used along with Domain-Sequence in
which case PCE-Sequence MUST have higher precedence in selecting the which case PCE-Sequence MUST have higher precedence in selecting the
next PCE in the inter-domain path computation procedures. next PCE in the inter-domain path computation procedures.
4.8. Relationship to RSVP-TE 5.2. Relationship to RSVP-TE
[RFC3209] already describes the notion of abstract nodes, where an [RFC3209] already describes the notion of abstract nodes, where an
abstract node is a group of nodes whose internal topology is opaque abstract node is a group of nodes whose internal topology is opaque
to the ingress node of the LSP. It further defines a subobject for to the ingress node of the LSP. It further defines a subobject for
AS but with a 2-Byte AS Number. AS but with a 2-Byte AS Number.
[DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new
subobjects for IGP Areas and 4-byte AS numbers. These subobjects can subobjects for IGP Areas and 4-byte AS numbers. These subobjects can
be included in Explicit Route Object (ERO), Exclude Route object be included in Explicit Route Object (ERO), Exclude Route object
(XRO) or Explicit Exclusion Route Subobject (EXRS) in RSVP-TE. (XRO) or Explicit Exclusion Route Subobject (EXRS) in RSVP-TE.
In any case subobject type defined in RSVP-TE are identical to the In any case subobject type defined in RSVP-TE are identical to the
subobject type defined in the related documents in PCEP. subobject type defined in the related documents in PCEP.
5. IANA Considerations 6. IANA Considerations
5.1. New Subobjects 6.1. New Subobjects
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
at http://www.iana.org/assignments/pcep/pcep.xhtml. Within this at http://www.iana.org/assignments/pcep/pcep.xhtml. Within this
registry IANA maintains two sub-registries: registry IANA maintains two sub-registries:
o "IRO Subobjects": http://www.iana.org/assignments/pcep/ o "IRO Subobjects": http://www.iana.org/assignments/pcep/
pcep.xhtml#iro-subobject pcep.xhtml#iro-subobject
o "XRO Subobjects": http://www.iana.org/assignments/pcep/ o "XRO Subobjects": http://www.iana.org/assignments/pcep/
pcep.xhtml#xro-subobject pcep.xhtml#xro-subobject
Upon approval of this document, IANA is requested to make identical Upon approval of this document, IANA is requested to make identical
additions to these registries as follows: additions to these registries as follows:
Subobject Type Reference Subobject Type Reference
TBD1 4 byte AS number [This I.D.] TBD1 4 byte AS number [This I.D.][DOMAIN-SUBOBJ]
TBD2 OSPF Area ID [This I.D.] TBD2 OSPF Area ID [This I.D.][DOMAIN-SUBOBJ]
TBD3 IS-IS Area ID [This I.D.] TBD3 IS-IS Area ID [This I.D.][DOMAIN-SUBOBJ]
6. Security Considerations 7. Security Considerations
This document specifies a standard representation of Domain-Sequence This document specifies a standard representation of Domain-Sequence
and new subobjects, which could be used in inter-domain PCE scenarios and new subobjects, which could be used in inter-domain PCE scenarios
as explained in other RFC and drafts. The new subobjects and Domain- as explained in other RFC and drafts. The new subobjects and Domain-
Sequence mechanisms defined in this document allow finer and more Sequence mechanisms defined in this document allow finer and more
specific control of the path computed by a cooperating PCE(s). Such specific control of the path computed by a cooperating PCE(s). Such
control increases the risk if a PCEP message is intercepted, control increases the risk if a PCEP message is intercepted,
modified, or spoofed because it allows the attacker to exert control modified, or spoofed because it allows the attacker to exert control
over the path that the PCE will compute or to make the path over the path that the PCE will compute or to make the path
computation impossible. Therefore, the security techniques described computation impossible. Therefore, the security techniques described
in [RFC5440] are considered more important. in [RFC5440] are considered more important.
Note, however, that the Domain-Sequence mechanisms also provide the Note, however, that the Domain-Sequence mechanisms also provide the
operator with the ability to route around vulnerable parts of the operator with the ability to route around vulnerable parts of the
network and may be used to increase overall network security. network and may be used to increase overall network security.
7. Manageability Considerations 8. Manageability Considerations
7.1. Control of Function and Policy 8.1. Control of Function and Policy
The exact behaviour with regards to desired inclusion and exclusion The exact behaviour with regards to desired inclusion and exclusion
of domains MUST be available for examination by an operator and MAY of domains MUST be available for examination by an operator and MAY
be configurable. Manual configurations is needed to identify which be configurable. Manual configurations is needed to identify which
PCEP peers understand the new domain subobjects defined in this PCEP peers understand the new domain subobjects defined in this
document. document.
7.2. Information and Data Models 8.2. Information and Data Models
A MIB module for management of the PCEP is being specified in a A MIB module for management of the PCEP is being specified in a
separate document [RFC7420]. That MIB module allows examination of separate document [RFC7420]. This document does not imply any new
individual PCEP messages, in particular requests, responses and extention to the current MIB module.
errors. The MIB module MUST be extended to include the ability to
view the Domain-Sequence extensions defined in this document.
7.3. Liveness Detection and Monitoring 8.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in [RFC5440]. listed in [RFC5440].
7.4. Verify Correct Operations 8.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in verification requirements in addition to those already listed in
[RFC5440]. [RFC5440].
7.5. Requirements On Other Protocols 8.5. Requirements On Other Protocols
In case of per-domain path computation [RFC5152], where the full path In case of per-domain path computation [RFC5152], where the full path
of an inter-domain TE LSP cannot be, or is not determined at the of an inter-domain TE LSP cannot be, or is not determined at the
ingress node, a signaling message may use the domain identifiers. ingress node, a signaling message can use the domain identifiers.
The Subobjects defined in this document SHOULD be supported by RSVP- The Subobjects defined in this document SHOULD be supported by RSVP-
TE. [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding TE. [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding
new subobjects for IGP Areas and 4-byte AS numbers. new subobjects for IGP Areas and 4-byte AS numbers.
Apart from this, mechanisms defined in this document do not imply any Apart from this, mechanisms defined in this document do not imply any
requirements on other protocols in addition to those already listed requirements on other protocols in addition to those already listed
in [RFC5440]. in [RFC5440].
7.6. Impact On Network Operations 8.6. Impact On Network Operations
The mechanisms described in this document can provide the operator The mechanisms described in this document can provide the operator
with the ability to exert finer and more specific control of the path with the ability to exert finer and more specific control of the path
computation by inclusion or exclusion of domain subobjects. There computation by inclusion or exclusion of domain subobjects. There
may be some scaling benefit when a single domain subobject may may be some scaling benefit when a single domain subobject may
substitute for many subobjects and can reduce the overall message substitute for many subobjects and can reduce the overall message
size and processing. size and processing.
Backward compatibility issues associated with the new subobjects Backward compatibility issues associated with the new subobjects
arise when a PCE does not recognize them, in which case PCE responds arise when a PCE does not recognize them, in which case PCE responds
according to the rules for a malformed object as per [RFC5440]. For according to the rules for a malformed object as per [RFC5440]. For
successful operations the PCEs in the network would need to be successful operations the PCEs in the network would need to be
upgraded. upgraded.
8. Acknowledgments 9. Acknowledgments
Authors would like to especially thank Adrian Farrel for his detailed Authors would like to especially thank Adrian Farrel for his detailed
reviews as well as providing text to be included in the document. reviews as well as providing text to be included in the document.
Further, we would like to thank Pradeep Shastry, Suresh Babu, Quintin Further, we would like to thank Pradeep Shastry, Suresh Babu, Quintin
Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo,
Venugopal Reddy, Reeja Paul, Sandeep Boina, Avantika and Sergio Venugopal Reddy, Reeja Paul, Sandeep Boina, Avantika Sergio Belotti
Belotti for their useful comments and suggestions. and Jonathan Hardwick for their useful comments and suggestions.
9. References 10. References
9.1. Normative References 10.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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling Resource ReserVation Protocol-
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
<http://www.rfc-editor.org/info/rfc3477>.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
(PCE) Communication Protocol (PCEP)", RFC 5440, March Element (PCE) Communication Protocol (PCEP)", RFC 5440,
2009. DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
Backward-Recursive PCE-Based Computation (BRPC) Procedure "A Backward-Recursive PCE-Based Computation (BRPC)
to Compute Shortest Constrained Inter-Domain Traffic Procedure to Compute Shortest Constrained Inter-Domain
Engineering Label Switched Paths", RFC 5441, April 2009. Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<http://www.rfc-editor.org/info/rfc5441>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, April 2009. Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
2009, <http://www.rfc-editor.org/info/rfc5521>.
[RFC6805] King, D. and A. Farrel, "The Application of the Path [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Computation Element Architecture to the Determination of a Path Computation Element Architecture to the Determination
Sequence of Domains in MPLS and GMPLS", RFC 6805, November of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
2012. DOI 10.17487/RFC6805, November 2012,
<http://www.rfc-editor.org/info/rfc6805>.
[ISO10589] [ISO10589]
ISO, "Intermediate system to Intermediate system routing ISO, "Intermediate system to Intermediate system routing
information exchange protocol for use in conjunction with information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode Network the Protocol for providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002, 1992. Service (ISO 8473)", ISO/IEC 10589:2002, 1992.
[IRO-UPDATE] [IRO-UPDATE]
Dhody, D., "Update to Include Route Object (IRO) Dhody, D., "Update to Include Route Object (IRO)
specification in Path Computation Element communication specification in Path Computation Element communication
Protocol (PCEP. (draft-dhody-pce-iro-update-02)", December Protocol (PCEP. (draft-ietf-pce-iro-update-02)", May 2015.
2014.
[DOMAIN-SUBOBJ] [DOMAIN-SUBOBJ]
Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, Dhody, D., Palle, U., Kondreddy, V., and R. Casellas,
"Domain Subobjects for Resource ReserVation Protocol - "Domain Subobjects for Resource ReserVation Protocol -
Traffic Engineering (RSVP-TE). (draft-ietf-teas-rsvp-te- Traffic Engineering (RSVP-TE). (draft-ietf-teas-rsvp-te-
domain-subobjects-00)", April 2015. domain-subobjects-02)", July 2015.
9.2. Informative References 10.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
Inter-Domain Multiprotocol Label Switching Traffic Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, DOI 10.17487/RFC4726, November
2006, <http://www.rfc-editor.org/info/rfc4726>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007. "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
May 2007, <http://www.rfc-editor.org/info/rfc4873>.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007. Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874,
April 2007, <http://www.rfc-editor.org/info/rfc4874>.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Path Computation Method for Establishing Inter-Domain Per-Domain Path Computation Method for Establishing Inter-
Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC Domain Traffic Engineering (TE) Label Switched Paths
5152, February 2008. (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
<http://www.rfc-editor.org/info/rfc5152>.
[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
Topology Confidentiality in Inter-Domain Path Computation "Preserving Topology Confidentiality in Inter-Domain Path
Using a Path-Key-Based Mechanism", RFC 5520, April 2009. Computation Using a Path-Key-Based Mechanism", RFC 5520,
DOI 10.17487/RFC5520, April 2009,
<http://www.rfc-editor.org/info/rfc5520>.
[RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path Computation Element (PCE)-Based Monitoring Tools for Path Computation Element (PCE)-Based
Architecture", RFC 5886, June 2010. Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
<http://www.rfc-editor.org/info/rfc5886>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, December Autonomous System (AS) Number Space", RFC 6793,
2012. DOI 10.17487/RFC6793, December 2012,
<http://www.rfc-editor.org/info/rfc6793>.
[RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, [RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas,
"PCE-Based Computation Procedure to Compute Shortest "PCE-Based Computation Procedure to Compute Shortest
Constrained Point-to-Multipoint (P2MP) Inter-Domain Constrained Point-to-Multipoint (P2MP) Inter-Domain
Traffic Engineering Label Switched Paths", RFC 7334, Traffic Engineering Label Switched Paths", RFC 7334,
August 2014. DOI 10.17487/RFC7334, August 2014,
<http://www.rfc-editor.org/info/rfc7334>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", RFC (PCEP) Management Information Base (MIB) Module",
7420, December 2014. RFC 7420, DOI 10.17487/RFC7420, December 2014,
<http://www.rfc-editor.org/info/rfc7420>.
Authors' Addresses Authors' Addresses
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560037 Bangalore, Karnataka 560037
India India
EMail: dhruv.ietf@gmail.com EMail: dhruv.ietf@gmail.com
 End of changes. 85 change blocks. 
172 lines changed or deleted 205 lines changed or added

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