diff options
Diffstat (limited to 'doc/rfc/rfc6369.txt')
| -rw-r--r-- | doc/rfc/rfc6369.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc6369.txt b/doc/rfc/rfc6369.txt new file mode 100644 index 0000000..557b18f --- /dev/null +++ b/doc/rfc/rfc6369.txt @@ -0,0 +1,1011 @@ + + + + + + +Internet Engineering Task Force (IETF) E. Haleplidis +Request for Comments: 6369 O. Koufopavlou +Category: Informational S. Denazis +ISSN: 2070-1721 University of Patras + September 2011 + + + Forwarding and Control Element Separation (ForCES) + Implementation Experience + +Abstract + + The Forwarding and Control Element Separation (ForCES) protocol + defines a standard communication and control mechanism through which + a Control Element (CE) can control the behavior of a Forwarding + Element (FE). This document captures the experience of implementing + the ForCES protocol and model. Its aim is to help others by + providing examples and possible strategies for implementing the + ForCES protocol. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6369. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + + + + +Haleplidis, et al. Informational [Page 1] + +RFC 6369 ForCES Implementation Experience September 2011 + + + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Document Goal . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 + 3. ForCES Architecture . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Pre-Association Setup - Initial Configuration . . . . . . 5 + 3.2. TML . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.3.1. Components . . . . . . . . . . . . . . . . . . . . . . 6 + 3.3.2. LFBs . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.4.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.4.2. Message Deserialization . . . . . . . . . . . . . . . 13 + 3.4.3. Message Serialization . . . . . . . . . . . . . . . . 15 + 4. Development Platforms . . . . . . . . . . . . . . . . . . . . 15 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 + +1. Introduction + + Forwarding and Control Element Separation (ForCES) defines an + architectural framework and associated protocols to standardize + information exchange between the control plane and the forwarding + plane in a ForCES Network Element (ForCES NE). [RFC3654] defines the + ForCES requirements, and [RFC3746] defines the ForCES framework. + + The ForCES protocol works in a master-slave mode in which Forwarding + Elements (FEs) are slaves and Control Elements (CEs) are masters. + The protocol includes commands for transport of Logical Functional + Block (LFB) configuration information, association setup, status, and + event notifications, etc. The reader is encouraged to read the + Forwarding and Control Element Separation Protocol [RFC5810] for + further information. + + [RFC5812] presents a formal way to define FE LFBs using XML. LFB + configuration components, capabilities, and associated events are + defined when LFBs are formally created. The LFBs within the + Forwarding Element (FE) are accordingly controlled in a standardized + way by the ForCES protocol. + + + + +Haleplidis, et al. Informational [Page 2] + +RFC 6369 ForCES Implementation Experience September 2011 + + + The Transport Mapping Layer (TML) transports the protocol messages. + The TML is where the issues of how to achieve transport-level + reliability, congestion control, multicast, ordering, etc., are + handled. It is expected that more than one TML will be standardized. + The various possible TMLs could vary their implementations based on + the capabilities of underlying media and transport. However, since + each TML is standardized, interoperability is guaranteed as long as + both endpoints support the same TML. All ForCES protocol layer + implementations must be portable across all TMLs. Although more than + one TML may be standardized for the ForCES protocol, all ForCES + implementations must implement the Stream Control Transmission + Protocol (SCTP) TML [RFC5811]. + + The Forwarding and Control Element Separation Applicability Statement + [RFC6041] captures the applicable areas in which ForCES can be used. + +1.1. Document Goal + + This document captures the experience of implementing the ForCES + protocol and model, and its main goal is to provide alternatives, + ideas, and proposals as how it can be implemented, not to tell others + how to implement it. + + Also, this document mentions possible problems and potential choices + that can be made, in an attempt to help implementors develop their + own products. + + Additionally, this document assumes that the reader has become + familiar with the three main ForCES RFCs: the Forwarding and Control + Element Separation Protocol [RFC5810], the Forwarding and Control + Element Separation Forwarding Element Model [RFC5812], and the SCTP- + Based Transport Mapping Layer (TML) for the Forwarding and Control + Element Separation Protocol [RFC5811]. + +2. Terminology and Conventions + + The terminology used in this document is the same as in the + Forwarding and Control Element Separation Protocol [RFC5810]; some of + the definitions below are copied from that document. + + Control Element (CE): A logical entity that implements the ForCES + protocol and uses it to instruct one or more FEs on how to process + packets. CEs handle functionality such as the execution of control + and signaling protocols. + + + + + + + +Haleplidis, et al. Informational [Page 3] + +RFC 6369 ForCES Implementation Experience September 2011 + + + Forwarding Element (FE): A logical entity that implements the ForCES + protocol. FEs use the underlying hardware to provide per-packet + processing and handling as directed/controlled by one or more CEs via + the ForCES protocol. + + LFB (Logical Functional Block): The basic building block that is + operated on by the ForCES protocol. The LFB is a well-defined, + logically separable functional block that resides in an FE and is + controlled by the CE via the ForCES protocol. The LFB may reside at + the FE's data path and process packets or may be purely an FE control + or configuration entity that is operated on by the CE. Note that the + LFB is a functionally accurate abstraction of the FE's processing + capabilities but not a hardware-accurate representation of the FE + implementation. + + LFB Class and LFB Instance: LFBs are categorized by LFB classes. An + LFB instance represents an LFB class (or type) existence. There may + be multiple instances of the same LFB class (or type) in an FE. An + LFB class is represented by an LFB class ID, and an LFB instance is + represented by an LFB instance ID. As a result, an LFB class ID + associated with an LFB instance ID uniquely specifies an LFB + existence. + + LFB Component: Operational parameters of the LFBs that must be + visible to the CEs are conceptualized in the FE model as the LFB + components. The LFB components include, for example, flags, single + parameter arguments, complex arguments, and tables that the CE can + read and/or write via the ForCES protocol. + + ForCES Protocol: While there may be multiple protocols used within + the overall ForCES architecture, the terms "ForCES protocol" and + "protocol" refer to the Fp reference points in the ForCES framework + [RFC3746]. This protocol does not apply to CE-to-CE communication, + FE-to-FE communication, or communication between FE and CE Managers. + Basically, the ForCES protocol works in a master-slave mode in which + FEs are slaves and CEs are masters. This document defines the + specifications for this ForCES protocol. + +3. ForCES Architecture + + ForCES has undergone two successful interoperability tests, where + very few issues were caught and resolved. + + This section discusses the ForCES architecture, implementation + challenges, and ways to overcome these challenges. + + + + + + +Haleplidis, et al. Informational [Page 4] + +RFC 6369 ForCES Implementation Experience September 2011 + + +3.1. Pre-Association Setup - Initial Configuration + + The initial configuration of the FE and the CE is done by the FE + Manager and the CE Manager, respectively. These entities have not as + yet been standardized. + + The simplest solution is static configuration files, which play the + role of the Managers and are read by FEs and CEs. + + For more dynamic solutions, however, it is expected that the Managers + will be entities that will talk to each other and exchange details + regarding the associations. Any developer can create any Manager, + but they should at least be able to exchange the details below. + + From the FE Manager side: + + 1. FE Identifiers (FEIDs). + + 2. FE IP addresses, if the FEs and CEs will be communicating via + network. + + 3. TML. The TML that will be used. If this is omitted, then SCTP + must be chosen as default. + + 4. TML priority ports. If this is omitted as well, then the CE must + use the default values from the respective TML RFC. + + From the CE Manager side: + + 1. CE Identifiers (CEIDs). + + 2. CE IP addresses, if the FEs and CEs will be communicating via + network. + + 3. TML. The TML that will be used. If this is omitted, then SCTP + must be chosen as default. + + 4. TML priority ports. If this is omitted as well, then the FE must + use the default values from the respective TML RFC. + +3.2. TML + + All ForCES implementations must support the SCTP TML. Even if + another TML will be chosen by the developer, SCTP is mandatory and + must be supported. + + + + + + +Haleplidis, et al. Informational [Page 5] + +RFC 6369 ForCES Implementation Experience September 2011 + + + There are several issues that should concern a developer for the TML: + + 1. Security. TML must be secure according to the respective RFC. + For SCTP, you have to use IPsec. + + 2. Remote connection. While ForCES is meant to be used locally, + both interoperability tests have proven that ForCES can be + deployed everywhere that SCTP/IP is available. In both + interoperability tests, there were connections between Greece and + China, and the performance was very satisfactory. However, in + order for the FE and CE to work in a non-local environment, an + implementor must ensure that the SCTP-TML ports are forwarded to + the CE and/or FE if they are behind NATs; if there is a firewall, + it will allow the SCTP ports through. These were identified + during the first ForCES interoperability test and documented in + the Implementation Report for Forwarding and Control Element + Separation [RFC6053]. + +3.3. Model + + The ForCES model is inherently very dynamic. Using the basic atomic + data types that are specified in the model, new atomic (single + valued) and/or compound (structures and arrays) datatypes can be + built. Thus, developers are free to create their own LFBs. One + other advantage that the ForCES model provides is inheritance. New + versions of existing LFBs can be created to suit any extra developer + requirements. + + The difficulty for a developer is to create an architecture that is + completely scalable so there is no need to write the same code for + new LFBs, new components, etc. Developers can just create code for + the defined atomic values, and new components can then be built based + on already written code, thus reusing it. + + The model itself provides the key, which is inheritance. + +3.3.1. Components + + First, a basic component needs to be created as the mother of all the + components that has the basic parameters of all the components: + + o The ID of the component. + + o The access rights of the component. + + o If it is an optional component. + + o If it is of variable size. + + + +Haleplidis, et al. Informational [Page 6] + +RFC 6369 ForCES Implementation Experience September 2011 + + + o Minimum data size. + + o Maximum data size. + + If the data size of the component is not variable, then the size is + either the minimum or the maximum size, as both should have the same + value. + + Next, some basic functions are in order: + + o A common constructor. + + o A common destructor. + + o Retrieve Component ID. + + o Retrieve access right property. + + o Query if it is an optional component. + + o Get Full Data. + + o Set Full Data. + + o Get Sparse Data. + + o Set Sparse Data. + + o Del Full Data. + + o Del Sparse Data. + + o Get Property. + + o Set Property. + + o Get Value. + + o Set Value. + + o Del Value. + + o Get Data. + + o Clone component. + + + + + + +Haleplidis, et al. Informational [Page 7] + +RFC 6369 ForCES Implementation Experience September 2011 + + + The Get/Set/Del Full Data, Get/Set/Del Sparse Data, and Get/Set + Property functions handle the respective ForCES commands and return + the respective TLV, for example, Set Full Data should return a + RESULT-TLV. The Get Value, Set Value, and Del Value functions are + called from Get Full/Sparse Data, Set Full/Sparse Data, and Del Full/ + Sparse Data respectively and provide the interface to the actual + values in the hardware, separating the forces handling logic from the + interface to the actual values. + + The Get Data function should return the value of the data only, not + in TLV format. + + The Clone function seems out of place. This function must return a + new component that has the exact same values and attributes. This + function is useful in array components as described further below. + + The only requirement is to implement the base atomic data types. Any + new atomic datatype can be built as a child of a base data type, + which will inherit all the functions and, if necessary, override + them. + + The struct component can then be built. A struct component is a + component by itself but consists of a number of atomic components. + These atomic components create a static array within the struct. The + ID of each atomic component is the array's index. For a struct + component, the Clone function must create and return an exact copy of + the struct component with the same static array. + + The most difficult component to be built is the array. The + difficulty lies in the actual benefit of the model: you have absolute + freedom over what you build. An array is an array of components. In + all rows, you have the exact same type of component, either a single + component or a struct. The struct can have multiple single + components or a combination of single components, structs, arrays, + and so on. So, the difficulty lies in how to create a new row, a new + component by itself. This is where the Clone function is very + useful. For the array, a mother component that can spawn new + components exactly like itself is needed. Once a Set command is + received, the mother component can spawn a new component if the + targeted row does not exist and add it into the array; with the Set + Full Data function, the value is set in the recently spawned + component, as the spawned component knows how the data is created. + In order to distinguish these spawned components from each other and + their functionality, some kind of index is required that will also + reflect how the actual data of the specific component is stored on + the hardware. + + + + + +Haleplidis, et al. Informational [Page 8] + +RFC 6369 ForCES Implementation Experience September 2011 + + + Once the basic constructors of all possible components are created, + then a developer only has to create LFB components or datatypes as a + child of one of the already-created components, and the only thing + the developer really needs to add is the three functions of Get + Value, Set Value, and Del Value of each component, which is platform + dependent. The rest stays the same. + +3.3.2. LFBs + + The same architecture in the components can be used for the LFBs, + allowing a developer to write LFB handling code only once. The + parent LFB has some basic attributes: + + o The LFB Class ID. + + o The LFB Instance ID. + + o An Array of Components. + + o An Array of Capabilities. + + o An Array of Events. + + Following are some common functions: + + o Handle Configuration Command. + + o Handle Query Command. + + o Get Class ID. + + o Get Instance ID. + + Once these are created, each LFB can inherit all these from the + parent, and the only thing it has to do is add the components that + have already been created. + + An example can be seen in Figure 1. The following code creates a + part of FEProtocolLFB: + + + + + + + + + + + + +Haleplidis, et al. Informational [Page 9] + +RFC 6369 ForCES Implementation Experience September 2011 + + + //FEID + cui = new Component_uInt(FEPO_FEID, ACCESS_READ_ONLY, FE_id); + Components[cui->get_ComponentId()]=cui; //Add component to array list + + //Current FEHB Policy Value + cub = new Component_uByte(FEPO_FEHBPolicy, ACCESS_READ_WRITE, 0); + Components[cub->get_ComponentId()]=cub; //Add component to array list + + //FEIDs for BackupCEs Array + cui = new Component_uInt(0, ACCESS_READ_WRITE, 0); + ca = new Component_Array(FEPO_BackupCEs, ACCESS_READ_WRITE); + ca->AddRow(cui, 1); + ca->AddMotherComponent(cui); + Components[ca->get_ComponentId()]=ca; //Add component to array list + + Figure 1: Example Code for Creating Part of FEProtocolLFB + + The same concept can be applied to handling LFBs as one FE. An FE is + a collection of LFBs. Thus, all LFBs can be stored in an array based + on the LFB's class id, version, and instance. Then, what is required + is an LFBHandler that will handle the array of LFBs. A specific LFB, + for example, can be addressed using the following scheme: + + LFBs[ClassID][Version][InstanceID] + + Note: While an array can be used in components, capabilities, and + events, a hash table or a similar concept is better suited for + storing LFBs using the component ID as the hash key with linked lists + for collision handling, as the created array can have large gaps if + the values of LFB Class ID vary greatly. + +3.4. Protocol + +3.4.1. TLVs + + The goal for protocol handling is to create a general and scalable + architecture that handles all protocol messages instead of something + implementation specific. There are certain difficulties that have to + be overcome first. + + Since the model allows a developer to define any LFB required, the + protocol has been thus created to give the user the freedom to + configure and query any component, whatever the underlying model. + While this is a strong point for the protocol itself, one difficulty + lies with the unknown underlying model and the unlimited number of + types of messages that can be created, making creating generic code a + daunting task. + + + + +Haleplidis, et al. Informational [Page 10] + +RFC 6369 ForCES Implementation Experience September 2011 + + + Additionally, the protocol also allows two different path approaches + to LFB components, and the CE or FE must handle both or even a mix of + them, making a generic decoding of the protocol message difficult. + + Another difficulty also arises from the batching capabilities of the + protocol. You can have multiple Operations within a message; you can + select more than one LFB to command and more than one component to + manipulate. + + A possible solution is again provided by inheritance. There are two + basic components in a protocol message: + + 1. The common header. + + 2. The rest of the message. + + The rest of the message is divided in Type-Length-Value (TLV) units + and, in one case, Index-Length-Value (ILV) units. + + The TLV hierarchy can be seen in Figure 2: + + Common Header + | + +---------------+---------------+---------------+ + | | | | + REDIRECT-TLV LFBselect-TLV ASResult-TLV ASTreason-TLV + | + | + OPER-TLV + | + | + PATH-DATA-TLV ---> Optional KEYINFO-TLV + | + +-------------+-------------+-------------+ + | | | | + SPARSEDATA-TLV RESULT-TLV FULLDATA-TLV PATH-DATA-TLV + + Figure 2: ForCES TLV Hierarchy + + The above figure shows only the basic hierarchical level of TLVs and + does not show batching. Also, this figure does not show the + recursion that can occur at the last level of the hierarchy. The + figure shows one kind of recursion with a PATH-DATA-TLV within a + PATH-DATA-TLV. A FULLDATA-TLV can be within a FULLDATA-TLV and a + SPARSEDATA-TLV. The possible combination of TLVs are described in + detail in the Forwarding and Control Element Separation Protocol + [RFC5810] as well as the data-packing rules. + + + + +Haleplidis, et al. Informational [Page 11] + +RFC 6369 ForCES Implementation Experience September 2011 + + + A TLV's main attributes are: + + o Type. + + o Length. + + o Data. + + o An array of TLVs. + + The array of TLVs is the next hierarchical level of TLVs nested in + this TLV. + + A TLV's common function could be: + + o A basic constructor. + + o A constructor using data from the wire. + + o Add a new TLV for next level. + + o Get the next TLV of next level. + + o Get a specific TLV of next level. + + o Replace a TLV of next level. + + o Get the Data. + + o Get the Length. + + o Set the Data. + + o Set the Length. + + o Set the Type. + + o Serialize the header. + + o Serialize the TLV to be written on the wire. + + All TLVs inherit these functions and attributes and either override + them or create new where it is required. + + + + + + + + +Haleplidis, et al. Informational [Page 12] + +RFC 6369 ForCES Implementation Experience September 2011 + + +3.4.2. Message Deserialization + + Following is an algorithm for deserializing any protocol message: + + 1. Get the message header. + + 2. Read the length. + + 3. Check the message type to understand what kind of message this + is. + + 4. If the length is larger than the message header, then there is + data for this message. + + 5. A check can be made here regarding the message type and the + length of the message. + + If the message is a Query or Config type, then there are LFBselect- + TLVs for this level: + + 1. Read the next 2 shorts(type-length). If the type is an + LFBselect-TLV, then the message is valid. + + 2. Read the necessary length for this LFBselect-TLV, and create the + LFBselect-TLV from the data of the wire. + + 3. Add this LFBselect-TLV to the main header array of LFBselect- + TLVs. + + 4. Repeat all above steps until the rest of the message has + finished. + + The next level of TLVs is OPER-TLVs. + + 1. Read the next 2 shorts(type-length). If the type is an OPER-TLV, + then the message is valid. + + 2. Read the necessary length for this OPER-TLV, and create the OPER- + TLV from the data of the wire. + + 3. Add this OPER-TLV to the LFBselect-TLV array of TLVs. + + 4. Do this until the rest of the LFBselect-TLV has finished. + + The next level of TLVs is PATH-DATA-TLVs. + + 1. Read the next 2 shorts(type-length). If the type is a PATH-DATA- + TLV, then the message is valid. + + + +Haleplidis, et al. Informational [Page 13] + +RFC 6369 ForCES Implementation Experience September 2011 + + + 2. Read the necessary length for this PATH-DATA-TLV, and create the + PATH-DATA-TLV from the data of the wire. + + 3. Add this PATH-DATA-TLV to the OPER-TLV's array of TLVs. + + 4. Do this until the rest of the OPER-TLV is finished. + + Here it gets interesting, as the next level of PATH-DATA-TLVs can be + one of the following: + + o PATH-DATA-TLVs. + + o FULLDATA-TLV. + + o SPARSEDATA-TLV. + + o RESULT-TLV. + + The solution to this difficulty is recursion. If the next TLV is a + PATH-DATA-TLV, then the PATH-DATA-TLV that is created uses the same + kind of deserialization until it reaches a FULLDATA-TLV or + SPARSEDATA-TLV. There can be only one FULLDATA-TLV or SPARSEDATA-TLV + within a PATH-DATA-TLV. + + 1. Read the next 2 shorts(type-length). + + 2. If the Type is a PATH-DATA-TLV, then repeat the previous + algorithm but add the PATH-DATA-TLV to this PATH-DATA-TLV's array + of TLVs. + + 3. Do this until the rest of the PATH-DATA-TLV is finished. + + 4. If the Type is a FULLDATA-TLV, then create the FULLDATA-TLV from + the message and add this to the PATH-DATA-TLV's array of TLVs. + + 5. If the Type is a SPARSEDATA-TLV, then create the SPARSEDATA-TLV + from the message and add this to the PATH-DATA-TLV's array of + TLVs. + + 6. If the Type is a RESULT-TLV, then create the RESULT-TLV from the + message and add this to the PATH-DATA-TLV's array of TLVs. + + If the message is a Query, it must not have any kind of data inside + the PATH-DATA-TLV. + + If the message is a Query Response, then it must have either a + RESULT-TLV or a FULLDATA-TLV. + + + + +Haleplidis, et al. Informational [Page 14] + +RFC 6369 ForCES Implementation Experience September 2011 + + + If the message is a Config, it must contain either a FULLDATA-TLV or + a SPARSEDATA-TLV. + + If the message is a Config Response, it must contain a RESULT-TLV. + + More details regarding message validation can be read in Section 7 of + the Forwarding and Control Element Separation Protocol [RFC5810]. + + Note: When deserializing, implementors must take care to ignore + padding of TLVs as all must be 32-bit aligned. The length value in + TLVs includes the Type and Length (4 bytes) but does not include + padding. + +3.4.3. Message Serialization + + The same concept can be applied in the message creation process. + Having the TLVs ready, a developer can go bottom up. All that is + required is the serialization function that will transform the TLV + into bytes ready to be transferred on the network. + + For example, for the creation of a simple query from the CE to the + FE, all the PATH-DATA-TLVs are created. Then they will be serialized + and inserted into an OPER-TLV, which in turn will be serialized and + inserted into an LFBselect-TLV. The LFBselect-TLV will then be + serialized and entered into the Common Header, which will be passed + to the TML to be transported to the FE. + + Having an array of TLVs inside a TLV that is next in the TLV + hierarchy allows the developer to insert any number of next-level + TLVs, thus creating any kind of message. + + Note: When the TLV is serialized to be written on the wire, + implementors must take care to include padding to TLVs as all must be + 32-bit aligned. + +4. Development Platforms + + Any development platform that can support the SCTP TML and the TML of + the developer's choosing is available for use. + + Figure 3 provides an initial survey of SCTP support for C/C++ and + Java at the present time. + + + + + + + + + +Haleplidis, et al. Informational [Page 15] + +RFC 6369 ForCES Implementation Experience September 2011 + + + /-------------+-------------+-------------+-------------\ + |\ Platform | | | | + | ----------\ | Windows | Linux | Solaris | + | Language \| | | | + +-------------+-------------+-------------+-------------+ + | | | | | + | C/C++ | Supported | Supported | Supported | + | | | | | + +-------------+-------------+-------------+-------------+ + | | Limited | | | + | Java | Third Party | Supported | Supported | + | | Not from SUN| | | + \-------------+-------------+-------------+-------------/ + + Figure 3: SCTP Support on Operating Systems + + A developer should be aware of some limitations regarding Java + implementations. + + Java inherently does not support unsigned types. A workaround can be + found in the creation of classes that do the translation of unsigned + types to Java types. The problem is that the unsigned long cannot be + used as-is in the Java platform. The proposed set of classes can be + found in [JavaUnsignedTypes]. + +5. Acknowledgements + + The authors would like to thank Adrian Farrel for sponsoring this + document and Jamal Hadi Salim for discussions that made this document + better. + +6. Security Considerations + + Developers of ForCES FEs and CEs must take the Security + Considerations of the Forwarding and Control Element Separation + Framework [RFC3746] and the Forwarding and Control Element Separation + Protocol [RFC5810] into account. + + Also, as specified in the Security Considerations section of the + SCTP-Based Transport Mapping Layer (TML) for the Forwarding and + Control Element Separation Protocol [RFC5811], transport-level + security has to be ensured by IPsec. + + + + + + + + + +Haleplidis, et al. Informational [Page 16] + +RFC 6369 ForCES Implementation Experience September 2011 + + +7. References + +7.1. Normative References + + [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, + W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and + Control Element Separation (ForCES) Protocol + Specification", RFC 5810, March 2010. + + [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping + Layer (TML) for the Forwarding and Control Element + Separation (ForCES) Protocol", RFC 5811, March 2010. + + [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control + Element Separation (ForCES) Forwarding Element Model", + RFC 5812, March 2010. + + [RFC6041] Crouch, A., Khosravi, H., Doria, A., Wang, X., and K. + Ogawa, "Forwarding and Control Element Separation (ForCES) + Applicability Statement", RFC 6041, October 2010. + + [RFC6053] Haleplidis, E., Ogawa, K., Wang, W., and J. Hadi Salim, + "Implementation Report for Forwarding and Control Element + Separation (ForCES)", RFC 6053, November 2010. + +7.2. Informative References + + [JavaUnsignedTypes] + "Java Unsigned Types", + <http://nam.ece.upatras.gr/index.php?q=node/44>. + + [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation + of IP Control and Forwarding", RFC 3654, November 2003. + + [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, + "Forwarding and Control Element Separation (ForCES) + Framework", RFC 3746, April 2004. + + + + + + + + + + + + + + +Haleplidis, et al. Informational [Page 17] + +RFC 6369 ForCES Implementation Experience September 2011 + + +Authors' Addresses + + Evangelos Haleplidis + University of Patras + Department of Electrical & Computer Engineering + Patras 26500 + Greece + + EMail: ehalep@ece.upatras.gr + + + Odysseas Koufopavlou + University of Patras + Department of Electrical & Computer Engineering + Patras 26500 + Greece + + EMail: odysseas@ece.upatras.gr + + + Spyros Denazis + University of Patras + Department of Electrical & Computer Engineering + Patras 26500 + Greece + + EMail: sdena@upatras.gr + + + + + + + + + + + + + + + + + + + + + + + + +Haleplidis, et al. Informational [Page 18] + |