Internet DRAFT - draft-lee-pce-app-oriented-arch

draft-lee-pce-app-oriented-arch



PCE Working Group                                            Young Lee
Internet Draft                                               Xian Zhang
Intended status: Informational                            Haomian Zheng
                                                                  Huawei
                                                           Guoying Zhang
                                                                    CATR



Expires: August 14, 2014                              February 14, 2014


    Application-oriented Stateful PCE Architecture and Use-cases for
                           Transport Networks


                  draft-lee-pce-app-oriented-arch-01.txt


Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 14, 2014.



Abstract






Lee et al                Expires August 2014                   [Page 1]

draft-lee-pce-app-oriented-arch-01                        February 2014


   This draft presents an application-oriented stateful PCE
   architecture for transport networks. Under this architecture,
   several use cases are described.



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



Table of Contents

   1. Introduction...................................................2
   2. Terminology....................................................3
   3. Architecture and Key Features..................................3
   4. Use-cases......................................................5
      4.1.  Dynamic Data Center Network Interconnection..............6
      4.2.  Packet-Optical Integration (POI).........................6
      4.3.  Virtual Network Service (VNS)............................7
      4.4.  Time-based Scheduling....................................7
      4.5.  Multi-vendor Interoperation..............................8
   5. References.....................................................9
      5.1. Informative References....................................9
   6. Authors' Addresses ............................................10
   7. Acknowledgment................................................11



1. Introduction

   With the emerging applications requiring large bandwidth and dynamic
   provisioning, such as Data Center Interconnection(DCI), cloud
   bursting and so on, the traditional transport network architecture
   is limited as it only provides "dumb pipe" services. These services
   lack the flexibility for operation and management. In order to
   support the demands, including large bandwidth, low service latency
   as well as dynamic and flexible resource allocation, transport
   networks may need to be enhanced architecturally such that it could
   be aware of application requirements in a dynamic fashion. The Path
   Computation Elements (PCE) architecture and the corresponding
   protocol extensions provide a mechanism that enables path
   computation for transport network. As specified in [RFC4655], a PCE


Lee et al                Expires August 2014                   [Page 2]

draft-lee-pce-app-oriented-arch-01                        February 2014


   supports the request for path computation issued by a Path
   Computation Client (PCC). When the PCC is external to the PCE, a
   communication protocol, i.e., PCE Protocol (PCEP), is required to
   support the path computation request/reply process. Furthermore,
   extensions to PCEP are proposed in [PCE-S] , [PCE-I], and [PCE-S-
   GMPLS] to enable stateful control over networks including transport
   networks.

   This draft provides an application-oriented stateful PCE
   architecture for transport networks. In particular, this
   architecture introduces transport network controller (TNC) component
   in which transport PCE plays a central role. Given the high demands
   from applications, an interface between the transport network
   controller and the application client controller is also introduced
   to enable the communication function between these entities.  The
   application client controller is a special type of PCC with respect
   to PCE capability within the transport network controller. This
   interface and its communication mechanism between the application
   client controller and the transport network controller enables
   operation of the transport network with more flexibility.
   Specifically, in a larger-scale transport network with multiple
   layers or multiple domains, the communication mechanism between
   different PCEs and the application client controllers is very
   important to satisfy the request from the application stratum.
   Current PCEP can provide communication between PCE and PCCs, and
   further extensions to PCEP may be desirable to cooperate with new
   types of PCCs such as application client controllers.



2. Terminology

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



3. Architecture and Key Features

   In this draft, a PCE-centric architecture which supports
   application-oriented transport network is defined. The architecture
   is illustrated in Figure 1. The functions of each architectural
   component are described. And then interfaces between the stateful
   PCE and the other functional blocks in the transport network are
   defined.



Lee et al                Expires August 2014                   [Page 3]

draft-lee-pce-app-oriented-arch-01                        February 2014



                                     ---------------
                                    |       Client  |
                             -------------- Control |
                            |      Client  |--------
                    -------------- Control |   /|\
                   |    Client    |-------      |
                   |    Control   |   /|\       |
                    --------------     |        |
                           /|\         |        |  Client-VNC Interface
                            |          |        |   (CVI)
                           \|/        \|/      \|/
                    ----------------------------------
               /   |  Virtual Network Control (VNC)   |
    Transport  |    ----------------------------------
    Network    |                      /|\
    Controller |                       |     VNC-PCE Interface (VPI)
      (TNC)    |                      \|/
               |    ----------------------------------
               \   |          Transport PCE           |
                    ----------------------------------
                                     /|\
                                      |     PCEP
                                     \|/

                        Physical Network Infrastructure


   Figure 1: Application-oriented PCE Architecture for Transport
   Network


   Transport Network Controller (TNC) in Figure 1 is the core of the
   application-oriented PCE architecture for transport network. It is
   built around the Transport PCE and provides additional functions
   that facilitate multi-layer control, virtual network service control
   and other functionalities such as topology abstraction via the
   Virtual Network Control (VNC) block. The VNC interfaces can be
   different types of client controllers, such as packet network
   controllers, data center provider controllers, enterprise network
   controllers, virtual service provider controllers, etc. The VNC
   provides network control function virtualization to the PCE and to
   the clients via the VNC-PCE Interface (VPI) and the Client-VNC


Lee et al                Expires August 2014                   [Page 4]

draft-lee-pce-app-oriented-arch-01                        February 2014


   Interface (CVI), respectively. The VNC allows the clients (via their
   client controllers) to program their client-defined virtual network
   services (VNS) over the CVI. The VNC also provides abstract network
   topology for each client based on the network resources allocated to
   the client. In order to facilitate this capability, the VNC needs to
   communicate with the PCE via the VPI interface. It is worth noting
   that the CVI can be an internal interface with respect to the TNC,
   or be an external interface from the perspective of transport PCE,
   according to the application. In this draft, it is assumed that VPI
   is an external interface from the PCE. The VNC is considered as a
   PCC to the PCE.

   The VNC provides control plane function virtualization over
   programmable interfaces such as virtual network path computation and
   optimization, topology abstraction hiding details of physical
   topology while supporting service-specific objectives the clients
   demand, maintaining virtual network service instances and the
   states, policy enforcement for virtual network services. See [NCFV]
   for details of control function virtualization concept. With this
   evolutionary architecture built on top of transport PCE, a number of
   challenging use-cases can be supported. Transport PCE is a stateful
   PCE and supports all the generic stateful PCE functions as described
   in [PCE-S] and [PCE-S-GMPLS].

   The CVI is an external interface with respect to the transport
   network controller (TNC). Client controller is an external client.
   Figure 1 shows that there are multiple client controls which are
   independent to each other and that each client supports various
   business applications. There could be multiple recursive layered
   client-server relationships in this architecture. For example,
   various applications are clients to client control, client control
   itself is also a client to virtual network control; likewise,
   virtual network control is also a client to physical network
   control. In each relationship, client can be considered as PCC that
   requesting service from server which can be considered as PCE. It is
   worth noting that one client or PCC can be connected with multiple
   servers and vice versa. Such layered relationship is important in
   protocol definition work on CVI and VPI interfaces as this allows
   third-party software developers to program client control and
   virtual network control functions in such a way to create, modify
   and delete virtual network services.

4. Use-cases

   This section provides a number of use-cases to which the
   architecture discussed in Section 3 is applied.



Lee et al                Expires August 2014                   [Page 5]

draft-lee-pce-app-oriented-arch-01                        February 2014


4.1. Dynamic Data Center Network Interconnection

   In the context of multiple data center networks where there is a
   need to move large data dynamically from one location to other
   location(s), data center network controller is a type of client
   controller that coordinates with the virtual network controller
   (VNC). This coordination across data center client controller and
   the VNC allows multiple instances of inter data center connections
   need for different applications. In this case there are multiple
   client-server pairs. Each of the data center can be a client that
   request resources from the data center network controller, which is
   considered as a server for service provisioning. The data center
   network controller is then a client that requesting services from
   transport server. The two client pairs are slightly different in
   this use case. The first pair is communicating on virtual resources,
   while the second pair focuses on allocating physical resources. From
   an extended PCE architecture point of view, client-server can be
   regarded as PCC-PCE.

   For each virtual resource request from client or application, the
   VNC keeps the instance and creates an abstracted network topology
   based on the network resources allocated to a particular request.
   The data center client controller has the view of this abstracted
   network topology and is given a full control of how to use the
   allocated virtual resources.

   The topology abstraction created by the VNC for the client is based
   on the transport PCE's physical network resource information and is
   needed to be filtered via the VNC's filtering mechanism based on
   contract, policy and security. In this way, physical resources are
   abstracted into virtual resources.

   The VNC interlays client control's request for inter data center
   connection and converts into a PC request to the PCE. Then a PCE
   instantiates a network path via its provisioning mechanism described
   in [PCE-I].

4.2. Packet-Optical Integration (POI)

   Client controller can also be a router network controller that needs
   transport network interconnections. The router network controller
   can request different connection services from the transport network
   based on different QoS needs.

   Note that this POI use-case is different from multi-layer PCE work
   [RFC5623] in that it allows more flexible interactions and more



Lee et al                Expires August 2014                   [Page 6]

draft-lee-pce-app-oriented-arch-01                        February 2014


   granular level of abstracted network topologies than tunnel-based
   virtual network topology.

4.3. Virtual Network Service (VNS)

   Virtual Network Service is instantiated by the client control via
   the CVI. As client control directly interfaces the application
   stratum, it understands multiple application requirements and their
   service needs. It is assumed that client control and VNC have the
   common knowledge on the end-point interfaces based on their business
   negotiation prior to service instantiation. End-point interfaces
   refer to client-network physical interfaces that connect client
   premise equipment to network provider equipment. The different level
   of topology abstractions can be provided by the VNC topology
   abstraction engine based on physical topology base maintained by the
   PNC.

   The level of topology abstraction is expressed in terms of the
   number of virtual network elements (VNEs) and virtual links (VLs).
   As different client has different control/application needs,
   abstracted topologies for a certain client can show much less degree
   of abstraction. The level of topology abstraction is determined by
   the policy (e.g., the granularity level) placed for the client
   and/or the path computation results by the PNC's PCE. The finer
   granularity the abstraction topology is, the more control is given
   to the client control. For instance, if the client is a third-party
   virtual service broker/provider, then it would desire much more
   sophisticated control of virtual network resources to support
   differing application needs. On the other hand, if the client were
   only to support simple tunnel services to its application, then
   abstracted topology for such client is a simple abstracted topology
   with a set of end-point tunnels.

   Synchronization is an important issue in layered path computation
   procedure. As we assumed, the transport PCE is a stateful PCE with
   TED and LSPD. Meanwhile the VNC also needs to maintain databases
   that contain virtual topology information, including a virtual TED
   and virtual LSPD. The information in these databases is obtained
   from the transport PCE databases, with proper mapping scheme. The
   mapping mechanism is out of scope for this draft.



4.4. Time-based Scheduling

   Transport services with time constraints are another highly-demanded
   task in the network. In this scenario, a client controller can


Lee et al                Expires August 2014                   [Page 7]

draft-lee-pce-app-oriented-arch-01                        February 2014


   request to reserve some bandwidth for future use. This 'time-based'
   service needs to be considered together with the traffic Engineering
   Database (TED) and Label Switched Path Database (LSPD). PCE will
   compute the scheduled network resource for this 'time-based' service,
   and reserve such resources for future use.

In this scenario, the LSPD contains two categories of LSP information,
current LSP in use and scheduled LSP. These two groups of LSP can be
included in a single LSPD or two separate ones, with internal interface
to PCE. PCEP should also be extended to include the scheduled
information for service requests, such as proposed in [Time-based].
With these extensions, the PCC (for example, application stratum) can
generate the path computation request.

4.5. Multi-vendor Interoperation

PCE orchestration is essential in multi-vendor scenario. VNC can be
connected with PCEs from more than one vendor to orchestrate the path
computation. For simplicity, in this case we assume a 'two domains with
two vendors', i.e., each vendor has a PCE within their respective
domain, as shown in Fig. 2.

   +--------------+              +--------------+
   |    Client    |              |    Client    |
   | Controller A |              | Controller B |
   +--------------+              +--------------+
          /|\                           /|\
           |                             |
          \|/                           \|/
   +--------------------------------------------+
   |        Virtual Network Controller          |
   |         +---------------------+            |
   |         |     Orchestrator    |            |
   |         +---------------------+            |
   +--------------------------------------------+
          /|\                           /|\
           |                             |
          \|/                           \|/
     +-----------+                 +-----------+
     | Transport |                 | Transport |
     |   PCE A   |                 |   PCE B   |
     +-----------+                 +-----------+
          /|\                           /|\
           |                             |


Lee et al                Expires August 2014                   [Page 8]

draft-lee-pce-app-oriented-arch-01                        February 2014


          \|/                           \|/
      ///------\\\                  //-------\\
   |||   Vendor   |||            |||   Vendor  |||
    ||     A      ||              ||     B     ||
      \\\------///                  \\-------//
                 Fig. 2 Architecture for Interoperation



The original path computation request comes from one of the client
controllers, with multiple vendors involved. This request is sent to
VNC, which will then categorize the request into a 'multi-vendor' class.
Before allocating virtual resources, the VNC will determine the domain
path and decompose the path computation request from client controller,
and then send PCReq to two transport PCEs respectively. The path will
be replied to VNC after computation, and corresponding databases are
updated in VNC after establishing the path.



It is worth noting that the architecture in multi-vendor use case is
quite similar to the Hierarchical PCE [H-PCE] but slightly different.
The PCEs belong to different vendors and the VNC may play as a parent
PCE by a service provider, for example, operators.



5. References

5.1. Informative References

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

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

   [RFC5623] Oki, E., Takeda, T., et al, "Framework for PCE-Based
             Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623,
             September 2009.






Lee et al                Expires August 2014                   [Page 9]

draft-lee-pce-app-oriented-arch-01                        February 2014


   [PCE-S]   Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
             Extensions for Stateful PCE", draft-ietf-pce-stateful-pce,
             work in progress. [PCE-I]   Crabbe, E., Minei, I.,
             Sivabalan, S., and Varga, R., "PCEP Extensions for PCE-
             initiated LSP Setup in a Stateful PCE Model", draft-
             crabbe-pce-pce-initiated-lsp, work in progress.

   [PCE-S-GMPLS] Zhang, X., Lee, Y., Casellas, R., Gonzalez de Dios,
             O., "Path Computation Element (PCE) Protocol Extensions
             for Stateful PCE Usage in GMPLS-controlled Networks",
             draft-zhang-pce-pcep-stateful-pce-gmpls-03.txt, work in
             progress.

   [NCFV]    Lee, Y. Bernstein, G., So, N., Fang L., and Ceccarelli, D.
             "Network Control Function Virtualization for Transport
             SDN",  draft-lee-network-control-function-virtualization,
             work in progress.

   [H-PCE]   Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas R.,
             King D., Extensions to Path Computation Element
             Communication Protocol (PCEP) for Hierarchical Path
             Computation Elements (PCE), draft-zhang-pce-hierarchy-
             extensions-04, work in progress.

   [Time-based] Zhang, X., Lee, Y., Casellas, R., Ganzalez, O.,
             "Stateful Path Computation Element (PCE) for Time-based
             Scheduling", draft-zhang-pce-stateful-time-based-
             scheduling-00, work in progress.



6. Authors' Addresses

   Young Lee
   Huawei Technologies
   5340 Legacy Dr.
   Plano, TX 75023, USA
   Phone: (469)277-5838
   Email: leeyoung@huawei.com

   Xian Zhang
   Huawei Technologies
   Email: zhang.xian@huawei.com




Lee et al                Expires August 2014                  [Page 10]

draft-lee-pce-app-oriented-arch-01                        February 2014


   Haomian Zheng
   Huawei Technologies
   Email: Zhenghaomian@huawei.com


   Guoying Zhang
   China Academy of Telecommunication Research of MII
   11 Yue Tan Nan Jie Beijing, P.R.China
   Phone: +86-10-68094272
   Email: zhangguoying@mail.ritt.com.cn

7. Acknowledgment



Intellectual Property

   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line
   IPR   repository at http://www.ietf.org/ipr

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions
   of   these Legal Provisions that are published by third parties,


Lee et al                Expires August 2014                  [Page 11]

draft-lee-pce-app-oriented-arch-01                        February 2014


   including   those that are translated into other languages, should
   not be   considered to be definitive versions of these Legal
   Provisions.

   For the avoidance of doubt, each Contributor to the IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect
   and   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.


Disclaimer of Validity

   All IETF Documents and the information contained therein are
   provided   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
   HE/SHE   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
   SOCIETY, THE   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIM ALL   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   LIMITED TO ANY   WARRANTY THAT THE USE OF THE INFORMATION THEREIN
   WILL NOT INFRINGE   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS   FOR A PARTICULAR PURPOSE.



Copyright Notice

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








Lee et al                Expires August 2014                  [Page 12]