Network Working Group YL. Zhao
Internet-Draft J. Zhang
Intended status: Informational BUPT
Expires: April 22, 2011 RJ. Jing
China Telecom Beijing Research
Institute
DJ. Wang
XH. Fu
ZTE Corporation
October 19, 2010
Protocol Extension Requirement for Cooperation between PCE and
Distributed Routing Controller in GMPLS Networks
draft-zhaoyl-pce-dre-01
Abstract
Path Computation Element (PCE) and distributed routing controller in
GMPLS networks have different advantages of path computation
respectively. PCE is suitable for the path computation in multi-
layer and multi-domain networks, especially in multi-constraints
environment. While distributed routing controller is good at the
path computation in parallel and distributed network control in the
local domain. A cooperative path computation architecture named Dual
Routing Engine (DRE) is proposed, which is based on the two path
computation engines and can combine the advantages of centralized and
distributed. The corresponding PCE communication protocol extension
and other protocol requirements for cooperation between PCE and
distributed routing controller are listed in this document.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2011.
Zhao, et al. Expires April 22, 2011 [Page 1]
Internet-Draft Cooperation between PCE and DRC October 2010
Copyright Notice
Copyright (c) 2010 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5
4. Cooperative Architecture based on PCE and Distributed
Routing Controller . . . . . . . . . . . . . . . . . . . . . . 6
4.1. DRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Different Application Scenarios . . . . . . . . . . . . . . . 8
5.1. Cross layers and cross domains . . . . . . . . . . . . . . 8
5.2. Independent coexistence . . . . . . . . . . . . . . . . . 8
5.3. Security backup . . . . . . . . . . . . . . . . . . . . . 8
5.4. Policy-enabled . . . . . . . . . . . . . . . . . . . . . . 8
5.5. Constraint-based . . . . . . . . . . . . . . . . . . . . . 9
5.6. Service-oriented . . . . . . . . . . . . . . . . . . . . . 9
5.7. Cooperation between network level and node level . . . . . 9
6. PCEP Extension Requirements . . . . . . . . . . . . . . . . . 10
6.1. PCEP extension requirement for the communication
between RES and PCE . . . . . . . . . . . . . . . . . . . 10
6.2. PCEP extension requirement for the communication
between RES and DRC . . . . . . . . . . . . . . . . . . . 11
7. Other Protocol Extension Requirements . . . . . . . . . . . . 11
7.1. OSPF-TE extension requirement for the cooperative
architecture . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. RSVP-TE extension requirement for the cooperative
architecture . . . . . . . . . . . . . . . . . . . . . . . 12
8. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Zhao, et al. Expires April 22, 2011 [Page 2]
Internet-Draft Cooperation between PCE and DRC October 2010
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Zhao, et al. Expires April 22, 2011 [Page 3]
Internet-Draft Cooperation between PCE and DRC October 2010
1. Introduction
Path Computation Element (PCE) is proposed to complete the
constraint-based shortest path computation in Multi-protocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) multi-layer and multi-
domain networks [RFC4665]. Then a series of Request for Comments
(RFCs) related to PCE technology, such as requirements for PCE
discovery, PCE Communication Protocol (PCEP), a backward recursive
PCE-based computation procedure (BRPC) and so on, have been
standardized. Studies prove that PCE is suitable for cross-layer and
cross-domain design of networks, capable of end-to-end path
computation under multiple constraints [1-2] and potentially applied
to resource allocation and routing optimization [3-4]. While
traditional distributed routing controller (DRC) in GMPLS/ASON
control plane is good at the path computation in parallel and
distributed network control in the local domain. On the other hand,
as the huge bandwidth requirement emerges, capacity of Tbit/s
transmission links and Pbit/s switching are necessary for next
generation optical networks. According to the current photonics
technology level, the node architecture will be very complicated and
of large power consumption. Then how to configure the switching
architecture in the node will be very important for the entire
network performance. DRC can also be used for the management and
configuration of resource in the internal node. Of course, both PCE
and DRC have corresponding different disadvantages respectively.
In order to optimize the performance of optical networks under
different application scenarios, PCE and distributed routing
controller need to cooperate with each other. A cooperative path
computation architecture named Dual Routing Engine (DRE) is proposed,
which includes two path computation engines, i.e. PCE and
distributed routing controller, and can combine their advantages.
Several different application scenarios are described in this
document. PCE communication protocol extension and other protocol
extension requirements for cooperation between PCE and distributed
routing controller are listed here.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Terminologies
LSR: Label Switching Router.
Zhao, et al. Expires April 22, 2011 [Page 4]
Internet-Draft Cooperation between PCE and DRC October 2010
LSP: Label Switched Path.
PCC: Path Computation Client. Any client application requesting a
path computation to be performed by the Path Computation Element.
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.
PCEP: PCE Communication Protocols, the communication protocol between
PCC and PCE.
DRC: Distributed Routing Controller, the module that can complete
path computation in the local domain or the internal node.
DRE: Dual Routing Engine, including PCE and DRC.
TED: Traffic Engineering Database.
RID: Resource Information Databases.
3. General Assumptions
PCE and distributed routing controller are two path computation
engines which have been standardized by IETF working group. They can
both complete the path computation in GMPLS networks. In order to
show how the cooperative architecture based on PCE and distributed
routing controller works, we make some assumptions as follows.
o Each GMPLS-based control node is equipped with a distributed
routing controller which can complete the path computation in the
local domain, even the path computation and resource configuration
in the internal node, and each domain is equipped with no less
than one PCE which cannot only complete the intra-domain path
computation, but also complete the inter-domain path computation.
o The topology and TE information are updated as soon as any change
occurs in the network, and the information kept at PCE and
distributed routing controller are synchronized by OSPF-TE.
o PCE and distributed routing controller can be selected arbitrary
according to the local routing strategy.
o Constraints and strategies can be considered by PCE during the
process of path computation including the intra-domain path and
inter-domain path.
Zhao, et al. Expires April 22, 2011 [Page 5]
Internet-Draft Cooperation between PCE and DRC October 2010
o An end-to-end path which crosses domains or crosses layers can be
completed by several PCEs or several DRCs or several PCEs and
DRCs. For example, the section of an end-to-end path in one
domain may be computed by PCE, but the section of this path in
another domain may be computed by DRC.
4. Cooperative Architecture based on PCE and Distributed Routing
Controller
As shown in Fig. 1, cooperative architecture consists of Path
Computation Element (PCE) and distributed routing controller (DRC).
Both of them maintain Traffic Engineering Databases (TEDs) to keep
network topology and other status information within the scope of
their respective functions. There is a function module named Routing
Engine Selector (RES) at each control node, which is responsible for
managing the switchover process between PCE and DRC and choosing the
right one while a LSP setup request arrives. At the same time, RES
posses the function of PCC and can be implemented in Connection
Controller (CC) module of GMPLS-based control plane.
------- -------
| PCE |-------------------------| PCE |
------- -------
/|\ /|\
/ | \ / | \
/ | \ / | \
-----------/---|---\---------- ----------/---|---\----------
| / ------- \ | | / ------ \ |
| / | RES | \ | | / | RES | \ |
| / ---|--- \ | | / ---|--- \ |
| / /---|---\ \ | | / /---|---\ \ |
| / /| DRC |\ \ | | / /| DRC |\ \ |
| / / ------- \ \ | | / / ------- \ \ |
| / / \ \ | | / / \ \ |
| / / \ \ | | / / \ \ |
| / / \ \ | | / / \ \ |
| ------- ------- | | ------- ------- |
| | RES |-----------| RES |-----| RES |-----------| RES ||
| ---|--- ---|--- | | ---|--- ---|--- |
| ---|--- ---|--- | | ---|--- ---|--- |
| | DRC | | DRC || || DRC | | DRC ||
| ------- ------- | | ------- ------- |
| domain A | | domain B |
------------------------------ -----------------------------
Fig.1 Cooperative architecture in multi-layer and multi-domain
Zhao, et al. Expires April 22, 2011 [Page 6]
Internet-Draft Cooperation between PCE and DRC October 2010
networks
4.1. DRC
DRC offers general routing functions based on GMPLS/ASON control
plane including link state advertisement, topology update and path
computation. A typical DRC contains two essential modules which are
topology analysis module and path computer module. The former floods
network topology and resource utilization information to maintain a
TED in each node. The latter responds to a routing request from
Connection Controller (CC), finds the optimized path solution and
returns it to CC. Except the general routing functions, DRC can also
complete the resource allocation and configuration, which refers to
internal resource allocation, ports interconnection, and switch
fabric configuration in the internal node. This function is getting
more and more important with the structure of the internal node
getting more and more complex. Details of DRC operation are out of
this document.
4.2. PCE
PCE has the advantage of centralized path computation especially in
multi-layer and multi-domain networks, especially in multi-
constraints environment. There is a Client/Server model between RES
and PCE. RES sends a TE-LSP computation request to PCE. PCE
performs path computation and returns the results back to RES.
Firstly RES makes choice of the best PCE based on a certain policy.
It sends performance query requests to multiple related PCEs, each of
which evaluates itself individually and then feeds back to the RES.
RES gathers performance status information from PCEs and decides
which one is feasible. Then a combination of RES and PCE is founded.
Secondly PCE serves to deal with the path computation requests coming
from RES through message parser. If a request carries path
information, it will be directed towards path computer. If it
carries policy information from RES, it is first interpreted by
policy parser along with local policy settings and then loaded into
path computer. Finally path computer implements multi-constraint
routing on the basis of the path information, policy information and
TE information. If path computation is successful the details of the
whole route are returned to RES. If it only gets an incomplete route
a new application for path computation request will be sent to the
next hop RES. Then a PCE or DRC will be selected to complement the
incomplete route.
Zhao, et al. Expires April 22, 2011 [Page 7]
Internet-Draft Cooperation between PCE and DRC October 2010
5. Different Application Scenarios
Cooperation between PCE and DRC is one of the key issues for the
cooperative architecture, which helps to achieve fast and exact
routing due to the advantages of both PCE and DRC. This section will
list several typical application scenarios of cooperation between PCE
and DRC.
5.1. Cross layers and cross domains
It is necessary for PCE to collaborate with DRC when the requirements
for path computation occur in multi-layer and multi-domain GMPLS
networks. PCE could be shared among several domains or layers and
make the best use of the inter-domain and inter-layer network
resources, so it is more suitable for inter-domain or inter-layer
path computation. DRC runs usually to fulfill intra-domain or intra-
layer routing in contrast to PCE.
5.2. Independent coexistence
Both PCE and DRC are working independently under this scenario.
While one customer applies a TE-LSP computation RES could select PCE
or DRC arbitrarily. Of course only one path computation engine can
be selected at each time. If a lot of applications for path
computation arrive simultaneously, the burst computing load may be
also balanced between them. The changed topology and resource status
information have to be maintained in PCE and DRC. So it is difficult
for the management of information synchronization on both sides.
5.3. Security backup
The cooperation mechanisms among different engines make it possible
that PCE and DRC backup each other to enhance the routing security
and reliability, since they both satisfy the demands of path
computation from customers. When the working engine (e.g. PCE)
fails, computation tasks could be switched to another reserved engine
(e.g. DRC) as soon as possible. In such a case both PCE and DRC
have to maintain the accordant network topology and resource status
information.
5.4. Policy-enabled
In order to compute the optimal path in consideration of traffic
engineering, different policies which mean series of rules and
actions from management plane or control plane are involved. PCE is
obviously more suitable for policy-enabled path computation framework
than DRC. Tab.1 lists some typical policy application instances that
may be exerted to the cooperative path computation architecture.
Zhao, et al. Expires April 22, 2011 [Page 8]
Internet-Draft Cooperation between PCE and DRC October 2010
Effective combinations of the above scenarios as well as possible new
scenarios could occur in the real networks.
+------------------------+------------------------------------------+
| Policy application | Description |
| scenarios | |
+------------------------+------------------------------------------+
| Policy configured | To centrally administer configured paths |
| paths | |
| Provider selection | To be applied in multi-provider |
| policy | topologies |
| Policy based | To provide constraints in a path |
| constraints | computation request |
| Advanced load | To balance the traffic load for the |
| balancing | whole network |
+------------------------+------------------------------------------+
Policy-enabled path computation instances
Table 1
5.5. Constraint-based
Constraint-based path computation is a basic function especially for
TE-LSP establishment. Available bandwidth, diversity, Shared Risk
Link Group (SRLG), optical impairments, wavelength continuity and
other constraints are likely to be considered. However, it is
difficult to compute an optimal path with these constraints under the
condition of the general GMPLS/ASON routing architecture. The
centralized operation manner makes PCE easy to fulfill constraint-
based path computation.
5.6. Service-oriented
PCEs can collaborate to finish constraint-based path computation
without sharing TE information with each other, which are
particularly useful when end-to-end constraints have to be taken into
account because of protection and path diversity. PCEs should play
an important role of service-oriented applications such as Layer 1
Virtual Private Network (L1 VPN), Bandwidth on Demand (BoD) and so
on. Based on GMPLS/ASON architecture, the advantages of PCE and
service plane can be combined to implement the framework of service-
oriented application.
5.7. Cooperation between network level and node level
In this application scenario, PCE maintains Traffic Engineering
Databases (TEDs) to keep network topology, and DRC maintains Resource
Zhao, et al. Expires April 22, 2011 [Page 9]
Internet-Draft Cooperation between PCE and DRC October 2010
Information Databases (RIDs) to keep node internal topology and
resource status. Both of them maintain the status information within
the scope of their functions. Routing Engine Selector (RES) is
responsible for managing the switchover process between PCE and DRC
and choosing the right one when a LSP setup request arrives.
The interconnection between different nodes is general routing
problem, which can be solved by PCE framework effectively, especially
in multi-domain, multi-layer and multi-constraints scenarios, while
the interconnection within the node is the problem of resource
allocation and configuration, which refers to internal resource
allocation, ports interconnection, and switch fabric configuration.
Through the cooperation of PCE and DRC, we can make resource
configuration more effectively and improve the performance of the
entire optical networks.
6. PCEP Extension Requirements
As an extension of PCC, RES can not only complete the communication
with PCE and DRC, but also complete the cooperation between PCE with
DRC. There are some PCEP extension requirements for the cooperative
path computation architecture and the procedure.
6.1. PCEP extension requirement for the communication between RES and
PCE
PCEP is the communication protocol between RES and PCE. However,
there is some extension requirement for PCEP in the cooperative path
computation architecture.
Firstly, the path computation request messages from RES to PCE should
be added an identification which appoints different application
scenarios, and the corresponding data structure should be defined
according to different identifications. For example, in the policy-
enabled scenario, a policy object is necessary to be defined in the
message sent from RES to PCE, and PCE should be able to parse the
different policies and conduct the corresponding operations during
the procedure of path computation.
Secondly, in the reply message from PCE to RES, some indication
information should be contained except the routes information, such
as the inter-domain loose path or the intra-domain path, the complete
end-to-end path or section path, some failure information and path
computation engine switchover requests.
Zhao, et al. Expires April 22, 2011 [Page 10]
Internet-Draft Cooperation between PCE and DRC October 2010
6.2. PCEP extension requirement for the communication between RES and
DRC
DRC can complete the path computation in the local domain in
distributed method, which is usually implemented in the OSPF-TE
module of GMPLS-based control plane. After the path computation, DRC
returns the computation results to RES (CC) including the detailed
routes and some failure or indication information.
As another important application, DRC can complete the path
computation, resource management and configuration in the internal
node with the node structure getting more and more complex. In this
application scenario, DRC has the function of routing and resource
allocation.
In all the application scenarios, DRC has the analogous functions
with PCE and some different extension functions, such as the
functions above. So there is requirement for application scenarios
identification in the communication message between RES and DRC. The
communication protocol between RES and DRC is necessary to be
standardized as the function of control node getting more and more
complex. Because RES and DRC are implemented in the same control
node and DRC has similar functions with PCE, then a simplified PCEP
can be used as the communication protocol between RES and DRC, which
can include the path computation request, identification and reply
messages only.
7. Other Protocol Extension Requirements
7.1. OSPF-TE extension requirement for the cooperative architecture
In the cooperative path computation architecture, the topology and TE
information should be kept and synchronized at each control node and
PCE in the local domain, and should also be updated as soon as any
change occurs. Meanwhile, all the inter-domain links and TE
information should be kept and synchronized at each PCE. So there is
extension requirement for OSPF-TE to guarantee the information at
each node synchronized in time.
Except the normal topology and TE information, some other constraints
information may be necessary to be contained in the OSPF-TE protocol
flooding in the entire networks, such as the physcial impairment
information. Then there is an extension requirement for the OSPF-TE
protocol to enable the synchronization of all the constraint
information at each node, which is of great value for the path
computation and resource allocation.
Zhao, et al. Expires April 22, 2011 [Page 11]
Internet-Draft Cooperation between PCE and DRC October 2010
7.2. RSVP-TE extension requirement for the cooperative architecture
In different cooperation modes between PCE and DRC, an end-to-end
path may be computed by several PCE and DRC, and then be setup by
signaling from the source node to the destination node. However,
sometimes an end-to-end path which crosses domains or layers may be
computed and setup section by section. Signaling should be triggered
when a section path is gained. The current RSVP-TE protocol is
necessary to be extended to support this application scenario.
Furthermore, as the scheme of path and resource allocation in the
internal node is gained, the resource reservation and action of
switches are to be conducted by some protocol as the control node is
getting more and more complex. RSVP-TE is the optimal option for
this function, and to be extended.
8. Discussions
According to the development of GMPLS networks, the cooperative
architecture can be introduced in two steps. First, PCE and DRC can
cooperate with each other to complete the path computation of the
entire networks at network level. Second, PCE and DRC can cooperate
with each other to complete the path computation at network level and
resource computation and allocation at node level with the network
size increasing and node structure getting complex.
9. Security Considerations
The cooperation between PCE and DRC can enhance the security of
networks because they can backup each other. However, because the
information is kept at both PCE and each DRC, especially the exchange
of information across domain boundaries is necessary in the multi-
domain operation, there is some security and confidentiality risk,
which can inherits the security requirement defined [RFC5440] and
[RFC5376].
10. Acknowledgments
The RFC text was produced using Marshall Rose's xml2rfc tool.
11. References
Zhao, et al. Expires April 22, 2011 [Page 12]
Internet-Draft Cooperation between PCE and DRC October 2010
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC4665] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
11.2. Informative References
[1] Nishioka, Itaru., "End-to-End path routing with PCEs in
multi-domain GMPLS networks", July 2008.
[2] Jabbari, Bijan., "On Constraints for Path Computation in
Multi-Layer Switched Networks", August 2007.
[3] Giorgetti, A. and F. Paolucci, "Routing and Wavelength
Assignment in PCE-based Wavelength Switched Optical
Networks", September 2008.
[4] Hayashi, Michiaki., "Advance Reservation-Based Network
Resource Manger for Optical Networks", February 2008.
Authors' Addresses
Yongli Zhao
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613811761857
Email: yonglizhao@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Jie Zhang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613911060930
Email: lgr24@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Zhao, et al. Expires April 22, 2011 [Page 13]
Internet-Draft Cooperation between PCE and DRC October 2010
Ruiquan Jing
China Telecom Beijing Research Institute
118 Xizhimenwai Avenue
Beijing 100035
P.R.China
Phone: +86-10-58552000
Email: jingrq@ctbri.com.cn
URI: http://www.ctbri.com.cn/
Dajiang Wang
ZTE Corporation
No.16,Huayuan Road,Haidian District
Beijing 100191
P.R.China
Phone: +8613811795408
Email: wang.dajiang@zte.com.cn
URI: http://www.zte.com.cn/
Xihua Fu
ZTE Corporation
West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District
Xi'an 710065
P.R.China
Phone: +8613798412242
Email: fu.xihua@zte.com.cn
URI: http://www.zte.com.cn/
Zhao, et al. Expires April 22, 2011 [Page 14]