ForCES Working Group Internet Draft D. Putzolu (editor) Document: draft-putzolu-forces-evaluation-01.txt Intel Expires: April 2004 October 2003 ForCES Protocol Evaluation Draft Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides an evaluation of the applicability of three proposed approaches for a ForCES protocol: FACT[2], GRMP[3], and Netlink2[4]. A summary of each of the proposed protocols against the ForCES requirements[5] and the ForCES framework[6] is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [7]. Putzolu Expires - April 2004 [Page 1] ForCES Protocol Evaluation Draft October 2003 Table of Contents 1. Introduction...................................................2 2. Protocol Proposals.............................................3 2.1 FACT.......................................................4 2.2 GRMP.......................................................4 2.3 Netlink2...................................................7 3. Architectural Requirements Compliance Evaluation...............7 3.1 FACT.......................................................7 3.2 GRMP.......................................................7 3.3 Netlink2...................................................9 4. Model Requirements Compliance Evaluation.......................9 4.1 FACT......................................................10 4.2 GRMP......................................................10 4.3 Netlink2..................................................11 5. Protocol Requirements Compliance Evaluation...................11 5.1 Protocol Requirement: Configuration of Modeled Elements...11 5.2 Protocol Requirement: Support for Secure Communication....13 5.3 Protocol Requirement: Scalability.........................14 5.4 Protocol Requirement: Multihop............................15 5.5 Protocol Requirement: Message Priority....................16 5.6 Protocol Requirement: Reliability.........................17 5.7 Protocol Requirement: Interconnect Independence...........18 5.8 Protocol Requirement: CE Redundancy or CE Failover........19 5.9 Protocol Requirement: Packet Redirection/Mirroring........20 5.10 Protocol Requirement: Topology Exchange..................21 5.11 Protocol Requirement: Dynamic Association................22 5.12 Protocol Requirement: Command Bundling...................22 5.13 Protocol Requirement: Asynchronous Event Notification....23 5.14 Protocol Requirement: Query Statistics...................24 5.15 Protocol Requirement: Protection Against Denial of Service Attacks.......................................................25 5.16 Protocol Requirement Summary Table.......................26 Security Considerations..........................................27 References.......................................................27 Acknowledgments..................................................28 Author's Addresses...............................................28 1. Introduction This document provides an evaluation of the applicability of FACT, GRMP, and Netlink2 as the ForCES protocol. This evaluation provides overviews of the protocols and general statements of applicability based upon the ForCES framework and requirements documents. The format and structure as well as some of the introductory content of this document is based on and taken from a similar document being produced in the MIDCOM working group[8]. Putzolu et al. Expires - April 2004 [Page 2] ForCES Protocol Evaluation Draft October 2003 The process for protocol evaluation found in this document consists of individuals providing sections evaluating a specific protocol. These sections are incorporated by the editor of the document, and are subject to feedback and changes based on the consensus of the ForCES working group. Some protocols that might be considered as potentially applicable as the ForCES protocol are not evaluated in this document since there where no champions to submit evaluations for them. Section 2 of this document is a list of the proposed protocols along with background information about each of the protocols. Section 3 of this document is an evaluation of the proposed protocols against the architectural requirements found in section 5 of the ForCES requirements. The purpose of this section is to determine how well each of the proposed protocols maps to the ForCES architecture. Section 4 of this document is an evaluation of the proposed protocols against the model requirements found in ForCES requirements. The purpose of this section is to determine how well each of the proposed protocols can be used with FEs that meet the ForCES model requirements. Section 5 of this document is an item level evaluation of the proposed protocols against the protocol requirements found in the ForCES requirements. The purpose of this section is to determine how well each of the proposed protocols satisfies each of the protocol requirements. Section 6 summarizes the evaluation, and includes a table with a breakdown for each of the protocols versus the requirements. The following categories of compliance are used: Fully met, partially met through the use of extensions, partially met through other changes to the protocol, or not met. This summary is not a conclusive statement of the suitability of the protocols, but rather to provide information to be considered as input into the overall protocol decision process. 2. Protocol Proposals The following protocols have been submitted to the ForCES WG for consideration: o FACT o GRMP o Netlink2 The following sections provide overviews of each of the protocols as well as relevant background information about each protocol. Putzolu et al. Expires - April 2004 [Page 3] ForCES Protocol Evaluation Draft October 2003 2.1 FACT Network Elements (NE) such as routers are becoming more and more complex as they try to cope with demanding features like policy based routing, firewalls and NATs, and QoS aware routing. As a result, issues like scalability, (the ability to cost-effectively grow a network as demand increases) and extensibility (the ability to dynamically configure the network for some specific services by programming the NEs that handle those services) become very important. The ForCEs protocol has been specified to help resolve these issues by decoupling control and forwarding elements of a network element, and also adding extensibility features to the NE. FACT (Forwarding And Control ElemenT) protocol has been designed for exchanging information between control elements (CEs) and forwarding elements (FEs) distributed in a ForCES network element (NE). The relationship between CEs and FEs is a master/slave one. The FACT protocol is logically separated into a base protocol and an extensible data model defined in [9]. It consists of a common, fixed size header and variable size payload which carries the information defined by the data model. All FACT messages are 32-bit aligned. FACTÆs messages are grouped into six (6) classes namely: 1) Connection and Association messages, which help establish logical connections between FEs and CEs, 2) Capabilities Control messages, which the CE uses to query and configure the capabilities of the FE, 3) State Maintenance messages, which are used to track element states, 4) Traffic Maintenance messages, which are used exchanging control packets between CEs and FEs, 5) Event Notification messages used for reporting asynchronous events, and 6) Vendor Specific messages which are used to extend the protocol beyond its current capabilities. FACT supports versioning and priority, and its unique design of separating control and data traffic into different channels helps reduce the threat of Denial of Service (DoS) attacks making the protocol more robust. It provides reliability by using a reliable transport protocol, thus simplifying the protocol design. It also provides failover mechanisms that can exploit redundant elements in the system or network element. 2.2 GRMP General Router Management Protocol (GRMP) Version 1 is intended to be as a ForCES protocol, which acts at the Fp reference point in the Putzolu et al. Expires - April 2004 [Page 4] ForCES Protocol Evaluation Draft October 2003 ForCES framework. GRMP is designed to meet all the requirements for the ForCES protocol at the Fp reference point. GRMP protocol is a master-slave protocol. CEs act as masters and FEs as slaves. Slaves only have right to send to masters request or query, response, and report messages. While masters can send command messages to slaves as well as request or query, response, and report messages. GRMP protocol acts in a mode of a base-protocol associated with a data model, which is FE model in ForCES. That is, GRMP only defines basic management messages, while many of managed data are defined in the associated ForCES FE model. Most of the data types and functional descriptions relating to specific IP services such as routing service conforming to RFC 1812 [10], QoS configurations, high-tough capabilities like NAT and firewall should be expressed by Logical functional Blocks (LFBs) defined by ForCES FE model and their specific LFB topologies. GRMP application layer is responsible to configure the LFBs and the LFB topologies so as to implement specific IP services and QoS deployment. GRMP is developed separately from General Switch Management Protocol (GSMP) protocol since current base specification version of GSMP did not support some of the basic functionality needed by GRMP. However, GRMP has been considering its possible compatibility with GSMP; with the work currently ongoing within the GSMP group that is adding flexibility to the base, GRMP is willing to work with the GSMP group to integrate this with GSMP. GRMP protocol is composed of protocol messages. GRMP organizes these messages according to different object types the messages manage for ForCES architecture, as follows: 1. FE management messages This type of messages is for FE layer operations, that is, to take a whole FE as a managed object. Messages of this type include that for operation of FE join or leave, FE action, FE attribute, FE event report, etc. 2. LFB management messages This type of messages is for LFB layer operations. It takes LFBs as its managed objects. Messages of this type include that for operation of LFB action, LFB attribute, etc. 3. Datapath management messages This type of messages is for the management of datapaths in an FE. It takes datapathes as the managed objects. 4. CE Informing messages This type of messages takes CE as the operated object to ask CE to send some information. Because CE acts as a master in ForCES Putzolu et al. Expires - April 2004 [Page 5] ForCES Protocol Evaluation Draft October 2003 protocol, allowed operations toward CE from FE are only that like CE query request, CE event report, etc. 5. GRMP slave management In GRMP, the GRMP slave part is treated as a module inside an FE. This module is outside of FE model scope, which will automatically be launched in a FE when the FE is to join a ForCES NE. Management to a GRMP slave is that like DoS protection policy, CE or FE failover policy, etc. Note that the management of GRMP slave does not take specific GRMP messages, in stead, it uses FE management messages for GRMP slave is considered as an object at FE layer. 6. Managed Object(MO) management messages In order to meet ForCES requirement of supporting network management tools like SNMP, GRMP provides the management messages. This type of messages takes a Managed Object (MO) defined in some specific network management tools as its managed objects. Operations of MOs are that like MO get, MO set, and MO response. There is another GRMP message that is defined out of scope of management purposes. This is GRMP ACK (acknowledge) message, which is mainly for communication control and error control purpose between CE and FE. From perspective the message communication types between CE and FE, GRMP messages can be divided into following types: 1. Messages for query and response types. These messages can be sent from CE to FE, or from FE to CE. 2. Messages for command and configuration types. These messages are only sent from CE to FE. 3. Messages for report types. These messages can be sent from CE to FE, or from FE to CE. In GRMP, a 5 bits "object class" identifier [3 Section 3.4.5] is applied to following GRMP managed objects: FE capability types FE attribute types LFB types LFB attribute types CE attribute types CE event types Currently defined "object class" includes GRMP class, different version of ForCES FE model class, vendor class. This means the managed objects above can include that defined by GRMP itself, different versions of ForCES FE models, and different vendors. Putzolu et al. Expires - April 2004 [Page 6] ForCES Protocol Evaluation Draft October 2003 2.3 Netlink2 3. Architectural Requirements Compliance Evaluation This section contains a review of each protocol proposalÆs level of compliance to the ForCES architecture requirements. Many of the architectural requirements will be instantiated in some fashion in the protocol selected. Given that the architectural requirements are not direct protocol requirements, the review below will consist of prose rather than specific levels of compliance as is used in the protocol section below. 3.1 FACT FACT fulfills all the protocol requirements listed in section 5. By doing this it in turn supports all the architectural requirements defined in the ForCES Requirements [5]. FACT supports the separation of the NE into CE and FE components, with CE handling roles such as control, signaling and routing data calculation. The CE configures the FE with all the information necessary for the FEÆs proper operation. The FEÆs functions could be layer-3 forwarding, NAT, metering, shaping, firewall, etc. Also, FACT state maintenance messages help resolve the various states of the distributed CEs and FEs to provide a unified state of the NE. 3.2 GRMP GRMP protocol is designed based on the ForCES architecture requirements. We review its compliance to the architecture requirements according to the individual requirement items as below: 1) For architecture requirement #1 GRMP packets can be transported via any suitable mediums, such as TCP/IP, Ethernet, ATM fabrics, and bus backplanes. Because of the design consideration for GRMP to be compatible with GSMP protocol, packet encapsulations defined for GSMP protocols as in RFC 3293 can also be applied to GRMP. 2) For architecture requirement #2 ForCES requires that FEs MUST support a minimal set of capabilities necessary for establishing network connectivity (e.g., interface discovery, port up/down functions). This process is usually out of the range of ForCES protocol, but GRMP protocol has no restriction on this functionality. 3) For architecture requirement #3 Putzolu et al. Expires - April 2004 [Page 7] ForCES Protocol Evaluation Draft October 2003 By properly configuring FEs with their LFBs in a NE via GRMP protocol, packets can arrive at one FE and depart at the other FE or FEs. In the case where more than one CE work simultaneously in a NE, the consistency and synchronization of control of the CEs is essential for above functionality, which is beyond the scope of ForCES protocol and also architecture requirements. 4) For architecture requirement #4 By properly configuring LFBs in FEs in a NE via GRMP protocol, the NE can appear as a single functional device in a network. In the case more than one CE work simultaneously in a NE, the consistency and synchronization for the CEs to control FEs is essential for this functionality, which is beyond the scope of ForCES protocol and architecture requirements. 5) For architecture requirement #5 ForCES protocol requirement #2 has comprised this architecture requirement, refer to Section 5.2.2 for details on GRMP compliance to this requirement. 6) For architecture requirement #6 Please refer to Section 5.13.2 for details. 7) For architecture requirement #7 Please refer to Section 5.8.2 for details. 8) For architecture requirement #8 Please refer to Section 5.9.2 for details. 9) For architecture requirement #9 GRMP supports RFC1812 [10] compliant router functions by means of following mechanisms in GRMP: -Fully supporting ForCES FE model -Packet redirection messages -Datapath management messages -Managed Object(MO) management messages 10) For architecture requirement #10 In GRMP, FE topology query and response messages [3 Section 4.1.3] are used for CEs to query FE topology information in a NE. 11) For architecture requirement #11 Please refer to Section 5.3.2 for details. 12) For architecture requirement #12 Please refer to Section 5.11.2 for details. 13) For architecture requirement #13 Putzolu et al. Expires - April 2004 [Page 8] ForCES Protocol Evaluation Draft October 2003 GRMP supports multiple FEs working together in a NE by using FE identifiers and by allowing CEs to be informed of FE topology information. GRMP supports multiple CEs working together in a NE by supporting CE redundancy or failover functionality. 14) For architecture requirement #14 GRMP defines Managed Object (MO) management messages [3 Section 4.5] to meet the requirement, in which it states that it must not be possible for management tools (e.g. SNMP, etc) to change the state of a FE in a manner that affects overall NE behavior without the CE being notified. A MO is an object defined by some network management tool, such as the object defined by Object Identifier in SNMP MIBs. MO management messages work in the way as below: 1. Query of MOs resident in an FE can be directly implemented by network management tools. To perform this, it is necessary for CE to configure some LFBs that has high touch capability in the FE. 2. Change of MOs resident in an FE can only be made via a CE. To do this, the high touch LFBs in the FE will redirect all network management protocol messages like SNMP messages concerning MO changes to the CE, then the CE will use the MO management messages to change values of MOs in the FE. Of course, if necessary, query of the MOs can also be made via the CE. 3. MOs resident in a CE can be directly queried or changed by the CE with the CE high tough capability. Before the CE can do this, network management messages are still needed to be redirected from FEs to the CE. 3.3 Netlink2 4. Model Requirements Compliance Evaluation This section contains a review of each protocolÆs level of compliance to the ForCES model requirements. The ForCES model will indirectly relate to the protocol in that the protocol will be used to carry information that the model represents. Given that the model requirements are only indirectly related to the protocol selection, the review below will consist of prose rather than specific levels of compliance as is used in the protocol section below. Putzolu et al. Expires - April 2004 [Page 9] ForCES Protocol Evaluation Draft October 2003 4.1 FACT The FACT protocol is logically separated into a base protocol and an extensible payload which can be used to carry the FE, Logical Functional Block (LFB) specific data which is defined by the FE Model [9]. Thus the FACT protocol is cleanly separated from the data model that it carries. The FE Model draft [9] defines the data model for the Forwarding Element and meets all the Model requirements. FACTÆs Configure Request and Configure Response message types under the Capabilities Control message group provide a flexible way to configure the functionality of the FE according to the FE Model [9]. The specific parameters needed to assign functionalities and behaviors to the Logical Functional Blocks (LFBs) in the FEs are dictated by the FE Model. Vendor Specific functions are supported by VS-Data request and VS- Data response messages in the Vendor Specific message group. 4.2 GRMP GRMP protocol is designed to use ForCES FE model as a base data model for the protocol functionality. GRMP aims to support all operations to all elements defined in ForCES FE model. Because ForCES FE model work is still in progress, following elements for ForCES FE model (including capability model and state model) with their operations are presented in current version of GRMP document: -FE capabilities -FE attributes, including FE statistics -FE events -LFBs with their attributes (including capabilities, statistics, etc), their actions, and their topologies -Datapaths Section 5.1.2 has described GRMP supported management for modeled elements including all above ForCES FE model elements in details. Along with the progress in ForCES FE model work, a modification of GRMP can be made to coordinate with the modification in ForCES FE model. GRMP supports ForCES FE model to meet following model requirements without any restriction from the protocol: 1. Types of logical functions 2. Variations of logical functions 3. Ordering of logical functions 4. Flexibility 5. Minimal set of logical functions Putzolu et al. Expires - April 2004 [Page 10] ForCES Protocol Evaluation Draft October 2003 4.3 Netlink2 5. Protocol Requirements Compliance Evaluation This section contains a review of each protocolÆs level of compliance to the ForCES protocol requirements. Given that the protocol requirements are directly related to the protocol proposals, a very concrete method is used in reviewing compliance - the following key identifies the level of compliance for each of the following protocols to each protocol requirement in the ForCES requirements RFC: T = Total compliance. Meets the requirement fully. P+ = Partial compliance. Fundamentally meets the requirement through the use of extensions (e.g. packages, additional parameters, etc.) P = Partial compliance. Meets some aspect of the requirement, however, the necessary changes require more than an extension and/or are inconsistent with the design intent of the protocol. N = Not compliant. Does not meet the requirement. Each subsection of this section begins with the specific protocol requirement text found in the ForCES requirements. 5.1 Protocol Requirement: Configuration of Modeled Elements The ForCES protocol MUST allow the CEs to determine the capabilities of each FE. These capabilities SHALL be expressed using the FE model whose requirements are defined in Section 6. Furthermore, the protocol MUST provide a means for the CEs to control all the FE capabilities that are discovered through the FE model. The protocol MUST be able to add/remove classification/action entries, set/delete parameters, query statistics, and register for and receive events. 5.1.1 FACT Compliance = T FACTÆs Capabilities Control message class contains Configure Request and Configure Response messages that can be used to configure the FEÆs behavior from the CE. Also, the Capability request and response messages can be used by the CE to query and learn the FE capabilities. Please see section 5.2 in [2] for more details on this. Putzolu et al. Expires - April 2004 [Page 11] ForCES Protocol Evaluation Draft October 2003 5.1.2 GRMP Most of GRMP protocol messages are for the management of modeled elements in ForCES FEs. They are listed as follows: 1) FE capability query and response messages [3 section 4.1.4] The messages allow a CE to query and get response of the capabilities of a FE. The FE capabilities include all FE capability types that are defined by vendors or this GRMP protocol itself, as well as defined in FE model. 2) FE attribute manipulate message [3 section 4.1.6] This message allows a CE to manipulate (add, delete, modify) attributes of a FE. The FE attributes should be the type of FE attributes that are allowed to be manipulated. They may be defined in FE model, by vendors or by GRMP itself. 3) FE attribute query and response messages [3 section 4.1.7] The messages allow a CE to query and get response of FE attribute values. The FE attributes should be the types of FE attributes that are allowed to be queried. The queried FE attribute may be defined in FE model, by vendors or by GRMP itself. Note that FE attributes include FE level statistics. 4) FE event report message [3 section 4.1.8] This message allows a FE to report events to a CE. The FE events include all events that are defined in FE model, by vendors and by GRMP itself. Some FE events may need to be registered by a CE before they are willing to send reports to the CE, but the others may need not. An FE attribute defined by GRMP itself (as a GRMP class object) is used for a CE to register its interested FE events [3 Section 4.1.6-Page29]. 5) LFB action manipulate message [3 section 4.2.1]. This message allows a CE to manipulate LFB actions in a FE ( LFB add, delete, modify, up, down, active, inactive, etc). The LFBs may be that defined in FE model, by vendors or by GRMP itself. Note that the LFB action manipulate message for LFB add operation has also included the operation to configure LFB topologies. In GRMP protocol, LFB topology is represented by means of PkfIDs [3 Section 3.4.6] [3 Section 4.2.1]. 6) LFB topology query and response messages [3 section 4.2.2] The messages allow a CE to query and get response of whole or some LFB topologies within a FE. The LFB topology representation is based on PkfIDs. 7) LFB attribute manipulate message [3 section 4.2.3]. Putzolu et al. Expires - April 2004 [Page 12] ForCES Protocol Evaluation Draft October 2003 This message allows a CE to manipulate (add, delete, or modify) LFB attributes in a FE. The LFB attributes include all attributes that are allowed to be manipulated in a LFB, and they may be defined via FE model, by vendors or by GRMP itself. 8) LFB attribute query and response messages [3 section 4.2.4] The messages allow a CE to query and get response of LFB attribute values in a FE. Note that LFB attributes include LFB level capabilities, statistics, etc. 9) Datapath Manipulate Message [3 section 4.3.1] This message allows a CE to manipulate (add, delete, modify) datapaths that interconnect LFBs in a FE. Datapaths are represented by PkfIDs. 10) Datapath query and response messages [3 section 4.3.2] The messages allow a CE to query and get response of connection status of all or some datapaths in a LFB topology in a FE. Protocol requirement compliance level: ( ) 5.1.3 Netlink2 5.2 Protocol Requirement: Support for Secure Communication a) FE configuration will contain information critical to the functioning of a network (e.g. IP Forwarding Tables). As such, it MUST be possible to ensure the integrity of all ForCES protocol messages and protect against man-in-the-middle attacks. b) FE configuration information may also contain information derived from business relationships (e.g. service level agreements). Because of the confidential nature of the information, it MUST be possible to secure (make private) all ForCES protocol messages. c) In order to ensure that authorized CEs and FEs are participating in a NE and defend against CE or FE impersonation attacks, the ForCES architecture MUST select a means of authentication for CEs and FEs. d) In some deployments ForCES is expected to be deployed between CEs and FEs connected to each other inside a box over a backplane, where physical security of the box ensures that man-in-the-middle, snooping, and impersonation attacks are not possible. In such scenarios the ForCES architecture MAY rely on the physical security of the box to defend against these attacks and protocol mechanisms May be turned off. e) In the case when CEs and FEs are connected over a network, security mechanisms MUST be specified or selected that protect the Putzolu et al. Expires - April 2004 [Page 13] ForCES Protocol Evaluation Draft October 2003 ForCES protocol against such attacks. Any security solution used for ForCES MUST specify how it deals with such attacks. 5.2.1 FACT Compliance = T FACT uses TLS when its endpoints are running over an IP network or in an insecure environment. For a closed box or physically secure environment, it is possible to turn off the protocol security functions. The security association between the CEs and FEs is established before any FACT association establishment messages are exchanged. Also, FACT recommends using rate limiting mechanisms on the FE to protect against DoS attacks. Please see section 8 in [2] for more details on this. 5.2.2 GRMP 1) When GRMP messages are encapsulated in a IP based medium, GRMP protocol has recommended to use IPsec or TLS(only for reliable transport protocols), which is also recommended by ForCES framework, to secure the communication between CEs and FEs to defend against possible man-in-the-middle or replay attacks and to do authentication for CEs and FEs. GRMP has no restrictions on using other approaches for secure communications. 2) When GRMP messages are transported via bus backplanes, the secure mechanism is allowed to be turned off while without affecting GRMP functions. 3) Current version of GRMP has not yet recommended secure mechanisms for GRMP messages to transmit over Ethernet or ATM mediums. Protocol requirement compliance level: ( ) 5.2.3 Netlink2 5.3 Protocol Requirement: Scalability The ForCES protocol MUST be capable of supporting (i.e., must scale to) at least hundreds of FEs and tens of thousands of ports. For example, the ForCES protocol field sizes corresponding to FE or port numbers SHALL be large enough to support the minimum required numbers. This requirement does not relate to the performance of a NE as the number of FEs or ports in the NE grows. 5.3.1 FACT Putzolu et al. Expires - April 2004 [Page 14] ForCES Protocol Evaluation Draft October 2003 Compliance = T FACT can support up to 64K FEs and 64K CEs at the same time due its 16 bit addressing range of both the CE-Tag and FE-Identifier fields. Please see section 4.1 in [2] for more details on this. In addition, it uses TCP (for IP interconnection between CEs and FEs) which provides congestion control and thus helps in supporting the scalability requirement. 5.3.2 GRMP In GRMP, a FE is identified by a 16 bits FE Identifier [3 section 3.2], which is theoretically able to identify up to 64k FEs. Possible limitation in GRMP protocol to FE port number may be from FE port address space, maximum number of list elements in "list data format" [3 section 3.4.3], and LFB instance identifier space. The evaluations of scalability for them are as follows: 1) An Addressable Entity (AE) address data format is defined in GRMP [3 section 3.4.4], which is theoretically capable of describing any length of addresses of AEs, therefore FE port address space is not limited. 2) Element number of a list in "list data format" [3 section 3.4.3] is expressed with 16 bits data space, which theoretically limits list element number within 64k. 3) LFB instance ID [3 section 4.2.1] is expressed using 16 bits data space, which can also theoretically represent 64k instances of one kind of LFB such as a port LFB. Protocol requirement compliance level: ( ) 5.3.3 Netlink2 5.4 Protocol Requirement: Multihop When the CEs and FEs are separated beyond a single hop, the ForCES protocol will make use of an existing RFC2914 compliant L4 protocol with adequate reliability, security and congestion control (e.g. TCP, SCTP) for transport purposes. 5.4.1 FACT Compliance = T Putzolu et al. Expires - April 2004 [Page 15] ForCES Protocol Evaluation Draft October 2003 FACT uses TCP as the transport protocol which is congestion aware and meets the transport requirements for multi-hop IP networks. Please see section 3.2 in [2] for more details on this. 5.4.2 GRMP GRMP is designed in its aims to be capable of supporting remote control that allows CEs and FEs to separate multihops away, as well as supporting close or very close proximity control of CEs and FEs. GRMP has no restriction for ForCES NE administrators to use any RFC 2914 compliant L4 protocols such as TCP or SCTP as interconnection protocols to increase the control reliability, security and congestion control ability, though current document of GRMP has missed making a recommendation on this. Besides, GRMP is seeking the possibility to potentially support L3 layer QoS based traffic control between CEs and FEs with the use of scheduling mechanisms in GRMP slave module [3 section 4.6.1]. Protocol requirement compliance level: ( ) 5.4.3 Netlink2 5.5 Protocol Requirement: Message Priority The ForCES protocol MUST provide a means to express the protocol message priorities. 5.5.1 FACT Compliance = T FACT supports up to 8 levels of priority using the 3 priority bits in the common header. Please see section 4.1.6 in [2] for more details on this. 5.5.2 GRMP GRMP defines a priority field (P) at GRMP message header [3 section 3.2] to express the protocol message priority. Currently only two priority levels are defined: normal priority and high priority. Protocol requirement compliance level: ( ) 5.5.3 Netlink2 Putzolu et al. Expires - April 2004 [Page 16] ForCES Protocol Evaluation Draft October 2003 5.6 Protocol Requirement: Reliability a) The ForCES protocol will be used to transport information that requires varying levels of reliability. By strict or robust reliability in this requirement we mean, no losses, no corruption, no re-ordering of information being transported and delivery in a timely fashion. b) Some information or payloads, such as redirected packets or packet sampling, may not require robust reliability (can tolerate some degree of losses). For information of this sort, ForCES MUST NOT be restricted to strict reliability. c) Payloads such as configuration information, e.g. ACLs, FIB entries, or FE capability information (described in section 7, (1)) are mission critical and must be delivered in a robust reliable fashion. Thus, for information of this sort, ForCES MUST either provide built-in protocol mechanisms or use a reliable transport protocol for achieving robust/strict reliability. d) Some information or payloads, such as heartbeat packets that may be used to detect loss of association between CE and FEs (see section 7, (8)), may prefer timeliness over reliable delivery. For information of this sort, ForCES MUST NOT be restricted to strict reliability. e) When ForCES is carried over multi-hop IP networks, it is a requirement that ForCES MUST use a RFC 2914 [11]-compliant transport protocol. f) In cases where ForCES is not running over an IP network such as an Ethernet or cell fabric between CE and FE, then reliability still MUST be provided when carrying critical information of the types specified in (c) above, either by the underlying link/network/transport layers or by built-in protocol mechanisms. 5.6.1 FACT Compliance = T FACT uses a reliable transport protocol to meet all the reliability requirements. For IP-interconnection between the protocol elements, FACT uses TCP as the transport protocol for the control channel. Please see section 3.2 in [2] for more details on this. 5.6.2 GRMP GRMP supplies two levels of built-in error control mechanisms and several other mechanisms to improve the protocol reliability: 1) Normal level error control In this level, GRMP protocol uses a specific GRMP ACK message [3 Section 3.4.1] associated with "Result" and "Code" fields in GRMP message headers [3 Section 3.2] to protect against errors that may result from message transmission, message processing, or message Putzolu et al. Expires - April 2004 [Page 17] ForCES Protocol Evaluation Draft October 2003 generation. The "Result" field can be set to "NoAck", "NoSuccessAck", "AckAll", and "SuccessAck" [3 Section 3.2] to ask the message receiver to send or not to send ACK message. According to the different importance and requirement of individual GRMP messages, recommendations have been made in GRMP for their values of ôResultö in the message header. As an example, GRMP packet redirection messages have been recommended to use "NoAck" value. 2) High level error control If higher level of reliability is required for some protocol messages, a built-in error control based on CRC-32 checksums can furthermore be applied [3 Section 3.2]. A tag in GRMP message header is used to optionally turn on or turn off the checksum mechanism. Note that checksum error control can only improve the protocol transmission reliability, therefore it can well fit for the case when GRMP protocol is running over a comparatively unreliable medium such as Ethernet or backplane where error control may not be supplied by the medium itself. 3) Transaction identifier to control the order of messages GRMP has defined different transaction identifiers for CE generated messages and for FE generated messages [3 Section 3.2]. This makes it possible to use protocol built-in method to order back protocol messages if in occasional cases messages are reordered. 4) QoS control of message transmission A scheduler is applied in GRMP slave model, which is not only for protection against DoS attacks but also able to supply some sorts of QoS controls such as bandwidth and priorities for GRMP message transmission so as to improve the protocol reliability regarding the timeliness of transmission. This is especially applicable when GRMP is applied in a single hop scenario. GRMP has no restriction on the use of any L4 layer protocols to improve the protocol reliability. Protocol requirement compliance level: ( ) 5.6.3 Netlink2 5.7 Protocol Requirement: Interconnect Independence The ForCES protocol MUST support a variety of interconnect technologies. (refer to section 5, requirement# 1) 5.7.1 FACT Putzolu et al. Expires - April 2004 [Page 18] ForCES Protocol Evaluation Draft October 2003 Compliance = T FACT uses interconnect independent addressing (FE Identifier, CE tag) in its common header to provide interconnect independence. For non-IP interconnects, such as ATM, an interconnect specific encapsulation will have to be defined to carry the FACT messages. For IP interconnects, FACT uses TCP as the transport protocol. Please see section 3.1 in [2] for more details on this. 5.7.2 GRMP GRMP packets can be transported via any suitable mediums, such as TCP/IP, Ethernet, ATM fabrics, and bus backplanes. Because of the design consideration for GRMP to be compatible with GSMP protocol, packet encapsulations defined for GSMP protocols as in RFC 3293 can also be applied to GRMP. Protocol requirement compliance level: ( ) 5.7.3 Netlink2 5.8 Protocol Requirement: CE Redundancy or CE Failover The ForCES protocol MUST support mechanisms for CE redundancy or CE failover. This includes the ability for CEs and FEs to determine when there is a loss of association between them, ability to restore association and efficient state (re)synchronization mechanisms. This also includes the ability to preset the actions an FE will take in reaction to loss of association to its CE e.g., whether the FE will continue to forward packets or whether it will halt operations. (refer to section 5, requirement# 7) 5.8.1 FACT Compliance = T FACT exchanges CE and FE element states using the PE State Maintenance messages. FACT also uses Heart-Beat messages (section 5.3 in [2]) to detect protocol element (CE or FE) failure or loss of association between elements and to trigger a switch-over to a functioning redundant element (CE or FE). Please see section 7.3 in [2] for more details on the different mechanisms (Strong consistency, weak consistency) used for CE failover. 5.8.2 GRMP GRMP meets ForCES CE redundancy or CE failover requirement by means of following mechanisms: Putzolu et al. Expires - April 2004 [Page 19] ForCES Protocol Evaluation Draft October 2003 1) CE failover or leave policy [3 Section 4.6.4] This policy is defined as a FE attribute and is setup via FE attribute manipulate message [3 Section 4.1.5]. The policy is usually set to a FE immediately after the FE is added to a ForCES NE and before it actually begins to provide IP service. In this policy attribute, selectable FE policies toward the CE failover are defined, which include graceful restart, going inactive, etc. In addition, CE re-association policies such as just waiting or trying to find out an alternative CE among a CE list are simultaneously defined. 2) FE heartbeat policy [3 Section 4.6.6] The ability to determine the loss of association between a CE and a FE can be achieved in GRMP by use of this FE heartbeat policy, which is also defined as a GRMP class FE attribute. In this policy attribute, policies for the FE to receive heartbeats from a CE and to send heartbeats to a CE are individually defined. After the heartbeat policy attribute is set, the FE can then optionally send heartbeat signals to a CE or receive and process heartbeat signals from a CE. Heartbeat signals are sent by use of GRMP FE or CE event report messages. Protocol requirement compliance level: ( ) 5.8.3 Netlink2 5.9 Protocol Requirement: Packet Redirection/Mirroring a) The ForCES protocol MUST define a way to redirect packets from the FE to the CE and vice-versa. Packet redirection terminates any further processing of the redirected packet at the FE. b) The ForCES protocol MUST define a way to mirror packets from the FE to the CE. Mirroring allows the packet duplicated by the FE at the mirroring point to be sent to the CE while the original packet continues to be processed by the FE. Examples of packets that may be redirected or mirrored include control packets (such as RIP, OSPF messages) addressed to the interfaces or any other relevant packets (such as those with Router Alert Option set). The ForCES protocol MUST also define a way for the CE to configure the behavior of a) and b) (above), to specify which packets are affected by each. 5.9.1 FACT Compliance = T FACTÆs Traffic Maintenance Message class includes Control Packet Redirect and Control Packet Forward messages to achieve packet redirection/mirroring. These messages are sent over the separate data Putzolu et al. Expires - April 2004 [Page 20] ForCES Protocol Evaluation Draft October 2003 channel. Please see section 5.4 in [2] for more details on this. Also, the Event Register/Deregister messages (section 5.5 in [2]) can be used to specify which packets should be redirected. 5.9.2 GRMP GRMP supports packet redirection by packet redirection messages [3 Section 4.7]. A LFB within LFB topology in a FE should be used to filter out packets that are to be redirected. Packets to be redirected are first put in GRMP slave [3 Section 4.6.1] and then be directed to a CE via GRMP packet redirection message. The attribute of this filter LFB are set by CEs, therefore the CE has the ability to control which packets can be redirected. For example, CE may want to filter out packets that are considered from DoS attackers. To redirect packets from CE to FE, CE just needs to encapsulate the packet to be redirected in the packet redirection message and send it to the FE. On the FE side, another LFB is used to resolve redirected packets from CE and to put the packets into datapaths in a FE LFB topology so that they can further be delivered by the FE. By use of the packet redirection message and by properly configuring LFBs in FE, a packet can be mirrored to CE instead of purely redirected to CE. That is, the packet is duplicated and one is redirected to CE and the other continues its way in the LFB topology. Protocol requirement compliance level: ( ) 5.9.3 Netlink2 5.10 Protocol Requirement: Topology Exchange The ForCES protocol MUST allow the FEs to provide their topology information (topology by which the FEs in the NE are connected) to the CE(s). (refer to section 5, requirement# 10) 5.10.1 FACT Compliance = T FACTÆs Capabilities and Control Message class includes Topology request and response messages to achieve topology information exchange between the CE and FEs. Please see sections 5.2.5, 5.2.6 in [2] for more details on this. 5.10.2 GRMP Putzolu et al. Expires - April 2004 [Page 21] ForCES Protocol Evaluation Draft October 2003 In GRMP, FE topology query and response messages [3 Section 4.1.3] are used for CEs to query FE topology information in the NE. Protocol requirement compliance level: ( ) 5.10.3 Netlink2 5.11 Protocol Requirement: Dynamic Association The ForCES protocol MUST allow CEs and FEs to join and leave a NE dynamically. (refer to section 5, requirement# 12) 5.11.1 FACT Compliance = T FACTÆs Connection and Association message class includes Join request, Join response, Leave request and Leave response messages to enable dynamic joining and leaving of protocol elements (CEs, FEs) in the NE. Please see sections 5.1.1, 5.1.2, 5.1.3, 5.1.4 in [2] for more details on this. 5.11.2 GRMP In GRMP, specific FE join request message [3 Section 4.1.1] and FE leave request message [3 Section 4.1.2] make FEs able to dynamically join or leave a ForCES NE. While CE failover or leave policy [3 Section 4.6.4] defines the way for CEs to dynamically join or leave the NE. GRMP also defines FE failover and rejoin policy [3 Section 4.6.5] for FEs to dynamically rejoin the NE. Protocol requirement compliance level: ( ) 5.11.3 Netlink2 5.12 Protocol Requirement: Command Bundling The ForCES protocol MUST be able to group an ordered set of commands to a FE. Each such group of commands SHOULD be sent to the FE in as few messages as possible. Furthermore, the protocol MUST support the ability to specify if a command group MUST have all-or-nothing semantics. 5.12.1 FACT Compliance = T Putzolu et al. Expires - April 2004 [Page 22] ForCES Protocol Evaluation Draft October 2003 FACT supports command bundling by using multiple TLVs in its message payload. For example, each TLV used in the Configure Request message could represent a different command such as Add, Delete, etc. In addition, FACT also supports 2-phase commit operations. Please see sections 5.2.3, 4.2 in [2] for more details on this. 5.12.2 GRMP In many cases of IP services, timely execution of ForCES protocol commands are essential for properly providing the services. Command bundling is a good approach to this. GRMP supports ForCES protocol command bundling in two ways: 1) Using GRMP batch messages [3 Section 4.8] This kind of GRMP messages allow GRMP application layers to pack several different GRMP message bodies into one single GRMP message. These messages should meet following conditions: -Are sent from the same CE to the same FE. -Do not need explicit message responses. Such messages include that like event report messages, FE or LFB action manipulate messages, attribute manipulate messages, etc. 2) Using list data format [3 Section 3.4.3] The list data format is used in several GRMP messages so that these messages can set more than one commands (that have same command type) in one message body. Examples of these GRMP messages are like: -FE attribute manipulate message [3 Section 4.1.6], which allow CE to manipulate several FE attributes at one blow. -FE attribute query and response messages [3 Section 4.1.7], which allow CE to query several FE attributes at one blow. -FE event report message [3 Section 4.1.8], which allow FE to report several FE events via one message. -LFB management messages [3 Section 4.2] -Datapath management messages [3 Section 4.3] Protocol requirement compliance level: ( ) 5.12.3 Netlink2 5.13 Protocol Requirement: Asynchronous Event Notification The ForCES protocol MUST be able to asynchronously notify the CE of events on the FE such as failures or change in available resources or capabilities. (refer to section 5, requirement# 6) 5.13.1 FACT Putzolu et al. Expires - April 2004 [Page 23] ForCES Protocol Evaluation Draft October 2003 Compliance = T FACTÆs Event Notification message class includes the Asynchronous FE Event notification message used to report asynchronous FE events to the CE. Please see section 5.5 in [2] for more details on this. 5.13.2 GRMP In GRMP, a FE asynchronously informs CEs of a monitored failure, resources and capabilities changes, and other asynchronous events via GRMP FE event report message [3 Section 4.1.8]. These events include all that are defined within GRMP scope, by ForCES FE model, and possibly by vendors. GRMP use an object class identifier [3 Section 3.4.5] to describe such inclusion. Current document of GRMP has defined following asynchronous events, which belong to GRMP event class: Object Class = 0 (GRMP class) FE Event Type -FE status event such as FE up, down, etc. -LFB status event such as LFB up, down, etc. -FE heartbeat -FE port change, such as port up, down, etc. -FE memory change -FE DoS attack alert Protocol requirement compliance level: ( ) 5.13.3 Netlink2 5.14 Protocol Requirement: Query Statistics The ForCES protocol MUST provide a means for the CE to be able to query statistics (monitor performance) from the FE. 5.14.1 FACT Compliance = T FACTÆs Capabilities and Control message class includes the Query request and response messages which can be used by the CE for querying the FEÆs properties and statistics. Please see sections 5.2.7, 5.2.8 in [2] for more details on this. 5.14.2 GRMP GRMP defines statistics regarding FE performance as FE or LFB attributes. The FE attributes of statistics are the statistics that take whole FE as a statistic object, and the LFB attributes of Putzolu et al. Expires - April 2004 [Page 24] ForCES Protocol Evaluation Draft October 2003 statistics usually take the individual LFBs as statistic objects. In GRMP, the statistics attributes include that defined in FE model, by vendors, and by GRMP protocol itself. GRMP uses FE attribute query and response messages [3 Section 4.1.7] and LFB attribute query and response messages [3 Section 4.2.4] to query the statistics. GRMP can also support query of statistics defined by network management tools like SNMP by using MO get message [3 Section 4.5.1] and MO response message [3 Section 4.5.3]. Protocol requirement compliance level: ( ) 5.14.3 Netlink2 5.15 Protocol Requirement: Protection Against Denial of Service Attacks Systems utilizing the ForCES protocol can be attacked using denial of service attacks based on CPU overload or queue overflow. The ForCES protocol could be exploited by such attacks to cause the CE to become unable to control the FE or appropriately communicate with other routers and systems. The ForCES protocol MUST therefore provide mechanisms for controlling FE capabilities that can be used to protect against such attacks. FE capabilities that MUST be manipulated via ForCES include the ability to install classifiers and filters to detect and drop attack packets, as well as to be able to install rate limiters that limit the rate of packets which appear to be valid but may be part of an attack (e.g. bogus BGP packets). 5.15.1 FACT Compliance = T FACT uses separate control and data channels to provide robustness in the protocol against Denial of Service (DoS) attacks. Please see section 3.3 in [2] for more details on this. Also, the Configure Request and Response messages in FACT could be used to install filters on FEs which can be used for rate-limiting the malicious traffic. 5.15.2 GRMP GRMP supports protection against DoS attacks by means of following defined mechanisms: 1) A model for GRMP slave module [3 Section 4.6.1] In this model, all GRMP messages sending to CE are put to two different channels: the data channel, which is only for packet redirection messages, and the control channel, which is for other Putzolu et al. Expires - April 2004 [Page 25] ForCES Protocol Evaluation Draft October 2003 GRMP messages that are usually generated by GRMP slave itself. Note that before redirected packets enter GRMP slave, a filter LFB defined by FE model is usually applied to decide what kind of packets are allowed to be redirected to CE. Messages on the two channels pass through a packet scheduler, then are put on the link connecting to CE. The scheduler is managed by CE by setting some scheduling policies (disciplines) to it. This policy setting can be done either at the scheduler startup time or on the fly during its runtime. In this way, the CE can control the traffic over the two message transmission channels dynamically according to the monitored traffic status. This also provides a means for CE to protect control channel transmission and to defend against DoS attacks. 2) GRMP DoS protection policy [3 Section 4.6.2] This is defined in GRMP as a FE attribute. In this policy attribute, scheduling priorities, channel bandwidths, and congestion control policies for the individual data channel and control channel can be assigned. 3) GRMP DoS attack alert policy [3 Section 4.6.3] This is also defined as a FE attribute. This policy specifies in which state a DoS attack is considered happened. DoS attack monitoring is performed by monitoring the status and statistics of the scheduler in the GRMP slave model. 4) A DoS attack alert event report [3 Section 4.1.8] This is an event report message sent from FE to CE to report that a DoS attack is monitored according to the preset DoS attack alert policy. The event report can also include some information concerning the attackers. When CE has received the DoS attack alert event report, it may need to change DoS protection policy in some way to ensure the control channel transport. CE can also change attributes of the filter LFB put at the data channel entrance so that the packets that are doubted from DoS attackers can be filtered. Protocol requirement compliance level: ( ) 5.15.3 Netlink2 5.16 Protocol Requirement Summary Table This section is a summary of the compliance levels claimed for each protocol above and is included as a convenience. Putzolu et al. Expires - April 2004 [Page 26] ForCES Protocol Evaluation Draft October 2003 Protocol Requirement FACT GRMP Netlink2 ==================================================================== 1. Configuration of Modeled Elements T ? ? 2. Support for Secure Communication T ? ? 3. Scalability T ? ? 4. Multihop T ? ? 5. Message Priority T ? ? 6. Reliability T ? ? 7. Interconnect Independence T ? ? 8. CE Redundancy or CE Failover T ? ? 9. Packet Redirection/Mirroring T ? ? 10. Topology Exchange T ? ? 11. Dynamic Association T ? ? 12. Command Bundling T ? ? 13. Asynchronous Event Notification T ? ? 14. Query Statistics T ? ? 15. Protection Against Denial of Service Attacks T ? ? Security Considerations This document is a comparison between three protocols in order to help in the selection of the best approach to use as the ForCES protocol. Security considerations are addressed in each of the protocol proposals and MUST be included as part of the fitness evaluation for each proposal. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Audu, A. et al., "ForwArding and Control ElemenT protocol (FACT)", work in progress, September 2003, 3 Wang, W. et al., "General Router Management Protocol (GRMP) Version 1ö, September 2003, 4 Salim, J. H. et al., "Netlink2 as ForCES Protocol", work in progress, June 2003, 5 Khosravi, H. et al., "Requirements for Separation of IP Control and Forwarding", work in progress, July 2003, Putzolu et al. Expires - April 2004 [Page 27] ForCES Protocol Evaluation Draft October 2003 6 Yang, L. et al., "Forwarding and Control Element Separation (ForCES) Framework", work in progress, August 2003, 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 8 Barnes, M., "Middlebox Communications (MIDCOM) Protocol Evaluation", work in progress, Nov 2002, 9 Yang, L. et al., "ForCES Forwarding Element Functional Model", work in progress, October 2003, 10 F. Baker, "Requirements for IP Version 4 Routers", RFC1812, June 1995. 11 S. Floyd, "Congestion Control Principles", RFC2914, September 2000. Acknowledgments Author's Addresses Alex Audu Alcatel R&I 1000 Coit Road Plano, TX 75075 Phone: 1-972-477-7809 Email: alex.audu@alcatel.com Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 Phone: 1-503-264-0334 Email: hormuzd.m.khosravi@intel.com David Putzolu Intel Mailstop JF3-206-H10 2111 NE 25th Avenue Phone: 503-264-4510 Email: david.putzolu@intel.com Putzolu et al. Expires - April 2004 [Page 28] ForCES Protocol Evaluation Draft October 2003 Weiming Wang Department of Information and Electronic Engineering Hangzhou University of Commerce 149 Jiaogong Road Hangzhou, 310035, P.R.China Phone: +86-571-88057712 Email: wangwm@hzcnc.com Putzolu et al. Expires - April 2004 [Page 29]