Network Working Group Kexin Tang
Internet-Draft Zhihong Wang
Intended status: Informational Yuanlin Bao
Expires: April 20, 2011 ZTE Corporation
Oct 17, 2010
Statefull PCE
draft-tang-pce-stateful-pce-00.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 20, 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
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Kexin Tang, et al. Expires April 20, 2011 [Page 1]
Internet-Draft Statefull PCE Oct 2010
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. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. PCE Discovery and PCEP Extensions . . . . . . . . . . . . . . . 4
4.1. Statefull PCE Capability Flag . . . . . . . . . . . . . . . 4
4.2. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Kexin Tang, et al. Expires April 20, 2011 [Page 2]
Internet-Draft Statefull PCE Oct 2010
1. Introduction
As defined in [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. Since stateful PCE has more network
information, it can be used to do some complicated work, such as
loops and resource scrap.
However, the exsisting PCE discovery ([RFC5088], [RFC5089]) and PCEP
don't support stateful 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.
3. Requirement
This section lists the tipcal use case of statefull PCE. As
described in [RFC4655], stateful PCE not only use information from
TED, but also information about existing paths (for example, TE LSPs)
in the network when processing new requests, so the information
carried in stateful PCE are more detailed than that of stateless
Kexin Tang, et al. Expires April 20, 2011 [Page 3]
Internet-Draft Statefull PCE Oct 2010
PCE.Knowing the state capability of PCEs, the PCC may make advanced
and informed choices about which PCE to use.
Another scenario for using the state of PCEs is that the PCC send the
path state (created or deleted) to stateful PCE. 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
PCEs . Knowing the state of PCEs, the PCC only send the path state
information to stateful PCEs.
[RFC5088] defines extensions to OSPFv2 [RFC2328] and OSPFv3 [RFC5340]
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 CE-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.
4. PCE Discovery and PCEP Extensions
4.1. Statefull PCE Capability Flag
To support statefull PCE, PCC SHOULD know a PCE is statefull or not.
Therefore, the PCE discovery message SHOULD indicates whether the PCE
advertises this message is a statefull PCE. Since PCE-CAP-FLAGS Sub-
TLV ([RFC5088] for OSPF, [RFC5089] for IS-IS) contains PCE Capability
Flags, so this document defines a new flag, Statefull PCE Capability
Flag, as follows (need to be assigned by IANA):
Bit Capabilities
9 Stateful PCE
4.2. PCEP Extensions
With respect to the definitation of stateful PCE ([RFC4655]), a
stateful PCE utilizes information from the TED as well as information
about existing paths (for example, TE LSPs) in the network when
processing new requests. So, a stateful PCE SHOULD know the status
Kexin Tang, et al. Expires April 20, 2011 [Page 4]
Internet-Draft Statefull PCE Oct 2010
(created or deleted) of a path it computed. Thus, the PCC SHOULD
tell PCE the path status which can be done by PCNtf message which is
detailed in this section.
A new Notification-type and two Notification-value are defined as
follows (need to be assigned by IANA):
o Notification-type=3: LSP path Status
* Notification-value=1: LSP path is created. When a LSP path is
created, the PCC SHOULD send a notification message with
Notification-type=3 and Notification-value=1 to PCE which
computed out the path.
* Notification-value=1: LSP path is deleted. When a LSP path is
deleted, the PCC SHOULD send a notification message with
Notification-type=3 and Notification-value=2 to PCE which
computed out the path.
Furthermore, the LSP path information SHOULD be contained in PCNtf
message so that a PCE can identify which path status changes. For
the exsisting ERO object has expressed the path information well, so,
it's subobjects ([RFC3209]) can be used in Optional TLVs of
NOTIFICATION object. (NOTE: This extension needs to be disscussed.)
5. 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.
6. IANA Consideration
TBD.
7. 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.
[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.
Kexin Tang, et al. Expires April 20, 2011 [Page 5]
Internet-Draft Statefull PCE Oct 2010
[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.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
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/
Kexin Tang, et al. Expires April 20, 2011 [Page 6]
Internet-Draft Statefull PCE Oct 2010
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/
Kexin Tang, et al. Expires April 20, 2011 [Page 7]