[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-oki-pce-inter-layer-ext) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 8282

Network Working Group                                             E. Oki
Internet Draft                                                       NTT
Category: Standards Track                                    J-L Le Roux
Created: February 18, 2008                                France Telecom
Expires: August 18, 2008                                       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-00.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.

   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.


Oki, Le Roux, and Farrel                                        [Page 1]


PCEP Extensions for Inter-Layer TE                         February 2008

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........................................5
   3.2.1. REQ-ADAP-CAP Object......................................6
   4. Procedure....................................................7
   4.1. Path Computation Request...................................7
   4.2. Path Computation Reply.....................................8
   5. Updated Format of PCEP Messages..............................8
   6. Manageability considerations.................................9
   7. IANA considerations..........................................9
   8. Security Considerations.....................................10
   9. Acknowledgments.............................................10
   10. References.................................................10
   10.1. Normative Reference......................................10
   10.2. Informative Reference....................................11
   11. Authors' Addresses.........................................11
   12. Intellectual Property Statement............................11

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),
   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 upper-layer LSPs. The network
   topology formed by lower-layer LSPs and advertised to the higher
   layer is called a Virtual Network Topology (VNT) [MLN-REQ].

Oki, Le Roux, and Farrel                                        [Page 2]


PCEP Extensions for Inter-Layer TE                         February 2008

   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.

   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.


Oki, Le Roux, and Farrel                                        [Page 3]


PCEP Extensions for Inter-Layer TE                         February 2008

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 nested signaling is allowed. When the INTER-LAYER
   object is absent from a PCReq message, the receiving PCE SHOULD
   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 nested 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, 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                                               |N|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

Oki, Le Roux, and Farrel                                        [Page 4]


PCEP Extensions for Inter-Layer TE                         February 2008

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

   N flag (1 bit): the N flag is used by a PCC in a PCReq message to
   indicate to a PCE whether nested signaling is allowed. When the N
   flag is set (one), nested signaling is allowed. When it is clear
   (zero), nested signaling is not allowed.

   The N flag is used by a PCE in a PCRep message to indicate to a PCC
   whether nested signaling is required to support the returned path.
   When the N flag is set (one), nested signaling is required. When it
   is clear (zero), nested signaling is not required.

   Note that nested signaling is used to support hierarchical
   [RFC4206] or stitched [LSP-STITCH] LSPs according to the physical
   attributes of the network layers.

   If the I flag is clear (zero), the N 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.

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

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

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




Oki, Le Roux, and Farrel                                        [Page 5]


PCEP Extensions for Inter-Layer TE                         February 2008

   The format of the SWTICH-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 the 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 or NOT a layer with
   the specified switching type and encoding type MUST 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.

   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 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 can be carried within a PCReq message and a
   PCRep message. It 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).



Oki, Le Roux, and Farrel                                        [Page 6]


PCEP Extensions for Inter-Layer TE                         February 2008

   The REQ-ADAP-CAP object MAY be used 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.

4. Procedure

4.1. Path Computation Request

   A PCC requests 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 nested 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.





Oki, Le Roux, and Farrel                                        [Page 7]


PCEP Extensions for Inter-Layer TE                         February 2008

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

         <request>::= <RP>
                      <END-POINTS>
                      [<OF>]
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<RRO>]
                      [<IRO>]
                      [<LOAD-BALANCING>]
                      [<INTER-LAYER>]
                      [<SWITCH-LAYER>]
                      [<REQ-ADAP-CAP>]
      where:

      <metric-list>::=<METRIC>[<metric-list>]











Oki, Le Roux, and Farrel                                        [Page 8]


PCEP Extensions for Inter-Layer TE                         February 2008

   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>]
                     [<path-list>]

         <path-list>::=<path>[<path-list>]

         <path>::= <ERO>
                  [<OF>]
                  [<LSPA>]
                  [<BANDWIDTH>]
                  [<metric-list>]
                  [<IRO>]
                  [<INTER-LAYER>]
                  [<SWITCH-LAYER>]
                  [<REQ-ADAP-CAP>]

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









Oki, Le Roux, and Farrel                                        [Page 9]


PCEP Extensions for Inter-Layer TE                         February 2008

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.

   [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, Le Roux, and Farrel                                       [Page 10]


PCEP Extensions for Inter-Layer TE                         February 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.

   [LSP-STITCH] A. Ayyangar et al., "Label Switched Path Stitching
             with Generalized Multiprotocol Label Switching Traffic
             Engineering (GMPLS TE)", draft-ietf-ccamp-lsp-stitching,
             work in progress.

11. Authors' Addresses

   Eiji Oki
   NTT
   3-9-11 Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: oki.eiji@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.

   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.

Oki, Le Roux, and Farrel                                       [Page 11]


PCEP Extensions for Inter-Layer TE                         February 2008

   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, Le Roux, and Farrel                                       [Page 12]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/