idnits 2.17.1
draft-ietf-forces-model-extension-04.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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC5812, updated by this document, for
RFC5378 checks: 2003-08-11)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (August 21, 2014) is 3536 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 728, but not defined
== Missing Reference: '1-9' is mentioned on line 981, but not defined
== Missing Reference: '0-9' is mentioned on line 981, but not defined
Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--).
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 Updates: 5812 (if approved) August 21, 2014
5 Intended status: Standards Track
6 Expires: February 22, 2015
8 ForCES Model Extension
9 draft-ietf-forces-model-extension-04
11 Abstract
13 Forwarding and Control Element Separation (ForCES) defines an
14 architectural framework and associated protocols to standardize
15 information exchange between the control plane and the forwarding
16 plane in a ForCES Network Element (ForCES NE). RFC5812 has defined
17 the ForCES Model that provides a formal way to represent the
18 capabilities, state, and configuration of forwarding elements within
19 the context of the ForCES protocol, so that control elements (CEs)
20 can control the FEs accordingly. More specifically, the model
21 describes the logical functions that are present in a forwarding
22 element (FE), what capabilities these functions support, and how
23 these functions are or can be interconnected.
25 RFC5812 has been around for two years and experience in its use has
26 shown room for small extensions without a need to alter the protocol
27 while retaining backward compatibility with older xml libraries.
28 This document updates RFC5812 and extends the model to allow complex
29 datatypes for metadata, optional default values for datatypes,
30 optional access types for structures and fixes an issue with Logical
31 Functional Block (LFB) inheritance. The document also introduces two
32 new features a new event condition BecomesEqualTo and LFB properties.
34 Status of This Memo
36 This Internet-Draft is submitted in full conformance with the
37 provisions of BCP 78 and BCP 79.
39 Internet-Drafts are working documents of the Internet Engineering
40 Task Force (IETF). Note that other groups may also distribute
41 working documents as Internet-Drafts. The list of current Internet-
42 Drafts is at http://datatracker.ietf.org/drafts/current/.
44 Internet-Drafts are draft documents valid for a maximum of six months
45 and may be updated, replaced, or obsoleted by other documents at any
46 time. It is inappropriate to use Internet-Drafts as reference
47 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on February 22, 2015.
50 Copyright Notice
52 Copyright (c) 2014 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (http://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
69 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
70 2. ForCES Model Extensions . . . . . . . . . . . . . . . . . . . 4
71 2.1. Complex datatypes for Metadata . . . . . . . . . . . . . 4
72 2.2. Optional Default Value for Datatypes . . . . . . . . . . 5
73 2.3. Optional Access Type for Structs . . . . . . . . . . . . 8
74 2.4. New Event Condition: BecomesEqualTo . . . . . . . . . . . 11
75 2.5. LFB Properties . . . . . . . . . . . . . . . . . . . . . 12
76 2.6. LFB class inheritance . . . . . . . . . . . . . . . . . . 14
77 2.7. Enhancing XML Validation . . . . . . . . . . . . . . . . 15
78 3. XML Extension Schema for LFB Class Library Documents . . . . 15
79 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
83 7.1. Normative References . . . . . . . . . . . . . . . . . . 29
84 7.2. Informative References . . . . . . . . . . . . . . . . . 30
85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
87 1. Introduction
89 The ForCES Model [RFC5812] presents a formal way to define Forwarding
90 Elements (FE) Logical Function Blocks (LFBs) using the eXtensible
91 Markup Language (XML). [RFC5812] has been published a more than two
92 years and current experience in its use has demonstrated need for
93 adding new and changing existing modeling concepts.
95 Specifically this document updates the ForCES Model [RFC5812] to
96 allow complex datatypes for metadata (Section 2.1), optional default
97 values for datatypes (Section 2.2), optional access types for
98 structures (Section 2.3) and fixes an issue with LFB class
99 inheritance (Section 2.6). Additionally the document introduces two
100 new features, a new event condition BecomesEqualTo (Section 2.4) and
101 LFB properties (Section 2.5).
103 These extensions are an update to the ForCES model [RFC5812] and do
104 not require any changes on the ForCES protocol [RFC5810] as they are
105 simply changes of the schema definition. Additionally backward
106 compatibility is ensured as XML libraries produced with the earlier
107 schema are still valid with the new one. In order for XML libraries
108 produced by the new schema to be compatible with existing ForCES
109 implementations, the XML Libraries MUST NOT include any of the
110 features described in this document, else the old implementation will
111 be unable to parse the XML library.
113 1.1. Requirements Language
115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
117 document are to be interpreted as described in [RFC2119].
119 1.2. Definitions
121 This document uses the terminology defined in the ForCES Model in
122 [RFC5812]. In particular, the reader is expected to be familiar with
123 the following terms:
125 FE Model
127 LFB (Logical Functional Block) Class (or type)
129 LFB Instance
131 LFB Model
133 Element
135 Attribute
137 LFB Metadata
139 ForCES Component
141 LFB Class Library
143 2. ForCES Model Extensions
145 2.1. Complex datatypes for Metadata
147 Section 4.6. (Element for Metadata Definitions) in the ForCES Model
148 [RFC5812] limits the datatype use in metadata to only atomic types.
149 Figure 1 shows the xml schema excerpt where ony typeRef and atomic
150 are allowed for a metadata definition.
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
171 Figure 1: Initial MetadataDefType Definition in the schema
173 However there are cases where complex metadata are used in the
174 datapath, for example two simple use cases can be seen in the
175 OpenFlow 1.1 specification [OpenFlowSpec1.1] and beyond:
177 1. The Action Set metadata is an array of actions descriptors, which
178 traverses the processing pipeline along with the packet data.
180 2. When a packet is received from a controller it may be accompanied
181 by a list of actions, as metadata, to be performed on it prior to
182 being sent on the processing pipeline. This list of actions is
183 also an array.
185 With this extension (Figure 2), complex data types are also allowed,
186 specifically structs and arrays as metadata. The key declarations
187 are required to check for validity of content keys in arrays and
188 componentIDs in structs.
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
221 Figure 2: New MetadataDefType Definition for the schema
223 2.2. Optional Default Value for Datatypes
225 In the original schema, default values can only be defined for
226 datatypes defined inside LFB components and not inside structures or
227 arrays. Therefore default values of datatypes that are constantly
228 being reused, e.g. counters with default value of 0, have to be
229 constantly respecified. Additionally, datatypes inside complex
230 datatypes cannot be defined with a default value, e.g. a counter
231 inside a struct that has a default value of 0.
233 This extension allows the option to add default values to atomic and
234 typeref types, whether they are as simple or complex datatypes. A
235 simple use case would be to have a struct component where one of the
236 components is a counter which the default value would be zero.
238 This extension alters the definition of the typeDeclarationGroup in
239 the XML schema from Figure 3 to Figure 4 to allow default values to
240 TypeRef.
242
244 Figure 3: Initial Excerpt of typeDeclarationGroup Definition in the
245 schema
247
248
249
251
253 Figure 4: New Excerpt of typeDeclarationGroup Definition in the
254 schema
256 Additionally this document appends to the initial declaration of the
257 AtomicType, Figure 5, an optional defaultValue, Figure 6, to allow
258 default values to Atomic datatypes. Note that both declarations
259 include the new special value validation described in Section 2.7
261
262
263
264
266
268
269
270
271
272
273
274
275
277 Figure 5: Initial Excerpt of AtomicType Definition in the schema
279
280
281
282
284
286
287
288
289
290
291
292
293
294
296
297
299 Figure 6: New Excerpt of AtomicType Definition in the schema
301 Examples of using default values is depicted in Figure 7.
303
304 Counter Values
305 Example default values in struct
306
307
308 GoodPacketCoutner
309 A counter for good packets
310 uint32
311 0
312
313
314 BadPacketCoutner
315 A counter for bad packets
316 uint32
317 0
318
319
320
322 Figure 7: Example of optional default values
324 2.3. Optional Access Type for Structs
326 In the original schema, the access type can only be defined on
327 components of an LFB and not on components within structs or arrays.
328 That means that when it is a struct datatype it is not possible to
329 fine-tune access type per component within the struct. A simple use
330 case would be to have a read-write struct component where one of the
331 components is a counter where the access-type could be read-reset or
332 read-only, e.g. a read-reset or a read-only counter inside a struct.
334 This extension allows the definition of the access type for a struct
335 component either in the datatype definitions or in the LFB component
336 definitions.
338 When optional access type for components within a struct are defined,
339 these components's access type MUST override the access type of the
340 struct. For example if a struct has an access type of read-write but
341 has a component that is a read-only counter, the counter's access
342 type MUST be read-only.
344 The access type for a component in a capability is always read-only
345 per [RFC5812]. If an access type is provided for a component in a
346 capability, the access type MUST be ignored. Similarly if an access
347 type is provided for a struct in a metadata the access type MUST be
348 ignored.
350 This extension alters the definition of the struct in the xml schema
351 from Figure 8 to Figure 9.
353
354
355
357
358
359
360
361
362
363
364
365
366
368
369
370
371
373 Figure 8: Initial xml for the struct definition in the schema
374
375
376
378
379
380
381
382
383
384
385
386
387
389
390
391
392
393
395
396
397
398
400 Figure 9: New xml for the struct definition in the schema
402 An example of using optional access types for structs can be depicted
403 in Figure 10
404
405 PacketFlows
406 Packet Flows, match and counter
407
408
409 FlowMatch
410 Flow Match
411 MatchType
412
413
414 MatchCounter
415 Packets matching the flow match
416 uint32
417 0
418
419
420
422 Figure 10: Example of optional access types for struct
424 2.4. New Event Condition: BecomesEqualTo
426 This extensions adds one more event condition in the model schema,
427 that of BecomesEqualTo. The difference between Greater Than and Less
428 Than, is that when the value becomes exactly that of the
429 BecomesEqualTo, the event is triggered. This event condition is
430 particularly useful when there is a need to monitor one or more
431 states of an LFB or the FE. For example in the CE High Availability
432 (CEHA) [RFC7121] RFC it may be useful for the master CE to know which
433 backup CEs have just become associated in order to connect to them
434 and begin synchronizing the state of the FE. The master CE could
435 always poll for such information but getting such an event will speed
436 up the process and the event may be useful in other cases as well for
437 monitoring state.
439 The event MUST be triggered only when the value of the targeted
440 component becomes equal to the event condition value.
441 Implementations MUST NOT generate subsequent events while the
442 targeted component's value remains equal to the event condition's
443 value.
445 The BecomesEqualTo is appended to the schema as follows:
447
450 Figure 11: New Excerpt of BecomesEqualTo event condition definition
451 in the schema
453 It can become useful for the CE to be notified when the state has
454 changed once the BecomesEqualTo event has been triggered, e.g. the CE
455 may need to know when a backup CE has lost association. Such an
456 event can be generated either by defining a second event on the same
457 component, namely an Event Changed, or by simply reusing
458 BecomesEqualTo and use event properties, in particular event
459 hysteresis. We append the following definition for the event
460 hysteresis defined in section 4.8.5.2 in [RFC5812], with V being the
461 hysteresis value:
463 o For an condition, after the last
464 notification a new notification MUST be
465 generated only one time once the value has changed by +/- V.
467 For example using the value of 1 for V, will in effect create a
468 singular event that will notify the CE that the value has changed by
469 at least 1.
471 A developer of a CE should consider using count or time filtering to
472 avoid being overrun by messages, e.g. in the case of rapid state
473 changes.
475 2.5. LFB Properties
477 The previous model definition specifies properties for components of
478 LFBs. Experience has shown that, at least for debug reasons, it
479 would be useful to have statistics per LFB instance to monitor sent
480 and received messages and errors in communication between CE and FE.
481 These properties are read-only.
483 In order to avoid ambiguity on protocol path semantics, this document
484 specifies that the LFB component with ID 0 specifically MUST refer to
485 LFB properties and ID 0 MUST NOT be used for any component
486 definition. This disallowment is backwards compatible as no known
487 LFB definition uses LFB component with ID 0. Any command with a path
488 starting from LFB component 0 refers to LFB properties. The
489 following change in the xml schema disallows usage of LFB component
490 0:
492
495 Figure 12: Initial xml for LFB Component IDs
496
497
498
499
500
501
502
503
504
506 Figure 13: New xml to disallow usage of 0 as LFB Component
508 The following datatype definitions are to be used as properties for
509 LFB instances.
511
512 LFBProperties
513 LFB Properties definition
514
515
516 PacketsSentToCE
517 Packets sent to CE
518 uint32
519
520
521 SentErrorPacketsToCE
522 Error Packets sent to CE
523 uint32
524
525
526 BytesSentToCE
527 Bytes sent to CE
528 uint32
529
530
531 SentErrorBytesToCE
532 Error Bytes sent to CE
533 uint32
534
535
536 PacketsReceivedFromCE
537 Packets received from CE
538 uint32
539
540
541 ReceivedErrorPacketsFromCE
542 Error Packets received from CE
543 uint32
545
546
547 BytesReceivedFromCE
548 Bytesreceived from CE
549 uint32
550
551
552 ReceivedErrorBytesFromCE
553 Error Bytes received from CE
554 uint32
555
556
557
559 Properties for LFB instances
561 2.6. LFB class inheritance
563 The ForCES model [RFC5812] allows inheritance for LFB classes.
564 However the xml schema defines only the LFB class from which an LFB
565 class inherits. Recent implementations have identified an issue
566 where ambiguity rises when different versions of the parent LFB class
567 exists. This document augments the derivedFrom part of the LFB class
568 definition with an optional version attribute when the derivedFrom
569 field is used.
571 Having the version attribute as optional was a decision based on the
572 need to maintain backwards compatibility with the XML schema defined
573 in [RFC5812]. However if the version is omitted then the derivedFrom
574 will always specify the first version of the parent LFB class, which
575 usually is version 1.0.
577 This extension alters the definition of the derivedFrom in the xml
578 schema from Figure 14 to Figure 15.
580
582 Figure 14: Initial xml for the LFB class inheritance
583
584
585
586
587
589
590
591
592
594 Figure 15: New xml for the LFB class inheritance
596 An example of the use of the version attribute is given in Figure 16
598 EtherPHYCop
600 Figure 16: Example of use of new xml for LFB class Inheritance
602 2.7. Enhancing XML Validation
604 As specified earlier this is not an extension but an enhancement of
605 the schema to provide additional validation rules. This includes
606 adding new key declarations to provide uniqueness as defined by the
607 ForCES Model [RFC5812]. Such validations work only on within the
608 same xml file.
610 This document introduces the following validation rules that did not
611 exist in the original schema in [RFC5812]:
613 1. Each metadata ID must be unique.
615 2. LFB Class IDs must be unique.
617 3. Component ID, Capability ID and Event Base ID must be unique per
618 LFB.
620 4. Event IDs must be unique per LFB.
622 5. Special Values in Atomic datatypes must be unique per atomic
623 datatype.
625 3. XML Extension Schema for LFB Class Library Documents
627 This section includes the new XML Schema. Note that the namespace
628 number has been updated from 1.0 to 1.1
630
631
636
637
638 Schema for Defining LFB Classes and associated types
639 (frames, data types for LFB attributes, and metadata).
640
641
642
643
644
645
646
647
648
649
651
653
655
657
659
660
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
680
681
682
683
684
685
686
687
688
689
690
691
692
694
695
696
697
698
699
700
701
702
704
705
706
707
708
709
710
711
712
713
714
715
717
718
720
721
722
723
724
725
726
729
730
731
732
733
734
735
736
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
777
779
780
781
782
783
784
785
786
787
789
790
791
792
793
794
795
796
798
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
822
823
824
826
827
829
830
831
832
833
834
835
836
837
838
839
840
842
844
845
846
847
849
850
851
852
853
854
856
857
858
859
861
862
863
864
865
867
868
869
870
871
872
873
874
875
876
877
878
879
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
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
923
924
925
926
927
929
931
933
935
937
939
940
942
943
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
969
970
971
974
975
976
977
978
979
980
981
982
983
984
985
986
988
989
990
991
992
993
994
995
996
997
999
1000
1001
1002
1003
1004
1005
1007
1009
1010
1011
1012
1013
1014
1015
1016
1017
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1044
1045
1046
1047
1048
1049
1050
1051
1053
1054
1055
1056
1057
1058
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1071
1072
1073
1074
1075
1076
1077
1079
1081
1082
1083
1084
1085
1086
1087
1089
1091
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1137
1138
1139
1141
1142
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
1179
1180
1181
1182
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1197
1198
1200
1202
1203
1205
1206
1207
1208
1210
1211
1212
1213
1215
1217
1219
1221
1223
1224
1226
1227
1228
1229
1230
1231
1232
1233
1235
1237
1239
1240
1241
1243
1244
1245
1246
1247
1248
1249
1250
1251
1253 ForCES LFB XML Schema
1255 4. Acknowledgements
1257 The author would like to acknowledge Joel Halpern, Jamal Hadi Salim
1258 and Dave Hood for their comments and discussion that helped shape
1259 this document in a better way. Adrian Farrel for his AD review and
1260 Ben Campbell for his Gen-ART review which both improved the quality
1261 of this document.
1263 5. IANA Considerations
1265 IANA has registered a new XML namespace, as per the guidelines in RFC
1266 3688 [RFC3688].
1268 URI: The URI for this namespace is
1270 urn:ietf:params:xml:ns:forces:lfbmodel:1.1
1272 Registrant Contact: IESG
1274 XML: none, this is an XML namespace
1276 6. Security Considerations
1278 This document adds only a few constructs to the initial model defined
1279 in [RFC5812], namely namely a new event, some new properties and a
1280 way to define optional access types and complex metadata. In
1281 addition this document addresses and clarifies an issue with the
1282 inheritance model by introducing the version of the derivedFrom LFB
1283 class. These constructs and the inheritance model change do not
1284 change the nature of the initial model.
1286 Thus the security considerations defined in [RFC5812] applies to this
1287 document as well as the changes proposed here are simply constructs
1288 to write XML library definitions, as where in [RFC5812] and clarifies
1289 the inheritance issue of the initial model and both have no effect on
1290 security semantics with the protocol.
1292 7. References
1294 7.1. Normative References
1296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1297 Requirement Levels", BCP 14, RFC 2119, March 1997.
1299 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1300 January 2004.
1302 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
1303 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
1304 Control Element Separation (ForCES) Protocol
1305 Specification", RFC 5810, March 2010.
1307 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
1308 Element Separation (ForCES) Forwarding Element Model", RFC
1309 5812, March 2010.
1311 [RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim,
1312 "High Availability within a Forwarding and Control Element
1313 Separation (ForCES) Network Element", RFC 7121, February
1314 2014.
1316 7.2. Informative References
1318 [OpenFlowSpec1.1]
1319 http://www.OpenFlow.org/, "The OpenFlow 1.1
1320 Specification.", .
1323 Author's Address
1325 Evangelos Haleplidis
1326 University of Patras
1327 Department of Electrical and Computer Engineering
1328 Patras 26500
1329 Greece
1331 Email: ehalep@ece.upatras.gr