Network Working Group J.P.Wang INTERNET-DRAFT L.J.Tang Intended status: Informational U.S.T.B Expires: October 9, 2010 April 9, 2010 A RSVP-TE Reservation Protocol Based on Priority in Multi-Domain Optical Network draft-wang-mpls-rsvp-te-pro-00 Abstract ASON (Automatic Switch Optical Network), which provides fast and dynamic connection from point to point, is the typical representation of the next generation intelligent optical network. There are two main kinds of resource reservation protocols in RSVP-TE (Resource Reservation Protocol-Traffic Engineering), the most widely applied signaling in ASON, which are FRP (forward reservation protocol) and BRP (backward reservation protocol). Both of them are used to apply in single-domain optical network. However, when they are used in multi-domain optical network, there are apparent drawbacks. On base of FRP and BRP, we propose a reservation protocol-IDRPBP, which is based on priority in multi-domain optical network with wavelength conversion implement at border nodes. Through analysis and simulation, we find it can achieve the trade-off between blocking probability and connection setup time. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on October 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Wang&Tang Expires - October 9 2010 [Page 1] Internet-Draft RSVP-TE protocol based on priority April 2010 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 BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Wang&Tang Expires - October 9 2010 [Page 2] Internet-Draft RSVP-TE protocol based on priority April 2010 Table of Contents 1. Terminology....................................................4 2. Introduction...................................................4 3. Reservation Protocol In Single-Domain..........................4 3.1 Forward reservation protocol-FRP...........................4 3.2 Backward reservation protocol-BRP..........................4 4. The Proposed Resource Reservation Protocol.....................5 4.1 Temporary Reservation......................................6 4.2 Confirmation...............................................6 5. Steps Of The IDRPBP Algorithm..................................7 6. Analysis Of The IDRPBP.........................................8 7.Security Considerations.........................................9 8. IANA Considerations............................................9 9.References......................................................9 Author's Addresses...............................................10 Wang&Tang Expires - October 9 2010 [Page 3] Internet-Draft RSVP-TE protocol based on priority April 2010 1. Terminology 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]. This document uses terms from [RFC3261][1]. 2. Introduction ASON[2] is the next generation intelligent optical network, which can provide automatic connection setup and switch. It was first proposed by ITU-T in Japan, 2003, and then with fast development in recent years, it has become the main stream of the next optical network. Signaling technology is one of the crucial technologies that can accomplish the functions in control plane of ASON. ITU-T has recommended three types of signaling protocols, which include PNNI, RSVP-TE and CR-LDP. IETF has extended RSVP-TE and CR-LDP in GMPLS (Generalized Multi-Protocol Label Switching). In this three signaling protocols, RSVP-TE was first designed for IP network before being modified and extended by GMPLS[3][4], so it is adopted by the majority of operators and becomes the most widely applicable signaling. In this text, we use RSVP-TE for our research. In real network, with the expansion of network scale and the promotion of service, there is such a need to divide a large single- domain into some small domains in order to provide dynamic services, since various network operators use different equipments, transport technologies and management. In multi-domain network, each small single-domain could use its own of signaling, routing, etc. They change and transport information by E-NNI between each of them. Therefore, study how the technologies, such as signaling, routing, can be used in multi-domain optical network is very important for the development of intelligent optical network. There are several resource reservation protocols of RSVP-TE used in single-domain, however, neither of them is appropriate for multi- domain. Since the optical network is tranformated from single-domain to multi-domain, we need to find a new resource reservation protocol suitable for it. There are two main types of resource reservation protocols in RSVP-TE, which are FRP and BRP[5][6]. Both of them have apparent drawbacks used in multi-domain. On base of FRP and BRP, we propose a reservation protocol named Inter-Domain Reservation Protocol Based on Priority (IDRPBP), which achieves the trade-off between blocking probability and connection setup time in the network with wavelength conversion at border nodes. 3. Reservation Protocol In Single-Domain The reservation protocols are used for wavelength reservation and configuration during the connection setup process in the optical network. As we know, FRP and BRP are the two basic types in single- domain. Before proposing the IDRPBP, we take a review of FRP and BRP. 3.1 Forward reservation protocol-FRP In FRP, when a client sends a connection setup request at the source node, it first finds whether there is free wavelength in the outgoing link. If there is, the source node puts the free wavelengths into the Path message and reserves them. The free wavelengths reserved can't be used by any other request until they are released. If not, it sends a PathErr message. When the Path message is sent to the intermediate node, the node searches for the free wavelengths in the outgoing link, obtains the intersection of the wavelengths between the new free wavelengths and the ones in the Path message and puts the intersection into the Path message instead of the ones that is already in it. Then the node reserves the intersection of the wavelengths and sends the Path message to the next node. If there is either no free wavelengths or no intersection, the node sends a PathErr message. When the destination node receives the Path message, it selects a wavelength and puts it into the Resv message, then sends the message upstream to notify every node to use this wavelength and release the others which has been reserved. When the source node receives the Resv message, the connection setup process is completed and data can be transported. The connection setup process is shown in Figure 1. Src Mid Mid Des | Path | | | |---------------------->| | | | | Path | | | |---------------->| | | | | Path | | | | ---------------->| | | | Resv | | | | <----------------| | | Resv | | | |<----------------| | | Resv | | | |<--------------------- | | | | Path | | | |---------------------->| | | | | Path | | | |---------------->| | | | PathErr | | | |<----------------| | | PathErr | | | |<--------------------- | | | Figure 1: FRP connection setup process As a setup request reserves all the free wavelengths, the others can not reserve them again until the request release them, so FRP has higher blocking probability and shorter connection setup time. 3.2 Backward reservation protocol-BRP The main difference between BRP and FRP is that the node sending the Path message to another node doesn't reserve the free wavelengths for the request in BRP. The Path message just takes the intersection of the free wavelengths to the destination node for selection. Therefore, the free wavelength may not be available at one certain node when the upstream Resv message which carries the wavelength arrives at the node. In this case, the node will send a ResvErr message to the destination node. Then, the destination node selects another wavelength from the intersection and sends the Resv message upstream again. The connection setup process is shown in Figure 2. Wang&Tang Expires - October 9 2010 [Page 4] Internet-Draft RSVP-TE protocol based on priority April 2010 Src Mid Mid Des | Path | | | |---------------------->| | | | | Path | | | |---------------->| | | | | Path | | | | ---------------->| | | | Resv | | | | <----------------| | | Resv | | | |<----------------| | | Resv | | | |<--------------------- | | | | Path | | | |---------------------->| | | | | Path | | | |---------------->| | | | | Path | | | | ---------------->| | | | Resv(l1) | | | | <----------------| | | Resv(l1) | | | |<----------------| | | | ResvErr | | | |---------------->| | | | | ResvErr | | | | ---------------->| | | | Resv(l2) | | | | <----------------| | | Resv(l2) | | | |<----------------| | | Resv(l2) | | | |<--------------------- | | | Figure 2: BRP connection setup process Since every request is allowed to enter the domain to search for free wavelength but does not reserve any wavelength during the Path process, BRP has longer connection setup time and lower blocking probability compared with FRP. 4. The Proposed Resource Reservation Protocol On base of FRP and BRP, we propose a new resource reservation protocol-IDRPBP used in multi-domain optical network with wavelength conversion at border nodes. Our reservation protocol includes two parts: temporary reservation and confirmation. Wang&Tang Expires - October 9 2010 [Page 5] Internet-Draft RSVP-TE protocol based on priority April 2010 4.1 Temporary Reservation According to different characters of services which need to cross multi-domain, we allocate one figure from 0 to 7 for each service connection setup request, representing different priorities. 7 is the highest one. For example, an inter-domain request arrives at the entrance node of Domain-1, which wants to set up a connection to Domain-n. First, if its priority is not higher than the one in the entrance node, it sends a PathErr message to the source node; otherwise, the priority is put into the entrance node and the request is allowed to enter the domain. Second, within Domain-1, the request temporarily reserves a free wavelength by BRP and completes its intra-domain connection. The free wavelength can't be reserved by any other inter-domain request, except for the intra-domain request. As for an intra-domain request, when it arrives at the entrance node of a certain domain and finds that there is a wavelength on its route which is temporarily reserved by an inter-domain request but not confirmed to reserve yet, it can temporarily use the wavelength to transmit its data without spending time on finding another free wavelength until the wavelength is confirmed to reserve so that we can dynamically make use of the wavelength resources. Third, the border node of Domain-1 sends a Path message downstream to the next domain to temporarily reserve the free wavelength and complete intra- domain connection like performing in Domain-1 until to Domain-n. 4.2 Confirmation The destination sends a Resv message upstream to each domain to confirm to reserve the free wavelength, delete the priority of the request in the entrance node and complete the inter-domain connection. The whole process is shown in Figure 3. Wang&Tang Expires - October 9 2010 [Page 6] Internet-Draft RSVP-TE protocol based on priority April 2010 Domain-1 Domain-2 ........ Domain-n |pri:higher | | | | | | Path | | | | | |-----------> | | | | | |Resv(l1) | | | | | |<----------- | | | | | | ResvConf | | | | | |-----------> | Path | | | | | |----------> | | | | | | PathErr |pri:lower | | | | PathErr |<---------- | | | | |<----------- | | | | | |pri:higher | | | | | | Path | | | | | |-----------> | | | | | |Resv(l1) | | | | | |<----------- | | | | | | ResvConf | | | | | |-----------> | Path | | | | | |----------> |pri:higher | | | | | | Path | | | | | |-----------> | | | | | | Resv(l2) | | | | | |<----------- | | | | | | ResvConf | | | | | |-----------> | Path | | | | | |---------> |pri:higher | | | | | | Path | | | | | | ------------>| | | | | | Resv(l3) | | | | | |<------------ | | | | | Resv | | | | | Resv |<--------- | | | | Resv |<------------ | | | | Resv |<---------- | | | | |<------------| | | | | | | | | | | Figure.3. IDRPBP connection setup process 5. Steps Of The IDRPBP Algorithm Step 1: Compare the priority of the connection setup request with the ones that have already been in the source node of the source domain. If the priority of the connection setup request is the highest one, it is put into the source node and the request is allowed to enter the domain. Else, send the PathErr message. Wang&Tang Expires - October 9 2010 [Page 7] Internet-Draft RSVP-TE protocol based on priority April 2010 Step 2: When the request is allowed to enter the domain. BRP is used to reserve a free wavelength in the domain, and then the Path message is sent to the next domain. Step 3: When the Path message arrives at the next domain. It acts the same as step 1 and step 2 to judge the priority which is in the Path message, reserve a free wavelength within the domain and send the Path message to the next domain. Step 4: When the Path message arrives at the destination node, the node sends the Resv message upstream to reserve a free wavelength in its domain and notifies the other domains to delete the priority of the request. Step 5: When the Resv message arrives at the source node, the connection is setup. 6. Analysis Of The IDRPBP In multi-domain optical network, the resource reservation protocol has much to do with the data transmission. The resource reservation protocols used in single-domain like FRP and BRP are not appropriate for multi-domain network, because they don't have the right rules for data transmission. In FRP, as a setup request reserves all the free wavelengths, the others can not reserve them again until the request releases them, so FRP has higher blocking probability. While, in BRP, since each request doesn't reserve any wavelength in Path process, when they come back to notify every node to reserve a wavelength for their light path, the wavelength may be already reserved. So BRP has longer connection setup time. In IDRPBP, we follow three principles: first, to any request, if one comes earlier, it can reserve the resource earlier, and others must wait in sequence; second, if a request has reserved a wavelength, the others can't reserve it again; third, if a request has the higher priority, it can be allowed to reserve the resource and need not to wait. So when a request has the highest priority, it can have the shorter connection setup time and if it has the lowest priority, the network can have the lower blocking probability. Therefore, our protocol achieves the trade-off between blocking probability and connection setup time. Regard to connection setup time, as IDRPBP uses wavelength conversion at border nodes, it acts like BRP to reserve wavelength in each domain, so if there is something wrong in Resv process, its reservation time is shorter than BRP's. In addition, because the number of requests of IDBPRP is smaller than BRP's and the distance of Path is much shorter than BRP's, so the probability of something wrong in Resv process is smaller than BRP's. Therefore the connection setup time of IDRPBP is shorter than BRP's. Wang&Tang Expires - October 9 2010 [Page 8] Internet-Draft RSVP-TE protocol based on priority April 2010 Regard to blocking probability, as we know, BRP outperforms FRP. As IDRPBP uses the priority, the number of requests in each domain was between BRP's and FRP's, so its network resource utility is smaller than BRP's, but bigger than FRP's. If the priorities decline in sequence, the connection setup time is like FRP when several requests comes; else when the priorities increase in sequence, the blocking probability is like BRP. Therefore the blocking probability of IDRPBP is between that of BRP and FRP. In IDRPBP, by using BRP in a single-domain, we reduce the blocking probability comparing with using FRP. However, BRP has longer connection setup time. So we use the priority to allow more than one request to enter a domain, in order that we can lower the connection setup time of BRP. To a certain connection setup request, if its priority is high enough, it will have the shorter connection setup time like FRP. The higher the priority is, the shorter the connection setup time is; if its priority is too low, the network will have the lower blocking probability like BRP. Compared with FRP and BRP by simulation, IDRPBP not only has the low blocking probability, but also has the short connection setup time. 7.Security Considerations The presence of the Reason header in a response does not affect the treatment of the response. Including such a header by an untrusted entity could adulterate the reactions of the originating entities. E.G. sending back a cause value "87" can cause an announcement within the PSTN/ISDN saying that the call was rejected due to the Closed User Group service. Therefore it is RECOMMENDED to include the Reason header information in Responses only by trusted entities as it is described within [RFC3325][7]. 8. IANA Considerations This document does not have any implications for IANA. 9.References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] ITU-T Recommendation G. 8080/ Y. 1304 , Architecture for the automatically switched optical network (ASON)[S]. ITU, Nov, 2001. [3] BERGER L. RFC347, Generalized multi-protocol label switching (GMPLS) signaling functional description[S]. 2003. [4] BERGER L. RFC3473, Generalized multi-protocol label switching signaling resource reservation protocol-traffic engineering (RSVP- TE) Extensions[S]. 2003. [5] YONG Y, KUO G S, "Label distribution in GMPLS-based wavelength- routed networks", Communications, Vol.3 of ICC (IEEE International Conference, Seoul, 2005), pp.1697-1701. Wang&Tang Expires - October 9 2010 [Page 9] Internet-Draft RSVP-TE protocol based on priority April 2010 [6] ZHANG H ,MA Y,MAO D F , et al , "Comparative study of signaling and routing schemes in ASTN" Proceedings of SPIE, Vol.5625 of SPIE(International Society Optical Engineering, Beijing, 2004) pp.1011-1021. [7] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. Authors' Addresses Jianping Wang University of Science and Technology Beijing NO.30 XueYuan Road, HaiDian, Beijing 100083 P.R China Phone: +86 13466764902 Email: 252788779@qq.com Wang&Tang Expires - October 9 2010 [Page 10]