[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 RFC 3214

MPLS WG                                                          J. Ash
Internet Draft                                                   Y. Lee
Document: draft-ietf-mpls-crlsp-modify-00.txt                      AT&T

                                                       P. Ashwood-Smith
                                                            B. Jamoussi
                                                               D. Fedyk
                                                            D. Skalecki
                                                        Nortel Networks

                                                                  L. Li
                                                           SS8 Networks

                                                          December 1999
Expires: June 2000

                     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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

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_ [3].  This feature has
   application in dynamic network resources management where traffic of
   different priorities and service classes is involved.

Ash, et. al.           <draft-ietf-mpls-crlsp-modify-00.txt>     [Page 1]

Internet Draft          LSP Modification Using CR-LDP      December, 1999

Table of Contents

1.0 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.0 Conventions Used in This Document  . . . . . . . . . . . . . . . . 3
3.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.0 LSP Modification Using CR-LDP. . . . . . . . . . . . . . . . . . . 3
4.1 Basic Procedure  . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2 Priority Handling  . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3 Modification Failure Case Handling . . . . . . . . . . . . . . . . 5
5.0 Application of LSP Bandwidth Modification in Dynamic Resource
    Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.0 Intellectual Property Considerations . . . . . . . . . . . . . . . 6
7.0 Security Considerations  . . . . . . . . . . . . . . . . . . . . . 7
8.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7

Ash, et. al.           <draft-ietf-mpls-crlsp-modify-00.txt>     [Page 2]

Internet Draft          LSP Modification Using CR-LDP      December, 1999

2.0 Conventions Used in This Document

   L:           LSP (Label Switched Path)
   Lid:         LSPID (LSP Identifier)
   T:           Traffic Parameters
   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",
   this document are to be interpreted as described in RFC-2119 [4].

3.0 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.  In Section 5, an example is described to demonstrate an
   application of the presented method in dynamically managing network
   bandwidth requirements without interrupting service.  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.
   Reference [3], <draft-ietf-mpls-cr-ldp-03.txt>, specifies the action
   indication flag of _modify_ for CR-LDP.

4.0 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.  The 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

Ash, et. al.           <draft-ietf-mpls-crlsp-modify-00.txt>     [Page 3]

Internet Draft          LSP Modification Using CR-LDP      December, 1999

   for LSP L1.  To modify the characteristics of L1, R1 sends a Label
   Request Message.  In the message, 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

   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 labels (incoming/outgoing) under it.
   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

Ash, et. al.           <draft-ietf-mpls-crlsp-modify-00.txt>     [Page 4]

Internet Draft          LSP Modification Using CR-LDP      December, 1999

   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

   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 an LSPID.  If a
   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 the CR-LDP draft, Reference [3].

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 as a higher value.
   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.  A retry may be attempted if desired by
   the network operator.  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 the LDP draft

5.0 Application of LSP Bandwidth Modification in Dynamic Resource

   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

Ash, et. al.           <draft-ietf-mpls-crlsp-modify-00.txt>     [Page 5]

Internet Draft          LSP Modification Using CR-LDP      December, 1999

   [2].  Assume that customers or services are assigned with given
   CR-LSPs.  These customers/services are assigned with one of three
   priorities: key, normal or best effort.  The network operator does
   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
   the highest value.

   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
   on the usage history, each link is assigned a current threshold
   priority Pi, which means that the link has no bandwidth available
   for a Label Request with a setup priority lower than Pi.  When an
   LSP's bandwidth needs to be modified, the operator uses a
   policy-based algorithm to assign a priority for its modification
   request, say Mp for LSP L2. The ingress LSR then sends a Label
   Request message with Setup Priority = Mp.  If there is sufficient
   bandwidth on the link for the modification, and the Setup priority
   in the Label Request Message is higher in priority (Mp numerically
   smaller) than the Pi threshold 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 which
   indicates that there are insufficient resources.  It should also be
   noted that when OSPF (or IS-IS) floods the available-link-bandwidth
   information, the available bandwidth associated with a priority
   lower than Pi (numerical value bigger) should be interpreted as _0_.

   This example based on a priority threshold Pi is implementation
   specific, and illustrates the flexibility of the modification
   procedure to prioritize and control network resources.
   The calculation of Mp can be network and service dependent, and is
   based on the operator's routing policy.  For example, the operator
   may assign a higher priority (lower Mp value) to L2 bandwidth
   modification if L2 belongs to a customer or service with _Key_
   priority.  The operator may also collect the actual usage of each
   LSP and assign a lower priority (higher Mp) to L2
   bandwidth-increase modification if, for example, in the past week
   L2 has exceeded its reserved bandwidth by 2 times on the average.
   In addition, an operator may try to increase the bandwidth of L2
   on its existing path unsuccessfully if there is insufficient
   bandwidth available on L2.  In that case, the operator is willing
   to increase the bandwidth of another LSP, L3, with the same
   ingress/egress LSRs as L2, in order to increase the overall
   ingress/egress bandwidth allocation.  However, in this case the
   L3 bandwidth modification is performed with a lower priority
   (higher Mp value) since L3 is routed on a secondary path, which
   results in the higher bandwidth allocation priority being given
    to the LSPs that are on their primary paths [2].

6.0 Intellectual Property Considerations

   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.

Ash, et. al.           <draft-ietf-mpls-crlsp-modify-00.txt>     [Page 6]

Internet Draft          LSP Modification Using CR-LDP      December, 1999

7.0 Security Considerations

   No security issues are addressed in this draft.

8.0 References

   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-03.txt, September 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.0 Authors' Addresses

   Gerald R. Ash                           Young Lee
   AT&T                                    AT&T
   Room MT E3-3C37                         Room MT C5-2D20
   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-368-1730
   Email: gash@att.com                     Email: younglee@att.com

   Bilel Jamoussi
   Nortel Networks Corp.
   600 Tech Park
   Billerica, MA 01821
   phone: 978-288-4506
   Email: jamoussi@NortelNetworks.com

   Peter Ashwood-Smith                     Li Li
   Nortel Networks Corp.                   SS8 Networks
   P O Box 3511 Station C                  135 Michael Cowpland Drive
   Ottawa, ON K1Y 4H7                      Suite 200
   Canada                                  Kanata, Ontario
   phone: +1 613 763-4534                  K2M 2E9 Canada
   Email: petera@NortelNetworks.com        phone: +1 613 592-4686
                                           Email: lili@ss8networks.com

   Darek Skalecki                          Don Fedyk
   Nortel Networks Corp.                   Nortel Networks Corp.
   P O Box 3511 Station C                  600 Tech Park
   Ottawa, ON K1Y 4H7                      Billerica, MA 01821
   Canada                                  USA
   phone: +1 613 765-2252                  phone: 978-288-3041
   Email: skalecki@NortelNetworks.com      fedyk@NortelNetworks.com

Ash, et. al.           <draft-ietf-mpls-crlsp-modify-00.txt>     [Page 7]

Internet Draft          LSP Modification Using CR-LDP      December, 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 implementation 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 languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

Ash, et. al.           <draft-ietf-mpls-crlsp-modify-00.txt>     [Page 8]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/