Internet DRAFT - draft-huangshg-pce-conflict-avoidance
draft-huangshg-pce-conflict-avoidance
PCE XF. Lin
Internet-Draft ZTE Corporation
Intended status: Informational shg. Huang
Expires: July 6, 2013 X. Li
J. Zhang
M. Zhang
HX. Wang
BUPT
January 2, 2013
Path Computation Element (PCE) Extensions for Link State Conflict
Avoidance Mechanism in Optical Transport Networks
draft-huangshg-pce-conflict-avoidance-01
Abstract
This document proposes a PCE based link state conflict avoidance
mechanism. Path Computation Element (PCE) can compute a network path
or route based on the information stored in Traffic Engineering
Database (TED) and TED collects the link resources information
through the OSPF-TE protocol. The proposed conflict avoidance
mechanism gives each link two state which respectively represents the
resource in this link is changed or not. The extended OSPF-TE
protocol will also flood the link state information when it floods
the link resources information. PCE will add the link state to the
calculated path when it returns the calculated path to Path
Computation Clients (PCC). When the RSVP-TE protocol reserves the
resource along the calculated path, it will compare the link state
stored in the calculated path with the link state stored in the
local. If the link state between the calculated path and the local
is inconsistent then the RSVP-TE protocol will stop the resource
reservation process, release the reserved resource and promote the
OSPF-TE protocol to flood the Link resources information immediately.
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
Lin, et al. Expires July 6, 2013 [Page 1]
Internet-Draft PCE extensions for link state conflict January 2013
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 6, 2013.
Copyright Notice
Copyright (c) 2013 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.
Lin, et al. Expires July 6, 2013 [Page 2]
Internet-Draft PCE extensions for link state conflict January 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . . 5
3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Applicability of Link State Conflict Avoidance Mechanism
in Optical Transport . . . . . . . . . . . . . . . . . . . . . 5
4.1. Two-value link state . . . . . . . . . . . . . . . . . . . 6
4.2. Path Computation Request and Path Computation Reply . . . . 7
4.3. RSVP-TE Process . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Lin, et al. Expires July 6, 2013 [Page 3]
Internet-Draft PCE extensions for link state conflict January 2013
1. Introduction
With the development in large scale optical transport network, the
calculation of optimal route becomes complicated and unrealistic
under the distributed optical network of multi-layers and multi-
domains. Path Computation Element (PCE) which is capable of
computing a network path or route based on a network graph, and of
applying computational constraints has effectively solved this issue.
[RFC4655] specifies the architecture for a Path Computation Element
(PCE)-based mode. It discusses PCE-based implementations including
composite, external, and multiple PCE path computation. Furthermore,
it discusses architectural considerations including centralized
computation, distributed computation, synchronization, PCE discovery
and load balancing, detection of PCE liveness, communication between
Path Computation Clients (PCCs) and the PCE (PCC-PCE communication)
and PCE-PCE communication, Traffic Engineering Database (TED)
synchronization, stateful and stateless PCEs, monitoring, policy and
confidentiality and evaluation metrics.
[RFC5440] specifies the Path Computation Element (PCE) Communication
Protocol (PCEP) for communications between a Path Computation Client
(PCC) and a PCE, or between two PCEs. Such interactions include path
computation requests and path computation replies as well as
notifications of specific states related to the use of a PCE in the
context of Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineering. PCEP is designed to be flexible and
extensible so as to easily allow for the addition of further messages
and objects.
[RFC5557] provides a set of requirements and PCEP extensions in
support of concurrent path computation applications. A concurrent
path computation is a path computation application where a set of TE
paths are computed concurrently in order to efficiently utilize
network resources. The computation method involved with a 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 the scope of this document.
PCE system structure characteristics include: PCE is compatible with
existing MPLS/GMPLS agreement. PCE is compatible with existing MPLS/
GMPLS network operation mode, including management level. PCE uses a
single, signaling protocol and structure, suitable for different
network environment, such as inner domain, between domains, and
between different operators, etc. PCE allows operators or equipment
manufacturers use different routing algorithms, based on complex
traffic engineering parameters and strategy calculation routing; and
has the flexible system structures. PCE can work with nets element
Lin, et al. Expires July 6, 2013 [Page 4]
Internet-Draft PCE extensions for link state conflict January 2013
equipment together, also can be in a single server implementation.
When the PCC and the PCE is not in the same physical location, they
use PCEP protocol and BRPC algorithm to realize multi-domain path
requests and path calculation.
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
PCC: Path Computation Client.
PCE: Path Computation Element.
TED: Traffic Engineering Database.
PCEP: The PCE communication Protocol.
4. Applicability of Link State Conflict Avoidance Mechanism in Optical
Transport
Once a request has been presented to a PCE, it chooses the proper
route within the network based on the resource information in TED.
The TED gathers the information related to the current topology and
resource usage in the network by continuous interaction with the
OSPF-TE protocol. When the PCE has chosen the route for a router
demand, the corresponding LSP will be setup using RSVP-TE protocol,
which will take care of performing node-by-node admission control and
actual resource allocation. OSPF-TE advertises the change of local
resource allocation status to all other TED by sending a Link State
Update message containing a special kind of Link State Advertisement
object called opaque LSA. The LSU message is distributed to all LSRs
using the OSPF flooding procedure.
In order to avoid that the massive information flooding is executed
for each minimal change, some flooding reduction mechanisms are used,
so that the origination rate of OSPF-TE LSU messages can be reduced.
But the flooding reduction mechanisms may cause that the resource
information stored in the TED cannot be updated in real time. A
potential solution would be to advertise a two-value state for each
local link with little size of packet. This would require
implementations to process these two-value state TLVs during the path
Lin, et al. Expires July 6, 2013 [Page 5]
Internet-Draft PCE extensions for link state conflict January 2013
calculation in PCE. It need to increase the rate of OSPF-TE Link
State messages and is anticipated that the Link State messages will
prove more generally useful.
4.1. Two-value link state
Each local link will be given two-value (0,1) link state where
1represent the resource in local link state have be changed and 0
represent the resource in local link state have no changed. The link
state TLV is as presented in the Fig.1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
// //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lin, et al. Expires July 6, 2013 [Page 6]
Internet-Draft PCE extensions for link state conflict January 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(36) | C-Tyoe(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Advertising Router | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchanne l |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchanne N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. Path Computation Request and Path Computation Reply
Once a PCC has successfully established a PCEP session with one or
more PCEs, it sends a path computation request to the PCE that
contains a variety of objects that specify the set of constraints and
attributes for the path to be computed. Upon receiving a path
computation request from a PCC, the PCE triggers a path computation.
The PCE manages to compute a path that includes the link state
information. Then PCE returns the set of computed paths
(EXPLICIT_ROUTE object) to the requesting PCC. Note that PCEP
supports the capability to send link state TLV in the computed path.
4.3. RSVP-TE Process
RSVP-TE enables the allocation of resources along the path. The
source node adds an EXPLICIT_ROUTE object to the RSVP-TE Path
message. The EXPLICIT_ROUTE object specifies the route as a sequence
of nodes. When the RSVP-TE reserve the resource in the local link
then in will compare the link state stored in the calculated path
with the link state stored in the local. If the link state between
the calculated path and the local is inconsistent then the RSVP-TE
protocol will stop the resource reservation process, release the
reserved resource and promote the OSPF-TE protocol to flood the Link
resources information immediately.
5. Security Considerations
TBD.
Lin, et al. Expires July 6, 2013 [Page 7]
Internet-Draft PCE extensions for link state conflict January 2013
6. Acknowledgments
TBD.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC4655] Farrel, A., "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.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation
Element(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
Authors' Addresses
Xuefeng Lin
ZTE Corporation
No.16,Huayuan Road,Haidian District
Beijing 100191
P.R.China
Phone: +8615901011821
Email: lin.xuefeng@zte.com.cn
URI: http://www.zte.com.cn/
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/
Lin, et al. Expires July 6, 2013 [Page 8]
Internet-Draft PCE extensions for link state conflict January 2013
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/
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/
Min Zhang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613910621756
Email: @bupt.edu.cn
URI: http://www.bupt.edu.cn/
Hongxiang Wang
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613683683550
Email: wanghx@bupt.edu.cn
URI: http://www.bupt.edu.cn/
Lin, et al. Expires July 6, 2013 [Page 9]
