Internet DRAFT - draft-zheng-pce-for-sdn-transport
draft-zheng-pce-for-sdn-transport
PCE Working Group . Haomian Zheng
Internet Draft Xian Zhang
Category: Informational Huawei Technologies
Expires: August 14, 2014 February 14, 2014
Path Computation Element to Support Software-Defined Transport Networks
Control
draft-zheng-pce-for-sdn-transport-00.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.
Copyright Notice
Copyright (c) 2014 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.
Zheng et al Expires August 2014 [Page 1]
draft-zheng-pce-for-SDN-transport-00 February 2014
Abstract
This draft describes PCE architecture and protocol in SDN-based
transport network. It is demonstrated that PCE can fit in the
transport SDN architecture and complete corresponding requests. The
PCE and its protocol can satisfy the functional requirement in
several transport SDN applications.
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. Path Computation in Transport SDN............................ 4
2.1. Transport SDN Architecture.............................. 4
2.2. Path computation and establishment...................... 5
2.2.1 Stateless PCE....................................... 5
2.2.2 Stateful PCE........................................ 5
2.2.3 PCE Initiation...................................... 5
3. PCE Applicability for Transport SDN.......................... 6
3.1. Photonic Enterprise Networks............................ 6
3.2. Virtualized Transport Network........................... 6
3.3. Data center interconnection............................. 8
3.4. Packet Optical Integration............................. 10
4. IANA Considerations ........................................ 11
5. References ................................................. 11
5.1. Normative References................................... 11
5.2. Informative References................................. 11
6. Authors' Addresses.......................................... 12
1. Introduction
Software Defined Networking (SDN) is an emerging approach to
networking and has great potential to shift paradigm in the field of
network control and management. SDN greatly simplifies the network
control and management by separating the control plane from data
plane, which allows network operators to manage network services on
an abstraction of the underlying physical networks. SDN requires
some method for the control plane to communicate with the data
Zheng Expires August 2014 [Page 2]
draft-zheng-pce-for-SDN-transport-00 February 2014
plane. OpenFlow is one of such mechanisms and is under development
to provide standardized communication [OpenFlow].
Specifically, for transport network, the idea of SDN is a perfect
choice for future development due to the natural separation of data
and control planes. There are some emerging service features and
requirements for transport networks that include services that are
time scheduled, dynamic, elastic, and underpinned by a Pay As You Go
billing model. These features require the transport controllers to
provide services with large bandwidth in a short period. All of the
above are the motivations for introducing the SDN idea into the
transport network.
Path Computation Element (PCE) was firstly developed to solve the
path computation problem for MPLS and GMPLS-controlled networks
[RFC4655]. Given the demand to simplify the network management and a
centralized PCE, the functional transport architecture is very close
to the idea of Software-defined Networking (SDN). In the SDN
architecture, PCE can be envisioned to be a core functional block in
the SDN controller, responsible not only for path computation but
for other functions such as provisioning and abstraction control.
This draft intends to discuss how the PCE architecture and PCEP
protocol developed to date can support the transport SDN by
analyzing the role PCE plays in some typical use cases.
Optical Enterprise network
PCE can provide transport service in small-scale enterprise network,
which is under a totally centralized control environment.
Virtualized transport network
PCE can be used for virtual service provisioning. In this way
clients can propose various network requests to operators.
Data-center Interconnection
Current PCE architecture and protocol can support transport services
provisioning in data-center Interconnection Networks.
Packet-optical Integration
Packet traffic can be transported over optical transport network.
The path computation in this case can be supported by coordinating
between Packet PCE and Optical PCE.
Zheng Expires August 2014 [Page 3]
draft-zheng-pce-for-SDN-transport-00 February 2014
This draft describes several classic scenarios in transport network,
to demonstrate the current PCE can be extended beyond path
computation functionality.
There is NO protocol extension (such as PCEP) in this draft. We only
focus on how current PCE (including RFCs and some WG/I-D Draft) can
satisfy the requirements.
2. Path Computation in Transport SDN
2.1. Transport SDN Architecture
A general architecture of transport SDN is shown as follow:
+-------------+
| Client |
| Controller |
+-------------+
/|\
|
\|/
+-------------------------+
|Transport +--------+ |
| Network | PCE | |
|Controller +--------+ |
+-------------------------+
/|\
|
\|/
+---------------------+
| Physical |
| Network |
| Infrastructure |
+---------------------+
Fig. 1 Generic Architecture of Transport SDN
As shown in Fig. 1, transport network controller (TNC) is core block
that connects with both clients and physical network infrastructure.
PCE is one of the functional blocks in the TNC for path computation.
In general, to request a transport service, client controller sends
a request with path requirement to TNC. PCE will compute a path
according to the request, and report the result to client.
For path establishment, the client will trigger the TNC and then TNC
will operate on the physical network infrastructure, for example,
network elements.
Zheng Expires August 2014 [Page 4]
draft-zheng-pce-for-SDN-transport-00 February 2014
2.2. Path computation and establishment
2.2.1 Stateless PCE
The PCE Protocol (PCEP) is the protocol that enables the
communication between Path Computation Clients (PCCs) and PCE. It
was firstly developed to support a stateless PCE with in [RFC4655].
PCCs will send path computation requests via the Path Computation
Request (PCReq) message to a Path Computation Elements (PCE). The
PCE, upon receiving this request, will calculate a path or multiple
paths and reply the result to the PCC via the Path Computation Reply
(PCRep) message. During the computation, the PCE has access to the
Traffic Engineering Database (TED). Network topology and resource
usage information are stored in the TED. Specific path computation
algorithms or policy-based routing schemes are out of scope for this
draft. Other details for PCEP can be referred to [RFC5440].
2.2.2 Stateful PCE
In stateless PCE the network information is managed in TED. However,
the state of active LSPs is not managed by PCE and as such there may
some limitations for real-time, dynamic LSP operations with
stateless PCE. With dynamic configuration and management request,
there will be resource contention problem in PCE. To address this
issue, stateful PCE is introduced in [draft-ietf-pce-stateful-pce-
07], with a LSP Database (LSPD) in the PCE. The LSPD allows
efficient LSP state synchronization between PCC and PCEs. A
delegation mode is proposed, with allowing PCC to delegate control
of its LSP to an active stateful PCE.
The stateful PCE can be applied in various scenarios, as presented
in [draft-ietf-pce-stateful-pce-app-01], including online
optimization, bandwidth scheduling, recovery and so on.
2.2.3 PCE Initiation
More dynamical management over LSP is proposed in [draft-ietf-pce-
pce-initiated-lsp-00], named as PCE initiation. In this mechanism,
PCE is able to trigger the creation of LSPs on demand, which is
especially suitable for a controller-based network in service
provisioning and path setup.
One of the typical applications for PCE initiation is the path
computing in SDN. When the request is generated from application
stratum, the PCE can compute the path and directly set it up,
instead of responding and triggering the application to establish
the connection. This new mechanism is more efficient than stateful
PCE and can provide better real-time performance in a dynamic
transport network.
Zheng Expires August 2014 [Page 5]
draft-zheng-pce-for-SDN-transport-00 February 2014
3. PCE Applicability for Transport SDN
Several applications are proposed under the transport SDN
arhictecture to demonstrate its ability to enhance the control and
management of transport networks, such as virtual transport
services, data center interconnection network and so on. For these
applications, PCE is playing an important role. In the following
sub-sections, we describe how the PCE and its protocol can support
applications in transport SDN via some typical examples.
3.1. Photonic Enterprise Networks
+---------+
| PCE |
+---------+
/ | \
/ | \
/ | \
/ | \
/ | \
+-----+ +-----+ +-----+
| NE1 | | NE2 | | NE3 |
+-----+ +-----+ +-----+
Fig. 2: PCE Control over Network Element
The enterprise networks are usually a small-scale network with
limited network elements. For simplicity, we assume in this use case
one PCE is enough for path computation, i.e., no multi-domain or
inter-PCE communication is involved. As shown in Fig. 2, NEs are
directly connected with PCE.
NEs can be but not limited to data centers. NEs are considered as
PCC to create request for path computation and establishment. PCEP
can be used for communication between PCCs and PCE, through the
interfaces between PCE and NEs. Stateful PCE is suited for this use
case for dynamic service provisioning, since the path is setup by
the PCC directly.
3.2. Virtualized Transport Network
Virtual transport service (VTS) is one of the advantages of
transport SDN. The architecture of providing VTS is described in Fig.
3.
Zheng Expires August 2014 [Page 6]
draft-zheng-pce-for-SDN-transport-00 February 2014
+------------+ +-----------+
| Client | | Client |
| Controller | ..... | Controller|
+------------+ +-----------+
/|\ /|\
| |
\|/ \|/
+--------------------------------------------------+
| | | |
| Transport +--------------------------------+ |
| Controller | Virtual Network Controller | |
| +--------------------------------+ |
| /|\ |
| +-------------+ |Provider Interface|
| | Other | \|/ |
| | Functional | +-------------+ |
| | Blocks | | PCE | |
| +-------------+ +-------------+ |
+-----------------------//-/---|-----\-------------+
// / | \
// / +--|--+ \
/ / | NE | \
// / +-----+ \
// / \
// / \
+-----/ / \
| NE | / +-\---+
+-----+ / | NE |
/ +-----+
/
+--/--+
| NE |
+-----+
Fig. 3: Architecture for VTS Provisioning
In this use case, the network elements are totally infrastructure
and we do not consider NE as PCC anymore. The path computation in
this case can be divided into two types: virtual path computation
and physical path computation.
The virtual path computation requests come from the client
controller and are sent to the virtualized network controller (VNC)
in the transport controller. Virtual network information such as
topology and available resources are stored in the VNC to determine
whether the requests can be satisfied or not and then respond the
Zheng Expires August 2014 [Page 7]
draft-zheng-pce-for-SDN-transport-00 February 2014
result to client controller. In this procedure, the VNC can be
treated as a PCE, and the interaction between client controller (PCC)
and VNC (PCE) is achieved via corresponding interface between PCC
and PCE.
The physical path computation is similar as described in section 3.1.
The PCE is connected with NEs for path computation. VNC projected
the virtual path request from client controller to a physical path
request and send it to PCE. The request is from the VNC via a
provider interface, which can be either considered as an internal
interface in transport controller or an external interface between
two blocks, depends on implementation policy. By receiving the
request, PCE will check the availability of resources and respond to
VNC, also via provider interface.
The path establishment can be completed by stateless PCE, stateful
PCE or PCE initiation. Stateless and stateful PCE will allocate the
physical resource by configuring the NEs after receiving the
corresponding message from PCC. In PCE initiation, dynamic creation
and teardown of LSPs are supported by PCE together with responding
LSP information to PCCs.
3.3. Data center interconnection
The virtual network services in Data Center Interconnection Network
are described in this section. As shown in Fig. 4, the DC controller
is connected with network provider controller, while DCs are
connected with NEs respectively.
In this use case it is assumed that Data center controller knows all
information, including endpoints interfaces, resource, location
information and any other application/user related information. For
the DC interconnection application, the client controller is the DC
controller, which can be an internal entity or an external entity
with respect to the relationship with the service provider.
Zheng Expires August 2014 [Page 8]
draft-zheng-pce-for-SDN-transport-00 February 2014
+------------+
| Data Center|
| Controller |
+------------+
/|\
|
\|/
+------------+
| Network |
| Provider |
| Controller |
+------------+
/|\
+---------+ | +----------+
| Data | | | Data |
|Center A | | | Center B |
+---------+ \|/ +----------+
\ ------------ /
\ //---- ----\\ /
\ /// \\\ /
\ /// +-----+ \\\ /
\ / | NE | \ /
\ // +-/---\\ \\ /
\ | / \\ | /
\ | / \\ /
\|+-----/ +----+ / \\ /|
|\| NE |-------| NE |/ +\\---+/ |
| +---\-+ +-|--+ | NE | |
| \ | +-----+ |
| \\ | |
| \ | Transport |
\\ \ | Network //
\ \+--/|-+ /
\\\ /| NE | ///
\\/ +-----+ ///
// \\---- ----//
/ ------------
+-----/----+
| Data |
| Center C |
+----------+
Fig. 4 Use case: Data Center Interconnection Network
In this use case the Network Provider Controller is playing as PCE
and DC controller is corresponding PCC. The requests can be either
from DC or the DC controller, with the DC controller have a full
visibility of all DCs. PCE is used to respond the path computation
request, to provide virtual network services. Stateless/Stateful PCE
and PCE initiation are all applicable in this case, similar as the
way described in Section 4.2. The communication between DC
controller and Network Provider Controller can also be implemented
via PCEP.
Zheng Expires August 2014 [Page 9]
draft-zheng-pce-for-SDN-transport-00 February 2014
3.4. Packet Optical Integration
+------------+
| Client |
| Controller |
+------------+
/|\
|
\|/
+------------------------------------------------+
| Network |
| Provider |
| Controller |
+------------------------------------------------+
/|\ /|\
| |
\|/ \|/
+---------------+ +---------------+
| Packet | | Optical |
| Network | | Network |
| Controller | | Controller |
+---------------+ +---------------+
/|\ /|\
| |
\|/ \|/
/----------\ /----------\
//// IP \\\\ //// Optical \\\\
| Packet | | Transport |
| Network | | Network |
\\\\ //// \\\\ ////
\----------/ \----------/
Fig. 5 Use Case: Packet Optical Integration
In this use case we describe packet traffic transported over an
optical transport server network (potentially incorporating multiple
layer networks), as shown in Fig. 5. The objective of this use case
is for packet and optical topologies to be jointly optimized for
greater efficiency, taking advantage of knowledge of topologies and
status, as well as dynamic capabilities supported by the optical
transport network.
There can be a few variations for path computation in this case,
depends on where the PCE is located. In this draft we assume that
there is one PCE located in Packet network controller and another
PCE located in Optical Network controller, respectively. A joint
optimization is applied by Network Provider controller, which is
connected with PCEs, for better resource utilization. Moreover,
client controller is also connected with network provider
controller.
In this case the path computation request is from the client
controller. All the three controllers has their respective TED and
LSPD (only if stateful or PCE initiation) and there are some
Zheng Expires August 2014 [Page 10]
draft-zheng-pce-for-SDN-transport-00 February 2014
synchronization mechanisms among them to guarantee the resource
consistency. Once the path computation request arrives the network
provider controller, it will be decomposed according to the network
topology and sent to the IP-PCE and Optical PCE respectively. The
IP-PCE and Optical PCE will then compute the path and respond.
The procedure of path establishment is similar as described in
section 4.2, which is applicable via stateless PCE, stateful PCE and
PCE initiation respectively. Communications among the controllers in
Fig. 5 can be achieved by PCEP.
4. IANA Considerations
5. References
5.1. Normative References
[RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path
Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[draft-ietf-pce-pce-initiated-lsp-00] Crabbe, E., Minei, I.,
Sivabalan, S., Varga. R, PCEP Extensions for PCE-initiated LSP Setup
in a Stateful PCE Model, draft-ietf-pce-pce-initiated-lsp-00,
December 2013.
[draft-ietf-pce-stateful-pce-app-01] Zhang, X., Minei, I.,
Applicability of Stateful Path Computation Element (PCE), draft-
ietf-pce-stateful-pce-app-01, September 2013.
[draft-ietf-pce-stateful-pce-07] Crabbe, E., Medved, J., Minei, I.,
and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-
stateful-pce-07 (work in progress), October 2013.
5.2. Informative References
[Openflow] Openflow Switch Specification,
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-
specifications/openflow/openflow-spec-v1.3.0.pdf
Zheng Expires August 2014 [Page 11]
draft-zheng-pce-for-SDN-transport-00 February 2014
6. Authors' Addresses
Haomian Zheng
Huawei Technologies
F3 R&D Center, Huawei Industrial Base,
Bantian, Longgang District,
Shenzhen 518129 P.R.China
Email: zhenghaomian@huawei.com
Xian Zhang
Huawei Technologies
F3 R&D Center, Huawei Industrial Base,
Bantian, Longgang District,
Shenzhen 518129 P.R.China
Email: zhang.xian@huawei.com
Zheng Expires August 2014 [Page 12]
