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
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
<pre>Network Working Group H. Smit
Request for Comments: 3784 Procket Networks
Category: Informational T. Li
June 2004
<span class="h1">Intermediate System to Intermediate System (IS-IS)</span>
<span class="h1">Extensions for Traffic Engineering (TE)</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes extensions to the Intermediate System to
Intermediate System (IS-IS) protocol to support Traffic Engineering
(TE). This document extends the IS-IS protocol by specifying new
information that an Intermediate System (router) can place in Link
State Protocol (LSP) Data Units. This information describes
additional details regarding the state of the network that are useful
for traffic engineering computations.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The IS-IS protocol is specified in ISO 10589 [<a href="#ref-1" title=""Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)"">1</a>], with extensions for
supporting IPv4 specified in <a href="./rfc1195">RFC 1195</a> [<a href="#ref-3" title=""Use of OSI IS-IS for routing in TCP/IP and dual environments"">3</a>]. Each Intermediate System
(IS) (router) advertises one or more IS-IS Link State Protocol Data
Units (LSPs) with routing information. Each LSP is composed of a
fixed header and a number of tuples, each consisting of a Type, a
Length, and a Value. Such tuples are commonly known as TLVs, and are
a good way of encoding information in a flexible and extensible
format.
This document contains the design of new TLVs to replace the existing
IS Neighbor TLV, IP Reachability TLV, and to include additional
information about the characteristics of a particular link to an IS-
IS LSP. The characteristics described in this document are needed
for Traffic Engineering [<a href="#ref-4" title=""Requirements for Traffic Engineering Over MPLS"">4</a>] (TE). Secondary goals include increasing
the dynamic range of the IS-IS metric and improving the encoding of
IP prefixes.
<span class="grey">Smit & Li Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
The router id is useful for traffic engineering purposes because it
describes a single address that can always be used to reference a
particular router.
Mechanisms and procedures to migrate to the new TLVs are not
discussed in this document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Introducing Sub-TLVs</span>
This document introduces a new way to encode routing information in
IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to
regular TLVs. They use the same concepts as regular TLVs. The
difference is that TLVs exist inside IS-IS packets, while sub-TLVs
exist inside TLVs. TLVs are used to add extra information to IS-IS
packets. Sub-TLVs are used to add extra information to particular
TLVs. Each sub-TLV consists of three fields, a one-octet Type field,
a one-octet Length field, and zero or more octets of Value. The Type
field indicates the type of items in the Value field. The Length
field indicates the length of the Value field in octets. Each sub-
TLV can potentially hold multiple items. The number of items in a
sub-TLV can be computed from the length of the whole sub-TLV, when
the length of each item is known. Unknown sub-TLVs are to be ignored
and skipped upon receipt.
The Sub-TLV type space is managed by the IETF IS-IS WG
(<a href="http://www.ietf.org/html.charters/isis-charter.html">http://www.ietf.org/html.charters/isis-charter.html</a>). New type
values are allocated following review on the IETF IS-IS mailing list.
This will normally require publication of additional documentation
describing how the new type is used. In the event that the IS-IS
working group has disbanded the review shall be performed by a
Designated Expert assigned by the responsible Area Director.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The Extended IS Reachability TLV</span>
The extended IS reachability TLV is TLV type 22.
The existing IS reachability (TLV type 2, defined in ISO 10589 [<a href="#ref-1" title=""Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)"">1</a>])
contains information about a series of IS neighbors. For each
neighbor, there is a structure that contains the default metric, the
delay, the monetary cost, the reliability, and the 7-octet ID of the
adjacent neighbor. Of this information, the default metric is
commonly used. The default metric is currently one octet, with one
bit used to indicate whether the metric is internal or external, and
one bit that was originally unused, but which was later defined by
<a href="./rfc2966">RFC 2966</a> to be the up/down bit. The remaining 6 bits are used to
store the actual metric, resulting in a possible metric range of 0-
63. This limitation is one of the restrictions that we would like to
lift.
<span class="grey">Smit & Li Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
The remaining three metrics (delay, monetary cost, and reliability)
are not commonly implemented and reflect unused overhead in the TLV.
The neighbor is identified by its system ID, typically 6-octets, plus
one octet indicating the pseudonode number. Thus, the existing TLV
consumes 11 octets per neighbor, with 4 octets for metric and 7
octets for neighbor identification. To indicate multiple
adjacencies, this structure is repeated within the IS reachability
TLV. Because the TLV is limited to 255 octets of content, a single
TLV can describe up to 23 neighbors. The IS reachability TLV can be
repeated within the LSP fragments to describe further neighbors.
The proposed extended IS reachability TLV contains a new data
structure, consisting of:
7 octets of system Id and pseudonode number
3 octets of default metric
1 octet of length of sub-TLVs
0-244 octets of sub-TLVs,
where each sub-TLV consists of a sequence of
1 octet of sub-type
1 octet of length of the value field of the sub-TLV
0-242 octets of value
Thus, if no sub-TLVs are used, the new encoding requires 11 octets
and can contain up to 23 neighbors. Please note that while the
encoding allows for 255 octets of sub-TLVs, the maximum value cannot
fit in the overall IS reachability TLV. The practical maximum is 255
octets minus the 11 octets described above, or 244 octets. Further,
there is no defined mechanism for extending the sub-TLV space for a
particular neighbor. Thus, wasting sub-TLV space is discouraged.
The metric octets are encoded as a 24-bit unsigned integer. Note
that the metric field in the new extended IP reachability TLV is
encoded as a 32-bit unsigned integer. These different sizes were
chosen so that it is very unlikely that the cost of an intra-area
route has to be chopped off to fit in the metric field of an inter-
area route.
To preclude overflow within a traffic engineering SPF implementation,
all metrics greater than or equal to MAX_PATH_METRIC SHALL be
considered to have a metric of MAX_PATH_METRIC. It is easiest to
select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link
metric does not overflow the number of bits for internal metric
calculation. We assume that this is 32 bits. Therefore, we have
chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
<span class="grey">Smit & Li Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
If a link is advertised with the maximum link metric (2^24 - 1), this
link MUST NOT be considered during the normal SPF computation. This
will allow advertisement of a link for purposes other than building
the normal Shortest Path Tree. An example is a link that is
available for traffic engineering, but not for hop-by-hop routing.
Certain sub-TLVs are proposed here:
Sub-TLV type Length (octets) Name
3 4 Administrative group (color)
6 4 IPv4 interface address
8 4 IPv4 neighbor address
9 4 Maximum link bandwidth
10 4 Reservable link bandwidth
11 32 Unreserved bandwidth
18 3 TE Default metric
250-254 Reserved for cisco specific extensions
255 Reserved for future expansion
Each of these sub-TLVs is described below. Unless stated otherwise,
multiple occurrences of the information are supported by multiple
inclusions of the sub-TLV.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Sub-TLV 3: Administrative group (color, resource class)</span>
The administrative group sub-TLV contains a 4-octet bit mask assigned
by the network administrator. Each set bit corresponds to one
administrative group assigned to the interface.
By convention, the least significant bit is referred to as 'group 0',
and the most significant bit is referred to as 'group 31'.
This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear once at most in
each extended IS reachability TLV.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Sub-TLV 6: IPv4 interface address</span>
This sub-TLV contains a 4-octet IPv4 address for the interface
described by the (main) TLV. This sub-TLV can occur multiple times.
Implementations MUST NOT inject a /32 prefix for the interface
address into their routing or forwarding table because this can lead
to forwarding loops when interacting with systems that do not support
this sub-TLV.
<span class="grey">Smit & Li Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
If a router implements the basic TLV extensions in this document, it
MAY add or omit this sub-TLV from the description of an adjacency.
If a router implements traffic engineering, it MUST include this
sub-TLV.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Sub-TLV 8: IPv4 neighbor address</span>
This sub-TLV contains a single IPv4 address for a neighboring router
on this link. This sub-TLV can occur multiple times.
Implementations MUST NOT inject a /32 prefix for the neighbor address
into their routing or forwarding table because this can lead to
forwarding loops when interacting with systems that do not support
this sub-TLV.
If a router implements the basic TLV extensions in this document, it
MAY add or omit this sub-TLV from the description of an adjacency.
If a router implements traffic engineering, it MUST include this
sub-TLV on point-to-point adjacencies.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Sub-TLV 9: Maximum link bandwidth</span>
This sub-TLV contains the maximum bandwidth that can be used on this
link in this direction (from the system originating the LSP to its
neighbors). This is useful for traffic engineering.
The maximum link bandwidth is encoded in 32 bits in IEEE floating
point format. The units are bytes (not bits!) per second.
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in
each extended IS reachability TLV.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Sub-TLV 10: Maximum reservable link bandwidth</span>
This sub-TLV contains the maximum amount of bandwidth that can be
reserved in this direction on this link. Note that for
oversubscription purposes, this can be greater than the bandwidth of
the link.
The maximum reservable link bandwidth is encoded in 32 bits in IEEE
floating point format. The units are bytes (not bits!) per second.
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in
each extended IS reachability TLV.
<span class="grey">Smit & Li Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Sub-TLV 11: Unreserved bandwidth</span>
This sub-TLV contains the amount of bandwidth reservable in this
direction on this link. Note that for oversubscription purposes,
this can be greater than the bandwidth of the link.
Because of the need for priority and preemption, each head end needs
to know the amount of reserved bandwidth at each priority level.
Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers.
The units are bytes (not bits!) per second. The values correspond to
the bandwidth that can be reserved with a setup priority of 0 through
7, arranged in increasing order with priority 0 occurring at the
start of the sub-TLV, and priority 7 at the end of the sub-TLV.
For stability reasons, rapid changes in the values in this sub-TLV
SHOULD NOT cause rapid generation of LSPs.
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in
each extended IS reachability TLV.
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Sub-TLV 18: Traffic Engineering Default Metric</span>
This sub-TLV contains a 24-bit unsigned integer. This metric is
administratively assigned and can be used to present a differently
weighted topology to traffic engineering SPF calculations.
To preclude overflow within a traffic engineering SPF implementation,
all metrics greater than or equal to MAX_PATH_METRIC SHALL be
considered to have a metric of MAX_PATH_METRIC. It is easiest to
select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link
metric does not overflow the number of bits for internal metric
calculation. We assume that this is 32 bits. Therefore, we have
chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25).
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in
each extended IS reachability TLV. If a link is advertised without
this sub-TLV, traffic engineering SPF calculations MUST use the
normal default metric of this link, which is advertised in the fixed
part of the extended IS reachability TLV.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. The Extended IP Reachability TLV</span>
The extended IP reachability TLV is TLV type 135.
The existing IP reachability TLVs (TLV type 128 and TLV type 130,
defined in <a href="./rfc1195">RFC 1195</a> [<a href="#ref-3" title=""Use of OSI IS-IS for routing in TCP/IP and dual environments"">3</a>]) carry IP prefixes in a format that is
analogous to the IS neighbor TLV from ISO 10589 [<a href="#ref-1" title=""Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)"">1</a>]. They carry four
metrics, of which only the default metric is commonly used. The
<span class="grey">Smit & Li Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
default metric has a possible range of 0-63. We would like to remove
this restriction.
In addition, route redistribution (a.k.a. route leaking) has a key
problem that was not fully addressed by the existing IP reachability
TLVs. <a href="./rfc1195">RFC 1195</a> [<a href="#ref-3" title=""Use of OSI IS-IS for routing in TCP/IP and dual environments"">3</a>] allows a router to advertise prefixes upwards in
the level hierarchy. Unfortunately there were no mechanisms defined
to advertise prefixes downwards in the level hierarchy.
To address these two issues, the proposed extended IP reachability
TLV provides for a 32 bit metric and adds one bit to indicate that a
prefix has been redistributed 'down' in the hierarchy.
The proposed extended IP reachability TLV contains a new data
structure, consisting of:
4 octets of metric information
1 octet of control information, consisting of
1 bit of up/down information
1 bit indicating the presence of sub-TLVs
6 bits of prefix length
0-4 octet of IPv4 prefix
0-250 optional octets of sub-TLVs, if present consisting of
1 octet of length of sub-TLVs
0-249 octets of sub-TLVs,
where each sub-TLV consists of a sequence of
1 octet of sub-type
1 octet of length of the value field of the sub-TLV
0-247 octets of value
This data structure can be replicated within the TLV, without
exceeding the maximum length of the TLV.
The 6 bits of prefix length can have the values 0-32 and indicate the
number of significant bits in the prefix. The prefix is encoded in
the minimal number of octets for the given number of significant
bits. This implies:
Significant bits Octets
0 0
1-8 1
9-16 2
17-24 3
25-32 4
The remaining bits of prefix are transmitted as zero and ignored upon
receipt.
<span class="grey">Smit & Li Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
If a prefix is advertised with a metric larger then MAX_PATH_METRIC
(0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered
during the normal SPF computation. This allows advertisement of a
prefix for purposes other than building the normal IP routing table.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. The up/down Bit</span>
If routers were allowed to redistribute IP prefixes freely in both
directions between level 1 and level 2 without any additional
mechanisms, those routers would not be able to determine looping of
routing information. A problem occurs when a router learns a prefix
via level 2 routing and advertises that prefix down into a level 1
area, where another router might pick up the route and advertise the
prefix back up into the level 2 backbone. If the original source
withdraws the prefix, those two routers might end up having a routing
loop between them, where part of the looped path is via level 1
routing and the other part of the looped path is via level 2 routing.
The solution that <a href="./rfc1195">RFC 1195</a> [<a href="#ref-3" title=""Use of OSI IS-IS for routing in TCP/IP and dual environments"">3</a>] poses is to allow only advertising
prefixes upward in the level hierarchy, and to disallow the
advertising of prefixes downward in the hierarchy.
To prevent this looping of prefixes between levels, a new bit of
information is defined in the new extended IP reachability TLV. This
bit is called the up/down bit. The up/down bit SHALL be set to 0
when a prefix is first injected into IS-IS. If a prefix is
advertised from a higher level to a lower level (e.g. level 2 to
level 1), the bit MUST be set to 1, indicating that the prefix has
traveled down the hierarchy. Prefixes that have the up/down bit set
to 1 may only be advertised down the hierarchy, i.e. to lower levels.
These semantics apply even if IS-IS is extended in the future to have
additional levels. By insuring that prefixes follow only the IS-IS
hierarchy, we have insured that the information does not loop,
thereby insuring that there are no persistent forwarding loops.
If a prefix is advertised from one area to another at the same level,
then the up/down bit SHALL be set to 1. This situation can arise
when a router implements multiple virtual routers at the same level,
but in different areas.
The semantics of the up/down bit in the new extended IP reachability
TLV are identical to the semantics of the up/down bit defined in <a href="./rfc2966">RFC</a>
<a href="./rfc2966">2966</a> [<a href="#ref-2" title=""Domain-wide Prefix Distribution with Two-Level IS-IS"">2</a>].
<span class="grey">Smit & Li Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Expandability of the Extended IP Reachability TLV with Sub-TLVs</span>
The extended IP reachability TLV can hold sub-TLVs that apply to a
particular prefix. This allows for easy future extensions. If there
are no sub-TLVs associated with a prefix, the bit indicating the
presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the
first octet after the prefix will be interpreted as the length of all
sub-TLVs associated with this IPv4 prefix. Please note that while
the encoding allows for 255 octets of sub-TLVs, the maximum value
cannot fit in the overall extended IP reachability TLV. The
practical maximum is 255 octets minus the 5-9 octets described above,
or 250 octets.
This document does not define any sub-TLVs for the extended IP
reachability TLV.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. The Traffic Engineering Router ID TLV</span>
The Traffic Engineering router ID TLV is TLV type 134.
The router ID TLV contains the 4-octet router ID of the router
originating the LSP. This is useful in several regards:
For traffic engineering, it guarantees that we have a single stable
address that can always be referenced in a path that will be
reachable from multiple hops away, regardless of the state of the
node's interfaces.
If OSPF is also active in the domain, traffic engineering can compute
the mapping between the OSPF and IS-IS topologies.
If a router does not implement traffic engineering, it MAY add or
omit the Traffic Engineering router ID TLV. If a router implements
traffic engineering, it MUST include this TLV in its LSP. This TLV
SHOULD not be included more than once in an LSP.
If a router advertises the Traffic Engineering router ID TLV in its
LSP, and if it advertises prefixes via the Border Gateway Protocol
(BGP) with the BGP next hop attribute set to the BGP router ID, the
Traffic Engineering router ID SHOULD be the same as the BGP router
ID.
Implementations MUST NOT inject a /32 prefix for the router ID into
their forwarding table because this can lead to forwarding loops when
interacting with systems that do not support this TLV.
<span class="grey">Smit & Li Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. TLV Codepoint Allocations</span>
This document defines the following new IS-IS TLV types, which have
been reflected in the ISIS TLV code-point registry:
Type Description IIH LSP SNP
---- ----------------------------------- --- --- ---
22 The extended IS reachability TLV n y n
134 The Traffic Engineering router ID TLV n y n
135 The extended IP reachability TLV n y n
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. New Registries</span>
IANA has created the following new registries.
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Sub-TLVs for the Extended IS Reachability TLV</span>
This registry contains codepoints for Sub-TLVs of TLV 22. The range
of values is 0-255. Allocations within the registry require
documentation of the proposed use of the allocated value and approval
by the Designated Expert assigned by the IESG (see [<a href="#ref-5" title="">5</a>]).
Taking into consideration allocations specified in this document, the
registry has been initialized as follows:
Type Description
---- -----------------------------------
0-2 unassigned
3 Administrative group (color)
4-5 unassigned
6 IPv4 interface address
7 unassigned
8 IPv4 neighbor address
9 Maximum link bandwidth
10 Reservable link bandwidth
11 Unreserved bandwidth
12-17 unassigned
18 TE Default metric
19-254 unassigned
255 Reserved for future expansion
<span class="grey">Smit & Li Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>. Sub-TLVs for the Extended IP Reachability TLV</span>
This registry contains codepoints for Sub-TLVs of TLV 135. The range
of values is 0-255. Allocations within the registry require
documentation of the use of the allocated value and approval by the
Designated Expert assigned by the IESG (see [<a href="#ref-5" title="">5</a>]).
No codepoints are defined in this document.
<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-1">1</a>] ISO, "Intermediate System to Intermediate System Intra-Domain
Routeing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode Network Service
(ISO 8473)", International Standard 10589:2002, Second Edition
[<a id="ref-2">2</a>] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix
Distribution with Two-Level IS-IS", <a href="./rfc2966">RFC 2966</a>, October 2000.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-3">3</a>] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", <a href="./rfc1195">RFC 1195</a>, December 1990
[<a id="ref-4">4</a>] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus,
"Requirements for Traffic Engineering Over MPLS", <a href="./rfc2702">RFC 2702</a>,
September 1999.
[<a id="ref-5">5</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>, October 1998.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
This document raises no new security issues for IS-IS.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgments</span>
The authors would like to thank Yakov Rekhter and Dave Katz for their
comments on this work.
<span class="grey">Smit & Li Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Authors' Addresses</span>
Henk Smit
EMail: hhwsmit@xs4all.nl
Tony Li
EMail: tony.li@tony.li
<span class="grey">Smit & Li Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3784">RFC 3784</a> IS-IS extensions for Traffic Engineering June 2004</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2004). 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.
Smit & Li Informational [Page 13]
</pre>
|
