idnits 2.17.1 draft-putzolu-forces-evaluation-01.txt: -(433): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(499): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(535): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(537): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(839): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1133): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 17 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 7) being 59 lines 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 3 instances of too long lines in the document, the longest one being 1 character 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: ---------------------------------------------------------------------------- == Line 1143 has weird spacing: '...ossibly by ve...' -- 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 (October 2003) is 7499 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 13 looks like a reference -- Missing reference section? '2' on line 1218 looks like a reference -- Missing reference section? '3' on line 32 looks like a reference -- Missing reference section? '4' on line 33 looks like a reference -- Missing reference section? '5' on line 313 looks like a reference -- Missing reference section? '6' on line 34 looks like a reference -- Missing reference section? '7' on line 44 looks like a reference -- Missing reference section? '8' on line 92 looks like a reference -- Missing reference section? '9' on line 453 looks like a reference -- Missing reference section? '10' on line 374 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ForCES Working Group 3 Internet Draft D. Putzolu (editor) 4 Document: draft-putzolu-forces-evaluation-01.txt Intel 5 Expires: April 2004 October 2003 7 ForCES Protocol Evaluation Draft 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document provides an evaluation of the applicability of three 32 proposed approaches for a ForCES protocol: FACT[2], GRMP[3], and 33 Netlink2[4]. A summary of each of the proposed protocols against the 34 ForCES requirements[5] and the ForCES framework[6] is provided. 35 Compliancy of each of the protocols against each requirement is 36 detailed. A conclusion summarizes how each of the protocols fares in 37 the evaluation. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC-2119 [7]. 45 Table of Contents 47 1. Introduction...................................................2 48 2. Protocol Proposals.............................................3 49 2.1 FACT.......................................................4 50 2.2 GRMP.......................................................4 51 2.3 Netlink2...................................................7 52 3. Architectural Requirements Compliance Evaluation...............7 53 3.1 FACT.......................................................7 54 3.2 GRMP.......................................................7 55 3.3 Netlink2...................................................9 56 4. Model Requirements Compliance Evaluation.......................9 57 4.1 FACT......................................................10 58 4.2 GRMP......................................................10 59 4.3 Netlink2..................................................11 60 5. Protocol Requirements Compliance Evaluation...................11 61 5.1 Protocol Requirement: Configuration of Modeled Elements...11 62 5.2 Protocol Requirement: Support for Secure Communication....13 63 5.3 Protocol Requirement: Scalability.........................14 64 5.4 Protocol Requirement: Multihop............................15 65 5.5 Protocol Requirement: Message Priority....................16 66 5.6 Protocol Requirement: Reliability.........................17 67 5.7 Protocol Requirement: Interconnect Independence...........18 68 5.8 Protocol Requirement: CE Redundancy or CE Failover........19 69 5.9 Protocol Requirement: Packet Redirection/Mirroring........20 70 5.10 Protocol Requirement: Topology Exchange..................21 71 5.11 Protocol Requirement: Dynamic Association................22 72 5.12 Protocol Requirement: Command Bundling...................22 73 5.13 Protocol Requirement: Asynchronous Event Notification....23 74 5.14 Protocol Requirement: Query Statistics...................24 75 5.15 Protocol Requirement: Protection Against Denial of Service 76 Attacks.......................................................25 77 5.16 Protocol Requirement Summary Table.......................26 78 Security Considerations..........................................27 79 References.......................................................27 80 Acknowledgments..................................................28 81 Author's Addresses...............................................28 83 1. 84 Introduction 86 This document provides an evaluation of the applicability of FACT, 87 GRMP, and Netlink2 as the ForCES protocol. This evaluation provides 88 overviews of the protocols and general statements of applicability 89 based upon the ForCES framework and requirements documents. The 90 format and structure as well as some of the introductory content of 91 this document is based on and taken from a similar document being 92 produced in the MIDCOM working group[8]. 94 The process for protocol evaluation found in this document consists 95 of individuals providing sections evaluating a specific protocol. 96 These sections are incorporated by the editor of the document, and 97 are subject to feedback and changes based on the consensus of the 98 ForCES working group. Some protocols that might be considered as 99 potentially applicable as the ForCES protocol are not evaluated in 100 this document since there where no champions to submit evaluations 101 for them. 103 Section 2 of this document is a list of the proposed protocols along 104 with background information about each of the protocols. 106 Section 3 of this document is an evaluation of the proposed protocols 107 against the architectural requirements found in section 5 of the 108 ForCES requirements. The purpose of this section is to determine how 109 well each of the proposed protocols maps to the ForCES architecture. 111 Section 4 of this document is an evaluation of the proposed protocols 112 against the model requirements found in ForCES requirements. The 113 purpose of this section is to determine how well each of the proposed 114 protocols can be used with FEs that meet the ForCES model 115 requirements. 117 Section 5 of this document is an item level evaluation of the 118 proposed protocols against the protocol requirements found in the 119 ForCES requirements. The purpose of this section is to determine how 120 well each of the proposed protocols satisfies each of the protocol 121 requirements. 123 Section 6 summarizes the evaluation, and includes a table with a 124 breakdown for each of the protocols versus the requirements. The 125 following categories of compliance are used: Fully met, partially met 126 through the use of extensions, partially met through other changes to 127 the protocol, or not met. This summary is not a conclusive statement 128 of the suitability of the protocols, but rather to provide 129 information to be considered as input into the overall protocol 130 decision process. 132 2. 133 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 2.1 145 FACT 147 Network Elements (NE) such as routers are becoming more and more 148 complex as they try to cope with demanding features like policy based 149 routing, firewalls and NATs, and QoS aware routing. As a result, 150 issues like scalability, (the ability to cost-effectively grow a 151 network as demand increases) and extensibility (the ability to 152 dynamically configure the network for some specific services by 153 programming the NEs that handle those services) become very 154 important. The ForCEs protocol has been specified to help resolve 155 these issues by decoupling control and forwarding elements of a 156 network element, and also adding extensibility features to the NE. 158 FACT (Forwarding And Control ElemenT) protocol has been designed for 159 exchanging information between control elements (CEs) and forwarding 160 elements (FEs) distributed in a ForCES network element (NE). The 161 relationship between CEs and FEs is a master/slave one. The FACT 162 protocol is logically separated into a base protocol and an 163 extensible data model defined in [9]. It consists of a common, fixed 164 size header and variable size payload which carries the information 165 defined by the data model. All FACT messages are 32-bit aligned. 167 FACT�s messages are grouped into six (6) classes namely: 168 1) Connection and Association messages, which help establish 169 logical connections between FEs and CEs, 170 2) Capabilities Control messages, which the CE uses to query and 171 configure the capabilities of the FE, 172 3) State Maintenance messages, which are used to track element 173 states, 174 4) Traffic Maintenance messages, which are used exchanging control 175 packets between CEs and FEs, 176 5) Event Notification messages used for reporting asynchronous 177 events, and 178 6) Vendor Specific messages which are used to extend the protocol 179 beyond its current capabilities. 181 FACT supports versioning and priority, and its unique design of 182 separating control and data traffic into different channels helps 183 reduce the threat of Denial of Service (DoS) attacks making the 184 protocol more robust. It provides reliability by using a reliable 185 transport protocol, thus simplifying the protocol design. It also 186 provides failover mechanisms that can exploit redundant elements in 187 the system or network element. 189 2.2 190 GRMP 192 General Router Management Protocol (GRMP) Version 1 is intended to be 193 as a ForCES protocol, which acts at the Fp reference point in the 194 ForCES framework. GRMP is designed to meet all the requirements for 195 the ForCES protocol at the Fp reference point. 197 GRMP protocol is a master-slave protocol. CEs act as masters and FEs 198 as slaves. Slaves only have right to send to masters request or 199 query, response, and report messages. While masters can send command 200 messages to slaves as well as request or query, response, and report 201 messages. GRMP protocol acts in a mode of a base-protocol associated 202 with a data model, which is FE model in ForCES. That is, GRMP only 203 defines basic management messages, while many of managed data are 204 defined in the associated ForCES FE model. Most of the data types and 205 functional descriptions relating to specific IP services such as 206 routing service conforming to RFC 1812 [10], QoS configurations, 207 high-tough capabilities like NAT and firewall should be expressed by 208 Logical functional Blocks (LFBs) defined by ForCES FE model and their 209 specific LFB topologies. GRMP application layer is responsible to 210 configure the LFBs and the LFB topologies so as to implement specific 211 IP services and QoS deployment. 213 GRMP is developed separately from General Switch Management Protocol 214 (GSMP) protocol since current base specification version of GSMP did 215 not support some of the basic functionality needed by GRMP. However, 216 GRMP has been considering its possible compatibility with GSMP; with 217 the work currently ongoing within the GSMP group that is adding 218 flexibility to the base, GRMP is willing to work with the GSMP group 219 to integrate this with GSMP. 221 GRMP protocol is composed of protocol messages. GRMP organizes these 222 messages according to different object types the messages manage for 223 ForCES architecture, as follows: 225 1. FE management messages 226 This type of messages is for FE layer operations, that is, to take a 227 whole FE as a managed object. Messages of this type include that for 228 operation of FE join or leave, FE action, FE attribute, FE event 229 report, etc. 231 2. LFB management messages 232 This type of messages is for LFB layer operations. It takes LFBs as 233 its managed objects. Messages of this type include that for 234 operation of LFB action, LFB attribute, etc. 236 3. Datapath management messages 237 This type of messages is for the management of datapaths in an FE. 238 It takes datapathes as the managed objects. 240 4. CE Informing messages 241 This type of messages takes CE as the operated object to ask CE to 242 send some information. Because CE acts as a master in ForCES 243 protocol, allowed operations toward CE from FE are only that like CE 244 query request, CE event report, etc. 246 5. GRMP slave management 247 In GRMP, the GRMP slave part is treated as a module inside an FE. 248 This module is outside of FE model scope, which will automatically 249 be launched in a FE when the FE is to join a ForCES NE. Management 250 to a GRMP slave is that like DoS protection policy, CE or FE 251 failover policy, etc. Note that the management of GRMP slave does 252 not take specific GRMP messages, in stead, it uses FE management 253 messages for GRMP slave is considered as an object at FE layer. 255 6. Managed Object(MO) management messages 256 In order to meet ForCES requirement of supporting network management 257 tools like SNMP, GRMP provides the management messages. This type of 258 messages takes a Managed Object (MO) defined in some specific 259 network management tools as its managed objects. Operations of MOs 260 are that like MO get, MO set, and MO response. 262 There is another GRMP message that is defined out of scope of 263 management purposes. This is GRMP ACK (acknowledge) message, which is 264 mainly for communication control and error control purpose between CE 265 and FE. 267 From perspective the message communication types between CE and FE, 268 GRMP messages can be divided into following types: 270 1. Messages for query and response types. These messages can be sent 271 from CE to FE, or from FE to CE. 273 2. Messages for command and configuration types. These messages are 274 only sent from CE to FE. 276 3. Messages for report types. These messages can be sent from CE to 277 FE, or from FE to CE. 279 In GRMP, a 5 bits "object class" identifier [3 Section 3.4.5] is 280 applied to following GRMP managed objects: 281 FE capability types 282 FE attribute types 283 LFB types 284 LFB attribute types 285 CE attribute types 286 CE event types 287 Currently defined "object class" includes GRMP class, different 288 version of ForCES FE model class, vendor class. This means the 289 managed objects above can include that defined by GRMP itself, 290 different versions of ForCES FE models, and different vendors. 292 2.3 293 Netlink2 295 297 3. 298 Architectural Requirements Compliance Evaluation 300 This section contains a review of each protocol proposal�s level of 301 compliance to the ForCES architecture requirements. Many of the 302 architectural requirements will be instantiated in some fashion in 303 the protocol selected. Given that the architectural requirements are 304 not direct protocol requirements, the review below will consist of 305 prose rather than specific levels of compliance as is used in the 306 protocol section below. 308 3.1 309 FACT 311 FACT fulfills all the protocol requirements listed in section 5. By 312 doing this it in turn supports all the architectural requirements 313 defined in the ForCES Requirements [5]. FACT supports the separation 314 of the NE into CE and FE components, with CE handling roles such as 315 control, signaling and routing data calculation. The CE configures 316 the FE with all the information necessary for the FE�s proper 317 operation. The FE�s functions could be layer-3 forwarding, NAT, 318 metering, shaping, firewall, etc. Also, FACT state maintenance 319 messages help resolve the various states of the distributed CEs and 320 FEs to provide a unified state of the NE. 322 3.2 323 GRMP 325 GRMP protocol is designed based on the ForCES architecture 326 requirements. We review its compliance to the architecture 327 requirements according to the individual requirement items as below: 329 1) For architecture requirement #1 330 GRMP packets can be transported via any suitable mediums, such as 331 TCP/IP, Ethernet, ATM fabrics, and bus backplanes. Because of the 332 design consideration for GRMP to be compatible with GSMP protocol, 333 packet encapsulations defined for GSMP protocols as in RFC 3293 can 334 also be applied to GRMP. 336 2) For architecture requirement #2 337 ForCES requires that FEs MUST support a minimal set of capabilities 338 necessary for establishing network connectivity (e.g., interface 339 discovery, port up/down functions). This process is usually out of 340 the range of ForCES protocol, but GRMP protocol has no restriction on 341 this functionality. 343 3) For architecture requirement #3 344 By properly configuring FEs with their LFBs in a NE via GRMP 345 protocol, packets can arrive at one FE and depart at the other FE or 346 FEs. In the case where more than one CE work simultaneously in a NE, 347 the consistency and synchronization of control of the CEs is 348 essential for above functionality, which is beyond the scope of 349 ForCES protocol and also architecture requirements. 351 4) For architecture requirement #4 352 By properly configuring LFBs in FEs in a NE via GRMP protocol, the NE 353 can appear as a single functional device in a network. In the case 354 more than one CE work simultaneously in a NE, the consistency and 355 synchronization for the CEs to control FEs is essential for this 356 functionality, which is beyond the scope of ForCES protocol and 357 architecture requirements. 359 5) For architecture requirement #5 360 ForCES protocol requirement #2 has comprised this architecture 361 requirement, refer to Section 5.2.2 for details on GRMP compliance 362 to this requirement. 364 6) For architecture requirement #6 365 Please refer to Section 5.13.2 for details. 367 7) For architecture requirement #7 368 Please refer to Section 5.8.2 for details. 370 8) For architecture requirement #8 371 Please refer to Section 5.9.2 for details. 373 9) For architecture requirement #9 374 GRMP supports RFC1812 [10] compliant router functions by means of 375 following mechanisms in GRMP: 376 -Fully supporting ForCES FE model 377 -Packet redirection messages 378 -Datapath management messages 379 -Managed Object(MO) management messages 381 10) For architecture requirement #10 382 In GRMP, FE topology query and response messages [3 Section 4.1.3] 383 are used for CEs to query FE topology information in a NE. 385 11) For architecture requirement #11 386 Please refer to Section 5.3.2 for details. 388 12) For architecture requirement #12 389 Please refer to Section 5.11.2 for details. 391 13) For architecture requirement #13 392 GRMP supports multiple FEs working together in a NE by using FE 393 identifiers and by allowing CEs to be informed of FE topology 394 information. GRMP supports multiple CEs working together in a NE by 395 supporting CE redundancy or failover functionality. 397 14) For architecture requirement #14 398 GRMP defines Managed Object (MO) management messages [3 Section 4.5] 399 to meet the requirement, in which it states that it must not be 400 possible for management tools (e.g. SNMP, etc) to change the state of 401 a FE in a manner that affects overall NE behavior without the CE 402 being notified. 404 A MO is an object defined by some network management tool, such as 405 the object defined by Object Identifier in SNMP MIBs. 407 MO management messages work in the way as below: 409 1. Query of MOs resident in an FE can be directly implemented by 410 network management tools. To perform this, it is necessary for CE to 411 configure some LFBs that has high touch capability in the FE. 413 2. Change of MOs resident in an FE can only be made via a CE. To do 414 this, the high touch LFBs in the FE will redirect all network 415 management protocol messages like SNMP messages concerning MO changes 416 to the CE, then the CE will use the MO management messages to change 417 values of MOs in the FE. Of course, if necessary, query of the MOs 418 can also be made via the CE. 420 3. MOs resident in a CE can be directly queried or changed by the CE 421 with the CE high tough capability. Before the CE can do this, network 422 management messages are still needed to be redirected from FEs to the 423 CE. 425 3.3 426 Netlink2 428 430 4. 431 Model Requirements Compliance Evaluation 433 This section contains a review of each protocol�s level of compliance 434 to the ForCES model requirements. The ForCES model will indirectly 435 relate to the protocol in that the protocol will be used to carry 436 information that the model represents. Given that the model 437 requirements are only indirectly related to the protocol selection, 438 the review below will consist of prose rather than specific levels of 439 compliance as is used in the protocol section below. 441 4.1 442 FACT 444 The FACT protocol is logically separated into a base protocol and an 445 extensible payload which can be used to carry the FE, Logical 446 Functional Block (LFB) specific data which is defined by the FE Model 447 [9]. Thus the FACT protocol is cleanly separated from the data model 448 that it carries. The FE Model draft [9] defines the data model for 449 the Forwarding Element and meets all the Model requirements. 451 FACT�s Configure Request and Configure Response message types under 452 the Capabilities Control message group provide a flexible way to 453 configure the functionality of the FE according to the FE Model [9]. 454 The specific parameters needed to assign functionalities and 455 behaviors to the Logical Functional Blocks (LFBs) in the FEs are 456 dictated by the FE Model. 458 Vendor Specific functions are supported by VS-Data request and VS- 459 Data response messages in the Vendor Specific message group. 461 4.2 462 GRMP 464 GRMP protocol is designed to use ForCES FE model as a base data model 465 for the protocol functionality. GRMP aims to support all operations 466 to all elements defined in ForCES FE model. Because ForCES FE model 467 work is still in progress, following elements for ForCES FE model 468 (including capability model and state model) with their operations 469 are presented in current version of GRMP document: 470 -FE capabilities 471 -FE attributes, including FE statistics 472 -FE events 473 -LFBs with their attributes (including capabilities, statistics, 474 etc), their actions, and their topologies 475 -Datapaths 476 Section 5.1.2 has described GRMP supported management for modeled 477 elements including all above ForCES FE model elements in details. 478 Along with the progress in ForCES FE model work, a modification of 479 GRMP can be made to coordinate with the modification in ForCES FE 480 model. 482 GRMP supports ForCES FE model to meet following model requirements 483 without any restriction from the protocol: 485 1. Types of logical functions 486 2. Variations of logical functions 487 3. Ordering of logical functions 488 4. Flexibility 489 5. Minimal set of logical functions 491 4.3 492 Netlink2 494 496 5. 497 Protocol Requirements Compliance Evaluation 499 This section contains a review of each protocol�s level of compliance 500 to the ForCES protocol requirements. Given that the protocol 501 requirements are directly related to the protocol proposals, a very 502 concrete method is used in reviewing compliance - the following key 503 identifies the level of compliance for each of the following 504 protocols to each protocol requirement in the ForCES requirements 505 RFC: 507 T = Total compliance. Meets the requirement fully. 509 P+ = Partial compliance. Fundamentally meets the requirement through 510 the use of extensions (e.g. packages, additional parameters, etc.) 512 P = Partial compliance. Meets some aspect of the requirement, 513 however, the necessary changes require more than an extension and/or 514 are inconsistent with the design intent of the protocol. 516 N = Not compliant. Does not meet the requirement. 518 Each subsection of this section begins with the specific protocol 519 requirement text found in the ForCES requirements. 521 5.1 522 Protocol Requirement: Configuration of Modeled Elements 524 The ForCES protocol MUST allow the CEs to determine the capabilities 525 of each FE. These capabilities SHALL be expressed using the FE model 526 whose requirements are defined in Section 6. Furthermore, the 527 protocol MUST provide a means for the CEs to control all the FE 528 capabilities that are discovered through the FE model. The protocol 529 MUST be able to add/remove classification/action entries, set/delete 530 parameters, query statistics, and register for and receive events. 532 5.1.1 FACT 534 Compliance = T 535 FACT�s Capabilities Control message class contains Configure Request 536 and Configure Response messages that can be used to configure the 537 FE�s behavior from the CE. Also, the Capability request and response 538 messages can be used by the CE to query and learn the FE 539 capabilities. Please see section 5.2 in [2] for more details on this. 541 5.1.2 GRMP 543 Most of GRMP protocol messages are for the management of modeled 544 elements in ForCES FEs. They are listed as follows: 546 1) FE capability query and response messages [3 section 4.1.4] 547 The messages allow a CE to query and get response of the capabilities 548 of a FE. The FE capabilities include all FE capability types that are 549 defined by vendors or this GRMP protocol itself, as well as defined 550 in FE model. 552 2) FE attribute manipulate message [3 section 4.1.6] 553 This message allows a CE to manipulate (add, delete, modify) 554 attributes of a FE. The FE attributes should be the type of FE 555 attributes that are allowed to be manipulated. They may be defined in 556 FE model, by vendors or by GRMP itself. 558 3) FE attribute query and response messages [3 section 4.1.7] 559 The messages allow a CE to query and get response of FE attribute 560 values. The FE attributes should be the types of FE attributes that 561 are allowed to be queried. The queried FE attribute may be defined in 562 FE model, by vendors or by GRMP itself. Note that FE attributes 563 include FE level statistics. 565 4) FE event report message [3 section 4.1.8] 566 This message allows a FE to report events to a CE. The FE events 567 include all events that are defined in FE model, by vendors and by 568 GRMP itself. Some FE events may need to be registered by a CE before 569 they are willing to send reports to the CE, but the others may need 570 not. An FE attribute defined by GRMP itself (as a GRMP class object) 571 is used for a CE to register its interested FE events [3 Section 572 4.1.6-Page29]. 574 5) LFB action manipulate message [3 section 4.2.1]. 575 This message allows a CE to manipulate LFB actions in a FE ( LFB add, 576 delete, modify, up, down, active, inactive, etc). The LFBs may be 577 that defined in FE model, by vendors or by GRMP itself. Note that the 578 LFB action manipulate message for LFB add operation has also included 579 the operation to configure LFB topologies. In GRMP protocol, LFB 580 topology is represented by means of PkfIDs [3 Section 3.4.6] [3 581 Section 4.2.1]. 583 6) LFB topology query and response messages [3 section 4.2.2] 584 The messages allow a CE to query and get response of whole or some 585 LFB topologies within a FE. The LFB topology representation is based 586 on PkfIDs. 588 7) LFB attribute manipulate message [3 section 4.2.3]. 590 This message allows a CE to manipulate (add, delete, or modify) LFB 591 attributes in a FE. The LFB attributes include all attributes that 592 are allowed to be manipulated in a LFB, and they may be defined via 593 FE model, by vendors or by GRMP itself. 595 8) LFB attribute query and response messages [3 section 4.2.4] 596 The messages allow a CE to query and get response of LFB attribute 597 values in a FE. Note that LFB attributes include LFB level 598 capabilities, statistics, etc. 600 9) Datapath Manipulate Message [3 section 4.3.1] 601 This message allows a CE to manipulate (add, delete, modify) 602 datapaths that interconnect LFBs in a FE. Datapaths are represented 603 by PkfIDs. 605 10) Datapath query and response messages [3 section 4.3.2] 606 The messages allow a CE to query and get response of connection 607 status of all or some datapaths in a LFB topology in a FE. 609 Protocol requirement compliance level: ( ) 611 5.1.3 Netlink2 613 615 5.2 616 Protocol Requirement: Support for Secure Communication 618 a) FE configuration will contain information critical to the 619 functioning of a network (e.g. IP Forwarding Tables). As such, it 620 MUST be possible to ensure the integrity of all ForCES protocol 621 messages and protect against man-in-the-middle attacks. 622 b) FE configuration information may also contain information derived 623 from business relationships (e.g. service level agreements). 624 Because of the confidential nature of the information, it MUST be 625 possible to secure (make private) all ForCES protocol messages. 626 c) In order to ensure that authorized CEs and FEs are participating 627 in a NE and defend against CE or FE impersonation attacks, the 628 ForCES architecture MUST select a means of authentication for CEs 629 and FEs. 630 d) In some deployments ForCES is expected to be deployed between CEs 631 and FEs connected to each other inside a box over a backplane, 632 where physical security of the box ensures that man-in-the-middle, 633 snooping, and impersonation attacks are not possible. In such 634 scenarios the ForCES architecture MAY rely on the physical 635 security of the box to defend against these attacks and protocol 636 mechanisms May be turned off. 637 e) In the case when CEs and FEs are connected over a network, 638 security mechanisms MUST be specified or selected that protect the 639 ForCES protocol against such attacks. Any security solution used 640 for ForCES MUST specify how it deals with such attacks. 642 5.2.1 FACT 644 Compliance = T 645 FACT uses TLS when its endpoints are running over an IP network or in 646 an insecure environment. For a closed box or physically secure 647 environment, it is possible to turn off the protocol security 648 functions. The security association between the CEs and FEs is 649 established before any FACT association establishment messages are 650 exchanged. Also, FACT recommends using rate limiting mechanisms on 651 the FE to protect against DoS attacks. Please see section 8 in [2] 652 for more details on this. 654 5.2.2 GRMP 656 1) When GRMP messages are encapsulated in a IP based medium, GRMP 657 protocol has recommended to use IPsec or TLS(only for reliable 658 transport protocols), which is also recommended by ForCES framework, 659 to secure the communication between CEs and FEs to defend against 660 possible man-in-the-middle or replay attacks and to do authentication 661 for CEs and FEs. GRMP has no restrictions on using other approaches 662 for secure communications. 664 2) When GRMP messages are transported via bus backplanes, the secure 665 mechanism is allowed to be turned off while without affecting GRMP 666 functions. 668 3) Current version of GRMP has not yet recommended secure mechanisms 669 for GRMP messages to transmit over Ethernet or ATM mediums. 671 Protocol requirement compliance level: ( ) 673 5.2.3 Netlink2 675 677 5.3 678 Protocol Requirement: Scalability 680 The ForCES protocol MUST be capable of supporting (i.e., must scale 681 to) at least hundreds of FEs and tens of thousands of ports. For 682 example, the ForCES protocol field sizes corresponding to FE or port 683 numbers SHALL be large enough to support the minimum required 684 numbers. This requirement does not relate to the performance of a NE 685 as the number of FEs or ports in the NE grows. 687 5.3.1 FACT 688 Compliance = T 689 FACT can support up to 64K FEs and 64K CEs at the same time due its 690 16 bit addressing range of both the CE-Tag and FE-Identifier fields. 691 Please see section 4.1 in [2] for more details on this. In addition, 692 it uses TCP (for IP interconnection between CEs and FEs) which 693 provides congestion control and thus helps in supporting the 694 scalability requirement. 696 5.3.2 GRMP 698 In GRMP, a FE is identified by a 16 bits FE Identifier [3 section 699 3.2], which is theoretically able to identify up to 64k FEs. 701 Possible limitation in GRMP protocol to FE port number may be from FE 702 port address space, maximum number of list elements in "list data 703 format" [3 section 3.4.3], and LFB instance identifier space. The 704 evaluations of scalability for them are as follows: 706 1) An Addressable Entity (AE) address data format is defined in GRMP 707 [3 section 3.4.4], which is theoretically capable of describing any 708 length of addresses of AEs, therefore FE port address space is not 709 limited. 711 2) Element number of a list in "list data format" [3 section 3.4.3] 712 is expressed with 16 bits data space, which theoretically limits list 713 element number within 64k. 715 3) LFB instance ID [3 section 4.2.1] is expressed using 16 bits data 716 space, which can also theoretically represent 64k instances of one 717 kind of LFB such as a port LFB. 719 Protocol requirement compliance level: ( ) 721 5.3.3 Netlink2 723 725 5.4 726 Protocol Requirement: Multihop 728 When the CEs and FEs are separated beyond a single hop, the ForCES 729 protocol will make use of an existing RFC2914 compliant L4 protocol 730 with adequate reliability, security and congestion control (e.g. TCP, 731 SCTP) for transport purposes. 733 5.4.1 FACT 735 Compliance = T 736 FACT uses TCP as the transport protocol which is congestion aware and 737 meets the transport requirements for multi-hop IP networks. Please 738 see section 3.2 in [2] for more details on this. 740 5.4.2 GRMP 742 GRMP is designed in its aims to be capable of supporting remote 743 control that allows CEs and FEs to separate multihops away, as well 744 as supporting close or very close proximity control of CEs and FEs. 745 GRMP has no restriction for ForCES NE administrators to use any RFC 746 2914 compliant L4 protocols such as TCP or SCTP as interconnection 747 protocols to increase the control reliability, security and 748 congestion control ability, though current document of GRMP has 749 missed making a recommendation on this. Besides, GRMP is seeking the 750 possibility to potentially support L3 layer QoS based traffic control 751 between CEs and FEs with the use of scheduling mechanisms in GRMP 752 slave module [3 section 4.6.1]. 754 Protocol requirement compliance level: ( ) 756 5.4.3 Netlink2 758 760 5.5 761 Protocol Requirement: Message Priority 763 The ForCES protocol MUST provide a means to express the protocol 764 message priorities. 766 5.5.1 FACT 768 Compliance = T 769 FACT supports up to 8 levels of priority using the 3 priority bits in 770 the common header. Please see section 4.1.6 in [2] for more details 771 on this. 773 5.5.2 GRMP 775 GRMP defines a priority field (P) at GRMP message header [3 section 776 3.2] to express the protocol message priority. Currently only two 777 priority levels are defined: normal priority and high priority. 779 Protocol requirement compliance level: ( ) 781 5.5.3 Netlink2 783 785 5.6 786 Protocol Requirement: Reliability 788 a) The ForCES protocol will be used to transport information that 789 requires varying levels of reliability. By strict or robust 790 reliability in this requirement we mean, no losses, no corruption, 791 no re-ordering of information being transported and delivery in a 792 timely fashion. 793 b) Some information or payloads, such as redirected packets or packet 794 sampling, may not require robust reliability (can tolerate some 795 degree of losses). For information of this sort, ForCES MUST NOT 796 be restricted to strict reliability. 797 c) Payloads such as configuration information, e.g. ACLs, FIB 798 entries, or FE capability information (described in section 7, 799 (1)) are mission critical and must be delivered in a robust 800 reliable fashion. Thus, for information of this sort, ForCES MUST 801 either provide built-in protocol mechanisms or use a reliable 802 transport protocol for achieving robust/strict reliability. 803 d) Some information or payloads, such as heartbeat packets that may 804 be used to detect loss of association between CE and FEs (see 805 section 7, (8)), may prefer timeliness over reliable delivery. For 806 information of this sort, ForCES MUST NOT be restricted to strict 807 reliability. 808 e) When ForCES is carried over multi-hop IP networks, it is a 809 requirement that ForCES MUST use a RFC 2914 [11]-compliant 810 transport protocol. 811 f) In cases where ForCES is not running over an IP network such as an 812 Ethernet or cell fabric between CE and FE, then reliability still 813 MUST be provided when carrying critical information of the types 814 specified in (c) above, either by the underlying 815 link/network/transport layers or by built-in protocol mechanisms. 817 5.6.1 FACT 819 Compliance = T 820 FACT uses a reliable transport protocol to meet all the reliability 821 requirements. For IP-interconnection between the protocol elements, 822 FACT uses TCP as the transport protocol for the control channel. 823 Please see section 3.2 in [2] for more details on this. 825 5.6.2 GRMP 827 GRMP supplies two levels of built-in error control mechanisms and 828 several other mechanisms to improve the protocol reliability: 830 1) Normal level error control 831 In this level, GRMP protocol uses a specific GRMP ACK message [3 832 Section 3.4.1] associated with "Result" and "Code" fields in GRMP 833 message headers [3 Section 3.2] to protect against errors that may 834 result from message transmission, message processing, or message 835 generation. The "Result" field can be set to "NoAck", "NoSuccessAck", 836 "AckAll", and "SuccessAck" [3 Section 3.2] to ask the message 837 receiver to send or not to send ACK message. According to the 838 different importance and requirement of individual GRMP messages, 839 recommendations have been made in GRMP for their values of �Result� 840 in the message header. As an example, GRMP packet redirection 841 messages have been recommended to use "NoAck" value. 843 2) High level error control 844 If higher level of reliability is required for some protocol 845 messages, a built-in error control based on CRC-32 checksums can 846 furthermore be applied [3 Section 3.2]. A tag in GRMP message header 847 is used to optionally turn on or turn off the checksum mechanism. 848 Note that checksum error control can only improve the protocol 849 transmission reliability, therefore it can well fit for the case when 850 GRMP protocol is running over a comparatively unreliable medium such 851 as Ethernet or backplane where error control may not be supplied by 852 the medium itself. 854 3) Transaction identifier to control the order of messages 855 GRMP has defined different transaction identifiers for CE generated 856 messages and for FE generated messages [3 Section 3.2]. This makes it 857 possible to use protocol built-in method to order back protocol 858 messages if in occasional cases messages are reordered. 860 4) QoS control of message transmission 861 A scheduler is applied in GRMP slave model, which is not only for 862 protection against DoS attacks but also able to supply some sorts of 863 QoS controls such as bandwidth and priorities for GRMP message 864 transmission so as to improve the protocol reliability regarding the 865 timeliness of transmission. This is especially applicable when GRMP 866 is applied in a single hop scenario. 868 GRMP has no restriction on the use of any L4 layer protocols to 869 improve the protocol reliability. 871 Protocol requirement compliance level: ( ) 873 5.6.3 Netlink2 875 877 5.7 878 Protocol Requirement: Interconnect Independence 880 The ForCES protocol MUST support a variety of interconnect 881 technologies. (refer to section 5, requirement# 1) 883 5.7.1 FACT 884 Compliance = T 885 FACT uses interconnect independent addressing (FE Identifier, CE tag) 886 in its common header to provide interconnect independence. For non-IP 887 interconnects, such as ATM, an interconnect specific encapsulation 888 will have to be defined to carry the FACT messages. For IP 889 interconnects, FACT uses TCP as the transport protocol. Please see 890 section 3.1 in [2] for more details on this. 892 5.7.2 GRMP 894 GRMP packets can be transported via any suitable mediums, such as 895 TCP/IP, Ethernet, ATM fabrics, and bus backplanes. Because of the 896 design consideration for GRMP to be compatible with GSMP protocol, 897 packet encapsulations defined for GSMP protocols as in RFC 3293 can 898 also be applied to GRMP. 900 Protocol requirement compliance level: ( ) 902 5.7.3 Netlink2 904 906 5.8 907 Protocol Requirement: CE Redundancy or CE Failover 909 The ForCES protocol MUST support mechanisms for CE redundancy or CE 910 failover. This includes the ability for CEs and FEs to determine when 911 there is a loss of association between them, ability to restore 912 association and efficient state (re)synchronization mechanisms. This 913 also includes the ability to preset the actions an FE will take in 914 reaction to loss of association to its CE e.g., whether the FE will 915 continue to forward packets or whether it will halt operations. 916 (refer to section 5, requirement# 7) 918 5.8.1 FACT 920 Compliance = T 921 FACT exchanges CE and FE element states using the PE State 922 Maintenance messages. FACT also uses Heart-Beat messages (section 5.3 923 in [2]) to detect protocol element (CE or FE) failure or loss of 924 association between elements and to trigger a switch-over to a 925 functioning redundant element (CE or FE). Please see section 7.3 in 926 [2] for more details on the different mechanisms (Strong consistency, 927 weak consistency) used for CE failover. 929 5.8.2 GRMP 931 GRMP meets ForCES CE redundancy or CE failover requirement by means 932 of following mechanisms: 934 1) CE failover or leave policy [3 Section 4.6.4] 935 This policy is defined as a FE attribute and is setup via FE 936 attribute manipulate message [3 Section 4.1.5]. The policy is usually 937 set to a FE immediately after the FE is added to a ForCES NE and 938 before it actually begins to provide IP service. In this policy 939 attribute, selectable FE policies toward the CE failover are defined, 940 which include graceful restart, going inactive, etc. In addition, CE 941 re-association policies such as just waiting or trying to find out an 942 alternative CE among a CE list are simultaneously defined. 944 2) FE heartbeat policy [3 Section 4.6.6] 945 The ability to determine the loss of association between a CE and a 946 FE can be achieved in GRMP by use of this FE heartbeat policy, which 947 is also defined as a GRMP class FE attribute. In this policy 948 attribute, policies for the FE to receive heartbeats from a CE and to 949 send heartbeats to a CE are individually defined. After the heartbeat 950 policy attribute is set, the FE can then optionally send heartbeat 951 signals to a CE or receive and process heartbeat signals from a CE. 952 Heartbeat signals are sent by use of GRMP FE or CE event report 953 messages. 955 Protocol requirement compliance level: ( ) 957 5.8.3 Netlink2 959 961 5.9 962 Protocol Requirement: Packet Redirection/Mirroring 964 a) The ForCES protocol MUST define a way to redirect packets from the 965 FE to the CE and vice-versa. Packet redirection terminates any 966 further processing of the redirected packet at the FE. 967 b) The ForCES protocol MUST define a way to mirror packets from the 968 FE to the CE. Mirroring allows the packet duplicated by the FE at the 969 mirroring point to be sent to the CE while the original packet 970 continues to be processed by the FE. 971 Examples of packets that may be redirected or mirrored include 972 control packets (such as RIP, OSPF messages) addressed to the 973 interfaces or any other relevant packets (such as those with Router 974 Alert Option set). The ForCES protocol MUST also define a way for the 975 CE to configure the behavior of a) and b) (above), to specify which 976 packets are affected by each. 978 5.9.1 FACT 980 Compliance = T 981 FACT�s Traffic Maintenance Message class includes Control Packet 982 Redirect and Control Packet Forward messages to achieve packet 983 redirection/mirroring. These messages are sent over the separate data 984 channel. Please see section 5.4 in [2] for more details on this. 985 Also, the Event Register/Deregister messages (section 5.5 in [2]) can 986 be used to specify which packets should be redirected. 988 5.9.2 GRMP 990 GRMP supports packet redirection by packet redirection messages [3 991 Section 4.7]. A LFB within LFB topology in a FE should be used to 992 filter out packets that are to be redirected. Packets to be 993 redirected are first put in GRMP slave [3 Section 4.6.1] and then be 994 directed to a CE via GRMP packet redirection message. The attribute 995 of this filter LFB are set by CEs, therefore the CE has the ability 996 to control which packets can be redirected. For example, CE may want 997 to filter out packets that are considered from DoS attackers. 999 To redirect packets from CE to FE, CE just needs to encapsulate the 1000 packet to be redirected in the packet redirection message and send it 1001 to the FE. On the FE side, another LFB is used to resolve redirected 1002 packets from CE and to put the packets into datapaths in a FE LFB 1003 topology so that they can further be delivered by the FE. 1005 By use of the packet redirection message and by properly configuring 1006 LFBs in FE, a packet can be mirrored to CE instead of purely 1007 redirected to CE. That is, the packet is duplicated and one is 1008 redirected to CE and the other continues its way in the LFB topology. 1010 Protocol requirement compliance level: ( ) 1012 5.9.3 Netlink2 1014 1016 5.10 1017 Protocol Requirement: Topology Exchange 1019 The ForCES protocol MUST allow the FEs to provide their topology 1020 information (topology by which the FEs in the NE are connected) to 1021 the CE(s). (refer to section 5, requirement# 10) 1023 5.10.1 FACT 1025 Compliance = T 1026 FACT�s Capabilities and Control Message class includes Topology 1027 request and response messages to achieve topology information 1028 exchange between the CE and FEs. Please see sections 5.2.5, 5.2.6 in 1029 [2] for more details on this. 1031 5.10.2 GRMP 1032 In GRMP, FE topology query and response messages [3 Section 4.1.3] 1033 are used for CEs to query FE topology information in the NE. 1035 Protocol requirement compliance level: ( ) 1037 5.10.3 Netlink2 1039 1041 5.11 1042 Protocol Requirement: Dynamic Association 1044 The ForCES protocol MUST allow CEs and FEs to join and leave a NE 1045 dynamically. (refer to section 5, requirement# 12) 1047 5.11.1 FACT 1049 Compliance = T 1050 FACT�s Connection and Association message class includes Join 1051 request, Join response, Leave request and Leave response messages to 1052 enable dynamic joining and leaving of protocol elements (CEs, FEs) in 1053 the NE. Please see sections 5.1.1, 5.1.2, 5.1.3, 5.1.4 in [2] for 1054 more details on this. 1056 5.11.2 GRMP 1058 In GRMP, specific FE join request message [3 Section 4.1.1] and FE 1059 leave request message [3 Section 4.1.2] make FEs able to dynamically 1060 join or leave a ForCES NE. While CE failover or leave policy [3 1061 Section 4.6.4] defines the way for CEs to dynamically join or leave 1062 the NE. GRMP also defines FE failover and rejoin policy [3 Section 1063 4.6.5] for FEs to dynamically rejoin the NE. 1065 Protocol requirement compliance level: ( ) 1067 5.11.3 Netlink2 1069 1071 5.12 1072 Protocol Requirement: Command Bundling 1074 The ForCES protocol MUST be able to group an ordered set of commands 1075 to a FE. Each such group of commands SHOULD be sent to the FE in as 1076 few messages as possible. Furthermore, the protocol MUST support the 1077 ability to specify if a command group MUST have all-or-nothing 1078 semantics. 1080 5.12.1 FACT 1082 Compliance = T 1083 FACT supports command bundling by using multiple TLVs in its message 1084 payload. For example, each TLV used in the Configure Request message 1085 could represent a different command such as Add, Delete, etc. In 1086 addition, FACT also supports 2-phase commit operations. Please see 1087 sections 5.2.3, 4.2 in [2] for more details on this. 1089 5.12.2 GRMP 1091 In many cases of IP services, timely execution of ForCES protocol 1092 commands are essential for properly providing the services. Command 1093 bundling is a good approach to this. GRMP supports ForCES protocol 1094 command bundling in two ways: 1096 1) Using GRMP batch messages [3 Section 4.8] 1097 This kind of GRMP messages allow GRMP application layers to pack 1098 several different GRMP message bodies into one single GRMP message. 1099 These messages should meet following conditions: 1100 -Are sent from the same CE to the same FE. 1101 -Do not need explicit message responses. 1102 Such messages include that like event report messages, FE or LFB 1103 action manipulate messages, attribute manipulate messages, etc. 1105 2) Using list data format [3 Section 3.4.3] 1106 The list data format is used in several GRMP messages so that these 1107 messages can set more than one commands (that have same command type) 1108 in one message body. Examples of these GRMP messages are like: 1109 -FE attribute manipulate message [3 Section 4.1.6], which allow CE to 1110 manipulate several FE attributes at one blow. 1111 -FE attribute query and response messages [3 Section 4.1.7], which 1112 allow CE to query several FE attributes at one blow. 1113 -FE event report message [3 Section 4.1.8], which allow FE to report 1114 several FE events via one message. 1115 -LFB management messages [3 Section 4.2] 1116 -Datapath management messages [3 Section 4.3] 1118 Protocol requirement compliance level: ( ) 1120 5.12.3 Netlink2 1122 1124 5.13 1125 Protocol Requirement: Asynchronous Event Notification 1127 The ForCES protocol MUST be able to asynchronously notify the CE of 1128 events on the FE such as failures or change in available resources or 1129 capabilities. (refer to section 5, requirement# 6) 1131 5.13.1 FACT 1132 Compliance = T 1133 FACT�s Event Notification message class includes the Asynchronous FE 1134 Event notification message used to report asynchronous FE events to 1135 the CE. Please see section 5.5 in [2] for more details on this. 1137 5.13.2 GRMP 1139 In GRMP, a FE asynchronously informs CEs of a monitored failure, 1140 resources and capabilities changes, and other asynchronous events 1141 via GRMP FE event report message [3 Section 4.1.8]. These events 1142 include all that are defined within GRMP scope, by ForCES FE model, 1143 and possibly by vendors. GRMP use an object class identifier [3 1144 Section 3.4.5] to describe such inclusion. Current document of GRMP 1145 has defined following asynchronous events, which belong to GRMP 1146 event class: 1148 Object Class = 0 (GRMP class) 1149 FE Event Type 1150 -FE status event such as FE up, down, etc. 1151 -LFB status event such as LFB up, down, etc. 1152 -FE heartbeat 1153 -FE port change, such as port up, down, etc. 1154 -FE memory change 1155 -FE DoS attack alert 1157 Protocol requirement compliance level: ( ) 1159 5.13.3 Netlink2 1161 1163 5.14 1164 Protocol Requirement: Query Statistics 1166 The ForCES protocol MUST provide a means for the CE to be able to 1167 query statistics (monitor performance) from the FE. 1169 5.14.1 FACT 1171 Compliance = T 1172 FACT�s Capabilities and Control message class includes the Query 1173 request and response messages which can be used by the CE for 1174 querying the FE�s properties and statistics. Please see sections 1175 5.2.7, 5.2.8 in [2] for more details on this. 1177 5.14.2 GRMP 1179 GRMP defines statistics regarding FE performance as FE or LFB 1180 attributes. The FE attributes of statistics are the statistics that 1181 take whole FE as a statistic object, and the LFB attributes of 1182 statistics usually take the individual LFBs as statistic objects. In 1183 GRMP, the statistics attributes include that defined in FE model, by 1184 vendors, and by GRMP protocol itself. GRMP uses FE attribute query 1185 and response messages [3 Section 4.1.7] and LFB attribute query and 1186 response messages [3 Section 4.2.4] to query the statistics. 1188 GRMP can also support query of statistics defined by network 1189 management tools like SNMP by using MO get message [3 Section 4.5.1] 1190 and MO response message [3 Section 4.5.3]. 1192 Protocol requirement compliance level: ( ) 1194 5.14.3 Netlink2 1196 1198 5.15 1199 Protocol Requirement: Protection Against Denial of Service Attacks 1201 Systems utilizing the ForCES protocol can be attacked using denial of 1202 service attacks based on CPU overload or queue overflow. The ForCES 1203 protocol could be exploited by such attacks to cause the CE to become 1204 unable to control the FE or appropriately communicate with other 1205 routers and systems. The ForCES protocol MUST therefore provide 1206 mechanisms for controlling FE capabilities that can be used to 1207 protect against such attacks. FE capabilities that MUST be 1208 manipulated via ForCES include the ability to install classifiers and 1209 filters to detect and drop attack packets, as well as to be able to 1210 install rate limiters that limit the rate of packets which appear to 1211 be valid but may be part of an attack (e.g. bogus BGP packets). 1213 5.15.1 FACT 1215 Compliance = T 1216 FACT uses separate control and data channels to provide robustness in 1217 the protocol against Denial of Service (DoS) attacks. Please see 1218 section 3.3 in [2] for more details on this. Also, the Configure 1219 Request and Response messages in FACT could be used to install 1220 filters on FEs which can be used for rate-limiting the malicious 1221 traffic. 1223 5.15.2 GRMP 1225 GRMP supports protection against DoS attacks by means of following 1226 defined mechanisms: 1228 1) A model for GRMP slave module [3 Section 4.6.1] 1229 In this model, all GRMP messages sending to CE are put to two 1230 different channels: the data channel, which is only for packet 1231 redirection messages, and the control channel, which is for other 1232 GRMP messages that are usually generated by GRMP slave itself. Note 1233 that before redirected packets enter GRMP slave, a filter LFB defined 1234 by FE model is usually applied to decide what kind of packets are 1235 allowed to be redirected to CE. Messages on the two channels pass 1236 through a packet scheduler, then are put on the link connecting to 1237 CE. The scheduler is managed by CE by setting some scheduling 1238 policies (disciplines) to it. This policy setting can be done either 1239 at the scheduler startup time or on the fly during its runtime. In 1240 this way, the CE can control the traffic over the two message 1241 transmission channels dynamically according to the monitored traffic 1242 status. This also provides a means for CE to protect control channel 1243 transmission and to defend against DoS attacks. 1245 2) GRMP DoS protection policy [3 Section 4.6.2] 1246 This is defined in GRMP as a FE attribute. In this policy attribute, 1247 scheduling priorities, channel bandwidths, and congestion control 1248 policies for the individual data channel and control channel can be 1249 assigned. 1251 3) GRMP DoS attack alert policy [3 Section 4.6.3] 1252 This is also defined as a FE attribute. This policy specifies in 1253 which state a DoS attack is considered happened. DoS attack 1254 monitoring is performed by monitoring the status and statistics of 1255 the scheduler in the GRMP slave model. 1257 4) A DoS attack alert event report [3 Section 4.1.8] 1258 This is an event report message sent from FE to CE to report that a 1259 DoS attack is monitored according to the preset DoS attack alert 1260 policy. The event report can also include some information concerning 1261 the attackers. 1263 When CE has received the DoS attack alert event report, it may need 1264 to change DoS protection policy in some way to ensure the control 1265 channel transport. CE can also change attributes of the filter LFB 1266 put at the data channel entrance so that the packets that are doubted 1267 from DoS attackers can be filtered. 1269 Protocol requirement compliance level: ( ) 1271 5.15.3 Netlink2 1273 1275 5.16 1276 Protocol Requirement Summary Table 1278 This section is a summary of the compliance levels claimed for each 1279 protocol above and is included as a convenience. 1281 Protocol Requirement FACT GRMP Netlink2 1282 ==================================================================== 1283 1. Configuration of Modeled Elements T ? ? 1284 2. Support for Secure Communication T ? ? 1285 3. Scalability T ? ? 1286 4. Multihop T ? ? 1287 5. Message Priority T ? ? 1288 6. Reliability T ? ? 1289 7. Interconnect Independence T ? ? 1290 8. CE Redundancy or CE Failover T ? ? 1291 9. Packet Redirection/Mirroring T ? ? 1292 10. Topology Exchange T ? ? 1293 11. Dynamic Association T ? ? 1294 12. Command Bundling T ? ? 1295 13. Asynchronous Event Notification T ? ? 1296 14. Query Statistics T ? ? 1297 15. Protection Against Denial of Service Attacks T ? ? 1299 Security Considerations 1301 This document is a comparison between three protocols in order to 1302 help in the selection of the best approach to use as the ForCES 1303 protocol. Security considerations are addressed in each of the 1304 protocol proposals and MUST be included as part of the fitness 1305 evaluation for each proposal. 1307 References 1309 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1310 9, RFC 2026, October 1996. 1312 2 Audu, A. et al., "ForwArding and Control ElemenT protocol (FACT)", 1313 work in progress, September 2003, 1315 3 Wang, W. et al., "General Router Management Protocol (GRMP) 1316 Version 1�, September 2003, 1318 4 Salim, J. H. et al., "Netlink2 as ForCES Protocol", work in 1319 progress, June 2003, 1321 5 Khosravi, H. et al., "Requirements for Separation of IP Control 1322 and Forwarding", work in progress, July 2003, 1323 1325 6 Yang, L. et al., "Forwarding and Control Element Separation 1326 (ForCES) Framework", work in progress, August 2003, 1327 1329 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1330 Levels", BCP 14, RFC 2119, March 1997 1332 8 Barnes, M., "Middlebox Communications (MIDCOM) Protocol 1333 Evaluation", work in progress, Nov 2002, 1334 1336 9 Yang, L. et al., "ForCES Forwarding Element Functional Model", 1337 work in progress, October 2003, 1339 10 F. Baker, "Requirements for IP Version 4 Routers", RFC1812, June 1340 1995. 1342 11 S. Floyd, "Congestion Control Principles", RFC2914, September 1343 2000. 1345 Acknowledgments 1347 Author's Addresses 1349 Alex Audu 1350 Alcatel R&I 1351 1000 Coit Road 1352 Plano, TX 75075 1353 Phone: 1-972-477-7809 1354 Email: alex.audu@alcatel.com 1356 Hormuzd Khosravi 1357 Intel 1358 2111 NE 25th Avenue 1359 Hillsboro, OR 97124 1360 Phone: 1-503-264-0334 1361 Email: hormuzd.m.khosravi@intel.com 1363 David Putzolu 1364 Intel 1365 Mailstop JF3-206-H10 1366 2111 NE 25th Avenue 1367 Phone: 503-264-4510 1368 Email: david.putzolu@intel.com 1369 Weiming Wang 1370 Department of Information and Electronic Engineering 1371 Hangzhou University of Commerce 1372 149 Jiaogong Road 1373 Hangzhou, 310035, P.R.China 1374 Phone: +86-571-88057712 1375 Email: wangwm@hzcnc.com