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]