Internet DRAFT - draft-hwang-gmpls-signaling-parallel
draft-hwang-gmpls-signaling-parallel
WANG Hui
LI Jinsheng
Internet Draft HONG Peiling
Document: draft-hwang-gmpls-signaling-parallel-00.txt InfoNet Lab
Expires: July 1,2002 USTC
February 1,2002
Add a 'parallel resource allocation style object' to GMPLS signaling -
RSVP-TE and CR-LDP
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
The Internet transport infrastructure is moving towards a model of
high-speed routers interconnected by optical core networks. At the
same time, a consensus has emerged in the industry on utilizing IP-
based protocols for the optical control plane. GMPLS is assumed to
be the most possible control plane for the future all optical
transport network. There are two major sets of signaling with GMPLS
to maintain LSP, which are RSVP-TE and CR-LDP. But both of the
singalings cannot do fast lightpath establishing according to their
setup strategies. In this draft, we present a fast lightpath
establishing scheme by adding a 'parallel resource allocation style
object' to GMPLS signaling sets - RSVP-TE and CR-LDP.
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 RFC 2119.
Wang Hui et. al. Internet-Draft February 2002 1
draft-hwang-gmpls-signaling-parallel-00.txt February 2002
3. Backgroud
The early deployment of WDM technology was in a point-to-point manner
to ease fiber exhaustion. As more advanced systems, such as optical
add/drop multiplexers(OADMs) and optical cross-connects(OXCs) have
matured, and because that both OADMs and OXCs are capable of routing
and switching wavelength,DWDM has become a network-level technology
[1]. GMPLS [2] protocol is known as a its most possible control
plane. GMPLS supports light wavelength switching and can do
lightpath provisioning, protection and restoration. GMPLS is an
effective control plane and with GMPLS merged to optical nodes,we can
get an automatic switched optical network (ASON)[3].
ASON is generally used as the backbone of transport networks. So
there is a restrict requirement for the speed of lightpath provision-
ing, establishing, fault protection and traffic restoration. And
these requirements are all challenges to the control plane. The
control plane should fit these requirements.
GMPLS is assumed to be the control plane for this intelligent all
optical network, which includes two major signaling sets : RSVP-TE[4]
and CR-LDP[5]. Both of the two signaling sets can do lightpath
provisoning, establishing and management jobs. The two signaling
sets are independent and we may only implement either RSVP-TE or CR-
LDP in a given system . But as to the current protocol of RSVP-TE and
CR-LDP, there are problems when the network use either of them to
establish a lightpath because both protocols can cause a big delay
when do lightpath setup and may not fit the restrict requirements of
path establishing speed especailly when the network size is
considerably big.
4. Problems with RSVP-TE or CR-LDP when establishing the lightpath
Both of RSVP-TE and CR-LDP's strategies of doing resource allocation
(more specifically, wavelengh assignment and optical cross-connects
making) for setting up a new lightpath are in serial style. That is
to say, the nodes along a lightpath will do their local resource
allocation one by one. One node won't do its local wavelengh
assignment and optical cross-connect operations unless it receives
the indication message from it downstream neighbor node. When this
node finishes its own local resource allocation successfully, it will
send out a message to its upstream neighbor node to indicating the
upper node's action of resource allocation. For example, in RSVP-TE
protocol stack, one node wont's allocate local resource untill it
receives the RESV message from downstream neighbor node, and when it
succeeds in its own local resource allocation, it will send out a
RESV message to its upstream neighbor node. So we see that the
resource reservation and allocation, or say, wavelength assignment
and optical cross-connects operations, are all done serially along
the lightpath from downstream nodes to upstream nodes.
This serial operation will bring a big delay to the process of
Wang Hui et. al. Internet-Draft February 2002 2
draft-hwang-gmpls-signaling-parallel-00.txt February 2002
establishing a new lightpath, especially when the network size
becomes considerably big and the number of an average lightpath
becomes big. What's more, the wavelength assignment and optical cross-
connects making are all time-consuming operations. Compared with the
signaling message transport delay, these serial resource allocation
operations contribute a big delay to the whole lightpath setup
process. For example, if we assume the delay caused by a single
optical cross-connect operation is C milliseconds, and if there are
totally N nodes at average along a lightpath in a given network,
these serial optical cross-connects operations will cost N*C
milliseconds in sum. If the N is considerably big, this delay will
be unacceptable when we need a fast lightpath provision.
This problem is originally from the serial resource allocation
operations carried with RSVP-TE or CR-LDP. What if we do parallel
resource allocation operations?
5. Do parallel resource allocation with a new indication object
In this draft we proposed a new strategy to setup the lightpath in
the way of doing parallel resource allocation operation along the
nodes in the path. In order to notify the nodes to do parallel
resource allocation, we suggest that we may implement a new object
within the path initial message. We name this object as 'Parallel
Resource Allocation style Object'(PRAO).
For example, when we use RSVP-TE to setup a lightpath, the source
node will firstly send out a PATH message, if it want to use the
strategy of parallel resource allocation it must include a PRAO
object to indicate the nodes along the path to do parallel resource
allocation operations. Here is the rough process of using this
strategy. First the source node sends out a message with a PRAO
object, and at the same time the source node begin to do its local
resouce allocation (wavelength assignment and optical cross-connect
making). When the middle nodes along the path receive this PATH
message and find a PRAO object within it, they will firstly relay
the PATH message to their downstream neighbor nodes (of cource, they
will do some needed modification to the PATH message according to
the standard GMPLS/RSVP-TE protocol), and at the same time they
will do their own local resource allocation operations. In this
way, the PATH message is relayed to the egress node and the egress
node begin to do its local resource allocation operations. After
the egress node's succeeding in its resource allocation, the egress
node will send back the RESV message which will act as an acknowledg-
ing message to PATH message. Of couse, the RESV message will contain
some needed standard GMPLS/RSVP-TE objects. The RESV message is
relayed by the middle nodes and finally arrive at the source node.
When the source node gets this RESV message, the whole lightpath is
successfully established.
In the process described above, the 'Parallel Resource Allocation
style Object'(PRAO) is used to indicate the nodes along the path to
do parallel wavelength assignment and optical cross-connects making
operations. All the nodes will do their own local resource
Wang Hui et. al. Internet-Draft February 2002 3
draft-hwang-gmpls-signaling-parallel-00.txt February 2002
allocation right after they receive the PATH message. Because the
delay of transporting the RSVP-TE signalling messages (such as
PATH message and RESV message) is much smaller than the delay
caused by optical node's cross-connects operations, all the
optical cross-connect operations can be considered to be done
parallelly. This parallel operations will save a lot of time
compared with the current serial operations. In fact, we can
model the whole optical crocss-connects operations along all the
nodes to be a single node's operation at the egress node.
The basic process of using PRAO in RSVP-TE can be changed to CR-LDP
process. The idea is the same.
So we suggest to add a new object named as 'Parallel Resource
Allocation style Object'(PRAO) to the signalling sets. This new
object can be chosen as an option on the occasion when we want to do
fast, parallel lightpath setup. Where there is critical for the path
setup speed, the source node can apply this object.
6. Benefits from the PARO object
With the PRAO object, we can do fast lightpath provision. And what's
more, on occasion where there is a failure and reroute is needed to
perform, we can use this strategy to do fast traffic restoration
based on dynamic protection path setup. The latter path protection
scheme will increase resource utilization because capacity or
bandwidth is not reserved beforehand and because it is available for
use by other (possible lower priority) traffic, when the protection
path dose not require this capacity.
7. Some considerations
The reason to do serial resource allocation as current RSVP-TE does,
is that the node need to make sure the downstream nodes have succeed-
ing in resource allocation. Because if one of the nodes along a
path fails to do its local resouce allocation will cause the failure
of establishing the whole lightpath. But as to our parallel resouce
allocation scheme, the node doesn't verify if the the other node
succeeds in its resouce allocation, what if a request is rejected by
a node? If this kind of failure occurs, the souce node has to
reroute the whole path. If this kind of failure occurs frequently,
this strategy is useless.
So how to avoid this kind of failure? We should consider the actual
running environment. Generally speaking, this kind of all optical
transport networks is used as big transport backbone in the network.
And the topology of this backbone may be known beforehand. So we
can use a good wavelength assignment and optical routing algorithm
to pre- compute all the lightpaths and distribute this path infor-
mation to all the edge nodes. And when the edge nodes want to setup
new light- path, they will simply pickup a right pre-comupted path to
follow from the local database. So there will be no resource
Wang Hui et. al. Internet-Draft February 2002 4
draft-hwang-gmpls-signaling-parallel-00.txt February 2002
allocation failures if the path computation algorithm is good enough.
In fact, this is a famous problem known as 'routing and wavelength
assignment (RWA) problem', and there are already a lot of mature
algorithms to compute the path for a given network and by use of
these RWA alogrithms we can achieve every effective routing and
wavelength assignment[6].
Because the source node will use a computed path to setup the light-
path, we cannot use the traditional hop-by-hop routing scheme,
instead we must use explict routing. So if the source node sends
out a message containing the PRAO object, it must include a Explict
Routing Object (ERO), too.
8. Conclusion and further discussion
This draft presented a basic idea of applying parallel resouce
allocation scheme to lightpath establishing. And a new object,
known as 'Parallel Resource Allocation style Object'(PRAO), is
suggested to add to the GMPLS signalling sets ( RSVP-TE or CR-LDP).
But the specific format of this PRAO object and its interaction
within the optical nodes are not included in this draft. This work
is not done currently, and still needs further discussion.
9. References
1. Nasir Ghani,Sudhir Dixit, Ti-Shiang Wang: "On IP-over-DWDM
Integration", IEEECommunication Magazine, March 2000
2. Eric Mannie, et. al. : "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", draft-ietf-ccamp-gmpls-architecture-00.txt,
Expiration date: May 2002, work in progress.
3. O. Aboul-Magd, et. al. : "Automatic Switched Optical Network
(ASON) Architecture and Its Related Protocols", draft-ietf-ipo-
ason-01.txt,June 2002, work in progress.
4. Peter Ashwood-Smith, et. al : "GMPLS Generalized MPLS Signaling -
RSVP-TE Extensions", draft-ietf-mpls-generalized-rsvp-te-06.txt,
Expiration Date: May 2002, work in progress.
5. Peter Ashwood-Smith, et. al: "GMPLS Generalized MPLS Signaling -
CR-LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-05.txt,
Expiration Date: May 2002, work in progress.
6. H. Zang, J.P. Jue and B. Mukherjeee, "A review of routing and
wavelength assignment approaches for wavelength-routed optical WDM
etworks," Optical Networks Magazine, January 2000.
7. Bala Rajagopalan, et. al: "IP over Optical Networks: A Framework",
draft-ietf-ipo-framework-00.txt, Expires on: 1/13/2002,work in
progress.
Wang Hui et. al. Internet-Draft February 2002 5
draft-hwang-gmpls-signaling-parallel-00.txt February 2002
10. Author's Addresses
Wang Hui
Infonet Lab,EEIS
Univ. of Sci. & Tech. of China
P.O. Box 4
Hefei, Anhui, China, 230027
Phone: +86-551-3603634
Email: whui@mail.ustc.edu.cn
WWW: http://mail.ustc.edu.cn/~whui
Full Copyright Statement
"Copyright (C) The Internet Society (2002). All Rights Reserved. This
document and translations of it may be copied and furnished to others, and
derivative works that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and distributed, in whole
or in part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Wang Hui et. al. Internet-Draft February 2002 6
