draft-ietf-pce-pcep-domain-sequence-02.txt   draft-ietf-pce-pcep-domain-sequence-03.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
Expires: August 5, 2013 Ltd Expires: January 10, 2014 R. Casellas
R. Casellas CTTC
CTTC - Centre Tecnologic de July 9, 2013
Telecomunicacions de Catalunya
Feb 2013
Standard Representation Of Domain-Sequence Standard Representation Of Domain-Sequence
draft-ietf-pce-pcep-domain-sequence-02 draft-ietf-pce-pcep-domain-sequence-03
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. In this context, a domain is a
context, a domain is a collection of network elements within a common collection of network elements within a common sphere of address
sphere of address management or path computational responsibility management or path computational responsibility such as an Interior
such as an IGP area or an Autonomous Systems. This document Gateway Protocol (IGP) area or an Autonomous Systems (AS). This
specifies a standard representation and encoding of a Domain- document specifies a standard representation and encoding of a
Sequence, which is defined as an ordered sequence of domains Domain-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 to be used by Path
defines new subobjects to be used to encode domain identifiers. Computation Elements (PCEs) to compute inter-domain shortest
constrained paths across a predetermined sequence of domains . This
document also 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 August 5, 2013. This Internet-Draft will expire on January 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 31 skipping to change at page 3, line 31
3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 14 3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 14
3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . . 15 3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . . 15
3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 16 3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 16
3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 17 3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 17
4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 18 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 18
4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 18 4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 18
4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 20 4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 20
4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 20 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22
4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 24 4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 24
4.4. PCE serving multiple domains . . . . . . . . . . . . . . . 25 4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . . 25
4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . . 25 4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . . 25
4.7. Relationship to PCE Sequence . . . . . . . . . . . . . . . 27 4.7. Relationship to PCE Sequence . . . . . . . . . . . . . . . 27
4.8. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 27 4.8. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. New Subobjects . . . . . . . . . . . . . . . . . . . . . . 28 5.2. New Subobjects . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Error Object Field Values . . . . . . . . . . . . . . . . 28 5.3. Error Object Field Values . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Manageability Considerations . . . . . . . . . . . . . . . . . 29 7. Manageability Considerations . . . . . . . . . . . . . . . . . 29
skipping to change at page 4, line 14 skipping to change at page 4, line 14
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. Further for inter-domain point-
multi-point (P2MP) tree, [PCE-P2MP-PROCEDURES] assumes the domain- to-multi-point (P2MP) tree computation, [PCE-P2MP-PROCEDURES] assumes
tree is known. the domain-tree is known.
The list of domains (domain-sequence) in a point-to-point (P2P) path The list of domains (domain-sequence) in a point-to-point (P2P) path
or a point-to-multi-point (P2MP) tree is usually a constraint in the or a point-to-multi-point (P2MP) tree is usually a constraint in the
path computation request. The PCE determines the next PCE to forward path computation request. The PCE determines the next PCE to forward
the request based on the domain-sequence. the request based on the domain-sequence. In a multi-domain path
computation, a PCC MAY indicate the sequence of domains to be
In a multi-domain path computation, a PCC MAY indicate the sequence traversed using the Include Route Object (IRO) defined in [RFC5440].
of domains to be traversed using the Include Route Object (IRO)
defined in [RFC5440].
When the sequence of domains is not known in advance, the When the sequence of domains is not known in advance, the
Hierarchical PCE [RFC6805] architecture and mechanisms can be used to Hierarchical PCE (H-PCE) [RFC6805] architecture and mechanisms can be
determine the end-to-end Domain-Sequence. used to determine the end-to-end Domain-Sequence.
This document defines a standard way to represent and encode a This document defines a standard way to represent and encode a
Domain-Sequence in various deployment scenarios including P2P, P2MP Domain-Sequence in various deployment scenarios including P2P, P2MP
and Hierarchical PCE (H-PCE) [RFC6805]. and H-PCE.
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 (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. document.
[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 Number (AS) (2-Byte) as an abstract node representing Autonomous System (AS) (albeit with a 2-Byte AS number) as an
domain is defined in [RFC3209], This document specifies new abstract node representing domain is defined in [RFC3209], this
subobjects to include or exclude domains such as an IGP area or an document specifies new subobjects to include or exclude domains such
Autonomous Systems (4-Byte). as an IGP area or an Autonomous Systems (4-Byte as per [RFC4893]).
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 6, line 20 skipping to change at page 6, line 20
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
[RFC4726] and [RFC4655] define domain as a separate administrative or [RFC4726] and [RFC4655] define domain as a separate administrative or
geographic environment within the network. A domain may be further geographic environment within the network. A domain may be further
defined as a zone of routing or computational ability. Under these defined as a zone of routing or computational ability. Under these
definitions a domain might be categorized as an Autonomous System definitions a domain might be categorized as an AS or an IGP area.
(AS) or an Interior Gateway Protocol (IGP) area. Each AS can be made Each AS can be made of several IGP areas. In order to encode a
of several IGP areas. In order to encode a Domain-Sequence, it is Domain-Sequence, it is required to uniquely identify a domain in the
required to uniquely identify a domain in the Domain-Sequence. A Domain-Sequence. A domain can be uniquely identified by area-id or
domain can be uniquely identified by area-id or AS or both. 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. reach the destination domain.
A 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). A domain-sequence can also be the computation request to PCE(s). A domain-sequence can also be the
result of a path computation. For example, in the case of H-PCE result of a path computation. For example, in the case of H-PCE
[RFC6805] Parent PCE MAY send the Domain-Sequence as a result in a [RFC6805] Parent PCE MAY send the Domain-Sequence as a result in a
skipping to change at page 8, line 42 skipping to change at page 8, line 42
TBD OSPF Area id TBD OSPF Area id
TBD ISIS Area id TBD ISIS Area id
- Autonomous system - Autonomous system
[RFC3209] already defines 2 byte AS number. [RFC3209] already defines 2 byte AS number.
To support 4 byte AS number as per [RFC4893] following subobject is 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 defined in
[RFC3209].
Type: (TBA by IANA) indicating 4 byte AS Number. Type: (TBA by IANA) indicating a 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 byte AS Number. Note that if 16-bit AS numbers are in AS-ID: The 4-Byte AS Number. Note that if 2-Byte 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
order bits (0 through 15) should be set to zero. high order bits (0 through 15) should be set to zero.
- 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 defined in
[RFC3209].
Type: (TBA by IANA) indicating 4 byte OSPF Area ID. Type: (TBA by IANA) indicating a 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 byte 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// IS-IS Area ID // // IS-IS Area ID //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 defined in
[RFC3209].
Type: (TBA by IANA) indicating IS-IS Area ID. Type: (TBA by IANA) indicating IS-IS Area ID.
Length: Variable (Total length of the subobject in bytes including Length: Variable. As per [RFC3209], the total length of the
padding). The Length MUST be at least 4, and MUST be a multiple of subobject in bytes, including the L, Type and Length fields. The
4. Length MUST be at least 4, and MUST be a 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 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-byte boundary. with trailing zeroes to a four-byte boundary.
3.4.2. Option (A): New IRO Object Type 3.4.2. Option (A): New IRO Object Type
[RFC5440] in its description of IRO does not require the subobjects [RFC5440] in its description of IRO does not require the subobjects
to be in a given particular order. When considering a Domain- to be in a given particular order. When considering a Domain-
Sequence, the domain relative ordering is a basic criterion and, as Sequence, the domain relative ordering is a basic criterion and, as
such, this option suggest a new IRO object type. 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)
skipping to change at page 11, line 9 skipping to change at page 11, line 20
Boundary Node (ABR/ASBR) and Inter-AS-Links. The subobjects 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 subobjects similar to handle the L bit (Loose / Strict) in the subobjects similar to
[RFC3209]. [RFC3209].
Further we have following options: Further we have following options:
* Option (A.1): New IRO Object Type for Domain-Sequence object only * Option (A.1): New IRO Object Type for Domain-Sequence object only.
A new IRO Object Type is used to specify the ordered sequence of
A new IRO Object Type is used to specify the ordered sequence of domains (Domain-Sequence) only. The PCReq message is modified to
domains (Domain-Sequence) only. The PCReq message is modified to allow encoding of both types of IRO; one with IRO Type 1 [RFC5440]
allow encoding of both types of IRO; one with IRO Type 1 [RFC5440] used to specify the intra-domain abstract nodes and resources and
used to specify the intra-domain abstract nodes and resources and the the second IRO Type with the new subobjects as described in this
second IRO Type with the new subobjects as described in this section section to specify the domain-sequence. All other rules of PCEP
to specify the domain-sequence. objects and message processing (ex. P bit handling of Common
Object Header) is as per [RFC5440].
All other rules of PCEP objects and message processing (ex. P bit
handling of Common Object Header) is as per [RFC5440].
* Option (A.2): New IRO Object Type for both intra and inter-domain
(domain-sequence)
A new IRO Object Type is used to include both intra nodes and inter-
domains nodes but the sequence of domain is strict. The intra-domain
nodes can still be ordered.
In case of inter-domain path computation, only the new IRO type is * Option (A.2): New IRO Object Type for both intra and inter-domain
used which contains the specific intra domain network nodes as well (domain-sequence). A new IRO Object Type is used to include both
as inter-domain abstract nodes or domains. The inter-domain abstract intra nodes and inter-domains nodes but the sequence of domain is
nodes are encoded in the sequence they must be traversed but the strict. The intra-domain nodes can still be ordered. In case of
intra-domain elements MAY be an unordered set. inter-domain path computation, only the new IRO type is 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 3.4.2.1. Handling of the Domain-Sequence IRO object
An IRO object containing Domain-Sequence subobjects constraints or An IRO object containing Domain-Sequence subobjects constraints or
defines the domains involved in a multi-domain path computation, defines the domains involved in a multi-domain path computation,
typically involving two or more collaborative PCEs. 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 areas for a identifiers. It is also possible to list the involved areas for a
skipping to change at page 13, line 21 skipping to change at page 13, line 26
o A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is o A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is
used to identify the next domain. (Refer Figure 1) used to identify the next domain. (Refer Figure 1)
o A single 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 Both an AS and an IGP Area: Combination of both AS and Area are o Both an AS and an IGP Area: Combination of both AS and Area are
used to identify the next domain. In this case the order is AS used to identify the next domain. In this case the order is AS
Subobject followed by Area. (Refer Figure 3) Subobject followed by Area. (Refer Figure 3)
Subobject of other types representing Boundary Node or Inter-AS-Link Subobject representing Boundary Node or Inter-AS-Link MUST be applied
do not pay any role in the selection of next domain, but they MUST be during the final path computation procedure as before.
applied during the final path computation procedure as before.
3.4.3. Option B: Existing 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 network elements that the computed path MUST to specify a set of network elements that the computed path MUST
traverse. traverse.
The new subobjects denoting the domain-sequence are 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.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Id (4 bytes) | | AS-ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The X-bit indicates whether the exclusion is mandatory or desired. The X-bit indicates whether the exclusion is mandatory or desired.
0 indicates that the AS specified MUST be excluded from the path 0: indicates that the AS specified MUST be excluded from the path
computed by the PCE(s). computed by the PCE(s).
1 indicates that the AS specified SHOULD be avoided from the inter- 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 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 PCE policy and the absence of a viable path that meets the other
constraints. 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.
3.5.1.2. IGP Area 3.5.1.2. 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 is encoded For OSPF, the area-id is a 32 bit number. The subobject is encoded
as follows: 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The X-bit indicates whether the exclusion is mandatory or desired. The X-bit indicates whether the exclusion is mandatory or desired.
0 indicates that the OSFF Area specified MUST be excluded from the 0: indicates that the OSFF Area specified MUST be excluded from the
path computed by the PCE(s). path computed by the PCE(s).
1 indicates that the OSFF Area specified SHOULD be avoided from the 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 inter-domain path computed by the PCE(s), but MAY be included
to PCE policy and the absence of a viable path that meets the other subject to PCE policy and the absence of a viable path that meets
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.
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]. The subobject is encoded as follows: 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. The X-bit indicates whether the exclusion is mandatory or desired.
0 indicates that the ISIS Area specified MUST be excluded from the 0: indicates that the ISIS Area specified MUST be excluded from the
path computed by the PCE(s). path computed by the PCE(s).
1 indicates that the ISIS Area specified SHOULD be avoided from the 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 inter-domain path computed by the PCE(s), but MAY be included
to PCE policy and the absence of a viable path that meets the other subject to PCE policy and the absence of a viable path that meets
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.
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.
skipping to change at page 25, line 15 skipping to change at page 25, line 15
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 | | |
| | | | | | | | | | | | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
4.4. PCE serving multiple domains 4.4. PCE Serving multiple Domains
A single PCE MAY be responsible for multiple domains; for example PCE A single PCE MAY be responsible for multiple domains; for example PCE
function deployed on an ABR. A PCE which can support 2 adjacent function deployed on an ABR. A PCE which can support 2 adjacent
domains can internally handle this situation without any impact on domains can internally handle this situation without any impact on
the neighboring domains. the neighboring domains.
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
skipping to change at page 27, line 31 skipping to change at page 27, line 31
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
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.
4.7. Relationship to PCE Sequence 4.7. 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 PCEP policy on the PCC, and this constraint can be carried in the PCReq
path computation request (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 SHOULD have higher precedence in selecting which case PCE-Sequence SHOULD have higher precedence in selecting
the next PCE in the inter-domain path computation procedures. Note the next PCE in the inter-domain path computation procedures. Note
that Domain-Sequence IRO constraints should still be checked as per that Domain-Sequence IRO constraints should still be checked as per
the rules of processing IRO. the rules of processing IRO.
4.8. Relationship to RSVP-TE 4.8. 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
Autonomous Systems (AS) (2-Byte). 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 MAY subobjects for IGP Areas and 4-byte AS numbers. These subobjects MAY
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). (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 5. IANA Considerations
5.1. PCEP Objects 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
skipping to change at page 30, line 13 skipping to change at page 30, line 13
listed in [RFC5440]. listed in [RFC5440].
7.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].
7.5. Requirements On Other Protocols 7.5. Requirements On Other Protocols
The Subobjects defined in this document SHOULD be supported by RSVP In case of per-domain path computation [RFC5152], where the full path
especially for per-domain path computation [RFC5152] where the of an inter-domain TE LSP cannot be or is not determined at the
domains need to encoded in the RSVP messages. [DOMAIN-SUBOBJ] ingress node, and signaling message may use domain identifiers. The
extends the notion of abstract nodes by adding new subobjects for IGP Subobjects defined in this document SHOULD be supported by RSVP-TE.
Areas and 4-byte AS numbers. [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].
7.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].
skipping to change at page 30, line 43 skipping to change at page 30, line 44
comments and suggestions. comments and suggestions.
9. References 9. References
9.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
system routing information exchange protocol
for use in conjunction with the Protocol for
providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002.
9.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 32, line 33 skipping to change at page 32, line 28
the Path Computation Element Architecture to the Path Computation Element Architecture to
the Determination of a Sequence of Domains in the Determination of a Sequence of Domains in
MPLS and GMPLS", RFC 6805, November 2012. 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)", pce-pcep-inter-domain-p2mp-procedures)",
February 2012. May 2013.
[PCEP-MIB] Koushik, A., Emile, S., Zhao, Q., King, D., [PCEP-MIB] Koushik, A., Emile, S., Zhao, Q., King, D.,
and J. Hardwick, "PCE communication and J. Hardwick, "PCE communication
protocol(PCEP) Management Information Base", protocol(PCEP) Management Information Base",
July 2012. Feb 2013.
[PCE-P2MP-PER-DEST] Dhody, D., Palle, U., and V. Kondreddy, [PCE-P2MP-PER-DEST] Dhody, D., Palle, U., and V. Kondreddy,
"Supporting explicit inclusion or exclusion of "Supporting explicit inclusion or exclusion of
abstract nodes for a subset of P2MP abstract nodes for a subset of P2MP
destinations in Path Computation Element destinations in Path Computation Element
Communication Protocol (PCEP). Communication Protocol (PCEP).
(draft-dhody-pce-pcep-p2mp-per-destination)", (draft-dhody-pce-pcep-p2mp-per-destination)",
Oct 2012. April 2013.
[DOMAIN-SUBOBJ] Dhody, D., Palle, U., Kondreddy, V., and R. [DOMAIN-SUBOBJ] Dhody, D., Palle, U., Kondreddy, V., and R.
Casellas, "Domain Subobjects for Resource Casellas, "Domain Subobjects for Resource
ReserVation Protocol - Traffic Engineering ReserVation Protocol - Traffic Engineering
(RSVP-TE). (RSVP-TE).
(draft-dhody-ccamp-rsvp-te-domain- (draft-dhody-ccamp-rsvp-te-domain-
subobjects)", Sept 2012. subobjects)", July 2013.
[ISO 10589] ISO, "Intermediate system to Intermediate
system routing information exchange protocol
for use in conjunction with the Protocol for
providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002.
Authors' Addresses Authors' Addresses
Dhruv Dhody Dhruv Dhody
Huawei Technologies India Pvt Ltd Huawei Technologies
Leela Palace Leela Palace
Bangalore, Karnataka 560008 Bangalore, Karnataka 560008
INDIA INDIA
EMail: dhruv.dhody@huawei.com EMail: dhruv.dhody@huawei.com
Udayasree Palle Udayasree Palle
Huawei Technologies India Pvt Ltd Huawei Technologies
Leela Palace Leela Palace
Bangalore, Karnataka 560008 Bangalore, Karnataka 560008
INDIA INDIA
EMail: udayasree.palle@huawei.com EMail: udayasree.palle@huawei.com
Ramon Casellas Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya CTTC
Av. Carl Friedrich Gauss n7 Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860 Castelldefels, Barcelona 08860
SPAIN SPAIN
EMail: ramon.casellas@cttc.es EMail: ramon.casellas@cttc.es
 End of changes. 61 change blocks. 
144 lines changed or deleted 139 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/