Network Working Group Y. Lee
Internet-Draft Huawei Technologies (USA)
Intended status: Standards Track D. King
Expires: April 14, 2007 Aria Networks
E. Oki
NTT
October 11, 2006
Path Computation Element Communication Protocol (PCECP) Requirements for
Support of Global Concurrent Optimization
draft-lee-pce-global-concurrent-optimization-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 April 14, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Lee, et al. Expires April 14, 2007 [Page 1]
Internet-Draft PCE Global Concurrent Optimization October 2006
Abstract
The Path Computation Element (PCE) is a network component,
application, or node that is capable of performing path computations
at the request of Path Computation Clients (PCCs). The PCE is
applied in Multiprotocol Label Switching Traffic Engineering
(MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
determine the routes of Label Switched Paths (LSPs) through the
network.
The Path Computation Element Communication Protocol (PCECP) is
specified for communications between PCCs and PCEs, and between
cooperating PCEs. This document provides application-specific
requirements for the PCECP in support of a large-scale concurrent
path computation application.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability for Global Concurrent Path Computation . . . . . 6
3.1. Greenfield Traffic Engineering . . . . . . . . . . . . . . 6
3.2. Re-optimization of Existing Networks . . . . . . . . . . . 6
3.2.1. Traffic Migration . . . . . . . . . . . . . . . . . . 6
3.3. Multi-layer Traffic Engineering . . . . . . . . . . . . . 7
3.4. Reconfiguration of the Virtual Network Topology (VNT) . . 7
3.5. The PCE Application Architecture . . . . . . . . . . . . . 7
4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Lee, et al. Expires April 14, 2007 [Page 2]
Internet-Draft PCE Global Concurrent Optimization October 2006
1. Terminology
The terminology explained herein complies with [RFC4655].
PCC: Path Computation Client: Any client application requesting a
path computation to be performed by a 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.
TED: Traffic Engineering Database which contains the topology and
resource information of the domain. The TED may be fed by IGP
extensions or potentially by other means.
PCECP: The PCE Communications Protocol that is used to communicate
path computation requests from PCCs to a PCE, and to return computed
paths from the PCE to the PCCs. The PCECP can also be used between
cooperating PCEs.
Although this is not a protocol specification, 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 RFC 2119 [RFC2119] for clarity of
specification of requirements.
Lee, et al. Expires April 14, 2007 [Page 3]
Internet-Draft PCE Global Concurrent Optimization October 2006
2. Introduction
[RFC4655] defines the PCE Architecture and explains how a PCE may
compute the paths of Multiprotocol Label Switching Traffic
Engineering (MPLS-TE) and Generalized MPLS (GMPLS) Label Switched
Paths (LSPs) at the request of PCCs. A PCC is shown to be any
network component that makes such a request and may be a Label
Switching Router (LSR) or a Network Management Station (NMS). The
PCE, itself, is shown to be located anywhere within the network, and
may be within an LSR, an NMS or Operational Support System (OSS), or
may be an independent network server.
The PCECP is the communications protocol used between PCC and PCE,
and may also be used between cooperating PCEs. [RFC4657] sets out
the common protocol requirements for the PCECP. Additional
application-specific requirements for PCECP are deferred to separate
documents.
This document provides the PCECP extension requirements in support of
a large-scale concurrent path computation application that may arise
during network operations. A large-scale concurrent path computation
is a path computation application where a large number of TE paths
need to be computed concurrently in order to efficiently utilize
network resources. The computation method involved with a large-
scale concurrent path computation is referred to as global concurrent
optimization in this document. Appropriate computation algorithms to
perform this type of optimization are out of scope of this document.
As new LSPs are added sequentially or removed from the network over
time, the global network resources become fragmented and the network
no longer provides the optimal use of the available capacity. A
large-scale global concurrent path computation would be able to
simultaneously consider the entire topology of the network and the
complete set of existing LSPs, and their respective constraints, and
look to re-optimize the entire network to satisfy all constraints for
all LSPs.
The need for large-scale concurrent path computation may also arise
when network operators need to set up a large number of TE LSPs in
their network planning process. All large-scale path computation is
typically an off-line computation. This document does not exclude
the possibility that network operators might require on-line
computation for large-scale concurrent path computation in the event
of catastrophic network failures, where large numbers of TE LSPs need
to be optimally rerouted in real-time.
The off-line computation requirements to support a large number of TE
LSPs are quite different from on-line path computation requirements.
Lee, et al. Expires April 14, 2007 [Page 4]
Internet-Draft PCE Global Concurrent Optimization October 2006
While on-line path computation is focused on finding a single best
path in a timely manner given the prevailing network conditions, a
large-scale off-line path computation application involves finding
paths for a large number of TE LSPs concurrently to meet a global
objective. While off-line computation may not require such stringent
time constraints as on-line path computation, the key objective
associated with large-scale off-line computation is to efficiently
allocate network resources from a global network perspective. While
on-line path computation is tactical, off-line large-scale path
computation is strategic.
As the PCE is envisioned to provide solutions in all path computation
matters, it is anticipated that the PCE would provide solutions for
large-scale global concurrent path computation needs.
Specific algorithms that the PCE may employ are beyond the scope of
this document. The main focus of this document is to highlight the
PCC-PCE communication needs in support of a large-scale concurrent
path computation application.
The PCE-PCC requirements addressed herein are specific to the context
where the PCE is a specialized PCE that is capable of solving large-
scale concurrent path computation applications. Discovery of such
capabilities might be desirable and could be achieved through
extensions to the PCE discovery mechanisms [PCE-DISCO], but that is
out of the scope of this document.
Lee, et al. Expires April 14, 2007 [Page 5]
Internet-Draft PCE Global Concurrent Optimization October 2006
3. Applicability for Global Concurrent Path Computation
This section discusses scenarios for which global concurrent path
computation may be applied. It also discusses how these scenarios
apply to the PCE architecture.
3.1. Greenfield Traffic Engineering
When a new TE network needs to be provisioned from a green-field
perspective, large numbers of TE LSPs need to be created based on
traffic demand, network topology, service constraints, and network
resources. Under this scenario, concurrent computation ability is
highly desirable, or required, to utilize network resources in an
optimal manner. Sequential path computation could potentially result
in sub-optimal use of network resources.
3.2. Re-optimization of Existing Networks
The need for global concurrent path computation may also arise in
existing networks. When an existing TE LSP network experiences sub-
optimal use of its resources, the need for re-optimization or
reconfiguration may arise. The scope of re-optimization and
reconfiguration may vary depending on particular situations. The
scope of re-optimization may be limited to bandwidth modification to
an existing TE LSP. However, it could well be that a large number of
TE LSPs may need to be re-optimized concurrently. In an extreme
case, the TE LSPs may need to be globally re-optimized. Note that
sequential re-optimization of such TE LSPs is unlikely to produce
substantial improvements in overall network optimization except in
very sparsely utilized networks.
3.2.1. Traffic Migration
When migrating from one set of TE LSPs to a reoptimized set of TE
LSPs it is important that the traffic be moved without causing
disruption. Various techniques exist in MPLS and GMPLS, such as make
before break [RFC3209], to establish the new LSPs before tearing down
the old LSPs. When multiple LSP routes are changed according to the
computed results, some of LSPs may be disrupted due to the resource
constraints. Make-before-break action can be considered. PCE may be
able to give NMS the orders of LSP rerouting action so that make-
before-break can be performed within the limited resources.
However, it may be the case that the reoptimization is radical. This
could mean that it is not possible to apply make before break in
order to migrate from the old LSPs to the new LSPs. In this case a
migration strategy is required. A PCE might indicate the order in
which reoptimized LSPs must be established and take over from the old
Lee, et al. Expires April 14, 2007 [Page 6]
Internet-Draft PCE Global Concurrent Optimization October 2006
LSP, or the PCE might perform the global reoptimization as a series
of sub-reoptimizations.
3.3. Multi-layer Traffic Engineering
When an optical transport layer provides lower-layer traffic
engineered LSPs for upper-layer client LSPs via the Hierarchical LSP
(H-LSP) mechanism, the operator may desire to pre-establish optical
LSPs in the optical transport network [MLN-REQ], this whole
multilayer network can be managed using PCE [PCE-MLN]. In this
scenario, it is anticipated that a large number of H-LSPs would be
created concurrently in such a way as to efficiently utilize network
resources in the lower-layer network. Again, concurrent path
computation capability would result in more efficient network
resource utilization than sequential path computation.
3.4. Reconfiguration of the Virtual Network Topology (VNT)
A set of one or more of lower-layer LSPs providing information for
efficient path handling in upper-layer(s) can be described as a
virtual network topology (VNT)[MLN-REQ].
Reconfiguration of the VNT [MLN-REQ] is another application scenario
where global concurrent path computation may be applicable. Triggers
for VNT reconfiguration, such as traffic demand changes, network
failures, and topological configuration changes, may require a large
set of existing LSPs to be re-computed. Again, concurrent path
computation capability would result in more efficient network
resource utilization than sequential path computation.
3.5. The PCE Application Architecture
Figure 1 shows how the aforementioned functionality applies to the
PCE architecture. It must be observed that the PCC is not
necessarily an LSR [RFC4655]. Although Figure 1 shows the PCE as
remote from the NMS, it might be collocated with the NMS.
Upon receipt of an application request (e.g., traffic demand matrix
is provided to the NMS by operator's planning procedure), the NMS
requests a global concurrent path computation to the PCE. The PCE
would then compute the requested paths concurrently applying some
algorithm(s). When the requested path computation completes, the PCE
would then send the resulting paths back to the NMS. The NMS would
supply the the head-end LSR with a fully computed explicit path for
each TE LSP that needs to be established.
Lee, et al. Expires April 14, 2007 [Page 7]
Internet-Draft PCE Global Concurrent Optimization October 2006
-----------
Application | ----- |
Request | | TED | |
| | ----- |
v | | |
------------- Request/ | v |
| | Response| ----- |
| NMS |<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
Figure 1
Lee, et al. Expires April 14, 2007 [Page 8]
Internet-Draft PCE Global Concurrent Optimization October 2006
4. PCECP Requirements
This section provides the PCECP requirements in support of a large-
scale concurrent path computation application. The requirements
specified herein should be regarded as application-specific
requirements and are justifiable based on the extensibility clause
found in section 6.1.14 of [RFC4657]:
The PCECP MUST support the requirements specified in the application-
specific requirements documents. The PCECP MUST also allow
extensions as more PCE applications will be introduced in the future.
It is also to be noted that some of the requirements discussed in
this section have discussed in the PCECP requirement document
[RFC4657]. For example, Section 5.1.16 in [RFC4657] provides a list
of generic constraints while Section 5.1.17 in [RFC4657] provides a
list of generic objective functions that MUST be supported by the
PCECP. While using such generic requirements as the baseline, this
section provides application-specific requirements in the context of
global concurrent path computation.
The PCECP SHOULD support the following capabilities either via
creation of new objects and/or modification of existing objects where
applicable.
o An indicator to convey that the request is a global concurrent
path computation. This indicator is necessary to ensure
consistency in applying global objectives and global constraints
in all path computations.
o Global Objective Function (GOF) field in which to specify the
global objective function. The global objective function is the
overarching objective function to which all individual path
computation requests are subjected in order to find a globally
optimal solution. A list of available global objective functions
SHOULD include the following objective functions at the minimum
and SHOULD be expandable for future addition:
* Minimize the sum of all TE LSP costs (min cost)
* Minimize the most utilized TE LSP (min max utilization)
o Global Constraints (GC) field in which to specify the list of
global constraints to which all the requested path computations
should be subjected. This list SHOULD include the following
constraints at the minimum and SHOULD be expandable for future
addition:
Lee, et al. Expires April 14, 2007 [Page 9]
Internet-Draft PCE Global Concurrent Optimization October 2006
* Maximum link utilization parameter indicators for all links
(Note: to avoid floating point number, indicators may be
integer values that indicate maximum link utilization to which
all links should be subjected. Granularity and other details
are subject to further study)
* Minimum link utilization parameter indicators for all links
(Note: same as above)
* Maximum number of hops for all the LSPs
* Exclusion of links/nodes in all LSP path computation (i.e., All
LSPs should not include the specified links/nodes in the path)
* An indication should be available in a path computation
response that further reoptimization may only become available
once existing traffic has been moved to the new LSPs.
* A list of existing or known TE LSPs should be kept intact
without any modification, i.e. LSPs that are not subject to
reoptimization computation. This capability would be useful in
minimizing disruption when a global reconfiguration may need to
takes place.
o Global Concurrent Vector (GCV) field in which to specify all the
individual path computation requests that are subject to
concurrent path computation and subject to the global objective
function and all of the global constraints.
o An indicator field in which to indicate the outcome of the
request. When the PCE could not find a feasible solution with the
initial request, the reason for infeasibility SHOULD be indicated.
The following indicators SHOULD be supported at the minimum:
* no feasible solution found
* memory overflow
* PCE too busy
* PCE not capable of concurrent reoptimization
* no data migration path available
* administrative privileges do not allow global reoptimization
Lee, et al. Expires April 14, 2007 [Page 10]
Internet-Draft PCE Global Concurrent Optimization October 2006
o Multi-Session Indicator field in the case where the original
request is sub-divided into multiple sessions. This case may
arise when the reason for infeasibility of the original request is
due to mathematically infeasible, or due to memory overflow, the
PCC may follow up with subsequent actions under a local policy.
The PCC may decide to scale down the original request into several
sessions and make requests to the PCE in several sessions. The
reason for this is to find a partial feasible solution in the
absence of optimal solution.
* Multi-Session Indicator
* The list of existing TE LSPs that should be kept without any
modification. Note that this may be indicated in the
aforementioned Global Constraints (GC) field. During multiple
sessions of path computation, the successfully computed paths
from the PCE to the PCC in a session should be indicated as the
constraint (i.e., as the TE LSPs that should be kept) in the
next session computation by the PCE so that the PCE may avoid
double booking. If the PCE is stateless PCE, this indication
is essential.
Lee, et al. Expires April 14, 2007 [Page 11]
Internet-Draft PCE Global Concurrent Optimization October 2006
5. Security Considerations
When global re-optimization is applied to an active network, it could
be extremely disruptive. Although the real security and policy
issues apply at the NMS, if the wrong results are returned to the
NMS, the wrong actions may be taken in the network. Therefore, it is
very important that the operator issuing the commands has sufficient
authority and is authenticated, and that the computation request is
subject to appropriate policy.
Lee, et al. Expires April 14, 2007 [Page 12]
Internet-Draft PCE Global Concurrent Optimization October 2006
6. Acknowledgements
We would like to thank Adrian Farrel, Jerry Ash and Lucy Yong for
their useful comments and suggestions.
Lee, et al. Expires April 14, 2007 [Page 13]
Internet-Draft PCE Global Concurrent Optimization October 2006
7. IANA Considerations
There are no IANA actions requested in this specification.
Lee, et al. Expires April 14, 2007 [Page 14]
Internet-Draft PCE Global Concurrent Optimization October 2006
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
8.2. Informative References
[MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi-
region and multi-layer networks (MRN/MLN)",
draft-ietf-ccamp-gmpls-mln-reqs, work in progress.
[PCE-DISCO]
Le Roux, J., "Requirements for Path Computation Element
(PCE) Discovery", draft-ietf-pce-discovery-reqs, work in
progress.
[PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE-
based inter-layer MPLS and GMPL traffic engineering",
draft-ietf-pce-inter-layer-frwk, work in progress.
Lee, et al. Expires April 14, 2007 [Page 15]
Internet-Draft PCE Global Concurrent Optimization October 2006
Authors' Addresses
Young Lee
Huawei Technologies (USA)
1700 Alma Drive, Suite 100
Plano, TX 75075
US
Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397
Email: ylee@huawei.com
Daniel King
Aria Networks
44/45 Market Place
Chippenham SN15 3HU
United Kingdom
Phone: +44 7790 775187
Fax: +44 1249 446530
Email: daniel.king@aria-networks.com
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585
JAPAN
Email: oki.eiji@lab.ntt.co.jp
Lee, et al. Expires April 14, 2007 [Page 16]
Internet-Draft PCE Global Concurrent Optimization October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Lee, et al. Expires April 14, 2007 [Page 17]