idnits 2.17.1 draft-ietf-forces-applicability-05.txt: -(559): 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): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 628. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Missing revision: the document name given in the document, 'draft-ietf-forces-applicability-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-forces-applicability-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-forces-applicability-', but the file name used is 'draft-ietf-forces-applicability-05' == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 423: '... A NE MUST support the appearance...' RFC 2119 keyword, line 451: '... MAY have direct access to indivi...' RFC 2119 keyword, line 484: '... change) the state of FE SHOULD NOT be...' RFC 2119 keyword, line 487: '... 2. It MUST NOT be possible for ma...' RFC 2119 keyword, line 498: '... RFC 1812 [2] also dictates that "Routers MUST be manageable...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 115 has weird spacing: '... the exchan...' == Line 120 has weird spacing: '... data forwa...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 2006) is 6495 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? '2' on line 498 looks like a reference -- Missing reference section? '3' on line 404 looks like a reference -- Missing reference section? '4' on line 131 looks like a reference -- Missing reference section? '8' on line 369 looks like a reference -- Missing reference section? '7' on line 369 looks like a reference -- Missing reference section? '9' on line 376 looks like a reference -- Missing reference section? '6' on line 505 looks like a reference -- Missing reference section? 'RFC 3654' on line 481 looks like a reference -- Missing reference section? 'TBD' on line 457 looks like a reference -- Missing reference section? 'RFC 3746' on line 494 looks like a reference -- Missing reference section? 'RFCXXXX' on line 536 looks like a reference Summary: 10 errors (**), 1 flaw (~~), 8 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Alan Crouch 3 Internet Draft Hormuzd Khosravi 4 Document: draft-ietf-forces-applicability- Intel Corp. 5 05.txt 6 Expires: January 2007 Mark Handley 7 Working Group: ForCES ICIR 8 Avri Doria 9 ETRI 11 July 2006 13 ForCES Applicability Statement 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as ``work in 31 progress.'' 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 48 ForCES Applicability Statement July 2006 50 this document are to be interpreted as described in [2]. 52 Abstract 54 The ForCES protocol defines a standard framework and mechanism for 55 the interconnection between Control Elements and Forwarding Elements 56 in IP routers and similar devices. In this document we describe the 57 applicability of the ForCES model and protocol. We provide example 58 deployment scenarios and functionality, as well as document 59 applications that would be inappropriate for ForCES. 61 Table of Contents 63 1. Purpose........................................................3 64 2. Overview.......................................................3 65 3. Terminology....................................................3 66 4. Applicability to IP Networks...................................3 67 4.1. Applicable Services.........................................4 68 4.1.1. Discovery, Capability Information Exchange................4 69 4.1.2. Topology Information Exchange.............................5 70 4.1.3. Configuration.............................................5 71 4.1.4. Routing Exchange..........................................5 72 4.1.5. QoS Exchange..............................................5 73 4.1.6. Security Exchange.........................................5 74 4.1.7. Filtering Exchange and Firewalls..........................6 75 4.1.8. Encapsulation, Tunneling Exchange.........................6 76 4.1.9. NAT and Application-level Gateways........................6 77 4.1.10. Measurement and Accounting................................6 78 4.1.11. Diagnostics...............................................6 79 4.1.12. CE Redundancy or CE Failover..............................6 80 4.2. CE-FE Link Capability.......................................7 81 4.3. CE/FE Locality..............................................7 82 5. Limitations and Out-of-Scope Items.............................7 83 5.1. Out of Scope Services.......................................8 84 5.1.1. Label Switching...........................................8 85 5.1.2. Separation of Control and Forwarding in Multimedia Gateways8 86 5.2. Localities..................................................8 87 6. Security Considerations........................................9 88 7. ForCES Manageability...........................................9 89 7.1. NE as an atomic element.....................................9 90 7.2. NE as composed of manageable elements.......................9 91 7.3. ForCES Protocol MIB........................................10 92 7.3.1. MIB Management of an FE..................................10 93 7.4. CE to CE communication.....................................11 94 7.5. The FEM and CEM............................................11 95 8. References....................................................12 96 8.1. Normative References.......................................12 98 ForCES Applicability Statement July 2006 100 8.2. Informative References.....................................12 101 9. Acknowledgments...............................................12 102 10. Authors' Addresses..........................................12 104 1. Purpose 106 The purpose of the ForCES Applicability Statement is to capture the 107 intent of the ForCES protocol designers as to how the protocol 108 should be used. The Applicability Statement will evolve alongside 109 the protocol, and will go to RFC as informational around the same 110 time the as the protocol goes to RFC. 112 2. Overview 114 The ForCES protocol defines a standard framework and mechanism for 115 the exchange of information between the logically separate 116 functionality of the control and data forwarding planes of IP 117 routers and similar devices. It focuses on the communication 118 necessary for separation of control plane functionality such as 119 routing protocols, signaling protocols, and admission control from 120 data forwarding plane per-packet activities such as packet 121 forwarding, queuing, and header editing. 123 This document defines the applicability of the ForCES mechanisms. It 124 describes types of configurations and settings where ForCES is most 125 appropriately applied. This document also describes scenarios and 126 configurations where ForCES would not be appropriate for use. 128 3. Terminology 130 A set of terminology associated with ForCES is defined in [3, 4]. 131 That terminology is reused here and the reader is directed to [3, 4] 132 for the following definitions: 134 o CE: Control Element. 136 o FE: Forwarding Element. 138 o ForCES: ForCES protocol. 140 4. Applicability to IP Networks 142 The purpose of this section is to list the areas of ForCES 143 applicability in IP network devices. Relatively low performance 145 ForCES Applicability Statement July 2006 147 devices may be implemented on a simple processor which performs both 148 control and packet forwarding functionality. ForCES is not 149 applicable for such devices. 151 Higher performance devices typically distribute work amongst 152 interface processors, and these devices (FEs) therefore need to 153 communicate with the control element(s) to perform their job. 154 ForCES provides a standard way to do this communication. 156 The remainder of this section lists the applicable services which 157 ForCES may support, applicable FE functionality, applicable CE-FE 158 link scenarios, and applicable topologies in which ForCES may be 159 deployed. 161 4.1. Applicable Services 163 In this section we describe the applicability of ForCES for the 164 following control-forwarding plane services: 166 o Discovery, Capability Information Exchange 168 o Topology Information Exchange 170 o Configuration 172 o Routing Exchange 174 o QoS Exchange 176 o Security Exchange 178 o Filtering Exchange 180 o Encapsulation/Tunneling Exchange 182 o NAT and Application-level Gateways 184 o Measurement and Accounting 186 o Diagnostics 188 o CE Redundancy or CE Failover 190 4.1.1. Discovery, Capability Information Exchange 192 ForCES Applicability Statement July 2006 194 Discovery is the process by which CEs and FEs learn of each other's 195 existence. ForCES assumes that CEs and FEs already know sufficient 196 information to begin communication in a secure manner. 197 The ForCES protocol is only applicable after CEs and FEs have found 198 each other. ForCES makes no assumption about whether discovery was 199 performed using a dynamic protocol or merely static configuration. 201 During the discovery phase, CEs and FEs may exchange capability 202 information with each other. For example, the FEs may express the 203 number of interface ports they provide, as well as the static and 204 configurable attributes of each port. 206 In addition to initial configuration, the CEs and FEs may also 207 exchange dynamic configuration changes using ForCES. For example, 208 FE's asynchronously inform the CE of an increase/decrease in 209 available resources or capabilities on the FE. 211 4.1.2. Topology Information Exchange 213 In this context, topology information relates to how the FEs are 214 interconnected with each other with respect to packet forwarding. 215 Whilst topology discovery is outside the scope of the ForCES 216 protocol, a standard topology discovery protocol may be selected and 217 used to "learn" the topology, and then the ForCES protocol may be 218 used to transmit the resulting information to the CE. 220 4.1.3. Configuration 222 ForCES is used to perform FE configuration. For example, CEs set 223 configurable FE attributes such as IP addresses, etc. for their 224 interfaces. 226 4.1.4. Routing Exchange 228 ForCES may be used to deliver packet forwarding information 229 resulting from CE routing calculations. For example, CEs may send 230 forwarding table updates to the FEs, so that they can make 231 forwarding decisions. FEs may inform the CE in the event of a 232 forwarding table miss. 234 4.1.5. QoS Exchange 236 ForCES may be used to exchange QoS capabilities between CEs and FEs. 237 For example, an FE may express QoS capabilities to the CE. Such 238 capabilities might include metering, policing, shaping, and queuing 239 functions. The CE may use ForCES to configure these capabilities. 241 4.1.6. Security Exchange 243 ForCES Applicability Statement July 2006 245 ForCES may be used to exchange Security information between CEs and 246 FEs. For example, the FE may use ForCES to express the types of 247 encryption that it is capable of using in an IPsec tunnel. The CE 248 may use ForCES to configure such a tunnel. 250 4.1.7. Filtering Exchange and Firewalls 252 ForCES may be used to exchange filtering information. For example, 253 Fes may use ForCES to express the filtering functions such as 254 classification and action that they can perform, and the CE may 255 configure these capabilities. 257 4.1.8. Encapsulation, Tunneling Exchange 259 ForCES may be used to exchange encapsulation capabilities of an FE, 260 such as tunneling, and the configuration of such capabilities. 262 4.1.9. NAT and Application-level Gateways 264 ForCES may be used to exchange configuration information for Network 265 Address Translators. Whilst ForCES is not specifically designed for 266 the configuration of application-level gateway functionality, this 267 may be in scope for some types of application-level gateways. 269 4.1.10. Measurement and Accounting 271 ForCES may be used to exchange configuration information regarding 272 traffic measurement and accounting functionality. In this area, 273 ForCES may overlap somewhat with functionality provided by 274 alternative network management mechanisms such as SNMP. In some 275 cases ForCES may be used to convey information to the CE to be 276 reported externally using SNMP. However, in other cases it may make 277 more sense for the FE to directly speak SNMP. 279 4.1.11. Diagnostics 281 ForCES may be used for CE's and FE's to exchange diagnostic 282 information. For example, an FE can send self-test results to the 283 CE. 285 4.1.12. CE Redundancy or CE Failover 287 ForCES is a master-slave protocol where FE's are slaves and CE's are 288 masters. Basic mechanisms for CE redundancy/failover are provided 289 in ForCES protocol. Broad concepts such as implementing CE 290 Redundancy, CE Failover, and CE-CE communication, while not 291 precluded by the ForCES architecture, are considered outside the 293 ForCES Applicability Statement July 2006 295 scope of ForCES protocol. ForCES protocol is designed to handle CE- 296 FE communication, and is not intended for CE-CE communication. 298 4.2. CE-FE Link Capability 300 When using ForCES, the bandwidth of the CE-FE link is a 301 consideration, and cannot be ignored. For example, sending a full 302 routing table of 110K routes is reasonable over a 100Mbit Ethernet 303 interconnect, but could be non-trivial over a lower-bandwidth link. 304 ForCES should be sufficiently future-proof to be applicable in 305 scenarios where routing tables grow to several orders of magnitude 306 greater than their current size (approximately 100K routes). 307 However, we also note that not all IP routers need full routing 308 tables. 310 4.3. CE/FE Locality 312 We do not intend ForCES to be applicable in configurations where the 313 CE and FE are located arbitrarily in the network. In particular, 314 ForCES is intended for environments where one of the following 315 applies: 317 o The control interconnect is some form of local bus, switch, or 318 LAN, where reliability is high, closely controlled, and not 319 susceptible to external disruption that does not also affect the CEs 320 and/or FEs. 322 o The control interconnect shares fate with the FE's forwarding 323 function. Typically this is because the control connection is also 324 the FE's primary packet forwarding connection, and so if that link 325 goes down, the FE cannot forward packets anyway. 327 The key guideline is that the reliability of the device should not 328 be significantly reduced by the separation of control and forwarding 329 functionality. 331 ForCES is applicable in localities consisting of control and 332 forwarding elements which are either components in the same physical 333 box, or are separated at most by one local network hop (historically 334 referred to as "Very Close" localities). 336 Example: a network element with a single control blade, and one or 337 more forwarding blades, all present in the same chassis and sharing 338 an interconnect such as Ethernet or PCI. In this locality, the 339 majority of the data traffic being forwarded typically does not 340 traverse the same links as the ForCES control traffic. 342 5. Limitations and Out-of-Scope Items 344 ForCES Applicability Statement July 2006 346 ForCES was designed to enable logical separation of control and 347 forwarding planes in IP network devices. However, ForCES is not 348 intended to be applicable to all services or to all possible CE/FE 349 localities. 351 The purpose of this section is to list limitations and out-of-scope 352 items for ForCES. 354 5.1. Out of Scope Services 356 The following control-forwarding plane services are explicitly not 357 addressed by ForCES: 359 o Label Switching 361 o Multimedia Gateway Control (MEGACO). 363 5.1.1. Label Switching 365 Label Switching is the purview of the GSMP Working Group in the Sub- 366 IP Area of the IETF. GSMP is a general purpose protocol to control 367 a label switch. GSMP defines mechanisms to separate the label 368 switch data plane from the control plane label protocols such as LDP 369 [8]. For more information on GSMP, see [7]. 371 5.1.2. Separation of Control and Forwarding in Multimedia Gateways 373 MEGACO defines a protocol used between elements of a physically 374 decomposed multimedia gateway. Separation of call control channels 375 from bearer channels is the purview of MEGACO. For more information 376 on MEGACO, see [9]. 378 5.2. Localities 380 ForCES protocol was intended to work within the localities described 381 in the last section. Outside these boundaries, care must be taken 382 or the protocol may not work right. Examples of localities where 383 ForCES was not originally intended to be used: 385 o Localities where there are multiple hops between CE and FE. 387 o Localities where hops between the CE and FE are dynamically 388 routing using IP routing protocols. 390 o Localities where the loss of the CE-FE link is of non- 391 negligible probability. 393 ForCES Applicability Statement July 2006 395 o Localities where two or more FEs controlled by the same CE 396 cannot communicate, either directly, or indirectly via other Fes 397 controlled by the same CE. 399 6. Security Considerations 401 The security of ForCES protocol will be addressed in the Protocol 402 Specification [6]. For security requirements, see architecture 403 requirement #5 and protocol requirement #2 in the Requirements Draft 404 [3]. The ForCES protocol assumes that the CE and FE are in the same 405 administration, and have shared secrets as a means of 406 administration. Whilst it might be technically feasible to have the 407 CE and FE administered independently, we strongly discourage such 408 uses, because they would require a significantly different trust 409 model from that ForCES assumes. 411 7. ForCES Manageability 412 From the management perspective, an NE can be viewed in at least two 413 ways. From one perspective, it is a single network element, 414 specifically a router that needs to be managed in essentially the 415 same way any router is managed. From another perspective element 416 management can view the individual entities and interfaces that make 417 up a ForCES NE. 419 7.1. NE as an atomic element 421 From the ForCES requirements RFC [RFC 3654], Section 4, point 4: 423 A NE MUST support the appearance of a single functional device. 425 As a single functional device a ForCES NE runs protocols and each of 426 the protocols has it own existing manageability aspects that are 427 document elsewhere. As a router it would also have a configuration 428 interface. When viewed in this manner, the NE is controlled as 429 single routing entity and no new management beyond what is already 430 available for routers and routing protocols would be required for a 431 ForCES NE. 433 7.2. NE as composed of manageable elements 435 When viewed as a decomposed set of elements from the management 436 perspective, the ForCES NE is divided into a set of one of more 437 Control Elements, Forwarding Elements and the interfaces between 438 them. The interface functionality between the CE and the FE is 439 provided by the ForCES protocol. As with all IETF protocols a MIB 440 is provided for the purposes of managing the protocol. 442 ForCES Applicability Statement July 2006 444 Additionally the architecture makes provision for configuration 445 control of the individual CEs and FEs. This is handled by elements 446 named FE manager (FEM) and the CE manager (CEM). Specifically from 447 the ForCES requirements 448 RFC [RFC 3654], Section 4, point 4: 450 However, external entities (e.g., FE managers and CE managers) 451 MAY have direct access to individual ForCES protocol elements 452 for providing information to transition them from the 453 pre-association to post-association phase. 455 7.3. ForCES Protocol MIB 457 From the ForCES MIB RFC [TBD], section X 459 The ForCES MIB is a primarily read-only MIB that captures 460 information related to the ForCES protocol. This includes 461 state information about the associations between CE(s) and 462 FE(s) in the NE. 464 The ForCES MIB does not include information that is specified in 465 other MIBs, such as packet counters for interfaces, etc. 467 More specifically, the information in the ForCES MIB relative to 468 associations includes: 470 - identifiers of the elements in the association 471 - state of the association 472 - configuration parameters of the association 473 - statistics of the association 475 7.3.1. MIB Management of an FE 477 While it is possible to manage a FE from a element manager, several 478 requirements relating to this have been included in the ForCES 479 Requirements. 481 From the ForCES Requirements [RFC 3654], Section 4, point 14: 483 1. The ability for a management tool (e.g., SNMP) to be used 484 to read (but not change) the state of FE SHOULD NOT be 485 precluded. 487 2. It MUST NOT be possible for management tools 488 (e.g., SNMP, etc) to change the state of a FE in a manner 489 that affects overall NE behavior without the CE being 490 notified. 492 ForCES Applicability Statement July 2006 494 The ForCES Requirements [RFC 3746], Section 5.7, goes further in 495 discussing the manner in which FEs should handle management requests 496 that are specifically directed to the FE: 498 RFC 1812 [2] also dictates that "Routers MUST be manageable 499 by SNMP". In general, for the post-association phase, most 500 external management tasks (including SNMP) should be done 501 through interaction with the CE in order to support the 502 appearance of a single functional device. Therefore, it is 503 recommended that an SNMP agent be implemented by CEs and 504 that the SNMP messages received by FEs be redirected to their 505 CEs. AgentX framework defined in RFC 2741 ([6]) may be applied 506 here such that CEs act in the role of master agent to process 507 SNMP protocol messages while FEs act in the role of subagent 508 to provide access to the MIB objects residing on FEs. AgentX 509 protocol messages between the master agent (CE) and the 510 subagent (FE) are encapsulated and transported via ForCES, 511 just like data packets from any other application layer 512 protocols. 514 7.4. CE to CE communication 516 The ForCES architecture allows for multiple CEs within a single NE. 517 The operating presumption is that the CEs will coordinate their 518 efforts in those cases where multiple CEs are available. Currently 519 the only specified method for CE to interact with FE is for there to 520 be one master CE, though there can be many backup CEs. Other 521 solutions that have been discussed include having multiple 522 specialist CEs per FE, however, the protocol does not support this 523 option. 525 The creation of a protocol or method for CE coordination is out of 526 scope for the initial ForCES specification effort. Any NE that uses 527 multiple CEs for reliability must provide its own coordination 528 mechanisms. 530 7.5. The FEM and CEM 532 Though out of scope for the initial ForCES specification effort, the 533 ForCES architecture include two entities, the CE Manager (CEM) and 534 the FE Manager (FEM) 536 From the ForCES Protocols Specification [RFCXXXX] 538 CE Manager (CEM) - A logical entity responsible for generic CE 539 management tasks. It is particularly used during the 541 ForCES Applicability Statement July 2006 543 pre-association phase to determine with which FE(s) a CE 544 should communicate. 546 FE Manager (FEM) - A logical entity responsible for generic 547 FE management tasks. It is used during pre-association phase 548 to determine with which CE(s) an FE should communicate. 550 8. References 551 8.1. Normative References 553 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 554 2026, October 1996. 556 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement 557 Levels", RFC2119 (BCP), IETF, March 1997. 559 3. Khosravi, et al., ��Requirements for Separation of IP Control and 560 Forwarding�, RFC 3654, November 2003. 562 4. L. Yang, et al., � ForCES Architectural Framework�, RFC 3746, 563 April 2004. 565 5. Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,and S. 566 Blake, "ForCES Forwarding Element Model", Feb. 2005. 568 6. A. Doria, et al., �ForCES Protocol Specification�, draft-ietf- 569 forces-protocol-06.txt, December 2005. 571 8.2. Informative References 573 7. A. Doria, F. Hellstrand, K. Sundell, T. Worster, �General Switch 574 Management Protocol (GSMP) V3�, RFC 3292, June 2002. 576 8. Andersson et al., "LDP Specification" RFC 3036, January 2001 578 9. F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November 579 2000 581 9. Acknowledgments 582 The authors wish to thank Jamal Hadi Salim, Vip Sharma, and many 583 others for their invaluable contributions. 585 10. Authors' Addresses 587 ForCES Applicability Statement July 2006 589 Alan Crouch 590 Intel 591 2111 NE 25th Avenue 592 Hillsboro, OR 97124 USA 593 Phone: +1 503 264 2196 594 Email: alan.crouch@intel.com 596 Hormuzd Khosravi 597 Intel 598 2111 NE 25th Avenue 599 Hillsboro, OR 97124 600 Phone: 1-503-264-0334 601 Email: hormuzd.m.khosravi@intel.com 603 Mark Handley 604 ICIR 605 1947 Center Street, Suite 600 606 Berkeley, CA 94708, USA 607 Email: mjh@icsi.berkeley.edu 609 Avri Doria 610 ETRI 611 Lulea University of Technology 612 Lulea, Sweden 613 Phone: +46 73 277 1788 614 Email: avri@acm.org 616 Copyright Statement 618 Copyright (C) The Internet Society (2006). This document is subject 619 to the rights, licenses and restrictions contained in BCP 78, and 620 except as set forth therein, the authors retain all their rights. 622 This document and the information contained herein are provided on 623 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 624 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 625 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 626 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 627 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 628 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.