Internet DRAFT - draft-xu-l3vpn-rsvp-te-bidirection
draft-xu-l3vpn-rsvp-te-bidirection
L3VPN Working Group Xiaohu Xu
Internet Draft Le Zhang
HUAWEI
Expires: April 2006 October 17, 2005
Bidirectional RSVP-TE Tunnel
draft-xu-l3vpn-rsvp-te-bidirection-01.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 April 17, 2006.
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. The bidirectional RSVP-TE tunnel can be used to
establish L3VPN with virtual router technology.
Xu Expires April 17, 2006 [Page 1]
Internet-Draft Bidirectional RSVP-TE Tunnel 10/17/2005
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 April 17, 2006 [Page 2]
Internet-Draft Bidirectional RSVP-TE Tunnel 10/17/2005
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 April 17, 2006 [Page 3]
Internet-Draft Bidirectional RSVP-TE Tunnel 10/17/2005
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 April 17, 2006 [Page 4]
Internet-Draft Bidirectional RSVP-TE Tunnel 10/17/2005
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 through a
RSVP-TE tunnel and interconnection of two separate LDP-based MPLS
networks through a RSVP-TE tunnel, which is also called as LDP over
TE.
8. Formal Syntax
9. Security Considerations
The bidirectional RSVP-TE tunnel fully inherits all the security
features of RSVP-TE.
Xu Expires April 17, 2006 [Page 5]
Internet-Draft Bidirectional RSVP-TE Tunnel 10/17/2005
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 April 17, 2006 [Page 6]
Internet-Draft Bidirectional RSVP-TE Tunnel 10/17/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 17, 2006 [Page 7]
Internet-Draft Bidirectional RSVP-TE Tunnel 10/17/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.
Xu Expires April 17, 2006 [Page 8]
