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