summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3214.txt
blob: 9e03b92e004f950135153ec876e70e03e26e8fa3 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
Network Working Group                                             J. Ash
Request for Comments: 3214                                          AT&T
Category: Standards Track                                         Y. Lee
                                                        Ceterus Networks
                                                        P. Ashwood-Smith
                                                             B. Jamoussi
                                                                D. Fedyk
                                                             D. Skalecki
                                                         Nortel Networks
                                                                   L. Li
                                                            SS8 Networks
                                                            January 2002


                     LSP Modification Using CR-LDP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document presents an approach to modify the bandwidth and
   possibly other parameters of an established CR-LSP (Constraint-based
   Routed Label Switched Paths) using CR-LDP (Constraint-based Routed
   Label Distribution Protocol) without service interruption.  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.  The LSP modification feature can be
   supported by CR-LDP by use of the _modify_value for the _action
   indicator flag_ in the LSPID TLV.  This feature has application in
   dynamic network resources management where traffic of different
   priorities and service classes is involved.










Ash, et al.                 Standards Track                     [Page 1]
^L
RFC 3214             LSP Modification Using CR-LDP          January 2002


Table of Contents

   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 Resource
       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 Document

   L:           LSP (Label Switched Path)
   L-id:        LSPID (LSP Identifier)
   T:           Traffic Parameters
   R:           LSR (Label Switching Router)
   FEC:         Forwarding Equivalence Class
   NHLFE:       Next Hop Label Forwarding Entry
   FTN:         FEC To NHLFE
   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].

2. 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 3 below, a method to modify an active LSP using CR-LDP is



Ash, et al.                 Standards Track                     [Page 2]
^L
RFC 3214             LSP Modification Using CR-LDP          January 2002


   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 4, an example
   is described to demonstrate an application of the presented method in
   dynamically managing network bandwidth requirements without
   interrupting service.  In CR-LDP, an action indicator flag of
   _modify_ is used in order to explicitly specify the behavior, and
   allow the existing LSPID to support other networking capabilities in
   the future.  Reference [3], RFC XXXX, specifies the action indicator
   flag of _modify_ for CR-LDP.

3. LSP Modification Using CR-LDP

3.1 Basic Procedure for Resource Modification

   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 document 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
   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 its 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



Ash, et al.                 Standards Track                     [Page 3]
^L
RFC 3214             LSP Modification Using CR-LDP          January 2002


   bandwidth double booking.  If a new service class is requested, Ri
   also prepares to receive the traffic on L1 in just the same way as
   handling it for a Label Request Message, perhaps using a different
   type of queue.  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 its 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 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 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 (as described in Section 3.2 below), 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 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 document, Reference [3].



Ash, et al.                 Standards Track                     [Page 4]
^L
RFC 3214             LSP Modification Using CR-LDP          January 2002


3.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 document 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 3.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.





Ash, et al.                 Standards Track                     [Page 5]
^L
RFC 3214             LSP Modification Using CR-LDP          January 2002


   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.

3.3 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.

3.4 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




Ash, et al.                 Standards Track                     [Page 6]
^L
RFC 3214             LSP Modification Using CR-LDP          January 2002


   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 document [5].

   In the event of a modification failure, all modifications to the LSP
   including the holding priority must be restored to their original
   values.

4. 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
   [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 each LSR keeps the usage status of its 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



Ash, et al.                 Standards Track                     [Page 7]
^L
RFC 3214             LSP Modification Using CR-LDP          January 2002


   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].

5. Acknowledgments

   The authors would like to acknowledge the careful review and comments
   of Adrian Farrel.

6. Intellectual Property Considerations

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

7. Security Considerations

   Protection against modification to LSPs by malign agents has to be
   controlled by the MPLS domain.

8. References

   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       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]
^L
RFC 3214             LSP Modification Using CR-LDP          January 2002


   [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       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 Label
       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' Addresses

   Gerald R. Ash
   AT&T
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748
   USA
   Phone: 732-420-4578
   EMail: gash@att.com

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

   Peter Ashwood-Smith
   Nortel Networks Corp.
   P O Box 3511 Station C
   Ottawa, ON K1Y 4H7
   Canada
   Phone: +1 613 763-4534
   EMail: petera@NortelNetworks.com









Ash, et al.                 Standards Track                     [Page 9]
^L
RFC 3214             LSP Modification Using CR-LDP          January 2002


   Darek Skalecki
   Nortel Networks Corp.
   P O Box 3511 Station C
   Ottawa, ON K1Y 4H7
   Canada
   Phone: +1 613 765-2252
   EMail: dareks@nortelnetworks.com

   Young Lee
   Ceterus Networks
   EMail: ylee@ceterusnetworks.com

   Li Li
   SS8 Networks
   495 March Rd., 5th Floor
   Kanata, Ontario
   K2K 3G1 Canada
   Phone: +1 613 592-2100 ext. 3228
   EMail: lili@ss8networks.com

   Don Fedyk
   Nortel Networks Corp.
   600 Tech Park
   Billerica, MA 01821
   USA
   Phone: 978-288-3041
   EMail: dwfedyk@nortelnetworks.com
























Ash, et al.                 Standards Track                    [Page 10]
^L
RFC 3214             LSP Modification Using CR-LDP          January 2002


10. Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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
   English.

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

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Ash, et al.                 Standards Track                    [Page 11]
^L