Network Working Group Cui Ying
Internet Draft Jiang Weilian
Feng Jun
Expiration Date: Jul. 2007 Teng Zhimeng
Zhang Chaofeng
ZTE, Inc.
Jan. 2007
Reoptimization of Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) loosely routed Label Switch Path (LSP) Locally
draft-cui-ccamp-te-loose-reopt-local-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.
This Internet-Draft will expire on Jul , 2007.
Copyright Notice
Copyright (C) The Internet Society (2007).
Abstract
This document defines a mechanism for the local reoptimization of
loosely routed MPLS and GMPLS (Generalized Multiprotocol Label
Switching) Traffic Engineering (TE) LSPs signaled with RSVP-TE.This
behavior of reoptimization is happened at loose node ,but not the
ingress node .
cui Expires: Jul. 2007 [Page 1]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007
Table of Contents
1. Terminology...................................................3
1.1 Acronyms and Abbreviations................................3
2. Introduction..................................................3
3. Signaling extensions..........................................4
3.1. Extension Attributes Flags TLV...........................5
3.2. RRO IPv4/IPv6 Sub-object Flags...........................6
4. Mode of operation.............................................6
4.1. Head-end reoptimization control..........................6
4.1.1. process PATH message................................6
4.1.2. process RESV message................................7
4.2. Process after reoptimization triggers....................7
4.2.1. Process PATH message................................7
4.2.2. Process RESV message...............................8
4.2.3. Process PATH TEAR message...........................9
4.3. Process ERROR message ...................................9
5. Multicast local reoptimiaiton.................................9
6. Intellectual Property Statement...............................9
7. Disclaimer of Validity.......................................10
8. Full Copyright Statement.....................................10
9. References...................................................10
10.Author Information...........................................11
cui Expires: Jul. 2007 [Page 2]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007
1. Terminology
This document follows the nomenclature of the MPLS Architecture
defined in [RFC3031] and [LOOSE-REOPT].
1.1 Acronyms and Abbreviations
This document follows the nomenclature defined in [LOOSE-REOPT]
New add :
local reoptimization: optimize a tunnel by loose node, not the
ingress nodes.
loose area: the traffic engineering area between loose nodes.
2. Introduction
This document defines a mechanism for the reoptimization of loosely
routed MPLS and GMPLS (Generalized Multiprotocol Label Switching)
Traffic Engineering LSPs signaled with RSVP-TE (see [RFC3209] and
[RFC3473]). A loosely routed LSP , defined in [LOOSE-REOPT],
that does not contain a full explicit route identifying each
LSR along the path of the LSP at the time it is signaled by the
ingress LSR. Such an LSP is signaled with no ERO, with an ERO that
contains at least one loose hop, or with an ERO that contains an
abstract node that is not a simple abstract node (that is, an
abstract node that identifies more than one LSR).
Although, IETF provides a method to solve the reoptimization of
loosely routed TE LSP, [LOOSE-REOPT], which is when the loose node
find the more optimal path , it will use notify message to inform
the TE LSP head-end, then TE LSP head-end use the method of “make
before break” to create a new tunnel. when the new tunnel is
created successfully,then TE LSP head-end will delete the old path.
But this method has some problems. Firstly, if loose node is far
away form TE LSP head-end , there are some middle nodes between TE
LSP head-end and the loose node, and the signal of reoptimization
will spend long time, at the same time, the middle nodes which do
not have more optimal path have to compute path also, and this will
increase the signaling load of the whole network. Secondly, the
loose node needs to inform the ingress LSR that the tunnel needs to
be re-optimized, but the notify message may be lost. Although using
reliable message is a good idea, but all of the nodes on the tunnel
must support reliable message. So, based on these problems, this
document suggests loose node re-optimization method locally, which
can resolve these problems properly.
This document supposes that the readers of the document are familiar
cui Expires: Jul. 2007 [Page 3]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007
whth [LOOSE-REOPT], and in order to preserve integrity , the document
cite narration from [LOOSE-REOPT].
An example of an explicit loosely routed TE LSP signaling.
<---area 1--><-area 0--><-area 2->
R1---R2----R3---R6 R8---R10
| | | / | \ |
| | | / | \ |
| | | / | \|
R4---------R5---R7----R9---R11
Assumptions
- R3, R5, R8 and R9 are ABRs
- The path of an inter-area TE LSP T1 from R1 (head-end LSR) to R11
(tail-end LSR) is defined on R1 as the following loosely routed
path: R1-R3(loose)-R8(loose)-R11(loose). R3, R8 and R11 are
defined as loose hops.
- the loose area : from R3 to R8
This document provides a method of local reoptimization of loose
nodes will affect few nodes. When a more optimal path appear at loose
area (between R3 and R8), messages of reoptimization will only
signal between loose nodes, for example R3 and R8, that is,
upstream node(R3)will signal messages of reoptimization to the
downstream loose node(R8), and the downsteam loose node will not
send message to other nodes,and the ingress node (R1) does not need
to do extra work.
This document provides a method of using methord of PATH refresh to
implement roptimization, not using the method of “make-before
break".This method will also decrease the work of the head-end.
The mechanism which provided by this document is not give a denial
to the methord of [LOOSE-REOPT], it can be supplement of
[LOOSE-REOPT]. The loose node can choice the local reoptimization,
and also can use the mothord in [LOOSE-REOPT].
3. Signaling extensions
A new flag in the RECORD_ROUTE object and new value sub-codes in the
attributes flags TLV are proposed in this document.(to be assigned
by IANA).
3.1. Extension Attributes Flags TLV
cui Expires: Jul. 2007 [Page 4]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
indicates the Attributes Flags TLV Attributes Flags TLV
Length
The length of the Value field in bytes. Thus, if no Value
field is present the Length field contains the value zero.
Each Value field must be zero padded at the end to take it
up to a four byte boundary -- the padding is not included in
the length so that a one byte value would be encoded in an
eight byte TLV with Length field set to one.
Value
Local reoptimization Desire 0x01
This value permits transit routers to use a local
reoptimization mechanism .When a more optimal path is
detected , loose node may optimize tunnel between the
loose node locally. The transit routers which are loose
node will process this value. If the loose node which
not supporting local reoptimization, must ignore this
value, else must express in the RERORD_REROUTE object.
This value must appear only in the PATH message, and
only loose transit nodes have to process this value.
Local reoptimization in use 0x02
This value indicates that the message with this value,is the
local reoptimization message, and the node which supporting
local reoptimization must process the message correctly. This
value can appear in the messages by RFC2205 defined.
This TLV may appear in the LSP_ATTRIBUTES,and may appear
in the LSP_REQUIRED_ATTRIBUTES,but it is not suggested to
appear in both at the same time.This document suggests that
cui Expires: Jul. 2007 [Page 5]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007
because local reoptimization is not mandatory function, so the
value of 0x01 should not appear in the LSP_REQUIRED_ATTRIBUTES.
In the local reoptimization , the tunnel ingress indicates that
the tunnel need local reoptimization using the value 0x01 of
LSP_REQUIRED_ATTRIBUTES in PATH message, the transit nodes
record information of local reoptimization, then response to
the ingress node that it support this function.
3.2. RRO IPv4/IPv6 Sub-object Flags
Extend RRO IPv4/IPv6 sub-objectFlags,new add
Local reoptimization in use 0x80
This new flag indicates that the node which has the IP address
Supports local reoptimization function. When the node discovers more
optimal path ,it will reoptimize the tunnel which with Local
reoptimization Desire value in the loose area.
4. Mode of operation
4.1. Head-end reoptimization control
The tunnel ingress may indicate that this tunnel permit
reoptimization locally , by user config.If the tunnel need local
reoptimization, the ingress must set Local reoptimization Desire
value in PATH message.
This value may appear in the Attributes Flags TLV of LSP_ATTRIBUTES,
or in the LSP_REQUIRED_ATTRIBUTES . This document suggests that the
value should be included in the LSP_ATTRIBUTES. If one of the two
objects has the value in the sub TLV,it indicates that the tunnel
need to be reoptimized locally , when receiving PATH message.
4.1.1. process PATH message
When receiving the PATH message from upstream node,The transit nodes
should decide that if the tunnel permit to local reoptimization.
If the tunnel has Local reoptimization Desire value in the PATH
message, and at the same time , if the transit node is loose route
node of this tunnel, that means the transit node can reoptimize this
tunnel locally but not reoptimize this tunnel by the ingress node.
Because Local reoptimization Desire may appper in the
LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES,so the process of the PATH
message must abide by RFC4420.
cui Expires: Jul. 2007 [Page 6]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007
4.1.2. process RESV message
When receiving RESV message from the downstream node,the transit
nodes should set Local reoptimization in use value in the RRO. Then
the ingress can know the information about where can support local
reoptimization.
4.2. Process after reoptimization triggers
When a new TE link appears or bandwidth of TE link increases, this
indicates that maybe a better path appears in the loose area. This
information may be flooded in the traffic engineering area by IGP
protocols. The traffic engineering area may be a area in the OSPF
or a level in the ISIS.
The loose node gets that information from IGP, if the loose node
supports the method of local reoptimizaiton, it will re-compute
tunnel through it using CSPF .The loose node computes the path
which the destination may be egress of the tunnel or may be another
loose node. If CSPF compute successfully , loose node compares the
new path with the old path which is using by the tunnel.
If the new path is more optimal than the old one ,the loose node
will signal the tunnel and complete reoptimization. If the loose node
does not support the local reoptimizaiton, this document suggests
that the loose node should send information to the tunnel ingress.
4.2.1. Process PATH message
Loose node sends the new PATH message,and some objects in the PATH
message must be modified , the objects are ERO,HOP object and add new
object of LSP_REQUIRED_ATTRIBUTES. LSP_REQUIRED_ATTRIBUTES must be
include in the PATH message. If PSB has saved SP_REQUIRED_ATTRIBUTES
of the old path,then the new path must not add this object again.
The LSP_REQUIRED_ATTRIBUTES must include Attributes Flags TLV, and
set value of “Local reoptimization in use” in this sub-TLV. These
new strict routes which computed by CSPF are added into the new
ERO, and the old explicit route will be copied in the end of the
new ERO. The old explicit route is the rest ERO subobjects which
delete the explicit subobjects before the destination loose node ,
which saving in loose node ‘s RSB who initiates the local
reoptimization.
When receiving the new PATH message , the transit nodes in the loose
area must decide if there have PSB corresponding to the new PATH
message. If there do not have corresponding PSB, then the transit
nodes must create a new PSB for the new coming PATH message, save
PATH message information, and express that the new coming message is
cui Expires: Jul. 2007 [Page 7]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007
the message of optimization, and send PATH message to downstream node
according to ERO; if there have PSB, then transit nodes MUST save
the HOP and new ERO of the new coming PATH message, at the same time,
mark reoptimizition flag to the these objects, but don’t delete the
old objects, and send PATH message to downstream nodtes according to
the new ERO. The destination of the local reoptimizaiton receives the
new PATH message, it knows that this PATH message is the
reoptimization message by “the Local reoptimization in use” value
and compare ERO subjects which get away from it with the old ERO,
it will find that the ERO in the new coming message is the same
with local old ERO, and then does not send the PATH message to
downstream nodes. The destination will send RESV message along the
path of new PATH message ,and the RESV message will be with the “
the Local reoptimization in use” value in the
LSP_REQUIRED_ATTRIBUTES. This does not affect the regular refresh
process of old path.
If the transit nodes don not support the vale of “Local
reoptimization in use”, the PATH ERROR message must be send to the
local reoptimization ingress, and drop the new coming PATH message.
The reoptimization ingress, which is signal the reoptimization
message, receives the PATH ERROR message, should not process local
reoptimization any more, it can make choice to send information to
the tunnel ingress or just keep silence.
4.2.2. Process RESV message
When receiving RESV message with “the Local reoptimization in use”
value in the LSP_REQUIRED_ATTRIBUTES, the transit node knows that the
RESV message is the local reoptimization message but not regular RESV
refresh message.
When processing the RESV message, because the message is the local
reoptimization message, the transit node should send RESV message
along the path of local reoptimization . In this document , if the
RESV message of local reoptimization has the same outgoing interface
with old RESV message of the tunnel, and the style of tunnel is SE
style, the reservation must to be do once.
When ingress node of local reoptimization receives the first coming
RESV message, it switches the traffic on the new path ,and then sends
PATH TEAR message with the “the Local reoptimization in use” value
in the LSP_ATTRIBUTES.
If errors are to be found when processing the RESV message, the node
MUST send RESV ERROR message, and drop the RESV message.
4.2.3 Process PATH TEAR message
cui Expires: Jul. 2007 [Page 8]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007
When the new PATH TEAR is created successfully, along the old path,
loose node send this message with the “the Local reoptimization in
use” value in the LSP_ATTRIBUTES. After receiving the PATH TEAR
message, the transit node should finds PSB or other information
according to the PATH TEAR message. If PSB exists and the PSB does
not have reoptimizaiton information, the transit node MUST deletes
the PSB as RFC3209 requires; if PSB exists and the PSB has
reoptimization information, the node must replace the ERO and HOP
of local reoptimzation with old one, HOP object need to that also.
If receiving the PATH TEAR message with no local reoptimization
value, the node must process the incoming message normally and at the
same time it must send PATH TEAR message out along reoptimization
path, which with the “the Local reoptimization in use” value in the
LSP_ATTRIBUTES.
4.3 Process ERROR message
The ingress node of local reoptimization, which signaling
reoptimization message, receives the PATH error with local
reotpimization flag, and should knows that the reoptimzation fail,
then should send PATH TEAR message to delete the path created by
local reoptimization.
For the RESV ERROR message with local reotpimization flag, the
destination of local reoptimization should send PATH ERROR message
to the ingress of local reoptimizaiton.
5. Multicast local reoptimiaiton
Now , there is not think about it clearly ,will be study in the
future .
6. 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.
cui Expires: Jul. 2007 [Page 9]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007
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.
7. 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.
8. Full Copyright Statement
Copyright (C) The Internet Society (2007).
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.
9. 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.
[LOOSE-REOPT] JP. Vasseur, Ed.,"Reoptimization of Multiprotocol
Label Switching (MPLS) Traffic Engineering (TE) loosely routed
Label Switch Path (LSP)",draft-ietf-ccamp-loose-path-reopt.
10.Author Information
Cui Ying
ZTE Inc.
cui Expires: Jul. 2007 [Page 10]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007
CHINA
Email: cui.ying@zte.com.cn
Jiang Weilian
ZTE Inc.
CHINA
Email: jiang.weilian@zte.com.cn
Feng Jun
ZTE Inc.
CHINA
Email: Feng.jun99@zte.com.cn
Teng Zhimeng
ZTE Inc.
CHINA
Email: Teng.zhimeng@zte.com.cn
Zhang Chaofeng
ZTE Inc.
CHINA
Email: Zhang.chaofeng@zte.com.cn
cui Expires: Jul. 2007 [Page 11]