idnits 2.17.1
draft-ietf-forces-model-extension-02.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 2 instances of too long lines in the document, the longest one
being 4 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 (May 20, 2014) is 3629 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 706, but not defined
== Missing Reference: '1-9' is mentioned on line 958, but not defined
== Missing Reference: '0-9' is mentioned on line 958, 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 May 20, 2014
5 Expires: November 21, 2014
7 ForCES Model Extension
8 draft-ietf-forces-model-extension-02
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, optional access
29 types for structures and fixes an issue with LFB inheritance. The
30 document also introduces two new features a new event condition
31 BecomesEqualTo and LFB properties.
33 Status of This Memo
35 This Internet-Draft is submitted in full conformance with the
36 provisions of BCP 78 and BCP 79.
38 Internet-Drafts are working documents of the Internet Engineering
39 Task Force (IETF). Note that other groups may also distribute
40 working documents as Internet-Drafts. The list of current Internet-
41 Drafts is at http://datatracker.ietf.org/drafts/current/.
43 Internet-Drafts are draft documents valid for a maximum of six months
44 and may be updated, replaced, or obsoleted by other documents at any
45 time. It is inappropriate to use Internet-Drafts as reference
46 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on November 21, 2014.
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. Terminology and Conventions . . . . . . . . . . . . . . . . . 2
68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
69 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
70 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
71 3. ForCES Model Extension proposal . . . . . . . . . . . . . . . 4
72 3.1. Complex datatypes for Metadata . . . . . . . . . . . . . 4
73 3.2. Optional Default Value for Datatypes . . . . . . . . . . 6
74 3.3. Optional Access Type for Structs . . . . . . . . . . . . 8
75 3.4. New Event Condition: BecomesEqualTo . . . . . . . . . . . 10
76 3.5. LFB Properties . . . . . . . . . . . . . . . . . . . . . 11
77 3.6. LFB class inheritance . . . . . . . . . . . . . . . . . . 12
78 3.7. Enhancing XML Validation . . . . . . . . . . . . . . . . 13
79 4. XML Extension Schema for LFB Class Library Documents . . . . 14
80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
84 8.1. Normative References . . . . . . . . . . . . . . . . . . 27
85 8.2. Informative References . . . . . . . . . . . . . . . . . 27
86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
88 1. Terminology and Conventions
90 1.1. Requirements Language
92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
94 document are to be interpreted as described in [RFC2119].
96 1.2. Definitions
98 This document follows the terminology defined by the ForCES Model in
99 [RFC5812]. The required definitions are repeated below for clarity.
101 FE Model - The FE model is designed to model the logical
102 processing functions of an FE. The FE model proposed in this
103 document includes three components; the LFB modeling of individual
104 Logical Functional Block (LFB model), the logical interconnection
105 between LFBs (LFB topology), and the FE-level attributes,
106 including FE capabilities. The FE model provides the basis to
107 define the information elements exchanged between the CE and the
108 FE in the ForCES protocol [RFC5810].
110 LFB (Logical Functional Block) Class (or type) - A template that
111 represents a fine-grained, logically separable aspect of FE
112 processing. Most LFBs relate to packet processing in the data
113 path. LFB classes are the basic building blocks of the FE model.
115 LFB Instance - As a packet flows through an FE along a data path,
116 it flows through one or multiple LFB instances, where each LFB is
117 an instance of a specific LFB class. Multiple instances of the
118 same LFB class can be present in an FE's data path. Note that we
119 often refer to LFBs without distinguishing between an LFB class
120 and LFB instance when we believe the implied reference is obvious
121 for the given context.
123 LFB Model - The LFB model describes the content and structures in
124 an LFB, plus the associated data definition. XML is used to
125 provide a formal definition of the necessary structures for the
126 modeling. Four types of information are defined in the LFB model.
127 The core part of the LFB model is the LFB class definitions; the
128 other three types of information define constructs associated with
129 and used by the class definition. These are reusable data types,
130 supported frame (packet) formats, and metadata.
132 Element - Element is generally used in this document in accordance
133 with the XML usage of the term. It refers to an XML tagged part
134 of an XML document. For a precise definition, please see the full
135 set of XML specifications from the W3C. This term is included in
136 this list for completeness because the ForCES formal model uses
137 XML.
139 Attribute - Attribute is used in the ForCES formal modeling in
140 accordance with standard XML usage of the term, i.e., to provide
141 attribute information included in an XML tag.
143 LFB Metadata - Metadata is used to communicate per-packet state
144 from one LFB to another, but is not sent across the network. The
145 FE model defines how such metadata is identified, produced, and
146 consumed by the LFBs, but not how the per-packet state is
147 implemented within actual hardware. Metadata is sent between the
148 FE and the CE on redirect packets.
150 ForCES Component - A ForCES Component is a well-defined, uniquely
151 identifiable and addressable ForCES model building block. A
152 component has a 32-bit ID, name, type, and an optional synopsis
153 description. These are often referred to simply as components.
154 LFB Component - An LFB component is a ForCES component that
155 defines the Operational parameters of the LFBs that must be
156 visible to the CEs.
158 LFB Class Library - The LFB class library is a set of LFB classes
159 that has been identified as the most common functions found in
160 most FEs and hence should be defined first by the ForCES Working
161 Group.
163 2. Introduction
165 The ForCES Model [RFC5812] presents a formal way to define FEs
166 Logical Function Blocks (LFBs) using XML. [RFC5812] has been
167 published a more than two years and current experience in its use has
168 demonstrated need for adding new and changing existing modeling
169 concepts.
171 Specifically this document extends the ForCES Model to allow complex
172 datatypes for metadata, optional default values for datatypes,
173 optional access types for structures and fixes an issue with the LFB
174 inheritance. Additionally the document introduces two new features a
175 new event condition BecomesEqualTo and LFB properties.
177 These extensions are an addendum to the ForCES model [RFC5812] and do
178 not require any changes on the ForCES protocol [RFC5810] as they are
179 simply changes of the schema definition. Additionally backward
180 compatibility is ensured as xml libraries produced with the earlier
181 schema are still valid with the new one.
183 3. ForCES Model Extension proposal
185 3.1. Complex datatypes for Metadata
187 Section 4.6. (Element for Metadata Definitions) in the ForCES Model
188 [RFC5812] limits the datatype use in metadata to only atomic types.
189 Figure 1 shows the xml schema excerpt where ony typeRef and atomic
190 are allowed for a metadata definition.
192 However there are cases where complex metadata are used in the
193 datapath, for example two simple use cases can be seen in the
194 OpenFlow switch 1.1 [OpenFlowSpec1.1] and beyond:
196 1. The Action Set metadata follows a packet inside the Flow Tables.
197 The Action Set metadata is an array of actions to be performed at
198 the end of the pipeline.
200 2. When a packet is received from a controller it may be accompanied
201 by a list of actions to be performed on it prior to be sent on
202 the flow table pipeline which is also an array.
204 With this extension (Figure 2), complex data types are also allowed,
205 specifically structs and arrays as metadata. The key declarations
206 are required to check for validity of content keys in arrays and
207 componentIDs in structs.
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
228 Figure 1: Initial MetadataDefType Definition in the schema
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
260 Figure 2: New MetadataDefType Definition for the schema
262 3.2. Optional Default Value for Datatypes
264 In the original schema, default values can only be defined for
265 datatypes defined inside LFB components and not inside structures or
266 arrays. Therefore default values of datatypes that are constantly
267 being reused, e.g. counters with default value of 0, have to be
268 constantly respecified. Additionally, datatypes inside complex
269 datatypes cannot be defined with a default value, e.g. a counter
270 inside a struct that has a default value of 0.
272 This extension allows optionally to add default values to atomic and
273 typeref types, whether they are as simple or complex datatypes. A
274 simple use case would be to have a struct component where one of the
275 components is a counter which the default value would be zero.
277 This extension alters the definition of the typeDeclarationGroup in
278 the xml schema from Figure 3 to Figure 4 to allow default values to
279 TypeRef.
281
283 Figure 3: Initial Excerpt of typeDeclarationGroup Defintion in the
284 schema
286
287
288
290
292 Figure 4: New Excerpt of typeDeclarationGroup Definition in the
293 schema
295 Additionally it appends to the declaration of the AtomicType this xml
296 (Figure 5) to allow default values to Atomic datatypes.
298
300 Figure 5: Appending xml in of AtomicType Definition in the schema
302
303 Counter Values
304 Example default values in struct
305
306
307 GoodPacketCoutner
308 A counter for good packets
309 uint32
310 0
311
312
313 BadPacketCoutner
314 A counter for bad packets
315 uint32
316 0
317
318
319
321 Figure 6: Example of optional default values
323 3.3. Optional Access Type for Structs
325 In the original schema, the access type can be only be defined on
326 components of LFB and not on components in structs or arrays.
327 However when it's a struct datatype it is not possible to fine-tune
328 access type per component in the struct. A simple use case would be
329 to have a read-write struct component where one of the components is
330 a counter where the access-type could be read-reset or read-only,
331 e.g. a read-reset or a read-only counter inside a struct.
333 With this extension is it allowed to define the access type for a
334 struct component either in the datatype definitions or in the LFB
335 component definitions.
337 When the optional access type for a struct component is defined it
338 MUST override the access type of the struct. If by accident an
339 access type for a component in a capability is defined, the access
340 type MUST NOT be taken into account and MUST always be considered as
341 read-only.
343 This extension alters the definition of the struct in the xml schema
344 from Figure 7 to Figure 8.
346
347
348
350
351
352
353
354
355
356
357
358
359
361
362
363
364
366 Figure 7: Initial xml for the struct definition in the schema
367
368
369
371
372
373
374
375
376
377
378
379
380
382
383
384
385
386
388
389
390
391
393 Figure 8: New xml for the struct definition in the schema
395
396 PacketFlows
397 Packet Flows, match and counter
398
399
400 FlowMatch
401 Flow Match
402 MatchType
403
404
405 MatchCounter
406 Packets matching the flow match
407 uint32
408 0
409
410
411
413 Figure 9: Example of optional access types for struct
415 3.4. New Event Condition: BecomesEqualTo
417 This extensions adds one more event condition in the model schema,
418 that of BecomesEqualTo. The difference between Greater Than and Less
419 Than, is that when the value is exactly that of the BecomesEqualTo,
420 the event is triggered. This event condition is particular useful
421 when there is a need to monitor one or more states of an LFB or the
422 FE. For example in the CEHA [I-D.ietf-forces-ceha] document it may
423 be useful for the master CE to know which backup CEs have just become
424 associated in order to connect to them and begin synchronizing the
425 state of the FE. The master CE could always poll for such
426 information but getting such an event will speed up the process and
427 the event may be useful in other cases as well for monitoring state.
429 The event MUST be triggered only when the value of the targeted
430 component becomes equal to the event condition value and MUST NOT
431 generate events while the targeted component's value remains equal to
432 the event condition's value.
434 The BecomesEqualTo is appended to the schema as follows:
436
439 Figure 10: New Excerpt of BecomesEqualTo event condition definition
440 in the schema
442 It can become useful for the CE to be notified when the state has
443 changed once the BecomesEqualTo event has been triggered, e.g. the CE
444 may need to know when a backup CE has lost association. Such an
445 event can be generated either by defining a second event on the same
446 component, namely an Event Changed, or by simply reusing
447 BecomesEqualTo and use event properties, in particular event
448 hysteresis. We append the following definition for the event
449 hysteresis defined in section 4.8.5.2 in [RFC5812], with V being the
450 hysteresis value:
452 o For an condition, after the last
453 notification a new notification MUST be
454 generated only one time once the value has changed by +/- V.
456 For example using the value of 1 for V, will in effect create a
457 singular event that will notify the CE that the value has changed by
458 at least 1.
460 A developer of a CE must also take into account to use count or time
461 filtering to avoid being overrun by messages, e.g. in the case of
462 rapid state changes.
464 3.5. LFB Properties
466 The current model definition specifies properties for components of
467 LFBs. Experience however has proven valuable at least for debug
468 reasons, to have statistics per LFB instance to monitor sent/received
469 messages and errors for communication between CE and FE. These
470 properties are read-only.
472 In order to avoid ambiguity on protocol path semantics, this document
473 reserves LFB component 0 for LFB properties. This reservation is
474 backwards compatible as no LFB definition uses LFB component 0. Any
475 command with a path starting from LFB component 0 refers to LFB
476 properties. The following change in the xml schema disallows usage
477 of LFB component 0:
479
482 Figure 11: Initial xml for LFB Component IDs
484
485
486
487
488
489
490
491
492
494 Figure 12: New xml for the disallowing usage of 0 as LFB Component
496 The following datatype definitions are to be used as properties for
497 LFB instances.
499
500 LFBProperties
501 LFB Properties definition
502
503
504 PacketsSentToCE
505 Packets sent to CE
506 uint32
507
508
509 SentErrorPacketsToCE
510 Error Packets sent to CE
511 uint32
513
514
515 BytesSentToCE
516 Bytes sent to CE
517 uint32
518
519
520 SentErrorBytesToCE
521 Error Bytes sent to CE
522 uint32
523
524
525 PacketsReceivedFromCE
526 Packets received from CE
527 uint32
528
529
530 ReceivedErrorPacketsFromCE
531 Error Packets received from CE
532 uint32
533
534
535 BytesReceivedFromCE
536 Bytesreceived from CE
537 uint32
538
539
540 ReceivedErrorBytesFromCE
541 Error Bytes received from CE
542 uint32
543
544
545
547 Properties for LFB instances
549 3.6. LFB class inheritance
551 The ForCES model [RFC5812] allows inheritance for LFB classes.
552 However the xml schema defines only the LFB class from which an LFB
553 class may inherit. Recent implementations have identified an issue
554 where ambiguity rises when different versions of an LFB class exists.
555 This document augments the derivedFrom part of the LFB class
556 definition with a mandatory version attribute when the derivedFrom
557 field is used.
559 This extension alters the definition of the derivedFrom in the xml
560 schema from Figure 13 to Figure 14.
562
564 Figure 13: Initial xml for the LFB class inheritance
566
567
568
569
570
572
573
574
575
577 Figure 14: New xml for the LFB class inheritance
579 EtherPHYCop
581 Figure 15: Example of use of new xml for LFB class Inheritance
583 3.7. Enhancing XML Validation
585 As specified earlier this is not an extension but an enhancement of
586 the schema to provide additional validation rules. This includes
587 adding new key declarations to provide uniqueness as defined by the
588 ForCES Model [RFC5812]. Such validations work only on within the
589 same xml file.
591 The following validation rules have been appended in the original
592 schema in [RFC5812]:
594 1. Each metadata ID must be unique.
596 2. LFB Class IDs must be unique.
598 3. Component ID, Capability ID and Event Base ID must be unique per
599 LFB.
601 4. Event IDs must be unique per LFB.
603 5. Special Values in Atomic datatypes must be unique per atomic
604 datatype.
606 4. XML Extension Schema for LFB Class Library Documents
608
609
614
615
616 Schema for Defining LFB Classes and associated types
617 (frames, data types for LFB attributes, and metadata).
618
619
620
621
622
623
624
625
626
627
629
631
633
635
637
638
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
671
672
673
674
675
676
677
678
679
681
682
683
684
685
686
687
688
689
690
691
692
694
695
697
698
699
700
701
703
704
707
708
709
710
711
712
713
714
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
754
756
757
758
759
760
761
762
763
764
766
767
768
769
770
771
772
773
775
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
799
800
801
803
804
806
807
808
809
810
811
812
813
814
815
816
817
819
821
822
823
824
826
827
828
829
830
831
833
834
835
836
838
839
840
841
842
844
845
846
848
849
850
851
852
853
854
855
856
857
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
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
901
902
903
904
905
907
909
911
913
915
917
918
920
921
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
951
952
953
954
955
956
957
958
959
960
961
962
963
965
966
967
968
969
970
971
972
973
974
976
977
978
979
980
981
982
984
986
987
988
989
990
991
992
993
994
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1021
1022
1023
1024
1025
1026
1027
1028
1030
1031
1032
1033
1034
1035
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1048
1049
1050
1051
1052
1053
1054
1056
1058
1059
1060
1061
1062
1063
1064
1066
1068
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1089
1090
1091
1092
1093
1094
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1115
1116
1117
1119
1120
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1158
1159
1160
1161
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1176
1177
1179
1181
1182
1184
1185
1187
1188
1190
1191
1192
1193
1195
1197
1199
1201
1203
1204
1206
1207
1208
1209
1210
1211
1212
1213
1215
1217
1219
1220
1221
1223
1224
1225
1226
1227
1228
1229
1230
1231
1233 OpenFlow XML Library
1235 5. Acknowledgements
1237 The author would like to acknowledge Joel Halpern, Jamal Hadi Salim
1238 and Dave Hood for their comments and discussion that helped shape
1239 this document in a better way.
1241 6. IANA Considerations
1243 This specification requests that LFB Component ID 0 to be reserved.
1245 7. Security Considerations
1247 The security considerations that have been described in the ForCES
1248 Model RFC [RFC5812] apply to this document as well.
1250 8. References
1252 8.1. Normative References
1254 [I-D.ietf-forces-ceha]
1255 Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES
1256 Intra-NE High Availability", draft-ietf-forces-ceha-08
1257 (work in progress), October 2013.
1259 [OpenFlowSpec1.1]
1260 http://www.OpenFlow.org/, "The OpenFlow 1.1
1261 Specification.", .
1264 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
1265 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
1266 Control Element Separation (ForCES) Protocol
1267 Specification", RFC 5810, March 2010.
1269 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
1270 Element Separation (ForCES) Forwarding Element Model", RFC
1271 5812, March 2010.
1273 8.2. Informative References
1275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1276 Requirement Levels", BCP 14, RFC 2119, March 1997.
1278 Author's Address
1279 Evangelos Haleplidis
1280 University of Patras
1281 Department of Electrical and Computer Engineering
1282 Patras 26500
1283 Greece
1285 Email: ehalep@ece.upatras.gr