[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 draft-ietf-pce-stateful-pce

Network Working Group                                          E. Crabbe
Internet-Draft                                              Google, Inc.
Intended status: Standards Track                               J. Medved
Expires: April 18, 2013                              Cisco Systems, Inc.
                                                                I. Minei
                                                  Juniper Networks, Inc.
                                                                R. Varga
                                               Pantheon Technologies SRO
                                                        October 15, 2012


                Stateful PCE extensions for MPLS-TE LSPs
                draft-crabbe-pce-stateful-pce-mpls-te-00

Abstract

   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to
   provide stateful control.  This document describes the objects and
   TLVs to be used with these PCEP extensions to control Multiprotocol
   Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE
   LSP) via a stateful PCE.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Status of this Memo

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

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

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

   This Internet-Draft will expire on April 18, 2013.



Crabbe, et al.           Expires April 18, 2013                 [Page 1]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  MPLS-TE specific descriptors used in PCEP Messages . . . . . .  3
     4.1.  MPLS-TE specific descriptors for the PCRpt Message . . . .  4
     4.2.  MPLS-TE specific descriptors for the PCUpd Message . . . .  4
     4.3.  MPLS-TE specific encoding for the PCReq Message for
           stateful PCE . . . . . . . . . . . . . . . . . . . . . . .  6
     4.4.  MPLS-TE specific encoding for the PCRep Message for
           stateful PCE . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Object and TLV Formats . . . . . . . . . . . . . . . . . . . .  8
     5.1.  LSP Identifiers TLVs . . . . . . . . . . . . . . . . . . .  8
     5.2.  Tunnel ID TLV  . . . . . . . . . . . . . . . . . . . . . . 11
     5.3.  LSP Update Error Code TLV  . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 12
     6.2.  PCEP-Error Object  . . . . . . . . . . . . . . . . . . . . 12
     6.3.  PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15









Crabbe, et al.           Expires April 18, 2013                 [Page 2]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


1.  Introduction

   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to
   provide stateful control.  This document describes the objects and
   TLVs to be used with these PCEP extensions to control Multiprotocol
   Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE
   LSP) via a stateful PCE.


2.  Terminology

   This document uses the following terms defined in [RFC5440]: PCC,
   PCE, PCEP Peer.

   This document uses the following terms defined in [RFC4090]: MPLS TE
   Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup.

   This document uses the following terms defined in
   [I-D.ietf-pce-stateful-pce] : Passive Stateful PCE, Active Stateful
   PCE, Delegation, Delegation Timeout Interval, LSP State Report, LSP
   Update Request, LSP Priority, LSP State Database, Revocation.

   Within this document, when describing PCE-PCE communications, the
   requesting PCE fills the role of a PCC.  This provides a saving in
   documentation without loss of function.

   The message formats in this document are specified using Routing
   Backus-Naur Format (RBNF) encoding as specified in [RFC5511].


3.  Motivation

   Several use cases for stateful PCE in an MPLS-TE network are included
   in [I-D.ietf-pce-stateful-pce].


4.  MPLS-TE specific descriptors used in PCEP Messages

   As defined in [RFC5440], a PCEP message consists of a common header
   followed by a variable-length body made of a set of objects that can
   be either mandatory or optional.  [I-D.ietf-pce-stateful-pce]
   describes the messages and objects needed in support of stateful PCE.
   The following sections contain MPLS-TE specific descriptors used in
   some of these messages.



Crabbe, et al.           Expires April 18, 2013                 [Page 3]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


4.1.  MPLS-TE specific descriptors for the PCRpt Message

   The format of the PCRpt message is defined in
   [I-D.ietf-pce-stateful-pce] as follows, and included here for easy
   reference:

      <PCRpt Message> ::= <Common Header>
                          <state-report-list>
   Where:

      <state-report-list> ::= <state-report>[<state-report-list>]

      <state-report> ::= <LSP>
                         [<path-list>]

   Where:

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

   For MPLS-TE LSPs, the path descriptor is defined as follows:

      <path>::=<ERO><attribute-list>

   Where:

       <attribute-list> ::= [<LSPA>]
                            [<BANDWIDTH>]
                            [<RRO>]
                            [<metric-list>]

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

   The LSP State Report MAY contain a path descriptor for the primary
   path and one or more path descriptors for backup paths.  A path
   descriptor MUST contain an ERO object as it was specified by a PCE or
   an operator.  A path descriptor MUST contain the RRO object if a
   primary or secondary LSP is set up along the path in the network.  A
   path descriptor MAY contain the LSPA, BANDWIDTH, and METRIC objects.
   The ERO,LSPA, BANDWIDTH, METRIC, and RRO objects are defined
   in[RFC5440].

4.2.  MPLS-TE specific descriptors for the PCUpd Message

   A Path Computation LSP Update Request message (also referred to as
   PCUpd message) is a PCEP message sent by a PCE to a PCC to update
   attributes of an LSP.  A PCUpd message can carry more than one LSP
   Update Request.  The Message-Type field of the PCEP common header for
   the PCUpd message is set to [TBD].



Crabbe, et al.           Expires April 18, 2013                 [Page 4]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


   The format of the PCUpd message is defined in
   [I-D.ietf-pce-stateful-pce] and included here for easy reference:


      <PCUpd Message> ::= <Common Header>
                          <udpate-request-list>
   Where:

      <update-request-list> ::= <update-request>[<update-request-list>]

      <update-request> ::= <LSP>
                           [<path-list>]

   Where:

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

   For MPLS-TE LSPs, the endoding of path descriptor is defined as
   follows:

      <path>::=<ERO><attribute-list>

   Where:
      <path>::=<ERO><attribute-list>

   Where:

      <attribute-list> ::= [<LSPA>]
                           [<BANDWIDTH>]
                           [<metric-list>]

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

   There is one mandatory object that MUST be included within each LSP
   Update Request in the PCUpd message: the LSP object (see
   [I-D.ietf-pce-stateful-pce]).  If the LSP object is missing, the
   receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory
   Object missing) and Error-value=[TBD] (LSP object missing).

   The LSP Update Request MUST contain a path descriptor for the primary
   path, and MAY contain one or more path descriptors for backup paths.
   A path descriptor MUST contain an ERO object.  A path descriptor MAY
   further contain the BANDWIDTH, IRO, and METRIC objects.  The ERO,
   LSPA, BANDWIDTH, METRIC, and IRO objects are defined in [RFC5440].

   Each LSP Update Request results in a separate LSP setup operation at
   a PCC.  An LSP Update Request MUST contain all LSP parameters that a
   PCC wishes to set for the LSP.  A PCC MAY set missing parameters from



Crabbe, et al.           Expires April 18, 2013                 [Page 5]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


   locally configured defaults.  If the LSP specified the Update Request
   is already up, it will be re-signaled.  The PCC will use make-before-
   break whenever possible in the re-signaling operation.

   A PCC MUST respond with an LSP State Report to each LSP Update
   Request to indicate the resulting state of the LSP in the network.  A
   PCC MAY respond with multiple LSP State Reports to report LSP setup
   progress of a single LSP.

   If the rate of PCUpd messages sent to a PCC for the same target LSP
   exceeds the rate at which the PCC can signal LSPs into the network,
   the PCC MAY perform state compression and only re-signal the last
   modification in its queue.

   Note that a PCC MUST process all LSP Update Requests - for example,
   an LSP Update Request is sent when a PCE returns delegation or puts
   an LSP into non-operational state.  The protocol relies on TCP for
   message-level flow control.

   Note also that it's up to the PCE to handle inter-LSP dependencies;
   for example, if ordering of LSP set-ups is required, the PCE has to
   wait for an LSP State Report for a previous LSP before triggering the
   LSP setup of a next LSP.

4.3.  MPLS-TE specific encoding for the PCReq Message for stateful PCE

   A PCC MAY include the LSP object defined in
   [I-D.ietf-pce-stateful-pce] in the PCReq message if the stateful PCE
   capability has been negotiated on a PCEP session between the PCC and
   a PCE.  The definition of the PCReq message (see [RFC5440], Section
   6.4) is then extended as follows:




















Crabbe, et al.           Expires April 18, 2013                 [Page 6]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


      <PCReq Message>::= <Common Header>
                         [<svec-list>]
                         <request-list>

   Where:

         <svec-list>::=<SVEC>[<svec-list>]
         <request-list>::=<request>[<request-list>]

         <request>::= <RP>
                      <END-POINTS>
                      [<LSP>]              <--- New Object
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<RRO>[<BANDWIDTH>]]
                      [<IRO>]
                      [<LOAD-BALANCING>]

   Where:

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

4.4.  MPLS-TE specific encoding for the PCRep Message for stateful PCE

   A PCE MAY include the LSP object defined in
   [I-D.ietf-pce-stateful-pce] in the PCRep message if the stateful PCE
   capability has been negotiated on a PCEP session between the PCC and
   the PCE and the LSP object was included in the corresponding PCReq
   message from the PCC.  The definition of the PCRep message (see
   [RFC5440], Section 6.5) is then extended as follows




















Crabbe, et al.           Expires April 18, 2013                 [Page 7]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


      <PCRep Message> ::= <Common Header>
                          <response-list>

   Where:

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

         <response>::=<RP>
                     [<LSP>]               <--- New Object
                     [<NO-PATH>]
                     [<attribute-list>]
                     [<path-list>]

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

         <path>::= <ERO><attribute-list>

   Where:

       <attribute-list>::=[<LSPA>]
                          [<BANDWIDTH>]
                          [<metric-list>]
                          [<IRO>]

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


5.  Object and TLV Formats

   The PCEP objects defined in this document are compliant with the PCEP
   object format defined in [RFC5440].  The P flag and the I flag of the
   PCEP objects defined in this document MUST always be set to 0 on
   transmission and MUST be ignored on receipt since these flags are
   exclusively related to path computation requests.

5.1.  LSP Identifiers TLVs

   Whenever the value of an LSP identifier changes, a PCC MUST send out
   an LSP State Report, where the LSP Object carries the LSP Identifiers
   TLV that contains the new value.  The LSP Identifiers TLV MUST also
   be included in the LSP object during state synchronization.  There
   are two LSP Identifiers TLVs, one for IPv4 and one for IPv6.

   The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following
   figure:






Crabbe, et al.           Expires April 18, 2013                 [Page 8]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type=[TBD]          |           Length=12           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   IPv4 Tunnel Sender Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             LSP ID            |           Tunnel ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Extended Tunnel ID                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 1: IPV4-LSP-IDENTIFIERS TLV format

   The type of the TLV is [TBD] and it has a fixed length of 12 octets.
   The value contains the following fields:

   IPv4 Tunnel Sender Address:  contains the sender node's IPv4 address,
      as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4
      Sender Template Object.

   LSP ID:  contains the 16-bit 'LSP ID' identifier defined in
      [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template
      Object.

   Tunnel ID:  contains the 16-bit 'Tunnel ID' identifier defined in
      [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
      Tunnel ID remains constant over the life time of a tunnel.
      However, when Global Path Protection or Global Default Restoration
      is used, both the primary and secondary LSPs have their own Tunnel
      IDs.  A PCC will report a change in Tunnel ID when traffic
      switches over from primary LSP to secondary LSP (or vice versa).

   Extended Tunnel ID:  contains the 32-bit 'Extended Tunnel ID'
      identifier defined in [RFC3209], Section 4.6.1.1 for the
      LSP_TUNNEL_IPv4 Session Object.

   The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l following
   figure:












Crabbe, et al.           Expires April 18, 2013                 [Page 9]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type=[TBD]          |           Length=36           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                  IPv6 tunnel sender address                   |
     +                          (16 octets)                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             LSP ID            |           Tunnel ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                       Extended Tunnel ID                      |
     +                          (16 octets)                          +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 2: IPV6-LSP-IDENTIFIERS TLV format

   The type of the TLV is [TBD] and it has a fixed length of 36 octets.
   The value contains the following fields:

   IPv6 Tunnel Sender Address:  contains the sender node's IPv6 address,
      as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6
      Sender Template Object.

   LSP ID:  contains the 16-bit 'LSP ID' identifier defined in
      [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template
      Object.

   Tunnel ID:  contains the 16-bit 'Tunnel ID' identifier defined in
      [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object.
      Tunnel ID remains constant over the life time of a tunnel.
      However, when Global Path Protection or Global Default Restoration
      is used, both the primary and secondary LSPs have their own Tunnel
      IDs.  A PCC will report a change in Tunnel ID when traffic
      switches over from primary LSP to secondary LSP (or vice versa).







Crabbe, et al.           Expires April 18, 2013                [Page 10]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


   Extended Tunnel ID:  contains the 128-bit 'Extended Tunnel ID'
      identifier defined in [RFC3209], Section 4.6.1.2 for the
      LSP_TUNNEL_IPv6 Session Object.

5.2.  Tunnel ID TLV

   The Tunnel ID TLV MAY be included in the LSPA object.

   The format of the TUNNEL TLV is shown in the following figure:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type=[TBD]          |           Length=4            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Reserved          |           Tunnel ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 3: Tunnel-ID TLV format

   The type of the TLV is [TBD] and it has a fixed length of 4 octets.
   The value contains a single field:

   Tunnel ID:  contains the 16-bit 'Tunnel ID' identifier defined in
      [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
      Tunnel ID remains constant over the life time of a tunnel.
      However, when Global Path Protection or Global Default Restoration
      is used, both the primary and secondary LSPs have their own Tunnel
      IDs.

5.3.  LSP Update Error Code TLV

   If an LSP Update Request failed, an LSP State Report MUST be sent to
   all connected stateful PCEs.  LSP State Report MUST contain the LSP
   Update Error Code TLV, indicating the cause of the failure.

   The format of the LSP-UPDATE-ERROR-CODE TLV is shown in the following
   figure:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Type=[TBD]          |            Length=4           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Error Code                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Crabbe, et al.           Expires April 18, 2013                [Page 11]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


                Figure 4: LSP-UPDATE-ERROR-CODE TLV format

   The type of the TLV is [TBD] and it has a fixed length of 4 octets.
   The value contains the error code that indicates the cause of the LSP
   setup failure.  Error codes will be defined in a later revision of
   this document.


6.  IANA Considerations

   This document requests IANA actions to allocate code points for the
   protocol elements defined in this document.  Values shown here are
   suggested for use by IANA.

6.1.  PCEP Objects

   This document defines the following new PCEP Object-classes and
   Object-values:

   Object-Class Value   Name                               Reference

            32          LSP                                This document
                        Object-Type
                            1

6.2.  PCEP-Error Object

   This document defines new Error-Type and Error-Value for the
   following new error conditions:

    Error-Type  Meaning
       6        Mandatory Object missing
                 Error-value=9:  ERO Object missing for a path in an LSP
                                 Update Request where TE-LSP setup is
                                 requested
                 Error-value=10: BANDWIDTH Object missing for a path in
                                 an LSP Update Request where TE-LSP
                                 setup is requested
                 Error-value=11: LSPA Object missing for a path in an
                                 LSP Update Request where TE-LSP setup
                                 is requested

6.3.  PCEP TLV Type Indicators

   This document defines the following new PCEP TLVs:






Crabbe, et al.           Expires April 18, 2013                [Page 12]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


       Value     Meaning                     Reference
         18       IPV4-LSP-IDENTIFIERS       This document
         19       IPV6-LSP-IDENTIFIERS       This document
         20       LSP-UPDATE-ERROR-CODE      This document
         24       TUNNEL-ID                  This document


7.  Security Considerations

   The security considerations listed in [I-D.ietf-pce-stateful-pce]
   apply to this document as well.


8.  Acknowledgements

   We would like to thank Adrian Farrel, Cyril Margaria and Ramon
   Casellas for their contributions to this document.

   We would like to thank Shane Amante,Julien Meuric, Kohei Shiomoto,
   Paul Schultz and Raveendra Torvi for their comments and suggestions.
   Thanks also to Dhruv Dhoddy, Oscar Gonzales de Dios, Tomas Janciga,
   Stefan Kobza and Kexin Tang for helpful discussions.


9.  References

9.1.  Normative References

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
              Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              May 2005.



Crabbe, et al.           Expires April 18, 2013                [Page 13]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


   [RFC5088]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "OSPF Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5088, January 2008.

   [RFC5089]  Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
              "IS-IS Protocol Extensions for Path Computation Element
              (PCE) Discovery", RFC 5089, January 2008.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440,
              March 2009.

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, April 2009.

9.2.  Informative References

   [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
              McManus, "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, September 1999.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3346]  Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D.,
              Christian, B., and W. Lai, "Applicability Statement for
              Traffic Engineering with MPLS", RFC 3346, August 2002.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              September 2003.

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

   [RFC4657]  Ash, J. and J. Le Roux, "Path Computation Element (PCE)
              Communication Protocol Generic Requirements", RFC 4657,
              September 2006.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, October 2008.

   [RFC5394]  Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,



Crabbe, et al.           Expires April 18, 2013                [Page 14]


Internet-Draft  Stateful PCE extensions for MPLS-TE LSPs    October 2012


              "Policy-Enabled Path Computation Framework", RFC 5394,
              December 2008.

   [RFC5557]  Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
              Computation Element Communication Protocol (PCEP)
              Requirements and Protocol Extensions in Support of Global
              Concurrent Optimization", RFC 5557, July 2009.


Authors' Addresses

   Edward Crabbe
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   Email: edc@google.com


   Jan Medved
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose, CA  95134
   US

   Email: jmedved@cisco.com


   Ina Minei
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: ina@juniper.net


   Robert Varga
   Pantheon Technologies SRO
   Mlynske Nivy 56
   Bratislava  821 05
   Slovakia

   Email: robert.varga@pantheon.sk






Crabbe, et al.           Expires April 18, 2013                [Page 15]


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