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
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
|
<pre>Internet Engineering Task Force (IETF) D. Joachimpillai
Request for Comments: 8013 Verizon
Category: Standards Track J. Hadi Salim
ISSN: 2070-1721 Mojatatu Networks
February 2017
<span class="h1">Forwarding and Control Element Separation (ForCES)</span>
<span class="h1">Inter-FE Logical Functional Block (LFB)</span>
Abstract
This document describes how to extend the Forwarding and Control
Element Separation (ForCES) Logical Functional Block (LFB) topology
across Forwarding Elements (FEs) by defining the inter-FE LFB class.
The inter-FE LFB class provides the ability to pass data and metadata
across FEs without needing any changes to the ForCES specification.
The document focuses on Ethernet transport.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc8013">http://www.rfc-editor.org/info/rfc8013</a>.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology and Conventions . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Definitions . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Problem Scope and Use Cases . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Assumptions . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Sample Use Cases . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2.1">3.2.1</a>. Basic IPv4 Router . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2.1.1">3.2.1.1</a>. Distributing the Basic IPv4 Router . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.2.2">3.2.2</a>. Arbitrary Network Function . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.2.2.1">3.2.2.1</a>. Distributing the Arbitrary Network Function . . . <a href="#page-8">8</a>
<a href="#section-4">4</a>. Inter-FE LFB Overview . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.1">4.1</a>. Inserting the Inter-FE LFB . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. Inter-FE Ethernet Connectivity . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. Inter-FE Ethernet Connectivity Issues . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.1.1">5.1.1</a>. MTU Consideration . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.1.2">5.1.2</a>. Quality-of-Service Considerations . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5.1.3">5.1.3</a>. Congestion Considerations . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5.2">5.2</a>. Inter-FE Ethernet Encapsulation . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6">6</a>. Detailed Description of the Ethernet Inter-FE LFB . . . . . . <a href="#page-13">13</a>
<a href="#section-6.1">6.1</a>. Data Handling . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6.1.1">6.1.1</a>. Egress Processing . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6.1.2">6.1.2</a>. Ingress Processing . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6.2">6.2</a>. Components . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-6.3">6.3</a>. Inter-FE LFB XML Model . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#section-8">8</a>. IEEE Assignment Considerations . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#section-9">9</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
In the ForCES architecture, a packet service can be modeled by
composing a graph of one or more LFB instances. The reader is
referred to the details in the ForCES model [<a href="./rfc5812" title=""Forwarding and Control Element Separation (ForCES) Forwarding Element Model"">RFC5812</a>].
The ForCES model describes the processing within a single Forwarding
Element (FE) in terms of Logical Functional Blocks (LFBs), including
provision for the Control Element (CE) to establish and modify that
processing sequence, and the parameters of the individual LFBs.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
Under some circumstances, it would be beneficial to be able to extend
this view and the resulting processing across more than one FE. This
may be in order to achieve scale by splitting the processing across
elements or to utilize specialized hardware available on specific
FEs.
Given that the ForCES inter-LFB architecture calls for the ability to
pass metadata between LFBs, it is imperative to define mechanisms to
extend that existing feature and allow passing the metadata between
LFBs across FEs.
This document describes how to extend the LFB topology across FEs,
i.e., inter-FE connectivity without needing any changes to the ForCES
definitions. It focuses on using Ethernet as the interconnection
between FEs.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology and Conventions</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Definitions</span>
This document depends on the terms (below) defined in several ForCES
documents: [<a href="./rfc3746" title=""Forwarding and Control Element Separation (ForCES) Framework"">RFC3746</a>], [<a href="./rfc5810" title=""Forwarding and Control Element Separation (ForCES) Protocol Specification"">RFC5810</a>], [<a href="./rfc5811" title=""SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol"">RFC5811</a>], [<a href="./rfc5812" title=""Forwarding and Control Element Separation (ForCES) Forwarding Element Model"">RFC5812</a>], [<a href="./rfc7391" title=""Forwarding and Control Element Separation (ForCES) Protocol Extensions"">RFC7391</a>], and
[<a href="./rfc7408" title=""Forwarding and Control Element Separation (ForCES) Model Extension"">RFC7408</a>].
Control Element (CE)
Forwarding Element (FE)
FE Model
LFB (Logical Functional Block) Class (or type)
LFB Instance
LFB Model
LFB Metadata
ForCES Component
LFB Component
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
ForCES Protocol Layer (ForCES PL)
ForCES Protocol Transport Mapping Layer (ForCES TML)
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Problem Scope and Use Cases</span>
The scope of this document is to solve the challenge of passing
ForCES-defined metadata alongside packet data across FEs (be they
physical or virtual) for the purpose of distributing the LFB
processing.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Assumptions</span>
o The FEs involved in the inter-FE LFB belong to the same Network
Element (NE) and are within a single administrative private
network that is in close proximity.
o The FEs are already interconnected using Ethernet. We focus on
Ethernet because it is commonly used for FE interconnection.
Other higher transports (such as UDP over IP) or lower transports
could be defined to carry the data and metadata, but these cases
are not addressed in this document.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Sample Use Cases</span>
To illustrate the problem scope, we present two use cases where we
start with a single FE running all the LFBs functionality and then
split it into multiple FEs achieving the same end goals.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Basic IPv4 Router</span>
A sample LFB topology depicted in Figure 1 demonstrates a service
graph for delivering a basic IPv4-forwarding service within one FE.
For the purpose of illustration, the diagram shows LFB classes as
graph nodes instead of multiple LFB class instances.
Since the purpose of the illustration in Figure 1 is to showcase how
data and metadata are sent down or upstream on a graph of LFB
instances, it abstracts out any ports in both directions and talks
about a generic ingress and egress LFB. Again, for illustration
purposes, the diagram does not show exception or error paths. Also
left out are details on Reverse Path Filtering, ECMP, multicast
handling, etc. In other words, this is not meant to be a complete
description of an IPv4-forwarding application; for a more complete
example, please refer to the LFBLibrary document [<a href="./rfc6956" title=""Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library"">RFC6956</a>].
The output of the ingress LFB(s) coming into the IPv4 Validator LFB
will have both the IPv4 packets and, depending on the implementation,
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
a variety of ingress metadata such as offsets into the different
headers, any classification metadata, physical and virtual ports
encountered, tunneling information, etc. These metadata are lumped
together as "ingress metadata".
Once the IPv4 validator vets the packet (for example, it ensures that
there is no expired TTL), it feeds the packet and inherited metadata
into the IPv4 unicast LPM (Longest-Prefix-Matching) LFB.
+----+
| |
IPv4 pkt | | IPv4 pkt +-----+ +---+
+------------->| +------------->| | | |
| + ingress | | + ingress |IPv4 | IPv4 pkt | |
| metadata | | metadata |Ucast+------------>| +--+
| +----+ |LPM | + ingress | | |
+-+-+ IPv4 +-----+ + NHinfo +---+ |
| | Validator metadata IPv4 |
| | LFB NextHop|
| | LFB |
| | |
| | IPv4 pkt |
| | + {ingress |
+---+ + NHdetails}
Ingress metadata |
LFB +--------+ |
| Egress | |
<--+ |<-----------------+
| LFB |
+--------+
Figure 1: Basic IPv4 Packet Service LFB Topology
The IPv4 unicast LPM LFB does an LPM lookup on the IPv4 FIB using the
destination IP address as a search key. The result is typically a
next-hop selector, which is passed downstream as metadata.
The NextHop LFB receives the IPv4 packet with associated next-hop
(NH) information metadata. The NextHop LFB consumes the NH
information metadata and derives a table index from it to look up the
next-hop table in order to find the appropriate egress information.
The lookup result is used to build the next-hop details to be used
downstream on the egress. This information may include any source
and destination information (for our purposes, which Media Access
Control (MAC) addresses to use) as well as egress ports. (Note: It
is also at this LFB where typically, the forwarding TTL-decrementing
and IP checksum recalculation occurs.)
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
The details of the egress LFB are considered out of scope for this
discussion. Suffice it to say that somewhere within or beyond the
Egress LFB, the IPv4 packet will be sent out a port (e.g., Ethernet,
virtual or physical).
<span class="h5"><a class="selflink" id="section-3.2.1.1" href="#section-3.2.1.1">3.2.1.1</a>. Distributing the Basic IPv4 Router</span>
Figure 2 demonstrates one way that the router LFB topology in
Figure 1 may be split across two FEs (e.g., two Application-Specific
Integrated Circuits (ASICs)). Figure 2 shows the LFB topology split
across FEs after the IPv4 unicast LPM LFB.
FE1
+-------------------------------------------------------------+
| +----+ |
| +----------+ | | |
| | Ingress | IPv4 pkt | | IPv4 pkt +-----+ |
| | LFB +-------------->| +------------->| | |
| | | + ingress | | + ingress |IPv4 | |
| +----------+ metadata | | metadata |Ucast| |
| ^ +----+ |LPM | |
| | IPv4 +--+--+ |
| | Validator | |
| LFB | |
+---------------------------------------------------|---------+
|
IPv4 packet +
{ingress + NHinfo}
metadata
FE2 |
+---------------------------------------------------|---------+
| V |
| +--------+ +--------+ |
| | Egress | IPv4 packet | IPv4 | |
| <-----+ LFB |<----------------------+NextHop | |
| | |{ingress + NHdetails} | LFB | |
| +--------+ metadata +--------+ |
+-------------------------------------------------------------+
Figure 2: Split IPv4 Packet Service LFB Topology
Some proprietary interconnections (for example, Broadcom HiGig over
XAUI [<a href="#ref-brcm-higig">brcm-higig</a>]) are known to exist to carry both the IPv4 packet
and the related metadata between the IPv4 Unicast LFB and IPv4NextHop
LFB across the two FEs.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
This document defines the inter-FE LFB, a standard mechanism for
encapsulating, generating, receiving, and decapsulating packets and
associated metadata FEs over Ethernet.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Arbitrary Network Function</span>
In this section, we show an example of an arbitrary Network Function
that is more coarsely grained in terms of functionality. Each
Network Function may constitute more than one LFB.
FE1
+-------------------------------------------------------------+
| +----+ |
| +----------+ | | |
| | Network | pkt |NF2 | pkt +-----+ |
| | Function +-------------->| +------------->| | |
| | 1 | + NF1 | | + NF1/2 |NF3 | |
| +----------+ metadata | | metadata | | |
| ^ +----+ | | |
| | +--+--+ |
| | | |
| | |
+---------------------------------------------------|---------+
V
Figure 3: A Network Function Service Chain within One FE
The setup in Figure 3 is typical of most packet processing boxes
where we have functions like deep packet inspection (DPI), NAT,
Routing, etc., connected in such a topology to deliver a packet
processing service to flows.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
<span class="h5"><a class="selflink" id="section-3.2.2.1" href="#section-3.2.2.1">3.2.2.1</a>. Distributing the Arbitrary Network Function</span>
The setup in Figure 3 can be split across three FEs instead of as
demonstrated in Figure 4. This could be motivated by scale-out
reasons or because different vendors provide different functionality,
which is plugged-in to provide such functionality. The end result is
having the same packet service delivered to the different flows
passing through.
FE1 FE2
+----------+ +----+ FE3
| Network | pkt |NF2 | pkt +-----+
| Function +-------------->| +------------->| |
| 1 | + NF1 | | + NF1/2 |NF3 |
+----------+ metadata | | metadata | |
^ +----+ | |
| +--+--+
|
V
Figure 4: A Network Function Service Chain Distributed across
Multiple FEs
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Inter-FE LFB Overview</span>
We address the inter-FE connectivity requirements by defining the
inter-FE LFB class. Using a standard LFB class definition implies no
change to the basic ForCES architecture in the form of the core LFBs
(FE Protocol or Object LFBs). This design choice was made after
considering an alternative approach that would have required changes
to both the FE Object capabilities (SupportedLFBs) and the
LFBTopology component to describe the inter-FE connectivity
capabilities as well as the runtime topology of the LFB instances.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Inserting the Inter-FE LFB ne 15</span>
The distributed LFB topology described in Figure 2 is re-illustrated
in Figure 5 to show the topology location where the inter-FE LFB
would fit in.
As can be observed in Figure 5, the same details passed between IPv4
unicast LPM LFB and the IPv4 NH LFB are passed to the egress side of
the inter-FE LFB. This information is illustrated as multiplicity of
inputs into the egress inter-FE LFB instance. Each input represents
a unique set of selection information.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
FE1
+-------------------------------------------------------------+
| +----------+ +----+ |
| | Ingress | IPv4 pkt | | IPv4 pkt +-----+ |
| | LFB +-------------->| +------------->| | |
| | | + ingress | | + ingress |IPv4 | |
| +----------+ metadata | | metadata |Ucast| |
| ^ +----+ |LPM | |
| | IPv4 +--+--+ |
| | Validator | |
| | LFB | |
| | IPv4 pkt + metadata |
| | {ingress + NHinfo} |
| | | |
| | +..--+..+ |
| | |..| | | |
| +-V--V-V--V-+ |
| | Egress | |
| | Inter-FE | |
| | LFB | |
| +------+----+ |
+---------------------------------------------------|---------+
|
Ethernet Frame with: |
IPv4 packet data and metadata
{ingress + NHinfo + Inter-FE info}
FE2 |
+---------------------------------------------------|---------+
| +..+.+..+ |
| |..|.|..| |
| +-V--V-V--V-+ |
| | Ingress | |
| | Inter-FE | |
| | LFB | |
| +----+------+ |
| | |
| IPv4 pkt + metadata |
| {ingress + NHinfo} |
| | |
| +--------+ +----V---+ |
| | Egress | IPv4 packet | IPv4 | |
| <-----+ LFB |<----------------------+NextHop | |
| | |{ingress + NHdetails} | LFB | |
| +--------+ metadata +--------+ |
+-------------------------------------------------------------+
Figure 5: Split IPv4-Forwarding Service with Inter-FE LFB
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
The egress of the inter-FE LFB uses the received packet and metadata
to select details for encapsulation when sending messages towards the
selected neighboring FE. These details include what to communicate
as the source and destination FEs (abstracted as MAC addresses as
described in <a href="#section-5.2">Section 5.2</a>); in addition, the original metadata may be
passed along with the original IPv4 packet.
On the ingress side of the inter-FE LFB, the received packet and its
associated metadata are used to decide the packet graph continuation.
This includes which of the original metadata and on which next LFB
class instance to continue processing. In Figure 5, an IPv4NextHop
LFB instance is selected and the appropriate metadata is passed to
it.
The ingress side of the inter-FE LFB consumes some of the information
passed and passes it the IPv4 packet alongside with the ingress and
NHinfo metadata to the IPv4NextHop LFB as was done earlier in both
Figures 1 and 2.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Inter-FE Ethernet Connectivity</span>
<a href="#section-5.1">Section 5.1</a> describes some of the issues related to using Ethernet as
the transport and how we mitigate them.
<a href="#section-5.2">Section 5.2</a> defines a payload format that is to be used over
Ethernet. An existing implementation of this specification that runs
on top of Linux Traffic Control [<a href="#ref-linux-tc" title=""Linux Traffic Control Classifier-Action Subsystem Architecture"">linux-tc</a>] is described in [<a href="#ref-tc-ife" title=""Distributing Linux Traffic Control Classifier-Action Subsystem"">tc-ife</a>].
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Inter-FE Ethernet Connectivity Issues</span>
There are several issues that may occur due to using direct Ethernet
encapsulation that need consideration.
<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>. MTU Consideration</span>
Because we are adding data to existing Ethernet frames, MTU issues
may arise. We recommend:
o Using large MTUs when possible (example with jumbo frames).
o Limiting the amount of metadata that could be transmitted; our
definition allows for filtering of select metadata to be
encapsulated in the frame as described in <a href="#section-6">Section 6</a>. We recommend
sizing the egress port MTU so as to allow space for maximum size
of the metadata total size to allow between FEs. In such a setup,
the port is configured to "lie" to the upper layers by claiming to
have a lower MTU than it is capable of. Setting the MTU can be
achieved by ForCES control of the port LFB (or some other
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
configuration. In essence, the control plane when explicitly
making a decision for the MTU settings of the egress port is
implicitly deciding how much metadata will be allowed. Caution
needs to be exercised on how low the resulting reported link MTU
could be: for IPv4 packets, the minimum size is 64 octets [<a href="./rfc791" title=""Internet Protocol"">RFC791</a>]
and for IPv6 the minimum size is 1280 octets [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>].
<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>. Quality-of-Service Considerations</span>
A raw packet arriving at the inter-FE LFB (from upstream LFB class
instances) may have Class-of-Service (CoS) metadata indicating how it
should be treated from a Quality-of-Service perspective.
The resulting Ethernet frame will be eventually (preferentially)
treated by a downstream LFB (typically a port LFB instance) and their
CoS marks will be honored in terms of priority. In other words, the
presence of the inter-FE LFB does not change the CoS semantics.
<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>. Congestion Considerations</span>
Most of the traffic passing through FEs that utilize the inter-FE LFB
is expected to be IP based, which is generally assumed to be
congestion controlled [<a href="#ref-UDP-GUIDE">UDP-GUIDE</a>]. For example, if congestion causes
a TCP packet annotated with additional ForCES metadata to be dropped
between FEs, the sending TCP can be expected to react in the same
fashion as if that packet had been dropped at a different point on
its path where ForCES is not involved. For this reason, additional
inter-FE congestion-control mechanisms are not specified.
However, the increased packet size due to the addition of ForCES
metadata is likely to require additional bandwidth on inter-FE links
in comparison to what would be required to carry the same traffic
without ForCES metadata. Therefore, traffic engineering SHOULD be
done when deploying inter-FE encapsulation.
Furthermore, the inter-FE LFB MUST only be deployed within a single
network (with a single network operator) or networks of an adjacent
set of cooperating network operators where traffic is managed to
avoid congestion. These are Controlled Environments, as defined by
Section 3.6 of [<a href="#ref-UDP-GUIDE">UDP-GUIDE</a>]. Additional measures SHOULD be imposed to
restrict the impact of inter-FE-encapsulated traffic on other
traffic; for example:
o rate-limiting all inter-FE LFB traffic at an upstream LFB
o managing circuit breaking [<a href="#ref-circuit-b">circuit-b</a>]
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
o Isolating the inter-FE traffic either via dedicated interfaces or
VLANs
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Inter-FE Ethernet Encapsulation</span>
The Ethernet wire encapsulation is illustrated in Figure 6. The
process that leads to this encapsulation is described in <a href="#section-6">Section 6</a>.
The resulting frame is 32-bit aligned.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inter-FE ethertype | Metadata length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV encoded Metadata ~~~..............~~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV encoded Metadata ~~~..............~~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original packet data ~~................~~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Packet Format Definition
The Ethernet header (illustrated in Figure 6) has the following
semantics:
o The Destination MAC Address is used to identify the Destination
FEID by the CE policy (as described in <a href="#section-6">Section 6</a>).
o The Source MAC Address is used to identify the Source FEID by the
CE policy (as described in <a href="#section-6">Section 6</a>).
o The ethertype is used to identify the frame as inter-FE LFB type.
Ethertype ED3E (base 16) is to be used.
o The 16-bit metadata length is used to describe the total encoded
metadata length (including the 16 bits used to encode the metadata
length).
o One or more 16-bit TLV-encoded metadatum follows the Metadata
length field. The TLV type identifies the metadata ID. ForCES
metadata IDs that have been registered with IANA will be used.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
All TLVs will be 32-bit-aligned. We recognize that using a 16-bit
TLV restricts the metadata ID to 16 bits instead of a ForCES-
defined component ID space of 32 bits if an Index-Length-Value
(ILV) is used. However, at the time of publication, we believe
this is sufficient to carry all the information we need; the TLV
approach has been selected because it saves us 4 bytes per
metadatum transferred as compared to the ILV approach.
o The original packet data payload is appended at the end of the
metadata as shown.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Detailed Description of the Ethernet Inter-FE LFB</span>
The Ethernet inter-FE LFB has two LFB input port groups and three LFB
output ports as shown in Figure 7.
The inter-FE LFB defines two components used in aiding processing
described in <a href="#section-6.1">Section 6.1</a>.
+-----------------+
Inter-FE LFB | |
Encapsulated | OUT2+--> Decapsulated Packet
-------------->|IngressInGroup | + metadata
Ethernet Frame | |
| |
raw Packet + | OUT1+--> Encapsulated Ethernet
-------------->|EgressInGroup | Frame
Metadata | |
| EXCEPTIONOUT +--> ExceptionID, packet
| | + metadata
+-----------------+
Figure 7: Inter-FE LFB
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Data Handling</span>
The inter-FE LFB (instance) can be positioned at the egress of a
source FE. Figure 5 illustrates an example source FE in the form of
FE1. In such a case, an inter-FE LFB instance receives, via port
group EgressInGroup, a raw packet and associated metadata from the
preceding LFB instances. The input information is used to produce a
selection of how to generate and encapsulate the new frame. The set
of all selections is stored in the LFB component IFETable described
further below. The processed encapsulated Ethernet frame will go out
on OUT1 to a downstream LFB instance when processing succeeds or to
the EXCEPTIONOUT port in the case of failure.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
The inter-FE LFB (instance) can be positioned at the ingress of a
receiving FE. Figure 5 illustrates an example destination FE in the
form of FE1. In such a case, an inter-FE LFB receives, via an LFB
port in the IngressInGroup, an encapsulated Ethernet frame.
Successful processing of the packet will result in a raw packet with
associated metadata IDs going downstream to an LFB connected on OUT2.
On failure, the data is sent out EXCEPTIONOUT.
<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>. Egress Processing</span>
The egress inter-FE LFB receives packet data and any accompanying
metadatum at an LFB port of the LFB instance's input port group
labeled EgressInGroup.
The LFB implementation may use the incoming LFB port (within the LFB
port group EgressInGroup) to map to a table index used to look up the
IFETable table.
If the lookup is successful, a matched table row that has the IFEInfo
details is retrieved with the tuple (optional IFETYPE, optional
StatId, Destination MAC address (DSTFE), Source MAC address (SRCFE),
and optional metafilters). The metafilters lists define a whitelist
of which metadatum are to be passed to the neighboring FE. The
inter-FE LFB will perform the following actions using the resulting
tuple:
o Increment statistics for packet and byte count observed at the
corresponding IFEStats entry.
o When the MetaFilterList is present, walk each received metadatum
and apply it against the MetaFilterList. If no legitimate
metadata is found that needs to be passed downstream, then the
processing stops and the packet and metadata are sent out the
EXCEPTIONOUT port with the exceptionID of EncapTableLookupFailed
[<a href="./rfc6956" title=""Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library"">RFC6956</a>].
o Check that the additional overhead of the Ethernet header and
encapsulated metadata will not exceed MTU. If it does, increment
the error-packet-count statistics and send the packet and metadata
out the EXCEPTIONOUT port with the exceptionID of FragRequired
[<a href="./rfc6956" title=""Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library"">RFC6956</a>].
o Create the Ethernet header.
o Set the Destination MAC address of the Ethernet header with the
value found in the DSTFE field.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
o Set the Source MAC address of the Ethernet header with the value
found in the SRCFE field.
o If the optional IFETYPE is present, set the ethertype to the value
found in IFETYPE. If IFETYPE is absent, then the standard inter-
FE LFB ethertype ED3E (base 16) is used.
o Encapsulate each allowed metadatum in a TLV. Use the metaID as
the "type" field in the TLV header. The TLV should be aligned to
32 bits. This means you may need to add a padding of zeroes at
the end of the TLV to ensure alignment.
o Update the metadata length to the sum of each TLV's space plus 2
bytes (a 16-bit space for the Metadata length field).
The resulting packet is sent to the next LFB instance connected to
the OUT1 LFB-port, typically a port LFB.
In the case of a failed lookup, the original packet and associated
metadata is sent out the EXCEPTIONOUT port with the exceptionID of
EncapTableLookupFailed [<a href="./rfc6956" title=""Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library"">RFC6956</a>]. Note that the EXCEPTIONOUT LFB
port is merely an abstraction and implementation may in fact drop
packets as described above.
<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>. Ingress Processing</span>
An ingressing inter-FE LFB packet is recognized by inspecting the
ethertype, and optionally the destination and source MAC addresses.
A matching packet is mapped to an LFB instance port in the
IngressInGroup. The IFETable table row entry matching the LFB
instance port may have optionally programmed metadata filters. In
such a case, the ingress processing should use the metadata filters
as a whitelist of what metadatum is to be allowed.
o Increment statistics for packet and byte count observed.
o Look at the metadata length field and walk the packet data,
extracting the metadata values from the TLVs. For each metadatum
extracted, in the presence of metadata filters, the metaID is
compared against the relevant IFETable row metafilter list. If
the metadatum is recognized and allowed by the filter, the
corresponding implementation Metadatum field is set. If an
unknown metadatum ID is encountered or if the metaID is not in the
allowed filter list, then the implementation is expected to ignore
it, increment the packet error statistic, and proceed processing
other metadatum.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
o Upon completion of processing all the metadata, the inter-FE LFB
instance resets the data point to the original payload (i.e.,
skips the IFE header information). At this point, the original
packet that was passed to the egress inter-FE LFB at the source FE
is reconstructed. This data is then passed along with the
reconstructed metadata downstream to the next LFB instance in the
graph.
In the case of a processing failure of either ingress or egress
positioning of the LFB, the packet and metadata are sent out the
EXCEPTIONOUT LFB port with the appropriate error ID. Note that the
EXCEPTIONOUT LFB port is merely an abstraction and implementation may
in fact drop packets as described above.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Components</span>
There are two LFB components accessed by the CE. The reader is asked
to refer to the definitions in Figure 8.
The first component, populated by the CE, is an array known as the
"IFETable" table. The array rows are made up of IFEInfo structure.
The IFEInfo structure constitutes the optional IFETYPE, the
optionally present StatId, the Destination MAC address (DSTFE), the
Source MAC address (SRCFE), and an optionally present array of
allowed metaIDs (MetaFilterList).
The second component (ID 2), populated by the FE and read by the CE,
is an indexed array known as the "IFEStats" table. Each IFEStats row
carries statistics information in the structure bstats.
A note about the StatId relationship between the IFETable table and
the IFEStats table -- an implementation may choose to map between an
IFETable row and IFEStats table row using the StatId entry in the
matching IFETable row. In that case, the IFETable StatId must be
present. An alternative implementation may map an IFETable row to an
IFEStats table row at provisioning time. Yet another alternative
implementation may choose not to use the IFETable row StatId and
instead use the IFETable row index as the IFEStats index. For these
reasons, the StatId component is optional.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Inter-FE LFB XML Model</span>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="IFE">
<frameDefs>
<frameDef>
<name>PacketAny</name>
<synopsis>Arbitrary Packet</synopsis>
</frameDef>
<frameDef>
<name>InterFEFrame</name>
<synopsis>
Ethernet frame with encapsulated IFE information
</synopsis>
</frameDef>
</frameDefs>
<dataTypeDefs>
<dataTypeDef>
<name>bstats</name>
<synopsis>Basic stats</synopsis>
<struct>
<component componentID="1">
<name>bytes</name>
<synopsis>The total number of bytes seen</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>packets</name>
<synopsis>The total number of packets seen</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>errors</name>
<synopsis>The total number of packets with errors</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
<dataTypeDef>
<name>IFEInfo</name>
<synopsis>Describing IFE table row Information</synopsis>
<struct>
<component componentID="1">
<name>IFETYPE</name>
<synopsis>
The ethertype to be used for outgoing IFE frame
</synopsis>
<optional/>
<typeRef>uint16</typeRef>
</component>
<component componentID="2">
<name>StatId</name>
<synopsis>
The Index into the stats table
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>DSTFE</name>
<synopsis>
The destination MAC address of the destination FE
</synopsis>
<typeRef>byte[6]</typeRef>
</component>
<component componentID="4">
<name>SRCFE</name>
<synopsis>
The source MAC address used for the source FE
</synopsis>
<typeRef>byte[6]</typeRef>
</component>
<component componentID="5">
<name>MetaFilterList</name>
<synopsis>
The allowed metadata filter table
</synopsis>
<optional/>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
</struct>
</dataTypeDef>
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="18">
<name>IFE</name>
<synopsis>
This LFB describes IFE connectivity parameterization
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="true">
<name>EgressInGroup</name>
<synopsis>
The input port group of the egress side.
It expects any type of Ethernet frame.
</synopsis>
<expectation>
<frameExpected>
<ref>PacketAny</ref>
</frameExpected>
</expectation>
</inputPort>
<inputPort group="true">
<name>IngressInGroup</name>
<synopsis>
The input port group of the ingress side.
It expects an interFE-encapsulated Ethernet frame.
</synopsis>
<expectation>
<frameExpected>
<ref>InterFEFrame</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>OUT1</name>
<synopsis>
The output port of the egress side
</synopsis>
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
<product>
<frameProduced>
<ref>InterFEFrame</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>OUT2</name>
<synopsis>
The output port of the Ingress side
</synopsis>
<product>
<frameProduced>
<ref>PacketAny</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>EXCEPTIONOUT</name>
<synopsis>
The exception handling path
</synopsis>
<product>
<frameProduced>
<ref>PacketAny</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>IFETable</name>
<synopsis>
The table of all inter-FE relations
</synopsis>
<array type="variable-size">
<typeRef>IFEInfo</typeRef>
</array>
</component>
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
<component componentID="2" access="read-only">
<name>IFEStats</name>
<synopsis>
The stats corresponding to the IFETable table
</synopsis>
<typeRef>bstats</typeRef>
</component>
</components>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
Figure 8: Inter-FE LFB XML
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA has registered the following LFB class name in the "Logical
Functional Block (LFB) Class Names and Class Identifiers" subregistry
of the "Forwarding and Control Element Separation (ForCES)" registry
<<a href="https://www.iana.org/assignments/forces">https://www.iana.org/assignments/forces</a>>.
+------------+--------+---------+-----------------------+-----------+
| LFB Class | LFB | LFB | Description | Reference |
| Identifier | Class | Version | | |
| | Name | | | |
+------------+--------+---------+-----------------------+-----------+
| 18 | IFE | 1.0 | An IFE LFB to | This |
| | | | standardize inter-FE | document |
| | | | LFB for ForCES | |
| | | | Network Elements | |
+------------+--------+---------+-----------------------+-----------+
Logical Functional Block (LFB) Class Names and Class Identifiers
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IEEE Assignment Considerations</span>
This memo includes a request for a new Ethernet protocol type as
described in <a href="#section-5.2">Section 5.2</a>.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
The FEs involved in the inter-FE LFB belong to the same NE and are
within the scope of a single administrative Ethernet LAN private
network. While trust of policy in the control and its treatment in
the datapath exists already, an inter-FE LFB implementation SHOULD
support security services provided by Media Access Control Security
(MACsec) [<a href="#ref-ieee8021ae">ieee8021ae</a>]. MACsec is not currently sufficiently widely
deployed in traditional packet processing hardware although it is
present in newer versions of the Linux kernel (which will be widely
deployed) [<a href="#ref-linux-macsec">linux-macsec</a>]. Over time, we expect that most FEs will be
able to support MACsec.
MACsec provides security services such as a message authentication
service and an optional confidentiality service. The services can be
configured manually or automatically using the MACsec Key Agreement
(MKA) over the IEEE 802.1x [<a href="#ref-ieee8021x">ieee8021x</a>] Extensible Authentication
Protocol (EAP) framework. It is expected that FE implementations are
going to start with shared keys configured from the control plane but
progress to automated key management.
The following are the MACsec security mechanisms that need to be in
place for the inter-FE LFB:
o Security mechanisms are NE-wide for all FEs. Once the security is
turned on, depending upon the chosen security level (e.g.,
Authentication, Confidentiality), it will be in effect for the
inter-FE LFB for the entire duration of the session.
o An operator SHOULD configure the same security policies for all
participating FEs in the NE cluster. This will ensure uniform
operations and avoid unnecessary complexity in policy
configuration. In other words, the Security Association Keys
(SAKs) should be pre-shared. When using MKA, FEs must identify
themselves with a shared Connectivity Association Key (CAK) and
Connectivity Association Key Name (CKN). EAP-TLS SHOULD be used
as the EAP method.
o An operator SHOULD configure the strict validation mode, i.e., all
non-protected, invalid, or non-verifiable frames MUST be dropped.
It should be noted that given the above choices, if an FE is
compromised, an entity running on the FE would be able to fake inter-
FE or modify its content, causing bad outcomes.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-ieee8021ae">ieee8021ae</a>]
IEEE, "IEEE Standard for Local and metropolitan area
networks Media Access Control (MAC) Security", IEEE
802.1AE-2006, DOI 10.1109/IEEESTD.2006.245590,
<<a href="http://ieeexplore.ieee.org/document/1678345/">http://ieeexplore.ieee.org/document/1678345/</a>>.
[<a id="ref-ieee8021x">ieee8021x</a>]
IEEE, "IEEE Standard for Local and metropolitan area
networks - Port-Based Network Access Control.", IEEE
802.1X-2010, DOI 10.1109/IEEESTD.2010.5409813,
<<a href="http://ieeexplore.ieee.org/document/5409813/">http://ieeexplore.ieee.org/document/5409813/</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5810">RFC5810</a>] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed.,
Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and
J. Halpern, "Forwarding and Control Element Separation
(ForCES) Protocol Specification", <a href="./rfc5810">RFC 5810</a>,
DOI 10.17487/RFC5810, March 2010,
<<a href="http://www.rfc-editor.org/info/rfc5810">http://www.rfc-editor.org/info/rfc5810</a>>.
[<a id="ref-RFC5811">RFC5811</a>] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
Layer (TML) for the Forwarding and Control Element
Separation (ForCES) Protocol", <a href="./rfc5811">RFC 5811</a>,
DOI 10.17487/RFC5811, March 2010,
<<a href="http://www.rfc-editor.org/info/rfc5811">http://www.rfc-editor.org/info/rfc5811</a>>.
[<a id="ref-RFC5812">RFC5812</a>] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model",
<a href="./rfc5812">RFC 5812</a>, DOI 10.17487/RFC5812, March 2010,
<<a href="http://www.rfc-editor.org/info/rfc5812">http://www.rfc-editor.org/info/rfc5812</a>>.
[<a id="ref-RFC7391">RFC7391</a>] Hadi Salim, J., "Forwarding and Control Element Separation
(ForCES) Protocol Extensions", <a href="./rfc7391">RFC 7391</a>,
DOI 10.17487/RFC7391, October 2014,
<<a href="http://www.rfc-editor.org/info/rfc7391">http://www.rfc-editor.org/info/rfc7391</a>>.
[<a id="ref-RFC7408">RFC7408</a>] Haleplidis, E., "Forwarding and Control Element Separation
(ForCES) Model Extension", <a href="./rfc7408">RFC 7408</a>, DOI 10.17487/RFC7408,
November 2014, <<a href="http://www.rfc-editor.org/info/rfc7408">http://www.rfc-editor.org/info/rfc7408</a>>.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-brcm-higig">brcm-higig</a>]
Broadcom, "HiGig", <<a href="http://www.broadcom.com/products/ethernet-communication-and-switching/switching/bcm56720">http://www.broadcom.com/products/</a>
<a href="http://www.broadcom.com/products/ethernet-communication-and-switching/switching/bcm56720">ethernet-communication-and-switching/switching/bcm56720</a>>.
[<a id="ref-circuit-b">circuit-b</a>]
Fairhurst, G., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22Network+Transport+Circuit+Breakers%22'>"Network Transport Circuit Breakers"</a>, Work
in Progress, <a href="./draft-ietf-tsvwg-circuit-breaker-15">draft-ietf-tsvwg-circuit-breaker-15</a>, April
2016.
[<a id="ref-linux-macsec">linux-macsec</a>]
Dubroca, S., "MACsec: Encryption for the wired LAN",
Netdev 11, Feb 2016.
[<a id="ref-linux-tc">linux-tc</a>] Hadi Salim, J., "Linux Traffic Control Classifier-Action
Subsystem Architecture", Netdev 01, Feb 2015.
[<a id="ref-RFC791">RFC791</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>,
DOI 10.17487/RFC0791, September 1981,
<<a href="http://www.rfc-editor.org/info/rfc791">http://www.rfc-editor.org/info/rfc791</a>>.
[<a id="ref-RFC2460">RFC2460</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, DOI 10.17487/RFC2460,
December 1998, <<a href="http://www.rfc-editor.org/info/rfc2460">http://www.rfc-editor.org/info/rfc2460</a>>.
[<a id="ref-RFC3746">RFC3746</a>] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", <a href="./rfc3746">RFC 3746</a>, DOI 10.17487/RFC3746, April 2004,
<<a href="http://www.rfc-editor.org/info/rfc3746">http://www.rfc-editor.org/info/rfc3746</a>>.
[<a id="ref-RFC6956">RFC6956</a>] Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J.
Halpern, "Forwarding and Control Element Separation
(ForCES) Logical Function Block (LFB) Library", <a href="./rfc6956">RFC 6956</a>,
DOI 10.17487/RFC6956, June 2013,
<<a href="http://www.rfc-editor.org/info/rfc6956">http://www.rfc-editor.org/info/rfc6956</a>>.
[<a id="ref-tc-ife">tc-ife</a>] Hadi Salim, J. and D. Joachimpillai, "Distributing Linux
Traffic Control Classifier-Action Subsystem", Netdev 01,
Feb 2015.
[<a id="ref-UDP-GUIDE">UDP-GUIDE</a>]
Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", Work in Progress, <a href="./draft-ietf-tsvwg-rfc5405bis-19">draft-ietf-tsvwg-</a>
<a href="./draft-ietf-tsvwg-rfc5405bis-19">rfc5405bis-19</a>, October 2016.
<span class="grey">Joachimpillai & Hadi Salim Standards Track [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc8013">RFC 8013</a> ForCES Inter-FE LFB February 2017</span>
Acknowledgements
The authors would like to thank Joel Halpern and Dave Hood for the
stimulating discussions. Evangelos Haleplidis shepherded and
contributed to improving this document. Alia Atlas was the AD
sponsor of this document and did a tremendous job of critiquing it.
The authors are grateful to Joel Halpern and Sue Hares in their roles
as the Routing Area reviewers for shaping the content of this
document. David Black put in a lot of effort to make sure the
congestion-control considerations are sane. Russ Housley did the
Gen-ART review, Joe Touch did the TSV area review, and Shucheng LIU
(Will) did the OPS review. Suresh Krishnan helped us provide clarity
during the IESG review. The authors are appreciative of the efforts
Stephen Farrell put in to fixing the security section.
Authors' Addresses
Damascane M. Joachimpillai
Verizon
60 Sylvan Rd
Waltham, MA 02451
United States of America
Email: damascene.joachimpillai@verizon.com
Jamal Hadi Salim
Mojatatu Networks
Suite 200, 15 Fitzgerald Rd.
Ottawa, Ontario K2H 9G1
Canada
Email: hadi@mojatatu.com
Joachimpillai & Hadi Salim Standards Track [Page 25]
</pre>
|
