idnits 2.17.1 draft-haleplidis-forces-implementation-experience-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (January 10, 2011) is 4848 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ClassID' is mentioned on line 381, but not defined == Missing Reference: 'Version' is mentioned on line 381, but not defined == Missing Reference: 'InstanceID' is mentioned on line 381, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 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 O. Koufopavlou 4 Intended status: Informational S. Denazis 5 Expires: July 14, 2011 University of Patras 6 January 10, 2011 8 ForCES Implementation Experience Draft 9 draft-haleplidis-forces-implementation-experience-02 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. Its 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 July 14, 2011. 38 Copyright Notice 40 Copyright (c) 2011 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 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Document Goal . . . . . . . . . . . . . . . . . . . . . . 4 58 3. ForCES Architecture . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Pre-association setup - Initial Configuration . . . . . . 6 60 3.2. TML . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.3.1. Components . . . . . . . . . . . . . . . . . . . . . . 7 63 3.3.2. LFBs . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 3.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 3.4.2. Message Deserialization . . . . . . . . . . . . . . . 13 67 3.4.3. Message Serialization . . . . . . . . . . . . . . . . 15 68 4. Developement Platforms . . . . . . . . . . . . . . . . . . . . 17 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 77 1. Terminology and Conventions 79 The terminology used in this document is the same as in the 80 Forwarding and Control Element Separation Protocol [RFC5810] and is 81 not copied in this document. 83 2. Introduction 85 Forwarding and Control Element Separation (ForCES) defines an 86 architectural framework and associated protocols to standardize 87 information exchange between the control plane and the forwarding 88 plane in a ForCES Network Element (ForCES NE). [RFC3654] has defined 89 the ForCES requirements, and [RFC3746] has defined the ForCES 90 framework. 92 The ForCES protocol works in a master-slave mode in which FEs are 93 slaves and CEs are masters. The protocol includes commands for 94 transport of Logical Functional Block (LFB) configuration 95 information, association setup, status, and event notifications, etc. 96 The reader is encouraged to read the Forwarding and Control Element 97 Separation Protocol [RFC5810] for further information. 99 [RFC5812] presents a formal way to define FE Logical Functional 100 Blocks (LFBs) using XML. LFB configuration components, capabilities, 101 and associated events are defined when the LFB is formally created. 102 The LFBs within the Forwarding Element (FE) are accordingly 103 controlled in a standardized way by the ForCES protocol. 105 The Transport Mapping Layer (TML) transports the protocol messages. 106 The TML is where the issues of how to achieve transport level 107 reliability, congestion control, multicast, ordering, etc. are 108 handled. It is expected that more than one TML will be standardized. 109 The various possible TMLs could vary their implementations based on 110 the capabilities of underlying media and transport. However, since 111 each TML is standardized, interoperability is guaranteed as long as 112 both endpoints support the same TML. All ForCES Protocol Layer 113 implementations must be portable across all TMLs. Although more than 114 one TML may be standardized for the ForCES Protocol, all ForCES 115 implementations must implement the SCTP TML [RFC5811]. 117 The Forwarding and Control Element Separation Applicability Statement 118 [RFC6041] captures the applicable areas in which ForCES can be used. 120 2.1. Document Goal 122 This document captures the experience of implementing the ForCES 123 protocol and model and its main goal is not to tell others how to 124 implement, but to provide alternatives, ideas and proposals as how it 125 can be implemented. 127 Also, this document mentions possible problems and potential choices 128 that can be made, in an attempt to help implementors develop their 129 own products. 131 Additionally this document takes into account that the reader has 132 become familiar with the three main ForCES RFCs, the Forwarding and 133 Control Element Separation Protocol [RFC5810], the Forwarding and 134 Control Element Separation Forwarding Element Model [RFC5812] and the 135 SCTP-Based Transport Mapping Layer (TML) for the Forwarding and 136 Control Element Separation Protocol [RFC5811]. 138 3. ForCES Architecture 140 This section discusses the ForCES architecture, implementation 141 challenges and how to overcome them. 143 3.1. Pre-association setup - Initial Configuration 145 The initial configuration of the FE and the Control Element (CE) is 146 done respectively by the FE Manager and the CE Manager. These 147 entities have not as yet been standardized. 149 The simplest solution, are static configuration files, which play the 150 role of the Managers and are read by FEs and CEs. 152 For more dynamic solutions however, it is expected that the Managers 153 will be entities that will talk to each other and exchange details 154 regarding the associations. Any developer can create any Manager, 155 but they should at least be able to exchange the following details: 157 From the FE Manager side: 159 1. FE Identifiers (FEIDs) 161 2. FE IP addresses, if the FEs and CEs will be communicating via 162 network. 164 3. TML. The TML that will be used. If this is omitted, then SCTP 165 must be chosen as default. 167 4. TML Priority ports. If this is omitted as well, then the CE must 168 use the default values from the respective TML RFC. 170 From the CE Manager side: 172 1. CE Identifiers (CEIDs) 174 2. CE IP addresses, if the FEs and CEs will be communicating via 175 network. 177 3. TML. The TML that will be used. If this is omitted, then SCTP 178 must be chosen as default. 180 4. TML Priority ports. If this is omitted as well, then the FE must 181 use the default values 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 RFC. 192 For SCTP you have to use IPSec. 194 2. NAT issues. ForCES can be deployed everywhere and can run over 195 SCTP/IP. In order for the FE and CE to work behind NATs you must 196 ensure that the TML ports are forwarded and that the firewall 197 allows SCTP through. This problem was identified during the 198 first ForCES interoperability test and documented in the 199 Implementation Report for Forwarding and Control Element 200 Separation [RFC6053]. 202 3.3. Model 204 The model inherently is very dynamic. Using the basic atomic values 205 that are specified, new datatypes can be built using atomic (single 206 valued) and/or compound (structures and arrays). 208 The difficulty is to create something that is completely scalable so 209 a develeper doesn't need to write the same code for new LFBs, or for 210 new components etc. Just create code for the defined atomic values 211 and then new components can be built based on already written code. 213 The model itself provides the key which is inheritance. 215 3.3.1. Components 217 First, a basic component needs to be created as the mother of all the 218 components with the basic parameters of all the components: 220 o The ID of the component. 222 o The access rights of that component. 224 o If it is an optional component. 226 o If it is of variable size. 228 o Minimum data size. 230 o Maximum data size. 232 If the data size of the component is not variable, then the size is 233 either the minimum or the maximum size, as both should have the same 234 value. 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 Property 262 o Set Property 264 o Get Value. 266 o Set Value. 268 o Del Value. 270 o Get Data. 272 o Clone component. 274 The Get/Set/Del Full/Sparse Data and Get/Set Property functions 275 handle the respective ForCES commands and return the respective TLV, 276 for example the Set Full Data should return a Result TLV. The Get/ 277 Set/Del Value are called from the Get/Set/Del Full/Sparse Data 278 respectively and provide the interface to the actual values in the 279 hardware, separating the forces handling logic from the interface to 280 the actual values. 282 The Get Data function should return the value of the data only, not 283 in TLV format. 285 The last function seems out of place. That function must return a 286 new component that has the exact same values and attributes. This 287 function is useful in array components as described further. 289 The only requirement is to implement the base atomic data types. Any 290 new atomic datatype can be built as a child of a base data type which 291 will inherit all the functions and if necessary override them. 293 The struct component can then be built. A struct component is a 294 component by itself, but consists of a number of atomic components. 295 These atomic components create a static array within the struct. The 296 ID of each atomic component is the array's index. The Clone 297 function, for a struct component, must create and return an exact 298 copy of the struct component with the same static array. 300 The most difficult component to be built is the array. The 301 difficulty lie in the actual benefit of the model. You have absolute 302 freedom over what you build. An array is an array of components. In 303 all rows you have the exact same type of component either a single 304 component or a struct. The struct can have multiple single 305 components, or a combination of single components, structs and arrays 306 and so on. So, the difficulty lies in how to create a new row, a new 307 component by itself. This is where the Clone function is very 308 useful. For the array a mother component that can spawn new 309 components exactly like itself is needed. Once a Set command is 310 received, the mother component can spawn a new component, if the 311 targeted row does not exists, and add it into the array, and with the 312 Set Full Data the value is set in the recently spawned component, as 313 the spawned component knows how the data is created. In order to 314 distinguish these spawned components from each other and their 315 functionality, some kind of index is required that will also reflect 316 on how the actual data of the specific component is stored on the 317 hardware. 319 Once the basic constructors of all possible components are created, 320 then a developer only has to create his LFB components or datatypes 321 as a child of one of the already created components and the only 322 thing the developer really needs to add, is the three functions of 323 Get/Set/Del value of each component which is platform dependent. The 324 rest stays the same. 326 3.3.2. LFBs 328 The same architecture in the components can be used for the LFBs, 329 allowing a developer to write LFB handling code only once. The 330 parent LFB has some basic attributes: 332 o The LFB Class ID. 334 o The LFB Instance ID. 336 o An Array of Components. 338 o An Array of Capabilities. 340 o An Array of Events. 342 Then some common functions: 344 o Handle Configuration Command. 346 o Handle Query Command. 348 o Get Class ID. 350 o Get Instance ID. 352 Once these are created each LFB can inherit all these from the parent 353 and the only thing it has to do is to add the components that have 354 already been created. 356 An example can be seen in Figure 1. The following code creates a 357 part of FEProtocolLFB: 359 //FEID 360 cui = new Component_uInt(FEPO_FEID, ACCESS_READ_ONLY, FE_id); 361 Components[cui->get_ComponentId()]=cui; //Add component to array list 363 //Current FEHB Policy Value 364 cub = new Component_uByte(FEPO_FEHBPolicy, ACCESS_READ_WRITE, 0); 365 Components[cub->get_ComponentId()]=cub; //Add component to array list 367 //FEIDs for BackupCEs Array 368 cui = new Component_uInt(0, ACCESS_READ_WRITE, 0); 369 ca = new Component_Array(FEPO_BackupCEs, ACCESS_READ_WRITE); 370 ca->AddRow(cui, 1); 371 ca->AddMotherComponent(cui); 372 Components[ca->get_ComponentId()]=ca; //Add component to array list 373 Figure 1: Example code for creating part of FEProtocolLFB 375 The same concept can be applied to handling LFBs as one FE. An FE is 376 a collection of LFBs. Thus all LFBs can be stored in an array based 377 on the LFB's class id, version and instance. Then what is required 378 is an LFBHandler that will handle the array of the LFBs. A specific 379 LFB, for example, can be addressed using the following scheme: 381 LFBs[ClassID][Version][InstanceID]. 383 Note: While an array can be used in components, capabilities and 384 events, a hash table or a similar concept is better suited for 385 storing LFBs using the component ID as the hash key with linked lists 386 for collision handling, as the created array can have large gaps if 387 the values of LFB Class ID vary greatly. 389 3.4. Protocol 391 3.4.1. TLVs 393 The goal, for protocol handling, is to create a general and scalable 394 architecture that handles all protocol messages instead of something 395 implementation specific. There are certain difficulties that have to 396 be overcome first. 398 Since the model allows a developer to define any LFB required, the 399 protocol has been thus created to give the user the freedom to 400 configure and query any component whatever the underlying model. 401 While this being a strong point for the protocol itself, one 402 difficulty lies with the unkwown underlying model and the unlimited 403 number of types of messages that can be created, making creating 404 something generic a daunting task. 406 Another difficulty also arises from the batching capabilities of the 407 protocol. You can have multiple Operations within a message, you can 408 select more than one LFB to command, and more than one component to 409 manipulate. 411 A possible solution is again provided by inheritance. There are two 412 basic components in a protocol message. 414 1. The common header. 416 2. The rest of the message. 418 The rest of the message is divided in Type-Length-Value (TLV) units, 419 and in one case Index-Length-Value (ILV) units. 421 The TLV hierarchy can be seen in the Figure 2: 423 Common Header 424 | 425 +-----------+----------+-----------+ 426 | | | | 427 Redirect LFBSelect ASResult ASTreason 428 TLV TLV TLV TLV 429 | 430 | 431 Operation 432 TLV 433 | 434 | Optional 435 PathData ---> KeyInfo TLV 436 TLV 437 | 438 +----------+---------+----------+ 439 | | | | 440 SparseData Result FullData PathData 441 TLV TLV TLV TLV 443 Figure 2: ForCES TLV Hierrachy 445 The above figure shows only the basic hierarchy level of TLVs and 446 does not show batching. Also this figure does not show the recursion 447 that can occur at the last level of the hierarchy. The figure shows 448 one kind of recursion with PathData within PathData. FullData can be 449 within FullData and SparseData. The possible combination of TLVs are 450 described in detail in the Forwarding and Control Element Separation 451 Protocol [RFC5810] as well as the data packing rules. 453 A TLV's main attributes are: 455 o Type 457 o Length 459 o Data 461 o An array of TLVs. 463 The array of TLVs is the next hierarchy level of TLVs nested in this 464 TLV. 466 A TLVs common function could be: 468 o A basic constructor. 470 o A constructor using data from the wire. 472 o Add a new TLV for next level. 474 o Get the next TLV of next level. 476 o Get a specific TLV of next level. 478 o Replace a TLV of next level. 480 o Get the Data. 482 o Get the Length. 484 o Set the Data. 486 o Set the Length. 488 o Set the Type. 490 o Serialize the header. 492 o Serialize the TLV to be written on the wire. 494 All TLVs inherit these functions and attributes and either override 495 them or create new where it is required. 497 3.4.2. Message Deserialization 499 What follows is a the algorithm for deserializing any protocol 500 message: 502 1. Get the message header. 504 2. Read the length. 506 3. Check the message type to understand what kind of message this 507 is. 509 4. If the length is larger than the message header then there is 510 data for this message. 512 5. A check can be made here regarding the message type and the 513 length of the message 515 If the message is a Query or Config type then for this level there 516 are LFBSelector TLVs: 518 1. Read the next 2 shorts(type-length). If the type is an 519 LFBSelector then the message is valid. 521 2. Read the necessary length for this LFBSelector and create the 522 LFBSelector from the data of the wire. 524 3. Add this LFBSelector to the mainheader array of LFBSelectors 526 4. Do this until the rest of the message has finished. 528 The next level of TLVs are Operation TLVs 530 1. Read the next 2 shorts(type-length). If the type is an 531 OperationTLV then the message is valid. 533 2. Read the necessary length for this OperationTLV and create the 534 OperationTLV from the data of the wire. 536 3. Add this OperationTLV to the LFBSelector array of TLVs. 538 4. Do this until the rest of the LFBSelector TLV has finished. 540 The next level of TLVs are PathData TLVs 542 1. Read the next 2 shorts(type-length). If the type is a PathData 543 then the message is valid. 545 2. Read the necessary length for this PathDataTLV and create the 546 PathDataTLV from the data of the wire. 548 3. Add this PathData TLV to the Operation TLV's array of TLVs. 550 4. Do this until the rest of the Operation TLV is finished. 552 Here it gets interesting, as the next level of PathDataTLVs can be 553 either: 555 o PathData TLVs. 557 o FullData TLV. 559 o SparseData TLV. 561 o Result TLV. 563 The solution to this difficulty is recursion. If the next TLV is 564 PathDataTLV then the PathDataTLV that is created uses the same kind 565 of deserialisation until it reaches a FullDataTLV or SparseDataTLV. 566 There can be only one FullDataTLV or SparseData within a PathData. 568 1. Read the next 2 shorts(type-length). 570 2. If the Type is a PathDataTLV then do again the previous algorithm 571 but add the PathDataTLV to this PathDataTLV's array of TLVs. 573 3. Do this until the rest of the PathData TVL is finished. 575 4. If the Type is a FullDataTLV then create the FullData TLV from 576 the message and add this to the PathData's array of TLVs. 578 5. If the Type is a SparseDataTLV then create the SparseData TLV 579 from the message and add this to the PathData's array of TLVs. 581 6. If the Type is a ResultTLV then create the Result TLV from the 582 message and add this to the PathData's array of TLVs. 584 If the message is a Query it must not have any kind of data inside 585 the PathData. 587 If the message is a Query Response then it must either have a 588 ResultTLV or a FullData TLV. 590 If the message is a Config it must have inside either a FullDataTLV 591 or a SparseData TLV. 593 If the message is a Config Reponse, it must have inside a ResultTLV. 595 More details regarding message validation can be be read in Section 7 596 of the Forwarding and Control Element Separation Protocol [RFC5810]. 598 Note: When deserializing, implementors must take care to ignore 599 padding of TLVs as all must be 32-bit aligned. The length value in 600 TLVs includes the Type and Length (4 bytes) but does not include 601 padding. 603 3.4.3. Message Serialization 605 The same concept can be applied in the message creation process. 606 Having the TLVs ready, a developer can go bottom up. All that is 607 required is the serialization function that will transform the TLV 608 into bytes ready to be transfered on the network. 610 For example for the creation of a simple query from the CE to the FE, 611 all the PathData are created. Then they will be serialized and 612 inserted into an Operation TLV, which in turn will be serialized and 613 inserted into an LFB Selector and in turn serialized and entered into 614 the Common Header which will be passed to the TML to be transported 615 to the FE. 617 Having an array of TLVs inside a TLV that are next in the TLV 618 hierarchy, allows the developer to insert any number of next level 619 TLVs thus creating any kind of message. 621 Note: When the TLV is serialized to be written on the wire, 622 implementors must take care to include padding to TLVs as all must be 623 32-bit aligned. 625 4. Developement Platforms 627 Any development platform that can support the SCTP TML and the TML of 628 the developer's choosing is available for use. 630 Figure 3 provides an initial survey of SCTP support for C/C++ and 631 Java at present time. 633 /-------------+-------------+-------------+-------------\ 634 |\ Platform | | | | 635 | ----------\ | Windows | Linux | Solaris | 636 | Language \| | | | 637 +-------------+-------------+-------------+-------------+ 638 | | | | | 639 | C/C++ | Supported | Supported | Supported | 640 | | | | | 641 +-------------+-------------+-------------+-------------+ 642 | | Limited | | | 643 | Java | Third Party | Supported | Supported | 644 | | Not from SUN| | | 645 \-------------+-------------+-------------+-------------/ 647 Figure 3: SCTP Support on Operating Systems 649 A developer should be aware of some limitations regarding Java 650 implementations. 652 Java inherently does not support unsigned types. A workaround this 653 can be found in the creation of classes that do the translation of 654 unsigned to java types. The problem is that the unsigned long cannot 655 be used as is in the Java platform. The proposed set of classes can 656 be found in [Java Unsigned Types]. 658 5. Acknowledgements 660 The authors would like to thank Adrian Farrel for sponsoring this 661 document and Jamal Hadi Salim for discussions to make this document 662 better. 664 6. IANA Considerations 666 This memo includes no request to IANA. 668 7. Security Considerations 670 Developers of ForCES FEs and CEs should take the security 671 considerations of the Forwarding and Control Element Separation 672 Framework [RFC3746] and the Forwarding and Control Element Separation 673 Protocol [RFC5810] into account. 675 Also, as specified in the security considerations section of the 676 SCTP-Based Transport Mapping Layer (TML) for the Forwarding and 677 Control Element Separation Protocol [RFC5811] the transport-level 678 security, has to be ensured by IPSec. 680 8. References 682 8.1. Normative References 684 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 685 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 686 Control Element Separation (ForCES) Protocol 687 Specification", RFC 5810, March 2010. 689 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 690 Layer (TML) for the Forwarding and Control Element 691 Separation (ForCES) Protocol", RFC 5811, March 2010. 693 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 694 Element Separation (ForCES) Forwarding Element Model", 695 RFC 5812, March 2010. 697 [RFC6041] Crouch, A., Khosravi, H., Doria, A., Wang, X., and K. 698 Ogawa, "Forwarding and Control Element Separation (ForCES) 699 Applicability Statement", RFC 6041, October 2010. 701 [RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim, 702 "Implementation Report for Forwarding and Control Element 703 Separation (ForCES)", RFC 6053, November 2010. 705 8.2. Informative References 707 [Java Unsigned Types] 708 "Classes that support unsigned primitive types for Java. 709 All except the unsigned long", 710 . 712 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 713 of IP Control and Forwarding", RFC 3654, November 2003. 715 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 716 "Forwarding and Control Element Separation (ForCES) 717 Framework", RFC 3746, April 2004. 719 Authors' Addresses 721 Evangelos Haleplidis 722 University of Patras 723 Patras, 724 Greece 726 Email: ehalep@ece.upatras.gr 728 Odysseas Koufopavlou 729 University of Patras 730 Patras, 731 Greece 733 Email: odysseas@ece.upatras.gr 735 Spyros Denazis 736 University of Patras 737 Patras, 738 Greece 740 Email: sdena@upatras.gr