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