Internet DRAFT - draft-wang-mpls-rsvp-te-pro

draft-wang-mpls-rsvp-te-pro




                                                

Network Working Group                                       J.P.Wang  
INTERNET-DRAFT                                              L.J.Tang
Intended status: Informational                               U.S.T.B
Expires: June 12, 2011                             December 12, 2010 
                   
   A RSVP-TE Reservation Protocol Based on Priority in Multi-Domain 
                         Optical Network 
                  draft-wang-mpls-rsvp-te-pro-01
                   
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 June 12, 2011.
               
Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.
                  
                
               
                
                
Wang&Tang              Expires - June 12 2011               [Page 1] 
Internet-Draft    RSVP-TE protocol based on priority       December 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 - June 12 2011               [Page 2] 
Internet-Draft    RSVP-TE protocol based on priority      December 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 - June 12 2011               [Page 3] 
Internet-Draft    RSVP-TE protocol based on priority      December 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 - June 12 2011               [Page 4] 
Internet-Draft    RSVP-TE protocol based on priority      December 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 - June 12 2011               [Page 5] 
Internet-Draft    RSVP-TE protocol based on priority      December 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 - June 12 2011               [Page 6] 
Internet-Draft    RSVP-TE protocol based on priority      December 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 - June 12 2011               [Page 7] 
Internet-Draft    RSVP-TE protocol based on priority      December 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 - June 12 2011               [Page 8] 
Internet-Draft    RSVP-TE protocol based on priority      December 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 - June 12 2011               [Page 9] 
Internet-Draft    RSVP-TE protocol based on priority      December 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 - June 12 2011               [Page 10]