Network Working Group Kexin Tang
Internet-Draft Zhihong Wang
Intended status: Informational Yuanlin Bao
Expires: April 28, 2011 Xuerong Wang
Gang Lu
ZTE Corporation
Oct 25, 2010
Stateful PCE
draft-tang-pce-stateful-pce-01.txt
Abstract
A PCE can be either stateful or stateless. The information carried
in stateful PCE are more detailed than that of stateless PCE. With
the state capability of PCEs, the PCCs may make advanced and informed
choices about the PCEs to use. This draft focus on stateful PCE,
describes the applicability of stateful PCE and gives the IGP and
PCEP extensions to support stateful PCE.
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 28, 2011.
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
Kexin Tang, et al. Expires April 28, 2011 [Page 1]
Internet-Draft Stateful PCE Oct 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability of stateful PCE . . . . . . . . . . . . . . . . . 4
3.1. stateful PCE in support of GCO . . . . . . . . . . . . . . 4
3.2. stateful PCE in support of resources restoration . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. PCE Discovery and PCEP Extensions . . . . . . . . . . . . . . . 6
5.1. PCED Extensions . . . . . . . . . . . . . . . . . . . . . . 6
5.2. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Kexin Tang, et al. Expires April 28, 2011 [Page 2]
Internet-Draft Stateful PCE Oct 2010
1. Introduction
As defined in section 6.8 of RFC4655 [RFC4655], a PCE can be either
stateful or stateless. For stateful PCE, there is a strict
synchronization between the PCE and not only the network states (in
term of topology and resource information), but also the set of
computed paths and reserved resources in use in the network. So
stateful PCE has more network information, and it can be used to do
some complicated work, such as supporting GCO as well as resources
restoration.
Since the information carried in stateful PCEs are more detailed than
that of stateless PCEs, having knowledge of the state capability of
PCEs, the PCC may make advanced and informed choices about which PCE
to use. However, the existing PCE discovery ([RFC5088], [RFC5089])
and PCEP don't support stateful PCE, and the PCC have no knowledge of
the state of PCE. So, this document focus on stateful PCE, describes
the applicability of stateful PCE and gives the IGP and PCEP
extensions to support stateful PCE.
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. Terminology
o PCC: Path Computation Client. A client application requesting a
path computation to be performed by the Path Computation Element.
o PCE: Path Computation Element. 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.
o PCED: PCE Discovery.
o PCEP: Path Computation Element communication Protocol.
o TED: Traffic Engineering Database, which contains the topology and
resource information of the domain. The TED may be fed by
Interior Gateway Protocol (IGP) extensions or potentially by other
means.
o GCO: Global Concurrent Optimization. A concurrent path
computation application where a set of TE paths are computed
concurrently in order to optimize network resources. A GCO path
Kexin Tang, et al. Expires April 28, 2011 [Page 3]
Internet-Draft Stateful PCE Oct 2010
computation is able to simultaneously consider the entire topology
of the network and the complete set of existing TE LSPs, and their
respective constraints, and look to optimize or reoptimize the
entire network to satisfy all constraints for all TE LSPs. A GCO
path computation can also provide an optimal way to migrate from
an existing set of TE LSPs to a reoptimized set (Morphing
Problem).
3. Applicability of stateful PCE
As mentioned in the preceding part of this document, stateful PCE
utilizes information from the TED as well as information about
existing paths (for example, TE LSPs) in the network. Since stateful
PCE has more network information, it can be used to solve the problem
of resources conflict. Typical use cases of stateful PCE are listed
in this section.
3.1. stateful PCE in support of GCO
As mentioned in RFC5557 [RFC5557], when computing or reoptimizing the
routes of a set of Traffic Engineering Label Switched Paths (TE LSPs)
through a network, it may be advantageous to perform bulk path
computations in order to avoid blocking problems and to achieve more
optimal network-wide solutions. Such bulk optimization is termed
Global Concurrent Optimization (GCO). A GCO is able to
simultaneously consider the entire topology of the network and the
complete set of existing TE LSPs, and their respective constraints,
and look to optimize or reoptimize the entire network to satisfy all
constraints for all TE LSPs.
Since stateful PCE realized not only network states (in term of
topology and resource information), but also the set of computed
paths and reserved resources in use in the network, it can help a GCO
realize the entire topology of the network and complete set of
existing TE LSPs, so as to make a GCO to achieve the optimal network,
particularly when there are several LSP needed to build, if a
stateful PCE have computed a end-to-end path successfully, and hold
the resources needed by this path, as a stateful PCE, therefore it
could realize the newly path and reserved resources, so it can inform
other PCEs involved in the GCO not to consider the same resources it
just hold for the path, so stateful PCE can avoid unnecessary retries
in GCO, so as to make a GCO sufficiently.
3.2. stateful PCE in support of resources restoration
Another important scenario for using the state of PCEs is that in
resources restoration. A serious situation of network failure as
Kexin Tang, et al. Expires April 28, 2011 [Page 4]
Internet-Draft Stateful PCE Oct 2010
fiber cutting may rise to a huge number of resources restoration
requests in a short time from the PCC.
In the restoration, if a stateful PCE have computed a LSP in its own
domain successfully, and hold the resources needed by this LSP, as a
stateful PCE, therefore it could realize the newly path and reserved
resources, so it can inform other PCEs involved in the end-to-end
path computation not to consider the same resources it just hold for
the LSP, so stateful PCE can avoid unnecessary retries in resources
restoration.
And if a stateful PCE failed to compute an end-to-end LSP, it will
informed the newly path states to other stateful PCE, and release the
resources it just hold, so the other stateful PCE can use the
resources.
4. Requirements
As mentioned before, stateful PCE synchronized with not only the
network states (in term of topology and resource information), but
also the set of computed paths and reserved resources in use in the
network. So the PCC need to tell stateful PCE the path state
(created or deleted). However, having no knowledge of the state of
PCEs, the PCC have no idea of which PCE to send the path state. In
this situation, there are two possibilities for the PCC: send the
path state to all the PCEs whatever the state of them, or not send to
any of the PCE, and every stateful PCE query the path state
information when needed. In the former case, there would be lots of
unnecessary operation; and in the second case, it would increasing
the complexity of the realization of the control plane and PCE.
Therefore there are requirement of having knowledge of the state of
PCEs for PCC. Knowing the state of PCEs, the PCC only send the path
state information to stateful PCEs.
[RFC5088] defines extensions to OSPFv2 [RFC2328] and OSPFv3 [RFC2740]
to allow a PCE in an OSPF routing domain to advertise some
information useful to a PCC for PCE selection. It defines a new TLV
(named the PCE Discovery TLV (PCED TLV)) to be carried within the
OSPF Router Information LSA ([RFC4970]). The type 5 sub-TLV of PCED
TLV, which named PCE-CAP-FLAGS sub-TLV, used to indicate PCE
capabilities. It contains eight capabilities, but not includes the
state capability of a PCE. So the PCE in an OSPF routing domain
cannot advertise its state capability information to a PCC for PCE
selection.
Kexin Tang, et al. Expires April 28, 2011 [Page 5]
Internet-Draft Stateful PCE Oct 2010
5. PCE Discovery and PCEP Extensions
This section provides protocol extensions for support of stateful
PCE. Protocol extensions discussed in this section including PCED
and PCEP.
5.1. PCED Extensions
To support stateful PCE, PCC SHOULD know a PCE is stateful or not.
Therefore, the PCE discovery message SHOULD indicates whether the PCE
advertises this message is a stateful PCE. Since PCE-CAP-FLAGS Sub-
TLV ([RFC5088] for OSPF, [RFC5089] for IS-IS) contains PCE Capability
Flags, this document defines a new flag, Stateful PCE Capability
Flag, as follows (need to be assigned by IANA):
Bit Capabilities
9 Stateful PCE
5.2. PCEP Extensions
A PCC that wishes to inform a successful end-to-end path computation
and end-to-end path connection may send an unsolicited notification
to the PCE involved in the end-to-end path computation. New
Notification-type and Notification-value are currently defined as
follows (need to be assigned by IANA):
o Notification-type=3: end-to-end path computation result
* Notification-value=1: end-to-end path computation successful.
When an end-to-end path is successfully computed, the PCC
SHOULD send a notification message with Notification-type=3 and
Notification-value=1 to all the PCE which involved in the end-
to-end path computation.
* Notification-value=2: end-to-end path computation failure.
When an end-to-end path is unsuccessfully computed, the PCC
SHOULD send a notification message with Notification-type=3 and
Notification-value=2 to all the PCE which involved in the end-
to-end path computation.
o Notification-type=4: end-to-end connection result
* Notification-value=1: end-to-end path connection is success.
When an end-to-end path is successfully connected, the PCC
SHOULD send a NOTIFICATION message with Notification-type=4 and
Notification-value=1 to all the PCE which involved in the end-
to-end path computation.
Kexin Tang, et al. Expires April 28, 2011 [Page 6]
Internet-Draft Stateful PCE Oct 2010
* Notification-value=2: end-to-end path connection failure. When
an end-to-end path is unsuccessfully connected, the PCC SHOULD
send a notification message with Notification-type=4 and
Notification-value=2 to all the PCE which involved in the end-
to-end path connection.
6. Security Considerations
The extensions of this draft is baed on PCEP and OSPF, only some
optional protocol elements are added which will not change the
security of existing network.
7. IANA Consideration
TBD.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5089, January 2008.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, July 2009.
Kexin Tang, et al. Expires April 28, 2011 [Page 7]
Internet-Draft Stateful PCE Oct 2010
Authors' Addresses
Kexin Tang
ZTE Corporation
No.68 ZiJingHua Road,Yuhuatai District
Nanjing, Jiangsu 210012
P.R.China
Phone: +86-025-52871745
Email: tang.kexin@zte.com.cn
URI: http://www.zte.com.cn/
Zhihong Wang
ZTE Corporation
12F, ZTE Plaza, No.19 East Huayuan Road,Haidian District
Beijing 100191
P.R.China
Phone: +86-010-59932453
Email: wang.zhihong@zte.com.cn
URI: http://www.zte.com.cn/
Yuanlin Bao
ZTE Corporation
5F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road,
Nanshan District, Shenzhen 518055
P.R.China
Phone: +86-755-26773731
Email: bao.yuanlin@zte.com.cn
URI: http://www.zte.com.cn/
Xuerong Wang
ZTE Corporation
R&D Building 3, ZTE Industrial Zone, Liuxian Road,Nanshan District
Shenzhen 518055
P.R.China
Phone: +86-755-26773926
Email: wang.xuerong@zte.com.cn
URI: http://www.zte.com.cn/
Kexin Tang, et al. Expires April 28, 2011 [Page 8]
Internet-Draft Stateful PCE Oct 2010
Gang Lu
ZTE Corporation
2/F, ZTE Plaza, North Huashiyuan Road, East Lake Zone
Wuhan 430223
P.R.China
Phone: +86-027-51811033
Email: lu.gang2@zte.com.cn
URI: http://www.zte.com.cn/
Kexin Tang, et al. Expires April 28, 2011 [Page 9]