Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8282.
Expired & archived
Authors Eiji Oki , Tomonori Takeda , Adrian Farrel , Fatai Zhang
Last updated 2013-01-14 (Latest revision 2012-07-13)
Replaces draft-oki-pce-inter-layer-ext
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 8282 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-pce-inter-layer-ext-07
Network Working Group                                             E. Oki 
Internet-Draft                                                 UEC Tokyo 
Intended status: Standards Track                         Tomonori Takeda 
                                                                     NTT 
                                                             J-L Le Roux 
                                                          France Telecom 
                                                               A. Farrel 
                                                        Juniper Networks 
                                                             Fatai Zhang 
                                                                  Huawei 
Expires: January 13, 2013                                  July 13, 2012 
                                      

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

Status of this Memo 

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

   Internet-Drafts are working documents of the Internet Engineering   
   Task Force (IETF), its areas, and its working groups.  Note that   
   other groups may also distribute working documents as Internet-   
   Drafts. 

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

   The list of current Internet-Drafts can be accessed at   
   http://www.ietf.org/ietf/1id-abstracts.txt. 

   The list of Internet-Draft Shadow Directories can be accessed at   
   http://www.ietf.org/shadow.html. 

   This Internet-Draft will expire on January 13, 2013. 

    

Abstract 

 
 
 
<E. Oki>                Expires January 2013                  [Page 1] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   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. 

Conventions used in this document 

   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 RFC-2119 [RFC2119]. 

Table of Contents 

    
   1. Introduction ................................................. 3 
   2. Overview of PCE-Based Inter-Layer Path Computation ........... 3 
   3. Protocol Extensions .......................................... 4 
      3.1. INTER-LAYER Object....................................... 4 
      3.2. SWITCH-LAYER Object ..................................... 7 
      3.3. REQ-ADAP-CAP Object ..................................... 8 
      3.4. New Metric Types......................................... 9 
      3.5. ERO sub-object ......................................... 10 
   4. Procedures .................................................. 10 
      4.1. Path Computation Request ............................... 10 
      4.2. Path Computation Reply ................................. 11 
   5. Updated Format of PCEP Messages ............................. 12 
   6. Manageability Considerations ................................ 13 
   7. IANA Considerations ......................................... 13 
      7.1. New PCEP Objects........................................ 13 
      7.2. New Registry for INTER-LAYER Object Flags .............. 14 
      7.3. METRIC Type ............................................ 15 
   8. Security Considerations ..................................... 15 
   9. Acknowledgments ............................................. 15 
   10. References ................................................. 15 
      10.1. Normative References .................................. 15 
      10.2. Informative References ................................ 16 
   11. Authors' Addresses ......................................... 16 
    
 
 
E. Oki                  Expires January 2013                  [Page 2] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

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. 

   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., PSC-1 
   and  PSC-2, or 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]. 

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

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. 
 
 
E. Oki                  Expires January 2013                  [Page 3] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   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 nodes may advertise a single TE 
   link with multiple switching capabilities. Those TE links exist at 
   the layer/region boarder normally. In this case, 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. 

3. Protocol Extensions  

   This section describes PCEP extensions for inter-layer path 
   computation. Three new objects are defined: the INTER-LAYER object, 
   the SWITCH-LAYER object, the REQ-ADAP-CAP object and SERVER-
   INDICATION. 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. 

   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). 
 
 
E. Oki                  Expires January 2013                  [Page 4] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   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. 

   INTER-LAYER Object-Class is to be assigned by IANA (recommended 
   value=18) 

   INTER-LAYER Object-Type is to be assigned by IANA (recommended 
   value=1) 

   The format of the INTER-LAYER object body is as follows: 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    Reserved                                             |T|M|I| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    

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

 
 
E. Oki                  Expires January 2013                  [Page 5] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   is set (one), multi-layer path is returned. When M flag is set (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. 

   - A mono-layer path that is specified by strict hops. The path may 
   include virtual TE links. 

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

   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. 

   - 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. 
 
 
E. Oki                  Expires January 2013                  [Page 6] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   - 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 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 SHOULD be transmitted as zero 
   and SHOULD be ignored on receipt. A PCE that forwards a path 
   computation request to other PCEs SHOULD preserve the settings of 
   reserved bits in the PCReq messages it sends and in the PCRep 
   messages it forwards to PCCs. 

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. 

   SWITCH-LAYER Object-Class is to be assigned by IANA (recommended 
   value=19) 

   SWITCH-LAYER Object-Type is to be assigned by IANA (recommended 
   value=1) 

   The format of the SWITCH-LAYER object body is as follows: 

 
 
E. Oki                  Expires January 2013                  [Page 7] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

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

   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 
   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. 
 
 
E. Oki                  Expires January 2013                  [Page 8] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   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 INTER-LAYER 
   Object. 

   REQ-ADAP-CAP Object-Class is to be assigned by IANA (recommended 
   value=20) 

   REQ-ADAP-CAP Object-Type is to be assigned by IANA (recommended 
   value=1) 

   The format of the REQ-ADAP-CAP object body is as follows: 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Switching Cap |   Encoding    | Reserved                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    

   The format is based on [RFC6001] and has equivalent semantics as the 
   IACD Upper SC and Lower SC. 

   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 

   Two new metric types are defined for the METRIC object in PCEP. 

   Type 11 (suggested value, to be assigned by IANA): Number of 
   adaptations on a path. 

   Type 12 (suggested value, to be assigned by IANA): Number of layers 
   to be involved on a path. 

    
 
 
E. Oki                  Expires January 2013                  [Page 9] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

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.  

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

   The type of SERVER-INDICATION   object is 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).  

  

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 

 
 
E. Oki                  Expires January 2013                 [Page 10] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   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 11 (TBC by IANA) is used, it 
   indicates that path computation MUST minimize or bound the number of 
   adaptations on a path. When metric type 12 (TBC by IANA) 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 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]. 

   PCE MAY specify the server layer path information in the ERO. In this 
   case, the requested PCE replies 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. 

 
 
E. Oki                  Expires January 2013                 [Page 11] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   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. 

5. Updated Format of PCEP Messages 

   Message formats in this section, as those in [RFC5440] are presented 
   using Backus-Naur Format as specified in [RFC5511]. 

   The format of the PCReq message is updated as follows: 

   <PCReq Message>::= <Common Header> 
                      [<SVEC-list>] 
                      <request-list> 
    
      where: 
         <svec-list>::=<SVEC> 
                       [<svec-list>] 
    
         <request-list>::=<request>[<request-list>] 
    
         <request>::= <RP> 
                      <END-POINTS> 
                      [<of-list>] 
                      [<LSPA>] 
                      [<BANDWIDTH>] 
                      [<metric-list>] 
                      [<RRO>[<BANDWIDTH>]] 
                      [<IRO>] 
                      [<LOAD-BALANCING>] 
                      [<INTER-LAYER> [<SWITCH-LAYER>]] 
                      [<REQ-ADAP-CAP>] 
      where: 
    
      <of-list>::=<OF>[<of-list>] 
      <metric-list>::=<METRIC>[<metric-list>] 
    
   The format of the PCRep message is updated as follows: 
   <PCRep Message> ::= <Common Header> 
                       <response-list> 
    

 
 
E. Oki                  Expires January 2013                 [Page 12] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

      where: 
         <response-list>::=<response>[<response-list>] 
    
         <response>::=<RP> 
                     [<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>] 
    

6. Manageability Considerations 

   Manageability of inter-layer traffic engineering with PCE must 
   address the following consideration for section 5.1. 

   - need for a MIB module for control and monitoring 
   - need for built-in diagnostic tools 
   - configuration implication for the protocol 
    
7. IANA Considerations 

7.1. New PCEP Objects 

   Four new objects: INTER-LAYER object, SWITCH-LAYER object, REQ-ADAP-
   CAP and SERVER-INDICATION object. 

 
 
E. Oki                  Expires January 2013                 [Page 13] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   INTER-LAYER Object-Class is to be assigned by IANA (recommended 
   value=18) 

   INTER-LAYER Object-Type is to be assigned by IANA (recommended 
   value=1) 

   SWITCH-LAYER Object-Class is to be assigned by IANA (recommended 
   value=19) 

   SWITCH-LAYER Object-Type is to be assigned by IANA (recommended 
   value=1) 

   REQ-ADAP-CAP Object-Class is to be assigned by IANA (recommended 
   value=20) 

   REQ-ADAP-CAP Object-Type is to be assigned by IANA (recommended 
   value=1) 

   SERVER-INDICATION Object-Class is to be assigned by IANA (recommended 
   value=21) 

   SERVER-INDICATION Object-Type is to be assigned by IANA (recommended 
   value=1) 

7.2. New Registry for INTER-LAYER Object Flags 

   IANA is requested to create a registry to manage the Flag field of 
   the INTER-Layer object. 

   New bit numbers may be allocated only by an IETF Consensus action. 
   Each bit should be tracked with the following qualities: 

   o  Bit number (counting from bit 0 as the most significant bit) 

   o  Capability Description 

   o  Defining RFC 

   Several bits are defined for the INTER-LAYER object flag fields in 
   this document. The following values have been assigned: 

   Bit Number   Description   Reference 

    29            T flag        this document 
    30            M flag        this document 
    31            I flag        this document 
 
 
E. Oki                  Expires January 2013                 [Page 14] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

    
7.3. METRIC Type 

   Two new metric types are defined in this document for the METRIC 
   object (specified in [RFC5440]). The IANA is requested to make the 
   following allocation (suggested value): 

   - Type 11 : Number of adaptations on a path  

   - Type 12 : Number of layers on a path  

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.  

   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. 

10. References 

10.1. Normative References 

   [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 
             requirements levels", RFC 2119, March 1997.  

   [RFC3471] L. Burger, "Generalized Multi-Protocol Label Switching 
             (GMPLS)", RFC 3471, January 2003. 

   [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching 
             Architecture", RFC 3945, October 2004. 

   [RFC4203] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of 
             Generalized Multi-Protocol Label Switching (GMPLS)", RFC 
             4203, October 2005. 

 
 
E. Oki                  Expires January 2013                 [Page 15] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   [RFC4206] K. Kompella, and Y. Rekhter, "Label Switched Paths (LSP) 
             Hierarchy with Generalized Multi-Protocol Label Switching 
             (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 

   [RFC5440] JP. Vasseur et al, "Path Computation Element (PCE) 
             Communication Protocol (PCEP)" RFC 5440, March 2009. 

   [RFC6457] E. Oki et al., "PCC-PCE Communication Requirements for 
             Inter-Layer Traffic Engineering", RFC6457, December 2011. 

   [RFC5623] E. Oki et al., "Framework for PCE-Based Inter-Layer MPLS 
             and GMPLS Traffic Engineering", September 2009. 

   [RFC5339] JL. Le Roux et al, "Evaluation of Existing GMPLS Protocols 
             against Multi-Layer and Multi-Region Networks (MLN/MRN)", 
             RFC5339, September 2008.  

10.2. Informative References 

   [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 
             Element (PCE)-Based Architecture", RFC 4655, September 2006. 

   [RFC5212] K. Shiomoto et al., "Requirements for GMPLS-based multi-
             region and multi-layer networks (MRN/MLN)", RFC 5212, July 
             2008. 

   [RFC6001] D. Papadimitriou et al., "Generalized Multi-Protocol Label 
             Switching (GMPLS) Protocol Extensions for Multi-Layer and 
             Multi-Region Networks (MLN/MRN)", RFC6001, October 2010. 

   [RFC5150] A. Ayyangar et al., "Label Switched Path Stitching with 
             Generalized Multiprotocol Label Switching Traffic 
             Engineering (GMPLS TE)", RFC 5150, February 2008. 

   [RFC5511] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used 
             in Various Protocol Specifications", April 2009. 

    

11. Authors' Addresses 

   Eiji Oki
   University of Electro-Communications 
   Tokyo 
   Japan 
   Email: oki@ice.uec.ac.jp 
 
 
E. Oki                  Expires January 2013                 [Page 16] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   Tomonori Takeda
   NTT 
   3-9-11 Midori-cho, 
   Musashino-shi, Tokyo 180-8585, Japan 
   Email: takeda.tomonori@lab.ntt.co.jp 
 
 
   Jean-Louis Le Roux
   France Telecom R&D, 
   Av Pierre Marzin, 
   22300 Lannion, France 
   Email: julien.meuric@orange.com 

   Adrian Farrel
   Juniper Networks 
   Email: adrian@olddog.co.uk 

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

   The IETF Trust takes no position regarding the validity or scope of   
   any Intellectual Property Rights or other rights that might be   
   claimed to pertain to the implementation or use of the technology   
   described in any IETF Document or the extent to which any license   
   under such rights might or might not be available; nor does it   
   represent that it has made any independent effort to identify any   
   such rights. 

   Copies of Intellectual Property disclosures made to the IETF   
   Secretariat and any assurances of licenses to be made available, or   
   the result of an attempt made to obtain a general license or   
 
 
E. Oki                  Expires January 2013                 [Page 17] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   permission for the use of such proprietary rights by implementers or   
   users of this specification can be obtained from the IETF on-line IPR   
   repository at http://www.ietf.org/ipr 

   The IETF invites any interested party to bring to its attention any   
   copyrights, patents or patent applications, or other proprietary   
   rights that may cover technology that may be required to implement   
   any standard or specification contained in an IETF Document. Please   
   address the information to the IETF at ietf-ipr@ietf.org. 

   The definitive version of an IETF Document is that published by, or   
   under the auspices of, the IETF. Versions of IETF Documents that are   
   published by third parties, including those that are translated into   
   other languages, should not be considered to be definitive versions   
   of IETF Documents. The definitive version of these Legal Provisions   
   is that published by, or under the auspices of, the IETF. Versions of   
   these Legal Provisions that are published by third parties, including   
   those that are translated into other languages, should not be   
   considered to be definitive versions of these Legal Provisions. 

   For the avoidance of doubt, each Contributor to the IETF Standards   
   Process licenses each Contribution that he or she makes as part of   
   the IETF Standards Process to the IETF Trust pursuant to the   
   provisions of RFC 5378. No language to the contrary, or terms,   
   conditions or rights that differ from or are inconsistent with the   
   rights and licenses granted under RFC 5378, shall have any effect and   
   shall be null and void, whether published or posted by such   
   Contributor, or included with or in such Contribution. 

Disclaimer of Validity 
 
   All IETF Documents and the information contained therein are provided   
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE   
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE   
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL   
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY   
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE   
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS   
   FOR A PARTICULAR PURPOSE. 

 
Full Copyright Statement 
 
   Copyright (c) 2010 IETF Trust and the persons identified as the   
   document authors.  All rights reserved. 

 
 
E. Oki                  Expires January 2013                 [Page 18] 


draft-ietf-pce-inter-layer-ext-07.txt                         July 2012 
    

   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. 

 
 
E. Oki                  Expires January 2013                 [Page 19]