draft-ietf-pce-pcep-xro-00.txt   draft-ietf-pce-pcep-xro-01.txt 
Network Working Group E. Oki Network Working Group E. Oki
Internet Draft NTT Internet Draft NTT
Category: Standards Track A. Farrel Category: Standards Track A. Farrel
Expires: October 2007 Old Dog Consulting Expires: January 2008 Old Dog Consulting
Extensions to the Path Computation Element Communication Protocol Extensions to the Path Computation Element Communication Protocol
(PCEP) for Route Exclusions (PCEP) for Route Exclusions
draft-ietf-pce-pcep-xro-00.txt draft-ietf-pce-pcep-xro-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The Path Computation Element (PCE) provides functions of path The Path Computation Element (PCE) provides functions of path
computation in support of traffic engineering in Multi-Protocol computation in support of traffic engineering in Multi-Protocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
When a Path Computation Client (PCC) requests a PCE for a route, it When a Path Computation Client (PCC) requests a PCE for a route, it
may be useful for the PCC to specify as constraints to the path may be useful for the PCC to specify, as constraints to the path
computation abstract nodes, resources, and Shared Risk Link Groups computation abstract nodes, resources, and Shared Risk Link Groups
(SRLGs) that are to be explicitly excluded from routes. Such (SRLGs) that are to be explicitly excluded from the computed route.
constraints are termed route exclusions. Such constraints are termed route exclusions.
The PCE Communication Protocol (PCEP) is designed as a communication The PCE Communication Protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs. This document presents PCEP protocol between PCCs and PCEs. This document presents PCEP
extensions for route exclusions. extensions for route exclusions.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 this document are to be interpreted as described in RFC 2119
[RFC2119]. [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Protocol Procedures and Extensions.............................3 2. Protocol Procedures and Extensions.............................3
2.1. Exclude Route Object (XRO)..................................4 2.1. Exclude Route Object (XRO)..................................3
2.2.1. Processing Rules..........................................7 2.1.1. Definition................................................3
2.1.2. Processing Rules..........................................7
2.2. Explicit Route Exclusion....................................8 2.2. Explicit Route Exclusion....................................8
2.2.1. Processing Rules...........................................9 2.2.1. Definition..................................................8
3. IANA Considerations...........................................10 2.2.2. Processing Rules............................................8
3.1. PCEP Objects...............................................10 3. Exclude Route with Confidentiality.............................9
3.2. Error Object Field Values..................................10 3.1. Exclude Route Object (XRO) carrying Path Key................9
4. Manageability considerations..................................10 3.3.1. Definition..................................................9
5. Security Considerations.......................................11 3.3.2. Processing Rules...........................................10
6. References....................................................11 4. IANA Considerations...........................................10
6.1. Normative Reference........................................11 4.1. PCEP Objects...............................................10
6.2. Informative Reference......................................11 4.2. Error Object Field Values..................................11
7. Authors?EAddresses............................................11 5. Manageability considerations..................................11
6. Security Considerations.......................................11
7. References....................................................11
7.1. Normative Reference........................................11
7.2. Informative Reference......................................12
8. Acknowledgements..............................................12
9. AuthorsEAddresses............................................12
10. Intellectual Property Statement.............................12
1. Introduction 1. Introduction
The Path Computation Element (PCE) defined in [RFC4655] is an entity The Path Computation Element (PCE) defined in [RFC4655] is an entity
that is capable of computing a network path or route based on a that is capable of computing a network path or route based on a
network graph, and applying computational constraints. A Path network graph, and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be Computation Client (PCC) may make requests to a PCE for paths to be
computed. computed.
When a PCC requests a PCE for a route, it may be useful for the PCC When a PCC requests a PCE for a route, it may be useful for the PCC
to specify abstract nodes, resources, and Shared Risk Link Groups to specify abstract nodes, resources, and Shared Risk Link Groups
(SRLGs) that are to be explicitly excluded from the route. (SRLGs) that are to be explicitly excluded from the route.
For example, disjoint paths for inter-domain LSPs may be computed by For example, disjoint paths for inter-domain LSPs may be computed by
cooperation between PCEs, each of which computes segments of the cooperation between PCEs, each of which computes segments of the
paths across one domain. In order to achieve path computation for a paths across one domain. In order to achieve path computation for a
secondary (backup) path, a PCE may act as a PCC to request another secondary (backup) path, a PCE may act as a PCC to request another
PCE for a route that must be a node/link/SRLG disjoint from the PCE for a route that must be a node/link/SRLG disjoint from the
primary (working) path. Another example is where a network operator primary (working) path. Another example is where a network operator
wants path to avoid specified nodes for administrative reasons wants a path to avoid specified nodes for administrative reasons,
perhaps because the specified nodes will be out-of-services in near perhaps because the specified nodes will be out-of-services in the
future. near future.
[RFC4657] specifies generic requirements for a communication [RFC4657] specifies generic requirements for a communication
protocol between PCCs and PCEs. Generic constraints described in protocol between PCCs and PCEs. Generic constraints described in
[RFC4657] include route exclusions for links, nodes, and SRLGs. That [RFC4657] include route exclusions for links, nodes, and SRLGs. That
is, the requirement for support of route exclusions within the PCC- is, the requirement for support of route exclusions within the PCC-
PCE communication protocol is already established. PCE communication protocol is already established.
Oki and Farrel Expires January 2008 2
The PCE communication protocol (PCEP) is designed as a communication The PCE communication protocol (PCEP) is designed as a communication
protocol between PCCs and PCEs and is defined in [PCEP]. This protocol between PCCs and PCEs and is defined in [PCEP]. This
document presents PCEP extensions to satisfy the requirements for document presents PCEP extensions to satisfy the requirements for
route exclusions as described in Sections 5.1.4 and 5.1.16 of route exclusions as described in Sections 5.1.4 and 5.1.16 of
[RFC4657]. [RFC4657].
Note that MPLS-TE and GMPLS signaling extensions for communicating Note that MPLS-TE and GMPLS signaling extensions for communicating
route exclusions between network nodes for specific Label Switched route exclusions between network nodes for specific Label Switched
Paths (LSPs) are described in [XRO]. Route exclusions may be Paths (LSPs) are described in [RFC4874]. Route exclusions may be
specified during provisioning requests for specific LSPs using the specified during provisioning requests for specific LSPs setting the
mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in [RFC3812]. mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in [RFC3812]
to false.
2. Protocol Procedures and Extensions 2. Protocol Procedures and Extensions
This section describes the procedures adopted by a PCE handling a This section describes the procedures adopted by a PCE handling a
request for path computation with route exclusions received from a request for path computation with route exclusions received from a
PCC, and defines how those exclusions are encoded. PCC, and defines how those exclusions are encoded.
There are two types of route exclusion described in [XRO]. There are two types of route exclusion described in [RFC4874].
1. Exclusion of certain abstract nodes or resources on the whole 1. Exclusion of certain abstract nodes or resources on the whole
path. This set of abstract nodes is referred to as the Exclude path. This set of abstract nodes is referred to as the Exclude
Route List. Route List.
2. Exclusion of certain abstract nodes or resources between a 2. Exclusion of certain abstract nodes or resources between a
specific pair of abstract nodes present in an explicit path. Such specific pair of abstract nodes present in an explicit path. Such
specific exclusions are referred to as an Explicit Route specific exclusions are referred to as an Explicit Route
Exclusion. Exclusion.
skipping to change at page 4, line 7 skipping to change at line 153
request. request.
A new PCEP object is defined as the Exclude Route Object (XRO) to A new PCEP object is defined as the Exclude Route Object (XRO) to
convey the Exclude Route List. The existing Include Route Object convey the Exclude Route List. The existing Include Route Object
(IRO) in PCEP [PCEP] is modified by introducing a new IRO subobject, (IRO) in PCEP [PCEP] is modified by introducing a new IRO subobject,
the Explicit Exclusion Route Subobject (EXRS), to convey Explicit the Explicit Exclusion Route Subobject (EXRS), to convey Explicit
Route Exclusions. Route Exclusions.
2.1. Exclude Route Object (XRO) 2.1. Exclude Route Object (XRO)
2.1.1. Definition
The XRO is OPTIONAL and MAY be carried within PCReq and PCRep The XRO is OPTIONAL and MAY be carried within PCReq and PCRep
messages. messages.
When present in a PCReq message, the XRO provides a list of network When present in a PCReq message, the XRO provides a list of network
resources that the PCE is requested to exclude from the path that it resources that the PCE is requested to exclude from the path that it
computes. Flags associated with each list member instruct the PCE as computes. Flags associated with each list member instruct the PCE as
to whether the network resources must be excluded from the computed to whether the network resources must be excluded from the computed
path or whether the PCE should make best efforts to exclude the path or whether the PCE should make best efforts to exclude the
resources from the computed path. resources from the computed path.
Oki and Farrel Expires January 2008 3
The XRO MAY be used on PCRep message with the NO-PATH object to The XRO MAY be used on PCRep message with the NO-PATH object to
indicate the set of elements of the original XRO that prevented the indicate the set of elements of the original XRO that prevented the
PCE from finding a path. The XRO MAY also be used on a PCRep message PCE from finding a path. The XRO MAY also be used on a PCRep message
for a successful path computation when the PCE wishes to provide a for a successful path computation when the PCE wishes to provide a
set of exclusions to be signaled during LSP setup. set of exclusions to be signaled during LSP setup using the
extensions to RSVP-TE [RFC4874].
XRO Object-Class is to be assigned by IANA (recommended value=17) The XRO Object-Class is to be assigned by IANA (recommended
value=17)
XRO Object-Type is to be assigned by IANA (recommended value=1) The XRO Object-Type is to be assigned by IANA (recommended value=1)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// (Subobjects) // // (Subobjects) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: XRO body format Figure 1: XRO body format
Flags: 16 bits - The following flags are currently defined:
F (Fail - 1 bit): when set, the requesting PCC requires the
computation of a new path for an existing TE LSP that has failed. If
the F bit is set, the path of the existing TE LSP MUST be provided
in the PCReq message by means of an RRO object defined in [PCEP].
This allows the path computation to take into account the previous
path and reserved resources to avoid double bandwidth booking should
the TED have not yet been updated or the corresponding resources not
be yet been released. This will usually be used in conjunction with
the exclusion from the path computation of the failed resource that
caused the LSP to fail.
Subobjects. The XRO is up made of one or more subobject(s). An XRO Subobjects. The XRO is up made of one or more subobject(s). An XRO
with no subobjects MUST not be sent and SHOULD be ignored on receipt. with no subobjects MUST NOT be sent and SHOULD be ignored on receipt.
In the following subobject definitions a set of fields have In the following subobject definitions a set of fields have
consistent meaning as follows: consistent meaning as follows:
X X
The X-bit indicates whether the exclusion is mandatory or The X-bit indicates whether the exclusion is mandatory or
desired. 0 indicates that the resource specified MUST be desired. 0 indicates that the resource specified MUST be
excluded from the path computed by the PCE 1 indicates that the excluded from the path computed by the PCE. 1 indicates that
resource specified SHOULD be excluded from the path computed by the resource specified SHOULD be excluded from the path
the PCE, but MAY be included subject to PCE policy and the computed by the PCE, but MAY be included subject to PCE policy
absence of a viable path that meets the other other constraints and the absence of a viable path that meets the other
and excludes the resource. constraints and excludes the resource.
Oki and Farrel Expires January 2008 4
Type Type
The type of the subobject. The following subobject types are The type of the subobject. The following subobject types are
defined. defined.
Type Subobject Type Subobject
-------------+------------------------------- -------------+-------------------------------
1 IPv4 prefix 1 IPv4 prefix
2 IPv6 prefix 2 IPv6 prefix
3 Unnumbered Interface ID 3 Unnumbered Interface ID
4 Autonomous system number 4 Autonomous system number
skipping to change at page 5, line 49 skipping to change at line 263
The subobject is to be interpreted as a node or set of nodes. The subobject is to be interpreted as a node or set of nodes.
All nodes identified by the subobject are to be excluded from All nodes identified by the subobject are to be excluded from
the computed path according to the setting of the X-bit. This the computed path according to the setting of the X-bit. This
value is valid only for subobject types 1, 2, 3, and 4. value is valid only for subobject types 1, 2, 3, and 4.
2 SRLG 2 SRLG
The subobject identifies an SRLG explicitly or indicates all The subobject identifies an SRLG explicitly or indicates all
of the SRLGs associated with the resource or resources of the SRLGs associated with the resource or resources
identified by the subobject. Resources that share any SRLG identified by the subobject. Resources that share any SRLG
with those identified are to be excluded from the computed with those identified are to be excluded from the computed
path according to the setting of the X-bit. This value is path according to the setting
valid for all subobjects. of the X-bit. This value is valid for all subobjects.
Reserved Reserved
Reserved fields MUST be transmitted as zero and SHOULD be Reserved fields MUST be transmitted as zero and SHOULD be
ignored on receipt. ignored on receipt.
The subobjects are encoded as follows: The subobjects are encoded as follows:
Oki and Farrel Expires January 2008 5
IPv4 prefix Subobject IPv4 prefix Subobject
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 = 1 | Length | IPv4 address (4 bytes) | |X| Type = 1 | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Attribute | | IPv4 address (continued) | Prefix Length | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 18 skipping to change at line 327
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 = 4 | Length | Reserved | Attribute | |X| Type = 4 | Length | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional AS Number High Octets| 2-Octet AS Number | | Optional AS Number High Octets| 2-Octet AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a two-octet AS number is used, the optional AS Number High If a two-octet AS number is used, the optional AS Number High
Octets MUST be set to zero. Octets MUST be set to zero.
Oki and Farrel Expires January 2008 6
SRLG Subobject SRLG Subobject
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 = 5 | Length | SRLG Id (4 bytes) | |X| Type = 5 | Length | SRLG Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG Id (continued) | Reserved | Attribute | | SRLG Id (continued) | Reserved | Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute SHOULD be set to two (2) and SHOULD be ignored on The Attribute SHOULD be set to two (2) and SHOULD be ignored on
receipt. receipt.
2.2.1. Processing Rules 2.1.2. Processing Rules
A PCC builds an XRO to encode all of the resources that it wishes A PCC builds an XRO to encode all of the resources that it wishes
the PCE to exclude from the path that it is requested to compute. the PCE to exclude from the path that it is requested to compute.
For each exclusion, the PCC clears the X-bit to indicate that the For each exclusion, the PCC clears the X-bit to indicate that the
PCE is required to exclude the resources, or sets the X-bit to PCE is required to exclude the resources, or sets the X-bit to
indicate that the PCC simply desires that the resources are excluded. indicate that the PCC simply desires that the resources are excluded.
For each exclusion, the PCC also sets the Attribute field to For each exclusion, the PCC also sets the Attribute field to
indicate how the PCE should interpret the contents of the exclusion indicate how the PCE should interpret the contents of the exclusion
subobject. subobject.
skipping to change at page 8, line 12 skipping to change at line 371
a PCErr message with the Error-Type "Not supported object" and a PCErr message with the Error-Type "Not supported object" and
follow the relevant procedures described in [PCEP]. follow the relevant procedures described in [PCEP].
If the PCE processes the XRO and attempts to compute a path, it MUST If the PCE processes the XRO and attempts to compute a path, it MUST
adhere to the requested exclusions as expressed in the XRO. That is, adhere to the requested exclusions as expressed in the XRO. That is,
the returned path MUST NOT include any resources encoded with the X- the returned path MUST NOT include any resources encoded with the X-
bit clear, and SHOULD NOT include any with the X-bit set unless bit clear, and SHOULD NOT include any with the X-bit set unless
alternate paths that match the other constraints expressed in the alternate paths that match the other constraints expressed in the
PCReq are unavailable. PCReq are unavailable.
When a PCE returns a path in a PCRep it MAY also supply an XRO. In When a PCE returns a path in a PCRep it MAY also supply an XRO. An
this case, the PCC SHOULD apply the contents using the same rules as XRO in a PCRep message with the NO-PATH object indicates that the
in [XRO] and SHOULD signal the an RSVP-TE XRO to indicate the set of elements of the original XRO prevented the PCE from finding a
exclusions that downstream LSRs should apply. This may be path. On the other hand, if an XRO is present in a PCRep message
particularly useful in per-domain path computation scenarios. [Note without a NO-PATH object, the PCC SHOULD apply the contents using
that this does not match the behavior for an explicit path where an the same rules as in [RFC4874] and the PCC or a corresponding LSR
IRO is used to force inclusions and an ERO is used to report a SHOULD signal an RSVP-TE XRO to indicate the exclusions that
computed path. We could consider using a separate object to report downstream LSRs should apply. This may be particularly useful in
the XRO that should be signaled.] per-domain path computation scenarios.
Oki and Farrel Expires January 2008 7
In the event that no suitable path can be computed and the PCE In the event that no suitable path can be computed and the PCE
returns a PCRep message containing a NO-PATH object, the PCE MAY returns a PCRep message containing a NO-PATH object, the PCE MAY
also include an XRO that lists one or more subobjects from the also include an XRO that lists one or more subobjects from the
original XRO that have contributed to the PCE's inability to select original XRO that have contributed to the PCE's inability to select
a path. a path.
2.2. Explicit Route Exclusion 2.2. Explicit Route Exclusion
2.2.1. Definition
Explicit Route Exclusion defines network elements that must not or Explicit Route Exclusion defines network elements that must not or
should not be used on the path between two abstract nodes or should not be used on the path between two abstract nodes or
resources explicitly indicated in the Include Route Object (IRO) resources explicitly indicated in the Include Route Object (IRO)
[PCEP]. This information is encoded by defining a new subobject for [PCEP]. This information is encoded by defining a new subobject for
the IRO . the IRO .
The new IRO subobject, the Explicit Exclusion Route Subobject (EXRS), The new IRO subobject, the Explicit Exclusion Route Subobject (EXRS),
has type defined by IANA (see Section 3.). The EXRS contains one or has type defined by IANA (see Section 3.). The EXRS contains one or
more subobjects in its own right. An EXRS MUST NOT be sent with no more subobjects in its own right. An EXRS MUST NOT be sent with no
subobjects, and if received with no subobjects MUST be ignored. subobjects, and if received with no subobjects MUST be ignored.
skipping to change at page 9, line 19 skipping to change at line 428
MUST be set to zero on transmission and MUST be ignored on MUST be set to zero on transmission and MUST be ignored on
receipt. receipt.
The EXRS subobject may carry any of the subobjects defined for The EXRS subobject may carry any of the subobjects defined for
inclusion in the XRO by this document or by future documents. The inclusion in the XRO by this document or by future documents. The
meanings of the fields of the XRO subobjects are unchanged when the meanings of the fields of the XRO subobjects are unchanged when the
subobjects are included in an EXRS, except that scope of the subobjects are included in an EXRS, except that scope of the
exclusion is limited to the single hop between the previous and exclusion is limited to the single hop between the previous and
subsequent elements in the IRO. subsequent elements in the IRO.
2.2.1. Processing Rules 2.2.2. Processing Rules
A PCC that supplies a partial explicit route to a PCE in an IRO MAY A PCC that supplies a partial explicit route to a PCE in an IRO MAY
also specify explicit exclusions by including one or more EXRSes in also specify explicit exclusions by including one or more EXRSes in
the IRO. the IRO.
If a PCE parses an IRO in a received PCReq message and encounters an If a PCE parses an IRO in a received PCReq message and encounters an
EXRS and does not recognize the subobject it MUST respond with a EXRS and does not recognize the subobject it MUST respond with a
PCErr message using the Error-Type "Unrecognized IRO subobject" and PCErr message using the Error-Type "Unrecognized IRO subobject" and
set the Error-Value to the subobject type code of the EXRS (see set the Error-Value to the subobject type code of the EXRS (see
Section 3). Section 3).
Oki and Farrel Expires January 2008 8
If a PCE parses an IRO and encounters an EXRS that it recognizes, If a PCE parses an IRO and encounters an EXRS that it recognizes,
but detects an EXRS subobject that it does not recognize it MUST act but detects an EXRS subobject that it does not recognize it MUST act
according to the setting of the X-bit in the subobject. If the X-bit according to the setting of the X-bit in the subobject. If the X-bit
is clear, the PCE MUST respond with a PCErr with Error-Type is clear, the PCE MUST respond with a PCErr with Error-Type
"Unrecognized EXRS subobject" and set the Error-Value to the EXRS "Unrecognized EXRS subobject" and set the Error-Value to the EXRS
subobject type code (see Section 3). If the X-bit is set, the PCE subobject type code (see Section 3). If the X-bit is set, the PCE
MAY respond with a PCErr as already stated or MAY ignore the EXRS MAY respond with a PCErr as already stated or MAY ignore the EXRS
subobject: this choice is a local policy decision. subobject: this choice is a local policy decision.
If a PCE parses an IRO and encounters an EXRS subobject that it If a PCE parses an IRO and encounters an EXRS subobject that it
skipping to change at page 10, line 5 skipping to change at line 465
and the next abstract node in the IRO. If the X-bit is set, the PCE and the next abstract node in the IRO. If the X-bit is set, the PCE
SHOULD NOT produce a path that includes any resource identified by SHOULD NOT produce a path that includes any resource identified by
the EXRS subobject in the path between the previous abstract node in the EXRS subobject in the path between the previous abstract node in
the IRO and the next abstract node in the IRO unless it is not the IRO and the next abstract node in the IRO unless it is not
possible to construct a path that avoids that resource while still possible to construct a path that avoids that resource while still
complying with the other constraints expressed in the PCReq message. complying with 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 PCRep message MUST
include an ERO to specify the path that has been computed. That ERO include an ERO to specify the path that has been computed. That ERO
MAY contain specific route exclusions using the EXRS as specified in MAY contain specific route exclusions using the EXRS as specified in
[XRO]. [RFC4874].
If the path computation fails and a PCErr is returned with a NO-PATH If the path computation fails and a PCErr is returned with a NO-PATH
object, the PCE MAY include an IRO to report the hops that could not object, the PCE MAY include an IRO to report the hops that could not
be complied with, and that IRO MAY include EXRSes. be complied with, and that IRO MAY include EXRSes.
3. IANA Considerations 3. Exclude Route with Confidentiality
3.1. PCEP Objects 3.1. Exclude Route Object (XRO) carrying Path Key
3.3.1. Definition
In PCE-based inter-domain diverse path computation, an XRO may be
used to find a backup (secondary) path. A sequential path
computation approach may be applied for this purpose, where a
working (primary) path route is computed first and a backup path
route that must be a node/link/SRLG disjoint route from the working
path is then computed [INTER-DOMAIN-REC-ANA]. Backward Recursive
Path Computation (BRPC) may be used for inter-domain path
computation [BRPC].
In some cases of inter-domain computation (e.g., where domains are
administered by different service providers), confidentiality must
be kept. For primary path computation, to preserve confidentiality,
instead of explicitly expressing the computed route, Path Key
Subobjects (PKSs) [PCE-PATH-KEY] are carried in the Explicit Route
Object (ERO) in the PCRep Message.
Therefore, during inter-domain diverse path computation, it may be
necessary to request diversity from a path that is not fully known
and where a segment of the path is represented by a PKS. This means
that a PKS may be present as a subobject of the XRO on a PCReq
message.
Oki and Farrel Expires January 2008 9
The format and definition of PKS when it appears as an XRO subobject
are as defined in [PCE-PATH-KEY], except for the definition of L bit.
The L bit of the PKS subobject in the XRO is defined as follows.
L
The L bit MUST be ignored.
3.3.2. Processing Rules
Consider that BRPC is applied for both working and backup path
computation in a sequential manner. First, PCC requests PCE for the
computation of a working path. After BRPC processing has completed,
the PCC receives the results of the working-path computation
expressed in an ERO in a PCRep message. The ERO may include PKSs if
certain segments of the path are to be kept confidential.
For backup path computation, when the PCC constructs a PCReq Message,
it includes the entire working-path in the XRO so that the computed
path is node/link disjoint from the working path. The XRO may also
include SRLGs to ensure SRLG diversity from the working path. If the
working path ERO includes PKS subobjects, these are also included in
the XRO to allow the PCE to ensure diversity.
A set of PCEs for backup path computation may be the same as ones
for working path computation, or they may be different.
- Identical PCEs
In the case where the same PCEs are used for both path
computations, the processing is as follows. During the process of
BRPC for backup path computation, a PCE may encounter a PKS as it
processes the XRO when it creates a virtual path tree (VPT) in its
own domain. The PCE retrieves the PCE-ID from the PKS, recognizes
itself, and converts the PKS into a set of XRO subobjects which it
uses for the local calculation to create the VPT. The XRO subobjects
created in this way MUST NOT be shared with other PCEs. Other
operations are the same as BRPC.
- Different PCEs
In the case where a set of PCEs for bakup path computation is
different from the ones used for working path computation, the
processing is as follows. If a PCE encounters a PKS in an XRO when
it is creating a virtual path tree in its own domain, the PCE
retrieves the PCE-ID from the PKS and sends a PCReq message to the
identified PCE to expand the PKS. The PCE computing the VPT treats
the path segment in the response as a set of XRO subobjects in
performing its path computation. The XRO subobjects determined in
this way MUST NOT be shared with other PCEs.
4. IANA Considerations
4.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.
Oki and Farrel Expires January 2008 10
Object Name Object Name Object Name Object Name
Class Type Class Type
17 XRO 1 Route exclusion 17 XRO 1 Route exclusion
3.2. Error Object Field Values. 4.2. Error Object Field Values.
The "PCEP Parameters" registry contains a subregistry "PCEP Errors". The "PCEP Parameters" registry contains a subregistry "PCEP Errors".
IANA is requested to make the following allocations from this IANA is requested to make the following allocations from this
registry. registry.
Values in this section are recommended and to be confirmed by IANA. Values in this section are recommended and to be confirmed by IANA.
Error Meaning and Error-Values Error Meaning and Error-Values
Type Type
skipping to change at page 10, line 35 skipping to change at line 575
The "PCEP Parameters" registry contains a subregistry "PCEP Errors". The "PCEP Parameters" registry contains a subregistry "PCEP Errors".
IANA is requested to make the following allocations from this IANA is requested to make the following allocations from this
registry. registry.
Values in this section are recommended and to be confirmed by IANA. Values in this section are recommended and to be confirmed by IANA.
Error Meaning and Error-Values Error Meaning and Error-Values
Type Type
11 Unrecognized IRO subobject 11 Unrecognized IRO subobject
Note that this Error-Type has been omitted from [PCEP] where it is Note that this Error-Type has been omitted from [PCEP] where it is
required. It is expected that it will be added to a later version of required. It is expected that it will be added to a later version of
[PCEP] and removed from this document. [PCEP] and removed from this document.
12 Unrecognized EXRS subobject 12 Unrecognized EXRS subobject
4. Manageability Considerations 5. Manageability considerations
A MIB module for management of the PCEP is specified in a separate A MIB module for management of the PCEP is specified in a separate
document. This MIB module allows examination of individual PCEP document. This MIB module allows examination of individual PCEP
messages, in particular requests, responses and errors. messages, in particular requests, responses and errors.
The MIB module MUST be extended to include the ability to view the The MIB module MUST be extended to include the ability to view the
route exclusion extensions defined in this document. route exclusion extensions defined in this document.
5. Security Considerations 6. Security Considerations
The new exclude route mechanisms defined in this document allow The new exclude route mechanisms defined in this document allow
finer and more specific control of the path computed by a PCE. Such finer and more specific control of the path computed by a PCE. Such
control increases the risk if a PCEP message is intercepted, control increases the risk if a PCEP message is intercepted,
modified, or spoofed. Therefore, the security techniques described modified, or spoofed. Therefore, the security techniques described
in [PCEP] are considered more important. in [PCEP] are considered more important.
6. References 7. References
6.1. Normative Reference 7.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997. requirements levels", RFC 2119, March 1997.
[PCEP] JP. Vasseur et al, "Path Computation Element (PCE) [PCEP] JP. Vasseur et al, "Path Computation Element (PCE)
communication Protocol (PCEP) - Version 1" draft-ietf-pce-pcep, communication Protocol (PCEP) - Version 1 -" draft-ietf-pce-pcep
(work in progress). (work in progress).
6.2. Informative Reference [INTER-DOMAIN-REC-ANA] T. Takeda et al., "Analysis of Inter-domain
Label Switched Path (LSP) Recovery" draft-ietf-ccamp-inter-domain-
recovery-analysis (work in progress).
[PCE-PATH-KEY] R. Bradford, JP Vasseur, and A. Farrel, "Preserving
Topology Confidentiality in Inter-Domain Path Computation using a
key based mechanism", draft-ietf-pce-path-key (work in progress).
Oki and Farrel Expires January 2008 11
[BRPC] JP. Vasseur et al, "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest inter-domain
Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc
(work in progress).
7.2. Informative Reference
[RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)",
RFC 3477, January 2003.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)
Management Information Base (MIB)", RFC 3812, June 2004. Management Information Base (MIB)", RFC 3812, June 2004.
[RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, September 2006. Element (PCE)-Based Architecture", RFC 4655, September 2006.
[RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE) [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657, September Communication Protocol Generic Requirements", RFC 4657, September
2006. 2006.
[XRO] Lee et al, "Exclude Routes - Extension to RSVP-TE", draft- [RFC4874] Lee et al, "Exclude Routes - Extension to Resource
ietf-ccamp-rsvp-te-exclude-route, (work in progress). ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April
2007.
7. Authors' Addresses 8. Acknowledgements
Authors would like to thank Tomonori Takeda for valuable comments on
inter-domain path computation.
9. Authors' Addresses
Eiji Oki Eiji Oki
NTT NTT
3-9-11 Midori-cho, 3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan Musashino-shi, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp Email: oki.eiji@lab.ntt.co.jp
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Full Copyright Statement 10. Intellectual Property Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology described
this document or the extent to which any license under such rights in this document or the extent to which any license under such
might or might not be available; nor does it represent that it has rights might or might not be available; nor does it represent that
made any independent effort to identify any such rights. Information it has made any independent effort to identify any such rights.
on the procedures with respect to rights in RFC documents can be Information on the procedures with respect to rights in RFC
found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Oki and Farrel Expires January 2008 13
 End of changes. 47 change blocks. 
88 lines changed or deleted 211 lines changed or added

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