Network Working Group Yang Hui
Internet Draft Jiang Weilian
Shen Xiaofeng
Expiration Date: Apr. 2007 Feng Jun
Teng Zhimeng
ZTE, Inc.
Oct. 2006
Resource-sharing Method for MBB CSPF by RSVP-TE
draft-yang-mpls-resouce-sharing-mbb-cspf-00
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.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document is based upon RSVP MBB（make-before-break）defined in RFC3209,
providing a method to realize resource-sharing between old path and new
path while RSVP-TE calculating a new path using CSPF in MBB manner.
1. Specification of Requirements
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].
yang Expires: Apr. 2007 [Page 1]
Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006
2. Terminology
This document follows the nomenclature of the MPLS Architecture defined in
[RFC3031].
2.1 Acronyms and Abbreviations
CSPF Constraint-based Shortest Path First.
LSR Label Switching Router
LSP Label Switched Path[y1]
MPLS MultiProtocol Label Switching
RSVP Resource ReSerVation Protocol
TE Traffic Engineering
TE LSP Traffic Engineering Label Switched Path
3. Introduction
As to the current applications of RSVP-TE, MBB mechanism is always to be
adopted while finding optimum route, or detecting faults in original lsp,
or restoring the lsp to the recovered path which was invalid before, or
expanding the bandwidth of tunnel etc.
MBB, Make Before Break, is a technique used to non-intrusively alter the
path of a TE LSP. The ingress LER first signals the new path, sharing the
bandwidth with the primary TE LSP (to avoid double booking), then
switches forwarding over to a new path. Finally the old path state is
torn down.
As defined in RFC3209, in MBB mechanism, the new lsp need share bandwidth
with the old lsp when routing and reserving. RSVP-TE may use SE mode
defined in RFC2205 to guarantee MBB sharing the reserved resources of old
path on the overlapping links when reserving. However, CSPF is only aimed
to calculate the optimum path by current link info and tunnel request.
Because the current link info does not save the resource reservation info
of the old path, in some cases, the new path calculation might fail or
provides the path which is not the optimum one.
In the following two situations, CSPF will exit the problems mentioned
above.
R1---10M----R2 R1---4M----R2
（Fig. 1-1） （Fig. 1-2）
In the network depicted above in figure 1-1, it establishes a tunnel 1
from R1 to R2 with its bandwidth as 6M. After the tunnel is established,
its bandwidth is changed into 9M. The info of link from R1 to R2 in CSPF
is shown in Fig.1-2(the available bandwidth of link R1->R2 is 4M, not meet
the requirement of 9M), and therefore CSPF path-calculating fails. So by
traditional RSVP-TE, this mbb will fail in CSPF.Obviously, the bandwidth
is able to meet the bandwidth requirement for MBB to reestablish tunnel.
If we improve the CSPF calculation of MBB, such error will be avoided.
R1--20M---R2---15M----R4 LSP1:
\ / R1---R2-->R4
15M 15M
\ /
R3
（Fig. 2-1）
yang Expires: Apr. 2007 [Page 2]
Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006
R1--15M---R2---10M----R4 LSP1: LSP2:
\ / R1---R2-->R4 R1---R2 R4
15M 15M \ /
\ / R3
R3
（Fig. 2-2）
In the network depicted above in figure 2-1, the bandwidth of R1 interface
is 20M, and TE bandwidths of R2, R3 and R4 are 15M respectively. Establish
a Tunnel 2 from R1 to R4 with its bandwidth as 5M and R2 as the loose node.
CSPF gived the path as LSP1 in Fig. 2-1. Now the bandwidths is shown in
Fig. 2-2. Then change the bandwidth of tunnel 2 into 15M, by traditional
RSVP-TE, CSPF will give the new path as LSP2 in Fig 2-2. Obviously, this
path is not the optimumest path that meets the constraint condition. If
being re-optimized after MBB, the tunnel 2 will switch to the path as LSP1
in Fig. 2-1.
As CSPF exists the above problems in MBB, this draft provides a method for
RSVP-TE in order to guarantee CSPF share the bandwidth with the old path when
calculating the new path in MBB, at the same time, the bandwidth will not
be available to the calculation for other tunnels.
4. The Resource-sharing Method for MBB CSPF by RSVP-TE
4.1. Solution
When adopting CSPF to calculate new path in MBB, RSVP-TE not only provides
the requirement of establishing a new path but also introduces the info of
strict route and bandwidth of old path etc. CSPF will make use of these
resource info to share the resources the old path has occupied when
calculating the new path, and thus MBB mechanism is able to establish the
optimum path successfully. As to how CSPF makes use of the resource info
of old path RSVP-TE provided to calculate the new path, it is not the key
point of this document. Here we assume to adopt the following method:
CSPF adds the resource info of the old path into a temporary link library
of TE link and the info is just used for the calculation this time
but not be notified outside, which will be restored after the path calculation
immediately.
The key point is: it is necessary to introduce the strict bandwidth info
of the old path, that is to say,the info of all the nodes that the old path
has passed must be included according to the saved ERO. If ERO of the old
path contains loose nodes, it is necessary to encapsulate the resource
info in the following way: at the head node,encapsulate the info between
the head node and the first loose node; at each loose node, encapsulate the
info between itself and the next loose node or the end node.
In the following, we’ll explain the details about the method advanced in
this draft.
4.2. Processing at the Head Node
In the network depicted above in figure 1-2, the bandwidth of tunnel 1 is
changed into 9 M. RSVP-TE adopting MBB mechanism to reestablish tunnel
encapsulate the requirement info of bandwidth（9 M） to CSPF as well as the
yang Expires: Apr. 2007 [Page 3]
Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006
strict path bandwidth info of the old path（<Interface 1 of R1,6M>,
Interface 1 of R2）;Thus, CSPF formed a temporary TE info database and the
temporary bandwidth of Interface 1 of R1 is 10M. The temporary bandwidth is
only used for MBB reestablishment of Tunnel 1,and the interface bandwidth
will recover to 4M after this path calculation. Then the
optimum path（Interface 1 of R1->R2) that satisfies the condition of
constraint-based bandwidth will be obtained. RSVP-TE will implement resource
reservation along this path in SE mode till new tunnel establishes, and then
break the old path. Thus, MBB mechanism Tunnel reestablishment successfully
completes.
4.3. Processing at the Loose Node
In the network depicted above in figure 2-2, the bandwidth of tunnel 2 is
changed into 15M. RSVP-TE adopts MBB mechanism to reestablish tunnel.
The head node R1 encapsulates the requirement info of tunnel 2
（15M,loose route R2） to CSPF as well as the strict path bandwidth info of
the old path（<Interface 1 of R1,5M>,Interface 1 of R2, R2, R4）; as
tunnel 2 designates R2 as Loose node, and the old path info in ERO contains
Loose node R2, in order to obtain strict bandwidth info of the old path,
The old path info（<Interface 2 of R2, 5M>,Interface 1 of R4） should be
re-encapsulated to CSPF on R2. Thus, at Node R1 and R2,before CSPF calculating
path, it distributes two temporary bandwidth 20M and 15M to corresponding
interfaces(the interface 1 of R1 and interface 2 of R2). Then
the optimum path that satisfies the condition of constraint-based bandwidth
will be obtained.（See the path LSP2 showed in Fig. 2-2）, RSVP-TE will
implement resource reservation along this path till new tunnel establishes,
and then tear down the old path. Thus, MBB mechanism Tunnel reestablishment
successfully completes and the new path is constraint-based optimum one.
5. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights, which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
6. Disclaimer of Validity
This document and the information contained herein are provided on an
yang Expires: Apr. 2007 [Page 4]
Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006
"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.
7. Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
8. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434.
[MPLS-ARCH] Rosen, Viswanathan, Callon, "Multiprotocol Label
Switching Architecture", RFC3031, January 2001.
[RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) -
version 1 functional specification," RFC2205, September 1997.
[RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, December 2001.
9.Author Information
Yang Hui
ZTE Inc.
CHINA
Email: yang.hui6@zte.com.cn
Jiang Weilian
ZTE Inc.
CHINA
Email: jiang.weilian@zte.com.cn
Shen Xiaofeng
ZTE Inc.
CHINA
Email: shen.xiaofeng@zte.com.cn
Feng Jun
ZTE Inc.
CHINA
Email: Feng.jun99@zte.com.cn
yang Expires: Apr. 2007 [Page 5]
Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006
Teng Zhimeng
ZTE Inc.
CHINA
Email: teng.zhimeng@zte.com.cn
yang Expires: Apr. 2007 [Page 6]
Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006