Internet DRAFT - draft-xu-mpls-rsvp-te-bidirection

draft-xu-mpls-rsvp-te-bidirection



L3VPN Working Group                                          Xiaohu Xu 
Internet Draft                                                Le Zhang  
                                                                HUAWEI        
Expires: July 2006                                    January 06, 2006 
                                   
 
                                      
                       Bidirectional RSVP-TE Tunnel 
                 draft-xu-mpls-rsvp-te-bidirection-00.txt 


Status of this Memo 

   By submitting this Internet-Draft, each author represents that       
   any applicable patent or other IPR claims of which he or she is       
   aware have been or will be disclosed, and any of which he or she       
   becomes aware will be disclosed, in accordance with Section 6 of       
   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 July, 2006. 

Copyright Notice 

      Copyright (C) The Internet Society (2006).  All Rights Reserved. 

Abstract 

   Through the binding of two unidirectional RSVP-TE tunnels established 
   between a pair of LSRs destined to each other, a bidirectional RSVP-
   TE tunnel is formed. The bidirectional RSVP-TE tunnel can be used to 
   establish L3VPN with virtual router technology.  


 
 
 
Xu                     Expires July 06, 2006                 [Page 1] 

Internet-Draft      Bidirectional RSVP-TE Tunnel            01/06/2006 
    

Conventions used in this document 

   In examples, "C:" and "S:" indicate lines sent by the client and 
   server respectively. 

   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. 

Table of Contents 

   1. Introduction................................................3 
   2. Basic principle.............................................3 
   3. Extension to RSVP-TE........................................3 
   4. Implementing procedure......................................4 
   5. Compatibility...............................................5 
   6. TTL.........................................................5 
   7. Application.................................................5 
   8. Formal Syntax...............................................5 
   9. Security Considerations.....................................5 
   10. Conclusions................................................6 
   11. Acknowledgments............................................6 
   12. References.................................................6 
      12.1. Normative References..................................6 
      12.2. Informative References................................6 
   Author's Addresses.............................................7 
   Intellectual Property Statement................................7 
   Disclaimer of Validity.........................................8 
   Copyright Statement............................................8 
    
















 
 
Xu                     Expires July 06, 2006                 [Page 2] 

Internet-Draft      Bidirectional RSVP-TE Tunnel            01/06/2006 
    

  1. Introduction 

   [L3VPN-VR] describes a network-based VPN architecture using the 
   virtual router (VR) concept. VRs belonging to the same VPN MAY 
   construct IP-based or MPLS-based tunnels providing connections to 
   each other. They MAY then exchange routing information and VPN 
   traffic over these tunnels. 

   RSVP-TE is very suitable to provide MPLS-based tunnel because it 
   consists of many good features such as TE, QoS and fast convergence. 
   But as RSVP-TE tunnel is unidirectional, it can not be used as tunnel 
   between VRs.  

   This document specifies a procedure to realize bidirectional RSVP-TE 
   tunnel.  

  2. Basic principle 

   Through the binding of two unidirectional RSVP-TE tunnels established 
   between a pair of LSRs destined to each other, a bidirectional RSVP-
   TE tunnel is formed. 

   The decision factors of RSVP-TE tunnel binding include tunnel source 
   address, tunnel destination address and multiplexor. Two 
   unidirectional RSVP-TE tunnels between a pair of LSRs destined to 
   each other will be bound successfully if all these decision factors 
   are matched, that is to say, the tunnel source address of one tunnel 
   is the tunnel destination address of the other one, the tunnel 
   destination address of one tunnel is the tunnel source address of the 
   other one, and the multiplexors of the two tunnels are the same. The 
   reason for making multiplexor as one of the decision factors is that 
   a pair of LSRs can setup many RSVP-TE tunnels with the same pair of 
   tunnel source address and tunnel destination address. 

   In order to identify through which tunnel a received packet is 
   transmitted by the egress LSR, penultimate-hop-popping (PHP) function 
   must be disabled on egress LSR. 

  3. Extension to RSVP-TE 

   Signaling the bidirectional RSVP-TE tunnel requires an extension to 
   RSVP-TE. A new binding object is added to RSVP-TE message, the format 
   of which is defined as follows:  

   Class = TBD(not defined) C_Type = TBD(not defined) 

    0                   1                   2                   3 
 
 
Xu                     Expires July 06, 2006                 [Page 3] 

Internet-Draft      Bidirectional RSVP-TE Tunnel            01/06/2006 
    

    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 

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   |          Reserved             |      Flag     |  Binding Key  | 

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The definition of the above fields is as follows: 

   - Reserved: 16 bits, it must be zero. 

   - Flag: 8 bits, the value 0x1 means requesting binding, which is 
   available only in Path message, and the value 0x2 means confirming 
   binding, which is available only in Resv message.   

   - Binding Key: 8 bits, it is used as multiplexor.                    

  4. Implementing procedure  

   When a LSR initializes a RSVP-TE tunnel with a request of binding, it 
   will send a RSVP Path message with the extension mentioned above, and 
   the Flag field of which is set to 0x1 and the Binding Key field 
   carries the Binding Key string configured for the tunnel interface.  

   Middle-hop LSRs process the Path message in ordinary way with the 
   unknown binding object transmitted. 

   As the egress LSR of the tunnel receives the Path message, it will 
   compare the binding decision factors within the message with the 
   configuration of local tunnel interfaces. If there is a matched 
   tunnel interface, no matter whether it is up or not, the egress LSR 
   will bind the matched tunnel interface with the tunnel initialized by 
   the ingress LSR, and reply a RSVP Resv message with the extension 
   mentioned above, and the Flag field of which is set to 0x2, and the 
   assigned label in the RSVP Resv message is a local unique label, but 
   not implicit null label or explicit null label. If there is no 
   matched tunnel, the egress LSR will reply with a Path-Err message 
   with a special error type code of binding failure which is to be 
   defined. 

   When the Resv message is received by the ingress LSR, it will know 
   the binding is successful and the state of tunnel interface will be 
   up. 



 
 
Xu                     Expires July 06, 2006                 [Page 4] 

Internet-Draft      Bidirectional RSVP-TE Tunnel            01/06/2006 
    

   Establishing a return RSVP-TE tunnel with a request of binding is in 
   the same way as that mentioned above. Through the above procedures, a 
   bidirectional RSVP-TE tunnel is formed.  

  5. Compatibility 

   In contrast with the procedure of bidirectional TE tunnel defined in 
   GMPLS related draft [RFC 3473], there is no additional requirement on 
   middle-hop LSRs here. The middle-hop LSRs only need to transit the 
   unknown binding object. In addition, the modification of RSVP-TE is 
   small relatively and the path of two opposite tunnel can be different. 

  6. TTL 

   [RFC3031] defined TTL as a way to suppress loops in MPLS networks. 
   The value of TTL field in the header of MPLS frame will be reduced as 
   it travels through LSP tunnel. Generally the TTL value of protocol 
   packet is set to 1. In order to run routing protocol, such as OSPF or 
   PIM, over bidirectional RSVP-TE tunnel interface, the TTL value of 
   routing protocol packet with TTL of 1 should not be copied to the TTL 
   field of MPLS frame as it enters RSVP-TE tunnel. 

  7. Application 

   The bidirectional RSVP-TE tunnel can be used to establish L3VPN with 
   virtual router technology. This L3VPN fully inherits the property of 
   RSVP-TE, such as TE, QoS and fast convergence features. In addition, 
   the overheads of IP based tunnel encapsulations such as GRE, IP in IP 
   are avoided. 

   In addition, the bidirectional RSVP-TE tunnel has many other purposes, 
   such as interconnection of two separate routing domains via bidiretional
   TE tunnel and LDP over TE. BFD can be deployed between the bidirectional 
   TE interfaces in order to achieve fast switchover of hot standby LSP.
    
  8. Formal Syntax 

  9. Security Considerations 

   The bidirectional RSVP-TE tunnel fully inherits all the security 
   features of RSVP-TE. 





 
 
Xu                     Expires July 06, 2006                 [Page 5] 

Internet-Draft      Bidirectional RSVP-TE Tunnel            01/06/2006 
    

  10. Conclusions 

   According to the special decision factors, two unidirectional RSVP-TE 
   tunnels established between a pair of LSRs destined to each other can 
   be bound to form a bidirectional RSVP-TE tunnel. 

  11. Acknowledgments 

   The authors would like to thank Xudong Liang, Shuibo Li and Yu Yi for 
   the enlightening discussions that helped shape the ideas presented 
   here. 

  12. References 

  12.1. Normative References 

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
         Levels", BCP 14, RFC 2119, March 1997. 

   [2]  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 
         Specifications: ABNF", RFC 2234, Internet Mail Consortium and 
         Demon Internet Ltd., November 1997. 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 
             Syntax Specifications: ABNF", RFC 2234, Internet Mail 
             Consortium and Demon Internet Ltd., November 1997. 

  12.2. Informative References 

   [3]  [L3VPN-VR] Paul Knight,"draft-ietf-l3vpn-vpn-vr-02.txt", April 
         2004 

   [4]  [RFC 3209] RSVP-TE: Extensions to RSVP for LSP Tunnels 

   [5]  [RFC 3473] L. Berger, "Generalized Multi-Protocol Label 
         Switching (GMPLS) Signaling", January 2003 







 
 
Xu                     Expires July 06, 2006                 [Page 6] 

Internet-Draft      Bidirectional RSVP-TE Tunnel            01/06/2006 
    

Author's Addresses 

   Xiaohu Xu 
   HUAWEI 
   Hua Wei Bld.,No.3 Xinxi Rd., 
   Shang-Di Information Industry Base 
   Hai-Dian District 
   Beijing P.R.China 
      
   Phone: +86 010 82882457 
   Email: xuxh@huawei.com 
    

   Le Zhang 
   HUAWEI 
   Hua Wei Bld.,No.3 Xinxi Rd., 
   Shang-Di Information Industry Base 
   Hai-Dian District 
   Beijing P.R.China 
      
   Phone: +86 010 82882457 
   Email: zhangle@huawei.com 
    

Intellectual Property Statement 

   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 

   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at 
   ietf-ipr@ietf.org 
 
 
Xu                     Expires July 06, 2006                 [Page 7] 

Internet-Draft      Bidirectional RSVP-TE Tunnel            01/06/2006 
    

Disclaimer of Validity 

   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM 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. 

Copyright Statement 

   Copyright (C) The Internet Society (2005). 

   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 





























 
 
Xu                     Expires July 06, 2006                 [Page 8]