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
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
|
<pre>Network Working Group K. Shiomoto
Request for Comments: 4990 NTT
Category: Informational R. Papneja
Isocore
R. Rabbat
Google
September 2007
<span class="h1">Use of Addresses</span>
<span class="h1">in Generalized Multiprotocol Label Switching (GMPLS) Networks</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.
Abstract
This document clarifies the use of addresses in Generalized
Multiprotocol Label Switching (GMPLS) networks. The aim is to
facilitate interworking of GMPLS-capable Label Switching Routers
(LSRs). The document is based on experience gained in
implementation, interoperability testing, and deployment.
The document describes how to interpret address and identifier fields
within GMPLS protocols, and how to choose which addresses to set in
those fields for specific control plane usage models. It also
discusses how to handle IPv6 sources and destinations in the MPLS and
GMPLS Traffic Engineering (TE) Management Information Base (MIB)
modules.
This document does not define new procedures or processes. Whenever
this document makes requirements statements or recommendations, these
are taken from normative text in the referenced RFCs.
<span class="grey">Shiomoto, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Support of Numbered and Unnumbered Links ........................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Numbered Addressing .............................................<a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Numbered Addresses in IGPs .................................<a href="#page-6">6</a>
<a href="#section-4.1.1">4.1.1</a>. Router Address and TE Router ID .....................<a href="#page-6">6</a>
<a href="#section-4.1.2">4.1.2</a>. Link ID and Remote Router ID ........................<a href="#page-6">6</a>
<a href="#section-4.1.3">4.1.3</a>. Local Interface IP Address ..........................<a href="#page-7">7</a>
<a href="#section-4.1.4">4.1.4</a>. Remote Interface IP Address .........................<a href="#page-7">7</a>
<a href="#section-4.2">4.2</a>. Numbered Addresses in RSVP-TE ..............................<a href="#page-7">7</a>
<a href="#section-4.2.1">4.2.1</a>. IP Tunnel End Point Address in Session Object .......<a href="#page-7">7</a>
<a href="#section-4.2.2">4.2.2</a>. IP Tunnel Sender Address in Sender Template Object ..8
<a href="#section-4.2.3">4.2.3</a>. IF_ID RSVP_HOP Object for Numbered Interfaces .......<a href="#page-8">8</a>
<a href="#section-4.2.4">4.2.4</a>. Explicit Route Object (ERO) .........................<a href="#page-9">9</a>
<a href="#section-4.2.5">4.2.5</a>. Record Route Object (RRO) ...........................<a href="#page-9">9</a>
<a href="#section-4.2.6">4.2.6</a>. IP Packet Source Address ............................<a href="#page-9">9</a>
<a href="#section-4.2.7">4.2.7</a>. IP Packet Destination Address .......................<a href="#page-9">9</a>
<a href="#section-5">5</a>. Unnumbered Addressing ..........................................<a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. Unnumbered Addresses in IGPs ..............................<a href="#page-10">10</a>
<a href="#section-5.1.1">5.1.1</a>. Link Local/Remote Identifiers in OSPF-TE ...........<a href="#page-10">10</a>
<a href="#section-5.1.2">5.1.2</a>. Link Local/Remote Identifiers in IS-IS-TE ..........<a href="#page-11">11</a>
<a href="#section-5.2">5.2</a>. Unnumbered Addresses in RSVP-TE ...........................<a href="#page-11">11</a>
<a href="#section-5.2.1">5.2.1</a>. Sender and End Point Addresses .....................<a href="#page-11">11</a>
<a href="#section-5.2.2">5.2.2</a>. IF_ID RSVP_HOP Object for Unnumbered Interfaces ....<a href="#page-11">11</a>
<a href="#section-5.2.3">5.2.3</a>. Explicit Route Object (ERO) ........................<a href="#page-11">11</a>
<a href="#section-5.2.4">5.2.4</a>. Record Route Object (RRO) ..........................<a href="#page-11">11</a>
<a href="#section-5.2.5">5.2.5</a>. LSP_Tunnel Interface ID Object .....................<a href="#page-12">12</a>
<a href="#section-5.2.6">5.2.6</a>. IP Packet Addresses ................................<a href="#page-12">12</a>
<a href="#section-6">6</a>. RSVP-TE Message Content ........................................<a href="#page-12">12</a>
<a href="#section-6.1">6.1</a>. ERO and RRO Addresses .....................................<a href="#page-12">12</a>
<a href="#section-6.1.1">6.1.1</a>. Strict Subobject in ERO ............................<a href="#page-12">12</a>
<a href="#section-6.1.2">6.1.2</a>. Loose Subobject in ERO .............................<a href="#page-14">14</a>
<a href="#section-6.1.3">6.1.3</a>. RRO ................................................<a href="#page-14">14</a>
<a href="#section-6.1.4">6.1.4</a>. Label Record Subobject in RRO ......................<a href="#page-15">15</a>
<a href="#section-6.2">6.2</a>. Component Link Identification .............................<a href="#page-15">15</a>
<a href="#section-6.3">6.3</a>. Forwarding Destination of Path Messages with ERO ..........<a href="#page-16">16</a>
<a href="#section-7">7</a>. Topics Related to the GMPLS Control Plane ......................<a href="#page-16">16</a>
<a href="#section-7.1">7.1</a>. Control Channel Separation ................................<a href="#page-16">16</a>
<a href="#section-7.1.1">7.1.1</a>. Native and Tunneled Control Plane ..................<a href="#page-16">16</a>
<a href="#section-7.2">7.2</a>. Separation of Control and Data Plane Traffic ..............<a href="#page-17">17</a>
<a href="#section-8">8</a>. Addresses in the MPLS and GMPLS TE MIB Modules .................<a href="#page-17">17</a>
<a href="#section-8.1">8.1</a>. Handling IPv6 Source and Destination Addresses ............<a href="#page-18">18</a>
<a href="#section-8.1.1">8.1.1</a>. Identifying LSRs ...................................<a href="#page-18">18</a>
<a href="#section-8.1.2">8.1.2</a>. Configuring GMPLS Tunnels ..........................<a href="#page-18">18</a>
<a href="#section-8.2">8.2</a>. Managing and Monitoring Tunnel Table Entries ..............<a href="#page-19">19</a>
<a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-19">19</a>
<span class="grey">Shiomoto, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
<a href="#section-10">10</a>. Acknowledgments ...............................................<a href="#page-20">20</a>
<a href="#section-11">11</a>. References ....................................................<a href="#page-20">20</a>
<a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-20">20</a>
<a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-21">21</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This informational document clarifies the use of addresses in
Generalized Multiprotocol Label Switching (GMPLS) [<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>] networks.
The aim is to facilitate interworking of GMPLS-capable Label
Switching Routers (LSRs). The document is based on experience gained
in implementation, interoperability testing, and deployment.
The document describes how to interpret address and identifier fields
within GMPLS protocols (RSVP-TE [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>], GMPLS OSPF [<a href="./rfc4203" title=""OSPF Extensions in Support of Generalized Multi-protocol Label Switching"">RFC4203</a>], and
GMPLS ISIS [<a href="./rfc4205" title=""Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4205</a>]), and how to choose which addresses to set in
those fields for specific control plane usage models.
This document does not define new procedures or processes and the
protocol specifications listed above should be treated as definitive.
Furthermore, where this document makes requirements statements or
recommendations, these are taken from normative text in the
referenced RFCs. Nothing in this document should be considered
normative.
This document also discusses how to handle IPv6 sources and
destinations in the MPLS and GMPLS Traffic Engineering (TE)
Management Information Base (MIB) modules [<a href="./rfc3812" title=""Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)"">RFC3812</a>], [<a href="./rfc4802" title=""Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base"">RFC4802</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
As described in [<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>], the components of a GMPLS network may be
separated into a data plane and a control plane. The control plane
may be further split into signaling components and routing
components.
A data plane switch or router is called a data plane entity. It is a
node on the data plane topology graph. A data plane resource is a
facility available in the data plane, such as a data plane entity
(node), data link (edge), or data label (such as a lambda).
In the control plane, there are protocol speakers that are software
implementations that communicate using signaling or routing
protocols. These are control plane entities, and may be physically
located separately from the data plane entities that they control.
Further, there may be separate routing entities and signaling
entities.
<span class="grey">Shiomoto, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
GMPLS supports a control plane entity that is responsible for one or
more data plane entities, and supports the separation of signaling
and routing control plane entities. For the purposes of this
document, it is assumed that there is a one-to-one correspondence
between control plane and data plane entities. That is, each data
plane switch has a unique control plane entity responsible for
participating in the GMPLS signaling and routing protocols, and that
each such control plane presence is responsible for a single data
plane switch.
The combination of control plane and data plane entities is referred
to as a Label Switching Router (LSR).
Note that the term 'Router ID' is used in two contexts within GMPLS.
It may refer to an identifier of a participant in a routing protocol,
or it may be an identifier for an LSR that participates in TE
routing. These could be considered as the control plane and data
plane contexts.
In this document, the contexts are distinguished by the following
definitions.
o Loopback address: A loopback address is a stable IP address of the
advertising router that is always reachable if there is any IP
connectivity to it [<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>], [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>]. Thus, for example, an
IPv4 127/24 address is excluded from this definition.
o TE Router ID: A stable IP address of an LSR that is always
reachable in the control plane if there is any IP connectivity to
the LSR, e.g., a loopback address. The most important requirement
is that the address does not become unusable if an interface on
the LSR is down [<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>], [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>].
o Router ID: The OSPF protocol version 2 [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>] defines the
Router ID to be a 32-bit network-unique number assigned to each
router running OSPF. IS-IS [<a href="./rfc1195" title=""Use of OSI IS-IS for routing in TCP/IP and dual environments"">RFC1195</a>] includes a similar concept
in the System ID. This document describes both concepts as the
"Router ID" of the router running the routing protocol. The
Router ID is not required to be a reachable IP address, although
an operator may set it to a reachable IP address on the same node.
o TE link: "A TE link is a representation in the IS-IS/OSPF Link
State advertisements and in the link state database of certain
physical resources, and their properties, between two GMPLS nodes"
[<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>].
o Data plane node: A vertex on the TE graph. It is a data plane
switch or router. Data plane nodes are connected by TE links that
<span class="grey">Shiomoto, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
are constructed from physical data links. A data plane node is
controlled through some combination of management and control
plane actions. A data plane node may be under full or partial
control of a control plane node.
o Control plane node: A GMPLS protocol speaker. It may be part of a
data plane switch or may be a separate computer. Control plane
nodes are connected by control channels that are logical
connection-less or connection-oriented paths in the control plane.
A control plane node is responsible for controlling zero, one, or
more data plane nodes.
o Interface ID: The Interface ID is defined in [<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>] and in
<a href="./rfc3471#section-9.1">Section 9.1 of [RFC3471]</a>.
o Data Plane Address: This document refers to a data plane address
in the context of GMPLS. It does not refer to addresses such as
E.164 SAPI in Synchronous Digital Hierarchy (SDH).
o Control Plane Address: An address used to identify a control plane
resource including, and restricted to, control plane nodes and
control channels.
o IP Time to Live (TTL): The IPv4 TTL field or the IPv6 Hop Limit
field, whichever is applicable.
o TED: Traffic Engineering Database.
o LSR: Label Switching Router.
o FA: Forwarding Adjacency.
o IGP: Interior Gateway Protocol.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Support of Numbered and Unnumbered Links</span>
The links in the control and data planes may be numbered or
unnumbered [<a href="./rfc3945" title=""Generalized Multi-Protocol Label Switching (GMPLS) Architecture"">RFC3945</a>]. That is, their end points may be assigned IP
addresses, or may be assigned link IDs specific to the control plane
or data plane entity at the end of the link. Implementations may
decide to support numbered and/or unnumbered addressing.
The argument for numbered addressing is that it simplifies
troubleshooting. The argument for unnumbered addressing is to save
on IP address resources.
An LSR may choose to only support its own links being configured as
numbered, or may only support its own links being configured as
<span class="grey">Shiomoto, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
unnumbered. But an LSR must not restrict the choice of other LSRs to
use numbered or unnumbered links since this might lead to
interoperablity issues. Thus, a node should be able to accept and
process link advertisements containing both numbered and unnumbered
addresses.
Numbered and unnumbered addressing is described in Sections <a href="#section-4">4</a> and <a href="#section-5">5</a>
of this document, respectively.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Numbered Addressing</span>
When numbered addressing is used, addresses are assigned to each node
and link in both the control and data planes of the GMPLS network.
A numbered link is identified by a network-unique identifier (e.g.,
an IP address).
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Numbered Addresses in IGPs</span>
In this section, we discuss numbered addressing using two Interior
Gateway Protocols (IGPs) that have extensions defined for GMPLS:
OSPF-TE and IS-IS-TE. The routing enhancements for GMPLS are defined
in [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>], [<a href="./rfc3784" title=""Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)"">RFC3784</a>], [<a href="./rfc4202" title=""Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4202</a>], [<a href="./rfc4203" title=""OSPF Extensions in Support of Generalized Multi-protocol Label Switching"">RFC4203</a>], and [<a href="./rfc4205" title=""Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4205</a>].
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Router Address and TE Router ID</span>
The IGPs define a field called the "Router Address". It is used to
advertise the TE Router ID.
The Router Address is advertised in OSPF-TE using the Router Address
TLV structure of the TE Link State Advertisement (LSA) [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>].
In IS-IS-TE, this is referred to as the Traffic Engineering router
ID, and is carried in the advertised Traffic Engineering router ID
TLV [<a href="./rfc3784" title=""Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)"">RFC3784</a>].
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Link ID and Remote Router ID</span>
In OSPF-TE [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>], the Router ID of the remote end of a TE link is
carried in the Link ID sub-TLV. This applies for point-to-point TE
links only; multi-access links are for further study.
In IS-IS-TE [<a href="./rfc3784" title=""Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)"">RFC3784</a>], the Extended IS Reachability TLV is used to
carry the System ID. This corresponds to the Router ID as described
in <a href="#section-2">Section 2</a>.
<span class="grey">Shiomoto, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. Local Interface IP Address</span>
The Local Interface IP Address is advertised in:
o the Local Interface IP Address sub-TLV in OSPF-TE [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>]
o the IPv4 Interface Address sub-TLV in IS-IS-TE [<a href="./rfc3784" title=""Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)"">RFC3784</a>].
This is the ID of the local end of the numbered TE link. It must be
a network-unique number (since this section is devoted to numbered
addressing), but it does not need to be a routable address in the
control plane.
<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>. Remote Interface IP Address</span>
The Remote Interface IP Address is advertised in:
o the Remote Interface IP Address sub-TLV in OSPF-TE [<a href="./rfc3630" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">RFC3630</a>]
o the IPv4 Neighbor Address sub-TLV in IS-IS-TE [<a href="./rfc3784" title=""Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)"">RFC3784</a>].
This is the ID of the remote end of the numbered TE link. It must be
a network-unique number (since this section is devoted to numbered
addressing), but it does not need to be a routable address in the
control plane
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Numbered Addresses in RSVP-TE</span>
The following subsections describe the use of addresses in the GMPLS
signaling protocol [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>].
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. IP Tunnel End Point Address in Session Object</span>
The IP tunnel end point address of the Session Object [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>] is
either an IPv4 or IPv6 address.
The Session Object is invariant for all messages relating to the same
Label Switched Path (LSP). The initiator of a Path message sets the
IP tunnel end point address in the Session Object to one of:
o The TE Router ID of the egress since the TE Router ID is routable
and uniquely identifies the egress node.
o The destination data plane address to precisely identify the
interface that should be used for the final hop of the LSP. That
is, the Remote Interface IP Address of the final TE link, if the
ingress knows that address.
<span class="grey">Shiomoto, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
The IP tunnel end point address in the Session Object is not required
to be routable in the control plane, but should be present in the
TED.
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. IP Tunnel Sender Address in Sender Template Object</span>
The IP tunnel sender address of the Sender Template Object [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]
is either an IPv4 or IPv6 address.
When an LSP is being set up to support an IPv4-numbered FA, [<a href="./rfc4206" title=""LSP Hierarchy with Generalized MPLS TE"">RFC4206</a>]
recommends that the IP tunnel sender address be set to the head-end
address of the TE link that is to be created so that the tail-end
address can be inferred as the /31 partner address.
When an LSP is being set up that will not be used to form an FA, the
IP tunnel sender address in the Sender Template Object may be set to
one of:
o The TE Router ID of the ingress LSR since the TE Router ID is a
unique, routable ID per node.
o The sender data plane address (i.e., the Local Interface IP
Address).
<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>. IF_ID RSVP_HOP Object for Numbered Interfaces</span>
There are two addresses used in the IF_ID RSVP_HOP object.
1. The IPv4/IPv6 Next/Previous Hop Address [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>]
When used in a Path or Resv messages, this address specifies the
IP reachable address of the control plane interface used to send
the messages, or the TE Router ID of the node that sends the
message. That is, it is a routable control plane address of the
sender of the message and can be used to send return messages.
Note that because of data plane / control plane separation (see
<a href="#section-7.1">Section 7.1</a>) and data plane robustness in the face of control
plane faults, it may be advisable to use the TE Router ID since it
is a more stable address.
2. The IPv4/IPv6 address in the Value Field of the Interface_ID TLV
[<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>]
This address identifies the data channel associated with the
signaling message. In all cases, the data channel is indicated by
the use of the data plane local interface address at the upstream
LSR, that is, at the sender of the Path message.
<span class="grey">Shiomoto, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
See <a href="#section-6.2">Section 6.2</a> for a description of these fields when bundled links
are used.
<span class="h4"><a class="selflink" id="section-4.2.4" href="#section-4.2.4">4.2.4</a>. Explicit Route Object (ERO)</span>
The IPv4/IPv6 address in the ERO provides a data-plane identifier of
an abstract node, TE node, or TE link to be part of the signaled LSP.
See <a href="#section-6">Section 6</a> for a description of the use of addresses in the ERO.
<span class="h4"><a class="selflink" id="section-4.2.5" href="#section-4.2.5">4.2.5</a>. Record Route Object (RRO)</span>
The IPv4/IPv6 address in the RRO provides a data-plane identifier of
either a TE node or a TE link that is part of an LSP that has been
established or is being established.
See <a href="#section-6">Section 6</a> for a description of the use of addresses in the RRO.
<span class="h4"><a class="selflink" id="section-4.2.6" href="#section-4.2.6">4.2.6</a>. IP Packet Source Address</span>
GMPLS signaling messages are encapsulated in IP. The IP packet
source address is either an IPv4 or IPv6 address and must be a
reachable control plane address of the node sending the TE message.
In order to provide control plane robustness, a stable IPv4 or IPv6
control plane address (for example, the TE Router ID) can be used.
Some implementations may use the IP source address of a received IP
packet containing a Path message as the destination IP address of a
packet containing the corresponding Resv message (see <a href="#section-4.2.7">Section 4.2.7</a>).
Using a stable IPv4 or IPv6 address in the IP packet containing the
Path message supports this situation robustly when one of the control
plane interfaces is down.
<span class="h4"><a class="selflink" id="section-4.2.7" href="#section-4.2.7">4.2.7</a>. IP Packet Destination Address</span>
The IP packet destination address for an IP packet carrying a GMPLS
signaling message is either an IPv4 or IPv6 address, and must be
reachable in the control plane if the message is to be delivered. It
must be an address of the intended next-hop recipient of the message.
That is, unlike RSVP, the IP packet is not addressed to the ultimate
destination (the egress).
For a Path message, a stable IPv4 or IPv6 address of the next-hop
node may be used. This may be the TE Router ID of the next-hop node.
A suitable address may be determined by examining the TE
advertisements for the TE link that will form the next-hop data link.
<span class="grey">Shiomoto, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
A Resv message is sent to the previous-hop node. The IPv4 or IPv6
destination of an IP packet carrying a Resv message may be any of the
following:
o The IPv4 or IPv6 source address of the received IP packet
containing the Path message.
o A stable IPv4 or IPv6 address of the previous node found by
examining the TE advertisements for the upstream data plane
interface.
o The value in the received in the Next/Previous Hop Address field
of the RSVP_HOP (PHOP) Object [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Unnumbered Addressing</span>
An unnumbered address is the combination of a network-unique node
identifier and a node-unique interface identifier.
An unnumbered link is identified by the combination of the TE Router
ID that is a reachable address in the control plane and a node-unique
Interface ID [<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>].
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Unnumbered Addresses in IGPs</span>
In this section, we consider unnumbered address advertisement using
OSPF-TE and IS-IS-TE.
<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>. Link Local/Remote Identifiers in OSPF-TE</span>
Link Local and Link Remote Identifiers are carried in OSPF using a
single sub-TLV of the Link TLV [<a href="./rfc4203" title=""OSPF Extensions in Support of Generalized Multi-protocol Label Switching"">RFC4203</a>]. They advertise the IDs of
an unnumbered TE link's local and remote ends, respectively. Link
Local/Remote Identifiers are numbers unique within the scopes of the
advertising LSR and the LSR managing the remote end of the link
respectively [<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>].
Note that these numbers are not network-unique and therefore cannot
be used as TE link end identifiers on their own. An unnumbered TE
link end network-wide identifier is comprised of two elements as
defined in [<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>]:
- A TE Router ID that is associated with the link local end
- The link local identifier.
<span class="grey">Shiomoto, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>. Link Local/Remote Identifiers in IS-IS-TE</span>
The Link Local and Link Remote Identifiers are carried in IS-IS using
a single sub-TLV of the Extended IS Reachability TLV. Link
identifiers are exchanged in the Extended Local Circuit ID field of
the "Point-to-Point Three-Way Adjacency" IS-IS Option type [<a href="./rfc4205" title=""Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"">RFC4205</a>].
The same discussion of unique identification applies here as in
<a href="#section-5.1.1">Section 5.1.1</a>.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Unnumbered Addresses in RSVP-TE</span>
We consider in this section the interface ID fields of objects used
in RSVP-TE in the case of unnumbered addressing.
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. Sender and End Point Addresses</span>
The IP Tunnel End Point Address in the RSVP Session Object and the IP
Tunnel Sender Address in the RSVP Sender Template Object cannot use
unnumbered addresses [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>].
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. IF_ID RSVP_HOP Object for Unnumbered Interfaces</span>
The interface ID field in the IF_INDEX TLV specifies the interface of
the data channel for an unnumbered interface.
In both Path and Resv messages, the value of the interface ID in the
IF_INDEX TLV specifies the local interface ID of the associated data
channel at the upstream node (the node sending the Path message and
receiving the Resv message).
See <a href="#section-6.2">Section 6.2</a> for a description of the use bundled links.
<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>. Explicit Route Object (ERO)</span>
The ERO may use an unnumbered identifier of a TE link to be part of
the signaled LSP.
See <a href="#section-6">Section 6</a> for a description of the use of addresses in the ERO.
<span class="h4"><a class="selflink" id="section-5.2.4" href="#section-5.2.4">5.2.4</a>. Record Route Object (RRO)</span>
The RRO records the data-plane identifiers of TE nodes and TE links
that are part of an LSP that has been established or is being
established. TE links may be identified using unnumbered addressing.
See <a href="#section-6">Section 6</a> for a description of the use of addresses in the RRO.
<span class="grey">Shiomoto, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
<span class="h4"><a class="selflink" id="section-5.2.5" href="#section-5.2.5">5.2.5</a>. LSP_Tunnel Interface ID Object</span>
The LSP_TUNNEL_INTERFACE_ID Object includes the LSR's Router ID and
Interface ID, as described in [<a href="./rfc3477" title=""Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"">RFC3477</a>], to specify an unnumbered
Forward Adjacency Interface ID. The Router ID of the GMPLS-capable
LSR must be set to the TE Router ID.
<span class="h4"><a class="selflink" id="section-5.2.6" href="#section-5.2.6">5.2.6</a>. IP Packet Addresses</span>
IP packets can only be addressed to numbered addresses.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. RSVP-TE Message Content</span>
This section examines the use of addresses in RSVP EROs and RROs, the
identification of component links, and forwarding addresses for RSVP
messages.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. ERO and RRO Addresses</span>
EROs may contain strict or loose hop subobjects. These are discussed
separately below. A separate section describes the use of addresses
in the RRO.
Implementations making limited assumptions about the content of an
ERO or RRO when processing a received RSVP message may cause or
experience interoperability issues. Therefore, implementations that
want to ensure full interoperability need to support the receipt for
processing of all ERO and RRO options applicable to their hardware
capabilities.
Note that the phrase "receipt for processing" is intended to indicate
that an LSR is not expected to look ahead in an ERO or process any
subobjects that do not refer to the LSR itself or to the next hop in
the ERO. An LSR is not generally expected to process an RRO except
by adding its own information.
Note also that implementations do not need to support the ERO options
containing Component Link IDs if they do not support link bundling
[<a href="./rfc4201" title=""Link Bundling in MPLS Traffic Engineering (TE)"">RFC4201</a>].
ERO processing at region boundaries is described in [<a href="./rfc4206" title=""LSP Hierarchy with Generalized MPLS TE"">RFC4206</a>].
<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>. Strict Subobject in ERO</span>
Depending on the level of control required, a subobject in the ERO
includes an address that may specify an abstract node (i.e., a group
of nodes), a simple abstract node (i.e., a specific node), or a
specific interface of a TE link in the data plane [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>].
<span class="grey">Shiomoto, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
A hop may be flagged as strict (meaning that the LSP must go directly
to the identified next hop without any intervening nodes), or loose.
If a hop is strict, the ERO may contain any of the following.
1. Address prefix or AS number specifying a group of nodes.
2. TE Router ID identifying a specific node.
3. Link ID identifying an incoming TE link.
4. Link ID identifying an outgoing TE link, optionally followed by a
Component Interface ID and/or one or two Labels.
5. Link ID identifying an incoming TE link, followed by a Link ID
identifying an outgoing TE link, optionally followed by a
Component Interface ID and/or one or two Labels.
6. TE Router ID identifying a specific node, followed by a Link ID
identifying an outgoing TE link, optionally followed by a
Component Interface ID and/or one or two Labels.
7. Link ID identifying an incoming TE link, followed by a TE Router
ID identifying a specific node, followed by a Link ID identifying
an outgoing TE link, optionally followed by Component Interface ID
and/or one or two Labels.
The label value that identifies a single unidirectional resource
between two nodes may be different from the perspective of upstream
and downstream nodes. This is typically the case in fiber switching
because the label value is a number indicating the port/fiber. It
may also be the case for lambda switching, because the label value is
an index for the lambda in the hardware and may not be a globally
defined value such as the wavelength in nanometers.
The value of a label in any RSVP-TE object indicates the value from
the perspective of the sender of the object/TLV [<a href="./rfc3471" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"">RFC3471</a>].
Therefore, any label in an ERO is given using the upstream node's
identification of the resource.
<span class="grey">Shiomoto, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>. Loose Subobject in ERO</span>
There are two differences between Loose and Strict subobjects.
o A subobject marked as a loose hop in an ERO must not be followed
by a subobject indicating a label value [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>].
o A subobject marked as a loose hop in an ERO should never include
an identifier (i.e., address or ID) of the outgoing interface.
There is no way to specify in an ERO whether a subobject identifies
an incoming or outgoing TE link. Path computation must be performed
by an LSR when it encounters a loose hop in order to resolve the LSP
route to the identified next hop. If an interface is specified as a
loose hop and is treated as an incoming interface, the path
computation will select a path that enters an LSR through that
interface. If the interface was intended to be used as an outgoing
interface, the computed path may be unsatisfactory and the explicit
route in the ERO may be impossible to resolve. Thus a loose hop that
identifies an interface should always identify the incoming TE link
in the data plane.
<span class="h4"><a class="selflink" id="section-6.1.3" href="#section-6.1.3">6.1.3</a>. RRO</span>
The RRO is used on Path and Resv messages to record the path of an
LSP. Each LSR adds subobjects to the RRO to record information. The
information added to an RRO by a node should be the same in the Path
and the Resv message although there may be some information that is
not available during LSP setup.
One use of the RRO is to allow the operator to view the path of the
LSP. At any transit node, it should be possible to construct the
path of the LSP by joining together the RRO from the Path and the
Resv messages.
It is also important that a whole RRO on a Resv message received at
an ingress LSR can be used as an ERO on a subsequent Path message to
completely recreate the LSP.
Therefore, when a node adds one or more subobjects to an RRO, any of
the following options is valid.
1. TE Router ID identifying the LSR.
2. Link ID identifying the incoming (upstream) TE link.
3. Link ID identifying the outgoing (downstream) TE link, optionally
followed by a Component Interface ID and/or one or two Labels.
<span class="grey">Shiomoto, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
4. Link ID identifying the incoming (upstream) TE link, followed by a
Link ID identifying the outgoing (downstream) TE link, optionally
followed by a Component Interface ID and/or one or two Labels.
5. TE Router ID identifying the LSR, followed by a Link ID
identifying the outgoing (downstream) TE link, optionally followed
by a Component Interface ID and/or one or two Labels.
6. Link ID identifying the incoming (upstream) TE link, followed by
the TE Router ID identifying the LSR, followed by a Link ID
identifying the outgoing (downstream) TE link, optionally followed
by a Component Interface ID and/or one or two Labels.
An implementation may choose any of these options and must be
prepared to receive an RRO that contains any of these options.
<span class="h4"><a class="selflink" id="section-6.1.4" href="#section-6.1.4">6.1.4</a>. Label Record Subobject in RRO</span>
RRO Label recording is requested by an ingress node setting the Label
Recording flag in the SESSION_ATTRIBUTE object and including an RRO
is included in the Path message as described in [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]. Under
these circumstances, each LSR along the LSP should include label
information in the RRO in the Path message if it is available.
As described in [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], the processing for a Resv message "mirrors
that of the Path" and "The only difference is that the RRO in a Resv
message records the path information in the reverse direction." This
means that hops are added to the RRO in the reverse order, but the
information added at each LSR is in the same order (see Sections
6.1.1, 6.1.2, and 6.1.3). Thus, when label recording is requested,
labels are included in the RROs in both the Path and Resv messages.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Component Link Identification</span>
When a bundled link [<a href="./rfc4201" title=""Link Bundling in MPLS Traffic Engineering (TE)"">RFC4201</a>] is used to provide a data channel, a
component link identifier is specified in the Interface
Identification TLV in the IF_ID RSVP_HOP Object in order to indicate
which data channel from within the bundle is to be used. The
Interface Identification TLV is IF_INDEX TLV (Type 3) in the case of
an unnumbered component link and IPv4 TLV (Type 1) or IPv6 TLV
(Type 2) in the case of a numbered component link.
The component link for the upstream data channel may differ from that
for the downstream data channel in the case of a bidirectional LSP.
In this case, the Interface Identification TLV specifying a
downstream interface is followed by another Interface Identification
TLV specifying an upstream interface.
<span class="grey">Shiomoto, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
Note that identifiers in TLVs for upstream and downstream data
channels in both Path and Resv messages are specified from the
viewpoint of the upstream node (the node sending the Path message and
receiving the Resv message), using identifiers belonging to the node.
An LSR constructing an ERO may include a Link ID that identifies a
bundled link. If the LSR knows the identities of the component links
and wishes to exert control, it may also include component link
identifiers in the ERO. Otherwise, the component link identifiers
are not included in the ERO.
When a bundled link is in use, the RRO may include the Link ID that
identifies the link bundle. Additionally, the RRO may include a
component link identifier.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Forwarding Destination of Path Messages with ERO</span>
The final destination of the Path message is the Egress node that is
specified by the tunnel end point address in the Session object.
The Egress node must not forward the corresponding Path message
downstream, even if the ERO includes the outgoing interface ID of the
Egress node for Egress control [<a href="./rfc4003" title=""GMPLS Signaling Procedure for Egress Control"">RFC4003</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Topics Related to the GMPLS Control Plane</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Control Channel Separation</span>
In GMPLS, a control channel can be separated from the data channel
and there is not necessarily a one-to-one association of a control
channel to a data channel. Two nodes that are adjacent in the data
plane may have multiple IP hops between them in the control plane.
There are two broad types of separated control planes: native and
tunneled. These differ primarily in the nature of encapsulation used
for signaling messages, which also results in slightly different
address handling with respect to the control plane address.
<span class="h4"><a class="selflink" id="section-7.1.1" href="#section-7.1.1">7.1.1</a>. Native and Tunneled Control Plane</span>
A native control plane uses IP forwarding to deliver RSVP-TE messages
between protocol speakers. The message is not further encapsulated.
IP forwarding applies normal rules to the IP header. Note that an IP
hop must not decrement the TTL of the received RSVP-TE message.
For the case where two adjacent nodes have multiple IP hops between
them in the control plane, then as stated in <a href="./rfc3945#section-9">Section 9 of [RFC3945]</a>,
<span class="grey">Shiomoto, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
implementations should use the mechanisms of <a href="./rfc4206#section-6.1.1">Section 6.1.1 of
[RFC4206]</a> whether or not they use LSP Hierarchy. Note that <a href="./rfc4206#section-6.1.1">Section</a>
<a href="./rfc4206#section-6.1.1">6.1.1 of [RFC4206]</a> applies to an "FA-LSP" as stated in that section,
but also to a "TE link" for the case where a normal TE link is used.
With a tunneled control plane, the RSVP-TE message is packaged in an
IP packet that is inserted into a tunnel such that the IP packet will
traverse exactly one IP hop. Various tunneling techniques can be
used including (but not limited to) IP-in-IP, Generic Routing
Encapsulation (GRE), and IP in MPLS.
Where the tunneling mechanism includes a TTL, it should be treated as
for any network message sent on that network. Implementations
receiving RSVP-TE messages on the tunnel interface must not compare
the RSVP-TE TTL to any other TTL (whether the IP TTL or the tunnel
TTL).
It has been observed that some implementations do not support the
tunneled control plane features, and it is suggested that to enable
interoperability, all implementations should support at least a
native control plane.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Separation of Control and Data Plane Traffic</span>
Data traffic must not be transmitted through the control plane. This
is crucial when attempting PSC (Packet-Switching Capable) GMPLS with
separated control and data channels.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Addresses in the MPLS and GMPLS TE MIB Modules</span>
This section describes a method of defining or monitoring an LSP
tunnel using the MPLS-TE-STD-MIB module [<a href="./rfc3812" title=""Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)"">RFC3812</a>] and GMPLS-TE-STD-
MIB module [<a href="./rfc4802" title=""Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base"">RFC4802</a>] where the ingress and/or egress routers are
identified using 128-bit IPv6 addresses. This is the case when the
mplsTunnelIngressLSRId and mplsTunnelEgressLSRId objects in the
mplsTunnelTable [<a href="./rfc3812" title=""Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)"">RFC3812</a>] cannot be used to carry the tunnel end
point address and Extended Tunnel Id fields from the signaled Session
Object because the IPv6 variant (LSP_TUNNEL_IPv6_SESSION object) is
in use.
The normative text for MIB objects for control and monitoring MPLS
and GMPLS nodes is found in the RFCs referenced above. This section
makes no changes to those objects, but describes how they may be used
to provide the necessary function.
<span class="grey">Shiomoto, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Handling IPv6 Source and Destination Addresses</span>
<span class="h4"><a class="selflink" id="section-8.1.1" href="#section-8.1.1">8.1.1</a>. Identifying LSRs</span>
For this feature to be used, all LSRs in the network must advertise a
32-bit value that can be used to identify the LSR. In this document,
this is referred to as the 32-bit LSR ID. The 32-bit LSR ID is the
OSPFv3 router ID [<a href="./rfc2740" title=""OSPF for IPv6"">RFC2740</a>] or the ISIS IPv4 TE Router ID [<a href="./rfc3784" title=""Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)"">RFC3784</a>].
Note that these are different from TE router ID (see <a href="#section-2">Section 2</a>).
<span class="h4"><a class="selflink" id="section-8.1.2" href="#section-8.1.2">8.1.2</a>. Configuring GMPLS Tunnels</span>
When setting up RSVP TE tunnels, it is common practice to copy the
values of the mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields
in the MPLS TE MIB mplsTunnelTable [<a href="./rfc3812" title=""Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)"">RFC3812</a>] into the Extended Tunnel
ID and IPv4 tunnel end point address fields, respectively, in the
RSVP-TE LSP_TUNNEL_IPv4 SESSION object [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>].
This approach cannot be used when the ingress and egress routers are
identified by 128-bit IPv6 addresses as the mplsTunnelIngressLSRId,
and mplsTunnelEgressLSRId fields are defined to be 32-bit values
[<a href="./rfc3811" title=""Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management"">RFC3811</a>], [<a href="./rfc3812" title=""Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)"">RFC3812</a>].
Instead, the IPv6 addresses should be configured in the mplsHopTable
as the first and last hops of the mplsTunnelHopTable entries defining
the explicit route for the tunnel. Note that this implies that a
tunnel with IPv6 source and destination addresses must have an
explicit route configured, although it should be noted that the
configuration of an explicit route in this way does not imply that an
explicit route will be signaled.
In more detail, the tunnel is configured at the ingress router as
follows. See [<a href="./rfc3812" title=""Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)"">RFC3812</a>] for definitions of MIB table objects and for
default (that is, "normal") behavior.
The mplsTunnelIndex and mplsTunnelInstance fields are set as normal.
The mplsTunnelIngressLSRId and mplsTunnelEgressLSRId fields should be
set to 32-bit LSR IDs for ingress and egress LSRs, respectively.
The mplsTunnelHopTableIndex must be set to a non-zero value. That
is, an explicit route must be specified.
The first hop of the explicit route must have mplsTunnelHopAddrType
field set to ipv6(2) and should have the mplsTunnelHopIpAddr field
set to a global scope IPv6 address of the ingress router that is
reachable in the control plane.
<span class="grey">Shiomoto, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
The last hop of the explicit route must have mplsTunnelHopAddrType
field set to ipv6(2) and should have the mplsTunnelHopIpAddr field
set to a global scope IPv6 address of the egress router that is
reachable in the control plane.
The ingress router should set the signaled values of the Extended
Tunnel ID and IPv6 tunnel end point address fields, respectively, of
the RSVP-TE LSP_TUNNEL_IPv6 SESSION object [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>] from the
mplsTunnelHopIpAddr object of the first and last hops in the
configured explicit route.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Managing and Monitoring Tunnel Table Entries</span>
In addition to their use for configuring LSPs as described in <a href="#section-8.1">Section</a>
<a href="#section-8.1">8.1</a>, the TE MIB modules (MPLS-TE-STD-MIB and GMPLS-TE-STD-MIB) may be
used for managing and monitoring MPLS and GMPLS TE LSPs,
respectively. This function is particularly important at egress and
transit LSRs.
For a tunnel with IPv6 source and destination addresses, an LSR
implementation should return values in the mplsTunnelTable as follows
(where "normal" behavior is the default taken from [<a href="./rfc3812" title=""Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)"">RFC3812</a>]).
The mplsTunnelIndex and mplsTunnelInstance fields are set as normal.
The mplsTunnelIngressLSRId field and mplsTunnelEgressLSRId are set to
32-bit LSR IDs. That is, each transit and egress router maps from
the IPv6 address in the Extended Tunnel ID field to the 32-bit LSR ID
of the ingress LSR. Each transit router also maps from the IPv6
address in the IPv6 tunnel end point address field to the 32-bit LSR
ID of the egress LSR.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
In the interoperability testing we conducted, the major issue we
found was the use of control channels for forwarding data. This was
due to the setting of both control and data plane addresses to the
same value in PSC (Packet-Switching Capable) equipment. This
occurred when attempting to test PSC GMPLS with separated control and
data channels. What resulted instead were parallel interfaces with
the same addresses. This could be avoided simply by keeping the
addresses for the control and data plane separate.
<span class="grey">Shiomoto, et al. Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>
The following people made textual contributions to this document:
Alan Davey, Yumiko Kawashima, Kaori Shimizu, Thomas D. Nadeau,
Ashok Narayanan, Eiji Oki, Lyndon Ong, Vijay Pandian, Hari
Rakotoranto, and Adrian Farrel.
The authors would like to thank Adrian Farrel for the helpful
discussions and the feedback he gave on the document. In addition,
Jari Arkko, Arthi Ayyangar, Deborah Brungard, Diego Caviglia, Lisa
Dusseault, Dimitri Papadimitriou, Jonathan Sadler, Hidetsugu
Sugiyama, and Julien Meuric provided helpful comments and
suggestions.
Adrian Farrel edited the final revisions of this document before and
after working group last call.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC2205">RFC2205</a>] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", <a href="./rfc2205">RFC 2205</a>, September 1997.
[<a id="ref-RFC2328">RFC2328</a>] Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>, April 1998.
[<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-RFC3471">RFC3471</a>] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", <a href="./rfc3471">RFC</a>
<a href="./rfc3471">3471</a>, January 2003.
[<a id="ref-RFC3473">RFC3473</a>] Berger, L., Ed., "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-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.
[<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 3630</a>, September
2003.
<span class="grey">Shiomoto, et al. Informational [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
[<a id="ref-RFC3811">RFC3811</a>] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of
Textual Conventions (TCs) for Multiprotocol Label Switching
(MPLS) Management", <a href="./rfc3811">RFC 3811</a>, June 2004.
[<a id="ref-RFC3812">RFC3812</a>] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", <a href="./rfc3812">RFC 3812</a>, June
2004.
[<a id="ref-RFC3945">RFC3945</a>] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", <a href="./rfc3945">RFC 3945</a>, October 2004.
[<a id="ref-RFC4003">RFC4003</a>] Berger, L., "GMPLS Signaling Procedure for Egress Control",
<a href="./rfc4003">RFC 4003</a>, February 2005.
[<a id="ref-RFC4201">RFC4201</a>] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
MPLS Traffic Engineering (TE)", <a href="./rfc4201">RFC 4201</a>, October 2005.
[<a id="ref-RFC4202">RFC4202</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-RFC4203">RFC4203</a>] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-protocol Label Switching", <a href="./rfc4203">RFC</a>
<a href="./rfc4203">4203</a>, October 2005.
[<a id="ref-RFC4206">RFC4206</a>] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
Generalized MPLS TE", <a href="./rfc4206">RFC 4206</a>, October 2005.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-RFC1195">RFC1195</a>] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", <a href="./rfc1195">RFC 1195</a>, December 1990.
[<a id="ref-RFC2740">RFC2740</a>] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", <a href="./rfc2740">RFC</a>
<a href="./rfc2740">2740</a>, December 1999.
[<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-RFC4205">RFC4205</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</a>
<a href="./rfc4205">4205</a>, October 2005.
<span class="grey">Shiomoto, et al. Informational [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
[<a id="ref-RFC4802">RFC4802</a>] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic Engineering
Management Information Base", <a href="./rfc4802">RFC 4802</a>, February 2007.
Authors' Addresses
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori
Musashino, Tokyo 180-8585
Japan
Phone: +81 422 59 4402
EMail: shiomoto.kohei@lab.ntt.co.jp
Richard Rabbat
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
Phone: +1 650-714-7618
EMail: rabbat@alum.mit.edu
Rajiv Papneja
Isocore Corporation
12359 Sunrise Valley Drive, Suite 100
Reston, Virginia 20191
United States of America
Phone: +1 703-860-9273
EMail: rpapneja@isocore.com
<span class="grey">Shiomoto, et al. Informational [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4990">RFC 4990</a> Use of Addresses in GMPLS Networks September 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
Shiomoto, et al. Informational [Page 23]
</pre>
|
