Network Working Group SH. Huang
Internet-Draft X. Li
Intended status: Informational BUPT
Expires: April 21, 2011 DJ. Wang
ZTE Corporation
WY. Gu
BUPT
XH. Fu
ZTE Corporation
October 18, 2010
Extensions to the Path Computation Element Communication Protocol(PCEP)
for Crank-back Routing
draft-huangshg-pce-crank-back-routing-00
Abstract
Path computation in large multi-layer and multi-region networks is
complex and may require special computational components and
cooperation between different network domains, whereby a failure
affect to establish a path or a failure of an existing path may be
corrected by a new path computation and fresh signaling. This
document specifies the crank-back routing mechanism based on re-
routing in crank back Path Computation Element (PCE). When a Path
Computation Client (PCC) requests a PCE for a route, it may be useful
for the PCC to specify Crank-back routing to the path computation,
abstract nodes, resources, and domains that are to be explicitly
excluded from the computed route. Such mechanism is termed Crank-
back routing. The PCE Communication Protocol (PCEP) is designed as a
communication protocol between PCCs and PCEs. To support this
mechanism, function of PCE and procedure of PCEP signaling
performance are extended.
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."
Huang, et al. Expires April 21, 2011 [Page 1]
Internet-Draft PCEP Extensions for Crank-back Routing October 2010
This Internet-Draft will expire on April 21, 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Huang, et al. Expires April 21, 2011 [Page 2]
Internet-Draft PCEP Extensions for Crank-back Routing October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Motivation for a Crank-back Routing . . . . . . . . . . . . . 5
5. Protocol Procedures and Extensions . . . . . . . . . . . . . . 5
5.1. Exclude Domain Object (XDO) and Include LSP Object
(ILO) . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Relationship to Signaling . . . . . . . . . . . . . . . . 7
6. Practical application . . . . . . . . . . . . . . . . . . . . 7
6.1. Single PCE path computation Environment . . . . . . . . . 7
6.2. Multiple PCE path computation Environment . . . . . . . . 8
6.3. Centralized computation model Environment . . . . . . . . 8
6.4. Distributed computation model Environment . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9
8.1. New Flags Of The RP Object . . . . . . . . . . . . . . . . 9
8.2. New Error-Type And Error-Value . . . . . . . . . . . . . . 9
8.3. New Flag Of The NO-PATH-VECTOR TLV . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Other Authors . . . . . . . . . . . . . . . . . . . . 10
A.1. Zhenyu Wang . . . . . . . . . . . . . . . . . . . . . . . 10
A.2. Yongjun Zhang . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Huang, et al. Expires April 21, 2011 [Page 3]
Internet-Draft PCEP Extensions for Crank-back Routing October 2010
1. Introduction
Crank-back routing is a mechanism whereby a failure affect to
establish a path or a failure of an existing path may be corrected by
a new path computation and fresh signaling. Crank-back routing
relies on the distribution of Crank-back information along with the
failure notification so that the new computation can be performed
avoiding the failure or blockage point. In the context of Path
Computation Element (PCE), Crank-back information may be passed back
to the head-end where the process of computation and signaling can be
repeated using the failed resource as an exclusion in the computation
process. But Crank-back may be used to attempt to correct the
problem at intermediate points along the path. Such Crank-back re-
computation nodes are most likely to be domain boundaries where the
Path Computation Client (PCC) had already invoked a PCE. Thus, a
failure within a domain is reported to the ingress domain boundary,
which will attempt to compute an alternate path across the domain.
Finishing this, the problem may be reported to the previous domain
and communicated to the ingress boundary for that domain, which may
attempt to select a more successful path either by choosing a
different entry point into the next domain, or by selecting a route
through a different set of domains.
2. 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].
3. Terminologies
LSR: Label Switching Router.
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.
TED: Traffic Engineering Database.
Huang, et al. Expires April 21, 2011 [Page 4]
Internet-Draft PCEP Extensions for Crank-back Routing October 2010
4. Motivation for a Crank-back Routing
Several motivations for a Crank-back Routing are listed below.It
should be highlighted that the aim of this section is to provide some
application examples for which a Crank-back Routing may be suitable:
this also clearly states that such a model does not aim to replace
existing path computation models but would apply to specific existing
or future situations.As can be seen from these examples, Crank-back
does not replace the existing Internet model where intelligence is
distributed within the network. Instead, it builds on this model and
makes use of distributed centers of information or computational
ability.
5. Protocol Procedures and Extensions
This section describes the procedures adopted by a PCE handling a
request for Crank-back routing computation with resources or domain
exclusions received from a PCC, and defines how those exclusions are
encoded.There are three types of resources or domain exclusion
described in. 1. Exclusion of certain abstract nodes or resources
from the specific domain. 2. Exclusion of certain domain from the
whole path.3. Include of the original LSP.When a specific Label
Switched Paths across several domains and the resource in a specific
domain collapse, the first step is that the failure notification will
send to the head PCE and this PCE calculation a another LSP path
avoiding the failure resource across the domain. If the PCE can!_t
find the suitable LSP in the failure domain, the Crank-back routing
request will dispatch to the previous domain and the PCE in the
previous domain is responsible for path calculation.This document
defines protocol extensions to allow a PCC to specify both types of
resources or domain exclusions and original LSP inclusions to a PCE
on a path computation request and allow a PCE to specify domain
exclusions and original LSP inclusions to another PCE on a path
computation request. A new PCEP object, the Exclude Domain Object
(XDO), is defined to convey the Exclude Domain List. Include LSP
Object (ILO) is defined to convey the original LSP. The existing
Include Route Object (IRO) in PCEP [RFC5440] and Exclude Route Object
(XRO) in PCEP [RFC5521] is modified by introducing a new IRO sub-
object and a new XRO sub-object to convey Explicit Domain Exclusions
and the original LSP.
5.1. Exclude Domain Object (XDO) and Include LSP Object (ILO)
Crank-back routing is based on the retrace point-based mechanism.
Turn point do not send a path error message to upstream PCE, but
reverting directly to the destination node for the residential, so
that the connection re-routing, and establish the connection.
Huang, et al. Expires April 21, 2011 [Page 5]
Internet-Draft PCEP Extensions for Crank-back Routing October 2010
If a label switching path fail because of link or node failure, a new
request will again request to PCE to repair label switched path,
because the PCC did not know the TED has been updated, the new path
request is request to carry these messages. If you want to use the
resources of the original LSP as a new request will have an
advantage. Therefore, path computation request message must be
permitted to identify the requested LSP path is restored, must also
support the inclusion of the original LSP and already failed element.
A network failure may affect a lot of LSPs, in this case, there will
be a lot of PCCs would like to request PCE at the same time.
Different levels of LSP will retrace the route using different
methods, so that the high-priority LSP would be rapidly recovered.
In order to achieve this approach, you must set he appropriate level
for each LSP in the PCE and configure the appropriate strategy to
accomplish this task.
Crank-back routing route can also be used to realize the TE LSP re-
optimization, in the new route request contains the original routing
path information that will help PCE to avoid double counting to
reduce bandwidth congestion issue.
The XDO and ILO are carried within Path Computation Request (PCReq)
and Path Computation Reply (PCRep) messages. When present in a PCReq
message, the XRO provides a list of network domains that the PCE is
requested to exclude from the path that it compute, the ILO provides
the original LSP that the PCE use to compute a new path containing
most of the normal running equipment in the original LSP. Flags
associated with each list member instruct the PCE as to whether the
domain must be excluded from the computed path and whether the
partial LSP must be included in the computed path. The XDO MAY be
used on a CRep message that carries the NO-PATH object (i.e., one
that reports a path computation failure) to indicate the set of
elements of the original XDO that prevented the PCE from finding a
path. The XDO MAY also be used on a PCRep message for a successful
path computation when the PCE wishes to provide a set of exclusions
to be signaled during LSP setup using the extensions to Resource
Reservation Protocol (RSVP)-TE [RFC4874]. XDO Body Format is in
accordance with the Exclude Route Object (XRO) in PCEP [RFC5521].
Include LSP Object (ILO) defines network elements that must not or
should not be used on the path between two PCE. This information is
encoded by defining a new sub-object for the ILO. The new ILO sub-
object has type 33. The ILO contains one or more sub-objects in its
own right. An ILO must not be sent without sub-objects, and if
received with no sub-objects, must be ignored.The format of the ILO
is as follows:
Huang, et al. Expires April 21, 2011 [Page 6]
Internet-Draft PCEP Extensions for Crank-back Routing October 2010
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// One or more ILO subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the ILO
L must be set to zero on transmission and must be ignored on receipt.
Reserved must be set to zero on transmission and should be ignored on
receipt. The ILO sub-object may carry any of the sub-objects defined
for inclusion in the ILO by this document or by future documents.
The meanings of the fields of the ILO sub-object are unchanged when
the sub-object are included in an ILO.
5.2. Relationship to Signaling
The inter-domain TE LSP is limited by the signaling methods supported
on the intermediate nodes. It is usually the domain border nodes
where this restriction applies since other transit nodes are
oblivious to the crank-back mechanism in use. The ingress of the LSP
may further restrict the choice by setting parameters in the Path
message when it is signaled. Determine the signaling method to be
used to cross the domain. If the ingress node of the inter-domain TE
LSP has specified crank-back restrictions on the methods to be used,
these must be adhered to. Within the freedom allowed by the ingress
node, the domain border node may choose any method according to local
configuration and policies.
6. Practical application
6.1. Single PCE path computation Environment
In "single PCE path computation", a single PCE is used to compute a
given path in a domain. All LSPs are computed by the single PCE and
this PCE make it best effort to find another appropriate LSP when it
receive crank-back request which include the XRO and ILO objects, if
this PCE can not find the needed LSP, a crank-back request include
the XDO and ILO objects is send to the previous domain.
Huang, et al. Expires April 21, 2011 [Page 7]
Internet-Draft PCEP Extensions for Crank-back Routing October 2010
6.2. Multiple PCE path computation Environment
In "multiple PCE path computation", multiple PCEs are used to compute
a given path in a domain. In this case, when a PCE send Path
Computation Request(PCReq) messages to another PCE and this PCE
compute the needed partial path for Previous PCE. After the network
run for a period of time, there is a node or link failure in the path
which is computed by current PCE, the failure notification is send to
the current PCE and the current PCE will make the greatest efforts to
compute another path. If the current PCE can!_t find the appropriate
path, the Path Computation Request (PCReq) messages including the XRO
and ILO objects send to previous PCE, this process continue to
execute until the PCE can find the appropriate path to the
destination. If all the PCE in this domain can!_t find the
appropriate path, the Path Computation Request (PCReq) messages
including the XDO and ILO objects send to a PCE which exist in
previous domain. The PCE in the previous domain will choose another
gateway node or choose another domain to establish the LSP.
6.3. Centralized computation model Environment
"Centralized computation model" refers to a model whereby all paths
in a domain are computed by a single, centralized PCE. There may be
multiple PCEs in a domain, but only one PCE per domain is involved in
any single path computation. Because there is only one PCE
participate in the LSP compute, the Crank-back routing request will
be send to the arbitrary PCE and the Path Computation Request (PCReq)
messages include the XRO and ILO objects.
6.4. Distributed computation model Environment
"Distributed computation model" refers to the computation of paths in
a domain being shared among multiple PCEs. Paths that span multiple
domains may be computed using the distributed model with one or more
PCEs responsible for each domain, or the centralized model by
defining a domain that encompasses all the other domains. From these
definitions, a centralized computation model inherently uses single
PCE path computation. However, a distributed computation model could
use either single PCE path computation or multiple PCE path
computations. There would be no such thing as a centralized model
that uses multiple PCEs.
7. Security Considerations
Crank-back Routing may raise new security issues when PCE-PCE
communication is done between different region networks for inter-
region path computation. Security issues may also exist when a
Huang, et al. Expires April 21, 2011 [Page 8]
Internet-Draft PCEP Extensions for Crank-back Routing October 2010
single PCE is granted full visibility of TE information that applies
to multiple areas.
It is expected that solutions for inter-region protocol extensions
will address these issues in detail using security techniques such as
authentication.
8. IANA Consideration
8.1. New Flags Of The RP Object
A new flag of the RP object is defined in this document, which
contains 2 bits.
VSPG Flags
Bit Number Name Flag Reference
23 VSPG
24 0: from source PCE to middle PCE this document
1: from destination PCE to middle PCE
Bit 24 is valid under the assumption that bit 23 is
valid
8.2. New Error-Type And Error-Value
A new Error-Type is defined in this document (Error-Type and Error-
value to be assigned by IANA).
Error-type Meaning Reference
14 DRPC procedure completion failure this document
Error-value
1: DRPC procedure not supported by one or more PCEs
along the domain path
8.3. New Flag Of The NO-PATH-VECTOR TLV
A new flag of the NO-PATH-VECTOR TLV defined in is specified in this
document.
Bit number Name Flag Reference
Huang, et al. Expires April 21, 2011 [Page 9]
Internet-Draft PCEP Extensions for Crank-back Routing October 2010
5 DRPC Path computation chain unavailable this document
9. Acknowledgments
The RFC text was produced using Marshall Rose's xml2rfc tool.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC4874] Lee, CY. and S. De , "Exclude Routes Extension to Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE)",
RFC 4874, April 2007.
[RFC5440] Vasseur, JP. and Ed. JL., "Path Computation Element (PCE)
Communication Protocol(PCEP)", RFC 5440, March 2009.
[RFC5521] Oki, E. and T. Takeda, "Extensions to the Path Computation
Element Communication Protocol(PCEP) for Route
Exclusions", RFC 5521, April 2009.
Appendix A. Other Authors
A.1. Zhenyu Wang
ZTE Corporation
12/F ZTE Plaza East Huayuan Road, Haidian District
Beijing
100191
P.R.China
+8613911266628
wang.zhenyu@zte.com.cn
http://www.zte.com.cn
Huang, et al. Expires April 21, 2011 [Page 10]
Internet-Draft PCEP Extensions for Crank-back Routing October 2010
A.2. Yongjun Zhang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing
100876
P.R.China
+8613366308960
yjzhang@bupt.edu.cn
http://www.bupt.edu.cn/
Authors' Addresses
Shanguo Huang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613693578265
Email: shghuang@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Xin li
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613426082735
Email: xinli@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Huang, et al. Expires April 21, 2011 [Page 11]
Internet-Draft PCEP Extensions for Crank-back Routing October 2010
Dajiang Wang
ZTE Corporation
12/F ZTE Plaza East Huayuan Road, Haidian District
Beijing 100191
P.R.China
Phone: +8613811795408
Email: wang.dajiang@zte.com.cn
URI: http://www.zte.com.cn/
Wanyi Gu
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613371692708
Email: wyg@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Xihua Fu
ZTE Corporation
West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District
Xi'an 710065
P.R.China
Phone: +8615802921223
Email: fu.xihua@zte.com.cn
URI: http://www.zte.com.cn/
Huang, et al. Expires April 21, 2011 [Page 12]