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

Versions: 00 01 02

Network Working Group                                         Kexin Tang
Internet-Draft                                              Xuerong Wang
Intended status: Informational                                Xuping Cao
Expires: May 3, 2012                                     ZTE Corporation
                                                            Oct 31, 2011


                              Stateful PCE
                   draft-tang-pce-stateful-pce-02.txt

Abstract

   A PCE can be either stateful or stateless.  The information carried
   in a stateful PCE is more detailed than that of a stateless PCE.
   This draft focus on stateful PCE, describes the problems without
   stateful PCE, and gives the IGP and PCEP extensions to realize
   stateful PCE.

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 May 3, 2012.

Copyright Notice

   Copyright (c) 2011 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



Kexin Tang, et al.         Expires May 3, 2012                  [Page 1]


Internet-Draft                Stateful PCE                      Oct 2011


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Conventions used in this document . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Problems  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  PCED Extensions . . . . . . . . . . . . . . . . . . . . . . 5
     4.2.  LSP State Synchronization . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8



































Kexin Tang, et al.         Expires May 3, 2012                  [Page 2]


Internet-Draft                Stateful PCE                      Oct 2011


1.  Introduction

   As defined in section 6.8 of [RFC4655], a PCE can be either stateful
   or stateless.  For stateful PCE, there is a strict synchronization
   between the PCEs not only the network states (in term of topology and
   resource information), but also the set of computed paths and
   reserved resources in use in the network.  Since stateful PCE has
   more network information, it can be used to do some complicated work.

   However, the existing PCE discovery protocol ([RFC5088], [RFC5089])
   and PCEP ([RFC5440]) do not support stateful PCE.  And there is no
   effective synchronization mechanism defined to realize stateful PCE
   yet.  For these sufficient reasons, this document focus on stateful
   PCE, describes the applicability of stateful PCE and gives the IGP
   and PCEP extensions to support stateful PCE.

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


2.  Terminology

   o  PCC: Path Computation Client.  A client application requesting a
      path computation to be performed by the Path Computation Element.

   o  PCE: Path Computation Element.  An entity that is capable of
      computing a network path or route based on a network graph, and of
      applying computational constraints during the computation.

   o  PCED: PCE Discovery.

   o  PCEP: Path Computation Element communication Protocol.

   o  TED: Traffic Engineering Database, which contains the topology and
      resource information of the domain.  The TED may be fed by
      Interior Gateway Protocol (IGP) extensions or potentially by other
      means.


3.  Problems

   This section lists the typical problems without stateful PCE.  As
   described in [RFC4655], stateful PCE uses information not only from
   the TED, but also information about existing paths (for example, TE
   LSPs) in the network when processing new requests, so the information



Kexin Tang, et al.         Expires May 3, 2012                  [Page 3]


Internet-Draft                Stateful PCE                      Oct 2011


   carried in stateful PCE are more detailed than that of stateless PCE.

   Without stateful PCE, there would not be a strict synchronization
   between PCE and LSP state.  Consequently,the PCE may not know the
   existing path in the network in time,and suppose the network resource
   taken by the existing path is unoccupied, so it would consider these
   resource in the other path computations.  Resource conflict occurs
   under this condition.

   A PCE may received several PCReq messages, this may occurs when a PCE
   is required to compute a large number of path for several LSPs,for
   example when fiber cutting happened or in a sudden accident,which may
   result in a large number of links down simultaneity,and need to be
   recovery in a short time.

   Figure 1 shows a demonstration topology for the subsequent context.

                           +-----+               +-----+
                           |  A  |---------------|  B  |
                           +-----+               +-----+
                                   \           /
                                    \         /
                                      +-----+
                                      |  C  |
                                      +-----+


                     Figure 1: demonstration topology

   In Figure1,we make the assumptions as follows:the link capacity
   between all these three nodes is 100M,and the node that hosts the PCE
   function received a PCReq massage,which required it to compute paths
   for two LSP respectively:LSP1 and LSP2.  LSP1 and LSP2 share the same
   original and terminal node pair,that is from node A to node B,and
   require the same link bandwidth:80M.

   For LSP 1,to get a shortest path,the PCE may return a path:A--B,while
   the computation result is not synchronized in its TED in time,the PCE
   assume the unreserved bandwidth of the link between A and B is still
   100M.

   Then for LSP2,which require 80M link capacity either,the PCE may
   still consider the shortest path,that is A--B as before,and it seems
   that in the TED currently,this shortest path has enough capacity for
   LSP2,so the PCE returns the optimal path A--B for LSP2.

   Once the LSP setup procedure by signaling for LSP1 and LSP2 is
   running,the setup procedure for the first LSP would successful, while



Kexin Tang, et al.         Expires May 3, 2012                  [Page 4]


Internet-Draft                Stateful PCE                      Oct 2011


   the latter one would encounter resource conflict:there would not be
   enough link capacity for the LSP to be setup,and it would return a
   signaling failure notification message.

   As for Inter-area or Inter-AS path computation for a LSP, it is often
   involved in multiple PCEs cooperation to compute an end-to-end path,
   for example, BRPC ([RFC5441]) and H-PCE ([H-PCE-FWK]).  Resource
   conflict would even worse in this situation because it takes extra
   time for communication between the cooperative PCEs.


4.  Protocol Extensions

4.1.  PCED Extensions

   [RFC5088] defines extensions to OSPFv2 ([RFC2328]) and OSPFv3
   ([RFC5340]) to allow a PCE in an OSPF routing domain to advertise
   some information useful to a PCC for PCE selection.  It defines a new
   TLV (named the PCE Discovery TLV (PCED TLV)) to be carried within the
   OSPF Router Information LSA ([RFC4970]).  The type 5 sub-TLV of PCED
   TLV, which named CE-CAP-FLAGS sub-TLV, used to indicate the
   capabilities of a PCE.  It contains eight capabilities currently, but
   not includes the stateful capability of a PCE.  So the PCE in an OSPF
   routing domain cannot advertise its state capability information to a
   PCC,which would help the PCC to make advanced and informed
   choices in PCE selection.

   To discover stateful PCE, a PCC SHOULD know whether PCE is stateful.
   Therefore, the PCE discovery message SHOULD indicate whether the PCE
   advertising this message is a stateful PCE.  Since PCE-CAP-FLAGS Sub-
   TLV ([RFC5088] for OSPF, [RFC5089] for IS-IS) contains PCE Capability
   Flags, this document defines a new flag, Stateful PCE Capability
   Flag, as follows (need to be assigned by IANA):

     Bit        Capabilities

     TBD        Stateful PCE

4.2.  LSP State Synchronization

   With respect to the definition of stateful PCE defined in [RFC4655],
   a stateful PCE utilizes information from the TED as well as
   information about existing paths (for example, TE LSPs) in the
   network when processing new path computation requests.  Therefore, a
   stateful PCE SHOULD know the status (created or deleted) of a LSP.
   For this reason, there SHOULD be a timely synchronization of LSP
   state between PCC and PCE, including the path computation result, and
   the LSP setup or deletion result.  For this purpose, this section



Kexin Tang, et al.         Expires May 3, 2012                  [Page 5]


Internet-Draft                Stateful PCE                      Oct 2011


   makes an extension to the PCNtf message defined in [RFC5440], defines
   a new Notification-type as follows (need to be assigned by IANA):

   o  Notification-type=TBD: LSP Status

      *  Notification-value=1: end-to-end path computation success(This
         value is available for distributed path computation only).
         When a optimal end-to-end path is computed successfully, the
         head-end PCE SHOULD send a notification message with
         Notification-type=TBD and Notification-value=1 to the other
         PCEs collaboratively in the PCE chain which computed the other
         path segments successfully.

      *  Notification-value=2: end-to-end path computation failure(This
         value is available for distributed path computation only).  If
         an end-to-end path computation is failed,the head-end PCE
         SHOULD send a notification message with Notification-type=TBD
         and Notification-value=2 to the other PCEs collaboratively in
         the PCE chain which computed the other path segments
         successfully.

      *  Notification-value=3: LSP setup success.  When a LSP is created
         successfully by signaling, the PCC SHOULD send a notification
         message with Notification-type=TBD and Notification-value=3 to
         all the PCEs.

      *  Notification-value=4: LSP setup failure.  When a LSP is failed
         to setup by signaling, the PCC SHOULD send a notification
         message with Notification-type=TBD and Notification-value=4 to
         all the PCEs.

      *  Notification-value=5: LSP delete success.  When a LSP is delete
         in the network successfully, the PCC SHOULD send a notification
         message with Notification-type= TBD and Notification-value=5 to
         all the PCEs.

      *  Notification-value=6: LSP delete failure .  When a LSP path is
         failed to delete, the PCC SHOULD send a notification message
         with Notification-type= TBD and Notification-value=6 to all the
         PCEs.


   This draft extended the PCNtf message, added the Path object which
   defined for PCRep message [RFC5440] to the PCNtf message ,to identify
   the ERO and the attribute of a LSP.

   The format of the extended PCNtf message is as follows:




Kexin Tang, et al.         Expires May 3, 2012                  [Page 6]


Internet-Draft                Stateful PCE                      Oct 2011


      <PCNtf Message>::=<Common Header>
                        <notify-list>

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

      <notify>::= [<request-id-list>]
                   <notification-list>

      <request-id-list>::=<RP><PATH> [<request-id-list>]

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


   where:

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

       <notification-list>::=<NOTIFICATION>[<notification-list>]



   With the newly added Path object which carries the ERO object and the
   attribute of a LSP,a PCE can identifies the status of which LSP
   changes,and the information of the LSP, so as to identifies the
   resource that taken by the LSP.


5.  Security Considerations

   The extensions of this draft are based on PCEP and OSPF, only some
   optional protocol elements are added which will not change the
   security of existing network.


6.  IANA Consideration

   The extensions of this draft is baed on PCEP and OSPF, only some
   optional protocol elements are added which will not change the
   security of existing network.


7.  Normative References

   [H-PCE-FWK]
              Daniel King, Adrian Farrel, Quintin Zhao, and Fatai Zhang,



Kexin Tang, et al.         Expires May 3, 2012                  [Page 7]


Internet-Draft                Stateful PCE                      Oct 2011


              "The Application of the Path Computation Element
              Architecture to the Determination of a Sequence of Domains
              in MPLS and GMPLS", draft-ietf-pce-hierarchy-fwk-00.txt .

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

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

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

   [RFC4970]  Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
              Shaffer, "Extensions to OSPF for Advertising Optional
              Router Capabilities", RFC 4970, July 2007.

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

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.

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

   [RFC5441]  Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
              Backward-Recursive PCE-Based Computation (BRPC) Procedure
              to Compute Shortest Constrained Inter-Domain Traffic
              Engineering Label Switched Paths", RFC 5441, April 2009.


Authors' Addresses

   Kexin Tang
   ZTE Corporation
   No.50 Software Avenue, Yuhuatai District
   Nanjing, Jiangsu  210012
   P.R.China

   Phone: +86-025-88014225
   Email: tang.kexin@zte.com.cn




Kexin Tang, et al.         Expires May 3, 2012                  [Page 8]


Internet-Draft                Stateful PCE                      Oct 2011


   Xuerong Wang
   ZTE Corporation
   R&D Building 3, ZTE Industrial Zone, Liuxian Road,Nanshan District
   Shenzhen  518055
   P.R.China

   Phone: +86-755-26773926
   Email: wang.xuerong@zte.com.cn


   Xuping Cao
   ZTE Corporation
   21F, ZTE Plaza, No.19 East Huayuan Road,Haidian District
   Beijing  100191
   P.R.China

   Email: cao.xuping@zte.com.cn


































Kexin Tang, et al.         Expires May 3, 2012                  [Page 9]


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