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

   <Text for this section>


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

   <Text for this section>


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

   <Text for this section>


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

   <Text for this section>

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

   <Text for this section>

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

   <Text for this section>

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

   <Text for this section>

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

   <Text for this section>




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

   <Text for this section>

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

   <Text for this section>

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

   <Text for this section>

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

   <Text for this section>

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

   <Text for this section>

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

   <Text for this section>

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

   <Text for this section>

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

   <Text for this section>

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

   <Text for this section>

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

   <Text for this section>

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, <draft-gopal-forces-fact-05.txt>

   3  Wang, W. et al., "General Router Management Protocol (GRMP)
      Version 1ö, September 2003, <draft-wang-forces-grmp-00.txt>

   4  Salim, J. H. et al., "Netlink2 as ForCES Protocol", work in
      progress, June 2003, <draft-jhsrha-forces-netlink2-01.txt>

   5  Khosravi, H. et al., "Requirements for Separation of IP Control
      and Forwarding", work in progress, July 2003,
      <draft-ietf-forces-requirements-10.txt>





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,
      <draft-ietf-forces-framework-08.txt>

   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,
      <draft-ietf-midcom-protocol-eval-06.txt>

   9  Yang, L. et al., "ForCES Forwarding Element Functional Model",
      work in progress, October 2003, <draft-ietf-forces-model-01.txt>

   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]