idnits 2.17.1 draft-haleplidis-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 -- The document date (July 08, 2013) is 3945 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'N' is mentioned on line 630, but not defined == Missing Reference: '1-9' is mentioned on line 905, but not defined == Missing Reference: '0-9' is mentioned on line 905, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-forces-ceha-07 Summary: 0 errors (**), 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: Informational July 08, 2013 5 Expires: January 09, 2014 7 ForCES Model Extension 8 draft-haleplidis-forces-model-extension-04 10 Abstract 12 Forwarding and Control Element Separation (ForCES) defines an 13 architectural framework and associated protocols to standardize 14 information exchange between the control plane and the forwarding 15 plane in a ForCES Network Element (ForCES NE). RFC5812 has defined 16 the ForCES Model provides a formal way to represent the capabilities, 17 state, and configuration of forwarding elements within the context of 18 the ForCES protocol, so that control elements (CEs) can control the 19 FEs accordingly. More specifically, the model describes the logical 20 functions that are present in an FE, what capabilities these 21 functions support, and how these functions are or can be 22 interconnected. 24 RFC5812 has been around for two years and experience in its use has 25 shown room for small extensions without a need to alter the protocol 26 while retaining backward compatibility with older xml libraries. 27 This document extends the model to allow complex datatypes for 28 metadata, optional default values for datatypes and optional access 29 types for structures. The document also introduces three new 30 features, bitmap as a new datatype, 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 January 09, 2014. 50 Copyright Notice 52 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . 7 75 3.4. New datatype: Bitmap . . . . . . . . . . . . . . . . . . 8 76 3.5. New Event Condition: BecomesEqualTo . . . . . . . . . . . 10 77 3.6. LFB Properties . . . . . . . . . . . . . . . . . . . . . 10 78 3.7. Enhancing XML Validation . . . . . . . . . . . . . . . . 11 79 4. XML Extension Schema for LFB Class Library Documents . . . . 12 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 85 8.2. Informative References . . . . . . . . . . . . . . . . . 26 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 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 97 This document follows the terminology defined by the ForCES Model in 98 [RFC5812]. The required definitions are repeated below for clarity. 100 FE Model - The FE model is designed to model the logical 101 processing functions of an FE. The FE model proposed in this 102 document includes three components; the LFB modeling of individual 103 Logical Functional Block (LFB model), the logical interconnection 104 between LFBs (LFB topology), and the FE-level attributes, 105 including FE capabilities. The FE model provides the basis to 106 define the information elements exchanged between the CE and the 107 FE in the ForCES protocol [RFC5810]. 109 LFB (Logical Functional Block) Class (or type) - A template that 110 represents a fine-grained, logically separable aspect of FE 111 processing. Most LFBs relate to packet processing in the data 112 path. LFB classes are the basic building blocks of the FE model. 114 LFB Instance - As a packet flows through an FE along a data path, 115 it flows through one or multiple LFB instances, where each LFB is 116 an instance of a specific LFB class. Multiple instances of the 117 same LFB class can be present in an FE's data path. Note that we 118 often refer to LFBs without distinguishing between an LFB class 119 and LFB instance when we believe the implied reference is obvious 120 for the given context. 122 LFB Model - The LFB model describes the content and structures in 123 an LFB, plus the associated data definition. XML is used to 124 provide a formal definition of the necessary structures for the 125 modeling. Four types of information are defined in the LFB model. 126 The core part of the LFB model is the LFB class definitions; the 127 other three types of information define constructs associated with 128 and used by the class definition. These are reusable data types, 129 supported frame (packet) formats, and metadata. 131 Element - Element is generally used in this document in accordance 132 with the XML usage of the term. It refers to an XML tagged part 133 of an XML document. For a precise definition, please see the full 134 set of XML specifications from the W3C. This term is included in 135 this list for completeness because the ForCES formal model uses 136 XML. 138 Attribute - Attribute is used in the ForCES formal modeling in 139 accordance with standard XML usage of the term, i.e., to provide 140 attribute information included in an XML tag. 142 LFB Metadata - Metadata is used to communicate per-packet state 143 from one LFB to another, but is not sent across the network. The 144 FE model defines how such metadata is identified, produced, and 145 consumed by the LFBs, but not how the per-packet state is 146 implemented within actual hardware. Metadata is sent between the 147 FE and the CE on redirect packets. 149 ForCES Component - A ForCES Component is a well-defined, uniquely 150 identifiable and addressable ForCES model building block. A 151 component has a 32-bit ID, name, type, and an optional synopsis 152 description. These are often referred to simply as components. 153 LFB Component - An LFB component is a ForCES component that 154 defines the Operational parameters of the LFBs that must be 155 visible to the CEs. 157 LFB Class Library - The LFB class library is a set of LFB classes 158 that has been identified as the most common functions found in 159 most FEs and hence should be defined first by the ForCES Working 160 Group. 162 2. Introduction 164 The ForCES Model [RFC5812] presents a formal way to define FEs 165 Logical Function Blocks (LFBs) using XML. [RFC5812] has been 166 published a more than two years and current experience in its use has 167 demonstrated need for adding new and changing existing modeling 168 concepts. 170 Specifically this document extends the ForCES Model to allow complex 171 datatypes for metadata, optional default values for datatypes and 172 optional access types for structures. Additionally the document 173 introduces three new features, bitmap as a new datatype, a new event 174 condition BecomesEqualTo and LFB properties. 176 These extensions are an addendum to the ForCES model [RFC5812] and do 177 not require any changes on the ForCES protocol [RFC5810] as they are 178 simply changes of the schema definition. Additionally backward 179 compatibility is ensured as xml libraries produced with the earlier 180 schema are still valid with the new one. 182 XXX: Discussion is needed to specify whether bitmap required protocol 183 definition of how bitmap is sent through the wire. 185 3. ForCES Model Extension proposal 187 3.1. Complex datatypes for Metadata 189 Section 4.6. (Element for Metadata Definitions) in the ForCES Model 190 [RFC5812] limits the datatype use in metadata to only atomic types. 191 Figure 1 shows the xml schema excerpt where ony typeRef and atomic 192 are allowed for a metadata definition. 194 However there are cases where complex metadata are used in the 195 datapath, for example two simple use cases can be seen in the 196 OpenFlow switch 1.1 [OpenFlowSpec1.1] and beyond: 198 1. The Action Set metadata follows a packet inside the Flow Tables. 199 The Action Set metadata is an array of actions to be performed at 200 the end of the pipeline. 202 2. When a packet is received from a controller it may be accompanied 203 by a list of actions to be performed on it prior to be sent on 204 the flow table pipeline which is also an array. 206 With this extension (Figure 2), complex data types are also allowed, 207 specifically structs and arrays as metadata. The key declarations 208 are required to check for validity of content keys in arrays and 209 componentIDs in structs. 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 230 Figure 1: Initial MetadataDefType Defintion in the schema 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 259 260 261 263 Figure 2: New MetadataDefType Defintion for the schema 265 3.2. Optional Default Value for Datatypes 267 In the original schema, default values can only be defined for 268 datatypes defined inside LFB components and not inside structures or 269 arrays. Therefore default values of datatypes that are constantly 270 being reused, e.g. counters with default value of 0, have to be 271 constantly respecified. Additionally, datatypes inside complex 272 datatypes cannot be defined with a default value, e.g. a counter 273 inside a struct that has a default value of 0. 275 This extension allows optionally to add default values to atomic and 276 typeref types, whether they are as simple or complex datatypes. A 277 simple use case would be to have a struct component where one of the 278 components is a counter which the default value would be zero. 280 This extension alters the definition of the typeDeclarationGroup in 281 the xml schema from Figure 3 to Figure 4 to allow default values to 282 TypeRef. 284 286 Figure 3: Initial Excerpt of typeDeclarationGroup Defintion in the 287 schema 289 290 291 293 295 Figure 4: New Excerpt of typeDeclarationGroup Defintion in the schema 297 Additionally it appends to the declaration of the AtomicType this xml 298 (Figure 5) to allow default values to Atomic datatypes. 300 302 Figure 5: Appending xml in of AtomicType Defintion in the schema 304 3.3. Optional Access Type for Structs 306 In the original schema, the access type can be only be defined on 307 components of LFB and not on components in structs or arrays. 308 However when it's a struct datatype it is not possible to fine-tune 309 access type per component in the struct. A simple use case would be 310 to have a read-write struct component where one of the components is 311 a counter where the access-type could be read-reset or read-only, 312 e.g. a read-reset or a read-only counter inside a struct. 314 With this extension is it allowed to define the access type for a 315 struct component either in the datatype definitions or in the LFB 316 component definitions. 318 When the optional access type for a struct component is defined it 319 MUST override the access type of the struct. If by accident an 320 access type for a component in a capability is defined, the access 321 type MUST NOT be taken into account and MUST always be considered as 322 read-only. 324 This extension alters the definition of the struct in the xml schema 325 from Figure 6 to Figure 7. 327 328 329 331 332 333 334 335 336 337 338 339 340 342 343 344 345 347 Figure 6: Initial xml for the struct definition in the schema 349 350 351 353 354 355 356 357 358 359 360 361 362 364 365 366 367 368 370 371 372 373 375 Figure 7: New xml for the struct definition in the schema 377 3.4. New datatype: Bitmap 379 With the current schema it is valid to create a struct of booleans in 380 order to simulate a bitmap value. However each boolean is sent as 381 4bytes. This extension adds the bitmap, a set of sequential named 382 bits. 384 Bitmaps may be useful in describing capabilities, e.g. Link speed 385 capabilities as multiple boolean values. 387 XXX Discussion may be required as to whether there is a need for 388 protocol description of how the bitmap is sent through the wire. 390 In the new schema, bits are named followed an optional bit value. An 391 example: 393 394 Bitmap example 395 A bitmap field example 396 397 398 399 400 402 Figure 8: Example of bitmap Defintion 404 The ordering of the bits MUST be implemented in the order that are 405 defined in the xml library. 407 The bitmap is defined in the model extension schema is as follows: 409 410 411 412 413 414 416 417 418 419 420 421 422 423 424 425 427 Figure 9: New Excerpt of bitmap Defintion in the schema 429 Along with the needed addition to the typeDeclarationGroup 430 Definition: 432 434 Figure 10: New Excerpt of typeDeclarationGroup Defintion in the 435 schema 437 3.5. New Event Condition: BecomesEqualTo 439 This extensions adds one more event condition in the model schema, 440 that of BecomesEqualTo. The difference between Greater Than and Less 441 Than, is that when the value is exactly that of the BecomesEqualTo, 442 the event is triggered. This event condition is particular useful 443 when there is a need to monitor one or more states of an LFB or the 444 FE. For example in the CEHA [I-D.ietf-forces-ceha] document it may 445 be useful for the master CE to know which backup CEs have just become 446 associated in order to connect to them and begin synchronizing the 447 state of the FE. The master CE could always poll for such 448 information but getting such an event will speed up the process and 449 the event may be useful in other cases as well for monitoring state. 451 The event MUST be triggered only when the value of the targeted 452 component becomes equal to the event condition value and MUST NOT 453 generate events while the targeted component's value remains equal to 454 the event condition's value. 456 The BecomesEqualTo is appended to the schema as follows: 458 461 Figure 11: New Excerpt of BecomesEqualTo event condition definition 462 in the schema 464 3.6. 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 XXX: Discussion for addressing LFB properties. Possibly in the 473 protocol extension? 475 The following datatype definitions are to be used as properties for 476 LFB instances. 478 479 LFBProperties 480 LFB Properties definition 481 482 483 SentToCE 484 Messages sent to CE 485 uint32 486 487 488 SentErrorsToCE 489 Error messages sent to CE 490 uint32 491 492 493 ReceivedFromCE 494 Messages received from CE 495 uint32 496 497 498 ReceivedErrorsFromCE 499 Error messages received from CE 500 uint32 501 502 503 505 Properties for LFB instances 507 3.7. Enhancing XML Validation 509 As specified earlier this is not an extension but an enhancement of 510 the schema to provide additional validation rules. This includes 511 adding new key declarations to provide uniqueness as deinfed by the 512 ForCES Model [RFC5812]. Such validations work only on within the 513 same xml file. 515 The following validation rules have been appended in the original 516 schema in [RFC5812]: 518 1. Each metadata ID must be unique. 520 2. LFB Class IDs must be unique. 522 3. Component ID, Capability ID and Event Base ID must be unique per 523 LFB. 525 4. Event IDs must be unique per LFB. 527 5. Special Values in Atomic datatypes must be unique per atomic 528 datatype. 530 4. XML Extension Schema for LFB Class Library Documents 532 533 538 539 540 Schema for Defining LFB Classes and associated types ( 541 frames, data types for LFB attributes, and metadata). 542 543 544 545 546 547 548 549 550 551 553 555 557 559 561 562 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 595 596 597 598 599 600 601 602 603 605 606 607 608 609 610 611 612 613 614 615 616 618 619 621 622 624 625 626 627 628 631 632 633 634 635 636 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 670 671 673 674 675 676 677 678 680 682 683 684 685 686 687 688 689 690 692 693 694 695 696 697 698 699 701 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 727 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 745 746 747 749 750 752 753 754 755 757 758 759 760 761 762 763 764 766 768 769 770 771 773 774 775 776 777 778 780 781 782 783 784 786 787 788 789 790 791 793 794 795 796 797 798 799 800 801 802 803 804 805 807 808 810 811 812 813 814 815 816 818 819 820 821 822 823 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 847 850 853 856 859 861 863 864 867 868 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 898 899 900 901 902 903 904 905 906 907 908 909 910 912 913 914 915 916 917 918 919 920 921 923 924 925 926 927 928 929 931 933 934 935 936 937 938 939 941 943 945 946 947 948 949 950 951 952 953 954 955 957 958 959 960 961 962 963 964 965 966 967 968 969 971 972 973 974 975 976 977 978 980 981 982 983 984 985 987 988 989 990 991 992 993 994 995 996 998 999 1000 1001 1002 1003 1004 1006 1008 1009 1010 1011 1012 1013 1014 1016 1018 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1032 1033 1034 1035 1036 1037 1038 1040 1041 1042 1043 1044 1045 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1066 1067 1068 1070 1071 1073 1074 1075 1076 1077 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1101 1102 1103 1104 1106 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1120 1121 1123 1125 1126 1128 1129 1130 1131 1133 1134 1135 1136 1138 1140 1142 1144 1146 1147 1149 1150 1151 1152 1153 1154 1155 1156 1158 1160 1162 1163 1164 1166 1167 1168 1169 1170 1171 1172 1173 1174 1176 OpenFlow XML Library 1178 5. Acknowledgements 1180 The author would like to acknowledge Joel Halpern, Jamal Hadi and 1181 Dave Hood for their comments and discussion that helped shape this 1182 document in a better way. 1184 6. IANA Considerations 1186 This memo includes no request to IANA. 1188 7. Security Considerations 1190 The security considerations that have been described in the ForCES 1191 Model RFC [RFC5812] apply to this document as well. 1193 8. References 1195 8.1. Normative References 1197 [I-D.ietf-forces-ceha] 1198 Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES 1199 Intra-NE High Availability", draft-ietf-forces-ceha-07 1200 (work in progress), May 2013. 1202 [OpenFlowSpec1.1] 1203 http://www.OpenFlow.org/, "The OpenFlow 1.1 1204 Specification.", , . 1207 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 1208 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 1209 Control Element Separation (ForCES) Protocol 1210 Specification", RFC 5810, March 2010. 1212 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 1213 Element Separation (ForCES) Forwarding Element Model", RFC 1214 5812, March 2010. 1216 8.2. Informative References 1218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1219 Requirement Levels", BCP 14, RFC 2119, March 1997. 1221 Author's Address 1223 Evangelos Haleplidis 1224 University of Patras 1225 Department of Electrical and Computer Engineering 1226 Patras 26500 1227 Greece 1229 Email: ehalep@ece.upatras.gr