idnits 2.17.1 draft-ietf-forces-model-extension-01.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 13 instances of too long lines in the document, the longest one being 7 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 (November 16, 2013) is 3811 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 627, but not defined == Missing Reference: '1-9' is mentioned on line 872, but not defined == Missing Reference: '0-9' is mentioned on line 872, 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 November 16, 2013 5 Expires: May 20, 2014 7 ForCES Model Extension 8 draft-ietf-forces-model-extension-01 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 two new features 30 a new event condition BecomesEqualTo and LFB properties. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 20, 2014. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 68 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. ForCES Model Extension proposal . . . . . . . . . . . . . . . 4 71 3.1. Complex datatypes for Metadata . . . . . . . . . . . . . 4 72 3.2. Optional Default Value for Datatypes . . . . . . . . . . 6 73 3.3. Optional Access Type for Structs . . . . . . . . . . . . 7 74 3.4. New Event Condition: BecomesEqualTo . . . . . . . . . . . 8 75 3.5. LFB Properties . . . . . . . . . . . . . . . . . . . . . 9 76 3.6. Enhancing XML Validation . . . . . . . . . . . . . . . . 11 77 4. XML Extension Schema for LFB Class Library Documents . . . . 12 78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 83 8.2. Informative References . . . . . . . . . . . . . . . . . 25 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 86 1. Terminology and Conventions 88 1.1. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 1.2. Definitions 95 This document follows the terminology defined by the ForCES Model in 96 [RFC5812]. The required definitions are repeated below for clarity. 98 FE Model - The FE model is designed to model the logical 99 processing functions of an FE. The FE model proposed in this 100 document includes three components; the LFB modeling of individual 101 Logical Functional Block (LFB model), the logical interconnection 102 between LFBs (LFB topology), and the FE-level attributes, 103 including FE capabilities. The FE model provides the basis to 104 define the information elements exchanged between the CE and the 105 FE in the ForCES protocol [RFC5810]. 107 LFB (Logical Functional Block) Class (or type) - A template that 108 represents a fine-grained, logically separable aspect of FE 109 processing. Most LFBs relate to packet processing in the data 110 path. LFB classes are the basic building blocks of the FE model. 112 LFB Instance - As a packet flows through an FE along a data path, 113 it flows through one or multiple LFB instances, where each LFB is 114 an instance of a specific LFB class. Multiple instances of the 115 same LFB class can be present in an FE's data path. Note that we 116 often refer to LFBs without distinguishing between an LFB class 117 and LFB instance when we believe the implied reference is obvious 118 for the given context. 120 LFB Model - The LFB model describes the content and structures in 121 an LFB, plus the associated data definition. XML is used to 122 provide a formal definition of the necessary structures for the 123 modeling. Four types of information are defined in the LFB model. 124 The core part of the LFB model is the LFB class definitions; the 125 other three types of information define constructs associated with 126 and used by the class definition. These are reusable data types, 127 supported frame (packet) formats, and metadata. 129 Element - Element is generally used in this document in accordance 130 with the XML usage of the term. It refers to an XML tagged part 131 of an XML document. For a precise definition, please see the full 132 set of XML specifications from the W3C. This term is included in 133 this list for completeness because the ForCES formal model uses 134 XML. 136 Attribute - Attribute is used in the ForCES formal modeling in 137 accordance with standard XML usage of the term, i.e., to provide 138 attribute information included in an XML tag. 140 LFB Metadata - Metadata is used to communicate per-packet state 141 from one LFB to another, but is not sent across the network. The 142 FE model defines how such metadata is identified, produced, and 143 consumed by the LFBs, but not how the per-packet state is 144 implemented within actual hardware. Metadata is sent between the 145 FE and the CE on redirect packets. 147 ForCES Component - A ForCES Component is a well-defined, uniquely 148 identifiable and addressable ForCES model building block. A 149 component has a 32-bit ID, name, type, and an optional synopsis 150 description. These are often referred to simply as components. 151 LFB Component - An LFB component is a ForCES component that 152 defines the Operational parameters of the LFBs that must be 153 visible to the CEs. 155 LFB Class Library - The LFB class library is a set of LFB classes 156 that has been identified as the most common functions found in 157 most FEs and hence should be defined first by the ForCES Working 158 Group. 160 2. Introduction 162 The ForCES Model [RFC5812] presents a formal way to define FEs 163 Logical Function Blocks (LFBs) using XML. [RFC5812] has been 164 published a more than two years and current experience in its use has 165 demonstrated need for adding new and changing existing modeling 166 concepts. 168 Specifically this document extends the ForCES Model to allow complex 169 datatypes for metadata, optional default values for datatypes and 170 optional access types for structures. Additionally the document 171 introduces two new features a new event condition BecomesEqualTo and 172 LFB properties. 174 These extensions are an addendum to the ForCES model [RFC5812] and do 175 not require any changes on the ForCES protocol [RFC5810] as they are 176 simply changes of the schema definition. Additionally backward 177 compatibility is ensured as xml libraries produced with the earlier 178 schema are still valid with the new one. 180 3. ForCES Model Extension proposal 182 3.1. Complex datatypes for Metadata 184 Section 4.6. (Element for Metadata Definitions) in the ForCES Model 185 [RFC5812] limits the datatype use in metadata to only atomic types. 186 Figure 1 shows the xml schema excerpt where ony typeRef and atomic 187 are allowed for a metadata definition. 189 However there are cases where complex metadata are used in the 190 datapath, for example two simple use cases can be seen in the 191 OpenFlow switch 1.1 [OpenFlowSpec1.1] and beyond: 193 1. The Action Set metadata follows a packet inside the Flow Tables. 194 The Action Set metadata is an array of actions to be performed at 195 the end of the pipeline. 197 2. When a packet is received from a controller it may be accompanied 198 by a list of actions to be performed on it prior to be sent on 199 the flow table pipeline which is also an array. 201 With this extension (Figure 2), complex data types are also allowed, 202 specifically structs and arrays as metadata. The key declarations 203 are required to check for validity of content keys in arrays and 204 componentIDs in structs. 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 225 Figure 1: Initial MetadataDefType Definition in the schema 227 228 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 258 Figure 2: New MetadataDefType Definition for the schema 260 3.2. Optional Default Value for Datatypes 262 In the original schema, default values can only be defined for 263 datatypes defined inside LFB components and not inside structures or 264 arrays. Therefore default values of datatypes that are constantly 265 being reused, e.g. counters with default value of 0, have to be 266 constantly respecified. Additionally, datatypes inside complex 267 datatypes cannot be defined with a default value, e.g. a counter 268 inside a struct that has a default value of 0. 270 This extension allows optionally to add default values to atomic and 271 typeref types, whether they are as simple or complex datatypes. A 272 simple use case would be to have a struct component where one of the 273 components is a counter which the default value would be zero. 275 This extension alters the definition of the typeDeclarationGroup in 276 the xml schema from Figure 3 to Figure 4 to allow default values to 277 TypeRef. 279 281 Figure 3: Initial Excerpt of typeDeclarationGroup Defintion in the 282 schema 284 285 286 288 290 Figure 4: New Excerpt of typeDeclarationGroup Definition in the 291 schema 293 Additionally it appends to the declaration of the AtomicType this xml 294 (Figure 5) to allow default values to Atomic datatypes. 296 298 Figure 5: Appending xml in of AtomicType Definition in the schema 300 3.3. Optional Access Type for Structs 302 In the original schema, the access type can be only be defined on 303 components of LFB and not on components in structs or arrays. 304 However when it's a struct datatype it is not possible to fine-tune 305 access type per component in the struct. A simple use case would be 306 to have a read-write struct component where one of the components is 307 a counter where the access-type could be read-reset or read-only, 308 e.g. a read-reset or a read-only counter inside a struct. 310 With this extension is it allowed to define the access type for a 311 struct component either in the datatype definitions or in the LFB 312 component definitions. 314 When the optional access type for a struct component is defined it 315 MUST override the access type of the struct. If by accident an 316 access type for a component in a capability is defined, the access 317 type MUST NOT be taken into account and MUST always be considered as 318 read-only. 320 This extension alters the definition of the struct in the xml schema 321 from Figure 6 to Figure 7. 323 324 325 327 328 329 330 331 332 333 334 335 336 338 339 340 341 343 Figure 6: Initial xml for the struct definition in the schema 345 346 347 349 350 351 352 353 354 355 356 357 358 360 361 362 363 364 366 367 368 369 371 Figure 7: New xml for the struct definition in the schema 373 3.4. New Event Condition: BecomesEqualTo 375 This extensions adds one more event condition in the model schema, 376 that of BecomesEqualTo. The difference between Greater Than and Less 377 Than, is that when the value is exactly that of the BecomesEqualTo, 378 the event is triggered. This event condition is particular useful 379 when there is a need to monitor one or more states of an LFB or the 380 FE. For example in the CEHA [I-D.ietf-forces-ceha] document it may 381 be useful for the master CE to know which backup CEs have just become 382 associated in order to connect to them and begin synchronizing the 383 state of the FE. The master CE could always poll for such 384 information but getting such an event will speed up the process and 385 the event may be useful in other cases as well for monitoring state. 387 The event MUST be triggered only when the value of the targeted 388 component becomes equal to the event condition value and MUST NOT 389 generate events while the targeted component's value remains equal to 390 the event condition's value. 392 The BecomesEqualTo is appended to the schema as follows: 394 397 Figure 8: New Excerpt of BecomesEqualTo event condition definition in 398 the schema 400 It can become useful for the CE to be notified when the state has 401 changed once the BecomesEqualTo event has been triggered, e.g. the CE 402 may need to know when a backup CE has lost association. Such an 403 event can be generated either by defining a second event on the same 404 component, namely an Event Changed, or by simply reusing 405 BecomesEqualTo and use event properties, in particular event 406 hysteresis. We append the following definition for the event 407 hysteresis defined in section 4.8.5.2 in [RFC5812], with V being the 408 hysteresis value: 410 o For an condition, after the last 411 notification a new notification MUST be 412 generated only one time once the value has changed by +/- V. 414 For example using the value of 1 for V, will in effect create a 415 singular event that will notify the CE that the value has changed by 416 at least 1. 418 A developer of a CE must also take into account to use count or time 419 filtering to avoid being overrun by messages, e.g. in the case of 420 rapid state changes. 422 3.5. LFB Properties 423 The current model definition specifies properties for components of 424 LFBs. Experience however has proven valuable at least for debug 425 reasons, to have statistics per LFB instance to monitor sent/received 426 messages and errors for communication between CE and FE. These 427 properties are read-only. 429 In order to avoid ambiguity on protocol path semantics, this document 430 reserves LFB component 0 for LFB properties. This reservation is 431 backwards compatible as no LFB definition uses LFB component 0. Any 432 command with a path starting from LFB component 0 refers to LFB 433 properties. The following change in the xml schema disallows usage 434 of LFB component 0: 436 439 Figure 9: Initial xml for LFB Component IDs 441 442 443 444 445 446 447 448 449 451 Figure 10: New xml for the disallowing usage of 0 as LFB Component 453 The following datatype definitions are to be used as properties for 454 LFB instances. 456 457 LFBProperties 458 LFB Properties definition 459 460 461 PacketsSentToCE 462 Packets sent to CE 463 uint32 464 465 466 SentErrorPacketsToCE 467 Error Packets sent to CE 468 uint32 469 470 471 BytesSentToCE 472 Bytes sent to CE 473 uint32 474 475 476 SentErrorBytesToCE 477 Error Bytes sent to CE 478 uint32 479 480 481 PacketsReceivedFromCE 482 Packets received from CE 483 uint32 484 485 486 ReceivedErrorPacketsFromCE 487 Error Packets received from CE 488 uint32 489 490 491 BytesReceivedFromCE 492 Bytesreceived from CE 493 uint32 494 495 496 ReceivedErrorBytesFromCE 497 Error Bytes received from CE 498 uint32 499 500 501 503 Properties for LFB instances 505 3.6. Enhancing XML Validation 507 As specified earlier this is not an extension but an enhancement of 508 the schema to provide additional validation rules. This includes 509 adding new key declarations to provide uniqueness as defined by the 510 ForCES Model [RFC5812]. Such validations work only on within the 511 same xml file. 513 The following validation rules have been appended in the original 514 schema in [RFC5812]: 516 1. Each metadata ID must be unique. 518 2. LFB Class IDs must be unique. 520 3. Component ID, Capability ID and Event Base ID must be unique per 521 LFB. 523 4. Event IDs must be unique per LFB. 525 5. Special Values in Atomic datatypes must be unique per atomic 526 datatype. 528 4. XML Extension Schema for LFB Class Library Documents 530 531 536 537 538 Schema for Defining LFB Classes and associated types 539 (frames, data types for LFB attributes, and metadata). 540 541 542 543 544 545 546 547 548 549 551 553 555 557 559 560 562 563 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 593 594 595 596 597 598 599 600 601 603 604 605 606 607 608 609 610 611 612 613 614 616 617 619 620 621 622 623 624 625 628 629 630 631 632 633 634 635 637 638 639 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 672 673 675 677 678 679 680 681 682 683 684 685 687 688 689 690 691 692 693 694 696 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 720 721 722 724 725 727 728 729 730 731 732 733 734 735 736 737 738 740 742 743 744 745 747 748 749 750 751 752 754 755 756 757 759 760 761 762 763 765 766 767 768 769 770 771 772 773 774 775 776 777 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 795 796 797 798 799 800 801 802 803 804 805 807 808 809 810 811 812 813 814 815 816 818 820 822 824 826 828 830 831 833 834 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 856 857 858 859 860 861 862 865 866 867 868 869 870 871 872 873 874 875 876 877 879 880 881 882 883 884 885 886 887 888 890 891 892 893 894 895 896 898 900 901 902 903 904 905 906 907 908 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 935 936 937 938 939 940 941 942 944 945 946 947 948 949 951 953 954 955 956 957 958 959 960 961 963 964 965 966 967 968 969 971 973 974 975 976 977 978 979 981 983 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1029 1030 1031 1033 1034 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1072 1073 1074 1075 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1090 1091 1093 1095 1096 1099 1100 1101 1102 1104 1105 1106 1107 1109 1111 1113 1115 1117 1118 1120 1121 1122 1123 1124 1125 1126 1127 1129 1131 1133 1134 1135 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 OpenFlow XML Library 1148 5. Acknowledgements 1150 The author would like to acknowledge Joel Halpern, Jamal Hadi and 1151 Dave Hood for their comments and discussion that helped shape this 1152 document in a better way. 1154 6. IANA Considerations 1156 This specification requests that LFB Component ID 0 to be reserved. 1158 7. Security Considerations 1160 The security considerations that have been described in the ForCES 1161 Model RFC [RFC5812] apply to this document as well. 1163 8. References 1165 8.1. Normative References 1167 [I-D.ietf-forces-ceha] 1168 Ogawa, K., Wang, W., Haleplidis, E., and J. Salim, "ForCES 1169 Intra-NE High Availability", draft-ietf-forces-ceha-08 1170 (work in progress), October 2013. 1172 [OpenFlowSpec1.1] 1173 http://www.OpenFlow.org/, "The OpenFlow 1.1 1174 Specification.", , . 1177 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 1178 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 1179 Control Element Separation (ForCES) Protocol 1180 Specification", RFC 5810, March 2010. 1182 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 1183 Element Separation (ForCES) Forwarding Element Model", RFC 1184 5812, March 2010. 1186 8.2. Informative References 1188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1189 Requirement Levels", BCP 14, RFC 2119, March 1997. 1191 Author's Address 1192 Evangelos Haleplidis 1193 University of Patras 1194 Department of Electrical and Computer Engineering 1195 Patras 26500 1196 Greece 1198 Email: ehalep@ece.upatras.gr