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
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
|
<pre>Network Working Group K. Kompella
Request for Comments: 4201 Y. Rekhter
Updates: <a href="./rfc3471">3471</a>, <a href="./rfc3472">3472</a>, <a href="./rfc3473">3473</a> Juniper Networks
Category: Standards Track L. Berger
Movaz Networks
October 2005
<span class="h1">Link Bundling in MPLS Traffic Engineering (TE)</span>
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 (2005).
Abstract
For the purpose of Generalized Multi-Protocol Label Switching (GMPLS)
signaling, in certain cases a combination of <link identifier, label>
is not sufficient to unambiguously identify the appropriate resource
used by a Label Switched Path (LSP). Such cases are handled by using
the link bundling construct, which is described in this document.
This document updates the interface identification TLVs, which are
defined in the GMPLS Signaling Functional Description.
<span class="grey">Kompella, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4201">RFC 4201</a> Link Bundling in MPLS-TE October 2005</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ................................................. <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Specification of Requirements .......................... <a href="#page-2">2</a>
<a href="#section-2">2</a>. Link Bundling ................................................ <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Restrictions on Bundling ............................... <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Routing Considerations ................................. <a href="#page-4">4</a>
<a href="#section-2.3">2.3</a>. Signaling Considerations ............................... <a href="#page-5">5</a>
<a href="#section-2.3.1">2.3.1</a>. Interface Identification TLV Format ............ <a href="#page-6">6</a>
<a href="#section-2.3.2">2.3.2</a>. Errored Component Identification ............... <a href="#page-7">7</a>
<a href="#section-3">3</a>. Traffic Engineering Parameters for Bundled Links ............. <a href="#page-7">7</a>
<a href="#section-3.1">3.1</a>. OSPF Link Type ......................................... <a href="#page-7">7</a>
<a href="#section-3.2">3.2</a>. OSPF Link ID ........................................... <a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. Local and Remote Interface IP Address .................. <a href="#page-7">7</a>
<a href="#section-3.4">3.4</a>. Local and Remote Identifiers ........................... <a href="#page-8">8</a>
<a href="#section-3.5">3.5</a>. Traffic Engineering Metric ............................. <a href="#page-8">8</a>
<a href="#section-3.6">3.6</a>. Maximum Bandwidth ...................................... <a href="#page-8">8</a>
<a href="#section-3.7">3.7</a>. Maximum Reservable Bandwidth ........................... <a href="#page-8">8</a>
<a href="#section-3.8">3.8</a>. Unreserved Bandwidth ................................... <a href="#page-8">8</a>
<a href="#section-3.9">3.9</a>. Resource Classes (Administrative Groups) ............... <a href="#page-8">8</a>
<a href="#section-3.10">3.10</a>. Maximum LSP Bandwidth ................................. <a href="#page-8">8</a>
<a href="#section-4">4</a>. Bandwidth Accounting ......................................... <a href="#page-9">9</a>
<a href="#section-5">5</a>. Security Considerations ...................................... <a href="#page-9">9</a>
<a href="#section-6">6</a>. IANA Considerations .......................................... <a href="#page-9">9</a>
<a href="#section-7">7</a>. References ................................................... <a href="#page-10">10</a>
<a href="#section-7.1">7.1</a>. Normative References ................................... <a href="#page-10">10</a>
<a href="#section-7.2">7.2</a>. Informative References ................................. <a href="#page-11">11</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
For the purpose of Generalized Multi-Protocol Label Switching (GMPLS)
signaling, in certain cases a combination of <link identifier, label>
is not sufficient to unambiguously identify the appropriate resource
used by a Label Switched Path (LSP). Such cases are handled by using
the link bundling construct, which is described in this document.
This document updates the interface identification TLVs, which are
defined in the GMPLS Signaling Functional Description.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Specification of Requirements</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Kompella, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4201">RFC 4201</a> Link Bundling in MPLS-TE October 2005</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Link Bundling</span>
As defined in [<a href="#ref-GMPLS-ROUTING" title=""Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">GMPLS-ROUTING</a>], a traffic engineering (TE) link is a
logical construct that represents a way to group/map information
about certain physical resources (and their properties) that
interconnect LSRs with information that is used by Constrained SPF
(for the purpose of path computation) and by GMPLS signaling.
As stated in [<a href="#ref-GMPLS-ROUTING" title=""Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">GMPLS-ROUTING</a>], depending on the nature of resources
that form a particular TE link for the purpose of GMPLS signaling, in
some cases a combination of <TE link identifier, label> is sufficient
to unambiguously identify the appropriate resource used by an LSP.
In other cases, a combination of <TE link identifier, label> is not
sufficient. Consider, for example, a TE link between a pair of
SONET/SDH cross-connects, where this TE link is composed of several
fibers. In this case the label is a TDM time slot, and moreover,
this time slot is significant only within a particular fiber. Thus,
when signaling an LSP over such a TE link, one needs to specify not
just the identity of the link, but also the identity of a particular
fiber within that TE link, as well as a particular label (time slot)
within that fiber. Such cases are handled by using the link bundling
construct, which is described in this document.
Consider a TE link such that, for the purpose of GMPLS signaling, a
combination of <TE link identifier, label> is not sufficient to
unambiguously identify the appropriate resources used by an LSP. In
this situation, the link bundling construct assumes that the set of
resources that form the TE link could be partitioned into disjoint
subsets, such that (a) the partition is minimal, and (b) within each
subset, a label is sufficient to unambiguously identify the
appropriate resources used by an LSP. We refer to such subsets as
"component links", and to the whole TE link as a "bundled link".
Furthermore, we restrict the identifiers that can be used to identify
component links such that they are unique for a given node. On a
bundled link, a combination of <component link identifier, label> is
sufficient to unambiguously identify the appropriate resources used
by an LSP.
The partition of resources that form a bundled link into component
links has to be done consistently at both ends of the bundled link.
Both ends of the bundled link also have to understand the other end's
component link identifiers.
The purpose of link bundling is to improve routing scalability by
reducing the amount of information that has to be handled by OSPF
and/or IS-IS. This reduction is accomplished by performing
information aggregation/abstraction. As with any other information
aggregation/abstraction, this results in losing some of the
<span class="grey">Kompella, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4201">RFC 4201</a> Link Bundling in MPLS-TE October 2005</span>
information. To limit the amount of losses, one needs to restrict
the type of information that can be aggregated/abstracted.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Restrictions on Bundling</span>
All component links in a bundle have the same Link Type (i.e.,
point-to-point or multi-access), the same Traffic Engineering metric,
the same set of resource classes at each end of the links, and must
begin and end on the same pair of LSRs.
A Forwarding Adjacency may be a component link; in fact, a bundle can
consist of a mix of point-to-point links and FAs.
If the component links are all multi-access links, the set of IS-IS
or OSPF routers that are connected to each component link must be the
same, and the Designated Router for each component link must be the
same. If these conditions cannot be enforced, multi-access links
must not be bundled.
Component link identifiers MUST be unique across both TE and
component link identifiers on a particular node. This means that
unnumbered identifiers have a node-wide scope, and that numbered
identifiers have the same scope as IP addresses.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Routing Considerations</span>
A component link may be either numbered or unnumbered. A bundled
link may itself be numbered or unnumbered, independent of whether the
component links of that bundled link are numbered.
Handling identifiers for unnumbered component links, including the
case in which a link is formed by a Forwarding Adjacency, follows the
same rules as those for an unnumbered TE link (see Section "Link
Identifiers" of [<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>]/[<a href="./rfc3480" title=""Signalling Unnumbered Links in CR-LDP (Constraint- Routing Label Distribution Protocol)"">RFC3480</a>]). Furthermore, link local
identifiers for all unnumbered links of a given LSR (whether
component links, Forwarding Adjacencies, or bundled links) MUST be
unique in the context of that LSR.
The "liveness" of the bundled link is determined by the liveness of
each of the component links within the bundled link; a bundled link
is alive when at least one of its component links is determined to be
alive. The liveness of a component link can be determined by any of
several means: IS-IS or OSPF hellos over the component link, RSVP
Hello, LMP hellos (see [<a href="#ref-LMP" title=""Link Management Protocol (LMP)"">LMP</a>]), or from layer 1 or layer 2
indications.
<span class="grey">Kompella, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4201">RFC 4201</a> Link Bundling in MPLS-TE October 2005</span>
Once a bundled link is determined to be alive, it can be advertised
as a TE link and the TE information can be flooded. If IS-IS/OSPF
hellos are run over the component links, IS-IS/OSPF flooding can be
restricted to just one of the component links. Procedures for doing
this are outside the scope of this document.
In the future, as new Traffic Engineering parameters are added to
IS-IS and OSPF, they should be accompanied by descriptions as to how
they can be bundled, and possible restrictions on bundling.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Signaling Considerations</span>
Because information about the bundled link is flooded, but
information about the component links is not, typically, an LSP's ERO
will identify the bundled link to be used for the LSP, but not the
component link. While Discovery of component link identities to be
used in an ERO is outside the scope of the document, it is envisioned
that such information may be provided via configuration or via future
RRO extensions. When the bundled link is identified in an ERO or is
dynamically identified, the choice of the component link for the LSP
is a local matter between the two LSRs at each end of the bundled
link.
Signaling must identify both the component link and label to use.
The choice of the component link to use is always made by the sender
of the Path/REQUEST message. If an LSP is bidirectional [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>],
the sender chooses a component link in each direction. The handling
of labels is not modified by this document.
Component link identifiers are carried in RSVP messages, as described
in <a href="./rfc3473#section-8">section 8 of [RFC3473]</a>. Component link identifiers are carried in
CR-LDP messages, as described in <a href="./rfc3473#section-8">section 8 of [RFC3473]</a>. Additional
processing related to unnumbered links is described in the
"Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV",
and "Unnumbered Forwarding Adjacencies" sections of
[<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>]/[<a href="./rfc3480" title=""Signalling Unnumbered Links in CR-LDP (Constraint- Routing Label Distribution Protocol)"">RFC3480</a>].
[<a id="ref-RFC3471">RFC3471</a>] defines the Interface Identification type-length-value
(TLV) types. This document specifies that the TLV types 1, 2, and 3
SHOULD be used to indicate component links in IF_ID RSVP_HOP objects
and IF_ID TLVs.
Type 1 TLVs are used for IPv4 numbered component link identifiers.
Type 2 TLVs are used for IPv6 numbered component link identifiers.
Type 3 TLVs are used for unnumbered component link identifiers.
<span class="grey">Kompella, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4201">RFC 4201</a> Link Bundling in MPLS-TE October 2005</span>
The Component Interface TLVs, TLV types 4 and 5, SHOULD NOT be used.
Note, in Path and REQUEST messages, link identifiers MUST be
specified from the sender's perspective.
Except in the special case noted below, for a unidirectional LSP,
only a single TLV SHOULD be used in an IF_ID RSVP_HOP object or IF_ID
TLV. This TLV indicates the component link identifier of the
downstream data channel on which label allocation must be done.
Except in the special case noted below, for a bidirectional LSP, only
one or two TLVs SHOULD be used in an IF_ID RSVP_HOP object or IF_ID
TLV. The first TLV always indicates the component link identifier of
the downstream data channel on which label allocation must be done.
When present, the second TLV always indicates the component link
identifier of the upstream data channel on which label allocation
must be done. When only one TLV is present, it indicates the
component link identifier for both downstream and upstream data
channels.
In the special case where the same label is to be valid across all
component links, two TLVs SHOULD be used in an IF_ID RSVP_HOP object
or IF_ID TLV. The first TLV indicates the TE link identifier of the
bundle on which label allocation must be done. The second TLV
indicates a bundle scope label. For TLV types 1 and 2, this is done
by using the special bit value of all ones (1) (e.g., 0xFFFFFFFF for
a type 1 TLV). Per [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>], for TLV types 3, 4, and 5, this is
done by setting the Interface ID field to the special value
0xFFFFFFFF. Note that this special case applies to both
unidirectional and bidirectional LSPs.
Although it SHOULD NOT be used, when used, the type 5 TLV MUST NOT be
the first TLV in an IF_ID RSVP_HOP object or IF_ID TLV.
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. Interface Identification TLV Format</span>
This section modifies <a href="./rfc3471#section-9.1.1">section 9.1.1. of [RFC3471]</a>. The definition of
the IP Address field of the TLV types 3, 4, and 5 is clarified.
For types 3, 4, and 5, the Value field has an identical format to
the contents of the C-Type 1 LSP_TUNNEL_INTERFACE_ID object
defined in [<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>]. Note that this results in the renaming of
the IP Address field defined in [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>].
<span class="grey">Kompella, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4201">RFC 4201</a> Link Bundling in MPLS-TE October 2005</span>
<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>. Errored Component Identification</span>
When Interface Identification TLVs are used, the TLVs are also used
to indicate the specific components associated with an error. For
RSVP, this means that any received TLVs SHOULD be copied into the
IF_ID ERROR_SPEC object (see <a href="./rfc3473#section-8.2">Section 8.2 in [RFC3473]</a>). The Error
Node Address field of the object SHOULD indicate the TE Link
associated with the error. For CR-LDP, this means that any received
TLVs SHOULD be copied into the IF_ID Status TLV (see <a href="./rfc3472#section-8.2">Section 8.2 in
[RFC3472]</a>). The HOP Address field of the TLV SHOULD indicate the TE
Link associated with the error.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Traffic Engineering Parameters for Bundled Links</span>
In this section, we define the Traffic Engineering parameters to be
advertised for a bundled link, based on the configuration of the
component links and of the bundled link. The definition of these
parameters for component links was undertaken in [<a href="./rfc3784" title=""Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)"">RFC3784</a>] and
[<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>]; we use the terminology from [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>].
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. OSPF Link Type</span>
The Link Type of a bundled link is the (unique) Link Type of the
component links. Note that this parameter is not present in IS-IS.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. OSPF Link ID</span>
For point-to-point links, the Link ID of a bundled link is the
(unique) Router ID of the neighbor. For multi-access links, this is
the interface address of the (unique) Designated Router. Note that
this parameter is not present in IS-IS.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Local and Remote Interface IP Address</span>
Note that in IS-IS, the Local Interface IP Address is known as the
IPv4 Interface Address and the Remote Interface IP Address is known
as the IPv4 Neighbor Address.
If the bundled link is numbered, the Local Interface IP Address is
the local address of the bundled link; similarly, the Remote
Interface IP Address is the remote address of the bundled link.
<span class="grey">Kompella, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4201">RFC 4201</a> Link Bundling in MPLS-TE October 2005</span>
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Local and Remote Identifiers</span>
If the bundled link is unnumbered, the link local identifier is set
to the identifier chosen for the bundle by the advertising LSR. The
link remote identifier is set to the identifier chosen by the
neighboring LSR for the reverse link corresponding to this bundle, if
known; otherwise, this is set to 0.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Traffic Engineering Metric</span>
The Traffic Engineering Metric for a bundled link is that of the
component links.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Maximum Bandwidth</span>
This parameter is not used. The maximum LSP Bandwidth (as described
below) replaces the Maximum Bandwidth for bundled links.
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Maximum Reservable Bandwidth</span>
For a given bundled link, we assume that either each of its component
links is configured with the Maximum Reservable Bandwidth, or the
bundled link is configured with the Maximum Reservable Bandwidth. In
the former case, the Maximum Reservable Bandwidth of the bundled link
is set to the sum of the Maximum Reservable Bandwidths of all
component links associated with the bundled link.
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>. Unreserved Bandwidth</span>
The unreserved bandwidth of a bundled link at priority p is the sum
of the unreserved bandwidths at priority p of all the component links
associated with the bundled link.
<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a>. Resource Classes (Administrative Groups)</span>
The Resource Classes for a bundled link are the same as those of the
component links.
<span class="h3"><a class="selflink" id="section-3.10" href="#section-3.10">3.10</a>. Maximum LSP Bandwidth</span>
The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth.
For an unbundled link, the Maximum Bandwidth is defined in
[<a href="#ref-GMPLS-ROUTING" title=""Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">GMPLS-ROUTING</a>]. The Maximum LSP Bandwidth of a bundled link at
priority p is defined to be the maximum of the Maximum LSP Bandwidth
at priority p of all of its component links.
<span class="grey">Kompella, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4201">RFC 4201</a> Link Bundling in MPLS-TE October 2005</span>
The details of how Maximum LSP Bandwidth is carried in IS-IS is given
in [<a href="#ref-GMPLS-ISIS" title=""Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">GMPLS-ISIS</a>]. The details of how Maximum LSP Bandwidth is carried
in OSPF is given in [<a href="#ref-GMPLS-OSPF" title=""OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">GMPLS-OSPF</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Bandwidth Accounting</span>
The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an
LSR with bundled links must apply admission control on a per-
component link basis. An LSP with a bandwidth requirement b and
setup priority p fits in a bundled link if at least one component
link has a maximum LSP bandwidth >= b at priority p. If there are
several such links, the implementation will choose which link to use
for the LSP.
In order to know the maximum LSP bandwidth (per priority) of each
component link, the Traffic Control module must track the unreserved
bandwidth (per priority) for each component link.
A change in the unreserved bandwidth of a component link results in a
change in the unreserved bandwidth of the bundled link. It also
potentially results in a change in the maximum LSP bandwidth of the
bundle; thus, the maximum LSP bandwidth should be recomputed.
If one of the component links goes down, the associated bundled link
remains up and continues to be advertised, provided that at least one
component link associated with the bundled link is up. The
unreserved bandwidth of the component link that is down is set to
zero, and the unreserved bandwidth and maximum LSP bandwidth of the
bundle must be recomputed. If all the component links associated
with a given bundled link are down, the bundled link MUST not be
advertised into OSPF/IS-IS.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This document defines ways of utilizing procedures defined in other
documents, referenced herein. Any security issues related to those
procedures are addressed in the referenced documents. Thus, this
document raises no new security issues for RSVP-TE [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>] or CR-
LDP [<a href="./rfc3212" title=""Constraint-Based LSP Setup using LDP"">RFC3212</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
This document changes the recommended usage of two of the
Interface_ID Types defined in [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>]. For this reason, the IANA
registry of GMPLS Signaling Parameters has been updated to read:
4 12 COMPONENT_IF_DOWNSTREAM - DEPRECATED
5 12 COMPONENT_IF_UPSTREAM - DEPRECATED
<span class="grey">Kompella, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4201">RFC 4201</a> Link Bundling in MPLS-TE October 2005</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-GMPLS-ISIS">GMPLS-ISIS</a>] Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate
System to Intermediate System (IS-IS) Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", <a href="./rfc4205">RFC 4205</a>, October 2005.
[<a id="ref-GMPLS-OSPF">GMPLS-OSPF</a>] Kompella, K. Ed. and Y. Rekhter, Ed., "OSPF
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", <a href="./rfc4203">RFC 4203</a>, October 2005.
[<a id="ref-GMPLS-ROUTING">GMPLS-ROUTING</a>] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", <a href="./rfc4202">RFC 4202</a>, October 2005.
[<a id="ref-RFC3471">RFC3471</a>] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
<a href="./rfc3471">RFC 3471</a>, January 2003.
[<a id="ref-RFC3473">RFC3473</a>] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
<a href="./rfc3473">RFC 3473</a>, January 2003.
[<a id="ref-RFC3472">RFC3472</a>] Ashwood-Smith, P. and L. Berger, "Generalized Multi-
Protocol Label Switching (GMPLS) Signaling
Constraint-based Routed Label Distribution Protocol
(CR-LDP) Extensions", <a href="./rfc3472">RFC 3472</a>, January 2003.
[<a id="ref-RFC3784">RFC3784</a>] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", <a href="./rfc3784">RFC 3784</a>, June 2004.
[<a id="ref-RFC3630">RFC3630</a>] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", <a href="./rfc3630">RFC</a>
<a href="./rfc3630">3630</a>, September 2003.
[<a id="ref-RFC3480">RFC3480</a>] Kompella, K., Rekhter, Y., and A. Kullberg,
"Signalling Unnumbered Links in CR-LDP (Constraint-
Routing Label Distribution Protocol)", <a href="./rfc3480">RFC 3480</a>,
February 2003.
[<a id="ref-RFC3477">RFC3477</a>] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Links in Resource ReSerVation Protocol - Traffic
Engineering (RSVP-TE)", <a href="./rfc3477">RFC 3477</a>, January 2003.
<span class="grey">Kompella, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4201">RFC 4201</a> Link Bundling in MPLS-TE October 2005</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3209">RFC3209</a>] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", <a href="./rfc3209">RFC 3209</a>, December 2001.
[<a id="ref-RFC3212">RFC3212</a>] Jamoussi, B., 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", <a href="./rfc3212">RFC 3212</a>, January 2002.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-LMP">LMP</a>] Lang, J., Ed., "Link Management Protocol (LMP)", <a href="./rfc4204">RFC</a>
<a href="./rfc4204">4204</a>, October 2005.
Authors' Addresses
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Yakov Rekhter
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
EMail: yakov@juniper.net
Lou Berger
Movaz Networks, Inc.
Phone: +1 703-847-1801
EMail: lberger@movaz.com
<span class="grey">Kompella, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4201">RFC 4201</a> Link Bundling in MPLS-TE October 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kompella, et al. Standards Track [Page 12]
</pre>
|
