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