idnits 2.17.1 draft-haleplidis-forces-implementation-experience-00.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 lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the message is a Query it MUST not have any kind of data inside the PathData. -- The document date (May 12, 2010) is 5097 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ClassID' is mentioned on line 350, but not defined == Missing Reference: 'InstanceID' is mentioned on line 350, but not defined == Missing Reference: 'LFB' is mentioned on line 350, but not defined == Unused Reference: 'RFC2629' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 616, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-forces-applicability-08 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 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 O. Koufopavlou 4 Intended status: Informational S. Denazis 5 Expires: November 13, 2010 University of Patras 6 May 12, 2010 8 ForCES Implementation Experience Draft 9 draft-haleplidis-forces-implementation-experience-00 11 Abstract 13 The forwarding and Control Element Separation (ForCES) protocol 14 defines a standard communication and control mechanism through which 15 a Control Element (CE) can control the behavior of a Forwarding 16 Element (FE). This document captures the experience of implementing 17 the ForCES protocol and model. It's aim is to help others by 18 providing examples and possible strategies for implementing the 19 ForCES protocol. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 13, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Document Goal . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. ForCES Architecture . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Pre-association setup - Initial Configuration . . . . . . 6 62 3.2. TML . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.3.1. Components . . . . . . . . . . . . . . . . . . . . . . 7 65 3.3.2. LFBs . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.4.2. Message Deserialization . . . . . . . . . . . . . . . 11 69 3.4.2.1. Config or Query . . . . . . . . . . . . . . . . . 12 70 4. Developement Platforms . . . . . . . . . . . . . . . . . . . . 14 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 79 1. Terminology and Conventions 81 The terminology that is used is the same as in the FE-protocol 82 [RFC5810] and is not copied in this document. 84 1.1. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Introduction 92 Forwarding and Control Element Separation (ForCES) defines an 93 architectural framework and associated protocols to standardize 94 information exchange between the control plane and the forwarding 95 plane in a ForCES Network Element (ForCES NE). [RFC3654] has defined 96 the ForCES requirements, and [RFC3746] has defined the ForCES 97 framework. 99 The ForCES protocol works in a master-slave mode in which FEs are 100 slaves and CEs are masters. The protocol includes commands for 101 transport of Logical Function Block (LFB) configuration information, 102 association setup, status, and event notifications, etc. The reader 103 is encouraged to read FE-protocol [RFC5810] for further information. 105 The FE-MODEL [RFC5812] presents a formal way to define FE Logical 106 Function Blocks (LFBs) using XML. LFB configuration components, 107 capabilities, and associated events are defined when the LFB is 108 formally created. The LFBs within the FE are accordingly controlled 109 in a standardized way by the ForCES protocol. 111 The TML transports the PL messages. The TML is where the issues of 112 how to achieve transport level reliability, congestion control, 113 multicast, ordering, etc. are handled. It is expected that more than 114 one TML will be standardized. The various possible TMLs could vary 115 their implementations based on the capabilities of underlying media 116 and transport. However, since each TML is standardized, 117 interoperability is guaranteed as long as both endpoints support the 118 same TML. All ForCES Protocol Layer implementations MUST be portable 119 across all TMLs. Although more than one TML may be standardized for 120 the ForCES Protocol, all ForCES implementations MUST implement the 121 SCTP-TML [RFC5811]. 123 The Applicability Statement [I-D.ietf-forces-applicability] captures 124 the applicable areas in which ForCES may be used. 126 2.1. Document Goal 128 This document captures the experience of implementing the ForCES 129 protocol and model and it's main goal is not to tell others how to 130 implement, but to provide alternatives, ideas and proposals as how it 131 can be implemented. 133 Also, this document mentions possible problems and potential choices 134 that can be made, in an attempt to help implementors develop their 135 own products. 137 Additionally this document takes into account that the reader has 138 become familiar with the three main ForCES RFCs, the FE-protocol 139 [RFC5810], the FE-MODEL [RFC5812] and the SCTP-TML [RFC5811]. 141 2.2. Definitions 143 This document follows the terminology defined by the ForCES 144 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 146 3. ForCES Architecture 148 This section discusses the ForCES architecture, difficulties and how 149 to overcome them. 151 3.1. Pre-association setup - Initial Configuration 153 The initial configuration of the FE and the CE respectively is done 154 by the FE Manager and the CE Manager. These entities has not as yet 155 been standardized and anyone can build their own. It is expected 156 that somehow they will talk to each other and exchange details 157 regarding the upcoming associations. Any developer can create any 158 Manager, but at least they should be able to exchange the following 159 details: 161 From the FE side: 163 1. FEID 165 2. FE IP, if your FE and CE will be communicating via network. 167 3. TML. The TML that you will be using. If you skip this, then 168 SCTP MUST be chosen as default from the CE side. 170 4. Priority ports. If you also skip this, then the CE MUST use the 171 default ones from the respective TML RFC. 173 From the CE side: 175 1. CEID 177 2. CE IP, if your FE and CE will be communicating via network. 179 3. TML. The TML that you will be using. If you skip this, then 180 SCTP MUST be chosen as default from the FE side. 182 4. Priority ports. If you also skip this, then the FE MUST use the 183 default ones from the respective TML RFC. 185 3.2. TML 187 All ForCES implementations MUST support the SCTP as TML. Even if 188 another TML will be chosen by the developer, SCTP is mandatory and 189 MUST be supported. 191 There are several issues that should concern a developer for the TML. 193 1. Security. TML must be secure according to the respective RFC. 194 For SCTP you have to use IPSec. 196 2. NAT issues. ForCES can be deployed everywhere and can run over 197 SCTP/IP. If you are behind a NAT, you must forward the TML 198 priority ports to your CE who listens at these ports. The issue 199 is what happens to the ports that the FE uses. Unless you bind 200 the same port numbers to the FE, your FE would have a random port 201 number. This means that port forwarding to the FE must include 202 all sctp ports. The CE can be easily behind a NAT since it will 203 bind the specific sctp ports. In order for the FE to work, it 204 must either have a global IP, or it must bind specific ports that 205 are forwarded to it unless all sctp ports are forwarded to the 206 FE. 208 3.3. Model 210 The model is very dynamic and can be used to model anything. Using 211 the basic atomic values that are defined, new datatypes can be built 212 using atomic (single valued) and/or compound (structures and arrays). 214 The difficulty is to create something that is completely scalable so 215 a develeper doesn't need to write the same code for new LFBs, or for 216 new components etc. Just create code for the defined atomic values 217 and then new components can be built based on already written code. 219 The model itself provides the key which is inheritance. 221 3.3.1. Components 223 First, a basic component needs to be created as the mother of all the 224 components with the basic parameters of all the components: 226 o The ID of the component. 228 o The access rights of that component. 230 o If it is of variable length. 232 o If it is an optional component. 234 o The size of its data. 236 Next, some basic functions are in order: 238 o A common constructor. 240 o A common deconstructor. 242 o Retrieve Component ID. 244 o Retrieve access right property. 246 o Query if it is an optional component. 248 o Get Full Data. 250 o Set Full Data. 252 o Get Sparse Data. 254 o Set Sparse Data. 256 o Del Full Data. 258 o Del Sparse Data. 260 o Get Hardware Value. 262 o Set Hardware Value. 264 o Del Hardware Value. 266 o Get Data. 268 o Clone component. 270 While almost all functions are logical, the last function seems out 271 of place. That function MUST return a new component that has the 272 exact same values and attributes. This function is especially useful 273 in array components. 275 Now any atomic datatype can be built as a child of that basic 276 component which will inherit all the functions and if necessary 277 override the mother's functions. 279 Next struct components can be built. A struct component is a 280 component itself, but contains an array of basic components. The ID 281 of the component is the array index. The Clone function must create 282 and return a similar struct component. 284 The most difficult component to be built is the array. The 285 difficulty lie in the actual benefit of the model. You have absolute 286 freedom over what you build. An array is an array of components. In 287 all rows you have the exact same type of component either a single 288 component or a specific struct. The struct can have multiple basic 289 components, or a combination of basic components, structs and arrays 290 and so on. So, the difficulty lies in how do to create a new row 291 since the array is very dynamic. This is where the clone function is 292 very useful. For the array you need a mother component. Once a set 293 command is received, the mother component can spawn a new component 294 and adds them into the array, and with the set fulldata the value is 295 set in the recently spawned component, as the spawned component knows 296 how the data is created. 298 Once the basic constructors of all possible components are created, 299 then a developer only has to create his LFB components or datatypes 300 as a child of one of the already created components and the only 301 thing the developer really needs to add, is the three functions of 302 Get/Set/Del hardware value of each component. The rest is the same. 304 3.3.2. LFBs 306 The same architecture in the components can be used for the LFBs. 307 The parent LFB has some basic attributes: 309 o The LFB Class ID. 311 o The LFB Instance ID. 313 o An Array of Components. 315 Then some common functions: 317 Handle Configuration Command. 319 Handle Query Command. 321 Get Class ID. 323 Get Instance ID. 325 Once these are created each LFB can inherit all these from the parent 326 and the only thing it has to do is to add the components that have 327 already been created. 329 An example of this is the following. The code next creates a part of 330 FEProtocolLFB: 332 //FEID 333 cui = new Component_uInt(FEPO_FEID, ACCESS_READ_ONLY, FE_id); 334 Components[cui->get_ComponentId()]=cui; //Add component 336 //Current FEHB Policy Value 337 cub = new Component_uByte(FEPO_FEHBPolicy, ACCESS_READ_WRITE, 0); 338 Components[cub->get_ComponentId()]=cub; //Add component 340 //FEIDs for BackupCEs Array 341 cui = new Component_uInt(0, ACCESS_READ_WRITE, 0); 342 ca = new Component_Array(FEPO_BackupCEs, ACCESS_READ_WRITE); 343 ca->AddRow(cui, 1); 344 ca->AddMotherComponent(cui); 345 Components[ca->get_ComponentId()]=ca; //Add BackupCEs Array component 347 Then all it is required is an LFBHandler that will have an array of 348 all the LFBs: 350 LFBs[ClassID][InstanceID][LFB]. 352 3.4. Protocol 354 3.4.1. TLVs 356 Since the model is so free to create anything the developer needs, 357 the protocol itself has been created thus to provide the user the 358 freedom to manipulate any component. This creates some difficulties 359 in developing a scalable architecture for handling the protocol 360 messages. 362 Another difficulty arises from the batching capabilities of the 363 protocol. You can have multiple Operations within a message, you can 364 select more than one LFB to command, and more than one component to 365 manipulate. 367 A possible solution is again provided by inheritance. There are two 368 basic components in a protocol message. 370 1. A main header. 372 2. The rest of the packet. 374 The rest of the packet is divided in Type-Length-Value (TLV) packets, 375 and in one case Index-Length-Value (ILV) packets. 377 The possible TLVs and ILVs the are described in detail in the forces 378 protocol RFC. 380 A TLV's main attributes are: 382 o Type 384 o Length 386 o Data 388 o An array of TLVs. 390 The array of TLVs is the next level of TLVs for this TLV. 392 A TLVs common function could be: 394 o A basic constructor. 396 o A constructor using data from the wire. 398 o Add a new TLV for next level. 400 o Get the next TLV of next level. 402 o Get a specific TLV of next level. 404 o Replace a TLV of next level. 406 o Get the Data. 408 o Get the Length. 410 o Set the Data. 412 o Set the Length. 414 o Set the Type. 416 o Serialize the header. 418 o Serialize the TLV to be written on the wire. 420 Next all TLVs can inherit all these functions and attributes and 421 either override them or create some new functions for each. 423 3.4.2. Message Deserialization 425 What follows is a the algorithm for deserializing any protocol 426 message: 428 1. Get the message header. 430 2. Read the length. 432 3. Check the message type to understand what kind of packet this is. 434 4. If the length is larger than the message header then there is 435 data for this packet. 437 5. A check can be made here regarding the message type and the 438 length of the packet 440 3.4.2.1. Config or Query 442 If the packet is a Query or Config type then for this level there are 443 LFBSelector TLVs: 445 1. Read the next 2 shorts(type-length). If the type==LFBSelector 446 then the message is valid. 448 2. Read the necessary length for this LFBSelector and create the 449 LFBSelector from the data of the wire. 451 3. Add this LFBSelector to the mainheader array of LFBSelectors 453 4. Do this until the rest of the packet has finished. 455 The next level of TLVs are Operation TLVs 457 1. Read the next 2 shorts(type-length). If the type==OperationTLV 458 then the message is valid. 460 2. Read the necessary length for this OperationTLV and create the 461 OperationTLV from the data of the wire. 463 3. Add this OperationTLV to the LFBSelector array of TLVs. 465 4. Do this until the rest of the LFBSelector's Packet has finished. 467 1. Read the next 2 shorts(type-length). If the type==PathData then 468 the message is valid. 470 2. Read the necessary length for this PathDataTLV and create the 471 PathDataTLV from the data of the wire. 473 3. Add this PathData TLV to the Operation TLV's array of TLVs. 475 4. Do this until the rest of the OperationTLV's Packet has finished. 477 Here it gets interesting, as the next level of PathDataTLVs can be 478 either: 480 o PathData TLVs. 482 o FullData TLV. 484 o SparseData TLV. 486 o Result TLVs 488 The solution to this difficulty is recursion. If the next TLV is 489 PathData then the PathData that is created uses the same kind of 490 deserialisation etc. until it reaches a FullData or SparseData. 491 There can be only one FullDataTLV or SparseData within a PathData. 493 1. Read the next 2 shorts(type-length). 495 2. If the Type==PathDataTLV then do again the previous algorithm but 496 add the PathDataTLV to this PathDataTLV's array of TLVs. 498 3. Do this until the rest of the PathData's Packet has finished. 500 4. If the Type==FullDataTLV create the FullData TLV from the packet 501 and add this to the PathData's array of TLVs 503 5. If the Type==SparseDataTLV create the SparseData TLV from the 504 packet and add this to the PathData's array of TLVs 506 6. If the Type==ResultTLV create the Result TLV from the packet and 507 add this to the PathData's array of TLVs 509 If the message is a Query it MUST not have any kind of data inside 510 the PathData. 512 If the message is a Query Response then it MUST either have a 513 ResultTLV or a FullData TLV. 515 If the message is a Config it MUST have inside either a FullDataTLV 516 or a SparseData TLV. 518 If the message is a Config Reponse, it MUST have inside a ResultTLV 520 4. Developement Platforms 522 Any Developmens platfor that can support the SCTP TML and the TML of 523 the developer's choosing is available for use. 525 The next table provides an initial survey of sctp support for C/C++ 526 and Java. 528 /-------------+-------------+-------------+-------------\ 529 |\ Platform | | | | 530 | ----------\ | Windows | Linux | Solaris | 531 | Language \| | | | 532 +-------------+-------------+-------------+-------------+ 533 | | | | | 534 | C/C++ | Supported | Supported | Supported | 535 | | | | | 536 +-------------+-------------+-------------+-------------+ 537 | | Limited | | | 538 | Java | Third Party | Supported | Supported | 539 | | Not from SUN| | | 540 \-------------+-------------+-------------+-------------/ 542 A developer should keep some limitations regarding Java. 544 Java inherently does not support unsigned types. A workaround this 545 can be found in the creation of classes that do the translation of 546 unsigned to java types. The problem is that the unsigned long cannot 547 be used as it is in the Java platform. The proposed set of classes 548 can be found in [Java Unsigned Types]. 550 5. Acknowledgements 552 TBA 554 6. IANA Considerations 556 This memo includes no request to IANA. 558 7. Security Considerations 560 The security considerations of the ForCES framework in [RFC3746] and 561 FE-protocol [RFC5810] are applicable in this document. Implementers 562 or users of ForCES FEs and CEs should take these considerations into 563 account. 565 Also, as specified in the security considerations section of the 566 SCTP-TML RFC [RFC5811] the transport-level security, has to be 567 ensured by TLS (Transport Layer Security). 569 8. References 571 8.1. Normative References 573 [I-D.ietf-forces-applicability] 574 Crouch, A., Khosravi, H., Doria, A., Wang, X., and K. 575 Ogawa, "ForCES Applicability Statement", 576 draft-ietf-forces-applicability-08 (work in progress), 577 February 2010. 579 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 580 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 581 Control Element Separation (ForCES) Protocol 582 Specification", RFC 5810, March 2010. 584 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 585 Layer (TML) for the Forwarding and Control Element 586 Separation (ForCES) Protocol", RFC 5811, March 2010. 588 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 589 Element Separation (ForCES) Forwarding Element Model", 590 RFC 5812, March 2010. 592 8.2. Informative References 594 [Java Unsigned Types] 595 "Classes that support unsigned primitive types for Java. 596 All except the unsigned long", 597 . 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 603 June 1999. 605 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 606 Text on Security Considerations", BCP 72, RFC 3552, 607 July 2003. 609 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 610 of IP Control and Forwarding", RFC 3654, November 2003. 612 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 613 "Forwarding and Control Element Separation (ForCES) 614 Framework", RFC 3746, April 2004. 616 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 617 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 618 May 2008. 620 Authors' Addresses 622 Evangelos Haleplidis 623 University of Patras 624 Patras, 625 Greece 627 Email: ehalep@ece.upatras.gr 629 Odysseas Koufopavlou 630 University of Patras 631 Patras, 632 Greece 634 Email: odysseas@ece.upatras.gr 636 Spyros Denazis 637 University of Patras 638 Patras, 639 Greece 641 Email: sdena@upatras.gr