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