One document matched: draft-ash-crlsp-modify-00.txt
MPLS WG J. Ash
Internet Draft Y. Lee
Document: draft-ash-crlsp-modify-00.txt AT&T
P. Ashwood-Smith
B. Jamoussi
L. Li
D. Fedyk
D. Skaleki
Nortel Networks
July 1999
LSP Modification Using CR-LDP
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
1. Abstract
After a CR-LSP is set up, its bandwidth reservation may need to be
changed by the network operator, due to the new requirements for the
traffic carried on that CR-LSP [2]. This contribution presents an
approach to modify the bandwidth and possibly other parameters of an
established CR-LSP using CR-LDP [3] without service interruption.
The LSP modification feature can be supported by CR-LDP with a minor
extension of an _action indicator flag_. This feature has
application in dynamic network resources management where traffic of
different priorities and service classes is involved.
2. Conventions used in this document
L: LSP (Label Switched Path)
Lid: LSPID (LSP Identifier)
T: Traffic Parameters
Ash, et. al 1 LSP Modification Using CR-LDP July, 1999
R: LSR (Label Switching Router)
FTN: FEC To NHLFE
FEC: Forwarding Equivalence Class
NHLFE: Next Hop Label Forwarding Entity
TLV: Type Length Value
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 [4].
3. Introduction
Consider an LSP L1 that has been established with its set of traffic
parameters T0. A certain amount of bandwidth is reserved along the
path of L1. Consider then that some changes are required on L1. For
example, the bandwidth of L1 needs to be increased to accommodate
the increased traffic on L1. Or the SLA associated with L1 needs to
be modified because a different service class is desired. The
network operator, in these cases, would like to modify the
characteristics of L1, for example, to change its traffic parameter
set from T0 to T1, without releasing the LSP L1 to interrupt the
service. In some other cases, network operators may want to reroute
a CR-LSP to a different path for either improved performance or
better network resource utilization. In all these cases, LSP
modification is required. In section 4 below, a method to modify an
active LSP using CR-LDP is presented. The concept of LSPID in CR-LDP
is used to achieve the LSP modification, without releasing the LSP
and interrupting the service and, without double booking the
bandwidth. Only a minimum extension on CR-LDP, an action indication
flag of _modify_ is needed in order to explicitly specify the
behavior, and allow the existing LSPID to support other networking
capabilities in the future. Section 5 specifies the action
indication flag of _modify_ for CR-LDP. In the appendix, an example
is described to demonstrate an application of the presented method
in dynamically managing network bandwidth requirements without
interrupting service.
4. LSP Modification Using CR-LDP
4.1 Basic Procedure
LSP modification can only be allowed when the LSP is already set up
and active. That is, modification is not defined nor allowed during
the LSP establishment or label release/withdraw phases. Only
modification requested by the ingress LSR of the LSP is considered
in this draft for CR-LSP. Ingress LSR cannot modify an LSP before a
previous modification procedure is completed.
Assume that CR-LSP L1 is set up with LSPID L-id1, which is unique in
the MPLS network. The ingress LSR R1 of L1 has in its FTN (FEC To
NHLFE) table FEC1 -> Label A mapping where A is the outgoing label
for LSP L1. To modify the characteristics of L1, R1 sends a Label
Ash, et. Al. February 2000 2 LSP Modification Using CR-LDP July, 1999
Request Message. In the messages, the TLVs will have the new
requested values, and the LSPID TLV is included which indicates the
value of L-id1. The Traffic Parameters TLV, the ER-TLV, the Resource
Class (color) TLV and the Preemption TLV can have values different
from those in the original Label Request Message, which has been
used to set up L1 earlier. Thus, L1 can be changed in its bandwidth
request (traffic parameter TLV), its traffic service class (traffic
parameter TLV), the route it traverses (ER TLV) and its setup and
holding (Preemption TLV) priorities. The ingress LSR R1 now still
has the entry in FTN as FEC1 -> Label A. R1 is waiting to establish
another entry for FEC1.
When an LSR Ri along the path of L1 receives the Label Request
message, its behavior is the same as that of receiving any Label
request message. The only extension is that Ri examines the LSPID
carried in the Label Request Message, L-id1 and identifies if it
already has L-id1. If Ri does not have L-id1, Ri behaves the same as
receiving a new Label Request message. If Ri already has L-id1, Ri
takes the newly received Traffic Parameter TLV and computes the new
bandwidth required and derives the new service class. Compared with
the already reserved bandwidth for L-id1, Ri now reserves only the
difference of the bandwidth requirements. This prevents Ri from
doing bandwidth double booking. If a new service class is requested,
Ri also prepares to receive the traffic on L1 in, perhaps a
different type of queue, just the same as handling it for a Label
Request Message. Ri assigns a new label for the Label Request
Message.
When the Label Mapping message is received, two sets of labels exist
for the same LSPID. Then the ingress LSR R1 will have two outgoing
labels, A and B, associated with the same FEC, where B is the new
outgoing label received for LSP L1. The ingress LSR R1 can now
activate the new entry in FTN, FEC1 - > Label B. This means that R1
swaps traffic on L1 to the new label _B_ (_new_ path) for L1. The
packets can now be sent with the new label B, with the new set of
traffic parameters if any, on a new path, that is, if a new path is
requested in the Label Request Message for the modification. All the
other LSRs along the path will start to receive the incoming packets
with the new label. For the incoming new label, the LSR has already
established its mapping to the new outgoing label. Thus, the packets
will be sent out with the new outgoing label. The LSRs do not have
to implement new procedures to track the new and old
characteristics of the LSP.
The ingress LSR R1 then starts to release the original label A for
LSP L1. The Label Release Message is sent by R1 towards the down
stream LSRs. The Release message carries the LSPID of L-id1 and the
Label TLV to indicate which label is to be released. The Release
Message is propagated to the egress LSR to release the original
labels previously used for L1. Upon receiving the Label Release
Message, LSR R1 examines the LSPID, L-id1 and finds out that the L-
id1 has still another set of label (incoming/outgoing) under it.
Ash, et. Al. February 2000 3 LSP Modification Using CR-LDP July, 1999
Thus, the old label is released without releasing the resource in
use. That is, if the bandwidth has been decreased for L1, the delta
bandwidth is released. Otherwise, no bandwidth is released. This
modification procedure can not only be applied to modify the traffic
parameters and/or service class of an active LSP, but also to
reroute an existing LSP, and/or change 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 Label
Request / Mapping / Notification / Release /Withdraw procedure of a
CR-LDP operated LSR with a specific action taken on LSPID. If Label
Withdraw Message is used to withdraw a label associated with an
LSPID, the Label TLV should be included to specify which label to
withdraw. Since the LSPID can also be used for other feature
support, an action indication flag of _modify_ assigned to the LSPID
would explicitly explain the action/semantics that should be
associated with the messaging procedure. The details of this flag
are addressed in Section 3 below.
4.2 Priority Handling
When sending a Label Request Message for an active LSP L1 to request
changes, the setup priority used in the label Request Message can be
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 to
be assigned to a modification request, based on their
policies/algorithms and other traffic situations in the network. For
example, the priority for modification can be determined by the
priority of the customer/LSP. If a customer has exceeded the
reserved bandwidth of its VPN LSP tunnel by too much, the
modification request's priority may be given higher.
The Label Request message for the modification of an active LSP can
also be sent with a holding priority different from its previous
one. This effectively changes the holding priority of the LSP. Upon
receiving a Label Request Message that requests a new holding
priority, the LSR assigns the new holding priority to the bandwidth.
That is, the new holding priority is assigned to both the existing
incoming / outgoing labels and the new labels to be established for
the LSPID in question. In this way self-bumping is prevented.
4.3 Modification Failure Case Handling
A modification attempt may fail due to insufficient resource or
other situations. A Notification message is sent back to the ingress
LSR R1 to indicate the failure of Label Request Message that
intended to modify the LSP. Retry may be attempted if desired by the
network operator.
Ash, et. Al. February 2000 4 LSP Modification Using CR-LDP July, 1999
If the LSP on the original path failed when a modification attempt
is in progress, the attempt should be aborted by using the Label
Abort Request message as specified in LDP draft [5].
5. Proposed Extensions to CR-LDP for CR-LSP Modification
5.1 _Action indicator Flag_ in LSPID TLV
As LSPID can be used for other purpose as well, for example, for LSP
merge or stacking, etc. which are not intended to be covered here,
an _action indicator flag_ is proposed to be carried in the LSPID
TLV. This _action indicator flag_ shows explicitly the action that
should be taken if the LSP already exists on the LSR receiving the
message. The indicator flag can take 4 bits (right most 4 bits) out
of the two reserved bytes in the LSPID TLV. A set of indicator code
points is proposed as follows:
0001: modify
The procedure for code point _modify_ is defined as in the above
section 2.1. The procedures for others are for future work.
5.2 New Status Code
Status code Type
Modify request not supported 0x04000008
This error code can be used to indicate that for some reason, the
modification attempt on the given LSPID is not allowed by the LSR.
For example, this can be an attempt that is sent out too soon after
last modification, before the LSR has completed the procedures in
the last modification attempt.
6. Intellectual Property Consideration
Nortel Networks may seek patent or other intellectual property
protection for some or all of the technologies disclosed in this
document. If any standards arising from this document are or become
protected by one or more patents assigned to Nortel Networks, Nortel
Networks is prepared to make a license available to any qualified
applicant upon reasonable and non-discriminatory terms and
conditions. Any such licenses will be subject to negotiations
outside of the IETF.
7. Security Considerations
No security issues are addressed in this draft.
8. References
Ash, et. Al. February 2000 5 LSP Modification Using CR-LDP July, 1999
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Ash, J., et. al., QoS Resource Management in MPLS-Based Networks,
draft-ash-qos-routing-00.txt, (work in progress).
3 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP,
draft-ietf-mpls-cr-ldp-01.txt, February 1999,(work in progress).
4 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
5 Andersson, L., et. al., LDP Specification, draft-ietf-mpls-ldp-
05.txt (work in progress)
9. Author's Addresses
Gerald R. Ash Young Lee
AT&T AT&T
Room MT E3-3C37 Room MT E3-3A04
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Phone: 732-420-4578 Phone: 732-420-4477
Fax: 732-440-6687 Fax: 732-440-6697
Email: gash@att.com Email: younglee@att.com
Bilel Jamoussi
Nortel Networks Corp.
3 Federal Street
Billerica, MA 01821
USA
phone: 978-288-4506
Email: jamoussi@NortelNetworks.com
Peter Ashwood-Smith Li Li
Nortel Networks Corp. Nortel Networks Corp.
P O Box 3511 Station C P O Box 3511 Station C
Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7
Canada Canada
Phone: +1 613 763-4534 phone: +1 613 765 3088
Email: petera@NortelNetworks.com lili@nortelnetworks.com
Darek Skalecki Don Fedyk
Nortel Networks Corp. Nortel Networks Corp.
P O Box 3511 Station C P O Box 3511 Station C
Ottawa, ON K1Y 4H7 Ottawa, ON K1Y 4H7
Canada Canada
phone: +1 613 765-2252 phone: +1 613 763 3268
Email: skalecki@NortelNetworks.com fedyk@nortelnetworks.com
Ash, et. Al. February 2000 6 LSP Modification Using CR-LDP July, 1999
Appendix
Application of LSP Bandwidth Modification in Dynamic Resource
Management
In this section, we gave an example of dynamic network resource
management using the LSP bandwidth modification capability. The
details of this example can be found in a previous Internet draft
presented in the last meeting. Assume that customers are assigned
with their CR-LSPs. These customers' are assigned with one of the
priorities as key, normal or best effort. The network operator
doesn't want to bump any LSPs during an LSP setup, so after these
CR-LSPs are set up, their holding priority are all assigned as the
highest.
The network operator wants to control the resource on the links of
LSRs, so all LSRs keep the usage status of its links and based on
the usage history, each link is assigned a current threshold
priority Pi. Which means that the link has no bandwidth available
for Label Request with a setup priority lower than Pi. When a LSP's
bandwidth needs to be modified, the operator uses policy based
algorithm to assign a priority for its modification request, say Mp
for LSP L2. Then the ingress LSR sends Label Request message with
(Setup Priority = Mp). The rule is then only if there is enough
bandwidth on the link and, the Setup priority in the Label Request
Message is higher in priority (Mp numerically smaller) than Pi of
the link, the Label Request Message will be accepted by the LSR.
Otherwise, the Label Request message will be rejected with a
Notification message indicates that there isn't enough resources. It
should also be note that when OSPF (or IS-IS) floods the link
available bandwidth information, the available bandwidth associated
with priority lower than Pi (numerical value bigger) should be
indicated as _0_. This procedure based on a priority threshold Pi is
implementation specific and value added. It offers networks
flexibility to prioritize and control its resources.
The calculation of Mp is network dependent, based on operator's own
algorithm. For example, the operator may assign a higher Mp to L2 if
L2 belongs to a customer with _Key_ priority. The operator may also
collect the actual usage of each LSP and assign a high Mp to L2 if
in the past week, L2 has exceeding its reserved bandwidth by 2 times
on the average, and the customer of L2 agrees to increase its
bandwidth for a better guaranteed service. Some operator may try to
increase the bandwidth of L2 on its existing path unsuccessfully as
there isn't enough bandwidth there. Then the operator is willing to
change the path of L2 in order to increase its bandwidth, but with a
lower priority Mp this time as L2 now is routed on its secondary
path, which should yield priority to the LSPs that are on its
primary paths here.
Ash, et. Al. February 2000 7 LSP Modification Using CR-LDP July, 1999
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
Ash, et. Al. February 2000 8 | PAFTECH AB 2003-2026 | 2026-04-21 22:26:15 |