As per Relevance of the word modification, we have this rfc below:
Network Working Group J.
Request for Comments: 3214 AT&
Category: Standards Track Y.
Ceterus
P. Ashwood-
B.
D.
D.
Nortel
L.
SS8
January 2002
LSP Modification Using CR-
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document presents an approach to modify the bandwidth
possibly other parameters of an established CR-LSP (Constraint-
Routed Label Switched Paths) using CR-LDP (Constraint-based
Label Distribution Protocol) without service interruption. After
CR-LSP is set up, its bandwidth reservation may need to be changed
the network operator, due to the new requirements for the
carried on that CR-LSP. The LSP modification feature can
supported by CR-LDP by use of the _modify_value for the _
indicator flag_ in the LSPID TLV. This feature has application
dynamic network resources management where traffic of
priorities and service classes is involved
Ash, et al. Standards Track [Page 1]
RFC 3214 LSP Modification Using CR-LDP January 2002
Table of
1. Conventions Used in This Document ............................ 2
2. Introduction ................................................. 2
3. LSP Modification Using CR-LDP ................................ 3
3.1 Basic Procedure for Resource Modification .................. 3
3.2 Rerouting LSPs ............................................. 5
3.3 Priority Handling .......................................... 6
3.4 Modification Failure Case Handling ......................... 6
4. Application of LSP Bandwidth Modification in Dynamic
Management ................................................... 7
5. Acknowledgments .............................................. 8
6. Intellectual Property Considerations ......................... 8
7. Security Considerations ...................................... 8
8. References ................................................... 8
9. Authors' Addresses ........................................... 9
10. Full Copyright Statement ..................................... 11
1. Conventions Used in This
L: LSP (Label Switched Path
L-id: LSPID (LSP Identifier
T: Traffic
R: LSR (Label Switching Router
FEC: Forwarding Equivalence
NHLFE: Next Hop Label Forwarding
FTN: FEC To
TLV: Type Length
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [4].
2.
Consider an LSP L1 that has been established with its set of
parameters T0. A certain amount of bandwidth is reserved along
path of L1. Consider then that some changes are required on L1.
example, the bandwidth of L1 needs to be increased to accommodate
increased traffic on L1. Or the SLA associated with L1 needs to
modified because a different service class is desired. The
operator, in these cases, would like to modify the characteristics
L1, for example, to change its traffic parameter set from T0 to T1,
without releasing the LSP L1 to interrupt the service. In some
cases, network operators may want to reroute a CR-LSP to a
path for either improved performance or better network
utilization. In all these cases, LSP modification is required.
section 3 below, a method to modify an active LSP using CR-LDP
Ash, et al. Standards Track [Page 2]
RFC 3214 LSP Modification Using CR-LDP January 2002
presented. The concept of LSPID in CR-LDP is used to achieve the
modification, without releasing the LSP and interrupting the
and, without double booking the bandwidth. In Section 4, an
is described to demonstrate an application of the presented method
dynamically managing network bandwidth requirements
interrupting service. In CR-LDP, an action indicator flag
_modify_ is used in order to explicitly specify the behavior,
allow the existing LSPID to support other networking capabilities
the future. Reference [3], RFC XXXX, specifies the action
flag of _modify_ for CR-LDP
3. LSP Modification Using CR-
3.1 Basic Procedure for Resource
LSP modification can only be allowed when the LSP is already set
and active. That is, modification is not defined nor allowed
the LSP establishment or label release/withdraw phases.
modification requested by the ingress LSR of the LSP is considered
this document for CR-LSP. The Ingress LSR cannot modify an
before a previous modification procedure is completed
Assume that CR-LSP L1 is set up with LSPID L-id1, which is unique
the MPLS network. The ingress LSR R1 of L1 has in its FTN (FEC
NHLFE) table FEC1 -> Label A mapping where A is the outgoing
for LSP L1. To modify the characteristics of L1, R1 sends a
Request Message. In the message, the TLVs will have the
requested values, and the LSPID TLV is included which indicates
value of L-id1. The Traffic Parameters TLV, the ER-TLV, the
Class (color) TLV and the Preemption TLV can have values
from those in the original Label Request Message, which has
used to set up L1 earlier. Thus, L1 can be changed in its
request (traffic parameter TLV), its traffic service class (
parameter TLV), the route it traverses (ER TLV) and its setup
holding (Preemption TLV) priorities. The ingress LSR R1 now still
the entry in its FTN as FEC1 -> Label A. R1 is waiting to
another entry for FEC1.
When an LSR Ri along the path of L1 receives the Label
message, its behavior is the same as that of receiving any
request message. The only extension is that Ri examines the
carried in the Label Request Message, L-id1, and identifies if
already has L-id1. If Ri does not have L-id1, Ri behaves the same
receiving a new Label Request message. If Ri already has L-id1,
takes the newly received Traffic Parameter TLV and computes the
bandwidth required and derives the new service class. Compared
the already reserved bandwidth for L-id1, Ri now reserves only
difference of the bandwidth requirements. This prevents Ri from
Ash, et al. Standards Track [Page 3]
RFC 3214 LSP Modification Using CR-LDP January 2002
bandwidth double booking. If a new service class is requested,
also prepares to receive the traffic on L1 in just the same way
handling it for a Label Request Message, perhaps using a
type of queue. Ri assigns a new label for the Label Request Message
When the Label Mapping message is received, two sets of labels
for the same LSPID. Then the ingress LSR R1 will have two
labels, A and B, associated with the same FEC, where B is the
outgoing label received for LSP L1. The ingress LSR R1 can
activate the new entry in its FTN, FEC1 - > Label B. This means
R1 swaps traffic on L1 to the new label _B_ (_new_ path) for L1.
packets can now be sent with the new label B, with the new set
traffic parameters if any, on a new path, that is, if a new path
requested in the Label Request Message for the modification. All
other LSRs along the path will start to receive the incoming
with the new label. For the incoming new label, the LSR has
established its mapping to the new outgoing label. Thus, the
will be sent out with the new outgoing label. The LSRs do not
to implement new procedures to track the new and old
of the LSP
The ingress LSR R1 then starts to release the original label A
LSP L1. The Label Release Message is sent by R1 towards the
stream LSRs. The Release message carries the LSPID of L-id1 and
Label TLV to indicate which label is to be released. The
Message is propagated to the egress LSR to release the
labels previously used for L1. Upon receiving the Label
Message, LSR Ri examines the LSPID, L-id1, and finds out that the L
id1 has still another set of labels (incoming/outgoing) under it
Thus, the old label is released without releasing the resource
use. That is, if the bandwidth has been decreased for L1, the
bandwidth is released. Otherwise, no bandwidth is released.
modification procedure can not only be applied to modify the
parameters and/or service class of an active LSP, but also to
an existing LSP (as described in Section 3.2 below), and/or
its setup/holding priority if desired. After the release procedure
the modification of the LSP is completed
The method described above follows the normal behavior of
Request / Mapping / Notification / Release / Withdraw procedure of
CR-LDP operated LSR with a specific action taken on an LSPID. If
Label Withdraw Message is used to withdraw a label associated with
LSPID, the Label TLV should be included to specify which label
withdraw. Since the LSPID can also be used for other
support, an action indication flag of _modify_ assigned to the
would explicitly explain the action/semantics that should
associated with the messaging procedure. The details of this
are addressed in the CR-LDP document, Reference [3].
Ash, et al. Standards Track [Page 4]
RFC 3214 LSP Modification Using CR-LDP January 2002
3.2 Rerouting
LSP modification can also be used to reroute an existing LSP.
modification requested by the ingress LSR of the LSP is considered
this document for CR-LSP. The Ingress LSR cannot modify an LSP
a previous modification procedure is completed
As in the previous section, consider a CR-LSP L1 with LSPID L-id1.
To modify the route of the LSP, the ingress LSR R1 sends a
Request Message. In the message, the LSPID TLV indicates L-id1
the Explicit Route TLV is specified with some different hops from
explicit route specified in the original Label Request Message.
action indication flag has the value _modify_.
At this point, the ingress LSR R1 still has an entry in FTN
FEC1 -> Label A. R1 is waiting to establish another entry for FEC1.
When an LSR Ri along the path of L1 receives the Label
message, its behavior is the same as that of receiving a
Request Message that modifies some other parameters of the LSP.
assigns a new label for the Label Request Message and forwards
message along the explicit route. It does not allocate any
resources except as described in section 3.1.
At another LSR Rj further along the path, the explicit route
from the previous route. Rj acts as Ri, but forwards the
Request message along the new route. From this point onwards
Label Request Message is treated as setting up a new LSP by each
until the paths converge at later LSR Rk. The _modify_ value of
action indication flag is ignored
At Rk and subsequent LSRs, the Label Request Message is handled as
Ri
On the return path, when the Label Mapping message is received,
sets of labels for the LSPID exist where the new route coincide
the old. Only one set of labels will exist at LSRs where the
diverge
When the Label Mapping message is received at the ingress LSR R1
has two outgoing labels, A and B, associated with the same FEC,
B is the new outgoing label received for LSP L1. R1 can now
the new entry in the FTN, FEC1 - > Label B and de-activate the
entry FEC1 - > Label A. This means that R1 swaps traffic on L1 to
new label B. The packets are now sent with the new label B, on
new path
Ash, et al. Standards Track [Page 5]
RFC 3214 LSP Modification Using CR-LDP January 2002
The ingress LSR R1 then starts to release the original label A
LSP L1. The Label Release Message is sent by R1 towards the
stream LSRs following the original route. The Release message
the LSPID of L-id1 and the Label TLV to indicate which label is to
released. At each LSR the old label is released - no further
is required to change the path of the data packets which are
following the new route programmed by the Label Mapping message
At some LSRs, where the routes diverged, there is only one label
the LSPID. For example, between Rj and Rk, the Label Release
will follow the old route. At LSRs between Rj and Rk only the
from the original route will exist for LSPID L-id1. At these
the LSPID TLV does not need to be examined to release the
label, but it must still be updated and passed on to the next LSR
the Label Release message is propagated. In this way, at Rk where
routes converge, the downstream LSR will know which label to
and can continue to forward the Label Release Message along the
route
3.3 Priority
When sending a Label Request Message for an active LSP L1 to
changes, the setup priority used in the label Request Message can
different from the one used in the previous Label Request Message
effectively indicating the priority of this _modification_ request
Network operators can use this feature to decide what priority is
be assigned to a modification request, based on
policies/algorithms and other traffic situations in the network.
example, the priority for modification can be determined by
priority of the customer/LSP. If a customer has exceeded
reserved bandwidth of its VPN LSP tunnel by too much,
modification request's priority may be given as a higher value.
Label Request message for the modification of an active LSP can
be sent with a holding priority different from its previous one
This effectively changes the holding priority of the LSP.
receiving a Label Request Message that requests a new
priority, the LSR assigns the new holding priority to the bandwidth
That is, the new holding priority is assigned to both the
incoming / outgoing labels and the new labels to be established
the LSPID in question. In this way self-bumping is prevented
3.4 Modification Failure Case
A modification attempt may fail due to insufficient resource or
situations. A Notification message is sent back to the ingress
R1 to indicate the failure of Label Request Message that intended
modify the LSP. A retry may be attempted if desired by the
Ash, et al. Standards Track [Page 6]
RFC 3214 LSP Modification Using CR-LDP January 2002
operator. If the LSP on the original path failed when a
attempt is in progress, the attempt should be aborted by using
Label Abort Request message as specified in the LDP document [5].
In the event of a modification failure, all modifications to the
including the holding priority must be restored to their
values
4. Application of LSP Bandwidth Modification in Dynamic
In this section, we gave an example of dynamic network
management using the LSP bandwidth modification capability.
details of this example can be found in a previous internet-
[2]. Assume that customers or services are assigned with given CR
LSPs. These customers/services are assigned with one of
priorities: key, normal or best effort. The network operator
not want to bump any LSPs during an LSP setup, so after these CR-
are set up, their holding priorities are all assigned as the
value
The network operator wants to control the resource on the links
the LSRs, so each LSR keeps the usage status of its links. Based
the usage history, each link is assigned a current threshold
Pi, which means that the link has no bandwidth available for a
Request with a setup priority lower than Pi. When an LSP's
needs to be modified, the operator uses a policy-based algorithm
assign a priority for its modification request, say Mp for LSP L2.
The ingress LSR then sends a Label Request message with
Priority = Mp. If there is sufficient bandwidth on the link for
modification, and the Setup priority in the Label Request Message
higher in priority (Mp numerically smaller) than the Pi threshold
the link, the Label Request Message will be accepted by the LSR
Otherwise, the Label Request message will be rejected with
Notification message which indicates that there are
resources. It should also be noted that when OSPF (or IS-IS)
the available-link-bandwidth information, the available
associated with a priority lower than Pi (numerical value bigger
should be interpreted as _0_.
This example based on a priority threshold Pi is
specific, and illustrates the flexibility of the
procedure to prioritize and control network resources.
calculation of Mp can be network and service dependent, and is
on the operator's routing policy. For example, the operator
assign a higher priority (lower Mp value) to L2
modification if L2 belongs to a customer or service with _Key
priority. The operator may also collect the actual usage of each
Ash, et al. Standards Track [Page 7]
RFC 3214 LSP Modification Using CR-LDP January 2002
and assign a lower priority (higher Mp) to L2 bandwidth-
modification if, for example, in the past week L2 has exceeded
reserved bandwidth by 2 times on the average. In addition,
operator may try to increase the bandwidth of L2 on its existing
unsuccessfully if there is insufficient bandwidth available on L2.
In that case, the operator is willing to increase the bandwidth
another LSP, L3, with the same ingress/egress LSRs as L2, in order
increase the overall ingress/egress bandwidth allocation. However
in this case the L3 bandwidth modification is performed with a
priority (higher Mp value) since L3 is routed on a secondary path
which results in the higher bandwidth allocation priority being
to the LSPs that are on their primary paths [2].
5.
The authors would like to acknowledge the careful review and
of Adrian Farrel
6. Intellectual Property
The IETF has been notified of intellectual property rights claimed
regard to some or all of the specification contained in
document. For more information consult the online list of
rights
7. Security
Protection against modification to LSPs by malign agents has to
controlled by the MPLS domain
8.
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
9, RFC 2026, October 1996.
[2] Ash, J., "Traffic Engineering & QoS Methods for IP-, ATM-, &
TDM-Based Multiservice Networks", Work in Progress
[3] Jamoussi, B., Editor, Andersson, L., Callon, R., Dantu, R., Wu
L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish
M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint
based LSP Setup Using LDP", RFC 3212, January 2002.
Ash, et al. Standards Track [Page 8]
RFC 3214 LSP Modification Using CR-LDP January 2002
[4] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[5] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B
Thomas, "LDP Specification", RFC 3036, January 2001.
[6] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol
Switching Architecture", RFC 3031, January 2001.
[7] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus
"Requirements for Traffic Engineering Over MPLS", RFC 2702,
September 1999.
[8] Ash, J., Girish, M., Gray, E., Jamoussi,B. and G. Wright
"Applicability Statement for CR-LDP", RFC 3213, January 2002.
9. Authors'
Gerald R.
AT&
Room MT D5-2A01
200 Laurel
Middletown, NJ 07748
Phone: 732-420-4578
EMail: gash@att.
Bilel
Nortel Networks Corp
600 Tech
Billerica, MA 01821
Phone: 978-288-4506
EMail: jamoussi@NortelNetworks.
Peter Ashwood-
Nortel Networks Corp
P O Box 3511 Station
Ottawa, ON K1Y 4H
Phone: +1 613 763-4534
EMail: petera@NortelNetworks.
Ash, et al. Standards Track [Page 9]
RFC 3214 LSP Modification Using CR-LDP January 2002
Darek
Nortel Networks Corp
P O Box 3511 Station
Ottawa, ON K1Y 4H
Phone: +1 613 765-2252
EMail: dareks@nortelnetworks.
Young
Ceterus
EMail: ylee@ceterusnetworks.
Li
SS8
495 March Rd., 5th
Kanata,
K2K 3G1
Phone: +1 613 592-2100 ext. 3228
EMail: lili@ss8networks.
Don
Nortel Networks Corp
600 Tech
Billerica, MA 01821
Phone: 978-288-3041
EMail: dwfedyk@nortelnetworks.
Ash, et al. Standards Track [Page 10]
RFC 3214 LSP Modification Using CR-LDP January 2002
10. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Ash, et al. Standards Track [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
