L3VPN Working Group Xiaohu Xu Internet Draft HUAWEI Le. Zhang HUAWEI Expires: April 2006 October 1, 2005 Bidirectional RSVP-TE Tunnel draft-xu-l3vpn-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. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may not be modified, and derivative works of it may not be created. This document may only be posted in an Internet-Draft. 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 April 1, 2006. Xu Expires April 1, 2006 [Page 1] Internet-Draft Bidirectional RSVP-TE Tunnel 10/1/2005 Copyright Notice Copyright (C) The Internet Society (2005). 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. Like GRE tunnel, the bidirectional RSVP-TE tunnel can be used to establish L3VPN with virtual router or policy routing technology. In contrast to BGP/MPLS VPN defined in [RFC2547bis], multicast is easier to be implemented and multicast traffics can travel in RSVP-TE tunnel with such L3VPN. This L3VPN fully inherits the property of RSVP-TE, such as TE, QoS and fast convergence features. In addition, the bidirectional RSVP-TE tunnel has many other purposes, such as interconnection of two separate routing domains through a RSVP-TE tunnel and implementing LDP over TE. 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 [ .1]. Table of Contents 1. Introduction................................................3 2. Implementing of bidirectional RSVP-TE tunnel.................4 2.1. Basic principle.........................................4 2.2. Extension to RSVP-TE....................................4 2.3. Procedure of implementing bidirectional RSVP-TE tunnel...5 3. Application of bidirectional RSVP-TE tunnel..................6 4. Formal Syntax...............................................6 5. Security Considerations......................................6 6. Conclusions.................................................7 7. Acknowledgments.............................................7 7.1. Normative References....................................7 7.2. Informative References..................................7 Author's Addresses.............................................8 Intellectual Property Statement.................................8 Disclaimer of Validity.........................................9 Copyright Statement............................................9 Acknowledgment.................................................9 Xu Expires April 1, 2006 [Page 2] Internet-Draft Bidirectional RSVP-TE Tunnel 10/1/2005 1. Introduction [RFC2547bis] specifies a set of procedures to provide an IP unicast VPN service in MPLS/IP networks, which is called BGP/MPLS VPN. But the procedures of BGP/MPLS VPN, especially multicast in BGP/MPLS VPN are complicated. Virtual router technology provides a more easy and flexible procedure to implement L3VPN, which is as follows: first, a GRE tunnel is established between a pair of PEs; second, the GRE tunnel interface and an interface connected to CE with each PE are bound to the same VRF; lastly, some routing protocols can be run over the VRF interfaces and a L3VPN is completed. In such L3VPN, multicast is supported natively as long as multicast routing protocol is enabled on the VRF interfaces. But as GRE tunnel has no properties such as TE, QoS and fast convergence features, the L3VPN implemented on GRE tunnel is not popular with service providers. RSVP-TE is very suitable to provide MPLS VPN service with the requirement of high availability and QoS assurance because it consists of many good features such as TE, QoS and fast convergence. As RSVP-TE tunnel is unidirectional, it can not be used to implement L3VPN through virtual router or policy routing technology as GRE tunnel. This document specifies a procedure to realize bidirectional RSVP-TE tunnel with an extension to RSVP-TE. 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. Like GRE tunnel, the bidirectional RSVP-TE tunnel can be used to establish L3VPN with virtual router or policy routing technology. This L3VPN fully inherits the property of RSVP-TE, such as TE, QoS and fast convergence features. In contrast to BGP/MPLS VPN defined in RFC2547bis, multicast is easier to be implemented in such L3VPN. In addition, the bidirectional RSVP-TE tunnel has many other purposes, such as interconnection between two separate routing domains through a RSVP-TE tunnel and implementing LDP over TE. Xu Expires April 1, 2006 [Page 3] Internet-Draft Bidirectional RSVP-TE Tunnel 10/1/2005 2. Implementing of bidirectional RSVP-TE tunnel 2.1. 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 binding key. 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 binding keys of both tunnels are the same. The reason for making binding key as one of the decision factors is that a LSR can setup different RSVP-TE tunnels with the same pair of tunnel source address and tunnel destination address, but these tunnel interfaces must be configured with different binding keys. 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. Like GRE tunnel, the bidirectional RSVP-TE tunnel can be used to establish L3VPN with virtual router or policy routing technology. The routing protocols, such as OSPF and PIM, can also be run over the bidirectional RSVP-TE tunnel interface. As we all known, the value of TTL field in the header of MPLS frame will be reduced as the frame is transmitted through LSP tunnel in order to avoiding loop in MPLS networks. 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 EXP field of MPLS frame as it enters RSVP-TE tunnel. 2.2. 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) Xu Expires April 1, 2006 [Page 4] Internet-Draft Bidirectional RSVP-TE Tunnel 10/1/2005 0 1 2 3 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 | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Binding Key (NULL padded display string) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. - Key Length: 8 bits, it specifies the length of the field of Binding Key. - Binding Key: a variable-length field, it is used to distinguish the different tunnel interfaces of a LSR with the same pair of tunnel source address and tunnel destination address. 2.3. Procedure of implementing bidirectional RSVP-TE tunnel 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 carry the Binding Key string configured for the tunnel. Middle-hop LSRs process the Path message in ordinary way with the binding object unchanged. As the egress LSR of the tunnel receives the Path message, it will compare the binding decision factors in the message, including tunnel source address, tunnel destination address and binding key with the configure information of local tunnel interfaces. Xu Expires April 1, 2006 [Page 5] Internet-Draft Bidirectional RSVP-TE Tunnel 10/1/2005 If there is a tunnel which matches the above three decision factors, the egress LSR will bind the matched tunnel 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. If there is no matched tunnel, the egress LSR will reply with a Path Error 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 success and the state of tunnel interface will be up. Establishing a return RSVP-TE tunnel with a request of binding from the above egress LSR to the above ingress LSR is in the same way as that mentioned above. Through the above procedures, a bidirectional RSVP-TE tunnel is formed. 3. Application of bidirectional RSVP-TE tunnel Like GRE tunnel, the bidirectional RSVP-TE tunnel can be used to establish L3VPN with virtual router or policy routing technology. This L3VPN fully inherits the property of RSVP-TE, such as TE, QoS and fast convergence features. In contrast to BGP/MPLS VPN defined in RFC2547bis, multicast is easier to be implemented in such a L3VPN. In addition, the bidirectional RSVP-TE tunnel has many other purposes, such as interconnection of two separate routing domains through a RSVP-TE tunnel and interconnection of two separate LDP-base MPLS networks through a RSVP-TE tunnel, which is also called as LDP over TE. The transit network does not need to know the routing information of the separate routing domains. 4. Formal Syntax 5. Security Considerations The bidirectional RSVP-TE tunnel inherits all the security features of RSVP-TE. Xu Expires April 1, 2006 [Page 6] Internet-Draft Bidirectional RSVP-TE Tunnel 10/1/2005 6. 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. 7. 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. 8. References 8.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. 8.2. Informative References [3] [RFC2547bis] Eric C. Rosen, Yakov Rekhter, "BGP/MPLS IP VPNs", "draft-ietf-l3vpn-rfc2547bis-03.txt", October 2004 [4] [RFC 3209] RSVP-TE: Extensions to RSVP for LSP Tunnels Xu Expires April 1, 2006 [Page 7] Internet-Draft Bidirectional RSVP-TE Tunnel 10/1/2005 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 April 1, 2006 [Page 8] Internet-Draft Bidirectional RSVP-TE Tunnel 10/1/2005 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Xu Expires April 1, 2006 [Page 9]