PCE Working Group                                                 E. Oki
Internet-Draft                      University of Electro-Communications
Intended status: Standards Track                               T. Takeda
Expires: July 7, 2017                                                NTT
                                                               A. Farrel
                                                        Juniper Networks
                                                                F. Zhang
                                           Huawei Technologies Co., Ltd.
                                                         January 3, 2017


Extensions to the Path Computation Element communication Protocol (PCEP)
           for Inter-Layer MPLS and GMPLS Traffic Engineering
                   draft-ietf-pce-inter-layer-ext-12

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.

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].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.




Oki, et al.               Expires July 7, 2017                  [Page 1]


Internet-Draft              Inter-Layer PCEP                January 2017


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 7, 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
   (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
   2.  Overview of PCE-Based Inter-Layer Path Computation  . . . . .   4
   3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  INTER-LAYER Object  . . . . . . . . . . . . . . . . . . .   4
     3.2.  SWITCH-LAYER Object . . . . . . . . . . . . . . . . . . .   7
     3.3.  REQ-ADAP-CAP Object . . . . . . . . . . . . . . . . . . .   9
     3.4.  New Metric Types  . . . . . . . . . . . . . . . . . . . .  10
     3.5.  SERVER-INDICATION Object  . . . . . . . . . . . . . . . .  10
   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 . . . . . . . . . . . . . . .  13
   6.  Manageability Considerations  . . . . . . . . . . . . . . . .  15
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     7.1.  New PCEP Objects  . . . . . . . . . . . . . . . . . . . .  16
     7.2.  New Registry for INTER-LAYER Object Flags . . . . . . . .  16
     7.3.  New Metric Types  . . . . . . . . . . . . . . . . . . . .  17
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  18
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  18
     11.2.  Informative References . . . . . . . . . . . . . . . . .  19



Oki, et al.               Expires July 7, 2017                  [Page 2]


Internet-Draft              Inter-Layer PCEP                January 2017


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

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 ([I-D.ietf-pce-stateful-pce],
   [I-D.ietf-pce-pce-initiated-lsp]).

   A network may comprise multiple layers.  These layers may represent
   separations of technologies (e.g., packet switch capable (PSC), time
   division multiplex (TDM), lambda switch capable (LSC)) [RFC3945],
   separation of data plane switching granularity levels (e.g., 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.               Expires July 7, 2017                  [Page 3]


Internet-Draft              Inter-Layer PCEP                January 2017


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], and hence 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.  Those TE links exist at
   the layer/region boarder normally.  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 signalling, 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.

3.1.  INTER-LAYER Object

   The INTER-LAYER object is optional and can be used in PCReq and PCRep
   messages, and also in PCRpt, PCUpd, and 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,



Oki, et al.               Expires July 7, 2017                  [Page 4]


Internet-Draft              Inter-Layer PCEP                January 2017


   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 follows
   as the usage of other objects on those messages as described in
   [I-D.ietf-pce-stateful-pce].  The applicability of this object to the
   PCInitiate message follows as the usage of other objects on those
   messages as described in [I-D.ietf-pce-pce-initiated-lsp].  These
   messages use the <attribute-list> as defined in [RFC5440] and
   extended by further PCEP extensions, and 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 TBD1 to be assigned by IANA.

   INTER-LAYER Object-Type 1 to be assigned by IANA.

   The format of the INTER-LAYER object body is shown in Figure 1.


       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.




Oki, et al.               Expires July 7, 2017                  [Page 5]


Internet-Draft              Inter-Layer PCEP                January 2017


   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 either because inter-
   layer path computation was not performed or because 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 mono-layer path or multi-layer path is
   requested.  When the M flag is set (one), multi-layer path is
   requested.  When it is clear (zero), mono-layer path is requested.

   The M flag is used by a PCE in a PCRep message to indicate to a PCC
   whether mono-layer path or multi-layer path is returned.  When M flag
   is set (one), multi-layer path is returned.  When M flag is clear
   (zero), 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 O flag
   in the RP object specified in [RFC5440].

   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.





Oki, et al.               Expires July 7, 2017                  [Page 6]


Internet-Draft              Inter-Layer PCEP                January 2017


   If the I flag is clear (zero), the T flag has no meaning and MUST be
   ignored.

   Note that the I flag and M flag 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 inter-
      layer path is setup even though the path computation result from a
      PCE to a PCC include 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.

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.




Oki, et al.               Expires July 7, 2017                  [Page 7]


Internet-Draft              Inter-Layer PCEP                January 2017


   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 SWTCH-LAYER object may be used on a PCRpt message consistent with
   how properties of existing LSPs are reported on that message
   [I-D.ietf-pce-stateful-pce].  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 SWTCH-LAYER object
   is not used on a PCUpd or PCInitiate messages.

   SWITCH-LAYER Object-Class TBD2 is to be assigned by IANA.

   SWITCH-LAYER Object-Type 1 is to be assigned by IANA.

   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

   Each row indicates a switching type and encoding type that must or
   must not be used for 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



Oki, et al.               Expires July 7, 2017                  [Page 8]


Internet-Draft              Inter-Layer PCEP                January 2017


   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 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 follows
   as the usage of other objects on those messages as described in
   [I-D.ietf-pce-stateful-pce].  The applicability of this object to the
   PCInitiate message follows as the usage of other objects on those
   messages as described in [I-D.ietf-pce-pce-initiated-lsp].  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 TBD3 is to be assigned by IANA.

   REQ-ADAP-CAP Object-Type 1 is to be assigned by IANA.

   The format of the REQ-ADAP-CAP object body is shown in Figure 3.




Oki, et al.               Expires July 7, 2017                  [Page 9]


Internet-Draft              Inter-Layer PCEP                January 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 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 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 TBD5 to indicate the metric "Number of
   adaptations on a path."

   IANA has assigned the value TBD6 to indicate the metric "Number of
   layers to be involved on a path."

   See Section 4.1, Section 4.2, and Section 4.3 for a description of
   how these metrics are applied.

3.5.  SERVER-INDICATION Object

   The SERVER-INDICATION is optional and is used to indicate that path
   information included in the ERO is server layer information and
   specify 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.








Oki, et al.               Expires July 7, 2017                 [Page 10]


Internet-Draft              Inter-Layer PCEP                January 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Switching Cap |   Encoding    |           Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                       Optional TLVs                           ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 4: The SERVER-INDICATION Object

   SERVER-INDICATION Object-Class TBD4 to be assigned by IANA.

   SERVER-INDICATION Object-Type 1 to be assigned by IANA.

   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
   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



Oki, et al.               Expires July 7, 2017                 [Page 11]


Internet-Draft              Inter-Layer PCEP                January 2017


   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 TBD5 is used, it indicates
   that path computation MUST minimize or bound the number of
   adaptations on a path.  When metric type TBD6 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 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 flag, M
   flag, and T flag 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, ingress node) can trigger the signaling to setup the LSPs
   according to the computed paths.

   In the case of unsuccessful path computation, the PCRep message also
   contains a NO-PATH object, and the SWITCH-TYPE object and/or the REQ-
   ADAP-CAP MAY be used to indicate the set of constraints that could
   not be satisfied.







Oki, et al.               Expires July 7, 2017                 [Page 12]


Internet-Draft              Inter-Layer PCEP                January 2017


4.3.  Stateful PCE and PCE Initiated LSPs

   Processing for stateful PCEs is described in
   [I-D.ietf-pce-stateful-pce].  That document defines the PCRpt message
   to allow a PCC to report to a PCE an LSP that 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, [I-D.ietf-pce-stateful-pce] 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
   [I-D.ietf-pce-pce-initiated-lsp].  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 [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-pce-initiated-lsp]
   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 enable the use of inter-
   layer parameters during passive stateful operations too, using the
   LSP object.

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








Oki, et al.               Expires July 7, 2017                 [Page 13]


Internet-Draft              Inter-Layer PCEP                January 2017


      <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.               Expires July 7, 2017                 [Page 14]


Internet-Draft              Inter-Layer PCEP                January 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.

   However, the preferred mechanism for configuration is through a YANG
   model.  Work has started on a YANG model for PCEP



Oki, et al.               Expires July 7, 2017                 [Page 15]


Internet-Draft              Inter-Layer PCEP                January 2017


   [I-D.ietf-pce-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 the "Path Computation Element
   Protocol (PCEP) Numbers".  This document requests IANA to carry out
   actions on subregistries of that registry.

7.1.  New PCEP Objects

   IANA is requested to make the following assignments from the "PCEP
   Objects" subregistry.


      Object-Class Value |Name   |Object-Type            |Reference
      -------------------+-------+-----------------------+-----------
      INTER-LAYER        | TBD1  | 1: Inter-layer        | [This.I-D]
                         |       | 2-15: Unassigned      |
      SWITCH-LAYER       | TBD2  | 1: Switch-layer       | [This.I-D]
                         |       | 2-15: Unassigned      |
      REQ-ADAP-CAP       | TBD3  | 1: Req-Adap-Cap       | [This.I-D]
                         |       | 2-15: Unassigned      |
      SERVER-INDICATION  | TBD4  | 1: Server-indication  | [This.I-D]


                                 Figure 7

7.2.  New Registry for INTER-LAYER Object Flags

   IANA is requested to create 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 an "IETF Review" action
   [RFC5226].  Each bit should be tracked with the following qualities:





Oki, et al.               Expires July 7, 2017                 [Page 16]


Internet-Draft              Inter-Layer PCEP                January 2017


   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 is requested to pre-populate the registry as follows:


      Bit | Flag | Multi-Layer Path Property     | Reference
      ----+------+-------------------------------+------------
      0-28| Unassigned                           |
       29 |   T  | Triggered Signalling Allowed  | [This.I-D]
       30 |   M  | Multi-Layer Requested         | [This.I-D]
       31 |   I  | Inter-Layer Allowed           | [This.I-D]


                                 Figure 8

7.3.  New Metric Types

   Two new metric types are defined in this document for the METRIC
   object (specified in [RFC5440]).  The IANA is requested to make the
   following allocations from the "Metric Object T Field" registry.


      Value | Description                     | Reference
      ------+---------------------------------+------------
       TBD5 | Number of adaptations on a path | [This.I-D]
       TBD6 | Number of layers on a path      | [This.I-D]


                                 Figure 9

   IANA is further requested to update the registry to show an
   assignment action of "IETF Consensus" as already documented in
   [RFC5440].

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.





Oki, et al.               Expires July 7, 2017                 [Page 17]


Internet-Draft              Inter-Layer PCEP                January 2017


   Path-Key-based mechanism defined in [RFC5520] MAY be applied to
   address the topology confidentiality between different layers.

9.  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.

10.  Contributors


      Jean-Louis Le Roux
      France Telecom R&D
      Av Pierre Marzin
      Lannion
      France
      22300

      Email: jeanlouis.leroux@orange.com


11.  References

11.1.  Normative References

   [I-D.ietf-pce-pce-initiated-lsp]
              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
              Extensions for PCE-initiated LSP Setup in a Stateful PCE
              Model", draft-ietf-pce-pce-initiated-lsp-07 (work in
              progress), July 2016.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
              Extensions for Stateful PCE", draft-ietf-pce-stateful-
              pce-18 (work in progress), December 2016.

   [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>.

   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Functional Description",
              RFC 3471, DOI 10.17487/RFC3471, January 2003,
              <http://www.rfc-editor.org/info/rfc3471>.




Oki, et al.               Expires July 7, 2017                 [Page 18]


Internet-Draft              Inter-Layer PCEP                January 2017


   [RFC3945]  Mannie, E., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Architecture", RFC 3945,
              DOI 10.17487/RFC3945, October 2004,
              <http://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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc4206>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [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>.

   [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>.

11.2.  Informative References

   [I-D.ietf-pce-pcep-yang]
              Dhody, D., Hardwick, J., Beeram, V., and j.
              jefftant@gmail.com, "A YANG Data Model for Path
              Computation Element Communications Protocol (PCEP)",
              draft-ietf-pce-pcep-yang-01 (work in progress), October
              2016.

   [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>.






Oki, et al.               Expires July 7, 2017                 [Page 19]


Internet-Draft              Inter-Layer PCEP                January 2017


   [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,
              <http://www.rfc-editor.org/info/rfc5150>.

   [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,
              <http://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,
              <http://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, <http://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,
              <http://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, <http://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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc6001>.







Oki, et al.               Expires July 7, 2017                 [Page 20]


Internet-Draft              Inter-Layer PCEP                January 2017


   [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, <http://www.rfc-editor.org/info/rfc6457>.

   [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>.

   [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,
              <http://www.rfc-editor.org/info/rfc7926>.

Authors' Addresses

   Eiji Oki
   University of Electro-Communications
   Tokyo
   Japan

   Email: oki@ice.uec.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










Oki, et al.               Expires July 7, 2017                 [Page 21]


Internet-Draft              Inter-Layer PCEP                January 2017


   Fatai Zhang
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District, Shenzhen  518129
   P. R. China

   Phone: +86-755-28972912
   Email: zhangfatai@huawei.com











































Oki, et al.               Expires July 7, 2017                 [Page 22]