One document matched: draft-cui-ccamp-te-loose-reopt-local-01.txt
Differences from draft-cui-ccamp-te-loose-reopt-local-00.txt
Network Working Group Cui Ying
Internet Draft Jiang Weilian
Feng Jun
Expiration Date: Jan. 2008 Teng Zhimeng
Zhang Chaofeng
ZTE, Inc.
Jul. 2007
Reoptimization of Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) loosely routed Label Switch Path (LSP) Locally
draft-cui-ccamp-te-loose-reopt-local-01
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 Jan , 2008.
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: Jan. 2008 [Page 1]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.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...............................9
4.2.3. Process PATH TEAR message...........................9
4.3. Process ERROR message ..................................10
5. Security Considerations .....................................11
6. IANA Considerations .........................................11
7. Acknowledgements.............................................11
8. References...................................................11
8.1. Normative References...................................11
8.2. Informative References.................................11
Author's Addresses..............................................11
Intellectual Property Statement.................................13
Full Copyright Statement........................................13
Intellectual Property...........................................13
cui Expires: Jan. 2008 [Page 2]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2008
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
finds 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: Jan. 2008 [Page 3]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007
with [LOOSE-REOPT], and in order to preserve integrity, the document
cites 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 compareing with [LOOSE-REOPT]. When
a more optimal path appears 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 more extra work. The
ingress node may using RROs to record the new path which the
tunnel is passing, and show it to the user.
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 works 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: Jan. 2008 [Page 4]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.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
because local reoptimization is not mandatory function, so
the value of 0x01 should not appear in the
cui Expires: Jan. 2008 [Page 5]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007
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.
Local reoptimization delete 0x04
This value indicates that the message with this value, is the
local reoptimization message, and the node which supporting
local reoptimization must should end the local reptimization
process, for example, delete the PSB or the RSB save in local
node. The value should appear in the PATH TEAR or RESV TEAR
messages of the local reoptimization.
3.2. RRO IPv4/IPv6 Sub-object Flags
Extend RRO IPv4/IPv6 sub-objectFlags, new add
Local reoptimization support 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 indicates that this tunnel permit
reoptimization locally, by user config. If the tunnel need local
reoptimization, the ingress must set "Local reoptimization desire"
value in the PATH message.
This value of "Local reoptimization desire" 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
cui Expires: Jan. 2008 [Page 6]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2008
should decide that if the tunnel is permited 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 the value of "Local reoptimization vesire" may appper in the
Attributes Flags TLV of LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES,
so the process of the PATH message must abide by RFC4420.
4.1.2. process RESV message
When receiving RESV message from the downstream node,the transit
nodes should set the value of "Local reoptimization surpport" in
the RRO. Then the ingress can know the information about where
can support local reoptimization, that means which nodes have the
ability to reoptimize the tunnel locally.
4.2. Processing after reoptimization triggers
When a new TE link appears or bandwidth of TE link increases, this
indicates that maybe a shorter 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 by 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 or reoptimize the tunnel by using the methord in the
[LOOSE-REOPT].
The transit nodes in the loose area will maintain the regular
refresh for the old path when processint the local reoptimization
message.
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
cui Expires: Jan. 2008 [Page 7]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007
new object of LSP_REQUIRED_ATTRIBUTES. LSP_REQUIRED_ATTRIBUTES must
be include in the PATH message. If PSB has saved
LSP_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.
The loose node computes the new explicit routes between the loose
area, that means that the destination is not the egress node but
loose node in the path. These new strict routes which computed by
CSPF are added into the new ERO, that means that the new ERO only
include the strict routes between the loose area and the last ERO
subobjects MUST be the destination loose node which should be set
loose node. The old explicit routes will be save the the loose node
and not be deleted until the reoptimation of the tunnel success.
The loose node may be modify the HOP object. If the new path has
new interface compare the old one, HOP object should be modified.
And the loose node should save the new objects for using local
reoptimation templately.
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 does 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
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 it will find
that the last ERO subojects in the ERO subobjects in the new coming
message is same with itself adress . Then the destination loose node
will not send the PATH message to downstream nodes. The destination
loose node will send RESV message along the path of new PATH message
, and the RESV message MUST set the "Local reoptimization in use"
value in the LSP_REQUIRED_ATTRIBUTES.
If the transit nodes don't not support the vale of "Local
reoptimization in use", the PATH ERROR message MUST be sent 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
cui Expires: Jan. 2008 [Page 8]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007
reoptimization any more, it can make choice to send information to
the tunnel ingress or just keep silence or use the methord of
reoptimation in the [LOOSE-REOPT].
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 in the loose
area 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 TEAR message
The ingress node of local reoptimization will send new PATH TEAR
message to downstream nodes when it receives the RESV message from
the new path. It can find the value of "the Local reoptimization
in use" in the Attributes Flags TLV of LSP_REQUIRED_ATTRIBUTES from
the new come RESV message. Then it will send new PATH TEAR message to
delete the old path. When the new PATH TEAR message is created
successfully, send along the old path, ingress node of local
reoptimization send this message with the "the Local reoptimization
in use" value in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES which
depend on the old PSB save which one.
If the ingress node receives the RESV TEAR message with the value of
"the Local reoptimization in use", it will send the PATH TEAR
messassage along the new path of reoptimization, MUST set the value
"the Local reoptimization delete " in the Attributes Flags TLV of
LSP_REQUIRED_ATTRIBUTES.
After receiving the PATH TEAR message, the transit node should decide
which path the new coming PATH TEAR message want to delete, that is
the old one or the new reoptimizate one. If the PSB dest not exist,
the transit node should drop the message as RFC3209 requires. If
cui Expires: Jan. 2008 [Page 9]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007
the PSB exists, then the transit node other information according
to the PATH TEAR message. If the PSB has reoptimization information,
and the same time, the transit nodes find the value of "the Local
reoptimization in use", then it will send the PATH TEAR message of
local reoptimization along the old path ; else if it find the value
of "the Local reoptimization delete", it will send the PATH TEAR
message along the new path. Then the transit node must replace the
ERO and HOP of local reoptimzation with old one, HOP object may be
to that also.
If PSB has not reoptimization information, and the same time, the
transit node find the value of "the Local reoptimization delete",
it should drop the message. The transit node with no reoptimization
information should process the PATH TEAR message as RFC3209 defines.
The destination node of local reoptimization receive the PATH TEAR
message with "the Local reoptimization in use" value or "the Local
reoptimization delete", it MUST not send the PATH TEAR message to
downsteam nodes.
If receiving the PATH TEAR message with no value of "local
reoptimization in use" or "the Local reoptimization delete" value,
the nodes must process the incoming message normally. At the same
time, the node which is has the information of local reoptimization
MUST send PATH TEAR message out along reoptimization path, which
with the the "Local reoptimization delete" value in the
LSP_REQUIRED_ATTRIBUTES.
If receiving the RESV TEAR message with reoptimation, the destionation
of the local reoptiomization should send PATH ERROR message with
"local reoptimization in use " along the new path to the ingress of
the local reoptimization. the ingress of the local reoptimization.
4.3 Process ERROR message
The ingress node of local reoptimization, which signaling
reoptimization message, receives the PATH ERROR message with "local
reoptimization in use ", and should knows that the reoptimzation
fail, then should send PATH TEAR message to delete the path created
by local reoptimization along the new path with the value of "local
reoptimization delete".
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 with "local reoptimization
in use ".
cui Expires: Jan. 2008 [Page 10]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007
5. Security Considerations
This doucment does not add abnormal security question.
6. IANA Considerations
This document defines new flag in the Attributes Flags TLV and
RRO IPv4/IPv6 Sub-object Flags in the Signaling extensions.These
new flags needs to be registered by the IANA .
7. Acknowledgements
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC2119.
[RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC2434.
[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)", RFC4736, November 2006.
8.2. Informative References
Authors' Addresses
Cui Ying
ZTE Inc.
CHINA
Email: cui.ying@zte.com.cn
Jiang Weilian
cui Expires: Jan. 2008 [Page 11]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007
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: Jan. 2008 [Page 12]
Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007
Full Copyright Statement
Copyright (C) The IETF Trust (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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
cui Expires: Jan. 2008 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 10:14:10 |