One document matched: draft-dhody-pce-cso-enabled-path-computation-02.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc ipr="trust200902" category="info" docName="draft-dhody-pce-cso-enabled-path-computation-02" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="CSO-PCE">Cross Stratum Optimization enabled Path Computation</title>
<author initials="D" surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.dhody@huawei.com</email>
</address>
</author>
<author initials="Y" surname="Lee" fullname="Young Lee">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>1700 Alma Drive, Suite 500</street>
<city>Plano</city>
<region>TX</region>
<code>75075</code>
<country>USA</country>
</postal>
<email>leeyoung@huawei.com</email>
</address>
</author>
<author initials="N" surname="Ciulli" fullname="Nicola Ciulli">
<organization>Nextworks</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>n.ciulli@nextworks.it</email>
</address>
</author>
<author initials="L. M." surname="Contreras" fullname="Luis M. Contreras">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>lmcm@tid.es</email>
</address>
</author>
<author initials="O" surname="Gonzalez de Dios" fullname="Oscar Gonzalez de Dios">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz</street>
<city>Madrid</city>
<region></region>
<code>28006</code>
<country>Spain</country>
</postal>
<email>ogondio@tid.es</email>
</address>
</author>
<date month="September" year="2012" />
<area>Routing</area>
<workgroup>PCE Working Group</workgroup>
<abstract>
<t>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 <xref target="CSO-DATACNTR"/>. </t>
<t>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. <xref target="RFC4655"/> explains the architecture for a Path Computation Element (PCE)-based model to address this problem space. </t>
<t>This document explains the architecture for CSO enabled Path Computation. </t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>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. <xref target="CSO-PROBLEM"/> describes the problem space for cross stratum optimization. </t>
<t><xref target="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. <xref target="fig1" /> shows typical data center architecture. </t>
<t>
<figure title="Data Center Architecture" anchor ="fig1" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
---------------
---------- | 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 |
---------------
]]></artwork>
</figure>
</t>
<t><xref target="fig2"/> shows the context of NS Query within the overarching data center architecture shown in <xref target="fig1" />.</t>
<t>
<figure title="NS Query Architecture" anchor ="fig2" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
--------------------------------------------
| 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) ---------------- |
-------------------------------------------
]]></artwork>
</figure>
</t>
<t>NS Query is a two-stage query that consists of two stages:</t>
<t>
<list style="symbols">
<t>A vertical query capability where an external point (i.e., the Application Control Gateway (ACG) in Data Center) will query the network (i.e., the Network Control Gateway (NCG)). The query can be initiated either by ACG to NCG or NCG to ACG depending on the mode of operation. ACG initiated query is an application-centric mode while NCG initiated query is a network-centric mode. It is anticipated that either ACG or NCG can be a final decision making point that chooses the end-to-end resources (i.e., both application IT resources and the network connectivity) depending on the mode of operation.</t>
<t>A horizontal query capability where the NCG gathers the collective information of a variety of horizontal schemes implemented in the network stratum.</t>
</list>
</t>
<t>As an example for vertical query (1st stage), <xref target="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.</t>
<t>For the horizontal query (2nd stage), PCE can be an ideal choice, <xref target="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.</t>
<t>This document describes how PCE Architecture as described in <xref target="RFC4655"/> can help in the second stage of NS query. </t>
<section title="Requirements Language" toc="default">
<t>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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Terminology" toc="default">
<t>The following terminology is used in this document.</t>
<t>
<list style="hanging">
<t hangText="ACG:">Application Control Gateway.</t>
<t hangText="Application Stratum:">The application stratum is the functional block which manages and controls application resources and provides application resources to a variety of clients/end-users. Application resources are non-network resources critical to achieving the application service functionality. Examples include: application specific servers, storage, content, large data sets, and computing power. Data Centers are regarded as tangible realization of the application stratum architecture.</t>
<t hangText="ALTO:">Application Layer Traffic Optimization.</t>
<t hangText="CSO:">Cross Stratum Optimization.</t>
<t hangText="GMPLS:">Generalized Multiprotocol Label Switching.</t>
<t hangText="i2aex:">Infrastructure to application information exposure.</t>
<t hangText="LSR:">Label Switch Router.</t>
<t hangText="MPLS:">Multiprotocol Label Switching.</t>
<t hangText="NCG:">Network Control Gateway.</t>
<t hangText="Network Stratum:">The network stratum is the functional block which manages and controls network resources and provides transport of data between clients/end-users to and among application resources. Network Resources are resources of any layer 3 or below (L1/L2/L3) such as bandwidth, links, paths, path processing (creation, deletion, and management), network databases, path computation, admission control, and resource reservation capability. </t>
<t hangText="NMS:">Network Management System</t>
<t hangText="PCC:">Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element.</t>
<t hangText="PCE:">Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.</t>
<t hangText="PCEP:">Path Computation Element Communication Protocol.</t>
<t hangText="TE:">Traffic Engineering.</t>
<t hangText="TED:">Traffic Engineering Database.</t>
<t hangText="UNI:">User Network Interface.</t>
</list>
</t>
</section>
<section title="CSO enabled PCE Architecture" toc="default">
<t>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 <xref target="fig2"/>). </t>
<t>In this section we will describe how PCE fits in this horizontal scheme. </t>
<t>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. </t>
<t>(1) NCG and PCE are co-located.</t>
<t>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.</t>
<t>
<figure title="NCG and PCE Collocated" anchor ="fig3" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
+--------------------------------------------------+
| -- -- -- -- -- -- -- -- -- |
| | | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
| |
| Application Stratum |
| |
| +---------------------------------------+ |
| | | |
+----+ ACG +-----+
| |
+------*---*----------------------------+
| |
| |
| |
+------*---*----------------------------+
| +----------+ +----------+ |
+----+ + *----------* * +-----+
| | | NCG | | PCE | | |
| | | *----------* * | |
| | +----------+ +----------+ | |
| | | |
| +---------------------------------------+ |
| |
| Network Stratum |
| -- -- -- -- -- -- -- -- -- |
| | | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
+--------------------------------------------------+
]]></artwork>
</figure>
</t>
<t>(2) NCG and external PCE</t>
<t>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 <xref target="RFC5440"/>. In this case the NCG includes Path Computation Client (PCC) functionalities.</t>
<t>
<figure title="NCG and external PCE" anchor ="fig4" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
+--------------------------------------------------+
| -- -- -- -- -- -- -- -- -- |
| | | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
| |
| Application Stratum |
| |
| +---------------------------------------+ |
| | | |
+----+ ACG +-----+
| |
+------*---*----------------------------+
| |
| |
| |
+------*---*-------+
| +----------+ | +----------+
+----+ | | *------* *--------+
| | | NCG | | | PCE | |
| | | | *------* * |
| | +----------+ | +----------+ |
| | | |
| +------------------+ |
| |
| Network Stratum |
| -- -- -- -- -- -- -- -- -- |
| | | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
+--------------------------------------------------+
]]></artwork></figure></t>
<t>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.</t>
<t>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. </t>
<t>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. <xref target="PCE-SERVICE-AWARE" /> describes the extension to PCEP to carry Latency, Latency-Variation and Loss as constraints for end to end path computation.</t>
<t>In a Stateful PCE (refer <xref target="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. </t>
<t>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. </t>
<t>In conclusion - </t>
<t>
<list style="symbols">
<t>NCG can use the PCE to do path computation based on constrains from multiple sources and destinations.</t>
<t>Stateful PCE can help in maintaining the status of the final cross optimized path. It can also help NCG in maintaining the relationship of application request and setup path. In case of any change of the path, the Stateful PCE and NCG and cooperate and take suitable action.</t>
</list>
</t>
</section>
<section title="Path Computation and Setup Procedure" toc="default">
<t>Path computation flow is shown in <xref target="fig5"/>. </t>
<t>
<list style="numbers">
<t>User for application would contact the application gateway ACG with its requirements.</t>
<t>ACG would further query the NCG to obtain the underlying network Status and quotations (offers) for the network connectivity services.</t>
<t>NCG would break the vertical request into suitable horizontal path computation request(s).</t>
<t>PCE would provide the result to NCG.</t>
<t>NCG would abstract the computation result and provide to ACG.</t>
<t>NCG and ACG would cooperate to finalize the path that needs to be setup.</t>
<t>Note that that the final decision can be made either in ACG or NCG depending on the mode of operation. With application centric mode, minimal data center/IT resource information would flow from ACG to NCG while ACG collects network abstracted information from NCG to choose the optimal application-network resources. With network centric mode, ACG would supply maximal data center/IT resource information to NCG so that NCG in conjunction with PCE would determine the optimal mixed set of application and network resources. In the latter case, the PCE COULD support application/IT- based constrained computation capability beyond network path computation. This requires further PCE capabilities to receive and process data center/IT resource information, possibly in conjunction with network information.</t>
</list>
</t>
<t>
<figure title="Path Computation Flow" anchor ="fig5" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
+----------+ 1 +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ 6 +---------------------------------------+
^ |
| 2|
| | +----------+ 3 +----------+
| +->| |--------->| |
| | NCG | | PCE |
+-----| |<---------| |
5 +----------+ 4 +----------+
]]></artwork>
</figure>
</t>
<t>In this section we would analyze the mechanisms to finally setup the cross stratum optimized path. </t>
<section title="Path Setup Using NMS" toc="default">
<t>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. </t>
<t>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. </t>
<t>Head end LSR (PCC) 'H' is always the owner of the path. </t>
<t>See <xref target="fig6"/> for this scenario. </t>
<t>
<figure title="Path Setup Using NMS" anchor="fig6" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
+----------+ +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ +---------------------------------------+
^ |
+-----------------+--+------------------------------------+
|+----------+ | | +----------+ +----------+|
|| | | +->| |--------->| ||
|| NMS | +-----| NCG | | PCE ||
|| |<----------| |<---------| ||
|+----------+ +----------+ +----------+|
| | ^ |
| | +------------------------------------+ |
| | | Network Stratum |
| | -- -- -- -- -- -- -- -- -- |
| +----->|H | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
+---------------------------------------------------------+
]]></artwork>
</figure>
</t>
</section>
<section title="Path Setup Using a Network Control Plane" toc="default">
<t>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 -</t>
<t>
<list style="symbols">
<t>NCG to Control Plane: GMPLS UNI or other protocols</t>
<t>Control Plane to Head end Router: GMPLS Control Channel Interface (CCI). Suitable protocol extensions are needed to achieve this.</t>
</list>
</t>
<t>See <xref target="fig7"/> for this scenario. </t>
<t>
<figure title="Path Setup Using Centralized Control Plane" anchor="fig7" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
+----------+ +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ +---------------------------------------+
^ |
+-----------------+--+------------------------------------+
|+----------+ | | +----------+ +----------+|
|| GMPLS | | +->| |--------->| ||
|| Control | +-----| NCG | | PCE ||
|| plane |<----------| |<---------| ||
|+----------+ +----------+ +----------+|
| | ^ |
| | +------------------------------------+ |
| | | Network Stratum |
| | -- -- -- -- -- -- -- -- -- |
| +----->|H | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
+---------------------------------------------------------+
]]></artwork>
</figure>
</t>
<t>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. </t>
<t>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.</t>
</section>
<section title="Path Setup using PCE" toc="default">
<t>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.</t>
<t>NCG via PCE and PCEP protocol can establish and tear-down LSP as shown in <xref target="fig8"/>. </t>
<t>
<figure title="Path Setup using PCE" anchor="fig8" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
+----------+ +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ +---------------------------------------+
^ |
+-----------------+--+------------------------------------+
| | | +----------+ +----------+|
| | +->| |--------->| ||
| | | NCG | | PCE ||
| +-----| |<---------| ||
| +----------+ +----------+|
| +---------------------------------------+ ^ |
| | +------------------------------------+ |
| | | Network Stratum |
| | -- -- -- -- -- -- -- -- -- |
| +->|H | | | | | | | | | | | | | | | | | |
| -- -- -- -- -- -- -- -- -- |
+---------------------------------------------------------+
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Other Consideration" toc="default">
<section title="Inter-domain" toc="default">
<section title="One Application Domain with Multiple Network Domains" toc="default">
<t>Underlying network connecting the datacenters MAYBE made up of multiple domains (AS and Area). In this case an inter-domain path computation is required.</t>
<t>
<figure title="Multi-domain Scenario" anchor="fig9" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
+----------+ +---------------------------------------+
| |-------->| |
| User | | ACG |
| |<--------| |
+----------+ +---------------------------------------+
^ |
| |
+--------------+ +--+--+------------------------------------+
| +----------+| | | | +----------+ +----------+|
| | || | | +->| |--------->| ||
| | PCE || | | | NCG | | PCE ||
| | || | +-----| |<---------| ||
| +----+-----+| | +----------+ +----+-----+|
| | | | | |
+-------+------+ +-----------------------------------+------+
| |
| |
|<---------------pcep session----------------->|
| |
]]></artwork>
</figure>
</t>
<t><xref target="RFC5441"/> describes an inter-domain path computation with cooperating PCEs which can be enhanced and utilized in CSO enabled path computation. </t>
</section>
<section title="Multiple Application Domains with Multiple Network Domains" toc="default">
<t>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.</t>
<section title="ACG talks to multiple NCGs" toc="default">
<t>As shown in <xref target="fig10"/>, ACG where the request originates may communicate with multiple NCG to get the network information from multiple domains to be cross optimized. </t>
<t>
<figure title="ACG talks to multiple NCG" anchor="fig10" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Application stratum
+---------------------------+ +---------------------------+
| | | |
| | | |
| | | |
| | | |
| | | |
| +----------------------+ | | +----------------------+ |
| | | | | | | |
+--+ ACG +-+ +--+ ACG +-+
| | | |
+-+-+-------------+-+--+ +-------+-+------------+
| | | +------------+ | |
| | +------------+ | | |
+-+-+--------+ +-----+ +-+-----+-+--+ +-----+
+--+ +---+ +-+ +--+ +----+ ++
| | NCG |---| | | | | NCG |----| ||
| | |---| | | | | |----| ||
| +------------+ | PCE | | | +------------+ | PCE ||
| | | | | | ||
| | |<+--+------------------->| ||
| +-----+ | | +-----+|
|Domain 1 | |Domain 2 |
+---------------------------+ +---------------------------+
Network Stratum
]]></artwork>
</figure>
</t>
</section>
<section title="ACG talks to the primary NCG, which talks to the other NCG of different domains" toc="default">
<t>As shown in <xref target="fig11"/>, ACG communicated only to the primary NCG, which may gather network information from multiple NCG and then communicate consolidated information to ACG. </t>
<t>
<figure title="Primary NCG talks to other NCG" anchor="fig11" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
Application stratum
+---------------------------+ +---------------------------+
| | | |
| | | |
| | | |
| | | |
| | | |
| +----------------------+ | | +----------------------+ |
| | | | | | | |
+--+ ACG +-+ +--+ ACG +-+
| | | |
+-+-+------------------+ +-------+-+------------+
| | | |
| | | |
+-+-+--------+ +-----+ +-------+-+--+ +-----+
+--+ +---+ +-+ +--+ +----+ ++
| | NCG |---| | | | | NCG |----| ||
| | |---| | | | | |----| ||
| +------+-----+ | PCE | | | +---+--------+ | PCE ||
| | | | | | | | ||
| | | |<+--+------+------------>| ||
| | +-----+ | | | +-----+|
|Domain 1 | | |Domain|2 |
+---------+-----------------+ +------+--------------------+
| | Network Stratum
| |
|<------------------------->|
| |
]]></artwork>
</figure>
</t>
</section>
</section>
</section>
<section title="Bottleneck" toc="default">
<t>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.</t>
<t>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. </t>
<t>The solution should focus on reducing such bottleneck.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>TBD</t>
</section>
<section title="Security Considerations" toc="default">
<t>TBD </t>
</section>
<section title="Manageability Considerations" toc="default">
<t>TBD</t>
</section>
<section title="Acknowledgements" toc="default">
<t>The research work of N. Ciulli and L.M. Contreras has been partially supported by the GEYSERS project (www.geysers.eu), funded by the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n. 248657.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.5441.xml" ?>
<!--CSO-DATACNTR-->
<reference anchor="CSO-DATACNTR">
<front>
<title>Research Proposal for Cross Stratum Optimization (CSO) between Data Centers and Networks. (draft-lee-cross-stratum-optimization-datacenter-00)</title>
<author initials="Y" surname="Lee" fullname="Lee Y">
<organization />
</author>
<author initials="G" surname="Bernstein" fullname="Bernstein G">
<organization />
</author>
<author initials="N" surname="So" fullname="So N">
<organization />
</author>
<author initials="T" surname="Kim" fullname="Tae Yeon Kim">
<organization />
</author>
<author initials="K" surname="Shiomoto" fullname="Shiomoto K">
<organization />
</author>
<author initials="O" surname="Gonzalez-de-Dios" fullname="Gonzalez-de-Dios O">
<organization />
</author>
<date month="March" year="2011" />
</front>
</reference>
<!--CSO-PROBLEM-->
<reference anchor="CSO-PROBLEM">
<front>
<title>Problem Statement for Cross-Layer Optimization. (draft-lee-cross-layer-optimization-problem-02)</title>
<author initials="Y" surname="Lee" fullname="Lee Y">
<organization />
</author>
<author initials="G" surname="Bernstein" fullname="Bernstein G">
<organization />
</author>
<author initials="N" surname="So" fullname="So N">
<organization />
</author>
<author initials="S" surname="Hares" fullname="Hares S">
<organization />
</author>
<author initials="F" surname="Xia" fullname="Xia F">
<organization />
</author>
<author initials="K" surname="Shiomoto" fullname="Shiomoto K">
<organization />
</author>
<author initials="O" surname="Gonzalez-de-Dios" fullname="Gonzalez-de-Dios O">
<organization />
</author>
<date month="January" year="2011" />
</front>
</reference>
<!--NS-QUERY-->
<reference anchor="NS-QUERY">
<front>
<title>Problem Statement for Network Stratum Query. (draft-lee-network-stratum-query-problem-02) </title>
<author initials="Y" surname="Lee" fullname="Lee Y">
<organization />
</author>
<author initials="G" surname="Bernstein" fullname="Bernstein G">
<organization />
</author>
<author initials="N" surname="So" fullname="So N">
<organization />
</author>
<author initials="D" surname="McDysan" fullname="McDysan D">
<organization />
</author>
<author initials="T" surname="Kim" fullname="Tae Yeon Kim">
<organization />
</author>
<author initials="K" surname="Shiomoto" fullname="Shiomoto K">
<organization />
</author>
<author initials="O" surname="Gonzalez-de-Dios" fullname="Gonzalez-de-Dios O">
<organization />
</author>
<date month="January" year="2011" />
</front>
</reference>
<!--CSO-PCE-REQT-->
<reference anchor="CSO-PCE-REQT">
<front>
<title>Path Computation Requirements for Cross-Stratum-Optimization. (draft-tovar-cso-path-computation-requirements-00)</title>
<author initials="A" surname="Tovar" fullname="Tovar A">
<organization />
</author>
<author initials="L. M." surname="Contreras" fullname="Contreras L. M.">
<organization />
</author>
<author initials="G" surname="Landi" fullname="Landi G">
<organization />
</author>
<author initials="N" surname="Ciulli" fullname="Ciulli N">
<organization />
</author>
<date month="October" year="2011"/>
</front>
</reference>
<!--PCE-SERVICE-AWARE-->
<reference anchor="PCE-SERVICE-AWARE">
<front>
<title>Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP). (draft-dhody-pce-pcep-service-aware-03)</title>
<author initials="D" surname="Dhody" fullname="Dhody D">
<organization />
</author>
<author initials="V" surname="Manral" fullname="Manral V">
<organization />
</author>
<date month="June" year="2012"/>
</front>
</reference>
<!--PCE-STATEFUL-->
<reference anchor="PCE-STATEFUL">
<front>
<title>PCEP Extensions for Stateful PCE. (draft-ietf-pce-stateful-pce-01)</title>
<author initials="E" surname="Crabbe" fullname="Crabbe E">
<organization />
</author>
<author initials="J" surname="Medved" fullname="Medved J">
<organization />
</author>
<author initials="R" surname="Varga" fullname="Varga R">
<organization />
</author>
<author initials="I" surname="Minei" fullname="Minei I">
<organization />
</author>
<date month="July" year="2012"/>
</front>
</reference>
<!--ALTO-APPNET-->
<reference anchor="ALTO-APPNET">
<front>
<title>ALTO Extensions to Support Application and Network Resource Information Exchange for High Bandwidth Applications. (draft-lee-alto-app-net-info-exchange-00)</title>
<author initials="Y" surname="Lee" fullname="Lee Y">
<organization />
</author>
<author initials="G" surname="Bernstein" fullname="Bernstein G">
<organization />
</author>
<author initials="T S" surname="Varga" fullname="Choi T S">
<organization />
</author>
<author initials="S" surname="Madhavan" fullname="Madhavan S">
<organization />
</author>
<author initials="D" surname="Dhody" fullname="Dhody D">
<organization />
</author>
<date month="July" year="2012"/>
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:20:25 |