draft-ietf-mpls-crlsp-modify-00.txt   draft-ietf-mpls-crlsp-modify-01.txt 
MPLS WG J. Ash MPLS WG J. Ash
Internet Draft Y. Lee Internet Draft Y. Lee
Document: draft-ietf-mpls-crlsp-modify-00.txt AT&T Document: draft-ietf-mpls-crlsp-modify-01.txt AT&T
P. Ashwood-Smith P. Ashwood-Smith
B. Jamoussi B. Jamoussi
D. Fedyk D. Fedyk
D. Skalecki D. Skalecki
Nortel Networks Nortel Networks
L. Li L. Li
SS8 Networks SS8 Networks
December 1999 February, 2000
Expires: June 2000 Expires: September 2000
LSP Modification Using CR-LDP LSP Modification Using CR-LDP
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 47 skipping to change at page 1, line 45
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
1. Abstract 1. Abstract
After a CR-LSP is set up, its bandwidth reservation may need to be 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 changed by the network operator, due to the new requirements for the
traffic carried on that CR-LSP [2]. This contribution presents an traffic carried on that CR-LSP [2]. This contribution presents an
approach to modify the bandwidth and possibly other parameters of an approach to modify the bandwidth and possibly other parameters of an
established CR-LSP using CR-LDP [3] without service interruption. established CR-LSP using CR-LDP [3] without service interruption.
The LSP modification feature can be supported by CR-LDP with a minor The LSP modification feature can be supported by CR-LDP by use of
extension of an _action indicator flag_ [3]. This feature has the _modify_ value for the _action indicator flag_ in the LSPID TLV
application in dynamic network resources management where traffic of [3]. This feature has application in dynamic network resources
different priorities and service classes is involved. management where traffic of different priorities and service classes
is involved.
Table of Contents Table of Contents
1.0 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.0 Conventions Used in This Document . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . . . 3
3.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.0 LSP Modification Using CR-LDP. . . . . . . . . . . . . . . . . . . 3 4. LSP Modification Using CR-LDP. . . . . . . . . . . . . . . . . . . 3
4.1 Basic Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1 Basic Procedure for Resource Modification . . . . . . . . . . . . 3
4.2 Priority Handling . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Rerouting LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3 Modification Failure Case Handling . . . . . . . . . . . . . . . . 5 4.3 Priority Handling . . . . . . . . . . . . . . . . . . . . . . . . 6
5.0 Application of LSP Bandwidth Modification in Dynamic Resource 4.4 Modification Failure Case Handling . . . . . . . . . . . . . . . . 6
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Application of LSP Bandwidth Modification in Dynamic Resource
6.0 Intellectual Property Considerations . . . . . . . . . . . . . . . 6 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.0 Security Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Intellectual Property Considerations . . . . . . . . . . . . . . . 8
9.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
2.0 Conventions Used in This Document 2. Conventions Used in This Document
L: LSP (Label Switched Path) L: LSP (Label Switched Path)
Lid: LSPID (LSP Identifier) L-id: LSPID (LSP Identifier)
T: Traffic Parameters T: Traffic Parameters
R: LSR (Label Switching Router) R: LSR (Label Switching Router)
FTN: FEC To NHLFE
FEC: Forwarding Equivalence Class FEC: Forwarding Equivalence Class
NHLFE: Next Hop Label Forwarding Entity NHLFE: Next Hop Label Forwarding Entity
FTN: FEC To NHLFE
TLV: Type Length Value TLV: Type Length Value
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [4]. this document are to be interpreted as described in RFC-2119 [4].
3.0 Introduction 3. Introduction
Consider an LSP L1 that has been established with its set of traffic Consider an LSP L1 that has been established with its set of traffic
parameters T0. A certain amount of bandwidth is reserved along the parameters T0. A certain amount of bandwidth is reserved along the
path of L1. Consider then that some changes are required on L1. For path of L1. Consider then that some changes are required on L1. For
example, the bandwidth of L1 needs to be increased to accommodate example, the bandwidth of L1 needs to be increased to accommodate
the increased traffic on L1. Or the SLA associated with L1 needs to the increased traffic on L1. Or the SLA associated with L1 needs to
be modified because a different service class is desired. The be modified because a different service class is desired. The
network operator, in these cases, would like to modify the network operator, in these cases, would like to modify the
characteristics of L1, for example, to change its traffic parameter characteristics of L1, for example, to change its traffic parameter
set from T0 to T1, without releasing the LSP L1 to interrupt the set from T0 to T1, without releasing the LSP L1 to interrupt the
service. In some other cases, network operators may want to reroute service. In some other cases, network operators may want to reroute
a CR-LSP to a different path for either improved performance or a CR-LSP to a different path for either improved performance or
better network resource utilization. In all these cases, LSP better network resource utilization. In all these cases, LSP
modification is required. In section 4 below, a method to modify an 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 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 is used to achieve the LSP modification, without releasing the LSP
and interrupting the service and, without double booking the and interrupting the service and, without double booking the
bandwidth. In Section 5, an example is described to demonstrate an bandwidth. In Section 5, an example is described to demonstrate an
application of the presented method in dynamically managing network application of the presented method in dynamically managing network
bandwidth requirements without interrupting service. Only a minimum bandwidth requirements without interrupting service. In CR-LDP, an
extension on CR-LDP, an action indication flag of _modify_ is needed action indicator flag of _modify_ is used in order to explicitly
in order to explicitly specify the behavior, and allow the existing specify the behavior, and allow the existing LSPID to support other
LSPID to support other networking capabilities in the future. networking capabilities in the future. Reference [3],
Reference [3], <draft-ietf-mpls-cr-ldp-03.txt>, specifies the action <draft-ietf-mpls-cr-ldp-03.txt>, specifies the action indicator flag
indication flag of _modify_ for CR-LDP. of _modify_ for CR-LDP.
4.0 LSP Modification Using CR-LDP 4. LSP Modification Using CR-LDP
4.1 Basic Procedure 4.1 Basic Procedure for Resource Modification
LSP modification can only be allowed when the LSP is already set up LSP modification can only be allowed when the LSP is already set up
and active. That is, modification is not defined nor allowed during and active. That is, modification is not defined nor allowed during
the LSP establishment or label release/withdraw phases. Only the LSP establishment or label release/withdraw phases. Only
modification requested by the ingress LSR of the LSP is considered modification requested by the ingress LSR of the LSP is considered
in this draft for CR-LSP. The Ingress LSR cannot modify an LSP before in this draft for CR-LSP. The Ingress LSR cannot modify an LSP before
a previous modification procedure is completed. a previous modification procedure is completed.
Assume that CR-LSP L1 is set up with LSPID L-id1, which is unique in 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 the MPLS network. The ingress LSR R1 of L1 has in its FTN (FEC To
skipping to change at page 4, line 14 skipping to change at page 4, line 14
for LSP L1. To modify the characteristics of L1, R1 sends a Label for LSP L1. To modify the characteristics of L1, R1 sends a Label
Request Message. In the message, the TLVs will have the new Request Message. In the message, the TLVs will have the new
requested values, and the LSPID TLV is included which indicates the requested values, and the LSPID TLV is included which indicates the
value of L-id1. The Traffic Parameters TLV, the ER-TLV, the Resource value of L-id1. The Traffic Parameters TLV, the ER-TLV, the Resource
Class (color) TLV and the Preemption TLV can have values different Class (color) TLV and the Preemption TLV can have values different
from those in the original Label Request Message, which has been 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 used to set up L1 earlier. Thus, L1 can be changed in its bandwidth
request (traffic parameter TLV), its traffic service class (traffic request (traffic parameter TLV), its traffic service class (traffic
parameter TLV), the route it traverses (ER TLV) and its setup and parameter TLV), the route it traverses (ER TLV) and its setup and
holding (Preemption TLV) priorities. The ingress LSR R1 now still holding (Preemption TLV) priorities. The ingress LSR R1 now still
has the entry in FTN as FEC1 -> Label A. R1 is waiting to establish has the entry in its FTN as FEC1 -> Label A. R1 is waiting to
another entry for FEC1. establish another entry for FEC1.
When an LSR Ri along the path of L1 receives the Label Request 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 message, its behavior is the same as that of receiving any Label
request message. The only extension is that Ri examines the LSPID request message. The only extension is that Ri examines the LSPID
carried in the Label Request Message, L-id1, and identifies if it 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 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 receiving a new Label Request message. If Ri already has L-id1, Ri
takes the newly received Traffic Parameter TLV and computes the new takes the newly received Traffic Parameter TLV and computes the new
bandwidth required and derives the new service class. Compared with bandwidth required and derives the new service class. Compared with
the already reserved bandwidth for L-id1, Ri now reserves only the the already reserved bandwidth for L-id1, Ri now reserves only the
difference of the bandwidth requirements. This prevents Ri from difference of the bandwidth requirements. This prevents Ri from
doing bandwidth double booking. If a new service class is requested, doing bandwidth double booking. If a new service class is requested,
Ri also prepares to receive the traffic on L1 in perhaps a Ri also prepares to receive the traffic on L1 in just the same way as
different type of queue, just the same as handling it for a Label handling it for a Label Request Message, perhaps using a different
Request Message. Ri assigns a new label for the Label Request type of queue. Ri assigns a new label for the Label Request Message.
Message.
When the Label Mapping message is received, two sets of labels exist 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 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 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 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 activate the new entry in its FTN, FEC1 - > Label B. This means that
swaps traffic on L1 to the new label _B_ (_new_ path) for L1. The 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 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 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 requested in the Label Request Message for the modification. All the
other LSRs along the path will start to receive the incoming packets 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 with the new label. For the incoming new label, the LSR has already
established its mapping to the new outgoing label. Thus, the packets 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 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 to implement new procedures to track the new and old characteristics
of the LSP. of the LSP.
The ingress LSR R1 then starts to release the original label A for 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 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 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 Label TLV to indicate which label is to be released. The Release
Message is propagated to the egress LSR to release the original Message is propagated to the egress LSR to release the original
labels previously used for L1. Upon receiving the Label Release labels previously used for L1. Upon receiving the Label Release
Message, LSR R1 examines the LSPID, L-id1, and finds out that the 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. L-id1 has still another set of labels (incoming/outgoing) under it.
Thus, the old label is released without releasing the resource in Thus, the old label is released without releasing the resource in
use. That is, if the bandwidth has been decreased for L1, the delta use. That is, if the bandwidth has been decreased for L1, the delta
bandwidth is released. Otherwise, no bandwidth is released. This bandwidth is released. Otherwise, no bandwidth is released. This
modification procedure can not only be applied to modify the traffic modification procedure can not only be applied to modify the traffic
parameters and/or service class of an active LSP, but also to parameters and/or service class of an active LSP, but also to
reroute an existing LSP, and/or change its setup/holding priority if reroute an existing LSP (as described in Section 4.2 below), and/or
desired. After the release procedure, the modification of the LSP is change its setup/holding priority if desired. After the release
completed. procedure, the modification of the LSP is completed.
The method described above follows the normal behavior of Label The method described above follows the normal behavior of Label
Request / Mapping / Notification / Release / Withdraw procedure of a Request / Mapping / Notification / Release / Withdraw procedure of a
CR-LDP operated LSR with a specific action taken on an LSPID. If a CR-LDP operated LSR with a specific action taken on an LSPID. If a
Label Withdraw Message is used to withdraw a label associated with an Label Withdraw Message is used to withdraw a label associated with an
LSPID, the Label TLV should be included to specify which label to LSPID, the Label TLV should be included to specify which label to
withdraw. Since the LSPID can also be used for other feature withdraw. Since the LSPID can also be used for other feature
support, an action indication flag of _modify_ assigned to the LSPID support, an action indication flag of _modify_ assigned to the LSPID
would explicitly explain the action/semantics that should be would explicitly explain the action/semantics that should be
associated with the messaging procedure. The details of this flag associated with the messaging procedure. The details of this flag
are addressed in the CR-LDP draft, Reference [3]. are addressed in the CR-LDP draft, Reference [3].
4.2 Priority Handling 4.2 Rerouting LSPs
LSP modification can also be used to reroute an existing LSP. Only
modification requested by the ingress LSR of the LSP is considered
in this draft for CR-LSP. The Ingress LSR cannot modify an LSP before
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 Label
Request Message. In the message, the LSPID TLV indicates L-id1 and
the Explicit Route TLV is specified with some different hops from
the explicit route specified in the original Label Request Message.
The action indication flag has the value _modify_.
At this point, the ingress LSR R1 still has an 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 a Label
Request Message that modifies some other parameters of the LSP.
Ri assigns a new label for the Label Request Message and forwards
the message along the explicit route. It does not allocate any
more resources except as described in section 4.1.
At another LSR Rj further along the path, the explicit route
diverges from the previous route. Rj acts as Ri, but forwards the
Label Request message along the new route. From this point onwards
the Label Request Message is treated as setting up a new LSP by
each LSR until the paths converge at later LSR Rk. The _modify_
value of the action indication flag is ignored.
At Rk and subsequent LSRs, the Label Request Message is handled as
at Ri.
On the return path, when the Label Mapping message is received, two
sets of labels for the LSPID exist where the new route coincide
with the old. Only one set of labels will exist at LSRs where the
routes diverge.
When the Label Mapping message is received at the ingress LSR R1 it
has two outgoing labels, A and B, associated with the same
FEC, where B is the new outgoing label received for LSP L1. R1 can
now activate the new entry in the FTN, FEC1 - > Label B and
de-activate the old entry FEC1 - > Label A. This means that R1
swaps traffic on L1 to the new label B. The packets are now sent
with the new label B, on the new path.
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 following the original route. The Release message
carries the LSPID of L-id1 and the Label TLV to indicate which
label is to be released. At each LSR the old label is released - no
further action is required to change the path of the data packets
which are already following the new route programmed by the Label
Mapping message.
At some LSRs, where the routes diverged, there is only one label
for the LSPID. For example, between Rj and Rk, the Label Release
Message will follow the old route. At LSRs between Rj and Rk only
the labels from the original route will exist for LSPID L-id1. At
these LSRs the LSPID TLV does not need to be examined to release the
correct label, but it must still be updated and passed on to the
next LSR as the Label Release message is propagated. In this way, at
Rk where the routes converge, the downstream LSR will know which
label to release and can continue to forward the Label Release
Message along the old route.
4.3 Priority Handling
When sending a Label Request Message for an active LSP L1 to request 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 changes, the setup priority used in the label Request Message can be
different from the one used in the previous Label Request Message, different from the one used in the previous Label Request Message,
effectively indicating the priority of this _modification_ request. effectively indicating the priority of this _modification_ request.
Network operators can use this feature to decide what priority is to Network operators can use this feature to decide what priority is to
be assigned to a modification request, based on their be assigned to a modification request, based on their
policies/algorithms and other traffic situations in the network. For policies/algorithms and other traffic situations in the network. For
example, the priority for modification can be determined by the example, the priority for modification can be determined by the
priority of the customer/LSP. If a customer has exceeded the priority of the customer/LSP. If a customer has exceeded the
skipping to change at page 5, line 43 skipping to change at page 6, line 53
modification request's priority may be given as a higher value. modification request's priority may be given as a higher value.
The Label Request message for the modification of an active LSP can The Label Request message for the modification of an active LSP can
also be sent with a holding priority different from its previous also be sent with a holding priority different from its previous
one. This effectively changes the holding priority of the LSP. one. This effectively changes the holding priority of the LSP.
Upon receiving a Label Request Message that requests a new holding Upon receiving a Label Request Message that requests a new holding
priority, the LSR assigns the new holding priority to the bandwidth. priority, the LSR assigns the new holding priority to the bandwidth.
That is, the new holding priority is assigned to both the existing That is, the new holding priority is assigned to both the existing
incoming / outgoing labels and the new labels to be established for incoming / outgoing labels and the new labels to be established for
the LSPID in question. In this way self-bumping is prevented. the LSPID in question. In this way self-bumping is prevented.
4.3 Modification Failure Case Handling 4.4 Modification Failure Case Handling
A modification attempt may fail due to insufficient resource or A modification attempt may fail due to insufficient resource or
other situations. A Notification message is sent back to the ingress other situations. A Notification message is sent back to the ingress
LSR R1 to indicate the failure of Label Request Message that LSR R1 to indicate the failure of Label Request Message that
intended to modify the LSP. A retry may be attempted if desired by intended to modify the LSP. A retry may be attempted if desired by
the network operator. If the LSP on the original path failed when a the network operator. If the LSP on the original path failed when a
modification attempt is in progress, the attempt should be aborted by modification attempt is in progress, the attempt should be aborted by
using the Label Abort Request message as specified in the LDP draft using the Label Abort Request message as specified in the LDP draft
[5]. [5].
5.0 Application of LSP Bandwidth Modification in Dynamic Resource In the event of a modification failure, all modifications to the LSP
including the holding priority must be restored to their original
values.
5. Application of LSP Bandwidth Modification in Dynamic Resource
Management Management
In this section, we gave an example of dynamic network resource In this section, we gave an example of dynamic network resource
management using the LSP bandwidth modification capability. The management using the LSP bandwidth modification capability. The
details of this example can be found in a previous Internet draft details of this example can be found in a previous Internet draft
[2]. Assume that customers or services are assigned with given [2]. Assume that customers or services are assigned with given
CR-LSPs. These customers/services are assigned with one of three CR-LSPs. These customers/services are assigned with one of three
priorities: key, normal or best effort. The network operator does priorities: key, normal or best effort. The network operator does
not want to bump any LSPs during an LSP setup, so after these not want to bump any LSPs during an LSP setup, so after these
CR-LSPs are set up, their holding priorities are all assigned as CR-LSPs are set up, their holding priorities are all assigned as
the highest value. the highest value.
The network operator wants to control the resource on the links of The network operator wants to control the resource on the links of
the LSRs, so all LSRs keep the usage status of their links. Based the LSRs, so each LSR keeps the usage status of its links. Based
on the usage history, each link is assigned a current threshold on the usage history, each link is assigned a current threshold
priority Pi, which means that the link has no bandwidth available priority Pi, which means that the link has no bandwidth available
for a Label Request with a setup priority lower than Pi. When an for a Label Request with a setup priority lower than Pi. When an
LSP's bandwidth needs to be modified, the operator uses a LSP's bandwidth needs to be modified, the operator uses a
policy-based algorithm to assign a priority for its modification policy-based algorithm to assign a priority for its modification
request, say Mp for LSP L2. The ingress LSR then sends a Label request, say Mp for LSP L2. The ingress LSR then sends a Label
Request message with Setup Priority = Mp. If there is sufficient Request message with Setup Priority = Mp. If there is sufficient
bandwidth on the link for the modification, and the Setup priority bandwidth on the link for the modification, and the Setup priority
in the Label Request Message is higher in priority (Mp numerically in the Label Request Message is higher in priority (Mp numerically
smaller) than the Pi threshold of the link, the Label Request smaller) than the Pi threshold of the link, the Label Request
skipping to change at page 6, line 52 skipping to change at page 8, line 10
on its existing path unsuccessfully if there is insufficient on its existing path unsuccessfully if there is insufficient
bandwidth available on L2. In that case, the operator is willing bandwidth available on L2. In that case, the operator is willing
to increase the bandwidth of another LSP, L3, with the same to increase the bandwidth of another LSP, L3, with the same
ingress/egress LSRs as L2, in order to increase the overall ingress/egress LSRs as L2, in order to increase the overall
ingress/egress bandwidth allocation. However, in this case the ingress/egress bandwidth allocation. However, in this case the
L3 bandwidth modification is performed with a lower priority L3 bandwidth modification is performed with a lower priority
(higher Mp value) since L3 is routed on a secondary path, which (higher Mp value) since L3 is routed on a secondary path, which
results in the higher bandwidth allocation priority being given results in the higher bandwidth allocation priority being given
to the LSPs that are on their primary paths [2]. to the LSPs that are on their primary paths [2].
6.0 Intellectual Property Considerations 6. Acknowledgments
The authors would like to acknowledge the careful review and
comments of Adrian Farrel.
7. Intellectual Property Considerations
Nortel Networks may seek patent or other intellectual property Nortel Networks may seek patent or other intellectual property
protection for some or all of the technologies disclosed in this protection for some or all of the technologies disclosed in this
document. If any standards arising from this document are or become document. If any standards arising from this document are or become
protected by one or more patents assigned to Nortel Networks, Nortel protected by one or more patents assigned to Nortel Networks, Nortel
Networks is prepared to make a license available to any qualified Networks is prepared to make a license available to any qualified
applicant upon reasonable and non-discriminatory terms and applicant upon reasonable and non-discriminatory terms and
conditions. Any such licenses will be subject to negotiations conditions. Any such licenses will be subject to negotiations
outside of the IETF. outside of the IETF.
7.0 Security Considerations 8. Security Considerations
No security issues are addressed in this draft. Protection against modification to LSPs by malign agents has to be
controlled by the MPLS domain.
8.0 References 9. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2 Ash, J., et. al., QoS Resource Management in MPLS-Based Networks, 2 Ash, J., et. al., QoS Resource Management in MPLS-Based Networks,
draft-ash-qos-routing-00.txt, (work in progress). draft-ash-qos-routing-00.txt, (work in progress).
3 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP, 3 Jamoussi, B., et. al., Constraint-Based LSP Setup using LDP,
draft-ietf-mpls-cr-ldp-03.txt, September 1999,(work in progress). draft-ietf-mpls-cr-ldp-03.txt, September 1999,(work in progress).
4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
5 Andersson, L., et. al., LDP Specification, draft-ietf-mpls-ldp- 5 Andersson, L., et. al., LDP Specification, draft-ietf-mpls-ldp-
05.txt (work in progress). 05.txt (work in progress).
9.0 Authors' Addresses 10. Authors' Addresses
Gerald R. Ash Young Lee Gerald R. Ash Young Lee
AT&T AT&T AT&T AT&T
Room MT E3-3C37 Room MT C5-2D20 Room MT E3-3C37 Room MT C5-2D20
200 Laurel Avenue 200 Laurel Avenue 200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748 Middletown, NJ 07748 Middletown, NJ 07748
USA USA USA USA
Phone: 732-420-4578 Phone: 732-420-4477 Phone: 732-420-4578 Phone: 732-420-4477
Fax: 732-440-6687 Fax: 732-368-1730 Fax: 732-440-6687 Fax: 732-368-1730
Email: gash@att.com Email: younglee@att.com Email: gash@att.com Email: younglee@att.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/