PCEP Protocol Extension for spectrum utilization optimization in Flexi- Grid Networks
draft-zhaoyl-pce-flexi-grid-pcep-ex-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Dajiang Wang , Jie Zhang , Tiantian Peng , Xiaosong Yu , Xuping Cao , Yongli Zhao | ||
| Last updated | 2011-10-24 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhaoyl-pce-flexi-grid-pcep-ex-00
Network Working Group YL. Zhao
Internet-Draft J. Zhang
Intended status: Informational TT. Peng
Expires: April 26, 2012 XS. Yu
BUPT
XP. Cao
DJ. Wang
ZTE Corporation
October 24, 2011
PCEP Protocol Extension for spectrum utilization optimization in Flexi-
Grid Networks
draft-zhaoyl-pce-flexi-grid-pcep-ex-00
Abstract
Flexi-grid networks overcomes the fixed grid channel of Wavelength
Switched Optical Network(WSON) by flexible spectrum to allow non-
uniform and dynamic allocation of spectrum based on the demand of the
incoming services' LSP. Flexi-grid networks is an effective solution
to solve the problem of efficient spectrum utilization.
Because the client LSP needs to be assigned contiguous spectrum in
flexi-grid networks, there will be two problems that would affect
spectrum utilization, i.e. RSA and fragmentation. We introduce two
kinds of methods which can improve the spectrum utilization further,
and some related PCEP extensions are defined in this document.
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 26, 2012.
Copyright Notice
Zhao, et al. Expires April 26, 2012 [Page 1]
Internet-Draft PCEP Extension October 2011
Copyright (c) 2011 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
4. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Introduction of RSA . . . . . . . . . . . . . . . . . . . 4
4.2. Algorithms of RSA . . . . . . . . . . . . . . . . . . . . 4
4.3. RSA Schemes Selection . . . . . . . . . . . . . . . . . . 5
5. Defragmentation . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Motivation of Defragmentation . . . . . . . . . . . . . . 6
5.2. Definition of Defragmentation . . . . . . . . . . . . . . 6
5.3. Application Scene of Defragmentation . . . . . . . . . . . 6
6. PCEP Protocol Extension . . . . . . . . . . . . . . . . . . . 7
6.1. PCEP Protocol Extension for RSA . . . . . . . . . . . . . 7
6.2. PCEP Protocol Extension for Defragmentation . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zhao, et al. Expires April 26, 2012 [Page 2]
Internet-Draft PCEP Extension October 2011
1. Introduction
Demand of traffic is increasing exponentially and already approaching
the limit of single mode fiber capacity. At the same time, because
of varying demand of traffic, we need an efficient and agile
utilization of the optical spectrum.
ITU-T Study Group 15 introduce a new flexi-grid networks to enable
dynamic allocation of spectrum resource. The flexi-grid networks is
an effective solution to solve the problem of efficient spectrum
resource utilization.
The granularity of flexi-grid networks can be smaller and agile.
i.e.,6.25GHz. In the flexi-grid networks, the appropriate size of
spectrum is determined by the used modulation format.According to the
client data rate LSP and physical consecutives of the selected
path,the appropriate size of spectrum is adaptively allocated to
optical connections by assigning the appropriate number of contiguous
spectrum from end-to-end.Before assigning the client LSP, we have to
find suitable route and fit contiguous spectrum for it, and it is a
complex process. So spectrum utilization is very important in RSA.
While there are several algorithms for RSA, flexi-grid networks
require to extend PCEP protocol to support different algorithms
seletion.
Upon tearing down of connections, the allocated spectrum are released
for future LSPs. In a dynamic traffic scenario, this setup and tear
down precedure for a channel leads to fragmentation of spectral
resources. Due to the fragmentation, the available spectrum is
divided into small noncontiguous spectral bands,the spectral
effciency in the network is compromised. Therefore the probability
of finding suffcient contiguous spectrum for a connection is
decreased. We introduce defragmentation to deal with fragmentation
in flexi-grid networks. then PCEP protocol has to add some messages
to support them.
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
RSA: Routing and Spectrum Assignment
Zhao, et al. Expires April 26, 2012 [Page 3]
Internet-Draft PCEP Extension October 2011
WSON:Wavelength Switched Optical Network
4. RSA
4.1. Introduction of RSA
In this part, we focus on the routing and spectrum assignment (RSA)
problem. This problem can be partitioned into two subproblems: (1)
routing and (2) spectrum assignment, and each subproblem can be
solved separately. Different from traditional WDM network, flexi-
grid networks assign continuous spectrum for new arrival LSP. Static
planning models are used for flexi-grid networks to improve spectrum
utilization.
4.2. Algorithms of RSA
There are several spectrum assignment algorithms.
(1)Random Fit (RF)
This scheme first searches the space of spectrum to determine the set
of all spectrum that are available on the required route. Among the
available spectrum, one is chosen randomly.
(2)First-Fit (FF)
In this scheme, all spectrum is numbered.When searching for available
spectrum, a lower numbered spectrum is considered before a higher-
numbered spectrum.The first available spectrum is then selected.
Compared to Random spectrum assignment, the computation cost of this
scheme is lower because there is no need to search the entire
spectrum space for each route.
(3)Least-Used (LU)/SPREAD
LU selects the spectrum that is the least used in the network,
thereby attempting to balance the load among all the spectrum. The
performance of LU is worse than Random, while also introducing
additional communication overhead (e.g., global information is
required to compute the least-used spectrum).
(4)Most-Used (MU)/PACK
MU is the opposite of LU in that it attempts to select the most-used
spectrum in the network. The communication overhead, storage, and
computation cost are all similar to those in LU.MU also slightly
outperforms FF, doing a better job of packing connections into fewer
Zhao, et al. Expires April 26, 2012 [Page 4]
Internet-Draft PCEP Extension October 2011
spectrum and conserving the spare capacity of less-used spectrum.
(5)Min-Product (MP)
MU is the opposite of LU works. In a single fiber network, MP
becomes FF. The goal of MP is to pack spectrum into fibers, thereby
minimizing the number of fibers in the network.
(6)Least-Loaded (LL)
The LL heuristic, like MP, is also designed for multi-fiber networks.
This heuristic selects the spectrum that has the largest residual
capacity on the most loaded link along route.
(7)MAX-SUM (MS)
MS was proposed for multi-fiber networks but it can also be applied
to the single-fiber case.MS considers all possible paths in the
network and attempts to maximize the remaining path capacities after
lightpath establishment.
(8)Relative Capacity Loss (RCL)
RCL is based on MS. RCL chooses spectrum to minimize the relative
capacity loss. RCL is based on the observation that minimizing total
capacity loss sometimes does not lead to the best choice of spectrum.
(9)Spectrum Reservation (Rsv)
In Rsv, a given spectrum on a specified link is reserved for a
traffic stream, usually a multihop stream. This scheme reduces the
blocking for multihop traffic,while increasing the blocking for
connections that traverse only one fiber link (single-hop traffic).
(10)Protecting Threshold (Thr)
In Thr, a single-hop connection is assigned spectrum only if the
number of idle spectrum on the link is at or above a given threshold.
4.3. RSA Schemes Selection
There are several spectrum assignment algorithms, we have to choose
one of them for flexi-grid networks. Different RSA schemes are
selected according to diffrent network condition. The PCEP protocol
needs to extend a bit that shows different schemes selected.
Zhao, et al. Expires April 26, 2012 [Page 5]
Internet-Draft PCEP Extension October 2011
5. Defragmentation
5.1. Motivation of Defragmentation
New arrival of LSPs are then either forced to utilize more spectrum
in the network or blocked in spite of suffcient spectrum being
available. Additionally, as the network evolves, a current optimal
routing scheme might no longer provide the optimal spectral
utilization over time. There is an increasing demand from the
network operators to be able to periodically reconfigure the network
and return it to its optimal state, so that the network can operate
more effciently.
5.2. Definition of Defragmentation
There is an operation defined as network defragmentation to solve
above problem. Reducing the blocking by consolidating the available
network resources, this operation will also enable better network
maintenance and more effcient network restoration and bandwidth
adjustment.
5.3. Application Scene of Defragmentation
The process of defragmentation: (1) select LSP for defragmentation,
and interrupt it considerring the time and cost, (2) choose forward
spectrum in original route or new route, (3) move the LSP on possible
spectrum.
An example of defragentation is as following: A,B,C are client LSPs
on link l, l1 is original statement of link l,l2 is statement of link
l after defragementation.
+-------------+ +----+ +---------+
l1: | A | | B | | C |
+-------------+----------+----+-----+---------+--
+-------------+----+-----------+
l2: | A | B | C |
+-------------+----+-----------+-----
Fig.1 Defragentation principle
we first focus on the problem of the time-point when should
defragmentation be operated. There is two ways to solve this
problem. One way is new arrival LSPs have no sufficient spectrum to
bear, then cause blocked in the network. The other way: (1) collect
Zhao, et al. Expires April 26, 2012 [Page 6]
Internet-Draft PCEP Extension October 2011
the information about occupation of spectrum fragments in a link or
in the network, (2) introduce a notation to describe the state of
spectrum fragment in a link or in a network, (3)when the size of this
notation reaches an assumed threshold, it is the time for
defragmentation.
we consider the methods of defragmentation. At present, there is two
methods for defragmentation. First is change route of client LSP,
meaning that the spectrum of this LSP in new route is ahead than the
spectrum in original route. Second is the LSP move forward directly
in original route.
6. PCEP Protocol Extension
6.1. PCEP Protocol Extension for RSA
The PCEP protocol need to be extended to support the algorithms
choosing of RSA. PCReq needs to add RAEO-list information. This
information include "Algorithm Id", which stands for the number of
different algorithms, and "Pri" that means priority of these
algorithms.
<request>::= <RP>
<END-POINTS>
[<RAEO-list>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
where RP Object:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |C|O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
Zhao, et al. Expires April 26, 2012 [Page 7]
Internet-Draft PCEP Extension October 2011
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C bit is the Cascade bit, if C=1,assign continuous spectrum for traffic else assign uncontinuous spectrum.
[<RAEO-list>] defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm Id | Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
NO-PATH:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nature of Issue|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: NO-PATH Object Format
NI - Nature of Issue (8 bits): The NI field is used to report the
nature of the issue that leads to a negative reply. Two values are
currently defined:
0: No path satisfying the set of constraints could be found
1: PCE chain broken
2: No path satisfying the Continuous spectrum
Zhao, et al. Expires April 26, 2012 [Page 8]
Internet-Draft PCEP Extension October 2011
6.2. PCEP Protocol Extension for Defragmentation
The presence of defragmentation in flexi-grid networks has an impact
on the information that needs to be transferred by the control plane
and PCE. Defragmentation has to interrupt the traffic and move it to
another spectrum or route. The PCEP protocol needs to be extended
two messages to support defragmentation, ingcluding information of
orginal route/spectrum and present route/spectrum, when to stop
defragmentation and so on.
Here is Spectrum Defragmentation Request Message and Spectrum
Defragmentation Reply Message. "Target Clutter Value" stands for the
goal of defragmentation. "R" means whether the network MUST make it.
Spectrum Defragmentation Request Message
<SDReq Message>::= <Common Header>
<SDTO-list>
[LSPA Object]
[<RAEO-list>]
Spectrum Defragmentation Reply Message
<SDRep Message>::= <Common Header>
<SDTO-list>
<Reroute-list>
[LSPA Object]
[<RAEO-list>]
Spectrum Defragmentation Reply Message
SDTO: Spectrum Defragmentation Target Object
Zhao, et al. Expires April 26, 2012 [Page 9]
Internet-Draft PCEP Extension October 2011
SDTO:Spectrum Defragmentation Target Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Clutter Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Reroute>::=<RP Object>
<path><Center Frequence><Bandwidth>
<path><Center Frequence><Bandwidth>
where Center Frequence is
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Center Frequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Center Frequence (32 bits): The requested bandwidth is encoded in 32 bits, expressed in bytes per second.
7. Security Considerations
TBD.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
Zhao, et al. Expires April 26, 2012 [Page 10]
Internet-Draft PCEP Extension October 2011
Authors' Addresses
Yongli Zhao
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613811761857
Email: yonglizhao@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/
Tiantian Peng
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8615116984347
Email: tt871228@163.com
URI: http://www.bupt.edu.cn/
Xiaosong Yu
BUPT
No.10,Xitucheng Road,Haidian District
Beijing 100876
P.R.China
Phone: +8613811731723
Email: yu.xiaosong@qq.com
URI: http://www.bupt.edu.cn/
Zhao, et al. Expires April 26, 2012 [Page 11]
Internet-Draft PCEP Extension October 2011
Xuping Cao
ZTE Corporation
No.16,Huayuan Road,Haidian District
Beijing 100191
P.R.China
Phone: +8615801379189
Email: cao.xuping@zte.com.cn
URI: http://www.zte.com.cn/
Dajiang Wang
ZTE Corporation
No.16,Huayuan Road,Haidian District
Beijing 100191
P.R.China
Phone: +8613811795408
Email: wang.dajiang@zte.com.cn
URI: http://www.zte.com.cn/
Zhao, et al. Expires April 26, 2012 [Page 12]