Network Working Group                                            E. Oki 
 Internet Draft                                                      NTT 
 Category: Standards Track                               Tomonori Takeda 
 Created: June, 2008                                                 NTT 
 Expires: December, 2008                                     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-01.txt 
                                       
    Status of this Memo 
     
    By submitting this Internet-Draft, each author represents that any 
    applicable patent or other IPR claims of which he or she is aware 
    have been or will be disclosed, and any of which he or she becomes 
    aware will be disclosed, in accordance with Section 6 of 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 Multi-Protocol 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. 
     

  
 Oki, Takeda, Le Roux, and Farrel                              [Page 1] 
  
 PCEP Extensions for Inter-Layer TE                           June 2008 
  
     
    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. 
  
 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......................................7 
    4. Procedure....................................................8 
    4.1.  Path Computation Request..................................8 
    4.2.  Path Computation Reply....................................8 
    5. Updated Format of PCEP Messages..............................8 
    6. Manageability Considerations................................10 
    7. IANA Considerations.........................................10 
    7.1.  New PCEP Objects.........................................10 
    7.2.  New Registry for INTER-LAYER Object Flags................10 
    8. Security Considerations.....................................10 
    9. Acknowledgments.............................................11 
    10.  References.................................................11 
    10.1. Normative Reference......................................11 
    10.2. Informative Reference....................................12 
    11.  Authors' Addresses.........................................12 
    12.  Intellectual Property Statement............................12 
  
 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. 
     



  
 Oki, Takeda, Le Roux, and Farrel                              [Page 2] 
 PCEP Extensions for Inter-Layer TE                           June 2008 
  
     
    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) [MLN-REQ], 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) [MLN-REQ].  
     
    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 
    [MLN-REQ]. 
     
    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                           June 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. 
     
 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                           June 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|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 was found notwithstanding the use of inter-layer path 
    computation. 
     
    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. 
     
    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. 
     


  
 Oki, Takeda, Le Roux, and Farrel                              [Page 5] 
 PCEP Extensions for Inter-Layer TE                           June 2008 
  
     
 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. 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.  
     
    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 6] 
 PCEP Extensions for Inter-Layer TE                           June 2008 
  
     
    MUST NOT enter or traverse any layer with the specified 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                      | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     
    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. 
     



  
 Oki, Takeda, Le Roux, and Farrel                              [Page 7] 
 PCEP Extensions for Inter-Layer TE                           June 2008 
  
     
 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 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. 
     
    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. 
     
 4.2. Path Computation Reply 
     
    The requested PCE replies to the requesting PCC for the inter-layer 
    path computation result in a PCRep message including the INTER-
    LAYER object. 
     
    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 
  
    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>] 
  


  
 Oki, Takeda, Le Roux, and Farrel                              [Page 8] 
 PCEP Extensions for Inter-Layer TE                           June 2008 
  
     
          <request>::= <RP> 
                       <END-POINTS> 
                       [<OF>] 
                       [<LSPA>] 
                       [<BANDWIDTH>] 
                       [<metric-list>] 
                       [<RRO>[<BANDWIDTH>]] 
                       [<IRO>] 
                       [<LOAD-BALANCING>] 
                       [<INTER-LAYER> [<SWITCH-LAYER>]] 
                       [<REQ-ADAP-CAP>] 
       where: 
  
       <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>] 
                             [<LSPA>] 
                             [<BANDWIDTH>] 
                             [<metric-list>] 
                             [<IRO>] 
                             [<INTER-LAYER>] 
                             [<SWITCH-LAYER>] 
                             [<REQ-ADAP-CAP>] 


  
 Oki, Takeda, Le Roux, and Farrel                              [Page 9] 
 PCEP Extensions for Inter-Layer TE                           June 2008 
  
     
          <metric-list>::=<METRIC>[<metric-list>] 
     
     
 6. Manageability Considerations 
     
    TBD 
  
    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 
     
    TBD 
     
 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 
     
    TBD 
     
 8. Security Considerations 
     
    TBD 


  
 Oki, Takeda, Le Roux, and Farrel                             [Page 10] 
 PCEP Extensions for Inter-Layer TE                           June 2008 
  
     
     
    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. 
     
    [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. 
  


  
 Oki, Takeda, Le Roux, and Farrel                             [Page 11] 
 PCEP Extensions for Inter-Layer TE                           June 2008 
  
     
 10.2. Informative Reference 
     
    [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 
              Element (PCE)-Based Architecture", RFC 4655, September 
              2006. 
     
    [MLN-REQ] K. Shiomoto et al., "Requirements for GMPLS-based multi- 
              region and multi-layer networks (MRN/MLN)", draft-ietf- 
              ccamp-gmpls-mln-reqs, 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. 
      
 11. Authors' Addresses 
     
    Eiji Oki  
    NTT  
    3-9-11 Midori-cho,  
    Musashino-shi, Tokyo 180-8585, Japan 
    Email: oki.eiji@lab.ntt.co.jp 
     
    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: jeanlouis.leroux@orange-ftgroup.com 
     
    Adrian Farrel 
    Old Dog Consulting 
    Email: adrian@olddog.co.uk 
     
 12. Intellectual Property Statement 
     
    The IETF 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 this 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.  
    Information on the procedures with respect to rights in RFC 
    documents can be found in BCP 78 and BCP 79. 


  
 Oki, Takeda, Le Roux, and Farrel                             [Page 12] 
 PCEP Extensions for Inter-Layer TE                           June 2008 
  
     
     
    Copies of IPR 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 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 
    this standard.  Please address the information to the IETF at ietf-
    ipr@ietf.org. 
     
    Disclaimer of Validity 
     
    This document and the information contained herein 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 HEREIN WILL NOT INFRINGE 
    ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
    FOR A PARTICULAR PURPOSE. 
     
    Copyright Statement 
     
    Copyright (C) The IETF Trust (2008). 
     
     
    This document is subject to the rights, licenses and restrictions 
    contained in BCP 78, and except as set forth therein, the authors 
    retain all their rights. 

















  
 Oki, Takeda, Le Roux, and Farrel                             [Page 13]