doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc7897.txt b/doc/rfc/rfc7897.txt
new file mode 100644
index 0000000..9306361
--- /dev/null
+++ b/doc/rfc/rfc7897.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          D. Dhody
+Request for Comments: 7897                                      U. Palle
+Category: Experimental                               Huawei Technologies
+ISSN: 2070-1721                                              R. Casellas
+                                                                    CTTC
+                                                               June 2016
+
+
+                           Domain Subobjects
+     for the Path Computation Element Communication Protocol (PCEP)
+
+Abstract
+
+   The ability to compute shortest constrained Traffic Engineering Label
+   Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
+   Generalized MPLS (GMPLS) networks across multiple domains has been
+   identified as a key requirement.  In this context, a domain is a
+   collection of network elements within a common sphere of address
+   management or path computational responsibility such as an Interior
+   Gateway Protocol (IGP) area or an Autonomous System (AS).  This
+   document specifies a representation and encoding of a domain
+   sequence, which is defined as an ordered sequence of domains
+   traversed to reach the destination domain to be used by Path
+   Computation Elements (PCEs) to compute inter-domain constrained
+   shortest paths across a predetermined sequence of domains.  This
+   document also defines new subobjects to be used to encode domain
+   identifiers.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7897.
+
+
+
+
+
+
+Dhody, et al.                 Experimental                      [Page 1]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   3.  Detail Description  . . . . . . . . . . . . . . . . . . . . .   6
+     3.1.  Domains . . . . . . . . . . . . . . . . . . . . . . . . .   6
+     3.2.  Domain Sequence . . . . . . . . . . . . . . . . . . . . .   6
+     3.3.  Domain Sequence Representation  . . . . . . . . . . . . .   7
+     3.4.  Include Route Object (IRO)  . . . . . . . . . . . . . . .   8
+       3.4.1.  Subobjects  . . . . . . . . . . . . . . . . . . . . .   8
+         3.4.1.1.  Autonomous System . . . . . . . . . . . . . . . .   8
+         3.4.1.2.  IGP Area  . . . . . . . . . . . . . . . . . . . .   9
+       3.4.2.  Update in IRO Specification . . . . . . . . . . . . .  10
+       3.4.3.  IRO for Domain Sequence . . . . . . . . . . . . . . .  11
+         3.4.3.1.  PCC Procedures  . . . . . . . . . . . . . . . . .  11
+         3.4.3.2.  PCE Procedures  . . . . . . . . . . . . . . . . .  11
+     3.5.  Exclude Route Object (XRO)  . . . . . . . . . . . . . . .  13
+       3.5.1.  Subobjects  . . . . . . . . . . . . . . . . . . . . .  13
+         3.5.1.1.  Autonomous System . . . . . . . . . . . . . . . .  14
+         3.5.1.2.  IGP Area  . . . . . . . . . . . . . . . . . . . .  14
+     3.6.  Explicit Exclusion Route Subobject (EXRS) . . . . . . . .  16
+     3.7.  Explicit Route Object (ERO) . . . . . . . . . . . . . . .  16
+   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
+     4.1.  Inter-Area Path Computation . . . . . . . . . . . . . . .  17
+     4.2.  Inter-AS Path Computation . . . . . . . . . . . . . . . .  19
+       4.2.1.  Example 1 . . . . . . . . . . . . . . . . . . . . . .  20
+       4.2.2.  Example 2 . . . . . . . . . . . . . . . . . . . . . .  22
+     4.3.  Boundary Node and Inter-AS Link . . . . . . . . . . . . .  25
+     4.4.  PCE Serving Multiple Domains  . . . . . . . . . . . . . .  25
+     4.5.  P2MP  . . . . . . . . . . . . . . . . . . . . . . . . . .  26
+     4.6.  Hierarchical PCE  . . . . . . . . . . . . . . . . . . . .  27
+
+
+
+Dhody, et al.                 Experimental                      [Page 2]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   5.  Other Considerations  . . . . . . . . . . . . . . . . . . . .  27
+     5.1.  Relationship to PCE Sequence  . . . . . . . . . . . . . .  27
+     5.2.  Relationship to RSVP-TE . . . . . . . . . . . . . . . . .  27
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
+     6.1.  New Subobjects  . . . . . . . . . . . . . . . . . . . . .  28
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
+   8.  Manageability Considerations  . . . . . . . . . . . . . . . .  29
+     8.1.  Control of Function and Policy  . . . . . . . . . . . . .  29
+     8.2.  Information and Data Models . . . . . . . . . . . . . . .  29
+     8.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  30
+     8.4.  Verify Correct Operations . . . . . . . . . . . . . . . .  30
+     8.5.  Requirements on Other Protocols . . . . . . . . . . . . .  30
+     8.6.  Impact on Network Operations  . . . . . . . . . . . . . .  30
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  31
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  32
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  34
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35
+
+1.  Introduction
+
+   A Path Computation Element (PCE) may be used to compute end-to-end
+   paths across multi-domain environments using a per-domain path
+   computation technique [RFC5152].  The Backward-Recursive PCE-Based
+   Computation (BRPC) mechanism [RFC5441] also defines a PCE-based path
+   computation procedure to compute an inter-domain constrained path for
+   (G)MPLS TE LSPs.  However, both per-domain and BRPC techniques assume
+   that the sequence of domains to be crossed from source to destination
+   is known and is either fixed by the network operator or obtained by
+   other means.  Also, for inter-domain point-to-multipoint (P2MP) tree
+   computation, it is assumed per [RFC7334] that the domain tree is
+   known a priori.
+
+   The list of domains (domain sequence) in point-to-point (P2P) or a
+   domain tree in P2MP is usually a constraint in inter-domain path
+   computation procedure.
+
+   The domain sequence (the set of domains traversed to reach the
+   destination domain) is either administratively predetermined or
+   discovered by some means like Hierarchical PCE (H-PCE).
+
+   [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 an
+   Autonomous System (albeit with a 2-byte AS number) as an abstract
+   node representing a domain is defined in [RFC3209].  In the current
+   document, we specify new subobjects to include or exclude domains
+   including an IGP area or an AS (4 bytes as per [RFC6793]).
+
+
+
+Dhody, et al.                 Experimental                      [Page 3]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   Further, the domain identifier may simply act as a delimiter to
+   specify where the domain boundary starts and ends in some cases.
+
+   This is a companion document to Resource Reservation Protocol -
+   Traffic Engineering (RSVP-TE) extensions for the domain identifiers
+   [RFC7898].
+
+1.1.  Scope
+
+   The procedures described in this document are experimental.  The
+   experiment is intended to enable research for the usage of the domain
+   sequence at the PCEs for inter-domain paths.  For this purpose, this
+   document specifies new domain subobjects as well as how they
+   incorporate with existing subobjects to represent a domain sequence.
+
+   The experiment will end two years after the RFC is published.  At
+   that point, the RFC authors will attempt to determine how widely this
+   has been implemented and deployed.
+
+   This document does not change the procedures for handling existing
+   subobjects in the PCE Communication Protocol (PCEP).
+
+   The new subobjects introduced by this document will not be understood
+   by legacy implementations.  If a legacy implementation receives one
+   of the subobjects that it does not understand in a PCEP object, the
+   legacy implementation will behave according to the rules for a
+   malformed object as per [RFC5440].  Therefore, it is assumed that
+   this experiment will be conducted only when both the PCE and the Path
+   Computation Client (PCC) form part of the experiment.  It is possible
+   that a PCC or PCE can operate with peers, some of which form part of
+   the experiment and some that do not.  In this case, since no
+   capabilities exchange is used to identify which nodes can use these
+   extensions, manual configuration should be used to determine which
+   peerings form part of the experiment.
+
+   When the results of implementation and deployment are available, this
+   document will be updated and refined, and then it could be moved from
+   Experimental to Standards Track.
+
+1.2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                      [Page 4]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+2.  Terminology
+
+   The following terminology is used in this document.
+
+   ABR:  Area Border Router.  Routers used to connect two IGP areas
+      (Open Shortest Path First (OSPF) or Intermediate System to
+      Intermediate System (IS-IS).
+
+   AS:  Autonomous System
+
+   ASBR:  Autonomous System Border Router
+
+   BN:  Boundary node; can be an ABR or ASBR.
+
+   BRPC:  Backward-Recursive PCE-Based Computation
+
+   Domain:  As per [RFC4655], any collection of network elements within
+      a common sphere of address management or path computational
+      responsibility.  Examples of domains include IGP area and AS.
+
+   Domain Sequence:  An ordered sequence of domains traversed to reach
+      the destination domain.
+
+   ERO:  Explicit Route Object
+
+   H-PCE:  Hierarchical PCE
+
+   IGP:  Interior Gateway Protocol.  Either of the two routing
+      protocols: OSPF or IS-IS.
+
+   IRO:  Include Route Object
+
+   IS-IS:  Intermediate System to Intermediate System
+
+   OSPF:  Open Shortest Path First
+
+   PCC:  Path Computation Client.  Any client application requesting a
+      path computation to be performed by a Path Computation Element.
+
+   PCE:  Path Computation Element.  An entity (component, application,
+      or network node) that is capable of computing a network path or
+      route based on a network graph and applying computational
+      constraints.
+
+   P2MP:  Point-to-Multipoint
+
+   P2P:  Point-to-Point
+
+
+
+
+Dhody, et al.                 Experimental                      [Page 5]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   RSVP:  Resource Reservation Protocol
+
+   TE LSP:  Traffic Engineering Label Switched Path
+
+   XRO:  Exclude Route Object
+
+3.  Detail Description
+
+3.1.  Domains
+
+   [RFC4726] and [RFC4655] define a domain as a separate administrative
+   or geographic environment within the network.  A domain could be
+   further defined as a zone of routing or computational ability.  Under
+   these definitions, a domain might be categorized as an AS or an IGP
+   area.  Each AS can be made of several IGP areas.  In order to encode
+   a domain sequence, it is required to uniquely identify a domain in
+   the domain sequence.  A domain can be uniquely identified by an
+   area-id, AS number, or both.
+
+3.2.  Domain Sequence
+
+   A domain sequence is an ordered sequence of domains traversed to
+   reach the destination domain.
+
+   A domain sequence can be applied as a constraint and carried in a
+   path computation request to a PCE(s).  A domain sequence can also be
+   the result of a path computation.  For example, in the case of H-PCE
+   [RFC6805], a parent PCE could send the domain sequence as a result in
+   a path computation reply.
+
+   In a P2P path, the domains listed appear in the order that they are
+   crossed.  In a P2MP path, the domain tree is represented as a list of
+   domain sequences.
+
+   A domain sequence enables a PCE to select the next domain and the PCE
+   serving that domain to forward the path computation request based on
+   the domain information.
+
+   A domain sequence can include boundary nodes (ABR or ASBR) or border
+   links (inter-AS links) to be traversed as an additional constraint.
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                      [Page 6]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   Thus, a domain sequence can be made up of one or more of the
+   following:
+
+   o  AS Number
+
+   o  Area ID
+
+   o  Boundary Node ID
+
+   o  Inter-AS Link Address
+
+   These are encoded in the new subobjects defined in this document as
+   well as in the existing subobjects that represent a domain sequence.
+
+   Consequently, a domain sequence can be used by:
+
+   1.  a PCE in order to discover or select the next PCE in a
+       collaborative path computation, such as in BRPC [RFC5441];
+
+   2.  the parent PCE to return the domain sequence when unknown; this
+       can then be an input to the BRPC procedure [RFC6805];
+
+   3.  a PCC or a PCE to constrain the domains used in inter-domain path
+       computation, explicitly specifying which domains to be expanded
+       or excluded; and
+
+   4.  a PCE in the per-domain path computation model [RFC5152] to
+       identify the next domain.
+
+3.3.  Domain Sequence Representation
+
+   A domain sequence appears in PCEP messages, notably in:
+
+   o  Include Route Object (IRO): As per [RFC5440], IRO can be used to
+      specify a set of network elements to be traversed to reach the
+      destination, which includes subobjects used to specify the domain
+      sequence.
+
+   o  Exclude Route Object (XRO): As per [RFC5521], XRO can be used to
+      specify certain abstract nodes, to be excluded from the whole
+      path, which include subobjects used to specify the domain
+      sequence.
+
+   o  Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], EXRS
+      can be used to specify exclusion of certain abstract nodes
+      (including domains) between a specific pair of nodes.  EXRS is a
+      subobject inside the IRO.
+
+
+
+
+Dhody, et al.                 Experimental                      [Page 7]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   o  Explicit Route Object (ERO): As per [RFC5440], ERO can be used to
+      specify a computed path in the network.  For example, in the case
+      of H-PCE [RFC6805], a parent PCE can send the domain sequence as a
+      result in a path computation reply using ERO.
+
+3.4.  Include Route Object (IRO)
+
+   As per [RFC5440], IRO can be used to specify that the computed path
+   needs to 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.
+
+   This document extends the support for 4-byte AS numbers and IGP
+   areas.
+
+                 Value  Description
+                 -----  ----------------
+                 5      4-byte AS number
+                 6      OSPF Area ID
+                 7      IS-IS Area ID
+
+   Note: Identical subobjects are carried in RSVP-TE messages as defined
+   in [RFC7898].
+
+3.4.1.1.  Autonomous System
+
+   [RFC3209] already defines 2-byte AS numbers.
+
+   To support 4-byte AS numbers as per [RFC6793], the following
+   subobject is defined:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |L|    Type     |     Length    |         Reserved              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      AS Number (4 bytes)                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   L: The L bit is an attribute of the subobject as defined in
+      [RFC3209], and its usage in the IRO subobject is defined in
+      [RFC7896].
+
+   Type:  5 (indicating a 4-byte AS number).
+
+
+
+Dhody, et al.                 Experimental                      [Page 8]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   Length:  8 (total length of the subobject in bytes).
+
+   Reserved:  Zero at transmission; ignored at receipt.
+
+   AS Number:  The 4-byte AS number.  Note that if 2-byte AS numbers are
+      in use, the low-order bits (16 through 31) MUST be used, and the
+      high-order bits (0 through 15) MUST be set to zero.
+
+3.4.1.2.  IGP Area
+
+   Since the length and format of Area ID is different for OSPF and
+   IS-IS, the following two subobjects are defined below:
+
+   For OSPF, the Area ID is a 32-bit number.  The subobject is encoded
+   as follows:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |L|    Type     |     Length    |         Reserved              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    OSPF Area ID (4 bytes)                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   L: The L bit is an attribute of the subobject as defined in
+      [RFC3209], and its usage in the IRO subobject is defined in
+      [RFC7896].
+
+   Type:  6 (indicating a 4-byte OSPF Area ID).
+
+   Length:  8 (total length of the subobject in bytes).
+
+   Reserved:  Zero at transmission; ignored at receipt.
+
+   OSPF Area ID:  The 4-byte OSPF Area ID.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                      [Page 9]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   For IS-IS, the Area ID is of variable length; thus, the length of the
+   subobject is variable.  The Area ID is as described in IS-IS by the
+   ISO standard [ISO10589].  The subobject is encoded as follows:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |L|    Type     |     Length    |  Area-Len     |  Reserved     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                        IS-IS Area ID                        //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   L: The L bit is an attribute of the subobject as defined in
+      [RFC3209], and its usage in the IRO subobject is defined in
+      [RFC7896].
+
+   Type:  7 (indicating the IS-IS Area ID).
+
+   Length:  Variable.  The length MUST be at least 8 and MUST be a
+      multiple of 4.
+
+   Area-Len:  Variable (length of the actual (non-padded) IS-IS area
+      identifier in octets; valid values are from 1 to 13, inclusive).
+
+   Reserved:  Zero at transmission; ignored at receipt.
+
+   IS-IS Area ID:  The variable-length IS-IS area identifier.  Padded
+      with trailing zeroes to a 4-byte boundary.
+
+3.4.2.  Update in IRO Specification
+
+   [RFC5440] describes IRO as an optional object used to specify network
+   elements to be traversed by the computed path.  It further states
+   that the L bit of such subobject has no meaning within an IRO.  It
+   also does not mention if IRO is an ordered or unordered list of
+   subobjects.
+
+   An update to the IRO specification [RFC7896] makes IRO as an ordered
+   list and includes support for the L bit.
+
+   The use of IRO for the domain sequence assumes the updated
+   specification is being used for IRO, as per [RFC7896].
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 10]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+3.4.3.  IRO for Domain Sequence
+
+   The subobject type for IPv4, IPv6, and unnumbered Interface IDs can
+   be used to specify boundary nodes (ABR/ASBR) and inter-AS links.  The
+   subobject type for the AS Number (2 or 4 bytes) and the IGP area are
+   used to specify the domain identifiers in the domain sequence.
+
+   The IRO can incorporate the new domain subobjects with the existing
+   subobjects in a sequence of traversal.
+
+   Thus, an IRO, comprising subobjects, that represents a domain
+   sequence defines the domains involved in an inter-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 IGP areas for
+   a given AS.
+
+   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
+   obtain a "next PCE" from a domain sequence is able to do so (e.g.,
+   via administrative configuration or discovery).
+
+3.4.3.1.  PCC Procedures
+
+   A PCC builds an IRO to encode the domain sequence, so that the
+   cooperating PCEs could compute an inter-domain shortest constrained
+   path across the specified sequence of domains.
+
+   A PCC may intersperse area and AS subobjects with other subobjects
+   without change to the previously specified processing of those
+   subobjects in the IRO.
+
+3.4.3.2.  PCE Procedures
+
+   If a PCE receives an IRO in a Path Computation Request (PCReq)
+   message that contains the subobjects defined in this document that it
+   does not recognize, it will respond according to the rules for a
+   malformed object as per [RFC5440].  The PCE MAY also include the IRO
+   in the PCEP Error (PCErr) message as per [RFC5440].
+
+   The interpretation of the L bit is as per Section 4.3.3.1 of
+   [RFC3209] (as per [RFC7896]).
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 11]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   In a Path Computation Reply (PCRep), PCE MAY also supply IRO (with
+   domain sequence information) with the NO-PATH object indicating that
+   the set of elements (domains) of the request's IRO prevented the PCEs
+   from finding a path.
+
+   The following processing rules apply for a domain sequence in IRO:
+
+   o  When a PCE parses an IRO, it interprets each subobject according
+      to the AS number associated with the preceding subobject.  We call
+      this the "current AS".  Certain subobjects modify the current AS,
+      as follows.
+
+      *  The current AS is initialized to the AS number of the PCC.
+
+      *  If the PCE encounters an AS subobject, then it updates the
+         current AS to this new AS number.
+
+      *  If the PCE encounters an area subobject, then it assumes that
+         the area belongs to the current AS.
+
+      *  If the PCE encounters an IP address that is globally routable,
+         then it updates the current AS to the AS that owns this IP
+         address.  This document does not define how the PCE learns
+         which AS owns the IP address.
+
+      *  If the PCE encounters an IP address that is not globally
+         routable, then it assumes that it belongs to the current AS.
+
+      *  If the PCE encounters an unnumbered link, then it assumes that
+         it belongs to the current AS.
+
+   o  When a PCE parses an IRO, it interprets each subobject according
+      to the Area ID associated with the preceding subobject.  We call
+      this the "current area".  Certain subobjects modify the current
+      area, as follows.
+
+      *  The current area is initialized to the Area ID of the PCC.
+
+      *  If the current AS is changed, the current area is reset and
+         needs to be determined again by a current or subsequent
+         subobject.
+
+      *  If the PCE encounters an area subobject, then it updates the
+         current area to this new Area ID.
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 12]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+      *  If the PCE encounters an IP address that belongs to a different
+         area, then it updates the current area to the area that has
+         this IP address.  This document does not define how the PCE
+         learns which area has the IP address.
+
+      *  If the PCE encounters an unnumbered link that belongs to a
+         different area, then it updates the current Area to the area
+         that has this link.
+
+      *  Otherwise, it assumes that the subobject belongs to the current
+         area.
+
+   o  In case the current PCE is not responsible for the path
+      computation in the current AS or area, then the PCE selects the
+      "next PCE" in the domain sequence based on the current AS and
+      area.
+
+   Note that it is advised that PCC should use AS and area subobjects
+   while building the domain sequence in IRO and avoid using other
+   mechanisms to change the "current AS" and "current area" as described
+   above.
+
+3.5.  Exclude Route Object (XRO)
+
+   XRO [RFC5521] is an optional object used to specify exclusion of
+   certain abstract nodes or resources from the whole path.
+
+3.5.1.  Subobjects
+
+   Some subobjects are to be used in XRO as defined in [RFC3209],
+   [RFC3477], [RFC4874], and [RFC5520], but new subobjects related to
+   domain sequence are needed.
+
+   This document extends the support for 4-byte AS numbers and IGP
+   areas.
+
+                 Value  Description
+                 -----  ----------------
+                 5      4-byte AS number
+                 6      OSPF Area ID
+                 7      IS-IS Area ID
+
+   Note: Identical subobjects are carried in RSVP-TE messages as defined
+   in [RFC7898].
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 13]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+3.5.1.1.  Autonomous System
+
+   The new subobjects to support 4-byte AS numbers and the IGP
+   (OSPF/IS-IS) area MAY also be used in the XRO to specify exclusion of
+   certain domains in the path computation procedure.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |X|    Type     |     Length    |         Reserved              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      AS Number (4 bytes)                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   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 it 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 the Area ID is different for OSPF and
+   IS-IS, the 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 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              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    OSPF Area ID (4 bytes)                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The X-bit indicates whether the exclusion is mandatory or desired.
+
+   0: indicates that the OSPF area specified MUST be excluded from the
+      path computed by the PCE(s).
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 14]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   1: indicates that the OSPF area specified SHOULD be avoided from the
+      inter-domain path computed by the PCE(s), but it 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; thus, the length of the
+   subobject is variable.  The Area ID is as described in IS-IS by the
+   ISO standard [ISO10589].  The subobject is encoded as follows:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |X|    Type     |     Length    |  Area-Len     |  Reserved     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   //                        IS-IS Area ID                        //
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The X-bit indicates whether the exclusion is mandatory or desired.
+
+   0: indicates that the IS-IS area specified MUST be excluded from the
+      path computed by the PCE(s).
+
+   1: indicates that the IS-IS area specified SHOULD be avoided from the
+      inter-domain path computed by the PCE(s), but it 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.
+
+   All the processing rules are as per [RFC5521].
+
+   Note that if a PCE receives an XRO in a PCReq message that contains
+   subobjects defined in this document that it does not recognize, it
+   will respond according to the rules for a malformed object as per
+   [RFC5440].
+
+   IGP area subobjects in the XRO are local to the current AS.  In case
+   multi-AS path computation excludes an IGP area in a different AS, the
+   IGP area subobject should be part of EXRS in the IRO to specify the
+   AS in which the IGP area is to be excluded.  Further, policy may be
+   applied to prune/ignore area subobjects in XRO after a "current AS"
+   change during path computation.
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 15]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+3.6.  Explicit Exclusion Route Subobject (EXRS)
+
+   The EXRS [RFC5521] is used to specify exclusion of certain abstract
+   nodes between a specific pair of nodes.
+
+   The EXRS can carry any of the subobjects defined for inclusion in the
+   XRO; thus, the new subobjects to support 4-byte AS numbers and the
+   IGP (OSPF / IS-IS) area can 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 the scope of the
+   exclusion is limited to the single hop between the previous and
+   subsequent elements in the IRO.
+
+   The EXRS should be interpreted in the context of the current AS and
+   current area of the preceding subobject in the IRO.  The EXRS does
+   not change the current AS or current area.  All other processing
+   rules are as per [RFC5521].
+
+   Note that if a PCE that supports the EXRS in an IRO parses an IRO,
+   and encounters an EXRS that contains subobjects defined in this
+   document that it does not recognize, it will act according to the
+   setting of the X-bit in the subobject as per [RFC5521].
+
+3.7.  Explicit Route Object (ERO)
+
+   ERO [RFC5440] is used to specify a computed path in the network.
+   PCEP ERO subobject types correspond to RSVP-TE ERO subobject types as
+   defined in [RFC3209], [RFC3473], [RFC3477], [RFC4873], [RFC4874], and
+   [RFC5520].  The subobjects related to the domain sequence are further
+   defined in [RFC7898].
+
+   The new subobjects to support 4-byte AS numbers and the IGP
+   (OSPF/IS-IS) area can also be used in the ERO to specify an abstract
+   node (a group of nodes whose internal topology is opaque to the
+   ingress node of the LSP).  Using this concept of abstraction, an
+   explicitly routed LSP can be specified as a sequence of domains.
+
+   In case of H-PCE [RFC6805], a parent PCE can be requested to find the
+   domain sequence.  Refer to the example in Section 4.6 of this
+   document.  The ERO in reply from the parent PCE can then be used in
+   per-domain path computation or BRPC.
+
+   If a PCC receives an ERO in a PCRep message that contains a subobject
+   defined in this document that it does not recognize, it will respond
+   according to the rules for a malformed object as per [RFC5440].
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 16]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+4.  Examples
+
+   The examples in this section are for illustration purposes only to
+   highlight how the new subobjects could be encoded.  They are not
+   meant to be an exhaustive list of all possible use cases and
+   combinations.
+
+4.1.  Inter-Area Path Computation
+
+   In an inter-area path computation where the ingress and the egress
+   nodes belong to different IGP areas within the same AS, the domain
+   sequence could be represented using an ordered list of area
+   subobjects.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 17]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+    -----------------                              -----------------
+   |                 |                            |                 |
+   |          +--+   |                            |     +--+        |
+   | +--+     |  |   |                            |     |  |        |
+   | |  |     +--+   |                            |     +--+   +--+ |
+   | +--+            |                            |            |  | |
+   |                 |                            |            +--+ |
+   |        +--+     |                            |                 |
+   |        |  |     |                            |     +--+        |
+   |        +--+     |                            |     |  |        |
+   |                 | -------------------------- |     +--+        |
+   |                +--+                       +--+                 |
+   |                |  |         +--+          |  |                 |
+   |Area 2          +--+         |  |          +--+  Area 4         |
+    ----------------- |          +--+            | -----------------
+                      |                          |
+                      |                +--+      |
+                      |    +--+        |  |      |
+                      |    |  |        +--+      |
+                      |    +--+                  |
+                      |                          |
+                      |                          |
+                      |                          |
+                      |                          |
+                      |           +--+           |
+                      |           |  |           |
+                      |           +--+           |
+    ----------------- |                          | ------------------
+   |                 +--+                      +--+                  |
+   |                 |  |                      |  |                  |
+   |                 +--+    Area 0            +--+                  |
+   |                 | -------------------------- |     +--+         |
+   |          +--+   |                            |     |  |         |
+   |          |  |   |                            |     +--+         |
+   | +--+     +--+   |                            |                  |
+   | |  |            |                            |            +--+  |
+   | +--+            |                            |            |  |  |
+   |                 |                            |            +--+  |
+   |       +--+      |                            |                  |
+   |       |  |      |                            |     +--+         |
+   |       +--+      |                            |     |  |         |
+   |                 |                            |     +--+         |
+   |                 |                            |                  |
+   | Area 1          |                            |  Area 5          |
+    -----------------                              ------------------
+
+                   Figure 1: Inter-Area Path Computation
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 18]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   The AS Number is 100.
+
+   If the ingress is in area 2, the egress is in area 4, and transit is
+   through area 0, here are some possible ways a PCC can encode the IRO:
+
+     +---------+ +---------+ +---------+
+     |IRO      | |Sub-     | |Sub-     |
+     |Object   | |object   | |object   |
+     |Header   | |Area 0   | |Area 4   |
+     |         | |         | |         |
+     |         | |         | |         |
+     +---------+ +---------+ +---------+
+
+     or
+
+     +---------+ +---------+ +---------+ +---------+
+     |IRO      | |Sub-     | |Sub-     | |Sub-     |
+     |Object   | |object   | |object   | |object   |
+     |Header   | |Area 2   | |Area 0   | |Area 4   |
+     |         | |         | |         | |         |
+     |         | |         | |         | |         |
+     +---------+ +---------+ +---------+ +---------+
+
+     or
+
+     +---------+ +---------+ +---------+ +---------+ +---------+
+     |IRO      | |Sub-     | |Sub-     | |Sub-     | |Sub-     |
+     |Object   | |object AS| |object   | |object   | |object   |
+     |Header   | |100      | |Area 2   | |Area 0   | |Area 4   |
+     |         | |         | |         | |         | |         |
+     |         | |         | |         | |         | |         |
+     +---------+ +---------+ +---------+ +---------+ +---------+
+
+   The domain sequence can further include encompassing AS information
+   in the AS subobject.
+
+4.2.  Inter-AS Path Computation
+
+   In inter-AS path computation, where the ingress and egress belong to
+   different ASes, the domain sequence could be represented using an
+   ordered list of AS subobjects.  The domain sequence can further
+   include decomposed area information in the area subobject.
+
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 19]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+4.2.1.  Example 1
+
+   As shown in Figure 2, where AS has a single area, the AS subobject in
+   the domain sequence can uniquely identify the next domain and PCE.
+
+              AS A                AS E                AS C
+         <------------->      <---------->      <------------->
+
+                  A4----------E1---E2---E3---------C4
+                 /           /                       \
+               /            /                          \
+             /            /       AS B                   \
+           /            /      <---------->                \
+     Ingress------A1---A2------B1---B2---B3------C1---C2------Egress
+           \                                    /          /
+             \                                /          /
+               \                            /          /
+                 \                        /          /
+                  A3----------D1---D2---D3---------C3
+
+                              <---------->
+                                  AS D
+
+     * All ASes have one area (area 0)
+
+                    Figure 2: Inter-AS Path Computation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 20]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   If the ingress is in AS A, the egress is in AS C, and transit is
+   through AS B, here are some possible ways a PCC can encode the IRO:
+
+   +-------+ +-------+ +-------+
+   |IRO    | |Sub-   | |Sub-   |
+   |Object | |object | |object |
+   |Header | |AS B   | |AS C   |
+   |       | |       | |       |
+   +-------+ +-------+ +-------+
+
+   or
+
+   +-------+ +-------+ +-------+ +-------+
+   |IRO    | |Sub-   | |Sub-   | |Sub-   |
+   |Object | |object | |object | |object |
+   |Header | |AS A   | |AS B   | |AS C   |
+   |       | |       | |       | |       |
+   +-------+ +-------+ +-------+ +-------+
+
+   or
+
+   +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+   |IRO    | |Sub-   | |Sub-   | |Sub-   | |Sub-   | |Sub-   | |Sub-   |
+   |Object | |object | |object | |object | |object | |object | |object |
+   |Header | |AS A   | |Area 0 | |AS B   | |Area 0 | |AS C   | |Area 0 |
+   |       | |       | |       | |       | |       | |       | |       |
+   +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+
+   Note that to get a domain disjoint path, the ingress could also
+   request the backup path with:
+
+   +-------+ +-------+
+   |XRO    | |Sub    |
+   |Object | |Object |
+   |Header | |AS B   |
+   |       | |       |
+   +-------+ +-------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 21]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   As described in Section 3.4.3, a domain subobject in IRO changes the
+   domain information associated with the next set of subobjects till
+   you encounter a subobject that changes the domain too.  Consider the
+   following IRO:
+
+   +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+   |IRO    | |Sub-   | |Sub-   | |Sub-   | |Sub-   | |Sub-   |
+   |Object | |object | |object | |object | |object | |object |
+   |Header | |AS B   | |IP     | |IP     | |AS C   | |IP     |
+   |       | |       | |B1     | |B3     | |       | |C1     |
+   +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+
+   On processing subobject "AS B", it changes the AS of the subsequent
+   subobjects till we encounter another subobject "AS C" that changes
+   the AS for its subsequent subobjects.
+
+   Consider another IRO:
+
+   +-------+ +-------+ +-------+ +-------+ +-------+
+   |IRO    | |Sub-   | |Sub-   | |Sub-   | |Sub-   |
+   |Object | |object | |object | |object | |object |
+   |Header | |AS D   | |IP     | |IP     | |IP     |
+   |       | |       | |D1     | |D3     | |C3     |
+   +-------+ +-------+ +-------+ +-------+ +-------+
+
+   Here as well, on processing "AS D", it changes the AS of the
+   subsequent subobjects till you encounter another subobject "C3" that
+   belongs in another AS and changes the AS for its subsequent
+   subobjects.
+
+   Further description for the boundary node and inter-AS link can be
+   found in Section 4.3.
+
+4.2.2.  Example 2
+
+   In Figure 3, AS 200 is made up of multiple areas.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 22]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+                  |
+                  |  +-------------+                +----------------+
+                  |  |Area 2       |                |Area 4          |
+                  |  |         +--+|                |          +--+  |
+                  |  |         |  ||                |          | B|  |
+                  |  |  +--+   +--+|                |   +--+   +--+  |
+                  |  |  |  |       |                |   |  |         |
+                  |  |  +--+       |                |   +--+         |
+                  |  |        +--+ |                |          +--+  |
+                  |  |        |  | |                |          |  |  |
+                  |  |        +--+ |                |   +--+   +--+  |
+                  |  |  +--+       |+--------------+|   |  |         |
+                  |  |  |  |       +--+          +--+   +--+         |
+   +-------------+|  |  +--+       |  |          |  |                |
+   |             ||  |             +--+          +--+                |
+   |         +--+||  +-------------+|              |+----------------+
+   |         |  |||                 |     +--+     |
+   |         +--+||                 |     |  |     |
+   |    +--+     ||                 |     +--+     |
+   |    |  |  +---+                +--+            |
+   |    +--+  |   |----------------|  |            |
+   |          +---+   Inter-AS     +--+   +--+     |
+   |+--+         ||    Links        |     |  |     |
+   ||A |      +---+                +--+   +--+     |
+   |+--+      |   |----------------|  |            |
+   |          +---+                +--+   +--+     |
+   |    +--+     ||  +------------+ |     |  |     |+----------------+
+   |    |  |     ||  |Area 3      +--+    +--+   +--+ Area 5         |
+   |    +--+     ||  |            |  |           |  |                |
+   |             ||  |            +--+           +--+                |
+   |         +--+||  |       +--+ | |  Area 0      ||   +--+         |
+   |         |  |||  |       |  | | +--------------+|   |  |         |
+   |         +--+||  |       +--+ |                 |   +--+         |
+   |             ||  |            |                 |          +--+  |
+   |Area 0       ||  |   +--+     |                 |   +--+   |  |  |
+   +-------------+|  |   |  |     |                 |   |  |   +--+  |
+                  |  |   +--+  +--+                 |   +--+         |
+                  |  |         |  |                 |                |
+                  |  |         +--+                 |          +--+  |
+                  |  |   +--+     |                 |          | C|  |
+                  |  |   |  |     |                 |          +--+  |
+                  |  |   +--+     |                 |                |
+                  |  |            |                 |                |
+                  |  +------------+                 +----------------+
+                  |
+       AS 100     |  AS 200
+                  |
+                    Figure 3: Inter-AS Path Computation
+
+
+
+Dhody, et al.                 Experimental                     [Page 23]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   For LSP (A-B), where ingress A is in (AS 100, area 0), egress B is in
+   (AS 200, area 4), and transit is through (AS 200, area 0), here are
+   some possible ways a PCC can encode the IRO:
+
+   +-------+ +-------+ +-------+ +-------+
+   |IRO    | |Sub-   | |Sub-   | |Sub-   |
+   |Object | |object | |object | |object |
+   |Header | |AS 200 | |Area 0 | |Area 4 |
+   |       | |       | |       | |       |
+   +-------+ +-------+ +-------+ +-------+
+
+   or
+
+   +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+   |IRO    | |Sub-   | |Sub-   | |Sub-   | |Sub-   | |Sub-   |
+   |Object | |object | |object | |object | |object | |object |
+   |Header | |AS 100 | |Area 0 | |AS 200 | |Area 0 | |Area 4 |
+   |       | |       | |       | |       | |       | |       |
+   +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+
+   For LSP (A-C), where ingress A is in (AS 100, area 0), egress C is in
+   (AS 200, area 5), and transit is through (AS 200, area 0), here are
+   some possible ways a PCC can encode the IRO:
+
+   +-------+ +-------+ +-------+ +-------+
+   |IRO    | |Sub-   | |Sub-   | |Sub-   |
+   |Object | |object | |object | |object |
+   |Header | |AS 200 | |Area 0 | |Area 5 |
+   |       | |       | |       | |       |
+   +-------+ +-------+ +-------+ +-------+
+
+   or
+
+   +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+   |IRO    | |Sub-   | |Sub-   | |Sub-   | |Sub-   | |Sub-   |
+   |Object | |object | |object | |object | |object | |object |
+   |Header | |AS 100 | |Area 0 | |AS 200 | |Area 0 | |Area 5 |
+   |       | |       | |       | |       | |       | |       |
+   +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 24]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+4.3.  Boundary Node and Inter-AS Link
+
+   A PCC or PCE can include additional constraints covering which
+   boundary nodes (ABR or ASBR) or border links (inter-AS link) to be
+   traversed while defining a domain sequence.  In which case, the
+   boundary node or link can be encoded as a part of the domain
+   sequence.
+
+   Boundary nodes (ABR/ASBR) can be encoded using the IPv4 or IPv6
+   prefix subobjects, usually with a loopback address of 32 and a prefix
+   length of 128, respectively.  An inter-AS link can be encoded using
+   the IPv4 or IPv6 prefix subobjects or unnumbered interface
+   subobjects.
+
+   For Figure 1, an ABR (say, 203.0.113.1) to be traversed can be
+   specified in IRO as:
+
+        +---------+ +---------+ +---------++---------+ +---------+
+        |IRO      | |Sub-     | |Sub-     ||Sub-     | |Sub-     |
+        |Object   | |object   | |object   ||object   | |object   |
+        |Header   | |Area 2   | |IPv4     ||Area 0   | |Area 4   |
+        |         | |         | |203.0.   ||         | |         |
+        |         | |         | |112.1    ||         | |         |
+        +---------+ +---------+ +---------++---------+ +---------+
+
+   For Figure 3, an inter-AS link (say, 198.51.100.1 - 198.51.100.2) to
+   be traversed can be specified as:
+
+          +---------+  +---------+ +---------+ +---------+
+          |IRO      |  |Sub-     | |Sub-     | |Sub-     |
+          |Object   |  |object AS| |object   | |object AS|
+          |Header   |  |100      | |IPv4     | |200      |
+          |         |  |         | |198.51.  | |         |
+          |         |  |         | |100.2    | |         |
+          +---------+  +---------+ +---------+ +---------+
+
+4.4.  PCE Serving Multiple Domains
+
+   A single PCE can be responsible for multiple domains; for example,
+   PCE function deployed on an ABR could be responsible for multiple
+   areas.  A PCE that can support adjacent domains can internally handle
+   those domains in the domain sequence without any impact on the other
+   domains in the domain sequence.
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 25]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+4.5.  P2MP
+
+   [RFC7334] describes an experimental inter-domain P2MP path
+   computation mechanism where the path domain tree is described as a
+   series of domain sequences; an example is shown in the figure below:
+
+                           +----------------+
+                           |                |Domain D1
+                           |        R       |
+                           |                |
+                           |        A       |
+                           |                |
+                           +-B------------C-+
+                            /              \
+                           /                \
+                          /                  \
+          Domain D2      /                    \ Domain D3
+          +-------------D--+             +-----E----------+
+          |                |             |                |
+          |  F             |             |                |
+          |          G     |             |       H        |
+          |                |             |                |
+          |                |             |                |
+          +-I--------------+             +-J------------K-+
+           /\                             /              \
+          /  \                           /                \
+         /    \                         /                  \
+        /      \                       /                    \
+       /        \                     /                      \
+      /          \                   /                        \
+     / Domain D4  \      Domain D5  /              Domain D6   \
+   +-L-------------W+       +------P---------+      +-----------T----+
+   |                |       |                |      |                |
+   |                |       |  Q             |      |   U            |
+   |  M        O    |       |         S      |      |                |
+   |                |       |                |      |          V     |
+   |          N     |       |   R            |      |                |
+   +----------------+       +----------------+      +----------------+
+
+                       Figure 4: Domain Tree Example
+
+   The domain tree can be represented as a series of domain sequences:
+
+   o  Domain D1, Domain D3, Domain D6
+
+   o  Domain D1, Domain D3, Domain D5
+
+   o  Domain D1, Domain D2, Domain D4
+
+
+
+Dhody, et al.                 Experimental                     [Page 26]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   The domain sequence handling described in this document could be
+   applied to the P2MP path domain tree.
+
+4.6.  Hierarchical PCE
+
+   In case of H-PCE [RFC6805], the parent PCE can be requested to
+   determine the domain sequence and return it in the path computation
+   reply, using the ERO.  For the example in Section 4.6 of [RFC6805],
+   the domain sequence can possibly appear as:
+
+   +---------+ +---------+ +---------+ +---------+
+   |ERO      | |Sub-     | |Sub-     | |Sub-     |
+   |Object   | |object   | |object   | |object   |
+   |Header   | |Domain 1 | |Domain 2 | |Domain 3 |
+   |         | |         | |         | |         |
+   |         | |         | |         | |         |
+   +---------+ +---------+ +---------+ +---------+
+
+   or
+
+   +---------+ +---------+ +---------+
+   |ERO      | |Sub-     | |Sub-     |
+   |Object   | |object   | |object   |
+   |Header   | |BN 21    | |Domain 3 |
+   |         | |         | |         |
+   |         | |         | |         |
+   +---------+ +---------+ +---------+
+
+5.  Other Considerations
+
+5.1.  Relationship to PCE Sequence
+
+   Instead of a domain sequence, a sequence of PCEs MAY be enforced by
+   policy on the PCC, and this constraint can be carried in the PCReq
+   message (as defined in [RFC5886]).
+
+   Note that PCE Sequence can be used along with domain sequence, in
+   which case PCE Sequence MUST have higher precedence in selecting the
+   next PCE in the inter-domain path computation procedures.
+
+5.2.  Relationship to RSVP-TE
+
+   [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
+   AS but with a 2-byte AS number.
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 27]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   [RFC7898] extends the notion of abstract nodes by adding new
+   subobjects for IGP areas and 4-byte AS numbers.  These subobjects can
+   be included in ERO, XRO, or EXRS in RSVP-TE.
+
+   In any case, subobject types defined in RSVP-TE are identical to the
+   subobject types defined in the related documents in PCEP.
+
+6.  IANA Considerations
+
+6.1.  New Subobjects
+
+   IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
+   registry at <http://www.iana.org/assignments/pcep>.  Within this
+   registry, IANA maintains two sub-registries:
+
+   o  IRO Subobjects
+
+   o  XRO Subobjects
+
+   IANA has made identical additions to those registries as follows:
+
+   Value   Description        Reference
+   -----   ----------------   -------------------
+   5       4-byte AS number   RFC 7897, [RFC7898]
+   6       OSPF Area ID       RFC 7897, [RFC7898]
+   7       IS-IS Area ID      RFC 7897, [RFC7898]
+
+   Further, IANA has added a reference to this document to the new RSVP
+   numbers that are registered by [RFC7898], as shown on
+   <http://www.iana.org/assignments/rsvp-parameters>.
+
+7.  Security Considerations
+
+   The protocol extensions defined in this document do not substantially
+   change the nature of PCEP.  Therefore, the security considerations
+   set out in [RFC5440] apply unchanged.  Note that further security
+   considerations for the use of PCEP over TCP are presented in
+   [RFC6952].
+
+   This document specifies a representation of the domain sequence and
+   new subobjects, which could be used in inter-domain PCE scenarios as
+   explained in [RFC5152], [RFC5441], [RFC6805], [RFC7334], etc.  The
+   security considerations set out in each of these mechanisms remain
+   unchanged by the new subobjects and domain sequence representation in
+   this document.
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 28]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   But the new subobjects do allow finer and more specific control of
+   the path computed by a cooperating PCE(s).  Such control increases
+   the risk if a PCEP message is intercepted, modified, or spoofed
+   because it allows the attacker to exert control over the path that
+   the PCE will compute or to make the path computation impossible.
+   Consequently, it is important that implementations conform to the
+   relevant security requirements of [RFC5440].  These mechanisms
+   include:
+
+   o  Securing the PCEP session messages using TCP security techniques
+      (Section 10.2 of [RFC5440]).  PCEP implementations SHOULD also
+      consider the additional security provided by the TCP
+      Authentication Option (TCP-AO) [RFC5925] or Transport Layer
+      Security (TLS) [PCEPS].
+
+   o  Authenticating the PCEP messages to ensure the messages are intact
+      and sent from an authorized node (Section 10.3 of [RFC5440]).
+
+   o  PCEP operates over TCP, so it is also important to secure the PCE
+      and PCC against TCP denial-of-service attacks.  Section 10.7.1 of
+      [RFC5440] outlines a number of mechanisms for minimizing the risk
+      of TCP-based denial-of-service attacks against PCEs and PCCs.
+
+   o  In inter-AS scenarios, attacks may be particularly significant
+      with commercial- as well as service-level implications.
+
+   Note, however, that the domain sequence mechanisms also provide the
+   operator with the ability to route around vulnerable parts of the
+   network and may be used to increase overall network security.
+
+8.  Manageability Considerations
+
+8.1.  Control of Function and Policy
+
+   The exact behavior with regards to desired inclusion and exclusion of
+   domains MUST be available for examination by an operator and MAY be
+   configurable.  Manual configurations are needed to identify which
+   PCEP peers understand the new domain subobjects defined in this
+   document.
+
+8.2.  Information and Data Models
+
+   A MIB module for management of the PCEP is being specified in a
+   separate document [RFC7420].  This document does not imply any new
+   extension to the current MIB module.
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 29]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+8.3.  Liveness Detection and Monitoring
+
+   Mechanisms defined in this document do not imply any new liveness
+   detection and monitoring requirements aside from those already listed
+   in [RFC5440].
+
+8.4.  Verify Correct Operations
+
+   Mechanisms defined in this document do not imply any new operation
+   verification requirements aside from those already listed in
+   [RFC5440].
+
+8.5.  Requirements on Other Protocols
+
+   In case of per-domain path computation [RFC5152], where the full path
+   of an inter-domain TE LSP cannot be determined (or is not determined)
+   at the ingress node, a signaling message can use the domain
+   identifiers.  The subobjects defined in this document SHOULD be
+   supported by RSVP-TE.  [RFC7898] 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
+   requirements on other protocols aside from those already listed in
+   [RFC5440].
+
+8.6.  Impact on Network Operations
+
+   The mechanisms described in this document can provide the operator
+   with the ability to exert finer and more specific control of the path
+   computation by inclusion or exclusion of domain subobjects.  There
+   may be some scaling benefit when a single domain subobject may
+   substitute for many subobjects and can reduce the overall message
+   size and processing.
+
+   Backward compatibility issues associated with the new subobjects
+   arise when a PCE does not recognize them, in which case PCE responds
+   according to the rules for a malformed object as per [RFC5440].  For
+   successful operations, the PCEs in the network would need to be
+   upgraded.
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 30]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+9.  References
+
+9.1.  Normative References
+
+   [ISO10589] International Organization for Standardization,
+              "Information technology -- Telecommunications and
+              information exchange between systems -- Intermediate
+              System to Intermediate System intra-domain routeing
+              information exchange protocol for use in conjunction with
+              the protocol for providing the connectionless-mode network
+              service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
+              2002.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+              <http://www.rfc-editor.org/info/rfc3209>.
+
+   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Resource ReserVation Protocol-
+              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
+              DOI 10.17487/RFC3473, January 2003,
+              <http://www.rfc-editor.org/info/rfc3473>.
+
+   [RFC3477]  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
+              in Resource ReSerVation Protocol - Traffic Engineering
+              (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
+              <http://www.rfc-editor.org/info/rfc3477>.
+
+   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
+              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
+              DOI 10.17487/RFC5440, March 2009,
+              <http://www.rfc-editor.org/info/rfc5440>.
+
+   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
+              "A Backward-Recursive PCE-Based Computation (BRPC)
+              Procedure to Compute Shortest Constrained Inter-Domain
+              Traffic Engineering Label Switched Paths", RFC 5441,
+              DOI 10.17487/RFC5441, April 2009,
+              <http://www.rfc-editor.org/info/rfc5441>.
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 31]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   [RFC5521]  Oki, E., Takeda, T., and A. Farrel, "Extensions to the
+              Path Computation Element Communication Protocol (PCEP) for
+              Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
+              2009, <http://www.rfc-editor.org/info/rfc5521>.
+
+   [RFC6805]  King, D., Ed. and A. Farrel, Ed., "The Application of the
+              Path Computation Element Architecture to the Determination
+              of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
+              DOI 10.17487/RFC6805, November 2012,
+              <http://www.rfc-editor.org/info/rfc6805>.
+
+   [RFC7896]  Dhody, D., "Update to the Include Route Object (IRO)
+              Specification in the Path Computation Element
+              Communication Protocol (PCEP)", RFC 7896,
+              DOI 10.17487/RFC7896, June 2016,
+              <http://www.rfc-editor.org/info/rfc7896>.
+
+   [RFC7898]  Dhody, D., Palle, U., Kondreddy, V., and R. Casellas,
+              "Domain Subobjects for Resource Reservation Protocol -
+              Traffic Engineering (RSVP-TE)", RFC 7898,
+              DOI 10.17487/RFC7898, June 2016,
+              <http://www.rfc-editor.org/info/rfc7898>.
+
+9.2.  Informative References
+
+   [PCEPS]    Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
+              Transport for PCEP", Work in Progress,
+              draft-ietf-pce-pceps-09, November 2015.
+
+   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
+              Element (PCE)-Based Architecture", RFC 4655,
+              DOI 10.17487/RFC4655, August 2006,
+              <http://www.rfc-editor.org/info/rfc4655>.
+
+   [RFC4726]  Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
+              Inter-Domain Multiprotocol Label Switching Traffic
+              Engineering", RFC 4726, DOI 10.17487/RFC4726, November
+              2006, <http://www.rfc-editor.org/info/rfc4726>.
+
+   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
+              "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
+              May 2007, <http://www.rfc-editor.org/info/rfc4873>.
+
+   [RFC4874]  Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
+              Extension to Resource ReserVation Protocol-Traffic
+              Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874,
+              April 2007, <http://www.rfc-editor.org/info/rfc4874>.
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 32]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+   [RFC5152]  Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
+              Per-Domain Path Computation Method for Establishing Inter-
+              Domain Traffic Engineering (TE) Label Switched Paths
+              (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
+              <http://www.rfc-editor.org/info/rfc5152>.
+
+   [RFC5520]  Bradford, R., Ed., Vasseur, JP., and A. Farrel,
+              "Preserving Topology Confidentiality in Inter-Domain Path
+              Computation Using a Path-Key-Based Mechanism", RFC 5520,
+              DOI 10.17487/RFC5520, April 2009,
+              <http://www.rfc-editor.org/info/rfc5520>.
+
+   [RFC5886]  Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
+              Monitoring Tools for Path Computation Element (PCE)-Based
+              Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
+              <http://www.rfc-editor.org/info/rfc5886>.
+
+   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
+              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
+              June 2010, <http://www.rfc-editor.org/info/rfc5925>.
+
+   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
+              Autonomous System (AS) Number Space", RFC 6793,
+              DOI 10.17487/RFC6793, December 2012,
+              <http://www.rfc-editor.org/info/rfc6793>.
+
+   [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
+              BGP, LDP, PCEP, and MSDP Issues According to the Keying
+              and Authentication for Routing Protocols (KARP) Design
+              Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
+              <http://www.rfc-editor.org/info/rfc6952>.
+
+   [RFC7334]  Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas,
+              "PCE-Based Computation Procedure to Compute Shortest
+              Constrained Point-to-Multipoint (P2MP) Inter-Domain
+              Traffic Engineering Label Switched Paths", RFC 7334,
+              DOI 10.17487/RFC7334, August 2014,
+              <http://www.rfc-editor.org/info/rfc7334>.
+
+   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
+              Hardwick, "Path Computation Element Communication Protocol
+              (PCEP) Management Information Base (MIB) Module",
+              RFC 7420, DOI 10.17487/RFC7420, December 2014,
+              <http://www.rfc-editor.org/info/rfc7420>.
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 33]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+Acknowledgments
+
+   The authors would like to especially thank Adrian Farrel for his
+   detailed reviews as well as providing text to be included in the
+   document.
+
+   Further, we would like to thank Pradeep Shastry, Suresh Babu, Quintin
+   Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo,
+   Venugopal Reddy, Reeja Paul, Sandeep Boina, Avantika Sergio Belotti,
+   and Jonathan Hardwick for their useful comments and suggestions.
+
+   Thanks to Jonathan Hardwick for shepherding this document.
+
+   Thanks to Deborah Brungard for being the responsible AD.
+
+   Thanks to Amanda Baber for the IANA review.
+
+   Thanks to Joel Halpern for the Gen-ART review.
+
+   Thanks to Klaas Wierenga for the SecDir review.
+
+   Thanks to Spencer Dawkins and Barry Leiba for comments during the
+   IESG review.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 34]
+
+RFC 7897               Domain Subobjects for PCEP              June 2016
+
+
+Authors' Addresses
+
+   Dhruv Dhody
+   Huawei Technologies
+   Divyashree Techno Park, Whitefield
+   Bangalore, Karnataka  560066
+   India
+
+   Email: dhruv.ietf@gmail.com
+
+
+   Udayasree Palle
+   Huawei Technologies
+   Divyashree Techno Park, Whitefield
+   Bangalore, Karnataka  560066
+   India
+
+   Email: udayasree.palle@huawei.com
+
+
+   Ramon Casellas
+   CTTC
+   Av. Carl Friedrich Gauss n7
+   Castelldefels, Barcelona  08860
+   Spain
+
+   Email: ramon.casellas@cttc.es
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                 Experimental                     [Page 35]
+