Network Working Group                                            E. Oki
 Internet Draft                                                UEC Tokyo
 Category: Standards Track                               Tomonori Takeda
 Created: December 2008                                              NTT
 Expires: June 2009                                          J-L Le Roux
                                                          France Telecom
                                                               A. Farrel
                                                      Old Dog Consulting
 
     Extensions to the Path Computation Element communication Protocol
         (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering
 
                   draft-ietf-pce-inter-layer-ext-02.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.
 
 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
 
 
 Oki, Takeda, Le Roux, and Farrel                              [Page 1]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    PCEs. This document presents PCEP extensions for inter-layer
    traffic engineering.
 
 Table of Contents
 
    1. Introduction.................................................2
    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.......................................6
    3.2.1.  REQ-ADAP-CAP Object.....................................8
    3.3.  New Metric Type...........................................9
    4. Procedure....................................................9
    4.1.  Path Computation Request..................................9
    4.2.  Path Computation Reply...................................10
    5. Updated Format of PCEP Messages.............................10
    6. Manageability Considerations................................11
    7. IANA Considerations.........................................12
    7.1.  New PCEP Objects.........................................12
    7.2.  New Registry for INTER-LAYER Object Flags................12
    7.3.  METRIC Type..............................................13
    8. Security Considerations.....................................13
    9. Acknowledgments.............................................13
    10.  References................................................13
    10.1. Normative Reference......................................13
    10.2. Informative Reference....................................14
    11.  Authors' Addresses........................................14
 
 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].
 
 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),
 
 
 
 Oki, Takeda, Le Roux, and Farrel                              [Page 2]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    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 [PCE-INTER-LAYER-FRWK].
 
    The PCE communication protocol (PCEP) is designed as a
    communication protocol between PCCs and PCEs and is defined in
    [PCEP]. A set of requirements for PCEP extensions to support inter-
    layer traffic engineering is described in [PCE-INTER-LAYER-REQ].
 
    This document presents PCEP extensions for inter-layer traffic
    engineering that satisfy the requirements described in [PCE-INTER-
    LAYER-REQ].
 
 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.
 
 
 
 
 
 Oki, Takeda, Le Roux, and Farrel                              [Page 3]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    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.
 
    [PCE-INTER-LAYER-FRWK] 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, and the REQ-ADAP-CAP object. Also, a new
    metric type is 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).
 
    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)
 
 
 
 
 
 Oki, Takeda, Le Roux, and Farrel                              [Page 4]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    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 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.
 
    [PCE-INTER-LAYER-REQ] 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.
 
 
 
 
 
 Oki, Takeda, Le Roux, and Farrel                              [Page 5]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    The choice of this sub-option can be specified by the use of O flag
    in the RP object specified in [PCEP].
 
    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.
    - 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
 
 
 
 
 
 Oki, Takeda, Le Roux, and Farrel                              [Page 6]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    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. The SWITCH-LAYER object MUST NOT be used on a PCReq
    unless an INTER-LAYER object is also present on the PCReq message.
 
    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:
 
     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
 
 
 
 
 Oki, Takeda, Le Roux, and Farrel                              [Page 7]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    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.2.1. 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 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 [MLN-SOL] and has equivalent semantics.
 
    Switching Capability (8 bits): see [RFC4203] for a description of
    parameters.
 
 
 
 
 Oki, Takeda, Le Roux, and Farrel                              [Page 8]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    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.3. New Metric Type
 
    A new metric type is defined for the METRIC object in PCEP.
 
    Type 11 (suggested value, to be assigned by IANA): Number of
    adaptations on a path.
 
 4. Procedure
 
 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 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.
 
    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
 
 
 
 Oki, Takeda, Le Roux, and Farrel                              [Page 9]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    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
    [PCEP].
 
    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 [PCEP] are presented
     using Backus-Naur Format as specified in [RBNF].
 
    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>]
 
 
 
 Oki, Takeda, Le Roux, and Farrel                             [Page 10]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
                       [<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>
 
       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>]
          <of-list>::=<OF>[<of-list>]
          <metric-list>::=<METRIC>[<metric-list>]
 
 6. Manageability Considerations
 
    TBD
 
    Manageability of inter-layer traffic engineering with PCE must
 
 
 
 Oki, Takeda, Le Roux, and Farrel                             [Page 11]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    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
 
    Three new objects: the INTER-LAYER object, the SWITCH-LAYER object,
    and the REQ-ADAP-CAP object.
 
    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)
 
 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:
 
 
 
 
 Oki, Takeda, Le Roux, and Farrel                             [Page 12]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    Bit Number   Description   Reference
     29           T flag        this document
     30           M flag        this document
     31           I flag        this document
 
 7.3. METRIC Type
 
    A new metric type is defined in this document for the METRIC object
    (specified in [PCEP]). The IANA is requested to make the following
    allocation (suggested value):
 
    - Type 11 : Number of adaptations on a path
 
 8. Security Considerations
 
    TBD
 
    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.
 
    It is expected that solutions for inter-layer protocol extensions
    will address these issues in detail using security techniques such
    as authentication.
 
 9. Acknowledgments
 
 
 
 10. References
 
 10.1. Normative Reference
 
    [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.
 
 
 
 
 Oki, Takeda, Le Roux, and Farrel                             [Page 13]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    [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.
 
    [PCEP]    JP. Vasseur et al, "Path Computation Element (PCE)
              communication Protocol (PCEP)" draft-ietf-pce-pcep, work
              in progress.
 
    [PCE-INTER-LAYER-REQ] E. Oki et al., "PCC-PCE Communication
              Requirements for Inter-Layer Traffic Engineering", draft-
              ietf-pce-inter-layer-req, work in progress.
 
    [PCE-INTER-LAYER-FRWK] E. Oki et al., "Framework for PCE-Based
              Inter-Layer MPLS and GMPLS Traffic Engineering", draft-
              ietf-pce-inter-layer-frwk, work in progress.
 
 10.2. Informative Reference
 
    [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.
 
    [MLN-SOL] D. Papadimitriou et al., " Generalized Multi-Protocol
              Label Switching (GMPLS) Protocol Extensions for Multi-
              Layer and Multi-Region Networks (MLN/MRN)", draft-ietf-
              ccamp-gmpls-mln-extensions, work in progress.
 
    [RFC5150] A. Ayyangar et al., "Label Switched Path Stitching
              with Generalized Multiprotocol Label Switching Traffic
              Engineering (GMPLS TE)", RFC 5150, February 2008.
 
    [RBNF]    Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax
              Used in Various Protocol Specifications", draft-farrel-
              rtg-common-bnf, work in progress.
 
 11. Authors' Addresses
 
    Eiji Oki
    University of Electro-Communications
    Tokyo
    Japan
    Email: oki@ice.uec.ac.jp
 
    Tomonori Takeda
 
 
 
 Oki, Takeda, Le Roux, and Farrel                             [Page 14]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    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: jeanlouis.leroux@orange-ftgroup.com
 
    Adrian Farrel
    Old Dog Consulting
    Email: adrian@olddog.co.uk
 
 Full Copyright Statement
 
    Copyright (c) 2008 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.
 
    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.
 
    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
 
 
 
 Oki, Takeda, Le Roux, and Farrel                             [Page 15]


 PCEP Extensions for Inter-Layer TE                       December 2008
 
 
    the result of an attempt made to obtain a general license or
    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.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Oki, Takeda, Le Roux, and Farrel                             [Page 16]