doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc8282.txt b/doc/rfc/rfc8282.txt
new file mode 100644
index 0000000..8c4988c
--- /dev/null
+++ b/doc/rfc/rfc8282.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            E. Oki
+Request for Comments: 8282                              Kyoto University
+Category: Standards Track                                      T. Takeda
+ISSN: 2070-1721                                                      NTT
+                                                               A. Farrel
+                                                        Juniper Networks
+                                                                F. Zhang
+                                           Huawei Technologies Co., Ltd.
+                                                           December 2017
+
+
+Extensions to the Path Computation Element Communication Protocol (PCEP)
+           for Inter-Layer MPLS and GMPLS Traffic Engineering
+
+Abstract
+
+   The Path Computation Element (PCE) provides path computation
+   functions in support of traffic engineering in Multiprotocol Label
+   Switching (MPLS) and Generalized MPLS (GMPLS) networks.
+
+   MPLS and GMPLS networks may be constructed from layered service
+   networks.  It is advantageous for overall network efficiency to
+   provide end-to-end traffic engineering across multiple network layers
+   through a process called inter-layer traffic engineering.  PCE is a
+   candidate solution for such requirements.
+
+   The PCE Communication Protocol (PCEP) is designed as a communication
+   protocol between Path Computation Clients (PCCs) and PCEs.  This
+   document presents PCEP extensions for inter-layer traffic
+   engineering.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in 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
+   https://www.rfc-editor.org/info/rfc8282.
+
+
+
+
+
+
+
+Oki, et al.                  Standards Track                    [Page 1]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 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
+   (https://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.  Requirements Language . . . . . . . . . . . . . . . . . .   4
+   2.  Overview of PCE-Based Inter-Layer Path Computation  . . . . .   4
+   3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   4
+     3.1.  INTER-LAYER Object  . . . . . . . . . . . . . . . . . . .   5
+     3.2.  SWITCH-LAYER Object . . . . . . . . . . . . . . . . . . .   8
+     3.3.  REQ-ADAP-CAP Object . . . . . . . . . . . . . . . . . . .   9
+     3.4.  New Metric Types  . . . . . . . . . . . . . . . . . . . .  10
+     3.5.  SERVER-INDICATION Object  . . . . . . . . . . . . . . . .  11
+   4.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .  11
+     4.1.  Path Computation Request  . . . . . . . . . . . . . . . .  11
+     4.2.  Path Computation Reply  . . . . . . . . . . . . . . . . .  12
+     4.3.  Stateful PCE and PCE Initiated LSPs . . . . . . . . . . .  13
+   5.  Updated Format of PCEP Messages . . . . . . . . . . . . . . .  14
+   6.  Manageability Considerations  . . . . . . . . . . . . . . . .  15
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
+     7.1.  New PCEP Objects  . . . . . . . . . . . . . . . . . . . .  16
+     7.2.  New Registry for INTER-LAYER Object Flags . . . . . . . .  17
+     7.3.  New Metric Types  . . . . . . . . . . . . . . . . . . . .  17
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  19
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  21
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22
+
+
+
+
+
+
+
+
+Oki, et al.                  Standards Track                    [Page 2]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+1.  Introduction
+
+   The Path Computation Element (PCE) defined in [RFC4655] is an entity
+   that is capable of computing a network path or route based on a
+   network graph and applying computational constraints.  A Path
+   Computation Client (PCC) may make requests to a PCE for paths to be
+   computed, and a PCE may initiate or modify services in a network by
+   supplying new paths [RFC8231] [RFC8281].
+
+   A network may comprise multiple layers.  These layers may represent
+   separation of technologies (e.g., packet switch capable (PSC), time
+   division multiplex (TDM), and lambda switch capable (LSC)) [RFC3945];
+   separation of data-plane switching granularity levels (e.g., Virtual
+   Circuit 4 (VC4) and VC12) [RFC5212]; or a distinction between client
+   and server networking roles (e.g., commercial or administrative
+   separation of client and server networks).  In this multi-layer
+   network, Label Switched Paths (LSPs) in lower layers are used to
+   carry higher-layer LSPs.  The network topology formed by lower-layer
+   LSPs and advertised as traffic engineering links (TE links) in the
+   higher layer is called a Virtual Network Topology (VNT) [RFC5212].
+   Discussion of other ways that network layering can be supported such
+   that connectivity in a higher-layer network can be provided by LSPs
+   in a lower-layer network is provided in [RFC7926].
+
+   It is important to optimize network resource utilization globally,
+   i.e., taking into account all layers, rather than optimizing resource
+   utilization at each layer independently.  This allows better network
+   efficiency to be achieved.  This is what we call inter-layer traffic
+   engineering.  This includes mechanisms allowing the computation of
+   end-to-end paths across layers (known as inter-layer path
+   computation) and mechanisms for control and management of the VNT by
+   setting up and releasing LSPs in the lower layers [RFC5212].
+
+   PCE can provide a suitable mechanism for resolving inter-layer path
+   computation issues.  The framework for applying the PCE-based path
+   computation architecture to inter-layer traffic engineering is
+   described in [RFC5623].
+
+   The PCE communication protocol (PCEP) is designed as a communication
+   protocol between PCCs and PCEs and is defined in [RFC5440].  A set of
+   requirements for PCEP extensions to support inter-layer traffic
+   engineering is described in [RFC6457].
+
+   This document presents PCEP extensions for inter-layer traffic
+   engineering that satisfy the requirements described in [RFC6457].
+
+
+
+
+
+
+Oki, et al.                  Standards Track                    [Page 3]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Overview of PCE-Based Inter-Layer Path Computation
+
+   [RFC4206] defines a way to signal a higher-layer LSP, which has an
+   explicit route that includes hops traversed by LSPs in lower layers.
+   The computation of end-to-end paths across layers is called inter-
+   layer path computation.
+
+   A Label Switching Router (LSR) in the higher layer might not have
+   information on the lower-layer topology, particularly in an overlay
+   or augmented model [RFC3945]; hence, it may not be able to compute an
+   end-to-end path across layers.
+
+   PCE-based inter-layer path computation consists of using one or more
+   PCEs to compute an end-to-end path across layers.  This could be
+   achieved by relying on a single PCE that has topology information
+   about multiple layers and can directly compute an end-to-end path
+   across layers considering the topology of all of the layers.
+   Alternatively, the inter-layer path computation could be performed
+   using multiple cooperating PCEs where each PCE has information about
+   the topology of one or more layers (but not all layers) and where the
+   PCEs collaborate to compute an end-to-end path.
+
+   As described in [RFC5339], a hybrid node may advertise a single TE
+   link with multiple switching capabilities.  Normally, those TE links
+   exist at the layer/region boarder.  In this case, a PCE needs to be
+   capable of specifying the server-layer path information when the
+   server-layer path information is required to be returned to the PCC.
+
+   [RFC5623] describes models for inter-layer path computation in more
+   detail.  It introduces the Virtual Network Topology Manager (VNTM), a
+   functional element that controls the VNT, and sets out three distinct
+   models (and a fourth hybrid model) for inter-layer control involving
+   a PCE, triggered signaling, and a Network Management System (NMS).
+
+3.  Protocol Extensions
+
+   This section describes PCEP extensions for inter-layer path
+   computation.  Four new objects are defined: the INTER-LAYER object,
+   the SWITCH-LAYER object, the REQ-ADAP-CAP object, and the SERVER-
+   INDICATION object.  Also, two new metric types are defined.
+
+
+
+Oki, et al.                  Standards Track                    [Page 4]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+3.1.  INTER-LAYER Object
+
+   The INTER-LAYER object is optional and can be used in Path
+   Computation Request (PCReq) and Path Computation Reply (PCRep)
+   messages, and also in Path Computation State Report (PCRpt), Path
+   Computation Update Request (PCUpd), and Path Computation LSP Initiate
+   Request (PCInitiate) messages.
+
+   In a PCReq message, the INTER-LAYER object indicates whether inter-
+   layer path computation is allowed, the type of path to be computed,
+   and whether triggered signaling (hierarchical LSPs per [RFC4206] or
+   stitched LSPs per [RFC5150] depending on physical network
+   technologies) is allowed.  When the INTER-LAYER object is absent from
+   a PCReq message, the receiving PCE MUST process as though inter-layer
+   path computation had been explicitly disallowed (I-bit set to zero --
+   see below).
+
+   In a PCRep message, the INTER-LAYER object indicates whether
+   inter-layer path computation has been performed, the type of path
+   that has been computed, and whether triggered signaling is used.
+
+   When a PCReq message includes more than one request, an INTER-LAYER
+   object is used per request.  When a PCRep message includes more than
+   one path per request that is responded to, an INTER-LAYER object is
+   used per path.
+
+   The applicability of this object to PCRpt and PCUpd messages is the
+   same as for other objects on those messages as described in
+   [RFC8231].  The applicability of this object to the PCInitiate
+   message is the same as for other objects on those messages as
+   described in [RFC8281].  These messages use the <attribute-list> as
+   defined in [RFC5440] and extended by further PCEP extensions, so the
+   <attribute-list> as extended in Section 5 can be used to include the
+   INTER-LAYER object on these messages.
+
+   INTER-LAYER Object-Class is 36.
+
+   Inter-layer Object-Type is 1.
+
+   The format of the INTER-LAYER object body is shown in Figure 1.
+
+
+
+
+
+
+
+
+
+
+
+Oki, et al.                  Standards Track                    [Page 5]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Reserved                                             |T|M|I|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 1: The INTER-LAYER Object
+
+   I flag (1 bit): The I flag is used by a PCC in a PCReq message to
+   indicate to a PCE whether an inter-layer path is allowed.  When the I
+   flag is set (one), the PCE MAY perform inter-layer path computation
+   and return an inter-layer path.  When the flag is clear (zero), the
+   path that is returned MUST NOT be an inter-layer path.
+
+   The I flag is used by a PCE in a PCRep message to indicate to a PCC
+   whether the path returned is an inter-layer path.  When the I flag is
+   set (one), the path is an inter-layer path.  When it is clear (zero),
+   the path is contained within a single layer because either inter-
+   layer path computation was not performed or a mono-layer path
+   (without any virtual TE link and without any loose hop that spans the
+   lower-layer network) was found notwithstanding the use of inter-layer
+   path computation.
+
+   M flag (1 bit): The M flag is used by a PCC in a PCReq message to
+   indicate to a PCE whether a mono-layer path or multi-layer path is
+   requested.  When the M flag is set (one), a multi-layer path is
+   requested.  When it is clear (zero), a mono-layer path is requested.
+
+   The M flag is used by a PCE in a PCRep message to indicate to a PCC
+   whether a mono-layer path or multi-layer path is returned.  When the
+   M flag is set (one), a multi-layer path is returned.  When the M flag
+   is clear (zero), a mono-layer path is returned.
+
+   If the I flag is clear (zero), the M flag has no meaning and MUST be
+   ignored.
+
+   [RFC6457] describes two sub-options for mono-layer path.
+
+   o  A mono-layer path that is specified by strict hops.  The path may
+      include virtual TE links.
+
+   o  A mono-layer path that includes loose hops that span the lower-
+      layer network.
+
+   The choice of this sub-option can be specified by the use of the O
+   flag in the Request Parameter (RP) object specified in [RFC5440].
+
+
+
+
+
+Oki, et al.                  Standards Track                    [Page 6]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+   T flag (1 bit): The T flag is used by a PCC in a PCReq message to
+   indicate to a PCE whether triggered signaling is allowed.  When the T
+   flag is set (one), triggered signaling is allowed.  When it is clear
+   (zero), triggered signaling is not allowed.
+
+   The T flag is used by a PCE in a PCRep message to indicate to a PCC
+   whether triggered signaling is required to support the returned path.
+   When the T flag is set (one), triggered signaling is required.  When
+   it is clear (zero), triggered signaling is not required.
+
+   Note that triggered signaling is used to support hierarchical
+   [RFC4206] or stitched [RFC5150] LSPs according to the physical
+   attributes of the network layers.
+
+   If the I flag is clear (zero), the T flag has no meaning and MUST be
+   ignored.
+
+   Note that the I and M flags differ in the following ways.  When the I
+   flag is clear (zero), virtual TE links must not be used in path
+   computation.  In addition, loose hops that span the lower-layer
+   network must not be specified.  Only regular TE links from the same
+   layer may be used.
+
+   o  When the I flag is set (one), the M flag is clear (zero), and the
+      T flag is set (one), virtual TE links are allowed in path
+      computation.  In addition, when the O flag of the RP object is
+      set, loose hops that span the lower-layer network may be
+      specified.  This will initiate lower-layer LSP setup; thus, the
+      inter-layer path is set up even though the path computation result
+      from a PCE to a PCC includes hops from the same layer only.
+
+   o  However, when the I flag is set (one), the M flag is clear (zero),
+      and the T flag is clear (zero), since triggered signaling is not
+      allowed, virtual TE links that have not been pre-signaled MUST NOT
+      be used in path computation.  In addition, loose hops that span
+      the lower-layer network MUST NOT be specified.  Therefore, this is
+      equivalent to the I flag being clear (zero).
+
+   Reserved bits of the INTER-LAYER object sent between a PCC and PCE in
+   the same domain MUST be transmitted as zero and SHOULD be ignored on
+   receipt.  A PCE that forwards a path computation request to other
+   PCEs MUST preserve the settings of reserved bits in the PCReq
+   messages it sends and in the PCRep messages it forwards to PCCs.
+
+   Note that the flags in the PCRpt message indicate the state of an
+   LSP, whereas the flags in the PCUpd and the PCInitiate messages
+   indicate the intended/desired state as determined by the PCE.
+
+
+
+
+Oki, et al.                  Standards Track                    [Page 7]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+3.2.  SWITCH-LAYER Object
+
+   The SWITCH-LAYER object is optional on a PCReq message and specifies
+   switching layers in which a path MUST, or MUST NOT, be established.
+   A switching layer is expressed as a switching type and encoding type.
+
+   When a SWITCH-LAYER object is used on a PCReq, it is interpreted in
+   the context of the INTER-LAYER object on the same message.  If no
+   INTER-LAYER object is present, the PCE MUST process the SWITCH-LAYER
+   object as though inter-layer path computation had been explicitly
+   disallowed.  In such a case, the SWITCH-LAYER object MUST NOT have
+   more than one LSP Encoding Type and Switching Type with the I flag
+   set.
+
+   The SWITCH-LAYER object is optional on a PCRep message, where it is
+   used with the NO-PATH object in the case of unsuccessful path
+   computation to indicate the set of constraints that could not be
+   satisfied.
+
+   The SWITCH-LAYER object may be used on a PCRpt message consistent
+   with how properties of existing LSPs are reported on that message
+   [RFC8231].  The PCRpt message uses the <attribute-list> as defined in
+   [RFC5440] and extended by further PCEP extensions.  This message can
+   use the <attribute-list> as extended in Section 5 to carry the
+   SWITCH-LAYER object.  The SWITCH-LAYER object is not used on a PCUpd
+   or PCInitiate messages.
+
+   SWITCH-LAYER Object-Class is 37.
+
+   Switch-layer Object-Type is 1.
+
+   The format of the SWITCH-LAYER object body is shown in Figure 2.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | LSP Enc. Type |Switching Type |          Reserved           |I|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                               .                               |
+      //                              .                              //
+      |                               .                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | LSP Enc. Type |Switching Type |          Reserved           |I|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 2: The SWITCH-LAYER Object
+
+
+
+
+
+Oki, et al.                  Standards Track                    [Page 8]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+   Each row indicates a switching type and encoding type that must or
+   must not be used for a specified layer(s) in the computed path.
+
+   The format is based on [RFC3471] and has equivalent semantics.
+
+   LSP Encoding Type (8 bits): see [RFC3471] for a description of
+   parameters.
+
+   Switching Type (8 bits): see [RFC3471] for a description of
+   parameters.
+
+   I flag (1 bit): the I flag indicates whether a layer with the
+   specified switching type and encoding type must or must not be used
+   by the computed path.  When the I flag is set (one), the computed
+   path MUST traverse a layer with the specified switching type and
+   encoding type.  When the I flag is clear (zero), the computed path
+   MUST NOT enter or traverse any layer with the specified switching
+   type and encoding type.
+
+   When a combination of switching type and encoding type is not
+   included in the SWITCH-LAYER object, the computed path MAY traverse a
+   layer with that combination of switching type and encoding type.
+
+   A PCC may want to specify only a Switching Type and not an LSP
+   Encoding Type.  In this case, the LSP Encoding Type is set to zero.
+
+3.3.  REQ-ADAP-CAP Object
+
+   The REQ-ADAP-CAP object is optional and is used to specify a
+   requested adaptation capability for both ends of the lower-layer LSP.
+   The REQ-ADAP-CAP object is used in a PCReq message for inter-PCE
+   communication, where the PCE that is responsible for computing
+   higher-layer paths acts as a PCC to request a path computation from a
+   PCE that is responsible for computing lower-layer paths.
+
+   The REQ-ADAP-CAP object is used in a PCRep message in case of
+   unsuccessful path computation (in this case, the PCRep message also
+   contains a NO-PATH object, and the REQ-ADAP-CAP object is used to
+   indicate the set of constraints that could not be satisfied).
+
+   The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono-
+   layer network to specify a requested adaptation capability for both
+   ends of the LSP.  In this case, it MAY be carried without an INTER-
+   LAYER object.
+
+   The applicability of this object to PCRpt and PCUpd messages is the
+   same as for other objects on those messages as described in
+   [RFC8231].  The applicability of this object to the PCInitiate
+
+
+
+Oki, et al.                  Standards Track                    [Page 9]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+   message is the same as for other objects on those messages as
+   described in [RFC8281].  These messages use the <attribute-list> as
+   defined in [RFC5440] and extended by further PCEP extensions.  These
+   messages can use the <attribute-list> as extended in Section 5 to
+   carry the REQ-ADAP-CAP object.
+
+   REQ-ADAP-CAP Object-Class is 38.
+
+   Req-Adap-Cap Object-Type is 1.
+
+   The format of the REQ-ADAP-CAP object body is shown in Figure 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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Switching Cap |   Encoding    |          Reserved             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 3: The REQ-ADAP-CAP Object
+
+   The format is based on [RFC6001] and has equivalent semantics as the
+   Interface Adjustment Capability Descriptor (IACD) Upper Switching
+   Capability and Lower Switching Capability fields.
+
+   Switching Capability (8 bits): see [RFC4203] for a description of
+   parameters.
+
+   Encoding (8 bits): see [RFC3471] for a description of parameters.
+
+   A PCC may want to specify a Switching Capability, but not an
+   Encoding.  In this case, the Encoding MUST be set to zero.
+
+3.4.  New Metric Types
+
+   This document defines two new metric types for use in the PCEP METRIC
+   object.
+
+   IANA has assigned the value 18 to indicate the metric "Number of
+   adaptations on a path".
+
+   IANA has assigned the value 19 to indicate the metric "Number of
+   layers on a path".
+
+   See Sections 4.1, 4.2, and 4.3 for a description of how these metrics
+   are applied.
+
+
+
+
+
+
+Oki, et al.                  Standards Track                   [Page 10]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+3.5.  SERVER-INDICATION Object
+
+   The SERVER-INDICATION is optional and is used to indicate that path
+   information included in the Explicit Route Object (ERO) is server-
+   layer information, and it specifies the characteristics of the server
+   layer, e.g., the switching capability and encoding of the server-
+   layer path.
+
+   The format of the SERVER-INDICATION object body is shown in Figure 4.
+
+        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
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       | Switching Cap |   Encoding    |           Reserved            |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       ~                       Optional TLVs                           ~
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 4: The SERVER-INDICATION Object
+
+   SERVER-INDICATION Object-Class is 39.
+
+   Server-indication Object-Type is 1.
+
+   Switching Capability (8 bits): see [RFC4203] for a description of
+   parameters.
+
+   Encoding (8 bits): see [RFC3471] for a description of parameters.
+
+   Optional TLVs: Optional TLVs MAY be included within the object to
+   specify more specific server-layer path information (e.g., traffic
+   parameters).  Such TLVs will be defined by other documents.
+
+4.  Procedures
+
+4.1.  Path Computation Request
+
+   A PCC requests or allows inter-layer path computation in a PCReq
+   message by including the INTER-LAYER object with the I flag set.  The
+   INTER-LAYER object indicates whether inter-layer path computation is
+   allowed, which path type is requested, and whether triggered
+   signaling is allowed.
+
+   The SWITCH-LAYER object, which MUST NOT be present unless the INTER-
+   LAYER object is also present, is optionally used to specify the
+   switching types and encoding types that define layers that must, or
+   must not, be used in the computed path.  When the SWITCH-LAYER object
+   is used with the INTER-LAYER object I flag clear (zero), inter-layer
+
+
+
+Oki, et al.                  Standards Track                   [Page 11]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+   path computation is not allowed, but constraints specified in the
+   SWITCH-LAYER object apply.  Example usage includes path computation
+   in a single-layer GMPLS network.
+
+   The REQ-ADAP-CAP object is optionally used to specify the interface
+   switching capability of both ends of the lower-layer LSP.  The
+   REQ-ADAP-CAP object is used in inter-PCE communication, where the PCE
+   that is responsible for computing higher-layer paths makes a request
+   as a PCC to a PCE that is responsible for computing lower-layer
+   paths.  Alternatively, the REQ-ADAP-CAP object may be used in the
+   NMS-VNTM model, where the VNTM makes a request as a PCC to a PCE that
+   is responsible for computing lower-layer paths.
+
+   The METRIC object is optionally used to specify metric types to be
+   optimized or bounded.  When metric type 18 is used, it indicates that
+   path computation MUST minimize or bound the number of adaptations on
+   a path.  When metric type 19 is used, it indicates that path
+   computation MUST minimize or bound the number of layers to be
+   involved on a path.
+
+   Furthermore, in order to allow different Objective Functions (OFs) to
+   be applied within different network layers, multiple OF objects
+   [RFC5541] MAY be present.  In such a case, the first OF object
+   specifies an objective function for the higher-layer network, and
+   subsequent OF objects specify objection functions of the subsequent
+   lower-layer networks.
+
+4.2.  Path Computation Reply
+
+   In the case of successful path computation, the requested PCE replies
+   to the requesting PCC for the inter-layer path computation result in
+   a PCRep message that MAY include the INTER-LAYER object.  When the
+   INTER-LAYER object is included in a PCRep message, the I, M, and T
+   flags indicate semantics of the path as described in Section 3.1.
+   Furthermore, when the C flag of the METRIC object in a PCReq is set,
+   the METRIC object MUST be included in the PCRep to provide the
+   computed metric value, as specified in [RFC5440].
+
+   The PCE MAY specify the server-layer path information in the ERO.  In
+   this case, the requested PCE replies with a PCRep message that
+   includes at least two sets of ERO information in the path-list: one
+   is for the client-layer path information, and another one is the
+   server-layer path information.  When SERVER-INDICATION is included in
+   a PCRep message, it indicates that the path in the ERO is the server-
+   layer path information.  The server-layer path specified in the ERO
+   could be loose or strict.  On receiving the replied path, the PCC
+   (e.g., NMS and ingress node) can trigger the signaling to set up the
+   LSPs according to the computed paths.
+
+
+
+Oki, et al.                  Standards Track                   [Page 12]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+   In the case of unsuccessful path computation, the PCRep message also
+   contains a NO-PATH object, and the SWITCH-TYPE object and/or
+   REQ-ADAP-CAP MAY be used to indicate the set of constraints that
+   could not be satisfied.
+
+4.3.  Stateful PCE and PCE Initiated LSPs
+
+   Processing for stateful PCEs is described in [RFC8231].  That
+   document defines the PCRpt message to allow a PCC to report to a PCE
+   that an LSP already exists in the network and to delegate control of
+   that LSP to the PCE.
+
+   When the LSP is a multi-layer LSP (or a mono-layer LSP for which
+   specific adaptations exist), the message objects defined in this
+   document are used on the PCRpt to describe an LSP that is delegated
+   to the PCE so that the PCE may process the LSP.
+
+   Furthermore, [RFC8231] defines the PCUpd message to allow a PCE to
+   modify an LSP that has been delegated to it.  When the LSP is a
+   multi-layer LSP (or a mono-layer LSP for which specific adaptations
+   exist), the message objects defined in this document are used on the
+   PCUpd to describe the new attributes of the modified LSP.
+
+   Processing for PCE-initiated LSPs is described in [RFC8281].  That
+   document defines the PCInitiate message that is used by a PCE to
+   request a PCC to set up a new LSP.  When the LSP is a multi-layer LSP
+   (or a mono-layer LSP for which specific adaptations exist), the
+   message objects defined in this document are used on the PCInitiate
+   to describe the attributes of the new LSP.
+
+   The new metric types defined in this document can also be used with
+   the stateful PCE extensions.  The format of PCEP messages described
+   in [RFC8231] and [RFC8281] uses <attribute-list> (which is extended
+   in Section 5 for the purpose of including the new metrics).
+
+   The stateful PCE implementation MAY use the extension of PCReq and
+   PCRep messages as defined in Section 5 to also enable the use of
+   inter-layer parameters during passive stateful operations, using the
+   LSP object.
+
+
+
+
+
+
+
+
+
+
+
+
+Oki, et al.                  Standards Track                   [Page 13]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+5.  Updated Format of PCEP Messages
+
+   Message formats in this section, as those in [RFC5440], are presented
+   using Routing Backus-Naur Format (RBNF) as specified in [RFC5511].
+
+   The format of the PCReq message is updated as shown in Figure 5.
+
+      <PCReq Message>::= <Common Header>
+                         [<svec-list>]
+                         <request-list>
+
+         where:
+            <svec-list>::=<SVEC>
+                          [<svec-list>]
+
+            <request-list>::=<request>[<request-list>]
+
+            <request>::= <RP>
+                         <END-POINTS>
+                         [<LSP>]
+                         [<LSPA>]
+                         [<BANDWIDTH>]
+                         [<metric-list>]
+                         [<of-list>]
+                         [<RRO>[<BANDWIDTH>]]
+                         [<IRO>]
+                         [<LOAD-BALANCING>]
+                         [<INTER-LAYER> [<SWITCH-LAYER>]]
+                         [<REQ-ADAP-CAP>]
+         where:
+
+         <of-list>::=<OF>[<of-list>]
+         <metric-list>::=<METRIC>[<metric-list>]
+
+                    Figure 5: The Updated PCReq Message
+
+   The format of the PCRep message is updated as shown in Figure 6.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Oki, et al.                  Standards Track                   [Page 14]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+      <PCRep Message> ::= <Common Header>
+                          <response-list>
+
+         where:
+            <response-list>::=<response>[<response-list>]
+
+            <response>::=<RP>
+                        [<LSP>]
+                        [<NO-PATH>]
+                        [<attribute-list>]
+                        [<path-list>]
+
+            <path-list>::=<path>[<path-list>]
+
+            <path>::= <ERO><attribute-list>
+
+         where:
+            <attribute-list>::=[<of-list>]
+                               [<LSPA>]
+                               [<BANDWIDTH>]
+                               [<metric-list>]
+                               [<IRO>]
+                               [<INTER-LAYER>]
+                               [<SWITCH-LAYER>]
+                               [<REQ-ADAP-CAP>]
+                               [<SERVER-INDICATION>]
+
+            <of-list>::=<OF>[<of-list>]
+            <metric-list>::=<METRIC>[<metric-list>]
+
+                    Figure 6: The Updated PCRep Message
+
+6.  Manageability Considerations
+
+   Implementations of this specification should provide a mechanism to
+   configure any optional features (such as whether a PCE supports
+   inter-layer computation and which metrics are supported).
+
+   A Management Information Base (MIB) module for modeling PCEP is
+   described in [RFC7420].  Systems that already use a MIB module to
+   manage their PCEP implementations might want to augment that module
+   to provide controls and indicators for support of inter-layer
+   features defined in this document and to add counters of messages
+   sent and received containing the objects defined here.
+
+
+
+
+
+
+
+Oki, et al.                  Standards Track                   [Page 15]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+   However, the preferred mechanism for configuration is through a YANG
+   model.  Work has started on a YANG model for PCEP [PCEP-YANG], and
+   this could be enhanced as described for the MIB module, above.
+
+   Additional policy configuration might be provided to allow a PCE to
+   discriminate between the computation services offered to different
+   PCCs.
+
+   A set of monitoring tools for the PCE-based architecture are provided
+   in [RFC5886].  Systems implementing this specification and PCE
+   monitoring should consider defining extensions to the mechanisms
+   defined in [RFC5886] to help monitor inter-layer path computation
+   requests.
+
+7.  IANA Considerations
+
+   IANA maintains a registry called "Path Computation Element Protocol
+   (PCEP) Numbers".  Per this document, IANA has carried out actions on
+   subregistries of that registry.
+
+7.1.  New PCEP Objects
+
+   IANA has made the following assignments in the "PCEP Objects"
+   subregistry.
+
+      Object-Class Value | Name  | Object-Type           | Reference
+      -------------------+-------+-----------------------+-----------
+      INTER-LAYER        |   36  | 0: Reserved           | RFC 8282
+                         |       | 1: Inter-layer        |
+                         |       | 2-15: Unassigned      |
+                         |       |                       |
+      SWITCH-LAYER       |   37  | 0: Reserved           | RFC 8282
+                         |       | 1: Switch-layer       |
+                         |       | 2-15: Unassigned      |
+                         |       |                       |
+      REQ-ADAP-CAP       |   38  | 0: Reserved           | RFC 8282
+                         |       | 1: Req-Adap-Cap       |
+                         |       | 2-15: Unassigned      |
+                         |       |                       |
+      SERVER-INDICATION  |   39  | 0: Reserved           | RFC 8282
+                         |       | 1: Server-indication  |
+
+                        Figure 7: New PCEP Objects
+
+
+
+
+
+
+
+
+Oki, et al.                  Standards Track                   [Page 16]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+7.2.  New Registry for INTER-LAYER Object Flags
+
+   IANA has created a new subregistry to manage the Flag field of the
+   INTER-LAYER object called the "Inter-Layer Object Path Property Bits"
+   registry.
+
+   New bit numbers may be allocated only by "IETF Review" [RFC8126].
+   Each bit should be tracked with the following qualities:
+
+   o  Bit number (counting from bit 0 as the most significant bit up to
+      a maximum of bit 31)
+
+   o  Capability Description
+
+   o  Defining RFC
+
+   IANA has populated the registry as follows:
+
+      Bit | Flag | Multi-Layer Path Property     | Reference
+      ----+------+-------------------------------+------------
+      0-28|      | Unassigned                    |
+       29 |   T  | Triggered Signaling Allowed   | RFC 8282
+       30 |   M  | Multi-Layer Requested         | RFC 8282
+       31 |   I  | Inter-Layer Allowed           | RFC 8282
+
+            Figure 8: New Registry for INTER-LAYER Object Flags
+
+7.3.  New Metric Types
+
+   Two new metric types are defined in this document for the METRIC
+   object (specified in [RFC5440]).  IANA has made the following
+   allocations from the "Metric Object T Field" registry.
+
+      Value | Description                     | Reference
+      ------+---------------------------------+------------
+        18  | Number of adaptations on a path | RFC 8282
+        19  | Number of layers on a path      | RFC 8282
+
+                        Figure 9: New Metric Types
+
+   IANA has updated the registry to show the registration procedure of
+   "IETF Review" as already documented in [RFC5440].
+
+
+
+
+
+
+
+
+
+Oki, et al.                  Standards Track                   [Page 17]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+8.  Security Considerations
+
+   Inter-layer traffic engineering with PCE may raise new security
+   issues when PCE-PCE communication is done between different layer
+   networks for inter-layer path computation.  Security issues may also
+   exist when a single PCE is granted full visibility of TE information
+   that applies to multiple layers.
+
+   The Path-Key-based mechanism defined in [RFC5520] MAY be applied to
+   address the topology confidentiality between different layers.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Functional Description",
+              RFC 3471, DOI 10.17487/RFC3471, January 2003,
+              <https://www.rfc-editor.org/info/rfc3471>.
+
+   [RFC3945]  Mannie, E., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Architecture", RFC 3945,
+              DOI 10.17487/RFC3945, October 2004,
+              <https://www.rfc-editor.org/info/rfc3945>.
+
+   [RFC4203]  Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
+              Support of Generalized Multi-Protocol Label Switching
+              (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
+              <https://www.rfc-editor.org/info/rfc4203>.
+
+   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
+              Hierarchy with Generalized Multi-Protocol Label Switching
+              (GMPLS) Traffic Engineering (TE)", RFC 4206,
+              DOI 10.17487/RFC4206, October 2005,
+              <https://www.rfc-editor.org/info/rfc4206>.
+
+   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
+              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
+              DOI 10.17487/RFC5440, March 2009,
+              <https://www.rfc-editor.org/info/rfc5440>.
+
+
+
+
+
+
+Oki, et al.                  Standards Track                   [Page 18]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc5520>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
+              Computation Element Communication Protocol (PCEP)
+              Extensions for Stateful PCE", RFC 8231,
+              DOI 10.17487/RFC8231, September 2017,
+              <https://www.rfc-editor.org/info/rfc8231>.
+
+   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
+              Computation Element Communication Protocol (PCEP)
+              Extensions for PCE-initiated LSP Setup in a Stateful PCE
+              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
+              <http://www.rfc-editor.org/info/rfc20>.
+
+9.2.  Informative References
+
+   [PCEP-YANG]
+              Dhody, D., Hardwick, J., Beeram, V., and j.
+              jefftant@gmail.com, "A YANG Data Model for Path
+              Computation Element Communications Protocol (PCEP)", Work
+              in Progress, draft-ietf-pce-pcep-yang-05, June 2017.
+
+   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
+              Element (PCE)-Based Architecture", RFC 4655,
+              DOI 10.17487/RFC4655, August 2006,
+              <https://www.rfc-editor.org/info/rfc4655>.
+
+   [RFC5150]  Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
+              "Label Switched Path Stitching with Generalized
+              Multiprotocol Label Switching Traffic Engineering (GMPLS
+              TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008,
+              <https://www.rfc-editor.org/info/rfc5150>.
+
+
+
+
+
+
+Oki, et al.                  Standards Track                   [Page 19]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+   [RFC5212]  Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
+              M., and D. Brungard, "Requirements for GMPLS-Based Multi-
+              Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
+              DOI 10.17487/RFC5212, July 2008,
+              <https://www.rfc-editor.org/info/rfc5212>.
+
+   [RFC5339]  Le Roux, JL., Ed. and D. Papadimitriou, Ed., "Evaluation
+              of Existing GMPLS Protocols against Multi-Layer and Multi-
+              Region Networks (MLN/MRN)", RFC 5339,
+              DOI 10.17487/RFC5339, September 2008,
+              <https://www.rfc-editor.org/info/rfc5339>.
+
+   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
+              Used to Form Encoding Rules in Various Routing Protocol
+              Specifications", RFC 5511, DOI 10.17487/RFC5511, April
+              2009, <https://www.rfc-editor.org/info/rfc5511>.
+
+   [RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
+              Objective Functions in the Path Computation Element
+              Communication Protocol (PCEP)", RFC 5541,
+              DOI 10.17487/RFC5541, June 2009,
+              <https://www.rfc-editor.org/info/rfc5541>.
+
+   [RFC5623]  Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
+              "Framework for PCE-Based Inter-Layer MPLS and GMPLS
+              Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
+              September 2009, <https://www.rfc-editor.org/info/rfc5623>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc5886>.
+
+   [RFC6001]  Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
+              D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
+              Extensions for Multi-Layer and Multi-Region Networks (MLN/
+              MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010,
+              <https://www.rfc-editor.org/info/rfc6001>.
+
+   [RFC6457]  Takeda, T., Ed. and A. Farrel, "PCC-PCE Communication and
+              PCE Discovery Requirements for Inter-Layer Traffic
+              Engineering", RFC 6457, DOI 10.17487/RFC6457, December
+              2011, <https://www.rfc-editor.org/info/rfc6457>.
+
+
+
+
+
+
+
+
+Oki, et al.                  Standards Track                   [Page 20]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc7420>.
+
+   [RFC7926]  Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
+              Ceccarelli, D., and X. Zhang, "Problem Statement and
+              Architecture for Information Exchange between
+              Interconnected Traffic-Engineered Networks", BCP 206,
+              RFC 7926, DOI 10.17487/RFC7926, July 2016,
+              <https://www.rfc-editor.org/info/rfc7926>.
+
+Acknowledgments
+
+   The authors would like to thank Cyril Margaria for his valuable
+   comments.  Helpful comments and suggested text were offered by Dhruv
+   Dhody, who also fixed the RBNF.  Jonathan Hardwick provided a helpful
+   review as document shepherd.
+
+Contributors
+
+   Jean-Louis Le Roux
+   France Telecom R&D
+   Av Pierre Marzin
+   Lannion 22300
+   France
+
+   Email: jeanlouis.leroux@orange.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Oki, et al.                  Standards Track                   [Page 21]
+
+RFC 8282                    Inter-Layer PCEP               December 2017
+
+
+Authors' Addresses
+
+   Eiji Oki
+   Kyoto University
+   Yoshida-honmachi, Sakyo-ku, Kyoto
+   Japan
+
+   Email: oki@i.kyoto-u.ac.jp
+
+
+   Tomonori Takeda
+   NTT
+   3-9-11 Midori-cho
+   Musashino-shi, Tokyo
+   Japan
+
+   Email: tomonori.takeda@ntt.com
+
+
+   Adrian Farrel
+   Juniper Networks
+
+   Email: afarrel@juniper.net
+
+
+   Fatai Zhang
+   Huawei Technologies Co., Ltd.
+   F3-5-B R&D Center, Huawei Base
+   Bantian, Longgang District, Shenzhen  518129
+   China
+
+   Phone: +86-755-28972912
+   Email: zhangfatai@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Oki, et al.                  Standards Track                   [Page 22]
+