idnits 2.17.1 draft-ietf-forces-evaluation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2003) is 7437 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 12 looks like a reference -- Missing reference section? '2' on line 1352 looks like a reference -- Missing reference section? '3' on line 31 looks like a reference -- Missing reference section? '4' on line 526 looks like a reference -- Missing reference section? '5' on line 470 looks like a reference -- Missing reference section? '6' on line 33 looks like a reference -- Missing reference section? '7' on line 43 looks like a reference -- Missing reference section? '8' on line 91 looks like a reference -- Missing reference section? '9' on line 614 looks like a reference -- Missing reference section? '10' on line 525 looks like a reference -- Missing reference section? '11' on line 508 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ForCES Working Group 2 Internet Draft D. Putzolu (editor) 3 Document: draft-ietf-forces-evaluation-00.txt Intel 4 Expires: June 2004 December 2003 6 ForCES Protocol Evaluation Draft 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document provides an evaluation of the applicability of three 31 proposed approaches for a ForCES protocol: FACT[2], GRMP[3], and 32 Netlink2[4]. A summary of each of the proposed protocols against the 33 ForCES requirements[5] and the ForCES framework[6] is provided. 34 Compliancy of each of the protocols against each requirement is 35 detailed. A conclusion summarizes how each of the protocols fares in 36 the evaluation. 38 Conventions used in this document 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC-2119 [7]. 44 ForCES Protocol Evaluation Draft December 2003 46 Table of Contents 48 1. Introduction...................................................2 49 2. Protocol Proposals.............................................3 50 2.1 FACT.......................................................4 51 2.2 GRMP.......................................................5 52 2.3 Netlink2...................................................6 53 3. Architectural Requirements Compliance Evaluation...............8 54 3.1 FACT.......................................................8 55 3.2 GRMP.......................................................8 56 3.3 Netlink2..................................................10 57 4. Model Requirements Compliance Evaluation......................12 58 4.1 FACT......................................................12 59 4.2 GRMP......................................................12 60 4.3 Netlink2..................................................13 61 5. Protocol Requirements Compliance Evaluation...................13 62 5.1 Protocol Requirement: Configuration of Modeled Elements...14 63 5.2 Protocol Requirement: Support for Secure Communication....15 64 5.3 Protocol Requirement: Scalability.........................16 65 5.4 Protocol Requirement: Multihop............................17 66 5.5 Protocol Requirement: Message Priority....................18 67 5.6 Protocol Requirement: Reliability.........................19 68 5.7 Protocol Requirement: Interconnect Independence...........20 69 5.8 Protocol Requirement: CE Redundancy or CE Failover........21 70 5.9 Protocol Requirement: Packet Redirection/Mirroring........22 71 5.10 Protocol Requirement: Topology Exchange..................23 72 5.11 Protocol Requirement: Dynamic Association................24 73 5.12 Protocol Requirement: Command Bundling...................25 74 5.13 Protocol Requirement: Asynchronous Event Notification....26 75 5.14 Protocol Requirement: Query Statistics...................26 76 5.15 Protocol Requirement: Protection Against Denial of Service 77 Attacks.......................................................27 78 5.16 Protocol Requirement Summary Table.......................28 79 Security Considerations..........................................29 80 References.......................................................29 81 Author's Addresses...............................................30 83 1. Introduction 85 This document provides an evaluation of the applicability of FACT, 86 GRMP, and Netlink2 as the ForCES protocol. This evaluation provides 87 overviews of the protocols and general statements of applicability 88 based upon the ForCES framework and requirements documents. The 89 format and structure as well as some of the introductory content of 90 this document is based on and taken from a similar document being 91 produced in the MIDCOM working group[8]. 93 ForCES Protocol Evaluation Draft December 2003 95 The process for protocol evaluation found in this document consists 96 of individuals providing sections evaluating a specific protocol. 97 These sections are incorporated by the editor of the document, and 98 are subject to feedback and changes based on the consensus of the 99 ForCES working group. Some protocols that might be considered as 100 potentially applicable as the ForCES protocol are not evaluated in 101 this document since there where no champions to submit evaluations 102 for them. 104 Section 2 of this document is a list of the proposed protocols along 105 with background information about each of the protocols. 107 Section 3 of this document is an evaluation of the proposed protocols 108 against the architectural requirements found in section 5 of the 109 ForCES requirements. The purpose of this section is to determine how 110 well each of the proposed protocols maps to the ForCES architecture. 112 Section 4 of this document is an evaluation of the proposed protocols 113 against the model requirements found in ForCES requirements. The 114 purpose of this section is to determine how well each of the proposed 115 protocols can be used with FEs that meet the ForCES model 116 requirements. 118 Section 5 of this document is an item level evaluation of the 119 proposed protocols against the protocol requirements found in the 120 ForCES requirements. The purpose of this section is to determine how 121 well each of the proposed protocols satisfies each of the protocol 122 requirements. 124 Section 6 summarizes the evaluation, and includes a table with a 125 breakdown for each of the protocols versus the requirements. The 126 following categories of compliance are used: Fully met, partially met 127 through the use of extensions, partially met through other changes to 128 the protocol, or not met. This summary is not a conclusive statement 129 of the suitability of the protocols, but rather to provide 130 information to be considered as input into the overall protocol 131 decision process. 133 2. Protocol Proposals 135 The following protocols have been submitted to the ForCES WG for 136 consideration: 137 o FACT 138 o GRMP 139 o Netlink2 141 The following sections provide overviews of each of the protocols as 142 well as relevant background information about each protocol. 144 ForCES Protocol Evaluation Draft December 2003 146 2.1 FACT 148 Network Elements (NE) such as routers are becoming more and more 149 complex as they try to cope with demanding features like policy based 150 routing, firewalls and NATs, and QoS aware routing. As a result, 151 issues like scalability, (the ability to cost-effectively grow a 152 network as demand increases) and extensibility (the ability to 153 dynamically configure the network for some specific services by 154 programming the NEs that handle those services) become very 155 important. The ForCEs protocol has been specified to help resolve 156 these issues by decoupling control and forwarding elements of a 157 network element, and also adding extensibility features to the NE. 159 FACT (Forwarding And Control ElemenT) protocol has been designed for 160 exchanging information between control elements (CEs) and forwarding 161 elements (FEs) distributed in a ForCES network element (NE). The 162 relationship between CEs and FEs is a master/slave one. The FACT 163 protocol is logically separated into a base protocol and an 164 extensible data model defined in [9]. It consists of a common, fixed 165 size header and variable size payload which carries the information 166 defined by the data model. All FACT messages are 32-bit aligned. 168 FACT's messages are grouped into six (6) classes namely: 169 1) Connection and Association messages, which help establish 170 logical connections between FEs and CEs, 171 2) Capabilities Control messages, which the CE uses to query and 172 configure the capabilities of the FE, 173 3) State Maintenance messages, which are used to track element 174 states, 175 4) Traffic Maintenance messages, which are used exchanging control 176 packets between CEs and FEs, 177 5) Event Notification messages used for reporting asynchronous 178 events, and 179 6) Vendor Specific messages which are used to extend the protocol 180 beyond its current capabilities. 182 FACT supports versioning and priority, and its unique design of 183 separating control and data traffic into different channels helps 184 reduce the threat of Denial of Service (DoS) attacks making the 185 protocol more robust. It provides reliability by using a reliable 186 transport protocol, thus simplifying the protocol design. It also 187 provides failover mechanisms that can exploit redundant elements in 188 the system or network element. 190 The FACT protocol follows the basic design principles of simplicity, 191 reuse of existing mechanisms and enabling easy interoperability. In 192 this respect, FACT reuses existing transport and security protocols 193 which are widely available and avoids building such mechanisms into 195 ForCES Protocol Evaluation Draft December 2003 197 the protocol which can increase complexity. It also mandates single 198 transport, security mechanisms and payload encapsulation which help 199 with enabling easy interoperability. The clean separation of FACT 200 base protocol and data model also helps with simplicity and 201 extensibility. 203 2.2 GRMP 205 General Router Management Protocol (GRMP) Version 1 intends to be as 206 a ForCES protocol, which acts at the Fp reference point in the ForCES 207 framework. GRMP is designed to meet all the requirements for the 208 ForCES protocol at the Fp reference point. 210 GRMP protocol is a master-slave protocol. CEs act as masters and FEs 211 as slaves. Slaves have rights to send to masters request, response or 212 report messages, while masters can send command messages to slaves as 213 well as send request, response, or report messages. GRMP protocol 214 acts in a mode of a base-protocol associated with a data model, where 215 GRMP is as a base-protocol and ForCES FE model as a Data Model. GRMP 216 defines basic management messages, while managed data are defined in 217 the associated ForCES FE model. Most of the data types and functional 218 descriptions related to specific IP services such as routing service 219 conforming to RFC 1812, QoS configurations, high-touch capabilities 220 like NAT and firewall should be expressed by Logical functional 221 Blocks (LFBs) and LFB topologies. The ForCES protocol application 222 layer is responsible on how to configure the LFBs and the LFB 223 topologies based on the FE capabilities in order to implement 224 specific IP services and QoS resources deployment. 226 GRMP is developed separately from General Switch Management Protocol 227 (GSMP) protocol. However, GRMP has been considering its possible 228 compatibility with GSMP. 230 GRMP protocol is composed of protocol messages. GRMP organizes these 231 messages according to the different object types and layers in ForCES 232 architecture the protocol intends to manage, as follows: 234 1. FE Coarse Layer 235 . FE management messages 236 These messages take a whole FE as the managed object. Messages of 237 this type include that for operation of FE join or leave, FE action, 238 FE attribute, FE event report, etc. Messages of this type also 239 include that for GRMP slave management, which is a module GRMP 240 protocol has defined in a FE that is responsible for protocol message 241 interpreting, executing, generating, and encapsulating at the FE 242 side. 244 2. FE Fine Layer 245 . LFB management messages 247 ForCES Protocol Evaluation Draft December 2003 249 This type of messages is for the management of LFB layer operation. 250 It takes LFBs as its managed objects. Messages of this type include 251 that for operation of LFB action, LFB attribute, etc. 253 . Datapath management messages 254 This type of messages is for the management of datapaths in an FE. 255 It takes datapathes as the managed objects. 257 3. CE Layer 258 . CE Informing messages 259 This type of messages takes CE as the operated object. Because CE 260 acts as a master in ForCES protocol, allowed operations to CE from FE 261 are only that like CE attribute query, CE event report, etc. 263 4. Protocol Layer and others 264 Messages of this type include: 265 . GRMP ACK message 266 . Packet redirection messages 267 . GRMP Batch messages 268 . Managed Object(MO) management messages 269 In order to support network management tools like SNMP in ForCES 270 architecture, GRMP provides these management messages. The messages 271 take Managed Objects (MOs) defined in some specific network 272 management tools as their operating objects. Operations of MOs are 273 that like MO get, MO set, and MO response. 275 From the perspective of the message communication in between CE and 276 FE, GRMP messages can be divided into following types: 278 1. Messages for query and response types. These messages can be from 279 CE to FE, or from FE to CE. 281 2. Messages for command and configuration types. These messages are 282 only from CE to FE. 284 3. Messages for report types. These messages can be from CE to FE, 285 or from FE to CE. 287 GRMP has defined a "Object Class" prefix [3 Section 3.4.5] to allow 288 managed objects to be defined inside GRMP protocol, by different 289 versions of ForCES FE models, or by vendors, in order to make GRMP 290 protocol more scalable and flexible regarding its managed entities. 292 2.3 Netlink2 294 Netlink2 [4] is a proposal for the ForCES post-association phase 295 protocol. It is derived from Linux Netlink [10], and as such it 296 builds on the experience gained by use of Netlink for forwarding and 298 ForCES Protocol Evaluation Draft December 2003 300 control separation in thousands of Linux-based NEs such as routers, 301 security gateways, NATs, bridges, etc. Netlink2 has incorporated 302 extensions to Netlink to allow multi-host distributed operation 303 across local and global networks. 305 The key features of Netlink2 are the following: 307 - Peer-to-peer protocol which can be used between an arbitrarily 308 large set of addressable elements (CEs or FEs). 310 - Embedded addressing of source and destination addressable 311 elements. 313 - Support for unicast, logical, and broadcast addressing. 315 - Separation from the underlying transport protocol. Netlink2 can 316 run directly over unreliable IP/UDP, or can run over TCP/IP or 317 SCTP/IP. It can also run directly over native link-layer 318 protocols (e.g., Ethernet, PCI). 320 - Application-layer support for synchronization, sequencing, and 321 acknowledgement (not dependent on the underlying transport) 322 provides for element association, reliable or unreliable message 323 exchanges, and atomic transactions. 325 - Congestion control by means of underlying transport protocol or by 326 means of Netlink2 flow control between addressable entities. 328 - Support for message priority. 330 - Support for message bundling and fragmentation. 332 - Simultaneous support for unicast and multicast communication. 333 Multiple Netlink2 wires can be established between CEs and FEs for 334 efficient message exchange. Multicast wires can enhance 335 scalability in certain local circumstances. 337 - Flexible ACK strategy support to minimize multicast ACK implosion. 339 - Support for FE_instance:LFB_instance and FE_group:LFB_class 340 addressing. 342 - Support for a variety of command/query modes. 344 - Authentication support by means of option headers. 346 - Support for protocol versioning and extension headers. 348 ForCES Protocol Evaluation Draft December 2003 350 3. Architectural Requirements Compliance Evaluation 352 This section contains a review of each protocol proposal's level of 353 compliance to the ForCES architecture requirements. Many of the 354 architectural requirements will be instantiated in some fashion in 355 the protocol selected. Given that the architectural requirements are 356 not direct protocol requirements, the review below will consist of 357 prose rather than specific levels of compliance as is used in the 358 protocol section below. 360 3.1 FACT 362 FACT fulfills all the protocol requirements listed in section 5. By 363 doing this it in turn supports all the architectural requirements 364 defined in the ForCES Requirements [5]. FACT supports the separation 365 of the NE into CE and FE components, with CE handling roles such as 366 control, signaling and routing data calculation. The CE configures 367 the FE with all the information necessary for the FE's proper 368 operation. The FE's functions could be layer-3 forwarding, NAT, 369 metering, shaping, firewall, etc. Also, FACT state maintenance 370 messages help resolve the various states of the distributed CEs and 371 FEs to provide a unified state of the NE. 373 3.2 GRMP 375 GRMP protocol is designed based on the ForCES architecture 376 requirements. We review its compliance to the individual requirement 377 items as below: 379 1) For architecture requirement #1 380 GRMP packets can be transported via any suitable mediums, such as 381 TCP/IP, Ethernet, ATM fabrics, and bus backplanes. 383 2) For architecture requirement #2 384 ForCES requires that FEs MUST support a minimal set of capabilities 385 necessary for establishing network connectivity (e.g., interface 386 discovery, port up/down functions). This process is usually out of 387 the range of the ForCES protocol, but GRMP protocol has no 388 restriction on this functionality. 390 3) For architecture requirement #3 391 By properly configuring FEs with their LFBs in a NE via GRMP 392 protocol, packets can arrive at one FE and depart at the other FE or 393 FEs. In the case where more than one CE work simultaneously in a NE, 394 the consistency and synchronization of control of the CEs is 395 basically required, but which is beyond the scope of the ForCES 396 protocol. 398 4) For architecture requirement #4 400 ForCES Protocol Evaluation Draft December 2003 402 By properly configuring LFBs in FEs in a NE via GRMP protocol, the NE 403 can appear as a single functional device in a network. In the case 404 more than one CE work simultaneously in a NE, the consistency and 405 synchronization for the CEs to control FEs is basically required, but 406 this is beyond the scope of the ForCES protocol. 408 5) For architecture requirement #5 409 ForCES protocol requirement #2 has comprised this architecture 410 requirement, refer to Section 5.2.2 for details on GRMP compliance to 411 this requirement. 413 6) For architecture requirement #6 414 Please refer to Section 5.13.2 for details. 416 7) For architecture requirement #7 417 Please refer to Section 5.8.2 for details. 419 8) For architecture requirement #8 420 Please refer to Section 5.9.2 for details. 422 9) For architecture requirement #9 423 GRMP supports RFC1812 compliant router functions by means of 424 following mechanisms in GRMP: 425 -Fully supporting ForCES FE model 426 -Packet redirection messages 427 -Datapath management messages 428 -Managed Object(MO) management messages 430 10) For architecture requirement #10 431 In GRMP, FE topology query and response messages [3 Section 4.1.3] 432 are used for CEs to query FE topology information in a NE. 434 11) For architecture requirement #11 435 Please refer to Section 5.3.2 for details. 437 12) For architecture requirement #12 438 Please refer to Section 5.11.2 for details. 440 13) For architecture requirement #13 441 GRMP supports multiple FEs working together in a NE by using FE 442 identifiers and by allowing CEs to be informed of FE topology 443 information. GRMP supports multiple CEs working together in a NE by 444 supporting CE redundancy or failover functionality. 446 14) For architecture requirement #14 447 GRMP defines Managed Object (MO) management messages [3 Section 4.5] 448 to meet the requirement. 450 ForCES Protocol Evaluation Draft December 2003 452 A MO is an object defined by some network management tool, such as 453 the object defined by Object Identifier in SNMP MIBs. MO management 454 messages work in the way as below: 456 1. Query of MOs resident in an FE can be directly implemented by 457 network management tools. 458 2. Change of MOs resident in an FE can only be made via a CE. To do 459 this, the high touch LFBs in the FE will redirect all network 460 management protocol messages like SNMP messages concerning MO changes 461 to the CE, then the CE will use the MO management messages described 462 in this section to change values of MOs in the FE. Of course, if 463 necessary, query of the MOs can also be made via the CE. 464 3. MOs resident in a CE can be directly queried or changed by the CE 465 with CE high touch capability. Before the CE can do this, network 466 management messages still need to be redirected from FEs to the CE. 468 3.3 Netlink2 470 Section 5 of [5] identifies a set of ForCES architecture 471 requirements, some of which have an impact on the design and features 472 of the ForCES post-association phase protocol. The following items 473 document the compliance of the Netlink2 proposal [4] to the each of 474 the ForCES architectural requirements. 476 1. Netlink2 is capable of operating over IP, therefore it is capable 477 of operating over any link-layer technology supporting IP. 478 Netlink2 is also capable of operating directly over link-layer 479 technologies in the absence of IP. This is made possible due to 480 the inclusion of the following protocol mechanisms: 482 - Source and Destination element addresses. 483 - Message priority 484 - Message length 485 - Sequence number 486 - ACK/NACK support 487 - Checksum option (available in the Netlink2 extension header) 489 Note that in the case of both IP and direct link-layer operation, 490 Netlink2 depends on the pre-association protocol to associate 491 Netlink2 CE/FE addresses to link-layer (and, if applicable, IP) 492 addresses. 494 2. Not applicable. 496 3. Netlink2 supports generic unicast transmission to/from any 497 particular FE. 499 ForCES Protocol Evaluation Draft December 2003 501 4. Netlink2 supports a state machine and the necessary protocol 502 messages to support the transition from pre-association to post- 503 association phase. 505 5. Netlink2 supports CE and FE authentication by means of 506 authentication and name protocol options. The authentication 507 mechanism design is not documented in [4]. The qualified name 508 mechanism is intended to be derived from [11]. 510 6. Netlink2 supports autonomous message generation by FEs. 512 7. Netlink2 supports NOOP messages which can be used to implement a 513 heartbeat protocol between addressable elements. One component of 514 CE redundancy (state synchronization) is enabled by allowing 515 secondary CEs to be participants in Netlink2 multicast wires. 517 8. Netlink2 allows multiple unicast and/or multicast wires to be 518 established between CEs and FEs, allowing separate channels for 519 data and control exchanges. Configuration of the necessary LFBs 520 for enabling packet redirection is opaque to Netlink2. 522 9. Netlink2 messages can be addressed to individual LFBs on an FE (or 523 to all LFBs of a class on all FEs within a particular multicast 524 group). The configuration commands for specific FE LFBs is opaque 525 to Netlink2. Command templates derived from [10] are documented 526 in [4] and may be used with Netlink2. 528 10.FE topology information may be conveyed by Netlink2 (but is not 529 defined by it). 531 11.Netlink2 includes a variety of mechanisms to enhance scalability. 532 Message exchanges (e.g., physical interface configuration) 533 specific to a particular FE can be unicast to/from that FE. 534 Message exchanges applicable to a set of multiple FEs (e.g., 535 nexthop updates) can be multicast to all FEs within the set. 536 Netlink2 messages include sufficient addressing information to 537 allow recipients on a multicast wire to quickly filter out 538 messages not intended for them. Partial ACK support is provided 539 to allow reliable multicast communication without ACK implosion at 540 the message originator. ACKs/NACKs for multicast messages can be 541 returned on a unicast wire to the message originator. 543 12.Netlink2 supports a state machine and the necessary protocol 544 messages for CEs and FEs to join and leave association 545 dynamically. 547 13.Netlink2 allows support for up to 64K addressable elements (using 548 the currently specified addressing structure). 550 ForCES Protocol Evaluation Draft December 2003 552 14.Not applicable. 554 4. Model Requirements Compliance Evaluation 556 This section contains a review of each protocol's level of compliance 557 to the ForCES model requirements. The ForCES model will indirectly 558 relate to the protocol in that the protocol will be used to carry 559 information that the model represents. Given that the model 560 requirements are only indirectly related to the protocol selection, 561 the review below will consist of prose rather than specific levels of 562 compliance as is used in the protocol section below. 564 4.1 FACT 566 The FACT protocol is logically separated into a base protocol and an 567 extensible payload which can be used to carry the FE, Logical 568 Functional Block (LFB) specific data which is defined by the FE Model 569 [9]. Thus the FACT protocol is cleanly separated from the data model 570 that it carries. The FE Model draft [9] defines the data model for 571 the Forwarding Element and meets all the Model requirements. 573 FACT's Configure Request and Configure Response message types under 574 the Capabilities Control message group provide a flexible way to 575 configure the functionality of the FE according to the FE Model [9]. 576 The specific parameters needed to assign functionalities and 577 behaviors to the Logical Functional Blocks (LFBs) in the FEs are 578 dictated by the FE Model. 580 Vendor Specific functions are supported by VS-Data request and VS- 581 Data response messages in the Vendor Specific message group. 583 4.2 GRMP 585 GRMP protocol is designed to use ForCES FE model as a base data model 586 for the protocol functionality. GRMP aims to support all operations 587 to all elements defined in ForCES FE model. Following elements for 588 ForCES FE model (including capability model and state model) with 589 their operations are presented in current version of GRMP document: 590 -FE capabilities 591 -FE attributes, including FE statistics 592 -FE events 593 -LFBs with their attributes (including capabilities, statistics, 594 etc), their actions, and their topologies 595 -Datapaths 596 Section 5.1.2 has described GRMP support for the management of the 597 modeled elements. Along with the progress in FE model work, a 598 modification of GRMP can be made to coordinate with the modification 599 in the FE model. 601 ForCES Protocol Evaluation Draft December 2003 603 GRMP protocol supports ForCES FE model to meet following model 604 requirements without any restriction from the protocol: 606 1. Types of logical functions 607 2. Variations of logical functions 608 3. Ordering of logical functions 609 4. Flexibility 610 5. Minimal set of logical functions 612 4.3 Netlink2 614 The Forces FE Information Model [9] will define schemas for 615 describing the capabilities and attributes of FEs and LFBs. From 616 these, protocol TLVs will be derived. These TLVs will be 617 communicated as the payload of ForCES protocol messages. The payload 618 of Netlink2 messages is opaque to Netlink2, with the exception that 619 the Netlink2 header includes a message type field which can be used 620 to convey information about the content of the message payload (this 621 feature could be ignored by defining a generic NLMSG_FECMD type). 622 Netlink2 supports message addressing at the granularity of 623 FE_instance:LFB_instance or FE_group:LFB_class. Further, it supports 624 a variety of flag fields (request, root, match, atomic, replace, 625 exclusive, create, and append) which support efficient atomic 626 transaction, configuration, and query exchanges as may be required by 627 the FE model. 629 5. Protocol Requirements Compliance Evaluation 631 This section contains a review of each protocol's level of compliance 632 to the ForCES protocol requirements. Given that the protocol 633 requirements are directly related to the protocol proposals, a very 634 concrete method is used in reviewing compliance - the following key 635 identifies the level of compliance for each of the following 636 protocols to each protocol requirement in the ForCES requirements 637 RFC: 639 T = Total compliance. Meets the requirement fully. 641 P+ = Partial compliance. Fundamentally meets the requirement through 642 the use of extensions (e.g. packages, additional parameters, etc.) 644 P = Partial compliance. Meets some aspect of the requirement, 645 however, the necessary changes require more than an extension and/or 646 are inconsistent with the design intent of the protocol. 648 N = Not compliant. Does not meet the requirement. 650 Each subsection of this section begins with the specific protocol 651 requirement text found in the ForCES requirements. 653 ForCES Protocol Evaluation Draft December 2003 655 5.1 Protocol Requirement: Configuration of Modeled Elements 657 The ForCES protocol MUST allow the CEs to determine the capabilities 658 of each FE. These capabilities SHALL be expressed using the FE model 659 whose requirements are defined in Section 6. Furthermore, the 660 protocol MUST provide a means for the CEs to control all the FE 661 capabilities that are discovered through the FE model. The protocol 662 MUST be able to add/remove classification/action entries, set/delete 663 parameters, query statistics, and register for and receive events. 665 5.1.1 FACT 667 FACT's Capabilities Control message class contains Configure Request 668 and Configure Response messages that can be used to configure the 669 FE's behavior from the CE. Also, the Capability request and response 670 messages can be used by the CE to query and learn the FE 671 capabilities. Please see section 5.2 in [2] for more details on this. 673 Protocol requirement compliance level: ( T ) 675 5.1.2 GRMP 677 Most of GRMP protocol messages are for the management of modeled 678 elements in ForCES FEs. They are listed as follows: 680 1) FE capability query and response messages [3 Section 4.1.4] 681 2) FE attribute manipulate message [3 Section 4.1.6] 682 3) FE attribute query and response messages [3 Section 4.1.7] 683 4) FE event report message [3 Section 4.1.8] 684 5) LFB action manipulate message [3 Section 4.2.1]. 685 6) LFB topology query and response messages [3 Section 4.2.2] 686 7) LFB attribute manipulate message [3 Section 4.2.3]. 687 8) LFB attribute query and response messages [3 Section 4.2.4] 688 9) Datapath Manipulate Message [3 Section 4.3.1] 689 10) Datapath query and response messages [3 Section 4.3.2] 691 Protocol requirement compliance level: ( T ) 693 5.1.3 Netlink2 695 Netlink2 includes service template definitions that allow modeled 696 elements to be configured using TLVs. As the model gets refined, 697 appropriate modifications to those TLVs can be made without modifying 698 the Netlink2 base protocol. 700 Protocol requirement compliance level: ( T ) 702 ForCES Protocol Evaluation Draft December 2003 704 5.2 Protocol Requirement: Support for Secure Communication 706 a) FE configuration will contain information critical to the 707 functioning of a network (e.g. IP Forwarding Tables). As such, it 708 MUST be possible to ensure the integrity of all ForCES protocol 709 messages and protect against man-in-the-middle attacks. 710 b) FE configuration information may also contain information derived 711 from business relationships (e.g. service level agreements). 712 Because of the confidential nature of the information, it MUST be 713 possible to secure (make private) all ForCES protocol messages. 714 c) In order to ensure that authorized CEs and FEs are participating 715 in a NE and defend against CE or FE impersonation attacks, the 716 ForCES architecture MUST select a means of authentication for CEs 717 and FEs. 718 d) In some deployments ForCES is expected to be deployed between CEs 719 and FEs connected to each other inside a box over a backplane, 720 where physical security of the box ensures that man-in-the-middle, 721 snooping, and impersonation attacks are not possible. In such 722 scenarios the ForCES architecture MAY rely on the physical 723 security of the box to defend against these attacks and protocol 724 mechanisms May be turned off. 725 e) In the case when CEs and FEs are connected over a network, 726 security mechanisms MUST be specified or selected that protect the 727 ForCES protocol against such attacks. Any security solution used 728 for ForCES MUST specify how it deals with such attacks. 730 5.2.1 FACT 732 FACT uses TLS when its endpoints are running over an IP network or in 733 an insecure environment. For a closed box or physically secure 734 environment, it is possible to turn off the protocol security 735 functions. The security association between the CEs and FEs is 736 established before any FACT association establishment messages are 737 exchanged. Also, FACT recommends using rate limiting mechanisms on 738 the FE to protect against DoS attacks. Please see section 8 in [2] 739 for more details on this. 741 Protocol requirement compliance level: ( T ) 743 5.2.2 GRMP 745 1) When GRMP messages are encapsulated in a IP based medium, GRMP 746 protocol recommends to use IPsec or TLS [3 Section 4.1.2] to 747 authenticate the CEs and FEs and to secure the communication between 748 CEs and FEs to defend against possible man-in-the-middle or replay 749 attacks. GRMP has no restrictions on using other approaches for 750 secure communications. When GRMP messages are transported over bus 751 backplanes or in the case CEs and FEs are physically all in one box, 753 ForCES Protocol Evaluation Draft December 2003 755 the secure mechanism to defend man-in-the-middle attach MAY be turned 756 off. 758 2) [3 Section 4.6] has addressed the GRMP mechanism to prevent DoS 759 attacks. 761 3) [3 Section 4.1.2] has addressed the method to prevent possible FE 762 join or leave flood attacks. 764 Protocol requirement compliance level: ( T ) 766 5.2.3 Netlink2 768 Secure communication is supported at the Netlink2-wire level using 769 pre-configured mechanisms (TLS, IP-SEC, MSEC, etc), in the case 770 security cannot be achieved by physical means only. Netlink2 771 introduces ForCES qualified names (fqn) that permit the 772 authentication of FEs and CEs based on names instead of potentially 773 variable addresses. The definition of fqns remains to be completed. 775 Protocol requirement compliance level: ( P+ ) 777 5.3 Protocol Requirement: Scalability 779 The ForCES protocol MUST be capable of supporting (i.e., must scale 780 to) at least hundreds of FEs and tens of thousands of ports. For 781 example, the ForCES protocol field sizes corresponding to FE or port 782 numbers SHALL be large enough to support the minimum required 783 numbers. This requirement does not relate to the performance of a NE 784 as the number of FEs or ports in the NE grows. 786 5.3.1 FACT 788 FACT can support up to 64K FEs and 64K CEs at the same time due its 789 16 bit addressing range of both the CE-Tag and FE-Identifier fields. 790 Please see section 4.1 in [2] for more details on this. In addition, 791 it uses TCP (for IP interconnection between CEs and FEs) which 792 provides congestion control and thus helps in supporting the 793 scalability requirement. 795 Protocol requirement compliance level: ( T ) 797 5.3.2 GRMP 799 In GRMP, a FE is identified by a 16 bits FE Identifier [3 section 800 3.2], which is theoretically able to identify up to 64k FEs. 802 Possible limitation in GRMP protocol to FE port number may be from FE 803 port address space, maximum number of list elements in "list data 805 ForCES Protocol Evaluation Draft December 2003 807 format" [3 section 3.4.3], and LFB instance identifier space. The 808 evaluations of scalability for them are as follows: 810 1) An Addressable Entity (AE) address data format is defined in GRMP 811 [GRMP_3.4.4], which is theoretically capable of describing any length 812 of addresses of AEs, therefore FE port address space is not limited. 814 2) Element number of a list in "list data format" [3 Section 3.4.3] 815 is expressed with 16 bits data space, which theoretically limits list 816 element number within 64k. 818 3) LFB instance ID [3 Section 4.2.1] is expressed using 16 bits data 819 space, which can also theoretically represent 64k instances of one 820 kind of LFB such as a port LFB. 822 Protocol requirement compliance level: ( T ) 824 5.3.3 Netlink2 826 Netlink2 includes a flexible multicast-capable addressing mechanism 827 (32-bits). This allows it to take full advantage of wires capable of 828 supporting multicast/broadcast, such as IP multicast-based wires or 829 Ethernet multicast-based wires (for the local scope environment). In 830 addition, Netlink2 does not limit the number and types of wires that 831 can be used (instead of a single pair of unicast-based control and 832 data channels). Netlink2 wires are configured during pre- 833 association. Support for multicast at the ForCES level is key for 834 scalable distribution (in terms of CPU usage and bandwidth) of 835 identical routing tables from a CE to multiple FEs, for instance. 836 Note that depending on the available transport mechanisms (or lack 837 thereof), a ForCES multicast wire may be implemented using suboptimal 838 multi-unicast TCP connections, for instance. 840 Protocol requirement compliance level: ( T ) 842 5.4 Protocol Requirement: Multihop 844 When the CEs and FEs are separated beyond a single hop, the ForCES 845 protocol will make use of an existing RFC2914 compliant L4 protocol 846 with adequate reliability, security and congestion control (e.g. TCP, 847 SCTP) for transport purposes. 849 5.4.1 FACT 851 FACT uses TCP as the transport protocol which is congestion aware and 852 meets the transport requirements for multi-hop IP networks. Please 853 see section 3.2 in [2] for more details on this. 855 ForCES Protocol Evaluation Draft December 2003 857 Protocol requirement compliance level: ( T ) 859 5.4.2 GRMP 861 GRMP aims to be capable of supporting remote control that allows CEs 862 and FEs to separate multihops away, as well as supporting close or 863 very close proximity control of CEs and FEs. When the CEs and FEs are 864 separated beyond a single hop, GRMP RECOMMENDS using an RFC2914 865 compliant L4 protocol such as TCP, SCTP for the protocol message 866 transmission with adequate reliability, security and congestion 867 control [3 Section 3.3]. 869 Protocol requirement compliance level: ( T ) 871 5.4.3 Netlink2 873 Congestion control and flow control may be necessary depending on the 874 scope in which the ForCES protocol operates. Congestion control is 875 particularly relevant in the global scope, and can be provided by the 876 transport mechanisms used for the Netlink2 wires. Flow control may 877 be provided either by the transport mechanism, by means of 878 backpressure (such as local scope case with a switching fabric 879 interconnecting CEs and FEs) or by an appropriate windowing of 880 Netlink2 messages. Netlink2 accomodates multi-hop wires (i.e., 881 global scope) using any appropriate congestion-control-friendly 882 transport protocol, such as TCP or SCTP. At a minimum, Netlink2 883 requires that UDP is available for the local scope, and TCP 884 (congestion control and reliability) and/or SCTP-PR (congestion 885 control and timeliness) 886 (Note: decision should be taken by the working group) for the global 887 scope. 889 Protocol requirement compliance level: ( T ) 891 5.5 Protocol Requirement: Message Priority 893 The ForCES protocol MUST provide a means to express the protocol 894 message priorities. 896 5.5.1 FACT 898 FACT supports up to 8 levels of priority using the 3 priority bits in 899 the common header. Please see section 4.1.6 in [2] for more details 900 on this. 902 Protocol requirement compliance level: ( T ) 904 5.5.2 GRMP 906 ForCES Protocol Evaluation Draft December 2003 908 GRMP defines a priority field at GRMP message header [3 Section 3.2] 909 to express the protocol message priority. 911 Protocol requirement compliance level: ( T ) 913 5.5.3 Netlink2 915 Netlink2 supports a priority bit in the Netlink2 message header 916 flags, as well as a 16-bit priority field using the Netlink2 header- 917 extension TLV. 919 Protocol requirement compliance level: ( T ) 921 5.6 Protocol Requirement: Reliability 923 a) The ForCES protocol will be used to transport information that 924 requires varying levels of reliability. By strict or robust 925 reliability in this requirement we mean, no losses, no corruption, 926 no re-ordering of information being transported and delivery in a 927 timely fashion. 928 b) Some information or payloads, such as redirected packets or packet 929 sampling, may not require robust reliability (can tolerate some 930 degree of losses). For information of this sort, ForCES MUST NOT 931 be restricted to strict reliability. 932 c) Payloads such as configuration information, e.g. ACLs, FIB 933 entries, or FE capability information (described in section 7, 934 (1)) are mission critical and must be delivered in a robust 935 reliable fashion. Thus, for information of this sort, ForCES MUST 936 either provide built-in protocol mechanisms or use a reliable 937 transport protocol for achieving robust/strict reliability. 938 d) Some information or payloads, such as heartbeat packets that may 939 be used to detect loss of association between CE and FEs (see 940 section 7, (8)), may prefer timeliness over reliable delivery. For 941 information of this sort, ForCES MUST NOT be restricted to strict 942 reliability. 943 e) When ForCES is carried over multi-hop IP networks, it is a 944 requirement that ForCES MUST use a RFC 2914 [12]-compliant 945 transport protocol. 946 f) In cases where ForCES is not running over an IP network such as an 947 Ethernet or cell fabric between CE and FE, then reliability still 948 MUST be provided when carrying critical information of the types 949 specified in (c) above, either by the underlying 950 link/network/transport layers or by built-in protocol mechanisms. 952 5.6.1 FACT 954 FACT uses a reliable transport protocol to meet all the reliability 955 requirements. For IP-interconnection between the protocol elements, 956 FACT uses TCP as the transport protocol for the control channel. 958 ForCES Protocol Evaluation Draft December 2003 960 Please see section 3.2 in [2] for more details on this. FACT also 961 provides protocol level responses or acknowledgements (and sequence 962 numbers) for control messages. 964 Protocol requirement compliance level: ( T ) 966 5.6.2 GRMP 968 GRMP supplies two levels of built-in error control mechanisms and 969 several other mechanisms to improve the protocol reliability: 971 1) Normal level error control 972 In this level, GRMP protocol uses a specific GRMP ACK message [3 973 Section 3.4.1] associated with "Result" and "Code" fields in the 974 message headers to protect against errors that may result from 975 message transmission, message processing, or message generating. 977 2) Strengthened level error control 978 If higher level of reliability is required for some protocol 979 messages, a built-in error control based on CRC-32 checksums can 980 furthermore be applied [3 Section 3.2]. This makes GRMP able to be 981 transported over some mediums that themselves cannot supply error 982 controls, like Ethernet, UDP, etc. 984 3) Transaction identifier to control the order of messages 985 GRMP has defined different transaction identifiers for CE generated 986 messages and for FE generated messages [3 Section 3.2]. This makes it 987 possible to use protocol built-in method to order back protocol 988 messages if in occasional cases messages are reordered. 990 4) GRMP recommends to use an RFC2914 compliant L4 protocol for 991 message transmission to improve the protocol reliability when CEs and 992 FEs are multihops away [3 Section 3.3]. 994 Protocol requirement compliance level: ( T ) 996 5.6.3 Netlink2 998 Netlink2 defines application-level ACKs to acknowedge that 999 transactions have completed successfully. Reliability can be built 1000 using such ACKs only, or can be enhanced using reliable transport 1001 protocols (expected to be necessary in the global scope), if 1002 available. Each Netlink2 message carries a sequence number as well 1003 as a flag that indicates whether an ACK is expected. 1005 Protocol requirement compliance level: ( T ) 1007 5.7 Protocol Requirement: Interconnect Independence 1009 ForCES Protocol Evaluation Draft December 2003 1011 The ForCES protocol MUST support a variety of interconnect 1012 technologies. (refer to section 5, requirement# 1) 1014 5.7.1 FACT 1016 FACT uses interconnect independent addressing (FE Identifier, CE tag) 1017 in its common header to provide interconnect independence. For non-IP 1018 interconnects, such as ATM, an interconnect specific encapsulation 1019 will have to be defined to carry the FACT messages. For IP 1020 interconnects, FACT uses TCP as the transport protocol. For non-IP 1021 interconnects, which do not provide reliability, the interconnect 1022 specific encapsulation might consist of an optional checksum and any 1023 other fields to help build reliability, although reuse of existing 1024 transport mechanisms is recommended. Please see section 3.1 in [2] 1025 for more details on this. 1027 Protocol requirement compliance level: ( T ) 1029 5.7.2 GRMP 1031 GRMP packets can be transported via any suitable mediums, such as 1032 TCP/IP, Ethernet, ATM fabrics, and bus backplanes [3 Section 3.3]. 1034 Protocol requirement compliance level: ( T ) 1036 5.7.3 Netlink2 1038 Netlink2 defines its own addressing. Encapsulations for various non- 1039 IP media remain to be defined. 1041 Protocol requirement compliance level: ( T ) 1043 5.8 Protocol Requirement: CE Redundancy or CE Failover 1045 The ForCES protocol MUST support mechanisms for CE redundancy or CE 1046 failover. This includes the ability for CEs and FEs to determine when 1047 there is a loss of association between them, ability to restore 1048 association and efficient state (re)synchronization mechanisms. This 1049 also includes the ability to preset the actions an FE will take in 1050 reaction to loss of association to its CE e.g., whether the FE will 1051 continue to forward packets or whether it will halt operations. 1052 (refer to section 5, requirement# 7) 1054 5.8.1 FACT 1056 FACT exchanges CE and FE element states using the PE State 1057 Maintenance messages. FACT also uses Heart-Beat messages (section 5.3 1058 in [2]) to detect protocol element (CE or FE) failure or loss of 1059 association between elements and to trigger a switch-over to a 1061 ForCES Protocol Evaluation Draft December 2003 1063 functioning redundant element (CE or FE). Please see section 7.3 in 1064 [2] for more details on the different mechanisms (Strong consistency, 1065 weak consistency) used for CE failover. 1067 Protocol requirement compliance level: ( T ) 1069 5.8.2 GRMP 1071 GRMP meets ForCES CE redundancy or CE failover requirement by means 1072 of following mechanisms: 1074 1) CE failover or leave policy [3 Section 4.6.4] 1075 This policy is defined as a FE attribute. In this attribute, 1076 selectable FE policies for CE failover such as FE graceful restart 1077 and CE re-association policies are defined. 1079 2) FE heartbeat policy [3 Section 4.6.6] 1080 The ability to determine the loss of association between a CE and a 1081 FE is obtained by use of this FE heartbeat policy and the associated 1082 CE heartbeat event. 1083 3) CE status event report [3 Section 4.4.2] 1085 Protocol requirement compliance level: ( T ) 1087 5.8.3 Netlink2 1089 Netlink2 accommodates transparent CE (and FE) redundancy and failover 1090 using Netlink2 multicast wires that include both the active and 1091 backup CE (and FE). Using the ECHO flag in the Netlink2 header, a 1092 hearbeat mechanism can be created to detect when failover must take 1093 place. Actions that take place after a loss of association remains 1094 to be defined. 1096 Protocol requirement compliance level: ( P+ ) 1098 5.9 Protocol Requirement: Packet Redirection/Mirroring 1100 a) The ForCES protocol MUST define a way to redirect packets from the 1101 FE to the CE and vice-versa. Packet redirection terminates any 1102 further processing of the redirected packet at the FE. 1103 b) The ForCES protocol MUST define a way to mirror packets from the 1104 FE to the CE. Mirroring allows the packet duplicated by the FE at the 1105 mirroring point to be sent to the CE while the original packet 1106 continues to be processed by the FE. 1108 Examples of packets that may be redirected or mirrored include 1109 control packets (such as RIP, OSPF messages) addressed to the 1110 interfaces or any other relevant packets (such as those with Router 1111 Alert Option set). The ForCES protocol MUST also define a way for the 1113 ForCES Protocol Evaluation Draft December 2003 1115 CE to configure the behavior of a) and b) (above), to specify which 1116 packets are affected by each. 1118 5.9.1 FACT 1120 FACT's Traffic Maintenance Message class includes Control Packet 1121 Redirect and Control Packet Forward messages to achieve packet 1122 redirection/mirroring. These messages are sent over the separate data 1123 channel. Please see section 5.4 in [2] for more details on this. 1124 Also, the Event Register/Deregister messages (section 5.5 in [2]) can 1125 be used to specify which packets should be redirected/mirrored. 1127 Protocol requirement compliance level: ( T ) 1129 5.9.2 GRMP 1131 GRMP supports packet redirection by packet redirection messages [3 1132 Section 4.7]. A LFB within LFB topology in a FE should be used to 1133 pick out packets that are to be redirected. Packets to be redirected 1134 are first put in GRMP slave [3 Section 4.6.1] and then are directed 1135 to a CE via the packet redirection message. The attribute of this 1136 filter LFB are set by CEs, therefore the CE has the ability to 1137 control which packets can be redirected. 1139 To redirect packets from CE to FE, CE just needs to encapsulate the 1140 packet to the packet redirection message and send it to the FE. On 1141 the FE side, GRMP salve resolves the redirected packet and put it 1142 into a datapath in a FE LFB topology so that they can further be 1143 delivered by the FE. 1145 By properly configuring LFBs in FE, a packet can be mirrored to CE 1146 instead of purely redirected to CE, i.e., the packet is duplicated 1147 and one is redirected to CE and the other continues its way in the 1148 LFB topology. 1150 Protocol requirement compliance level: ( T ) 1152 5.9.3 Netlink2 1154 It is expected that the necessary LFB for packet redirection and 1155 mirroring is defined by the model itself. The message format to 1156 carry redirected packets between the FE and CE remains to be defined. 1158 Protocol requirement compliance level: ( P+ ) 1160 5.10 Protocol Requirement: Topology Exchange 1162 ForCES Protocol Evaluation Draft December 2003 1164 The ForCES protocol MUST allow the FEs to provide their topology 1165 information (topology by which the FEs in the NE are connected) to 1166 the CE(s). (refer to section 5, requirement# 10) 1168 5.10.1 FACT 1170 FACT's Capabilities and Control Message class includes Query request 1171 and response messages to achieve topology information exchange 1172 between the CE and FEs. Please see sections 5.2.5, 5.2.6 in [2] for 1173 more details on this. 1175 Protocol requirement compliance level: ( T ) 1177 5.10.2 GRMP 1179 GRMP FE topology query and response messages [3 Section 4.1.3] are 1180 used for CEs to query FE topology information in the NE. 1182 Protocol requirement compliance level: ( T ) 1184 5.10.3 Netlink2 1186 This is expected to be defined by the FE model, therefore it opaque 1187 to Netlink2. 1189 Protocol requirement compliance level: ( P+ ) 1191 5.11 Protocol Requirement: Dynamic Association 1193 The ForCES protocol MUST allow CEs and FEs to join and leave a NE 1194 dynamically. (refer to section 5, requirement# 12) 1196 5.11.1 FACT 1198 FACT's Connection and Association message class includes Join 1199 request, Join response, Leave request and Leave response messages to 1200 enable dynamic joining and leaving of protocol elements (CEs, FEs) in 1201 the NE. Please see sections 5.1.1, 5.1.2, 5.1.3, 5.1.4 in [2] for 1202 more details on this. 1204 Protocol requirement compliance level: ( T ) 1206 5.11.2 GRMP 1208 In GRMP, specific FE join request message [3 Section 4.1.1] and FE 1209 leave request message [3 Section 4.1.2] make FEs able to dynamically 1210 join or leave a ForCES NE. While CE failover or leave policy [3 1211 Section 4.6.4] defines the way for CEs to dynamically join or leave 1213 ForCES Protocol Evaluation Draft December 2003 1215 the NE. GRMP also defines FE failover and rejoin policy [3 Section 1216 4.6.5] for FEs to dynamically rejoin the NE. 1218 Protocol requirement compliance level: ( T ) 1220 5.11.3 Netlink2 1222 Netlink2 uses SYN and FIN messages similarly to TCP to set up and 1223 tear down associations. Such messages are sent by default on a 1224 broadcast wire, or on pre-configured wires. 1226 Protocol requirement compliance level: ( T ) 1228 5.12 Protocol Requirement: Command Bundling 1230 The ForCES protocol MUST be able to group an ordered set of commands 1231 to a FE. Each such group of commands SHOULD be sent to the FE in as 1232 few messages as possible. Furthermore, the protocol MUST support the 1233 ability to specify if a command group MUST have all-or-nothing 1234 semantics. 1236 5.12.1 FACT 1238 FACT supports command bundling by using multiple TLVs in its message 1239 payload. For example, each TLV used in the Configure Request message 1240 could represent a different command such as Add, Delete, etc. In 1241 addition, FACT also supports 2-phase commit operations. Please see 1242 sections 5.2.3, 4.2 in [2] for more details on this. 1244 Protocol requirement compliance level: ( T ) 1246 5.12.2 GRMP 1248 GRMP supports ForCES protocol command bundling by use of GRMP batch 1249 messages [3 Section 4.8]. The messages allow GRMP application layers 1250 to pack several different sub message bodies into one single GRMP 1251 message. The sub messages are defined to be executed in an all-or- 1252 nothing mode. 1254 Protocol requirement compliance level: ( T ) 1256 5.12.3 Netlink2 1258 Netlink2 supports the concatenation of multiple commands of an 1259 identical type in the same Netlink2 message (such as multiple route 1260 additions), as well as the bundling of different commands sent in 1261 separate Netlink2 messages (using the MULTI flag). All-or-nothing 1262 (2-phase commit) is supported using the ATOMIC flag. 1264 ForCES Protocol Evaluation Draft December 2003 1266 Protocol requirement compliance level: ( T ) 1268 5.13 Protocol Requirement: Asynchronous Event Notification 1270 The ForCES protocol MUST be able to asynchronously notify the CE of 1271 events on the FE such as failures or change in available resources or 1272 capabilities. (refer to section 5, requirement# 6) 1274 5.13.1 FACT 1276 FACT's Event Notification message class includes the Asynchronous FE 1277 Event notification message used to report asynchronous FE events to 1278 the CE. Please see section 5.5 in [2] for more details on this. 1280 Protocol requirement compliance level: ( T ) 1282 5.13.2 GRMP 1284 In GRMP, a FE asynchronously informs CEs of a failure, resources and 1285 capabilities changes, and other asynchronous events via GRMP FE event 1286 report message [3 Section 4.1.8]. 1288 Protocol requirement compliance level: ( T ) 1290 5.13.3 Netlink2 1292 Netlink2 is peer-to-peer, so any addressable entity can send a 1293 message to any other. FE and LFB-level events will have to be 1294 defined in the FE model, so that Netlink2 can transmit them. 1296 Protocol requirement compliance level: ( T ) 1298 5.14 Protocol Requirement: Query Statistics 1300 The ForCES protocol MUST provide a means for the CE to be able to 1301 query statistics (monitor performance) from the FE. 1303 5.14.1 FACT 1305 FACT's Capabilities and Control message class includes the Query 1306 request and response messages which can be used by the CE for 1307 querying the FE's properties and statistics. Please see sections 1308 5.2.5, 5.2.6 in [2] for more details on this. 1310 Protocol requirement compliance level: ( T ) 1312 5.14.2 GRMP 1314 ForCES Protocol Evaluation Draft December 2003 1316 GRMP defines statistics regarding FE performance as FE or LFB 1317 attributes. GRMP uses FE attribute query and response messages [3 1318 Section 4.1.7] and LFB attribute query and response messages [3 1319 Section 4.2.4] to query the statistics. 1321 GRMP can also support query of statistics defined by network 1322 management tools like SNMP by using MO get message [3 Section 4.5.1] 1323 and MO response message [3 Section 4.5.3]. 1325 Protocol requirement compliance level: ( T ) 1327 5.14.3 Netlink2 1329 Statistics are specific to LFBs and therefore remain opaque to the 1330 Netlink2 protocol. 1332 Protocol requirement compliance level: ( T ) 1334 5.15 Protocol Requirement: Protection Against Denial of Service Attacks 1336 Systems utilizing the ForCES protocol can be attacked using denial of 1337 service attacks based on CPU overload or queue overflow. The ForCES 1338 protocol could be exploited by such attacks to cause the CE to become 1339 unable to control the FE or appropriately communicate with other 1340 routers and systems. The ForCES protocol MUST therefore provide 1341 mechanisms for controlling FE capabilities that can be used to 1342 protect against such attacks. FE capabilities that MUST be 1343 manipulated via ForCES include the ability to install classifiers and 1344 filters to detect and drop attack packets, as well as to be able to 1345 install rate limiters that limit the rate of packets which appear to 1346 be valid but may be part of an attack (e.g. bogus BGP packets). 1348 5.15.1 FACT 1350 FACT uses separate control and data channels to provide robustness in 1351 the protocol against Denial of Service (DoS) attacks. Please see 1352 section 3.3 in [2] for more details on this. Also, the Configure 1353 Request and Response messages in FACT could be used to install 1354 filters on FEs which can be used for rate-limiting the malicious 1355 traffic. 1357 Protocol requirement compliance level: ( T ) 1359 5.15.2 GRMP 1361 GRMP supports protection against DoS attacks by means of following 1362 mechanisms: 1364 1) A model for GRMP slave module [3 Section 4.6.1] 1366 ForCES Protocol Evaluation Draft December 2003 1368 In this model, all GRMP messages sending to CE are put into two 1369 different channels: the data channel, which is only for packet 1370 redirection messages, and the control channel, which is for other 1371 GRMP messages. Messages on the two channels pass through a packet 1372 scheduler for the link connecting to CE. The scheduler is managed by 1373 CE by setting some scheduling policies (disciplines) to it. In this 1374 way, the CE can control the traffic over the two channels dynamically 1375 according to the monitored traffic status, to defend against DoS 1376 attacks and to protect control channel transmission. 1378 2) GRMP DoS protection policy [3 Section 4.6.2] 1379 In this policy, scheduling priorities, channel bandwidths, and 1380 congestion control policies for the individual data channel and 1381 control channel can be set. 1383 3) GRMP DoS attack alert policy [3 Section 4.6.3] 1385 4) A DoS attack alert event report [3 Section 4.1.8] 1387 Protocol requirement compliance level: ( T ) 1389 5.15.3 Netlink2 1391 Netlink2 defines Netlink2 SYN Cookies as a mechanism to prevent DoS 1392 attacks originating in a environment where security cannot be 1393 physically ensured. Netlink2 relies on appropriate policers to rate 1394 limit data traffic redirected to CEs. As different wires may be used 1395 for data and control traffic, prioritization and 1396 reliability/unreliability can be chosen appropriately for each wire 1397 with a suitable transport protocol. 1399 Protocol requirement compliance level: ( T ) 1401 5.16 Protocol Requirement Summary Table 1403 This section is a summary of the compliance levels claimed for each 1404 protocol above and is included as a convenience. 1406 ForCES Protocol Evaluation Draft December 2003 1408 Protocol Requirement FACT GRMP Netlink2 1409 ==================================================================== 1410 1. Configuration of Modeled Elements T T T 1411 2. Support for Secure Communication T T P+ 1412 3. Scalability T T T 1413 4. Multihop T T T 1414 5. Message Priority T T T 1415 6. Reliability T T T 1416 7. Interconnect Independence T T T 1417 8. CE Redundancy or CE Failover T T P+ 1418 9. Packet Redirection/Mirroring T T P+ 1419 10. Topology Exchange T T P+ 1420 11. Dynamic Association T T T 1421 12. Command Bundling T T T 1422 13. Asynchronous Event Notification T T T 1423 14. Query Statistics T T T 1424 15. Protection Against Denial of Service Attacks T T T 1426 Security Considerations 1428 This document is a comparison between three protocols in order to 1429 help in the selection of the best approach to use as the ForCES 1430 protocol. Security considerations are addressed in each of the 1431 protocol proposals and MUST be included as part of the fitness 1432 evaluation for each proposal. 1434 References 1436 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1437 9, RFC 2026, October 1996. 1439 2 Audu, A. et al., "ForwArding and Control ElemenT protocol (FACT)", 1440 work in progress, November 2003, 1442 3 Wang, W. et al., "General Router Management Protocol (GRMP) 1443 Version 1", November 2003, 1445 4 Salim, J. H. et al., "Netlink2 as ForCES Protocol", work in 1446 progress, October 2003, 1448 5 Khosravi, H. et al., "Requirements for Separation of IP Control 1449 and Forwarding", RFC 3654, July 2003. 1451 ForCES Protocol Evaluation Draft December 2003 1453 6 Yang, L. et al., "Forwarding and Control Element Separation 1454 (ForCES) Framework", work in progress, October 2003, 1455 1457 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1458 Levels", BCP 14, RFC 2119, March 1997 1460 8 Barnes, M., "Middlebox Communications (MIDCOM) Protocol 1461 Evaluation", work in progress, Nov 2002, 1462 1464 9 Yang, L. et al., "ForCES Forwarding Element Functional Model", 1465 work in progress, October 2003, 1467 10 Hadi Salim, et. al., "Linux Netlink as an IP Services Protocol", 1468 RFC 3549, July 2003. 1470 11 M. Bakke, et. al., "iSCSI Naming and Discover", work in Progress, 1471 June 20, 2003, 1473 12 S. Floyd, "Congestion Control Principles", RFC2914, September 1474 2000. 1476 Author's Addresses 1478 Alex Audu 1479 Alcatel R&I 1480 1000 Coit Road 1481 Plano, TX 75075 1482 U.S.A. 1483 Phone: 1-972-477-7809 1484 Email: alex.audu@alcatel.com 1486 Steven Blake 1487 Ericsson 1488 920 Main Campus Drive, Suite 500 1489 Raleigh, NC 27606 1490 U.S.A. 1491 Email: steven.blake@ericsson.com 1493 Ligang Dong 1494 Hangzhou University of Commerce 1495 149 Jiaogong Road 1496 Hangzhou, 310035, P.R.China 1497 Phone: +86-571-88071024 1498 Email: donglg@mail.hzic.edu.cn 1500 ForCES Protocol Evaluation Draft December 2003 1502 Robert Haas 1503 IBM Research 1504 Zurich Research Laboratory 1505 Saeumerstrasse 4 1506 CH-8803 Rueschlikon, 1507 Switzerland 1508 Email: rha@zurich.ibm.com 1510 Hormuzd Khosravi 1511 Intel 1512 2111 NE 25th Avenue 1513 Hillsboro, OR 97124 1514 U.S.A. 1515 Phone: 1-503-264-0334 1516 Email: hormuzd.m.khosravi@intel.com 1518 David Putzolu 1519 Intel 1520 Mailstop JF3-206-H10 1521 2111 NE 25th Avenue 1522 Hillsboro, OR 97124 1523 U.S.A. 1524 Phone: 1-503-264-4510 1525 Email: david.putzolu@intel.com 1527 Jamal Hadi Salim 1528 Znyx Networks 1529 195 Stafford Rd. West 1530 Ottawa, Ontario 1531 Canada 1532 Email: hadi@znyx.com 1534 Weiming Wang 1535 Department of Information and Electronic Engineering 1536 Hangzhou University of Commerce 1537 149 Jiaogong Road 1538 Hangzhou, 310035, P.R.China 1539 Phone: +86-571-88057712 1540 Email: wangwm@hzcnc.com