| PCE Working Group | D. Dhody |
| Internet-Draft | Y. Lee |
| Intended status: Informational | Huawei Technologies |
| Expires: July 25, 2015 | LM. Contreras |
| O. Gonzalez de Dios | |
| Telefonica I+D | |
| N. Ciulli | |
| Nextworks | |
| January 21, 2015 |
Cross Stratum Optimization enabled Path Computation
draft-dhody-pce-cso-enabled-path-computation-07
Applications like cloud computing, video gaming, HD Video streaming, Live Concerts, Remote Medical Surgery, etc are offered by Data Centers. These data centers are geographically distributed and connected via a network. Many decisions are made in the Application space without any concern of the underlying network. Cross stratum application/network optimization focus on the challenges and opportunities presented by data center based applications and carriers networks together [CSO-DATACNTR].
Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. [RFC4655] explains the architecture for a Path Computation Element (PCE)-based model to address this problem space.
This document explains the architecture for CSO enabled Path Computation.
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 July 25, 2015.
Copyright (c) 2015 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.
Many application services offered by Data Center to end-users make significant use of the underlying networks resources in the form of bandwidth consumption used to carry the actual traffic between data centers and/or among data center and end-users. There is a need for cross optimization for both network and application resources. [CSO-PROBLEM] describes the problem space for cross stratum optimization.
[NS-QUERY] describes the general problem of network stratum (NS) query in Data Center environments. Network Stratum (NS) query is an ability to query the network from application controller in Data Centers so that decision would be jointly performed based on both the application needs and the network status. Figure 1 shows typical data center architecture.
---------------
---------- | DC 1 |
| End-user |. . . . .>| o o o |
| | | \|/ |
---------- | O |
| ----- --|------
| |
| |
| -----------------|-----------
| / | \
| / ..........O PE1 \ --------------
| | . | | o o o DC 2 |
| | PE4 . PE2 | | \|/ |
----|---O.........................O---|---|---O |
| . | | |
| . PE3 | --------------
\ ..........O Carrier /
\ | Network /
---------------|-------------
|
--------|------
| O |
| /|\ |
| o o o |
| DC 3 |
---------------
Figure 1: Data Center Architecture
Figure 2 shows the context of NS Query within the overarching data center architecture shown in Figure 1.
--------------------------------------------
| Application Overlay |
| (Data Centers) |
| |
---------- | -------------- -------------- |
| End-User | | | Application |. . . .| Application | |
| |. . . >| | Control | | Processes | |
---------- | | Gateway (ACG)| -------------- |
| | | -------------- |
| ------------- . . . . | Application | |
| /\ | Related Data | |
| || -------------- |
----------||--------------------------------
||
|| Network Stratum Query (First
|| Stage)
||
----------||--------------------------------
| \/ Network Underlay |
| |
| -------------- ---------------- |
| | Network |. . . | Network | |
| | Control | | Processes | |
| | Gateway (NCG)| ----------------
| | | ---------------- |
| ------------- | Network | |
| |------------->| Related Data | |
| (Second Stage) ---------------- |
-------------------------------------------
Figure 2: NS Query Architecture
NS Query is a two-stage query that consists of two stages:
As an example for vertical query (1st stage), [ALTO-APPNET] describes Application Layer Traffic Optimization (ALTO) information model and protocol extensions to support application and network resource information exchange for high bandwidth applications in partially controlled and controlled environments as part of the infrastructure to application information exposure (i2aex) initiative.
For the horizontal query (2nd stage), PCE can be an ideal choice, [CSO-PCE-REQT] describes the general requirement PCE should support in order to accommodate CSO capability. This document is intended to fulfill the general PCE requirements discussed in the aforementioned reference.
This document describes how PCE Architecture as described in [RFC4655] can help in the second stage of NS query.
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].
The following terminology is used in this document.
In the network stratum, the Network Control Gateway (NCG) serves as the proxy gateway to the network. The NCG receives the query request from the ACG, probes the network to test the capabilities for data flows to/from particular points in the network, and gathers the collective information of a variety of horizontal schemes implemented in the network stratum. This is a horizontal query (Stage 2 in Figure 2).
In this section we will describe how PCE fits in this horizontal scheme.
A Path Computation Element (PCE) is 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.
(1) NCG and PCE are co-located.
In this composite solution, the same node implements functionality of both NCG and PCE. When a network stratum query is received from the ACG (stage 1), this query is broken into one or more Path computation requests and handled by the PCE functionality co-located with the NCG. There is no need for PCEP protocol here. In this case, an external PCE interface (e.g., CLI, SNMP, proprietary) needs to be supported. This is out of the scope of this document.
+--------------------------------------------------+
| -- -- -- -- -- -- -- -- -- |
| | | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
| |
| Application Stratum |
| |
| +---------------------------------------+ |
| | | |
+----+ ACG +-----+
| |
+------*---*----------------------------+
| |
| |
| |
+------*---*----------------------------+
| +----------+ +----------+ |
+----+ + *----------* * +-----+
| | | NCG | | PCE | | |
| | | *----------* * | |
| | +----------+ +----------+ | |
| | | |
| +---------------------------------------+ |
| |
| Network Stratum |
| -- -- -- -- -- -- -- -- -- |
| | | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
+--------------------------------------------------+
Figure 3: NCG and PCE Collocated
(2) NCG and external PCE
In this solution, an external node implements PCE functionality. Network stratum query received from the ACG (stage 1) is converted into Path computation requests at the NCG and relayed to the external PCE using the PCEP [RFC5440]. In this case the NCG includes Path Computation Client (PCC) functionalities.
+--------------------------------------------------+
| -- -- -- -- -- -- -- -- -- |
| | | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
| |
| Application Stratum |
| |
| +---------------------------------------+ |
| | | |
+----+ ACG +-----+
| |
+------*---*----------------------------+
| |
| |
| |
+------*---*-------+
| +----------+ | +----------+
+----+ | | *------* *--------+
| | | NCG | | | PCE | |
| | | | *------* * |
| | +----------+ | +----------+ |
| | | |
| +------------------+ |
| |
| Network Stratum |
| -- -- -- -- -- -- -- -- -- |
| | | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
+--------------------------------------------------+
Figure 4: NCG and external PCE
PCE has the capability to compute constrained paths between a source and one or more destination(s), optionally providing the value of the metrics associated to the computed path(s). Thus it can fit very well in the horizontal query stage of CSO. A PCE MAY have further capability to do multi-layer and/or inter-domain path computation which can be further utilized. NCG which understands the vertical query and the presence of applications constraints can break the application request into suitable path computation request which PCE understands. In this scenario, the PCE MAY have no knowledge of applications and provide only network related metrics to the NCG: the NCG (or the ACG for an application-centric model) is in charge of correlating the network quotations with the application layer information to achieve the global CSO objective.
With this architecture, NCG can request PCE different sets of computation mode that are not currently supported by PCE. For instance, NCG may request PCE a multi-destination and multi-source path computation request. This scenario arises when there are many possible Data Center choices for a given application request and there could be multiple sources for this request. Multi-destination with a single source (aka., anycast) is a default case for multi-destination and multi-source path computation.
In addition, with this architecture, NCG may have different sets of objectives and constraints than typical path computation requests. For instance, multi-criteria objective functions that combine the bandwidth requirement and latency may be very useful for some applications. [PCE-SERVICE-AWARE] describes the extension to PCEP to carry Latency, Latency-Variation and Loss as constraints for end to end path computation.
In a Stateful PCE (refer [PCE-STATEFUL]), there is a strict synchronization of the network states (in term of topology and resource information), and the set of computed paths and reserved resources in use in the network. In other words, the PCE utilizes information from the TED as well as information about existing paths (for example, TE LSPs) in the network when processing new requests. Stateful PCE will be very important tool to achieve the goals of cross stratum optimization as maintains the status of final path selected after cross (application and network) optimization.
As Stateful PCE would keep both LSP ID and the application ID associated with the LSP, it will make path computation more efficient in terms of resource usage and computation time. Moreover, Stateful PCE would have an accurate snapshot of network resource information and as such it can increase adaptability to the changes. This may be important for some application that requires a stringent performance objective.
In conclusion -
Path computation flow is shown in Figure 5.
+----------+ 1 +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ 6 +---------------------------------------+
^ |
| 2|
| | +----------+ 3 +----------+
| +->| |--------->| |
| | NCG | | PCE |
+-----| |<---------| |
5 +----------+ 4 +----------+
Figure 5: Path Computation Flow
In this section we would analyze the mechanisms to finally setup the cross stratum optimized path.
After ACG and NCG have decided the path that needs to be set, NCG can send a request to NMS asking it relay the message to the head end LSR (also a PCC) to setup the pre computed path. Once the path signaling is completed and the LSP is setup, PCC should relay the status of the LSP to the Stateful PCE.
In this mechanism we can reuse the existing NMS to establish the path. Any updates or deletion of such path would be made via the NMS.
Head end LSR (PCC) 'H' is always the owner of the path.
See Figure 6 for this scenario.
+----------+ +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ +---------------------------------------+
^ |
+-----------------+--+------------------------------------+
|+----------+ | | +----------+ +----------+|
|| | | +->| |--------->| ||
|| NMS | +-----| NCG | | PCE ||
|| |<----------| |<---------| ||
|+----------+ +----------+ +----------+|
| | ^ |
| | +------------------------------------+ |
| | | Network Stratum |
| | -- -- -- -- -- -- -- -- -- |
| +----->|H | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
+---------------------------------------------------------+
Figure 6: Path Setup Using NMS
A network control plane (e.g. GMPLS) MAY be used to automatically establish the cross optimized path between the selected end points. This control plane MAY be triggered via -
See Figure 7 for this scenario.
+----------+ +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ +---------------------------------------+
^ |
+-----------------+--+------------------------------------+
|+----------+ | | +----------+ +----------+|
|| GMPLS | | +->| |--------->| ||
|| Control | +-----| NCG | | PCE ||
|| plane |<----------| |<---------| ||
|+----------+ +----------+ +----------+|
| | ^ |
| | +------------------------------------+ |
| | | Network Stratum |
| | -- -- -- -- -- -- -- -- -- |
| +----->|H | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
+---------------------------------------------------------+
Figure 7: Path Setup Using Centralized Control Plane
After cross optimization, ACG and NCG will select the suitable end points, (the path is already calculated by PCE), this path is conveyed to the head end LSR which signals the path and notify the status to the Stateful PCE. Later NCG can send suitable message to tear down the path.
Using centralized control plane can make the NCG responsible for the LSP. Head end LSR signals and maintains the status but the establishment and tear-down are initiated by the control plane. This would have an obvious advantage in managing the setup paths. The Stateful PCE will maintain the TED as well as the status of setup LSP. NCG through centralized control plane can further setup/teardown/modify/re-optimize those paths.
A Stateful PCE extension MAY be developed to communicate the cross optimized path to the head end LSR. Current PCEP protocol requires PCC to trigger Path request and PCE to provide reply. Even in Stateful PCE, PCC must delegate the LSP to a PCE, a PCE never initiate path setup. An extension to PCEP protocol MAY let PCE notify to PCC (Head end LSR) to establish the path.
NCG via PCE and PCEP protocol can establish and tear-down LSP as shown in Figure 8. [PCE_INITIATED] is one such attempt to extend PCEP.
+----------+ +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ +---------------------------------------+
^ |
+-----------------+--+------------------------------------+
| | | +----------+ +----------+|
| | +->| |--------->| ||
| | | NCG | | PCE ||
| +-----| |<---------| ||
| +----------+ +----------+|
| +---------------------------------------+ ^ |
| | +------------------------------------+ |
| | | Network Stratum |
| | -- -- -- -- -- -- -- -- -- |
| +->|H | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
+---------------------------------------------------------+
Figure 8: Path Setup using PCE
A logically centralized Software Defined Network (SDN) controller MAY be used to properly configure in an automatic way the traffic forwarding rules that allow the end to end communication across the Network Stratum.
Figure 9 shows this scenario.
+----------+ +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ +---------------------------------------+
^ |
+-----------------+--+------------------------------------+
| | | +----------+ +----------+|
| | +->| |--------->| ||
| | | NCG | | PCE ||
| +-----| |<---------| ||
| +----------+ +----------+|
| | ^ |
| v | |
| +----------------------------+ |
| +-| SDN Controller |--+ |
| | +----------------------------+ | |
| | | | | | | | | |
| v v v v v v v v |
| -- -- -- -- -- -- -- -- |
| | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- |
| |
| Network Stratum |
| |
+---------------------------------------------------------+
Figure 9: Path Setup using SDN
A direct interface between the SDN Controller and the PCE could be present in the architecture shown in Figure 9.
As result of the interaction between ACG and NCG (including the PCE processing), the NCG is able to instruct the SDN Controller to populate a number of forwarding rules to the network devices for building the end to end path.
Underlying network connecting the datacenters MAYBE made up of multiple domains (AS and Area). In this case an inter-domain path computation is required.
+----------+ +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ +---------------------------------------+
^ |
| |
+--------------+ +--+--+------------------------------------+
| +----------+| | | | +----------+ +----------+|
| | || | | +->| |--------->| ||
| | PCE || | | | NCG | | PCE ||
| | || | +-----| |<---------| ||
| +----+-----+| | +----------+ +----+-----+|
| | | | | |
+-------+------+ +-----------------------------------+------+
| |
| |
|<---------------pcep session----------------->|
| |
Figure 10: Multi-domain Scenario
[RFC5441] describes an inter-domain path computation with cooperating PCEs which can be enhanced and utilized in CSO enabled path computation.
Underlying network connecting the datacenters MAY be made up of multiple domains (AS and Area) as well as applications domains and ACG MAY be distributed. In such case multiple ACG and NCG will be involved in cross optimizing. This needs to be analyzed further.
As shown in Figure 11, ACG where the request originates may communicate with multiple NCG to get the network information from multiple domains to be cross optimized.
Application stratum
+---------------------------+ +---------------------------+
| | | |
| | | |
| | | |
| | | |
| | | |
| +----------------------+ | | +----------------------+ |
| | | | | | | |
+--+ ACG +-+ +--+ ACG +-+
| | | |
+-+-+-------------+-+--+ +-------+-+------------+
| | | +------------+ | |
| | +------------+ | | |
+-+-+--------+ +-----+ +-+-----+-+--+ +-----+
+--+ +---+ +-+ +--+ +----+ ++
| | NCG |---| | | | | NCG |----| ||
| | |---| | | | | |----| ||
| +------------+ | PCE | | | +------------+ | PCE ||
| | | | | | ||
| | |<+--+------------------->| ||
| +-----+ | | +-----+|
|Domain 1 | |Domain 2 |
+---------------------------+ +---------------------------+
Network Stratum
Figure 11: ACG talks to multiple NCG
As shown in Figure 12, ACG communicated only to the primary NCG, which may gather network information from multiple NCG and then communicate consolidated information to ACG.
Application stratum
+---------------------------+ +---------------------------+
| | | |
| | | |
| | | |
| | | |
| | | |
| +----------------------+ | | +----------------------+ |
| | | | | | | |
+--+ ACG +-+ +--+ ACG +-+
| | | |
+-+-+------------------+ +-------+-+------------+
| | | |
| | | |
+-+-+--------+ +-----+ +-------+-+--+ +-----+
+--+ +---+ +-+ +--+ +----+ ++
| | NCG |---| | | | | NCG |----| ||
| | |---| | | | | |----| ||
| +------+-----+ | PCE | | | +---+--------+ | PCE ||
| | | | | | | | ||
| | | |<+--+------+------------>| ||
| | +-----+ | | | +-----+|
|Domain 1 | | |Domain|2 |
+---------+-----------------+ +------+--------------------+
| | Network Stratum
| |
|<------------------------->|
| |
Figure 12: Primary NCG talks to other NCG
In this case, the Data Centers are federated building a community cloud. In each Data Center, the connection to the network stratum that interconnects the Data Center federation is done by means of one or more devices controllable through an SDN controller particular for that Data Center.
The NCG, then, interacts with a number of separated SDN controllers, orchestrating their operation in order to perform the service requested by the ACG in an optimized way.
Figure 13 shows this scenario.
+----------+ +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ +---------------------------------------+
| ^
| |
+----------+--+-------------------------+
| | | |
| v | |
| +----------+ +----------+|
| | |-------->| ||
| | NCG | | PCE ||
| | |<--------| ||
| +----------+ +----------+|
| | ^ | ^ |
| | | | | |
+-------+-+----+-+----------------------+
| | | |
+-------------+ | | +-------------+
| +-------------+ +-------------+ |
| | | |
v | v |
+--------------------+ +--------------------+
+- | SDN Controller DC1 | . . . | SDN Controller DCN | -+
| +--------------------+ +--------------------+ |
| |
| Federated Data Centers |
+-------------------------------------------------------------+
Figure 13: NCG orchestration of separated SDN domains
A different scenario for multi-domain interconnection could be due to the deployment of multi-layered multi-domain networks (and these domains may be technology, administrative or vendor specific (vendor islands))for supporting end-to-end connectivity at the Network Stratum. Each of those domains can be controlled by a distinct SDN controller adapted to the specifics of the technology under control.
The NCG requests path calculation to a multi-layer PCE which takes into consideration such diversity providing an integrated computation for the best path according to application constraints. The NCG instruct a primary SDN controller which apart of configuring the elements directly controlled by itself, it is able to communicate with other SDN controllers with responsibility over other domains. Such communication can be done through the usage of specific methods through pre-defined South Bound Interface or East/West Interface (out of the scope of this document).
The following figure shows this scenario.
+----------+ +---------------------------------------+
| |------->| |
| User | | ACG |
| |<-------| |
+----------+ +---------------------------------------+
| ^
| |
+----------+--+-------------------------+
| | | |
| v | |
| +----------+ +----------+ |
| | |------>| Multi- | |
| | NCG | | Layer | |
| | |<------| PCE | |
| +----------+ +----------+ |
| | ^ |
| | | |
+----------+--+-------------------------+
| |
v |
+----------+
| SDN |----------+
|Controller| |
+----------+ |
^ +----------+
| | SDN |
v |Controller|
Layer-N +----------+
Resources ^
|
v
Layer-N-1
Resources
Figure 14: Nested multi-layer SDN domains
In optical networks all PCE messages are sent over control channel, in Stateful PCE cases its observed that in case of a major link or node failure lot of PCEP messages are sent from all PCC to PCE. This use lot of bandwidth of the control channel.
PCE MAY become a common point of failure and bottleneck. PCE/NCG/ACG failure as well as the link-failure disrupting connectivity could be highly disruptive to the system.
The solution should focus on reducing such bottleneck.
[ABNO] demonstrates cross-stratum application/network optimization for the data center use case with PCE as the heart of Application-Based Network Operations (ABNO) architecture. It further highlights the interaction between various ABNO components and PCE to achieve this use-case.
[ACTN] describes the framework for abstraction and control of transport networks (ACTN) using hierarchy of controllers. The Physical Network Controller (PNC) or Virtual Network Controller (VNC) is equivalent to the NCG in the CSO framework, both rely on PCE for the network optimization.
None, This is an informational document.
TBD
TBD
Part of the work in this document has been funded by the European Community's Seventh Framework Programme projects XIFI (L.M. Contreras and O. Gonzalez), under grant agreement n. 604590, and GEYSERS (N. Ciulli and L.M. Contreras), under grant agreement n. 248657.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |