idnits 2.17.1
draft-ietf-forces-model-extension-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 13 instances of too long lines in the document, the longest
one being 7 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (November 16, 2013) is 3811 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'N' is mentioned on line 627, but not defined
== Missing Reference: '1-9' is mentioned on line 872, but not defined
== Missing Reference: '0-9' is mentioned on line 872, but not defined
== Outdated reference: A later version (-10) exists of
draft-ietf-forces-ceha-08
Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force E. Haleplidis
3 Internet-Draft University of Patras
4 Intended status: Standards Track November 16, 2013
5 Expires: May 20, 2014
7 ForCES Model Extension
8 draft-ietf-forces-model-extension-01
10 Abstract
12 Forwarding and Control Element Separation (ForCES) defines an
13 architectural framework and associated protocols to standardize
14 information exchange between the control plane and the forwarding
15 plane in a ForCES Network Element (ForCES NE). RFC5812 has defined
16 the ForCES Model provides a formal way to represent the capabilities,
17 state, and configuration of forwarding elements within the context of
18 the ForCES protocol, so that control elements (CEs) can control the
19 FEs accordingly. More specifically, the model describes the logical
20 functions that are present in an FE, what capabilities these
21 functions support, and how these functions are or can be
22 interconnected.
24 RFC5812 has been around for two years and experience in its use has
25 shown room for small extensions without a need to alter the protocol
26 while retaining backward compatibility with older xml libraries.
27 This document extends the model to allow complex datatypes for
28 metadata, optional default values for datatypes and optional access
29 types for structures. The document also introduces two new features
30 a new event condition BecomesEqualTo and LFB properties.
32 Status of This Memo
34 This Internet-Draft is submitted in full conformance with the
35 provisions of BCP 78 and BCP 79.
37 Internet-Drafts are working documents of the Internet Engineering
38 Task Force (IETF). Note that other groups may also distribute
39 working documents as Internet-Drafts. The list of current Internet-
40 Drafts is at http://datatracker.ietf.org/drafts/current/.
42 Internet-Drafts are draft documents valid for a maximum of six months
43 and may be updated, replaced, or obsoleted by other documents at any
44 time. It is inappropriate to use Internet-Drafts as reference
45 material or to cite them other than as "work in progress."
47 This Internet-Draft will expire on May 20, 2014.
49 Copyright Notice
51 Copyright (c) 2013 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
54 This document is subject to BCP 78 and the IETF Trust's Legal
55 Provisions Relating to IETF Documents
56 (http://trustee.ietf.org/license-info) in effect on the date of
57 publication of this document. Please review these documents
58 carefully, as they describe your rights and restrictions with respect
59 to this document. Code Components extracted from this document must
60 include Simplified BSD License text as described in Section 4.e of
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
64 Table of Contents
66 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 2
67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
68 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2
69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
70 3. ForCES Model Extension proposal . . . . . . . . . . . . . . . 4
71 3.1. Complex datatypes for Metadata . . . . . . . . . . . . . 4
72 3.2. Optional Default Value for Datatypes . . . . . . . . . . 6
73 3.3. Optional Access Type for Structs . . . . . . . . . . . . 7
74 3.4. New Event Condition: BecomesEqualTo . . . . . . . . . . . 8
75 3.5. LFB Properties . . . . . . . . . . . . . . . . . . . . . 9
76 3.6. Enhancing XML Validation . . . . . . . . . . . . . . . . 11
77 4. XML Extension Schema for LFB Class Library Documents . . . . 12
78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
82 8.1. Normative References . . . . . . . . . . . . . . . . . . 25
83 8.2. Informative References . . . . . . . . . . . . . . . . . 25
84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
86 1. Terminology and Conventions
88 1.1. Requirements Language
90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
92 document are to be interpreted as described in [RFC2119].
94 1.2. Definitions
95 This document follows the terminology defined by the ForCES Model in
96 [RFC5812]. The required definitions are repeated below for clarity.
98 FE Model - The FE model is designed to model the logical
99 processing functions of an FE. The FE model proposed in this
100 document includes three components; the LFB modeling of individual
101 Logical Functional Block (LFB model), the logical interconnection
102 between LFBs (LFB topology), and the FE-level attributes,
103 including FE capabilities. The FE model provides the basis to
104 define the information elements exchanged between the CE and the
105 FE in the ForCES protocol [RFC5810].
107 LFB (Logical Functional Block) Class (or type) - A template that
108 represents a fine-grained, logically separable aspect of FE
109 processing. Most LFBs relate to packet processing in the data
110 path. LFB classes are the basic building blocks of the FE model.
112 LFB Instance - As a packet flows through an FE along a data path,
113 it flows through one or multiple LFB instances, where each LFB is
114 an instance of a specific LFB class. Multiple instances of the
115 same LFB class can be present in an FE's data path. Note that we
116 often refer to LFBs without distinguishing between an LFB class
117 and LFB instance when we believe the implied reference is obvious
118 for the given context.
120 LFB Model - The LFB model describes the content and structures in
121 an LFB, plus the associated data definition. XML is used to
122 provide a formal definition of the necessary structures for the
123 modeling. Four types of information are defined in the LFB model.
124 The core part of the LFB model is the LFB class definitions; the
125 other three types of information define constructs associated with
126 and used by the class definition. These are reusable data types,
127 supported frame (packet) formats, and metadata.
129 Element - Element is generally used in this document in accordance
130 with the XML usage of the term. It refers to an XML tagged part
131 of an XML document. For a precise definition, please see the full
132 set of XML specifications from the W3C. This term is included in
133 this list for completeness because the ForCES formal model uses
134 XML.
136 Attribute - Attribute is used in the ForCES formal modeling in
137 accordance with standard XML usage of the term, i.e., to provide
138 attribute information included in an XML tag.
140 LFB Metadata - Metadata is used to communicate per-packet state
141 from one LFB to another, but is not sent across the network. The
142 FE model defines how such metadata is identified, produced, and
143 consumed by the LFBs, but not how the per-packet state is
144 implemented within actual hardware. Metadata is sent between the
145 FE and the CE on redirect packets.
147 ForCES Component - A ForCES Component is a well-defined, uniquely
148 identifiable and addressable ForCES model building block. A
149 component has a 32-bit ID, name, type, and an optional synopsis
150 description. These are often referred to simply as components.
151 LFB Component - An LFB component is a ForCES component that
152 defines the Operational parameters of the LFBs that must be
153 visible to the CEs.
155 LFB Class Library - The LFB class library is a set of LFB classes
156 that has been identified as the most common functions found in
157 most FEs and hence should be defined first by the ForCES Working
158 Group.
160 2. Introduction
162 The ForCES Model [RFC5812] presents a formal way to define FEs
163 Logical Function Blocks (LFBs) using XML. [RFC5812] has been
164 published a more than two years and current experience in its use has
165 demonstrated need for adding new and changing existing modeling
166 concepts.
168 Specifically this document extends the ForCES Model to allow complex
169 datatypes for metadata, optional default values for datatypes and
170 optional access types for structures. Additionally the document
171 introduces two new features a new event condition BecomesEqualTo and
172 LFB properties.
174 These extensions are an addendum to the ForCES model [RFC5812] and do
175 not require any changes on the ForCES protocol [RFC5810] as they are
176 simply changes of the schema definition. Additionally backward
177 compatibility is ensured as xml libraries produced with the earlier
178 schema are still valid with the new one.
180 3. ForCES Model Extension proposal
182 3.1. Complex datatypes for Metadata
184 Section 4.6. (Element for Metadata Definitions) in the ForCES Model
185 [RFC5812] limits the datatype use in metadata to only atomic types.
186 Figure 1 shows the xml schema excerpt where ony typeRef and atomic
187 are allowed for a metadata definition.
189 However there are cases where complex metadata are used in the
190 datapath, for example two simple use cases can be seen in the
191 OpenFlow switch 1.1 [OpenFlowSpec1.1] and beyond:
193 1. The Action Set metadata follows a packet inside the Flow Tables.
194 The Action Set metadata is an array of actions to be performed at
195 the end of the pipeline.
197 2. When a packet is received from a controller it may be accompanied
198 by a list of actions to be performed on it prior to be sent on
199 the flow table pipeline which is also an array.
201 With this extension (Figure 2), complex data types are also allowed,
202 specifically structs and arrays as metadata. The key declarations
203 are required to check for validity of content keys in arrays and
204 componentIDs in structs.
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
225 Figure 1: Initial MetadataDefType Definition in the schema
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
258 Figure 2: New MetadataDefType Definition for the schema
260 3.2. Optional Default Value for Datatypes
262 In the original schema, default values can only be defined for
263 datatypes defined inside LFB components and not inside structures or
264 arrays. Therefore default values of datatypes that are constantly
265 being reused, e.g. counters with default value of 0, have to be
266 constantly respecified. Additionally, datatypes inside complex
267 datatypes cannot be defined with a default value, e.g. a counter
268 inside a struct that has a default value of 0.
270 This extension allows optionally to add default values to atomic and
271 typeref types, whether they are as simple or complex datatypes. A
272 simple use case would be to have a struct component where one of the
273 components is a counter which the default value would be zero.
275 This extension alters the definition of the typeDeclarationGroup in
276 the xml schema from Figure 3 to Figure 4 to allow default values to
277 TypeRef.
279
281 Figure 3: Initial Excerpt of typeDeclarationGroup Defintion in the
282 schema
284
285
286
288
290 Figure 4: New Excerpt of typeDeclarationGroup Definition in the
291 schema
293 Additionally it appends to the declaration of the AtomicType this xml
294 (Figure 5) to allow default values to Atomic datatypes.
296
298 Figure 5: Appending xml in of AtomicType Definition in the schema
300 3.3. Optional Access Type for Structs
302 In the original schema, the access type can be only be defined on
303 components of LFB and not on components in structs or arrays.
304 However when it's a struct datatype it is not possible to fine-tune
305 access type per component in the struct. A simple use case would be
306 to have a read-write struct component where one of the components is
307 a counter where the access-type could be read-reset or read-only,
308 e.g. a read-reset or a read-only counter inside a struct.
310 With this extension is it allowed to define the access type for a
311 struct component either in the datatype definitions or in the LFB
312 component definitions.
314 When the optional access type for a struct component is defined it
315 MUST override the access type of the struct. If by accident an
316 access type for a component in a capability is defined, the access
317 type MUST NOT be taken into account and MUST always be considered as
318 read-only.
320 This extension alters the definition of the struct in the xml schema
321 from Figure 6 to Figure 7.
323
324
325
327
328
329
330
331
332
333
334
335
336
338
339
340
341
343 Figure 6: Initial xml for the struct definition in the schema
345
346
347
349
350
351
352
353
354
355
356
357
358
360
361
362
363
364
366
367
368
369
371 Figure 7: New xml for the struct definition in the schema
373 3.4. New Event Condition: BecomesEqualTo
375 This extensions adds one more event condition in the model schema,
376 that of BecomesEqualTo. The difference between Greater Than and Less
377 Than, is that when the value is exactly that of the BecomesEqualTo,
378 the event is triggered. This event condition is particular useful
379 when there is a need to monitor one or more states of an LFB or the
380 FE. For example in the CEHA [I-D.ietf-forces-ceha] document it may
381 be useful for the master CE to know which backup CEs have just become
382 associated in order to connect to them and begin synchronizing the
383 state of the FE. The master CE could always poll for such
384 information but getting such an event will speed up the process and
385 the event may be useful in other cases as well for monitoring state.
387 The event MUST be triggered only when the value of the targeted
388 component becomes equal to the event condition value and MUST NOT
389 generate events while the targeted component's value remains equal to
390 the event condition's value.
392 The BecomesEqualTo is appended to the schema as follows:
394
397 Figure 8: New Excerpt of BecomesEqualTo event condition definition in
398 the schema
400 It can become useful for the CE to be notified when the state has
401 changed once the BecomesEqualTo event has been triggered, e.g. the CE
402 may need to know when a backup CE has lost association. Such an
403 event can be generated either by defining a second event on the same
404 component, namely an Event Changed, or by simply reusing
405 BecomesEqualTo and use event properties, in particular event
406 hysteresis. We append the following definition for the event
407 hysteresis defined in section 4.8.5.2 in [RFC5812], with V being the
408 hysteresis value:
410 o For an condition, after the last
411 notification a new notification MUST be
412 generated only one time once the value has changed by +/- V.
414 For example using the value of 1 for V, will in effect create a
415 singular event that will notify the CE that the value has changed by
416 at least 1.
418 A developer of a CE must also take into account to use count or time
419 filtering to avoid being overrun by messages, e.g. in the case of
420 rapid state changes.
422 3.5. LFB Properties
423 The current model definition specifies properties for components of
424 LFBs. Experience however has proven valuable at least for debug
425 reasons, to have statistics per LFB instance to monitor sent/received
426 messages and errors for communication between CE and FE. These
427 properties are read-only.
429 In order to avoid ambiguity on protocol path semantics, this document
430 reserves LFB component 0 for LFB properties. This reservation is
431 backwards compatible as no LFB definition uses LFB component 0. Any
432 command with a path starting from LFB component 0 refers to LFB
433 properties. The following change in the xml schema disallows usage
434 of LFB component 0:
436
439 Figure 9: Initial xml for LFB Component IDs
441
442
443
444
445
446
447
448
449
451 Figure 10: New xml for the disallowing usage of 0 as LFB Component
453 The following datatype definitions are to be used as properties for
454 LFB instances.
456
457 LFBProperties
458 LFB Properties definition
459
460
461 PacketsSentToCE
462 Packets sent to CE
463 uint32
464
465
466 SentErrorPacketsToCE
467 Error Packets sent to CE
468 uint32
469
470
471 BytesSentToCE
472 Bytes sent to CE
473 uint32
474
475
476 SentErrorBytesToCE
477 Error Bytes sent to CE
478 uint32
479
480
481 PacketsReceivedFromCE
482 Packets received from CE
483 uint32
484
485
486 ReceivedErrorPacketsFromCE
487 Error Packets received from CE
488 uint32
489
490
491 BytesReceivedFromCE
492 Bytesreceived from CE
493 uint32
494
495
496 ReceivedErrorBytesFromCE
497 Error Bytes received from CE
498 uint32
499
500
501
503 Properties for LFB instances
505 3.6. Enhancing XML Validation
507 As specified earlier this is not an extension but an enhancement of
508 the schema to provide additional validation rules. This includes
509 adding new key declarations to provide uniqueness as defined by the
510 ForCES Model [RFC5812]. Such validations work only on within the
511 same xml file.
513 The following validation rules have been appended in the original
514 schema in [RFC5812]:
516 1. Each metadata ID must be unique.
518 2. LFB Class IDs must be unique.
520 3. Component ID, Capability ID and Event Base ID must be unique per
521 LFB.
523 4. Event IDs must be unique per LFB.
525 5. Special Values in Atomic datatypes must be unique per atomic
526 datatype.
528 4. XML Extension Schema for LFB Class Library Documents
530
531
536
537
538 Schema for Defining LFB Classes and associated types
539 (frames, data types for LFB attributes, and metadata).
540
541
542
543
544
545
546
547
548
549
551
553
555
557
559
560
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
593
594
595
596
597
598
599
600
601
603
604
605
606
607
608
609
610
611
612
613
614
616
617
619
620
621
622
623
624
625
628
629
630
631
632
633
634
635
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
675
677
678
679
680
681
682
683
684
685
687
688
689
690
691
692
693
694
696
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
720
721
722
724
725
727
728
729
730
731
732
733
734
735
736
737
738
740
742
743
744
745
747
748
749
750
751
752
754
755
756
757
759
760
761
762
763
765
766
767
768
769
770
771
772
773
774
775
776
777
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
795
796
797
798
799
800
801
802
803
804
805
807
808
809
810
811
812
813
814
815
816
818
820
822
824
826
828
830
831
833
834
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
856
857
858
859
860
861
862
865
866
867
868
869
870
871
872
873
874
875
876
877
879
880
881
882
883
884
885
886
887
888
890
891
892
893
894
895
896
898
900
901
902
903
904
905
906
907
908
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
935
936
937
938
939
940
941
942
944
945
946
947
948
949
951
953
954
955
956
957
958
959
960
961
963
964
965
966
967
968
969
971
973
974
975
976
977
978
979
981
983
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1029
1030
1031
1033
1034
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1072
1073
1074
1075
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1090
1091
1093
1095
1096
1099
1100
1101
1102
1104
1105
1106
1107
1109
1111
1113
1115
1117
1118
1120
1121
1122
1123
1124
1125
1126
1127
1129
1131
1133
1134
1135
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146 OpenFlow XML Library
1148 5. Acknowledgements
1150 The author would like to acknowledge Joel Halpern, Jamal Hadi and
1151 Dave Hood for their comments and discussion that helped shape this
1152 document in a better way.
1154 6. IANA Considerations
1156 This specification requests that LFB Component ID 0 to be reserved.
1158 7. Security Considerations
1160 The security considerations that have been described in the ForCES
1161 Model RFC [RFC5812] apply to this document as well.
1163 8. References
1165 8.1. Normative References
1167 [I-D.ietf-forces-ceha]
1168 Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES
1169 Intra-NE High Availability", draft-ietf-forces-ceha-08
1170 (work in progress), October 2013.
1172 [OpenFlowSpec1.1]
1173 http://www.OpenFlow.org/, "The OpenFlow 1.1
1174 Specification.", , .
1177 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
1178 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
1179 Control Element Separation (ForCES) Protocol
1180 Specification", RFC 5810, March 2010.
1182 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
1183 Element Separation (ForCES) Forwarding Element Model", RFC
1184 5812, March 2010.
1186 8.2. Informative References
1188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1189 Requirement Levels", BCP 14, RFC 2119, March 1997.
1191 Author's Address
1192 Evangelos Haleplidis
1193 University of Patras
1194 Department of Electrical and Computer Engineering
1195 Patras 26500
1196 Greece
1198 Email: ehalep@ece.upatras.gr