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
|
<pre>Internet Engineering Task Force (IETF) E. Haleplidis
Request for Comments: 6369 O. Koufopavlou
Category: Informational S. Denazis
ISSN: 2070-1721 University of Patras
September 2011
<span class="h1">Forwarding and Control Element Separation (ForCES)</span>
<span class="h1">Implementation Experience</span>
Abstract
The Forwarding and Control Element Separation (ForCES) protocol
defines a standard communication and control mechanism through which
a Control Element (CE) can control the behavior of a Forwarding
Element (FE). This document captures the experience of implementing
the ForCES protocol and model. Its aim is to help others by
providing examples and possible strategies for implementing the
ForCES protocol.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</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/rfc6369">http://www.rfc-editor.org/info/rfc6369</a>.
Copyright Notice
Copyright (c) 2011 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
<span class="grey">Haleplidis, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Document Goal . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology and Conventions . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. ForCES Architecture . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Pre-Association Setup - Initial Configuration . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. TML . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Model . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3.1">3.3.1</a>. Components . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3.2">3.3.2</a>. LFBs . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.4">3.4</a>. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-3.4.1">3.4.1</a>. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-3.4.2">3.4.2</a>. Message Deserialization . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-3.4.3">3.4.3</a>. Message Serialization . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-4">4</a>. Development Platforms . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-5">5</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding
plane in a ForCES Network Element (ForCES NE). [<a href="./rfc3654" title=""Requirements for Separation of IP Control and Forwarding"">RFC3654</a>] defines the
ForCES requirements, and [<a href="./rfc3746" title=""Forwarding and Control Element Separation (ForCES) Framework"">RFC3746</a>] defines the ForCES framework.
The ForCES protocol works in a master-slave mode in which Forwarding
Elements (FEs) are slaves and Control Elements (CEs) are masters.
The protocol includes commands for transport of Logical Functional
Block (LFB) configuration information, association setup, status, and
event notifications, etc. The reader is encouraged to read the
Forwarding and Control Element Separation Protocol [<a href="./rfc5810" title=""Forwarding and Control Element Separation (ForCES) Protocol Specification"">RFC5810</a>] for
further information.
[<a id="ref-RFC5812">RFC5812</a>] presents a formal way to define FE LFBs using XML. LFB
configuration components, capabilities, and associated events are
defined when LFBs are formally created. The LFBs within the
Forwarding Element (FE) are accordingly controlled in a standardized
way by the ForCES protocol.
<span class="grey">Haleplidis, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
The Transport Mapping Layer (TML) transports the protocol messages.
The TML is where the issues of how to achieve transport-level
reliability, congestion control, multicast, ordering, etc., are
handled. It is expected that more than one TML will be standardized.
The various possible TMLs could vary their implementations based on
the capabilities of underlying media and transport. However, since
each TML is standardized, interoperability is guaranteed as long as
both endpoints support the same TML. All ForCES protocol layer
implementations must be portable across all TMLs. Although more than
one TML may be standardized for the ForCES protocol, all ForCES
implementations must implement the Stream Control Transmission
Protocol (SCTP) TML [<a href="./rfc5811" title=""SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol"">RFC5811</a>].
The Forwarding and Control Element Separation Applicability Statement
[<a href="./rfc6041" title=""Forwarding and Control Element Separation (ForCES) Applicability Statement"">RFC6041</a>] captures the applicable areas in which ForCES can be used.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Document Goal</span>
This document captures the experience of implementing the ForCES
protocol and model, and its main goal is to provide alternatives,
ideas, and proposals as how it can be implemented, not to tell others
how to implement it.
Also, this document mentions possible problems and potential choices
that can be made, in an attempt to help implementors develop their
own products.
Additionally, this document assumes that the reader has become
familiar with the three main ForCES RFCs: the Forwarding and Control
Element Separation Protocol [<a href="./rfc5810" title=""Forwarding and Control Element Separation (ForCES) Protocol Specification"">RFC5810</a>], the Forwarding and Control
Element Separation Forwarding Element Model [<a href="./rfc5812" title=""Forwarding and Control Element Separation (ForCES) Forwarding Element Model"">RFC5812</a>], and the SCTP-
Based Transport Mapping Layer (TML) for the Forwarding and Control
Element Separation Protocol [<a href="./rfc5811" title=""SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol"">RFC5811</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology and Conventions</span>
The terminology used in this document is the same as in the
Forwarding and Control Element Separation Protocol [<a href="./rfc5810" title=""Forwarding and Control Element Separation (ForCES) Protocol Specification"">RFC5810</a>]; some of
the definitions below are copied from that document.
Control Element (CE): A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs on how to process
packets. CEs handle functionality such as the execution of control
and signaling protocols.
<span class="grey">Haleplidis, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
Forwarding Element (FE): A logical entity that implements the ForCES
protocol. FEs use the underlying hardware to provide per-packet
processing and handling as directed/controlled by one or more CEs via
the ForCES protocol.
LFB (Logical Functional Block): The basic building block that is
operated on by the ForCES protocol. The LFB is a well-defined,
logically separable functional block that resides in an FE and is
controlled by the CE via the ForCES protocol. The LFB may reside at
the FE's data path and process packets or may be purely an FE control
or configuration entity that is operated on by the CE. Note that the
LFB is a functionally accurate abstraction of the FE's processing
capabilities but not a hardware-accurate representation of the FE
implementation.
LFB Class and LFB Instance: LFBs are categorized by LFB classes. An
LFB instance represents an LFB class (or type) existence. There may
be multiple instances of the same LFB class (or type) in an FE. An
LFB class is represented by an LFB class ID, and an LFB instance is
represented by an LFB instance ID. As a result, an LFB class ID
associated with an LFB instance ID uniquely specifies an LFB
existence.
LFB Component: Operational parameters of the LFBs that must be
visible to the CEs are conceptualized in the FE model as the LFB
components. The LFB components include, for example, flags, single
parameter arguments, complex arguments, and tables that the CE can
read and/or write via the ForCES protocol.
ForCES Protocol: While there may be multiple protocols used within
the overall ForCES architecture, the terms "ForCES protocol" and
"protocol" refer to the Fp reference points in the ForCES framework
[<a href="./rfc3746" title=""Forwarding and Control Element Separation (ForCES) Framework"">RFC3746</a>]. This protocol does not apply to CE-to-CE communication,
FE-to-FE communication, or communication between FE and CE Managers.
Basically, the ForCES protocol works in a master-slave mode in which
FEs are slaves and CEs are masters. This document defines the
specifications for this ForCES protocol.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. ForCES Architecture</span>
ForCES has undergone two successful interoperability tests, where
very few issues were caught and resolved.
This section discusses the ForCES architecture, implementation
challenges, and ways to overcome these challenges.
<span class="grey">Haleplidis, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Pre-Association Setup - Initial Configuration</span>
The initial configuration of the FE and the CE is done by the FE
Manager and the CE Manager, respectively. These entities have not as
yet been standardized.
The simplest solution is static configuration files, which play the
role of the Managers and are read by FEs and CEs.
For more dynamic solutions, however, it is expected that the Managers
will be entities that will talk to each other and exchange details
regarding the associations. Any developer can create any Manager,
but they should at least be able to exchange the details below.
From the FE Manager side:
1. FE Identifiers (FEIDs).
2. FE IP addresses, if the FEs and CEs will be communicating via
network.
3. TML. The TML that will be used. If this is omitted, then SCTP
must be chosen as default.
4. TML priority ports. If this is omitted as well, then the CE must
use the default values from the respective TML RFC.
From the CE Manager side:
1. CE Identifiers (CEIDs).
2. CE IP addresses, if the FEs and CEs will be communicating via
network.
3. TML. The TML that will be used. If this is omitted, then SCTP
must be chosen as default.
4. TML priority ports. If this is omitted as well, then the FE must
use the default values from the respective TML RFC.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. TML</span>
All ForCES implementations must support the SCTP TML. Even if
another TML will be chosen by the developer, SCTP is mandatory and
must be supported.
<span class="grey">Haleplidis, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
There are several issues that should concern a developer for the TML:
1. Security. TML must be secure according to the respective RFC.
For SCTP, you have to use IPsec.
2. Remote connection. While ForCES is meant to be used locally,
both interoperability tests have proven that ForCES can be
deployed everywhere that SCTP/IP is available. In both
interoperability tests, there were connections between Greece and
China, and the performance was very satisfactory. However, in
order for the FE and CE to work in a non-local environment, an
implementor must ensure that the SCTP-TML ports are forwarded to
the CE and/or FE if they are behind NATs; if there is a firewall,
it will allow the SCTP ports through. These were identified
during the first ForCES interoperability test and documented in
the Implementation Report for Forwarding and Control Element
Separation [<a href="./rfc6053" title=""Implementation Report for Forwarding and Control Element Separation (ForCES)"">RFC6053</a>].
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Model</span>
The ForCES model is inherently very dynamic. Using the basic atomic
data types that are specified in the model, new atomic (single
valued) and/or compound (structures and arrays) datatypes can be
built. Thus, developers are free to create their own LFBs. One
other advantage that the ForCES model provides is inheritance. New
versions of existing LFBs can be created to suit any extra developer
requirements.
The difficulty for a developer is to create an architecture that is
completely scalable so there is no need to write the same code for
new LFBs, new components, etc. Developers can just create code for
the defined atomic values, and new components can then be built based
on already written code, thus reusing it.
The model itself provides the key, which is inheritance.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Components</span>
First, a basic component needs to be created as the mother of all the
components that has the basic parameters of all the components:
o The ID of the component.
o The access rights of the component.
o If it is an optional component.
o If it is of variable size.
<span class="grey">Haleplidis, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
o Minimum data size.
o Maximum data size.
If the data size of the component is not variable, then the size is
either the minimum or the maximum size, as both should have the same
value.
Next, some basic functions are in order:
o A common constructor.
o A common destructor.
o Retrieve Component ID.
o Retrieve access right property.
o Query if it is an optional component.
o Get Full Data.
o Set Full Data.
o Get Sparse Data.
o Set Sparse Data.
o Del Full Data.
o Del Sparse Data.
o Get Property.
o Set Property.
o Get Value.
o Set Value.
o Del Value.
o Get Data.
o Clone component.
<span class="grey">Haleplidis, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
The Get/Set/Del Full Data, Get/Set/Del Sparse Data, and Get/Set
Property functions handle the respective ForCES commands and return
the respective TLV, for example, Set Full Data should return a
RESULT-TLV. The Get Value, Set Value, and Del Value functions are
called from Get Full/Sparse Data, Set Full/Sparse Data, and Del Full/
Sparse Data respectively and provide the interface to the actual
values in the hardware, separating the forces handling logic from the
interface to the actual values.
The Get Data function should return the value of the data only, not
in TLV format.
The Clone function seems out of place. This function must return a
new component that has the exact same values and attributes. This
function is useful in array components as described further below.
The only requirement is to implement the base atomic data types. Any
new atomic datatype can be built as a child of a base data type,
which will inherit all the functions and, if necessary, override
them.
The struct component can then be built. A struct component is a
component by itself but consists of a number of atomic components.
These atomic components create a static array within the struct. The
ID of each atomic component is the array's index. For a struct
component, the Clone function must create and return an exact copy of
the struct component with the same static array.
The most difficult component to be built is the array. The
difficulty lies in the actual benefit of the model: you have absolute
freedom over what you build. An array is an array of components. In
all rows, you have the exact same type of component, either a single
component or a struct. The struct can have multiple single
components or a combination of single components, structs, arrays,
and so on. So, the difficulty lies in how to create a new row, a new
component by itself. This is where the Clone function is very
useful. For the array, a mother component that can spawn new
components exactly like itself is needed. Once a Set command is
received, the mother component can spawn a new component if the
targeted row does not exist and add it into the array; with the Set
Full Data function, the value is set in the recently spawned
component, as the spawned component knows how the data is created.
In order to distinguish these spawned components from each other and
their functionality, some kind of index is required that will also
reflect how the actual data of the specific component is stored on
the hardware.
<span class="grey">Haleplidis, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
Once the basic constructors of all possible components are created,
then a developer only has to create LFB components or datatypes as a
child of one of the already-created components, and the only thing
the developer really needs to add is the three functions of Get
Value, Set Value, and Del Value of each component, which is platform
dependent. The rest stays the same.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. LFBs</span>
The same architecture in the components can be used for the LFBs,
allowing a developer to write LFB handling code only once. The
parent LFB has some basic attributes:
o The LFB Class ID.
o The LFB Instance ID.
o An Array of Components.
o An Array of Capabilities.
o An Array of Events.
Following are some common functions:
o Handle Configuration Command.
o Handle Query Command.
o Get Class ID.
o Get Instance ID.
Once these are created, each LFB can inherit all these from the
parent, and the only thing it has to do is add the components that
have already been created.
An example can be seen in Figure 1. The following code creates a
part of FEProtocolLFB:
<span class="grey">Haleplidis, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
//FEID
cui = new Component_uInt(FEPO_FEID, ACCESS_READ_ONLY, FE_id);
Components[cui->get_ComponentId()]=cui; //Add component to array list
//Current FEHB Policy Value
cub = new Component_uByte(FEPO_FEHBPolicy, ACCESS_READ_WRITE, 0);
Components[cub->get_ComponentId()]=cub; //Add component to array list
//FEIDs for BackupCEs Array
cui = new Component_uInt(0, ACCESS_READ_WRITE, 0);
ca = new Component_Array(FEPO_BackupCEs, ACCESS_READ_WRITE);
ca->AddRow(cui, 1);
ca->AddMotherComponent(cui);
Components[ca->get_ComponentId()]=ca; //Add component to array list
Figure 1: Example Code for Creating Part of FEProtocolLFB
The same concept can be applied to handling LFBs as one FE. An FE is
a collection of LFBs. Thus, all LFBs can be stored in an array based
on the LFB's class id, version, and instance. Then, what is required
is an LFBHandler that will handle the array of LFBs. A specific LFB,
for example, can be addressed using the following scheme:
LFBs[ClassID][Version][InstanceID]
Note: While an array can be used in components, capabilities, and
events, a hash table or a similar concept is better suited for
storing LFBs using the component ID as the hash key with linked lists
for collision handling, as the created array can have large gaps if
the values of LFB Class ID vary greatly.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Protocol</span>
<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>. TLVs</span>
The goal for protocol handling is to create a general and scalable
architecture that handles all protocol messages instead of something
implementation specific. There are certain difficulties that have to
be overcome first.
Since the model allows a developer to define any LFB required, the
protocol has been thus created to give the user the freedom to
configure and query any component, whatever the underlying model.
While this is a strong point for the protocol itself, one difficulty
lies with the unknown underlying model and the unlimited number of
types of messages that can be created, making creating generic code a
daunting task.
<span class="grey">Haleplidis, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
Additionally, the protocol also allows two different path approaches
to LFB components, and the CE or FE must handle both or even a mix of
them, making a generic decoding of the protocol message difficult.
Another difficulty also arises from the batching capabilities of the
protocol. You can have multiple Operations within a message; you can
select more than one LFB to command and more than one component to
manipulate.
A possible solution is again provided by inheritance. There are two
basic components in a protocol message:
1. The common header.
2. The rest of the message.
The rest of the message is divided in Type-Length-Value (TLV) units
and, in one case, Index-Length-Value (ILV) units.
The TLV hierarchy can be seen in Figure 2:
Common Header
|
+---------------+---------------+---------------+
| | | |
REDIRECT-TLV LFBselect-TLV ASResult-TLV ASTreason-TLV
|
|
OPER-TLV
|
|
PATH-DATA-TLV ---> Optional KEYINFO-TLV
|
+-------------+-------------+-------------+
| | | |
SPARSEDATA-TLV RESULT-TLV FULLDATA-TLV PATH-DATA-TLV
Figure 2: ForCES TLV Hierarchy
The above figure shows only the basic hierarchical level of TLVs and
does not show batching. Also, this figure does not show the
recursion that can occur at the last level of the hierarchy. The
figure shows one kind of recursion with a PATH-DATA-TLV within a
PATH-DATA-TLV. A FULLDATA-TLV can be within a FULLDATA-TLV and a
SPARSEDATA-TLV. The possible combination of TLVs are described in
detail in the Forwarding and Control Element Separation Protocol
[<a href="./rfc5810" title=""Forwarding and Control Element Separation (ForCES) Protocol Specification"">RFC5810</a>] as well as the data-packing rules.
<span class="grey">Haleplidis, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
A TLV's main attributes are:
o Type.
o Length.
o Data.
o An array of TLVs.
The array of TLVs is the next hierarchical level of TLVs nested in
this TLV.
A TLV's common function could be:
o A basic constructor.
o A constructor using data from the wire.
o Add a new TLV for next level.
o Get the next TLV of next level.
o Get a specific TLV of next level.
o Replace a TLV of next level.
o Get the Data.
o Get the Length.
o Set the Data.
o Set the Length.
o Set the Type.
o Serialize the header.
o Serialize the TLV to be written on the wire.
All TLVs inherit these functions and attributes and either override
them or create new where it is required.
<span class="grey">Haleplidis, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Message Deserialization</span>
Following is an algorithm for deserializing any protocol message:
1. Get the message header.
2. Read the length.
3. Check the message type to understand what kind of message this
is.
4. If the length is larger than the message header, then there is
data for this message.
5. A check can be made here regarding the message type and the
length of the message.
If the message is a Query or Config type, then there are LFBselect-
TLVs for this level:
1. Read the next 2 shorts(type-length). If the type is an
LFBselect-TLV, then the message is valid.
2. Read the necessary length for this LFBselect-TLV, and create the
LFBselect-TLV from the data of the wire.
3. Add this LFBselect-TLV to the main header array of LFBselect-
TLVs.
4. Repeat all above steps until the rest of the message has
finished.
The next level of TLVs is OPER-TLVs.
1. Read the next 2 shorts(type-length). If the type is an OPER-TLV,
then the message is valid.
2. Read the necessary length for this OPER-TLV, and create the OPER-
TLV from the data of the wire.
3. Add this OPER-TLV to the LFBselect-TLV array of TLVs.
4. Do this until the rest of the LFBselect-TLV has finished.
The next level of TLVs is PATH-DATA-TLVs.
1. Read the next 2 shorts(type-length). If the type is a PATH-DATA-
TLV, then the message is valid.
<span class="grey">Haleplidis, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
2. Read the necessary length for this PATH-DATA-TLV, and create the
PATH-DATA-TLV from the data of the wire.
3. Add this PATH-DATA-TLV to the OPER-TLV's array of TLVs.
4. Do this until the rest of the OPER-TLV is finished.
Here it gets interesting, as the next level of PATH-DATA-TLVs can be
one of the following:
o PATH-DATA-TLVs.
o FULLDATA-TLV.
o SPARSEDATA-TLV.
o RESULT-TLV.
The solution to this difficulty is recursion. If the next TLV is a
PATH-DATA-TLV, then the PATH-DATA-TLV that is created uses the same
kind of deserialization until it reaches a FULLDATA-TLV or
SPARSEDATA-TLV. There can be only one FULLDATA-TLV or SPARSEDATA-TLV
within a PATH-DATA-TLV.
1. Read the next 2 shorts(type-length).
2. If the Type is a PATH-DATA-TLV, then repeat the previous
algorithm but add the PATH-DATA-TLV to this PATH-DATA-TLV's array
of TLVs.
3. Do this until the rest of the PATH-DATA-TLV is finished.
4. If the Type is a FULLDATA-TLV, then create the FULLDATA-TLV from
the message and add this to the PATH-DATA-TLV's array of TLVs.
5. If the Type is a SPARSEDATA-TLV, then create the SPARSEDATA-TLV
from the message and add this to the PATH-DATA-TLV's array of
TLVs.
6. If the Type is a RESULT-TLV, then create the RESULT-TLV from the
message and add this to the PATH-DATA-TLV's array of TLVs.
If the message is a Query, it must not have any kind of data inside
the PATH-DATA-TLV.
If the message is a Query Response, then it must have either a
RESULT-TLV or a FULLDATA-TLV.
<span class="grey">Haleplidis, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
If the message is a Config, it must contain either a FULLDATA-TLV or
a SPARSEDATA-TLV.
If the message is a Config Response, it must contain a RESULT-TLV.
More details regarding message validation can be read in <a href="#section-7">Section 7</a> of
the Forwarding and Control Element Separation Protocol [<a href="./rfc5810" title=""Forwarding and Control Element Separation (ForCES) Protocol Specification"">RFC5810</a>].
Note: When deserializing, implementors must take care to ignore
padding of TLVs as all must be 32-bit aligned. The length value in
TLVs includes the Type and Length (4 bytes) but does not include
padding.
<span class="h4"><a class="selflink" id="section-3.4.3" href="#section-3.4.3">3.4.3</a>. Message Serialization</span>
The same concept can be applied in the message creation process.
Having the TLVs ready, a developer can go bottom up. All that is
required is the serialization function that will transform the TLV
into bytes ready to be transferred on the network.
For example, for the creation of a simple query from the CE to the
FE, all the PATH-DATA-TLVs are created. Then they will be serialized
and inserted into an OPER-TLV, which in turn will be serialized and
inserted into an LFBselect-TLV. The LFBselect-TLV will then be
serialized and entered into the Common Header, which will be passed
to the TML to be transported to the FE.
Having an array of TLVs inside a TLV that is next in the TLV
hierarchy allows the developer to insert any number of next-level
TLVs, thus creating any kind of message.
Note: When the TLV is serialized to be written on the wire,
implementors must take care to include padding to TLVs as all must be
32-bit aligned.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Development Platforms</span>
Any development platform that can support the SCTP TML and the TML of
the developer's choosing is available for use.
Figure 3 provides an initial survey of SCTP support for C/C++ and
Java at the present time.
<span class="grey">Haleplidis, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
/-------------+-------------+-------------+-------------\
|\ Platform | | | |
| ----------\ | Windows | Linux | Solaris |
| Language \| | | |
+-------------+-------------+-------------+-------------+
| | | | |
| C/C++ | Supported | Supported | Supported |
| | | | |
+-------------+-------------+-------------+-------------+
| | Limited | | |
| Java | Third Party | Supported | Supported |
| | Not from SUN| | |
\-------------+-------------+-------------+-------------/
Figure 3: SCTP Support on Operating Systems
A developer should be aware of some limitations regarding Java
implementations.
Java inherently does not support unsigned types. A workaround can be
found in the creation of classes that do the translation of unsigned
types to Java types. The problem is that the unsigned long cannot be
used as-is in the Java platform. The proposed set of classes can be
found in [<a href="#ref-JavaUnsignedTypes">JavaUnsignedTypes</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgements</span>
The authors would like to thank Adrian Farrel for sponsoring this
document and Jamal Hadi Salim for discussions that made this document
better.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
Developers of ForCES FEs and CEs must take the Security
Considerations of the Forwarding and Control Element Separation
Framework [<a href="./rfc3746" title=""Forwarding and Control Element Separation (ForCES) Framework"">RFC3746</a>] and the Forwarding and Control Element Separation
Protocol [<a href="./rfc5810" title=""Forwarding and Control Element Separation (ForCES) Protocol Specification"">RFC5810</a>] into account.
Also, as specified in the Security Considerations section of the
SCTP-Based Transport Mapping Layer (TML) for the Forwarding and
Control Element Separation Protocol [<a href="./rfc5811" title=""SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol"">RFC5811</a>], transport-level
security has to be ensured by IPsec.
<span class="grey">Haleplidis, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-RFC5810">RFC5810</a>] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol
Specification", <a href="./rfc5810">RFC 5810</a>, March 2010.
[<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>, March 2010.
[<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>, March 2010.
[<a id="ref-RFC6041">RFC6041</a>] Crouch, A., Khosravi, H., Doria, A., Wang, X., and K.
Ogawa, "Forwarding and Control Element Separation (ForCES)
Applicability Statement", <a href="./rfc6041">RFC 6041</a>, October 2010.
[<a id="ref-RFC6053">RFC6053</a>] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim,
"Implementation Report for Forwarding and Control Element
Separation (ForCES)", <a href="./rfc6053">RFC 6053</a>, November 2010.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-JavaUnsignedTypes">JavaUnsignedTypes</a>]
"Java Unsigned Types",
<<a href="http://nam.ece.upatras.gr/index.php?q=node/44">http://nam.ece.upatras.gr/index.php?q=node/44</a>>.
[<a id="ref-RFC3654">RFC3654</a>] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", <a href="./rfc3654">RFC 3654</a>, November 2003.
[<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>, April 2004.
<span class="grey">Haleplidis, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6369">RFC 6369</a> ForCES Implementation Experience September 2011</span>
Authors' Addresses
Evangelos Haleplidis
University of Patras
Department of Electrical & Computer Engineering
Patras 26500
Greece
EMail: ehalep@ece.upatras.gr
Odysseas Koufopavlou
University of Patras
Department of Electrical & Computer Engineering
Patras 26500
Greece
EMail: odysseas@ece.upatras.gr
Spyros Denazis
University of Patras
Department of Electrical & Computer Engineering
Patras 26500
Greece
EMail: sdena@upatras.gr
Haleplidis, et al. Informational [Page 18]
</pre>
|
