draft-ietf-pce-pcep-domain-sequence-01.txt   draft-ietf-pce-pcep-domain-sequence-02.txt 
PCE Working Group D. Dhody PCE Working Group D. Dhody
Internet-Draft U. Palle Internet-Draft U. Palle
Intended status: Experimental Huawei Technologies India Pvt Intended status: Experimental Huawei Technologies India Pvt
Expires: January 6, 2013 Ltd Expires: August 5, 2013 Ltd
R. Casellas R. Casellas
CTTC - Centre Tecnologic de CTTC - Centre Tecnologic de
Telecomunicacions de Catalunya Telecomunicacions de Catalunya
July 5, 2012 Feb 2013
Standard Representation Of Domain Sequence Standard Representation Of Domain-Sequence
draft-ietf-pce-pcep-domain-sequence-01 draft-ietf-pce-pcep-domain-sequence-02
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 for P2P and P2MP scenarios. In this identified as a key requirement for P2P and P2MP scenarios. In this
context, a domain is a collection of network elements within a common context, a domain is a collection of network elements within a common
sphere of address management or path computational responsibility sphere of address management or path computational responsibility
such as an IGP area or an Autonomous Systems. This document such as an IGP area or an Autonomous Systems. This document
specifies a standard representation and encoding of a domain specifies a standard representation and encoding of a Domain-
sequence, which is defined as an ordered sequence of domains Sequence, which is defined as an ordered sequence of domains
traversed to reach the destination domain. This document also traversed to reach the destination domain. This document also
defines new sub-objects to be used to encode domain identifiers. defines new subobjects to be used to encode domain identifiers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2013. This Internet-Draft will expire on August 5, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
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. Standard Representation . . . . . . . . . . . . . . . . . 7 3.3. Standard Representation . . . . . . . . . . . . . . . . . 7
3.3.1. New Sub-Objects . . . . . . . . . . . . . . . . . . . 7 3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . . 8
3.3.1.1. Autonomous system . . . . . . . . . . . . . . . . 7 3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . . 8 3.4.2. Option (A): New IRO Object Type . . . . . . . . . . . 10
3.3.2. Use in PCEP Objects . . . . . . . . . . . . . . . . . 9 3.4.2.1. Handling of the Domain-Sequence IRO object . . . . 11
3.3.2.1. Include Route Object . . . . . . . . . . . . . . . 9 3.4.3. Option B: Existing IRO Object Type . . . . . . . . . . 13
3.3.2.2. Exclude Route Object . . . . . . . . . . . . . . . 13 3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . . 14
3.3.2.3. Explicit Route Object . . . . . . . . . . . . . . 15 3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2.4. Explicit Exclusion Route Sub-Object . . . . . . . 16 3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 14
3.4. Other Considerations . . . . . . . . . . . . . . . . . . . 16 3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . . 15
3.4.1. Inter-Area Path Computation . . . . . . . . . . . . . 16 3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 16
3.4.2. Inter-AS Path Computation . . . . . . . . . . . . . . 18 3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 17
3.4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . 18 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 18
3.4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . 20 4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 18
3.4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . 22 4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 20
3.4.4. PCE serving multiple domains . . . . . . . . . . . . . 23 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 20
3.4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22
3.4.6. HPCE . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 24
3.4.7. Relationship to PCE Sequence . . . . . . . . . . . . . 25 4.4. PCE serving multiple domains . . . . . . . . . . . . . . . 25
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 25 4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . . 25
4.2. New Sub-Objects . . . . . . . . . . . . . . . . . . . . . 26 4.7. Relationship to PCE Sequence . . . . . . . . . . . . . . . 27
4.3. Error Object Field Values . . . . . . . . . . . . . . . . 26 4.8. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6. Manageability Considerations . . . . . . . . . . . . . . . . . 27 5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Control of Function and Policy . . . . . . . . . . . . . . 27 5.2. New Subobjects . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Information and Data Models . . . . . . . . . . . . . . . 27 5.3. Error Object Field Values . . . . . . . . . . . . . . . . 28
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 27 7. Manageability Considerations . . . . . . . . . . . . . . . . . 29
6.5. Requirements On Other Protocols . . . . . . . . . . . . . 27 7.1. Control of Function and Policy . . . . . . . . . . . . . . 29
6.6. Impact On Network Operations . . . . . . . . . . . . . . . 28 7.2. Information and Data Models . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . . 28 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 30
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
A PCE may be used to compute end-to-end paths across multi-domain A PCE may be used to compute end-to-end paths across multi-domain
environments using a per-domain path computation technique [RFC5152]. environments using a per-domain path computation technique [RFC5152].
The so called backward recursive path computation (BRPC) mechanism The so called backward recursive path computation (BRPC) mechanism
[RFC5441] defines a PCE-based path computation procedure to compute [RFC5441] defines a PCE-based path computation procedure to compute
inter-domain constrained (G)MPLS TE LSPs. However, both per-domain inter-domain constrained (G)MPLS TE LSPs. However, both per-domain
and BRPC techniques assume that the sequence of domains to be crossed and BRPC techniques assume that the sequence of domains to be crossed
from source to destination is known, either fixed by the network from source to destination is known, either fixed by the network
operator or obtained by other means. For inter-domain point-to- operator or obtained by other means. For inter-domain point-to-
multi-point (P2MP) tree, [PCE-P2MP-PROCEDURES] assumes the domain- multi-point (P2MP) tree, [PCE-P2MP-PROCEDURES] assumes the domain-
tree is known. tree is known.
The list of domains in a point-to-point (P2P) path or a point-to- The list of domains (domain-sequence) in a point-to-point (P2P) path
multi-point (P2MP) tree is usually a constraint in the path or a point-to-multi-point (P2MP) tree is usually a constraint in the
computation request. The PCE decouples the domain to determine the path computation request. The PCE determines the next PCE to forward
next PCE to forward the request. the request based on the domain-sequence.
According to BRPC mechanism the PCC MAY indicate the sequence of In a multi-domain path computation, a PCC MAY indicate the sequence
domains to be traversed using the Include Route Object (IRO) defined of domains to be traversed using the Include Route Object (IRO)
in [RFC5440]. defined in [RFC5440].
This document proposes a standard way to represent and encode a When the sequence of domains is not known in advance, the
domain sequence using IRO in various deployment scenarios including Hierarchical PCE [RFC6805] architecture and mechanisms can be used to
P2P, P2MP and Hierarchical PCE (HPCE) [PCE-HIERARCHY-FWK]. determine the end-to-end Domain-Sequence.
The domain sequence (the set of domains traversed to reach the This document defines a standard way to represent and encode a
Domain-Sequence in various deployment scenarios including P2P, P2MP
and Hierarchical PCE (H-PCE) [RFC6805].
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 (H-PCE) that is outside of the scope of this discovered by some means (H-PCE) that is outside of the scope of this
document. Here the focus is only on a standard representation of the document.
domain sequence in all possible scenarios.
[RFC5440] defines the Include Route Object (IRO) and the Explicit
Route Object (ERO); [RFC5521] defines the Exclude Route Object (XRO)
and the Explicit Exclusion Route Subobject (EXRS); The use of
Autonomous Number (AS) (2-Byte) as an abstract node representing
domain is defined in [RFC3209], This document specifies new
subobjects to include or exclude domains such as an IGP area or an
Autonomous Systems (4-Byte).
1.1. Requirements Language 1.1. Requirements Language
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. Terminology 2. Terminology
The following terminology is used in this document. The following terminology is used in this document.
skipping to change at page 5, line 13 skipping to change at page 5, line 20
areas. areas.
AS: Autonomous System. AS: Autonomous System.
ASBR: Autonomous System Boundary Router. ASBR: Autonomous System Boundary Router.
BN: Boundary Node, Can be an ABR or ASBR. BN: Boundary Node, Can be an ABR or ASBR.
BRPC: Backward Recursive Path Computation BRPC: Backward Recursive Path Computation
Domain: Any collection of network elements within a common sphere of Domain: As per [RFC4655], any collection of network elements within
address management or path computational responsibility. Examples a common sphere of address management or path computational
of domains include Interior Gateway Protocol (IGP) areas and responsibility. Examples of domains include Interior Gateway
Autonomous Systems (ASs). Protocol (IGP) areas and Autonomous Systems (ASs).
Domain-Seq: An ordered sequence of domains traversed to reach the Domain-Sequence: An ordered sequence of domains traversed to reach
destination domain. the destination domain.
ERO: Explicit Route Object ERO: Explicit Route Object
H-PCE: Hierarchical PCE H-PCE: Hierarchical PCE
IGP: Interior Gateway Protocol. Either of the two routing IGP: Interior Gateway Protocol. Either of the two routing
protocols, Open Shortest Path First (OSPF) or Intermediate System protocols, Open Shortest Path First (OSPF) or Intermediate System
to Intermediate System (IS-IS). to Intermediate System (IS-IS).
IRO: Include Route Object IRO: Include Route Object
skipping to change at page 6, line 9 skipping to change at page 6, line 17
P2P: Point-to-Point P2P: Point-to-Point
RSVP: Resource Reservation Protocol RSVP: Resource Reservation Protocol
TE LSP: Traffic Engineering Label Switched Path. TE LSP: Traffic Engineering Label Switched Path.
3. Detail Description 3. Detail Description
3.1. Domains 3.1. Domains
A domain can be defined as a separate administrative or geographic [RFC4726] and [RFC4655] define domain as a separate administrative or
environment within the network. A domain may be further defined as a geographic environment within the network. A domain may be further
zone of routing or computational ability. Under these definitions a defined as a zone of routing or computational ability. Under these
domain might be categorized as an Autonomous System (AS) or an definitions a domain might be categorized as an Autonomous System
Interior Gateway Protocol (IGP) area ( as per [RFC4726] and (AS) or an Interior Gateway Protocol (IGP) area. Each AS can be made
[RFC4655]). To uniquely identify a domain in the domain sequence of several IGP areas. In order to encode a Domain-Sequence, it is
both AS and Area-id MAYBE important. required to uniquely identify a domain in the Domain-Sequence. A
domain can be uniquely identified by area-id or AS or both.
3.2. Domain-Sequence 3.2. Domain-Sequence
A domain-sequence is an ordered sequence of domains traversed to A domain-sequence is an ordered sequence of domains traversed to
reach the destination domain. In this context a Domain could be an reach the destination domain.
Autonomous System (AS) or an IGP Area. Note that an AS can be
further made of multiple Areas.
Domain Sequence can be applied as a constraint and carried in path A domain-sequence can be applied as a constraint and carried in path
computation request to PCE(s). In case of HPCE [PCE-HIERARCHY-FWK] computation request to PCE(s). A domain-sequence can also be the
Parent PCE MAY send the domain sequence as a result in path result of a path computation. For example, in the case of H-PCE
computation reply. [RFC6805] Parent PCE MAY send the Domain-Sequence as a result in a
path computation reply.
In this context, ordered sequence is important, in a P2P path, the In this context, the ordered nature of a domain-sequence is
domains listed appear in the order that they are crossed. In a P2MP important. In a P2P path, the domains listed appear in the order
path, the domain tree is represented as list of domain sequences. that they are crossed. In a P2MP path, the domain tree is
represented as list of domain sequences.
One main goal of the Domain-Sequence is to enable a PCE to select the A domain-sequence enables a PCE to select the next PCE to forward the
next PCE to forward the path computation request based on the domain path computation request based on the domain information.
information.
A PCC or PCE MAY add an additional constraints covering which A PCC or PCE MAY add an additional constraints covering which
Boundary Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be Boundary Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be
traversed while defining a domain sequence. traversed while defining a Domain-Sequence.
Thus a Domain-Sequence MAY be made up of one or more of - Thus a Domain-Sequence MAY be made up of one or more of -
o AS Number o AS Number
o Area ID o Area ID
o Boundary Node ID o Boundary Node ID
o Inter-AS-Link Address o Inter-AS-Link Address
Consequently, a Domain-Sequence can be used: Consequently, a Domain-Sequence can be used:
skipping to change at page 7, line 8 skipping to change at page 7, line 17
o Boundary Node ID o Boundary Node ID
o Inter-AS-Link Address o Inter-AS-Link Address
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 further be an input to BRPC procedure; this can further be an input to BRPC procedure [RFC6805];
3. By a PCC (or PCE) to constraint the domains used in a H-PCE path 3. by a PCC (or PCE) to constraint the domains used in a H-PCE path
computation, explicitly specifying which domains to be expanded; computation, explicitly specifying which domains to be expanded;
4. by a PCE in per-domain path computation model [RFC5152] to
identify the next domain(s);
3.3. Standard Representation 3.3. Standard Representation
3.3.1. New Sub-Objects Domain-Sequence MAY appear in PCEP Messages, notably in -
Some sub-objects are defined in [RFC3209], [RFC3473], [RFC3477] and o Include Route Object (IRO): As per [RFC5440], used to specify set
[RFC4874], but new sub-objects related to Domain-Sequence are needed. of network elements that MUST be traversed. These subobjects are
used to specify the domain-sequence that MUST be traversed to
reach the destination.
3.3.1.1. Autonomous system o Exclude Route Object (XRO): As per [RFC5521], used to specify
certain abstract nodes that MUST be excluded from whole path.
These subobjects are used to specify certain domains that MUST be
avoided to reach the destination.
[RFC3209] already defines 2 octet AS number. o Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], used
to specify exclusion of certain abstract nodes between a specific
pair of nodes. EXRS are a subobject inside the IRO. These
subobjects are used to specify the domains that must be excluded
between two abstract nodes.
To support 4 octet AS number as per [RFC4893] following subobject is o Explicit Route Object (ERO): As per [RFC5440],used to specify a
computed path in the network.
3.4. Include Route Object (IRO)
As per [RFC5440], IRO (Include Route Object) can be used to specify
that the computed path MUST traverse a set of specified network
elements or abstract nodes.
3.4.1. Subobjects
Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477] and
[RFC4874], but new subobjects related to Domain-Sequence are needed.
The following subobject types are used in IRO.
The following subobject types are used.
Type Subobject
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number (2 Byte)
33 Explicit Exclusion (EXRS)
This document extends the above list to support 4-Byte AS numbers and
IGP Areas.
The following subobject types are used.
Type Subobject
TBD Autonomous system number (4 Byte)
TBD OSPF Area id
TBD ISIS Area id
- Autonomous system
[RFC3209] already defines 2 byte AS number.
To support 4 byte AS number as per [RFC4893] 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | |L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Id (4 bytes) | | AS Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: The L bit is an attribute of the subobject as define in [RFC3209]. L: The L bit is an attribute of the subobject as define in [RFC3209].
Type: (TBA by IANA) indicating 4 octet AS Number. Type: (TBA by IANA) indicating 4 byte AS Number.
Length: 8 (Total length of the subobject in bytes). Length: 8 (Total length of the subobject in bytes).
Reserved: Zero at transmission, Ignored at receipt. Reserved: Zero at transmission, Ignored at receipt.
AS-ID: The 4 octet AS Number. Note that if 16-bit AS numbers are in AS-ID: The 4 byte AS Number. Note that if 16-bit AS numbers are in
use, the low order bits (16 through 31) should be used and the high use, the low order bits (16 through 31) should be used and the high
order bits (0 through 15) should be set to zero. order bits (0 through 15) should be set to zero.
3.3.1.2. IGP Area - IGP Area
Since the length and format of Area-id is different for OSPF and Since the length and format of Area-id is different for OSPF and
ISIS, following two subobjects are defined: ISIS, following two subobjects are defined:
For OSPF, the area-id is a 32 bit number. The Subobject looks For OSPF, the area-id is a 32 bit number. The Subobject looks
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | |L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area Id (4 bytes) | | OSPF Area Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: The L bit is an attribute of the subobject as define in [RFC3209]. L: The L bit is an attribute of the subobject as define in [RFC3209].
Type: (TBA by IANA) indicating 4 octet OSPF Area ID. Type: (TBA by IANA) indicating 4 byte OSPF Area ID.
Length: 8 (Total length of the subobject in bytes). Length: 8 (Total length of the subobject in bytes).
Reserved: Zero at transmission, Ignored at receipt. Reserved: Zero at transmission, Ignored at receipt.
OSPF Area Id: The 4 octet OSPF Area ID. OSPF Area Id: The 4 byte OSPF Area ID.
For IS-IS, the area-id is of variable length and thus the length of For IS-IS, the area-id is of variable length and thus the length of
the Subobject is variable. The Area-id is as described in IS-IS by the Subobject is variable. The Area-id is as described in IS-IS by
ISO standard [ISO 10589]. ISO standard [ISO 10589].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Area-Len | Reserved | |L| Type | Length | Area-Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 8 skipping to change at page 10, line 19
Length: Variable (Total length of the subobject in bytes including Length: Variable (Total length of the subobject in bytes including
padding). The Length MUST be at least 4, and MUST be a multiple of padding). The Length MUST be at least 4, and MUST be a multiple of
4. 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 2 to 11 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-octet boundary. with trailing zeroes to a four-byte boundary.
3.3.2. Use in PCEP Objects
These sub-objects MAYBE used in -
o Include Route Object (IRO): As per [RFC5440], used to specify set
of network elements that MUST be traversed. These subobjects are
used to specify the domain-sequence that MUST be traversed to
reach the destination.
o Exclude Route Object (XRO): As per [RFC5521], used to specify
certain abstract nodes that MUST be excluded from whole path.
These subobjects are used to specify certain domains that MUST be
avoided to reach the destination.
o Explicit Route Object (ERO): As per [RFC5440],used to specify a
computed path in the network. These subobjects are used to
specify the domain-sequence when computed by a Parent PCE
([PCE-HIERARCHY-FWK]).
o Explicit Exclusion Route Sub-Object (EXRS): As per [RFC5521], used
to specify exclusion of certain abstract nodes between a specific
pair of nodes. EXRS are a sub-object inside the IRO. These
subobjects are used to specify the domains that must be excluded
between two abstract nodes.
3.3.2.1. Include Route Object
3.3.2.1.1. Option 1: New IRO Object Type
The IRO (Include Route Object) [RFC5440] is an optional object used 3.4.2. Option (A): New IRO Object Type
to specify a set of specified network elements that the computed path
MUST traverse. [RFC5440] in its description of IRO does not
constrain the sub-objects to be in a given particular order. When
considering a domain sequence, the domain relative ordering is a
basic criterion and, as such, this document specifies a new IRO
object type.
We define a new type of IRO Object to define Domain Sequence. [RFC5440] in its description of IRO does not require the subobjects
to be in a given particular order. When considering a Domain-
Sequence, the domain relative ordering is a basic criterion and, as
such, this option suggest a new IRO object type.
IRO Object-Class is 10. IRO Object-Class is 10.
IRO Object-Type is TBD. (2 suggested value to IANA) IRO Object-Type is TBD. (2 suggested value to IANA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Subobjects) // // (Subobjects) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-objects: The IRO is made of sub-objects identical to the ones Subobjects: The IRO is made of subobjects identical to the ones
defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO sub- defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO
object type is identical to the sub-object type defined in the subobject type is identical to the subobject type defined in the
related documents. Some new sub-objects related to Domain-Sequence related documents. Some new subobjects related to Domain-Sequence
are also added in this document. are also added in this document as mentioned in Section 3.4.
The following sub-object types are used.
Type Sub-object
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system number (2 Byte)
33 Explicit Exclusion (EXRS)
TBD Autonomous system number (4 Byte)
TBD OSPF Area id
TBD ISIS Area id
[RFC3209] defines sub-objects for IPv4, IPv6 and unnumbered Interface [RFC3209] defines subobjects for IPv4, IPv6 and unnumbered Interface
ID, which in the context of domain-sequence is used to specify ID, which in the context of domain-sequence is used to specify
Boundary Node (ABR/ASBR) and Inter-AS-Links. The sub-objects for AS Boundary Node (ABR/ASBR) and Inter-AS-Links. The subobjects for AS
Number (2 or 4 Byte) and IGP Area is used to specify the domains in Number (2 or 4 Byte) and IGP Area is used to specify the domains in
the domain-sequence. the domain-sequence.
The new IRO Object-Type used to define the domain-sequence would The new IRO Object-Type used to define the domain-sequence would
handle the L bit (Loose / Strict) in the sub-objects. handle the L bit (Loose / Strict) in the subobjects similar to
[RFC3209].
Note that PCReq message is free to carry both type of IRO with IRO Further we have following options:
Type 1 ([RFC5440]) used to specify the intra-domain abstract nodes
and resources and the new IRO Type as described in this document to * Option (A.1): New IRO Object Type for Domain-Sequence object only
specify the domain-sequence.
A new IRO Object Type is used to specify the ordered sequence of
domains (Domain-Sequence) only. The PCReq message is modified to
allow encoding of both types of IRO; one with IRO Type 1 [RFC5440]
used to specify the intra-domain abstract nodes and resources and the
second IRO Type with the new subobjects as described in this section
to specify the domain-sequence.
All other rules of PCEP objects and message processing (ex. P bit All other rules of PCEP objects and message processing (ex. P bit
handling of Common Object Header) is as per [RFC5440]. handling of Common Object Header) is as per [RFC5440].
3.3.2.1.1.1. Mode of Operation * Option (A.2): New IRO Object Type for both intra and inter-domain
(domain-sequence)
A domain sequence IRO object constraints or defines the domains A new IRO Object Type is used to include both intra nodes and inter-
involved in a multi-domain path computation, typically involving two domains nodes but the sequence of domain is strict. The intra-domain
or more collaborative PCEs. nodes can still be ordered.
A domain sequence can have varying degrees on granularity; it is In case of inter-domain path computation, only the new IRO type is
possible to have a domain sequence composed of, uniquely, AS used which contains the specific intra domain network nodes as well
as inter-domain abstract nodes or domains. The inter-domain abstract
nodes are encoded in the sequence they must be traversed but the
intra-domain elements MAY be an unordered set.
3.4.2.1. Handling of the Domain-Sequence IRO object
An IRO object containing Domain-Sequence subobjects constraints or
defines the domains involved in a multi-domain path computation,
typically involving two or more collaborative PCEs.
A Domain-Sequence can have varying degrees of granularity; it is
possible to have a Domain-Sequence composed of, uniquely, AS
identifiers. It is also possible to list the involved areas for a identifiers. It is also possible to list the involved areas for a
given AS. 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).
A PCC builds a domain sequence IRO (new type) to encode the domain A PCC builds a Domain-Sequence IRO to encode the Domain-Sequence,
sequence, that is all domains that it wishes the cooperating PCEs to that is all domains that it wishes the cooperating PCEs to traverse
traverse in order to compute the end to end path. in order to compute the end to end path.
For each inclusion, the PCC clears the L-bit to indicate that the PCE For each inclusion, the PCC clears the L-bit to indicate that the PCE
is required to include the domain, or sets the L-bit to indicate that is required to include the domain, or sets the L-bit to indicate that
the PCC simply desires that the domain be included in the domain- the PCC simply desires that the domain be included in the domain-
sequence. sequence.
When a PCE receives a PCReq message it looks for a domain sequence When a PCE receives a PCEP Request message with an IRO, it looks for
IRO (new type) to see if domain-sequence are required. If the PCE a Domain-Sequence IRO (new type) to see if a domain-sequence is
finds more than one domain sequence IRO (new type), it MUST use the specified. If the message contains more than one Domain-Sequence IRO
first one in the message and MUST ignore subsequent instances. (new type), it MUST use the first one in the message and MUST ignore
subsequent instances.
If the PCE does not recognize the domain sequence IRO (new type), it If a PCE does not recognize the Domain-Sequence IRO (new type), it
MUST return a PCErr message with Error-Type "Unknown Object" and MUST return a PCErr message with Error-Type "Unknown Object" and
Error-value "Unrecognized object Type" as described in [RFC5440]. Error-value "Unrecognized object Type" as described in [RFC5440].
If the PCE is unwilling or unable to process the domain sequence IRO If a PCE is unwilling or unable to process the Domain-Sequence IRO
(new type), it MUST return a PCErr message with the Error-Type "Not (new type), it MUST return a PCErr message with the Error-Type "Not
supported object" and follow the relevant procedures described in supported object" and follow the relevant procedures described in
[RFC5440]. [RFC5440].
If a PCE that supports the domain sequence IRO (new type) and If a PCE that supports the Domain-Sequence IRO (new type) and
encounters a subobject that it does not support or recognize, it MUST encounters a subobject that it does not support or recognize, it MUST
act according to the setting of the L-bit in the subobject. If the act according to the setting of the L-bit in the subobject. If the
L-bit is clear, the PCE MUST respond with a PCErr with Error-Type L-bit is clear, the PCE MUST respond with a PCErr with Error-Type
"Unrecognized subobject" and set the Error-Value to the subobject "Unrecognized subobject" and set the Error-Value to the subobject
type code. If the L-bit is set, the PCE MAY respond with a PCErr as type code. If the L-bit is set, the PCE MAY respond with a PCErr as
already stated or MAY ignore the subobject: this choice is a local already stated or MAY ignore the subobject: this choice is a local
policy decision. policy decision.
If a PCE parses a domain sequence IRO (new type) and encounters these If a PCE parses a Domain-Sequence IRO (new type), it MUST act
subobject that it recognizes, it MUST act according to the according to the requirements expressed in the subobject. That is,
requirements expressed in the subobject. That is, if the L-bit is if the L-bit is clear, the PCE(s) MUST produce a path that follows
clear, the PCE(s) MUST produce a path that follows domain-sequence domain-sequence nodes in order identified by the subobjects in the
nodes in order identified by the sub-objects in the path. If the path. If the L-bit is set, the PCE(s) SHOULD produce a path along
L-bit is set, the PCE(s) SHOULD produce a path along the domain the Domain-Sequence unless it is not possible to construct a path
sequence unless it is not possible to construct a path complying with complying with the other constraints expressed in the request.
the other constraints expressed in the PCReq message.
A successful path computation reported in a PCRep message MUST A successful path computation reported in a PCEP response message
include an ERO to specify the path that has been computed as MUST include an ERO to specify the path that has been computed as
specified in [RFC5440] following the domain-sequence. specified in [RFC5440] following the sequence of domains.
When a PCE returns a path in a PCRep, it MAY also supply a domain In a PCEP response message, PCE MAY also supply a Domain-Sequence IRO
sequence IRO (new type) in a PCRep message with the NO-PATH object (new type) with the NO-PATH object indicating that the set of
indicates that the set of elements of the original domain sequence elements of the request's Domain-Sequence IRO prevented the PCE from
IRO prevented the PCE from finding a path. finding a path.
Sub-Object types for AS and IGP Area guide the next domain selection Subobject types for AS and IGP Area affect the next domain selection
and finding the PCE serving that domain. as well as finding the PCE serving that domain.
Note that a particular domain in the domain-sequence can be Note that a particular domain in the domain-sequence can be
identified by - identified by :-
o Just Area: Only the IGP (OSPF or ISIS) Area subobject is used to o A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is
identify the next domain. (Refer Figure 1) used to identify the next domain. (Refer Figure 1)
o Just AS: Only the AS subobject is used to identify the next o A single AS: Only the AS subobject is used to identify the next
domain. (Refer Figure 2) domain. (Refer Figure 2)
o AS and IGP Area: Combination of both AS and Area are used to o Both an AS and an IGP Area: Combination of both AS and Area are
identify the next domain. In this case the order is AS Subobject used to identify the next domain. In this case the order is AS
followed by Area. (Refer Figure 3) Subobject followed by Area. (Refer Figure 3)
Sub-Object of other types representing Boundary Node or Inter-As-Link Subobject of other types representing Boundary Node or Inter-AS-Link
do not pay any role in selection of next domain and subsequently PCE do not pay any role in the selection of next domain, but they MUST be
selection in the domain-sequence. But they MUST be applied during applied during the final path computation procedure as before.
the final path computation procedure as before.
3.3.2.1.2. Option 2: Same IRO Object Type 3.4.3. Option B: Existing IRO Object Type
The IRO (Include Route Object) [RFC5440] is an optional object used The IRO (Include Route Object) [RFC5440] is an optional object used
to specify a set of specified network elements that the computed path to specify a set of network elements that the computed path MUST
MUST traverse. traverse.
The new sub-objects denoting the domain-sequence is carried in the The new subobjects denoting the domain-sequence are carried in the
same IRO Type 1, and all the rules of processing as specified in same IRO Type 1, and all the rules of processing as specified in
[RFC5440] are applied. [RFC5440] are applied.
Note the following differences - Note the following differences :-
o Order: Since there is no inherent order specified in the encoding o Order: Since there is no inherent order specified in the encoding
of the subobjects in IRO Type 1 [RFC5440]. It is the job of PCE of the subobjects in IRO Type 1 [RFC5440], it is the job of the
to figure out the order of the domains to be crossed to reach the PCE to figure out the optimal order of the domains to be crossed
destination domain. Note that in case of doubt, or when to reach the destination domain. Note that in case of doubt, or
applicable, PCE can still apply the ordering as specified in the when applicable, the PCE can still apply the ordering as specified
PCReq message. in the request message. Further PCE may have to crankback and try
multiple permutations before figuring out the correct sequence.
o Loose / Strict: [RFC5440] state that the L bit of the sub-objects o Loose / Strict (L-Bit): [RFC5440] state that the L bit of the
within an IRO Type 1 [RFC5440] has no meaning. This is applicable subobjects within an IRO Type 1 [RFC5440] has no meaning. This
for sub-objects denoting domain-sequence as well. will be applicable for subobjects denoting domain-sequence as
well.
o Scope: Sub-objects referring to domains and boundary nodes will o Scope: Coexistence of intra-domain nodes, boundary nodes and
mix with subobjects for internal network nodes of multiple domain nodes in the same IRO List. It is the job of PCE to figure
domains. It is the job of PCE to figure out the scope and apply out the scope and apply the processing rules accordingly. The
the processing rules accordingly. The PCE should distinguish nodes in the IRO which are recognized by the PCE are handled
between - the subobject is unknown (not in TED) or known but the locally and others are forwarded to next PCE hoping they would
computation fails. The PCE processing the IRO MAY include as many handle them, the aggregating PCE (Ingress PCE or Parent) would
of the elements of the IRO as possible. If the PCE is passing the make sure that all nodes in IRO are handled correctly.
request onwards, it is OK for it to have unknown nodes, and it can
assume that the next PCE might be able to satisfy the remaining
elements of the IRO. On the other hand, if the PCE is making an
end-to-end (or edge-to-edge, or end-to-edge) path and will return
the response to a PCC (rather than pass it on) then the PCE must
fail if it cannot satisfy the IRO. Ultimately, when the path
segments are aggregated by a head-end PCE or by a parent PCE, that
PCE can check to see whether any elements of the IRO are still
missing and handle accordiangly.
3.3.2.2. Exclude Route Object 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
The following subobject types are defined to be used in XRO as The following subobject types are defined to be used in XRO as
defined in [RFC3209], [RFC3477], [RFC4874], and [RFC5521]. defined in [RFC3209], [RFC3477], [RFC4874], and [RFC5521].
Type Sub-object Type Subobject
1 IPv4 prefix 1 IPv4 prefix
2 IPv6 prefix 2 IPv6 prefix
4 Unnumbered Interface ID 4 Unnumbered Interface ID
32 Autonomous system number (2 Byte) 32 Autonomous system number (2 Byte)
34 SRLG 34 SRLG
64 IPv4 Path Key 64 IPv4 Path Key
65 IPv6 Path Key 65 IPv6 Path Key
This document extends the above list to support 4-Byte AS numbers and
IGP Areas.
Type Subobject
TBD Autonomous system number (4 Byte) TBD Autonomous system number (4 Byte)
TBD OSPF Area id TBD OSPF Area id
TBD ISIS Area id TBD ISIS Area id
The new subobjects to support 4 octet AS and IGP (OSPF / ISIS) Area 3.5.1.1. Autonomous system
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.
The X-bit indicates whether the exclusion is mandatory or desired. 0
indicates that the domain specified MUST be excluded from the path
computed by the PCE(s). 1 indicates that the domain specified SHOULD
be excluded from the inter-domain path computed by the PCE(s), but
MAY be included subject to PCE policy and the absence of a viable
path that meets the other constraints and excludes the domain. All
other fields are consistent with the definition in Section 3.3.1.
4 Octet Autonomous system:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Id (4 bytes) | | AS Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OSPF Area: The X-bit indicates whether the exclusion is mandatory or desired.
0 indicates that the AS specified MUST be excluded from the path
computed by the PCE(s).
1 indicates that the AS specified SHOULD be avoided from the inter-
domain path computed by the PCE(s), but MAY be included subject to
PCE policy and the absence of a viable path that meets the other
constraints.
All other fields are consistent with the definition in Section 3.4.
3.5.1.2. IGP Area
Since the length and format of Area-id is different for OSPF and
ISIS, following two subobjects are defined:
For OSPF, the area-id is a 32 bit number. The subobject is encoded
as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type | Length | Reserved | |X| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area Id (4 bytes) | | OSPF Area Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IS-IS Area: The X-bit indicates whether the exclusion is mandatory or desired.
0 indicates that the OSFF Area specified MUST be excluded from the
path computed by the PCE(s).
1 indicates that the OSFF Area specified SHOULD be avoided from the
inter-domain path computed by the PCE(s), but MAY be included subject
to PCE policy and the absence of a viable path that meets the other
constraints.
All other fields are consistent with the definition in Section 3.4.
For IS-IS, the area-id is of variable length and thus the length of
the subobject is variable. The Area-id is as described in IS-IS by
ISO standard [ISO 10589]. The subobject is encoded as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type | Length | Area-Len | Reserved | |X| Type | Length | Area-Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// IS-IS Area ID // // IS-IS Area ID //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The X-bit indicates whether the exclusion is mandatory or desired.
0 indicates that the ISIS Area specified MUST be excluded from the
path computed by the PCE(s).
1 indicates that the ISIS Area specified SHOULD be avoided from the
inter-domain path computed by the PCE(s), but MAY be included subject
to PCE policy and the absence of a viable path that meets the other
constraints.
All other fields are consistent with the definition in Section 3.4.
If a PCE that supports XRO and encounters a subobject that it does If a PCE that supports XRO and encounters a subobject that it does
not support or recognize, it MUST act according to the setting of the not support or recognize, it MUST act according to the setting of the
X-bit in the subobject. If the X-bit is clear, the PCE MUST respond X-bit in the subobject. If the X-bit is clear, the PCE MUST respond
with a PCErr with Error-Type "Unrecognized subobject" and set the with a PCErr with Error-Type "Unrecognized subobject" and set the
Error-Value to the subobject type code. If the X-bit is set, the PCE Error-Value to the subobject type code. If the X-bit is set, the PCE
MAY respond with a PCErr as already stated or MAY ignore the MAY respond with a PCErr as already stated or MAY ignore the
subobject: this choice is a local policy decision. subobject: this choice is a local policy decision.
All the other processing rules are as per [RFC5521]. All the other processing rules are as per [RFC5521].
3.3.2.3. Explicit Route Object 3.6. Explicit Exclusion Route Subobject (EXRS)
Explicit Exclusion Route Subobject (EXRS) [RFC5521] is used to
specify exclusion of certain abstract nodes between a specific pair
of nodes.
The EXRS subobject may carry any of the subobjects defined for
inclusion in the XRO, thus the new subobjects to support 4 byte AS
and IGP (OSPF / ISIS) Area MAY also be used in the EXRS. The
meanings of the fields of the new XRO subobjects are unchanged when
the subobjects are included in an EXRS, except that scope of the
exclusion is limited to the single hop between the previous and
subsequent elements in the IRO.
All the processing rules are as per [RFC5521].
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 sub-object types correspond computed path in the network. PCEP ERO subobject types correspond to
to RSVP-TE ERO sub-object types as defined in [RFC3209], [RFC3473], RSVP-TE ERO subobject types as defined in [RFC3209], [RFC3473],
[RFC3477], [RFC4873], [RFC4874], and [RFC5520]. [RFC3477], [RFC4873], [RFC4874], and [RFC5520].
Type Sub-object Type Subobject
1 IPv4 prefix 1 IPv4 prefix
2 IPv6 prefix 2 IPv6 prefix
3 Label 3 Label
4 Unnumbered Interface ID 4 Unnumbered Interface ID
32 Autonomous system number (2 Byte) 32 Autonomous system number (2 Byte)
33 Explicit Exclusion (EXRS) 33 Explicit Exclusion (EXRS)
37 Protection 37 Protection
64 IPv4 Path Key 64 IPv4 Path Key
65 IPv6 Path Key 65 IPv6 Path Key
This document extends the above list to support 4-Byte AS numbers and
IGP Areas.
Type Subobject
TBD Autonomous system number (4 Byte) TBD Autonomous system number (4 Byte)
TBD OSPF Area id TBD OSPF Area id
TBD ISIS Area id TBD ISIS Area id
The new subobjects to support 4 octet 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 ERO to specify an abstract node (a group of MAY 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, a Parent PCE ([PCE-HIERARCHY-FWK]) MAY In case of Hierarchical PCE [RFC6805], a Parent PCE MAY be requested
be requested to find the domain-sequence. The Parent PCE MUST use to find the domain-sequence. Refer example in Section 4.6.
ERO with AS and IGP Area subobjects to encode the computed domain-
sequence. Refer example in Section 3.4.6.
3.3.2.4. Explicit Exclusion Route Sub-Object
Explicit Exclusion Route Sub-Object (EXRS) [RFC5521] is used to
specify exclusion of certain abstract nodes between a specific pair
of nodes.
The EXRS subobject may carry any of the subobjects defined for
inclusion in the XRO, thus the new subobjects to support 4 octet AS
and IGP (OSPF / ISIS) Area MAY also be used in the EXRS. The
meanings of the fields of the new XRO subobjects are unchanged when
the subobjects are included in an EXRS, except that scope of the
exclusion is limited to the single hop between the previous and
subsequent elements in the IRO.
All the processing rules are as per [RFC5521]. The format of the new ERO subobjects is similar to new IRO
subobjects, refer Section 3.4.
3.4. Other Considerations 4. Other Considerations
3.4.1. Inter-Area Path Computation 4.1. Inter-Area Path Computation
In an inter-area path computation where ingress and egress belong to In an inter-area path computation where the ingress and the egress
different IGP area, the domain sequence MAYBE represented using a nodes belong to different IGP areas within the same AS, the Domain-
ordered list of AREA sub-objects. AS number MAYBE skipped, as area Sequence MAY be represented using a ordered list of Area subobjects.
information is enough to select the next PCE. The AS number MAY be skipped, as area information is enough to select
the next PCE.
+-------------------+ +-------------------+ +-------------------+ +-------------------+
| | | | | | | |
| +--+ | | +--+ | | +--+ | | +--+ |
| +--+ | | | | | | | | +--+ | | | | | | |
| | | +--+ | | +--+ +--+ | | | | +--+ | | +--+ +--+ |
| +--* + + | | | | +--* + + | | |
| | | +--+ | | | | +--+ |
| *--+ + + | | *--+ + + |
| | | | | +--+ | | | | | | +--+ |
skipping to change at page 18, line 7 skipping to change at page 20, line 7
| +--+ | | | | | | +--+ | | | | |
| | | +--+ | | | | +--+ |
| | | | | | | |
| Area 1 | | Area 5 | | Area 1 | | Area 5 |
+------------------+ +--------------------+ +------------------+ +--------------------+
AS Number is 100. AS Number is 100.
Figure 1: Inter-Area Path Computation Figure 1: Inter-Area Path Computation
This could be represented as <IRO> as: This could be represented in the <IRO> as:
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|IRO | |Sub | |Sub | |Sub | |IRO | |Sub | |Sub | |Sub |
|Object | |Object | |Object | |Object | |Object | |Object | |Object | |Object |
|Header | |Area 2 | |Area 0 | |Area 4 | |Header | |Area 2 | |Area 0 | |Area 4 |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|IRO | |Sub | |Sub | |Sub | |Sub | |IRO | |Sub | |Sub | |Sub | |Sub |
|Object | |Object As| |Object | |Object | |Object | |Object | |Object AS| |Object | |Object | |Object |
|Header | |100 | |Area 2 | |Area 0 | |Area 4 | |Header | |100 | |Area 2 | |Area 0 | |Area 4 |
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
AS is optional and it MAY be skipped. PCE should be able to AS is optional and it MAY be skipped. PCE should be able to
understand both notations. understand both notations.
3.4.2. Inter-AS Path Computation 4.2. Inter-AS Path Computation
In inter-AS path computation, where ingress and egress belong to In inter-AS path computation, where ingress and egress belong to
different AS, the domain sequence is represented using an ordered different AS, the Domain-Sequence is represented using an ordered
list of AS sub-objects. The domain sequence MAY further include list of AS subobjects. The Domain-Sequence MAY further include
decomposed area information in AREA sub-objects. decomposed area information in Area subobjects.
3.4.2.1. Example 1 4.2.1. Example 1
As shown in Figure 2, where AS to be made of a single area, the area As shown in Figure 2, where AS to be made of a single area, the area
subobject MAY be skipped in the domain sequence as AS is enough to subobject MAY be skipped in the Domain-Sequence as AS is enough to
uniquely identify the next domain and PCE. uniquely identify the next domain and PCE.
+---------------------------------+ +---------------------------------+
|AS 200 | |AS 200 |
| +------+ | | +------+ |
| | | | | | | |
+------------------------+ | | | +------+ | +------------------------+ | | | +------+ |
| AS 100 | | +------+ | | | | AS 100 | | +------+ | | |
| +------+ | | +------+ | | | | +------+ | | +------+ | | |
| | +-+-----+-+ | +------+ | | | +-+-----+-+ | +------+ |
skipping to change at page 20, line 5 skipping to change at page 22, line 5
| |PCE | | | |PCE | | | |PCE | | | |PCE | |
| +------+ | | +------+ | | +------+ | | +------+ |
| | | | | | | |
+------------------------+ | | +------------------------+ | |
+---------------------------------+ +---------------------------------+
Both AS are made of Area 0. Both AS are made of Area 0.
Figure 2: Inter-AS Path Computation Figure 2: Inter-AS Path Computation
This could be represented as <IRO> as: This could be represented in the <IRO> as:
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|IRO | |Sub | |Sub | |IRO | |Sub | |Sub |
|Object | |Object As| |Object As| |Object | |Object AS| |Object AS|
|Header | |100 | |200 | |Header | |100 | |200 |
| | | | | | | | | | | |
| | | | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|IRO | |Sub | |Sub | |Sub | |Sub | |IRO | |Sub | |Sub | |Sub | |Sub |
|Object | |Object As| |Object | |Object As| |Object | |Object | |Object AS| |Object | |Object AS| |Object |
|Header | |100 | |Area 0 | |200 | |Area 0 | |Header | |100 | |Area 0 | |200 | |Area 0 |
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Area is optional and it MAY be skipped. PCE should be able to Area subobject is optional and it MAY be skipped. PCE should be
understand both notations. able to understand both notations.
3.4.2.2. Example 2 4.2.2. Example 2
As shown in Figure 3, where AS 200 is made up of multiple areas and As shown in Figure 3, where AS 200 is made up of multiple areas and
multiple domain-sequence exist, PCE MAY include both AS and AREA multiple domain-sequence exist, PCE MAY include both AS and Area
subobject to uniquely identify the next domain and PCE. subobject to uniquely identify the next domain and PCE.
| |
| +-------------+ +----------------+ | +-------------+ +----------------+
| |Area 2 | |Area 4 | | |Area 2 | |Area 4 |
| | +--+| | +--+ | | | +--+| | +--+ |
| | | || | | | | | | | || | | | |
| | +--+ +--+| | +--+ +--+ | | | +--+ +--+| | +--+ +--+ |
| | | | | | | | | | | | | | | | | |
| | *--+ | | +--+ | | | *--+ | | +--+ |
skipping to change at page 21, line 51 skipping to change at page 23, line 51
| \| +--+ +--+ | +--+ | | \| +--+ +--+ | +--+ |
| \ | | | | | \ | | | |
| |\ +--+ | +--+ | | |\ +--+ | +--+ |
| | \ +--+ | | | | | | | \ +--+ | | | | |
| | \| | | | +--+ | | | \| | | | +--+ |
| | *--+ | | | | | *--+ | | |
| | | | | | | | | |
| +------------+ +----------------+ | +------------+ +----------------+
| |
| |
As 100 | AS 200 AS 100 | AS 200
| |
Figure 3: Inter-AS Path Computation Figure 3: Inter-AS Path Computation
The domain sequence can be carried in IRO as shown below: The Domain-Sequence can be carried in the IRO as shown below:
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|IRO | |Sub | |Sub | |Sub | |Sub | |Sub | |Sub | |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | |Sub |
|Object | |Object | |Object | |Object | |Object | |Object | |Object | |Object | |Object | |Object | |Object | |Object | |Object | |Object |
|Header | |As 100 | |Area 1 | |AS 200 | |Area 3 | |Area 0 | |Area 4 | |Header | |AS 100 | |Area 1 | |AS 200 | |Area 3 | |Area 0 | |Area 4 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
Combination of both AS and Area uniquely identify a domain in the domain
sequence. The combination of both an AS and an Area uniquely identify a domain
in the Domain-Sequence.
Note that an Area domain identifier always belongs to the previous AS Note that an Area domain identifier always belongs to the previous AS
that appear before it or, if no AS sub-objects are present, it is that appears before it or, if no AS subobjects are present, it is
assumed to be the current AS. assumed to be the current AS.
If the area information cannot be provided, PCE MAY forward the path If the area information cannot be provided, PCE MAY forward the path
computation request to the next PCE based on AS only. If multiple computation request to the next PCE based on AS alone. If multiple
PCEs of different area domain exist, PCE MAY apply local policy to PCEs are responsible, PCE MAY apply local policy to select the next
select the next PCE. Furthermore the domain sequence (list of areas PCE.
within AS) in the next PCE MAYBE pre-administered or MAYBE discovered
via some mechanism (ex. HPCE).
3.4.3. Boundary Node and Inter-AS-Link 4.3. Boundary Node and Inter-AS-Link
A PCC or PCE MAY add additional constraints covering which Boundary A PCC or PCE MAY add additional constraints covering which Boundary
Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be traversed Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be traversed
while defining a domain sequence. In which case the Boundary Node or while defining a Domain-Sequence. In which case the Boundary Node or
Link MAY be encoded as a part of the domain-sequence using the Link MAY be encoded as a part of the domain-sequence using the
existing sub-objects. existing subobjects.
Boundary Node (ABR / ASBR) can be encoded using the IPv4 or IPv6 Boundary Nodes (ABR / ASBR) can be encoded using the IPv4 or IPv6
prefix sub-objects. The Inter-AS link can be encoded using the IPv4 prefix subobjects usually the loopback address of 32 and 128 prefix
or IPv6 prefix or unnumbered interface sub-objects. length respectively. An Inter-AS link can be encoded using the IPv4
or IPv6 prefix subobjects or unnumbered interface subobjects.
For Figure 1, an ABR to be traversed can be specified as: For Figure 1, an ABR to be traversed can be specified as:
+---------+ +---------+ +---------++---------+ +---------+ +---------+ +---------+ +---------++---------+ +---------+
|IRO | |Sub | |Sub ||Sub | |Sub | |IRO | |Sub | |Sub ||Sub | |Sub |
|Object | |Object | |Object ||Object | |Object | |Object | |Object | |Object ||Object | |Object |
|Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 | |Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 |
| | | | |x.x.x.x || | | | | | | | |x.x.x.x || | | |
| | | | | || | | | | | | | | || | | |
+---------+ +---------+ +---------++---------+ +---------+ +---------+ +---------+ +---------++---------+ +---------+
For Figure 2, an inter-AS-link to be traversed can be specified as: For Figure 2, an inter-AS-link to be traversed can be specified as:
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|IRO | |Sub | |Sub | |Sub | |Sub | |IRO | |Sub | |Sub | |Sub | |Sub |
|Object | |Object As| |Object | |Object | |Object As| |Object | |Object AS| |Object | |Object | |Object AS|
|Header | |100 | |IPv4 | |IPv4 | |200 | |Header | |100 | |IPv4 | |IPv4 | |200 |
| | | | |x.x.x.x | |x.x.x.x | | | | | | | |x.x.x.x | |x.x.x.x | | |
| | | | | | | | | | | | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
3.4.4. PCE serving multiple domains 4.4. PCE serving multiple domains
A single PCE MAYBE responsible for multiple domains; for example PCE A single PCE MAY be responsible for multiple domains; for example PCE
function deployed on an ABR. Domain sequence should have no impact function deployed on an ABR. A PCE which can support 2 adjacent
on this. PCE which can support 2 adjacent domains can internally domains can internally handle this situation without any impact on
handle this situation without any impact on the neighboring domains. the neighboring domains.
3.4.5. P2MP 4.5. P2MP
In case of inter-domain P2MP path computation, (Refer In case of inter-domain P2MP path computation, (Refer
[PCE-P2MP-PROCEDURES]) the path domain tree is nothing but a series [PCE-P2MP-PROCEDURES]) the path domain tree is nothing but a series
of Domain Sequences, as shown in the below figure: of Domain Sequences, as shown in the below figure:
D1-D3-D6, D1-D3-D5 and D1-D2-D4. D1-D3-D6, D1-D3-D5 and D1-D2-D4.
D1 D1
/ \ / \
D2 D3 D2 D3
/ / \ / / \
D4 D5 D6 D4 D5 D6
All rules of processing as applied to P2P can be applied to P2MP as All rules of processing as applied to P2P can be applied to P2MP as
well. well.
In case of P2MP, different destinations MAY have different domain In case of P2MP, different destinations MAY have different Domain-
sequence within the domain tree, it requires domain-sequence to be Sequence within the domain tree, it requires domain-sequence to be
attached per destination. (Refer [PCE-P2MP-PER-DEST]) attached per destination. (Refer [PCE-P2MP-PER-DEST])
3.4.6. HPCE 4.6. Hierarchical PCE
As per [PCE-HIERARCHY-FWK], consider a case as shown in Figure 4 As per [RFC6805], consider a case as shown in Figure 4 consisting of
consisting of multiple child PCEs and a parent PCE. multiple child PCEs and a parent PCE.
+--------+ +--------+
| Parent | | Parent |
| PCE | | PCE |
+--------+ +--------+
+-------------------+ +-------------------+ +-------------------+ +-------------------+
| +--+ | | +--+ | | +--+ | | +--+ |
| +--+ | | | | | | | | +--+ | | | | | | |
| | | +--+ | | +--+ +--+ | | | | +--+ | | +--+ +--+ |
skipping to change at page 24, line 52 skipping to change at page 26, line 52
| + + +--+ | | + + +--+ |
| +--+ | | | | +--+ | | |
| | | | | +--+ | | | | | | +--+ |
| +--+ | | | | | | +--+ | | | | |
| | | +--+ | | | | +--+ |
| Area 1 | | Area 5 | | Area 1 | | Area 5 |
+------------------+ +--------------------+ +------------------+ +--------------------+
Figure 4: Hierarchical PCE Figure 4: Hierarchical PCE
In HPCE implementation the initiator PCE - PCE(1) can request the In H-PCE, the Ingress PCE PCE(1) can request the parent PCE to
parent PCE to determine the domain sequence and return in the path determine the Domain-Sequence and return it in the PCEP response,
computation reply message (PCRep), using the ERO Object. The ERO can using the ERO Object. The ERO can contain an ordered sequence of
contain an ordered sequence of sub-object such as AS and Area (OSPF/ subobjects such as AS and Area (OSPF/ISIS) subobjects. In this case,
ISIS). In this case, the PCRep would carry the domain sequence the Domain-Sequence appear as:
result as:
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|ERO | |Sub | |Sub | |Sub | |ERO | |Sub | |Sub | |Sub |
|Object | |Object | |Object | |Object | |Object | |Object | |Object | |Object |
|Header | |Area 2 | |Area 0 | |Area 4 | |Header | |Area 2 | |Area 0 | |Area 4 |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
|ERO | |Sub | |Sub | |Sub | |Sub | |ERO | |Sub | |Sub | |Sub | |Sub |
|Object | |Object As| |Object | |Object | |Object | |Object | |Object AS| |Object | |Object | |Object |
|Header | |100 | |Area 2 | |Area 0 | |Area 4 | |Header | |100 | |Area 2 | |Area 0 | |Area 4 |
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Note that, in the case of ERO objects, no new PCEP object type is Note that, in the case of ERO objects, no new PCEP object type is
required since the ordering constraint is assumed. required since the ordering constraint is assumed.
3.4.7. Relationship to PCE Sequence 4.7. Relationship to PCE Sequence
[RFC5886] and [PCE-P2MP-PROCEDURES] along with Domain Sequence Instead of a domain-sequence, a sequence of PCEs MAY be enforced by
introduces the concept of PCE-Sequence, where a sequence of PCEs, policy on the PCC, and this constraint can be carried in the PCEP
based on the domain sequence, should be decided and attached in the path computation request (as defined in [RFC5886]).
PCReq at the very beginning of path computation.
An alternative would be to use domain sequences, note that PCE- Note that PCE-Sequence can be used along with domain-sequence in
Sequence can be used along with domain-sequence in which case PCE- which case PCE-Sequence SHOULD have higher precedence in selecting
Sequence SHOULD have higher precedence in selecting the next PCE in the next PCE in the inter-domain path computation procedures. Note
the inter-domain path computation procedures. Note that Domain- that Domain-Sequence IRO constraints should still be checked as per
Sequence IRO constraints should still be checked as per the rules of the rules of processing IRO.
processing IRO.
4. IANA Considerations 4.8. Relationship to RSVP-TE
4.1. PCEP Objects [RFC3209] already describes the notion of abstract nodes, where an
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
Autonomous Systems (AS) (2-Byte).
[DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new
subobjects for IGP Areas and 4-byte AS numbers. These subobjects MAY
be included in Explicit Route Object (ERO), Exclude Route object
(XRO) or Explicit Exclusion Route Subobject (EXRS).
In any case subobject type defined in RSVP-TE are identical to the
subobject type defined in the related documents in PCEP.
5. IANA Considerations
5.1. PCEP Objects
The "PCEP Parameters" registry contains a subregistry "PCEP Objects". The "PCEP Parameters" registry contains a subregistry "PCEP Objects".
IANA is requested to make the following allocations from this IANA is requested to make the following allocations from this
registry. registry.
Object Name Reference Object Name Reference
Class Class
10 IRO [RFC5440] 10 IRO [RFC5440]
Object-Type Object-Type
(TBA): Domain Sequence [This I.D.] (TBA): Domain-Sequence [This I.D.]
4.2. New Sub-Objects 5.2. New Subobjects
The "PCEP Parameters" registry contains a subregistry "PCEP Objects" The "PCEP Parameters" registry contains a subregistry "PCEP Objects"
with an entry for the Include Route Object (IRO) and Exclude Route with an entry for the Include Route Object (IRO), Exclude Route
Object (XRO). IANA is requested to add further subobjects as Object (XRO) and Explicit Route Object (ERO). IANA is requested to
follows: add further subobjects as follows:
7 ERO
10 IRO
17 XRO
Subobject Type Reference Subobject Type Reference
TBA 4 octet AS number [This I.D.] TBA 4 byte AS number [This I.D.]
TBA OSPF Area ID [This I.D.] TBA OSPF Area ID [This I.D.]
TBA IS-IS Area ID [This I.D.] TBA IS-IS Area ID [This I.D.]
4.3. Error Object Field Values 5.3. Error Object Field Values
The "PCEP Parameters" registry contains a subregistry "Error Types The "PCEP Parameters" registry contains a subregistry "Error Types
and Values". IANA is requested to make the following allocations and Values". IANA is requested to make the following allocations
from this subregistry from this subregistry
ERROR Meaning Reference ERROR Meaning Reference
Type Type
TBA "Unrecognized subobject" [This I.D.] TBA "Unrecognized subobject" [This I.D.]
Error-Value: type code Error-Value: type code
5. Security Considerations 6. Security Considerations
This document specifies a standard representation of domain sequence, This document specifies a standard representation of Domain-Sequence
which MAYBE used in inter-domain PCE scenarios as explained in other and new subobjects, which MAY be used in inter-domain PCE scenarios
RFC and drafts. The new sub-objects and domain sequence mechanisms as explained in other RFC and drafts. The new subobjects and Domain-
defined in this document allow finer and more specific control of the Sequence mechanisms defined in this document allow finer and more
path computed by a cooperating PCE(s). Such control increases the specific control of the path computed by a cooperating PCE(s). Such
risk if a PCEP message is intercepted, modified, or spoofed because control increases the risk if a PCEP message is intercepted,
it allows the attacker to exert control over the path that the PCE modified, or spoofed because it allows the attacker to exert control
will compute or to make the path computation impossible. Therefore, over the path that the PCE will compute or to make the path
the security techniques described in [RFC5440] are considered more computation impossible. Therefore, the security techniques described
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.
6. Manageability Considerations 7. Manageability Considerations
6.1. Control of Function and Policy 7.1. Control of Function and Policy
Several local policy decisions should be made at the PCE. Firstly, Several local policy decisions should be made at the PCE. Firstly,
the exact behavior with regard to desired inclusion and exclusion of the exact behavior with regard to desired inclusion and exclusion of
domains must be available for examination by an operator and may be domains must be available for examination by an operator and may be
configurable. Second, the behavior on receipt of an unrecognized configurable. Second, the behavior on receipt of an unrecognized
sub-objects with the L or X-bit set should be configurable and must subobjects with the L or X-bit set should be configurable and must be
be available for inspection. The inspection and control of these available for inspection. The inspection and control of these local
local policy choices may be part of the PCEP MIB module. policy choices may be part of the PCEP MIB module.
6.2. Information and Data Models 7.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 [PCEP-MIB]. That MIB module allows examination of separate document [PCEP-MIB]. That MIB module allows examination of
individual PCEP messages, in particular requests, responses and individual PCEP messages, in particular requests, responses and
errors. The MIB module MUST be extended to include the ability to errors. The MIB module MUST be extended to include the ability to
view the domain-sequence extensions defined in this document. view the domain-sequence extensions defined in this document.
6.3. Liveness Detection and Monitoring 7.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].
6.4. Verify Correct Operations 7.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].
6.5. Requirements On Other Protocols 7.5. Requirements On Other Protocols
The Sub-objects defined in this document SHOULD be supported by RSVP The Subobjects defined in this document SHOULD be supported by RSVP
especially for per-domain path computation [RFC5152] where the especially for per-domain path computation [RFC5152] where the
domains need to encoded in the RSVP messages. domains need to encoded in the RSVP messages. [DOMAIN-SUBOBJ]
extends the notion of abstract nodes by adding 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].
6.6. Impact On Network Operations 7.6. Impact On Network Operations
Mechanisms defined in this document do not have any impact on network Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [RFC5440]. operations in addition to those already listed in [RFC5440].
7. Acknowledgments 8. Acknowledgments
We would like to thank Adrian Farrel, Pradeep Shastry, Suresh Babu, We would like to thank Adrian Farrel, Pradeep Shastry, Suresh Babu,
Quintin Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, Quintin Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo,
Venugopal Reddy, Reeja Paul and Sandeep Boina for their useful Venugopal Reddy, Reeja Paul and Sandeep Boina for their useful
comments and suggestions. comments and suggestions.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997. RFC 2119, March 1997.
[ISO 10589] ISO, "Intermediate system to Intermediate [ISO 10589] ISO, "Intermediate system to Intermediate
system routeing information exchange protocol system routing information exchange protocol
for use in conjunction with the Protocol for for use in conjunction with the Protocol for
providing the Connectionless-mode Network providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002. Service (ISO 8473)", ISO/IEC 10589:2002.
8.2. Informative References 9.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., and G. Swallow, "RSVP-TE: Srinivasan, V., and G. Swallow, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", RFC 3209, Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001. December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label [RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource Switching (GMPLS) Signaling Resource
ReserVation Protocol-Traffic Engineering ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions", RFC 3473, January 2003. (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling [RFC3477] Kompella, K. and Y. Rekhter, "Signalling
Unnumbered Links in Resource ReSerVation Unnumbered Links in Resource ReSerVation
skipping to change at page 30, line 5 skipping to change at page 32, line 22
[RFC5521] Oki, E., Takeda, T., and A. Farrel, [RFC5521] Oki, E., Takeda, T., and A. Farrel,
"Extensions to the Path Computation Element "Extensions to the Path Computation Element
Communication Protocol (PCEP) for Route Communication Protocol (PCEP) for Route
Exclusions", RFC 5521, April 2009. Exclusions", RFC 5521, April 2009.
[RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A
Set of Monitoring Tools for Path Computation Set of Monitoring Tools for Path Computation
Element (PCE)-Based Architecture", RFC 5886, Element (PCE)-Based Architecture", RFC 5886,
June 2010. June 2010.
[RFC6805] King, D. and A. Farrel, "The Application of
the Path Computation Element Architecture to
the Determination of a Sequence of Domains in
MPLS and GMPLS", RFC 6805, November 2012.
[PCE-P2MP-PROCEDURES] Zhao, Q., Dhody, D., Ali, Z., Saad,, T., [PCE-P2MP-PROCEDURES] Zhao, Q., Dhody, D., Ali, Z., Saad,, T.,
Sivabalan,, S., and R. Casellas, "PCE-based Sivabalan,, S., and R. Casellas, "PCE-based
Computation Procedure To Compute Shortest Computation Procedure To Compute Shortest
Constrained P2MP Inter-domain Traffic Constrained P2MP Inter-domain Traffic
Engineering Label Switched Paths (draft-ietf- Engineering Label Switched Paths (draft-ietf-
pce-pcep-inter-domain-p2mp-procedures-02)", pce-pcep-inter-domain-p2mp-procedures)",
February 2012. February 2012.
[PCE-HIERARCHY-FWK] King, D. and A. Farrel, "The Application of [PCEP-MIB] Koushik, A., Emile, S., Zhao, Q., King, D.,
the Path Computation Element Architecture to and J. Hardwick, "PCE communication
the Determination of a Sequence of Domains in protocol(PCEP) Management Information Base",
MPLS and GMPLS. July 2012.
(draft-ietf-pce-hierarchy-fwk-04)", June 2012.
[PCEP-MIB] Kiran Koushik, A S., Stephan, E., Zhao, Q., [PCE-P2MP-PER-DEST] Dhody, D., Palle, U., and V. Kondreddy,
and D. King, "PCE communication protocol(PCEP) "Supporting explicit inclusion or exclusion of
Management Information Base", July 2010. abstract nodes for a subset of P2MP
destinations in Path Computation Element
Communication Protocol (PCEP).
(draft-dhody-pce-pcep-p2mp-per-destination)",
Oct 2012.
[PCE-P2MP-PER-DEST] Dhody, D. and U. Palle, "Supporting explicit- [DOMAIN-SUBOBJ] Dhody, D., Palle, U., Kondreddy, V., and R.
path per destination in Path Computation Casellas, "Domain Subobjects for Resource
Element Communication Protocol (PCEP) P2MP ReserVation Protocol - Traffic Engineering
Path Request Message. (draft-dhody-pce-pcep- (RSVP-TE).
p2mp-per-destination-01)", Feb 2012.
(draft-dhody-ccamp-rsvp-te-domain-
subobjects)", Sept 2012.
Authors' Addresses Authors' Addresses
Dhruv Dhody Dhruv Dhody
Huawei Technologies India Pvt Ltd Huawei Technologies India Pvt Ltd
Leela Palace Leela Palace
Bangalore, Karnataka 560008 Bangalore, Karnataka 560008
INDIA INDIA
EMail: dhruv.dhody@huawei.com EMail: dhruv.dhody@huawei.com
 End of changes. 152 change blocks. 
398 lines changed or deleted 509 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/