idnits 2.17.1 draft-ietf-bmwg-conterm-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 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.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 54 has weird spacing: '...network of ro...' == Line 164 has weird spacing: '...network of ro...' == Line 1204 has weird spacing: '...ping to respo...' == Line 1252 has weird spacing: '...rwarded traff...' -- 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 (July 2002) is 7953 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) == Unused Reference: '9' is defined on line 1325, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1356, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1383, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2385 (ref. '8') (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2547 (ref. '10') (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. '11' == Outdated reference: A later version (-13) exists of draft-ietf-idr-restart-02 == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-05 == Outdated reference: A later version (-10) exists of draft-ietf-forces-requirements-02 ** Downref: Normative reference to an Informational draft: draft-ietf-forces-requirements (ref. '15') -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' Summary: 8 errors (**), 0 flaws (~~), 16 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Working Group H.Berkowitz, Gett Communications 3 Internet Draft S.Hares, Nexthop 4 Document: draft-ietf-bmwg-conterm-03.txt A.Retana, Cisco 5 Expires January 2003 P.Krishnaswamy, Consultant 6 M.Lepp, Juniper Networks 7 E.Davies, Nortel Networks 8 July 2002 10 Terminology for Benchmarking BGP Device Convergence 11 in the Control Plane 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 A revised version of this draft document will be submitted to the RFC 31 editor as a Informational document for the Internet Community. 32 Discussion and suggestions for improvement are requested. 33 This document will expire before January 2003 . Distribution of this 34 draft is unlimited. 36 Copyright Notice 38 Copyright (C) The Internet Society (2002). All Rights Reserved. 40 Abstract 42 This draft establishes terminology to standardize the description of 43 benchmarking methodology for measuring eBGP convergence in the 44 control plane of a single BGP device. Future documents will address 45 iBGP convergence, the initiation of forwarding based on converged 46 control plane information and multiple interacting BGP devices. This 47 terminology is applicable to both IPv4 and IPv6. Illustrative 48 examples of each version are included where relevant. 50 Table of Contents 51 1. Introduction....................................................3 52 1.1 Overview and Roadmap.......................................3 53 1.2 Definition Format..........................................3 54 2. Constituent elements of a router or network of routers.........4 55 2.1 BGP Instance or Device.....................................4 56 2.2 BGP Peer...................................................5 57 2.3 Default Route, Default Free Table, and Full Table..........5 58 2.4 Classes of BGP-Speaking Routers............................8 59 3. Routing Data Structures.........................................9 60 3.1 Routing Information Base (RIB).............................9 61 3.2 Policy....................................................11 62 3.3 Policy Information Base...................................11 63 3.4 Forwarding Information Base (FIB).........................12 64 4. Components and characteristics of Routing information..........13 65 4.1 (Network) Prefix..........................................13 66 4.2 Network Prefix Length.....................................13 67 4.3 Route.....................................................14 68 4.4 BGP Route.................................................14 69 4.5 BGP Route Attributes and BGP Timers.......................15 70 4.6 Route Instance............................................16 71 4.7 Active Route..............................................17 72 4.8 Unique Route..............................................17 73 4.9 Non-Unique Route..........................................17 74 4.10 BGP UPDATE message.....................................17 75 4.11 Characterization of sets of update messages............18 76 4.12 Route Flap.............................................20 77 5. Route Changes and Convergence..................................21 78 5.1 Route Change Events.......................................21 79 5.2 Device Convergence in the Control Plane...................22 80 6. BGP Operation Events...........................................23 81 6.1 Hard reset................................................24 82 6.2 Soft reset................................................24 83 7. Factors that impact the performance of the convergence process.24 84 7.1 General factors affecting device convergence..............24 85 7.2 Implementation-specific and other factors affecting BGP 86 convergence............................................26 87 8. Security Considerations........................................27 88 9. References.....................................................27 89 10. Acknowledgments...............................................28 90 11. Author's Addresses............................................29 92 1. Introduction 94 This document defines terminology for use in characterizing the 95 convergence performance of BGP processes in routers or other devices 96 that instantiate BGP functionality (see RFC1771 [1]). It is the first 97 part of a two document series, of which the subsequent document will 98 contain the associated tests and methodology. This terminology is 99 applicable to both IPv4 and IPv6. Illustrative examples of each 100 version are included where relevant. 102 The following observations underlie the approach adopted in this, and 103 the companion document: 104 - The principal objective is to derive methodologies to standardize 105 conducting and reporting convergence-related measurements for BGP. 106 - It is necessary to remove ambiguity from many frequently used 107 terms that arise in the context of such measurements. 108 - As convergence characterization is a complex process, it is 109 desirable to restrict the initial focus in this set of documents 110 to specifying how to take basic control plane measurements as a 111 first step to characterizing BGP convergence. 113 For path vector protocols, such as BGP, the primary initial focus 114 will therefore be on network and system control-plane activity 115 consisting of the arrival, processing, and propagation of routing 116 information 117 Subsequent drafts will explore the more intricate aspects of 118 convergence measurement, such as the impacts of the presence of 119 policy processing, simultaneous traffic on the control and data paths 120 within the DUT, and other realistic performance modifiers. 121 Convergence of Interior Gateway Protocols will also be considered in 122 separate drafts. 124 1.1 Overview and Roadmap 126 Characterizations of the BGP convergence performance of a device must 127 take into account all distinct stages and aspects of BGP 128 functionality. This requires that the relevant terms and metrics be 129 as specifically defined as possible. Such definition is the goal of 130 this document. 132 The necessary definitions are classified into two separate 133 categories: 134 - Descriptions of the constituent elements of a network or a router 135 that is undergoing convergence 136 - Descriptions of factors that impact convergence processes 138 1.2 Definition Format 140 The definition format is equivalent to that defined in [3], and is 141 repeated here for convenience: 143 X.x Term to be defined. (e.g., Latency) 145 Definition: 147 One or more sentences forming the body of the definition. 149 Discussion: 150 A brief discussion of the term, its application and any 151 restrictions that there might be on measurement 152 procedures. 154 Measurement units: 155 The units used to report measurements of this term, if 156 applicable. 157 Issues: 158 List of issues or conditions that could affect this term. 160 See Also: 161 List of related terms that are relevant to the definition 162 or discussion of this term. 164 2. Constituent elements of a router or network of routers. 166 Many terms included in this list of definitions were originally 167 described in previous standards or papers. They are included here 168 because of their pertinence to this discussion. Where relevant, 169 reference is made to these sources. An effort has been made to keep 170 this list complete with regard to the necessary concepts without over 171 definition. 173 2.1 BGP Instance or Device 175 Definition: 176 A BGP instance is a process with a single Loc-RIB that 177 runs on a BGP device. 179 Discussion: 180 We have chosen to use "device" as the general case, to 181 deal with the understood [e.g. [9]] and yet-to-be-invented 182 cases where the control processing may be separate from 183 forwarding [12]. A BGP device may be a traditional 184 router, a route server, a BGP-aware traffic steering 185 device, a device using BGP to exchange topology 186 information with a GMPLS environment, etc. A device such 187 as a route server, for example, never forwards traffic, so 188 forwarding-based measurements would be meaningless for it. 190 Measurement units: N/A 192 Issues: 194 See Also: 196 2.2 BGP Peer 198 Definition: 199 A BGP peer is another BGP instance to which the Device 200 Under Test (DUT) has established a TCP connection over 201 which a BGP session is active. In the test scenarios in 202 the methodology discussion that will follow this draft, 203 peers send BGP advertisements to the DUT and receive DUT- 204 originated advertisements. 206 Discussion: 207 This is a protocol-specific definition, not to be confused 208 with another frequent usage, which refers to the 209 business/economic definition for the exchange of routes 210 without financial compensation. 212 It is worth noting that a BGP peer, by this definition is 213 associated with a BGP peering session, and there may be 214 more than one such active session on a router or on a 215 tester. The peering sessions referred to here may exist 216 between various classes of BGP routers (see section 2.3). 218 Measurement units: number of BGP peers 220 Issues: 222 See Also: 224 2.3 Default Route, Default Free Table, and Full Table 226 An individual router's routing table may not necessarily contain a 227 default route. Not having a default route, however, is not 228 synonymous with having a full default-free table(DFT). 229 It should be noted that the references to number of routes in this 230 section are to routes installed in the loc-RIB, not route instances, 231 and that the total number of route instances may be 4 to 10 times the 232 number of routes. 234 The actual path setup and forwarding of MPLS speaking routers are 235 outside the scope of this document. A device that computes BGP 236 routes, which a sub-IP device can use to set up paths, has its BGP 237 aspects within scope. 239 2.3.1 Default Route 241 Definition: 242 A Default Route is a route entry that can match any 243 prefix. If a router does not have a route for a particular 244 packet's destination address, it forwards this packet to 245 the next hop in the default route entry, provided its 246 Forwarding Table (Forwarding Information Base (FIB) 247 contains one. The notation for a default route for IPv4 is 248 0.0.0.0/0 and for IPv6 it is 0:0:0:0:0:0:0:0 or ::/0. 250 Discussion: 252 Measurement units: N.A. 254 Issues: 256 See Also: default free routing table, route, route instance 258 2.3.2 Default Free Routing Table 260 Definition: 261 A default free routing table has no default routes and is 262 typically seen in routers in the core or top tier of 263 routers in the network. 265 Discussion: 266 The term originates from the concept that routers at the 267 core or top tier of the Internet will not be configured 268 with a default route (Notation in IPv4 0.0.0.0/0 and in 269 IPv6 0:0:0:0:0:0:0:0 or ::/0). Thus they will forward 270 every prefix to a specific next hop based on the longest 271 match on the IP addresses. 273 Default free routing table size is commonly used as an 274 indicator of the magnitude of reachable Internet address 275 space. However, default free routing tables may also 276 include routes internal to the router's AS. 278 Measurements: The number of routes 280 See Also: Full Default Free, Default Route 282 2.3.3 Full Default Free Table 284 Definition: 285 A full default free table is a set of BGP routes generally 286 accepted to be the complete set of BGP routes collectively 287 announced by the complete set of autonomous systems making 288 up the public Internet. Due to the dynamic nature of the 289 Internet, the exact size and composition of this table may 290 vary slightly depending where and when it is observed. 291 Discussion: 292 Several investigators ([17],[18],[19]) measure this on a 293 daily and/or weekly basis; June 2001 measurements put the 294 table at approximately 105,000 routes, growing 295 exponentially. 297 It is generally accepted that a full table, in this usage, 298 does not contain the infrastructure routes or individual 299 sub-aggregates of routes that are otherwise aggregated by 300 the provider before announcement to other autonomous 301 systems. 303 Measurement Units: number of routes 305 Issues: 307 See Also: Routes, Route Instances, Default Route 309 2.3.4 Full Provider Internal Table 311 Definition: 312 A full provider internal table is a superset of the full 313 routing table that contains infrastructure and non- 314 aggregated routes. 316 Discussion: 317 Experience has shown that this table can contain 1.3 to 318 1.5 times the number of routes in the externally visible 319 full table. Tables of this size, therefore, are a real- 320 world requirement for key internal provider routers. 322 Measurement Units: number of routes 324 Issues: 326 See Also: Routes, Route Instances, Default Route 328 2.4 Classes of BGP-Speaking Routers 330 A given router may perform more than one of the following functions, 331 based on its logical location in the network. 333 2.4.1 Provider Edge Router 335 Definition: 336 A provider edge router is a router at the edge of a 337 provider's network, configured to speak BGP, which peers 338 with a BGP speaking router operated by the end-user. The 339 traffic that transits this router may be destined to, or 340 originate from non-contiguous autonomous systems. 342 Discussion: 343 Such a router will always speak eBGP and may speak iBGP. 345 Measurement units: 347 Issues: 349 See Also: 351 2.4.2 Subscriber Edge Router 353 Definition: 354 A subscriber edge router is a BGP-speaking router 355 belonging to an end user organization that may be multi- 356 homed, and which carries traffic only to and from that end 357 user AS. 359 Discussion: 360 Such a router will always speak eBGP and may speak iBGP. 362 Measurement units: 364 Issues: 366 See Also: 368 2.4.3 Inter-provider Border Router 370 Definition: 371 An inter-provider border router is a BGP speaking router 372 which maintains BGP sessions with another BGP speaking 373 router in another provider AS. Traffic transiting this 374 router may be directed to or from another AS that has no 375 direct connectivity with this provider's AS. 377 Discussion: 378 Such a router will always speak eBGP and may speak iBGP. 380 Measurement units: 382 Issues: 384 See Also: 386 2.4.4 Intra-provider Core Router 388 Definition: 389 An intra-provider core router is a provider router 390 speaking iBGP to the provider's edge routers, other intra- 391 provider core routers, or the provider's inter-provider 392 border routers. 394 Discussion: 395 Such a router will always speak iBGP and may speak eBGP. 397 Measurement units: 399 Issues: 400 MPLS speaking routers are outside the scope of this 401 document. It is entirely likely, however, that core Label 402 Switched Routers, especially in the P router role of 403 RFC 2547 [10], may contain little or no BGP information. 405 See Also: 407 3. Routing Data Structures 409 3.1 Routing Information Base (RIB) 411 The RIB collectively consists of a set of logically (not necessarily 412 literally) distinct databases, each of which is enumerated below. The 413 RIB contains all destination prefixes to which the router may 414 forward, and one or more currently reachable next hop addresses for 415 them. 417 Routes included in this set potentially have been selected from 418 several sources of information, including hardware status, interior 419 routing protocols, and exterior routing protocols. RFC 1812 contains 420 a basic set of route selection criteria relevant in an all-source 421 context. Many implementations impose additional criteria. A common 422 implementation-specific criterion is the preference given to 423 different routing information sources. 425 3.1.1 Adj-RIB-In and Adj-RIB-Out 427 Definition: 428 Adj-RIB-In and Adj-RIB-Out are "views" of routing 429 information from the perspective of individual peer 430 routers. 432 The Adj-RIB-In contains information advertised to the DUT 433 by a specific peer. The Adj-RIB-Out contains the 434 information the DUT will advertise to the peer. 436 See RFC 1771[1]. 438 Discussion: 440 Issues: 442 Measurement Units: Number of route instances 444 See Also: Route, BGP Route, Route Instance, Loc-RIB, FIB 446 3.1.2 Loc-RIB 448 Definition: 449 The Loc-RIB contains the set of best routes selected from 450 the various Adj-RIBs, after applying local policies and 451 the BGP route selection algorithm. 453 Discussion: 454 The separation implied between the various RIBs is 455 logical. It does not necessarily follow that these RIBs 456 are distinct and separate entities in any given 457 implementation. 459 Types of routes can include internal BGP, external 460 BGP,interface, static and IGP routes. 462 Issues: 464 Measurement Units: Number of route instances. 466 See Also: Route, BGP Route, Route Instance, Adj-RIB-in, 467 Adj-RIB-out,FIB 469 3.2 Policy 471 Definition: 472 Policy is "the ability to define conditions for accepting, 473 rejecting, and modifying routes received in 474 advertisements"[9]. 476 Discussion: 477 RFC 1771 [1] further constrains policy to be within the 478 hop-by-hop routing paradigm. Policy is implemented using 479 filters and associated policy actions. Many AS's 480 formulate and document their policies using the Routing 481 Policy Specification Language (RPSL) [6] and then 482 automatically generate configurations for the BGP 483 processes in their routers from the RPSL specifications. 485 Measurement Units: Number of policies; length of policies 487 Issues: 489 See Also: Policy Information Base. 491 3.3 Policy Information Base 493 Definition: 494 A policy information base is the set of incoming and 495 outgoing policies. 497 Discussion: 498 All references to the phase of the BGP selection process 499 below are made with respect to RFC 1771 [1] definition of 500 these phases. 502 Incoming policies are applied in Phase 1 of the BGP 503 selection process [1] to the Adj-RIB-In routes to set the 504 metric for the Phase 2 decision process. Outgoing 505 Policies are applied in Phase 3 of the BGP process to the 506 Adj-RIB-Out routes preceding route (prefix and path 507 attribute tuple) announcements to a specific peer. 509 Policies in the Policy Information Base have matching and 510 action conditions. Common information to match include 511 route prefixes, AS paths, communities, etc. The action on 512 match may be to drop the update and not pass it to the 513 Loc-RIB, or to modify the update in some way, such as 514 changing local preference (on input) or MED (on output), 515 adding or deleting communities, prepending the current AS 516 in the AS path, etc. 518 The amount of policy processing (both in terms of route 519 maps and filter/access lists) will impact the convergence 520 time and properties of the distributed BGP algorithm. The 521 amount of policy processing may vary from a simple policy 522 which accepts all routes and sends all routes to complex 523 policy with a substantial fraction of the prefixes being 524 filtered by filter/access lists. 526 Measurement Units: Number and length of policies 528 Issues: 530 See Also: 532 3.4 Forwarding Information Base (FIB) 534 Definition: 535 As according to the definition in Appendix B of [4]: 536 "The table containing the information necessary to forward 537 IP Datagrams is called the Forwarding Information Base. 538 At minimum, this contains the interface identifier and 539 next hop information for each reachable destination 540 network prefix." 542 Discussion: 543 The forwarding information base describes a database 544 indexing network prefixes versus router port identifiers. 546 The forwarding information base is distinct from the 547 "routing table" (the Routing Information Base or RIB), 548 which holds all routing information received from routing 549 peers. The Forwarding Information Base is generated from 550 the RIB. For the purposes of this document, the FIB is 551 effectively the subset of the RIB used by the forwarding 552 plane to make per-packet forwarding decisions. 554 Most current implementations have full, non-cached FIBs 555 per router interface. All the route computation and 556 convergence occurs before entries are downloaded into a 557 FIB. 559 Measurement units: N.A. 561 Issues: 563 See Also: Route, RIB 565 4. Components and characteristics of Routing information 567 4.1 (Network) Prefix 569 Definition: 570 "A network prefix is . . . a contiguous set of bits at the 571 more significant end of the address that defines a set of 572 systems; host numbers select among those systems." 573 (This definition is taken directly from section 2.2.5.2, 574 "Classless Inter Domain Routing (CIDR)", in [3].) 576 Discussion: 577 In the CIDR context, the network prefix is the network 578 component of an IP address. 580 Measurement Units: N.A. 582 Issues: 584 See Also 586 4.2 Network Prefix Length 588 Definition: 589 The network prefix length is the number of bits used to 590 define the network prefix. 592 Discussion: 593 A common alternative to using a bit-wise mask to 594 communicate this component is the use of "slash (/) 595 notation." Slash notation binds the notion of network 596 prefix length (see 4.2) in bits to an IP address. E.g., 597 141.184.128.0/17 indicates the network component of this 598 IPv4 address is 17 bits wide. Similar notation is used for 599 IPv6 network prefixes e.g. :FF02:20::/24 601 When referring to groups of addresses, the network prefix 602 length is often used as a means of describing groups of 603 addresses as an equivalence class. For example, 604 'one hundred /16 addresses' refers to 100 addresses whose 605 network prefix length is 16 bits. 607 Measurement units: bits 609 Issues: 611 See Also: network prefix 613 4.3 Route 615 Definition: 616 In general, a 'route' is the n-tuple 617 618 A route is not end-to-end, but is defined with respect to 619 a specific next hop that will move traffic closer to the 620 destination defined by the prefix. In this usage, a route 621 is the basic unit of information about a target 622 destination distilled from routing protocols. 624 Discussion: 625 This term refers to the concept of a route common to all 626 routing protocols. With reference to the definition above, 627 typical non-routing-protocol attributes would be 628 associated with diffserv or traffic engineering. 630 Measurement Units: N.A. 632 Issues: None. 634 See Also: BGP route 636 4.4 BGP Route 638 Definition: 639 A BGP route is an n-tuple 640 . 642 Discussion: 643 BGP Attributes, such as Nexthop or AS path are defined in 644 RFC 1771[1], where they are known as Path Attributes, and 645 are the qualifying data that accompanies the network 646 prefixes in a BGP route UPDATE message. (An UPDATE message 647 may contain multiple prefixes that share a common set of 648 attributes). 650 From RFC 1771: " For purposes of this protocol a route is 651 defined as a unit of information that pairs a destination 652 with the attributes of a path to that destination... A 653 variable length sequence of path attributes is present in 654 every UPDATE. Each path attribute is a triple 655 656 of variable length." 658 Measurement Units: N.A. 660 Issues: 662 See Also: Route, prefix, Adj-RIB-in, NLRI. 664 4.5 BGP Route Attributes and BGP Timers 666 The definitions in this section refer to items that are originally 667 defined in RFC 1771 [1] and are repeated here for convenience, and to 668 allow for some discussion beyond the definitions in RFC 1771. 670 4.5.1 Network Level Reachability Information (NLRI) 672 Definition: 673 The NRLI consists of one or more network prefixes that 674 share all other BGP path attributes and are distributed in 675 the update portion (as opposed to the unfeasible routes 676 portion) of a BGP UPDATE message. 678 Discussion: 679 Each prefix in the NLRI is combined with the (common) 680 path attributes in the UPDATE message to form a BGP route. 681 The NLRI encapsulates a set of destinations to which 682 packets can be routed (from this point in the network) 683 along a common route described by the path attributes. 685 Measurement Units: N.A. 687 Issues: 689 See Also: Route Packing, Network Prefix, BGP Route, NLRI 691 4.5.2 MinRouteAdvertisementInterval (MRAI) 693 Definition: 694 (Paraphrased from 1771[1]) The MRAI timer determines the 695 minimum time between advertisements of routes to a 696 particular destination (prefix) from a single BGP device. 697 The timer is applied on a pre-prefix basis, although the 698 timer is set on a per BGP device basis. 700 Discussion: 701 Given that a BGP instance may manage in excess of 100,000 702 routes, RFC 1771 allows for a degree of optimization in 703 order to limit the number of timers needed. The MRAI does 704 not apply to routes received from BGP speakers in the same 705 AS or to explicit withdrawals. 707 RFC 1771 also recommends that random jitter is applied to 708 MRAI in an attempt to avoid synchronization effects 709 between the BGP instances in a network. 711 In this document we define RIB convergence by measuring 712 the time an NLRI is advertised to the DUT to the time it 713 is advertised from the DUT. Clearly any delay inserted by 714 the MRAI will have a significant effect on this 715 measurement. 717 Measurement Units: seconds. 719 Issues: 721 See Also: NLRI, BGP route 723 4.5.3 MinASOriginationInterval (MAOI) 725 Definition: 726 The MAOI specifies the minimum interval between 727 advertisements of locally originated routes from this BGP 728 instance. 730 Discussion: 731 Random jitter is applied to MAOI in an attempt to avoid 732 synchronization effects between BGP instances in a 733 network. 735 Measurement Units: seconds 737 Issues: 739 See Also: MRAI, BGP route 741 4.6 Route Instance 743 Definition: 744 A route instance is a single occurrence of a route sent by 745 a BGP Peer for a particular prefix. When a router has 746 multiple peers from which it accepts routes, routes to the 747 same prefix may be received from several peers. This is 748 then an example of multiple route instances. 750 Discussion: 751 Each route instance is associated with a specific peer. 752 The BGP selection algorithm may reject a specific route 753 instance due to local policy. 755 Measurement Units: Number of route instances 757 Issues: 758 The number of route instances in the Adj-RIB-in bases will 759 vary based on the function to be performed by a router. An 760 inter-provider router, located in the default free zone 761 will likely receive more route instances than a provider 762 edge router, located closer to the end-users of the 763 network. 765 See Also: 767 4.7 Active Route 769 Definition: 770 Route for which there is a FIB entry corresponding to a 771 RIB entry. 773 Discussion: 775 Measurement Units: Number of routes. 777 Issues: 779 See also: RIB. 781 4.8 Unique Route 783 Definition: 784 A unique route is a prefix for which there is just one 785 route instance across all Adj-Ribs-In. 787 Discussion: 789 Measurement Units: N.A. 791 Issues: 793 See Also: route, route instance 795 4.9 Non-Unique Route 797 Definition: 798 A Non-unique route is a prefix for which there is at least 799 one other route in a set including more than one Adj-RIB- 800 in. 802 Discussion: 804 Measurement Units: N.A. 806 Issues: 808 See Also: route, route instance, unique active route. 810 4.10BGP UPDATE message 812 Definition: 813 An UPDATE message is an advertisement of a single NLRI, 814 possibly containing multiple prefixes, and multiple 815 withdrawals of unfeasible routes. See RFC 1771 ([1]) for 816 details. 818 Discussion: 820 Measurement Units: N.A. 822 Issues: 824 4.11Characterization of sets of update messages 826 This section contains a sequence of definitions that build up to the 827 definition of an Update Train, a concept originally introduced by 828 Jain and Routhier [11]. This is a formalization of the sort of test 829 stimulus that is expected as input to a DUT running BGP. This data 830 could be a well-characterized, ordered and timed set of hand-crafted 831 BGP UPDATE packets. It could just as well be a set of BGP UPDATE 832 packets that have been captured from a live router. 834 Characterization of route mixtures and Update Trains is an open area 835 of research. The particular question of interest for this work is 836 the identification of suitable Update Trains, modeled or taken from 837 live traces that reflect realistic sequences of UPDATEs and their 838 contents. 840 4.11.1 Route Packing 842 Definition: 843 Route packing is the number of route prefixes accommodated 844 in a single Routing Protocol UPDATE Message either as 845 updates (additions or modifications) or withdrawals. 847 Discussion: 848 In general, a routing protocol update may contain more 849 than one prefix. In BGP, a single UPDATE may contain two 850 sets of multiple network prefixes: one set of additions 851 and updates with identical attributes (the NLRI) and one 852 set of unfeasible routes to be withdrawn. 854 Measurement Units: 855 Number of prefixes. 857 Issues: 859 See Also: route, BGP route, route instance, update train, NLRI. 861 4.11.2 Route Mixture 863 Definition: 864 A collection of routes such as an NLRI, a set of UPDATE 865 messages or a RIB. 867 Discussion: 868 A route mixture is the input data for the benchmark. The 869 particular route mixture used as input must be selected to 870 suit the question being asked of the benchmark. 871 Data containing simple route mixtures, such as 100,000 /32 872 routes might test the performance limits of the BGP 873 device. 875 Using live data, or input that simulates live data, should 876 improve understanding of how the BGP device will operate 877 in a live network. The data for this kind of test must be 878 route mixtures that model the patterns of arriving control 879 traffic in the live Internet. 881 To accomplish that kind of modeling it is necessary to 882 identify the key parameters that characterize a live 883 Internet route mixture. The parameters and how they 884 interact is an open research problem. However, we 885 identify the following as affecting the route mixture: 886 - Path length distribution 887 - Attribute distribution 888 - Prefix distribution 889 - Packet packing 890 - Probability density function of inter-arrival times of 891 UPDATES Each of the items above is more 892 complex than a singlenumber. For example, one could 893 consider the distribution of prefixes by AS or 894 distribution of prefixes by length. 896 Measurement Units: Probability density functions 898 Issues: 900 See Also: NLRI, RIB. 902 4.11.3 Update Train 904 Definition: 905 An update train is a set of Routing Protocol UPDATE 906 messages sent by a router to a BGP peer. 908 Discussion: 909 The arrival pattern of UPDATEs can be influenced by many 910 things, including TCP parameters, hold-down timers, BGP 911 header processing, a peer coming up or multiple peers 912 sending at the same time. Network conditions such as a 913 local or remote peer flapping a link can also affect the 914 arrival pattern. 916 Measurement units: 917 Probability density function for the inter-arrival times 918 of UPDATE packets in the train. 920 Issues: 921 Characterizing the profiles of real world UPDATE trains is 922 a matter for future research. In order to generate 923 realistic UPDATE trains as test stimuli a formal 924 mathematical scheme or a proven heuristic is needed to 925 drive the selection of prefixes. Whatever mechanism is 926 selected it must generate Update trains that have similar 927 characteristics to those measured from live routers. 929 See Also: Route Mixture, MRAI, MAOI 931 4.11.4 Randomness in Update Trains 933 As we have seen from the previous sections, an update train used as a 934 test stimulus has a considerable number of parameters that can be 935 varied, to a greater or lesser extent, randomly and independently. 937 A random Update Train will contain: 939 - A route mixture randomized across 940 - NLRIs 941 - updates and withdrawals 942 - prefixes 943 - inter-arrival times of the UPDATEs 944 and possibly across other variables. 946 This is intended to simulate the unpredictable asynchronous nature of 947 the network, whereby UPDATE packets may have arbitrary contents and 948 be delivered at random times. 950 It is important that the data set be randomized sufficiently to avoid 951 favoring one vendor's implementation over another's. 952 Specifically, the distribution of prefixes could be structured to 953 favor the internal organization of the routes in a particular 954 vendor's databases. This is to be avoided. 956 4.12Route Flap 958 Definition: 959 RIPE 210 [7] define a route flap as "the announcement and 960 withdrawal of prefixes." For our purposes we define a 961 route flap as the rapid withdrawal/announcement or 962 announcement/withdrawal of a prefix in the Adj-RIB-in. A 963 route flap is not a problem until a route is flapped 964 several times in close succession. This causes negative 965 repercussions throughout the internet. 967 Discussion: 968 Route flapping can be considered a special and 969 pathological case of update trains. A practical 970 interpretation of what may be considered excessively rapid 971 is the RIPE recommendation of "four flaps in a row". See 972 Section 6.1.5 on flap damping for further discussion. 974 Measurement units: Flapping events per unit time. 976 Issues: 977 Specific Flap events can be found in Section 5.1Route 978 Change Events. A bench-marker should use a mixture of 979 different route change events in testing. 981 See Also: Route change events, flap damping, packet train 983 5. Route Changes and Convergence 985 The following two definitions are central to the benchmarking of 986 external routing convergence, and so are singled out for more 987 extensive discussion. 989 5.1 Route Change Events 991 A taxonomy characterizing routing information changes seen in 992 operational networks is proposed in [4] as well as Labovitz et al[5]. 993 These papers describe BGP protocol-centric events, and event 994 sequences in the course of an analysis of network behavior. The 995 terminology in the two papers categorizes similar but slightly 996 different behaviors with some overlap. We would like to apply these 997 taxonomies to categorize the tests under definition where possible, 998 because these tests must tie in to phenomena that arise in actual 999 networks. We avail ourselves of, or may extend, this terminology as 1000 necessary for this purpose. 1002 A route can be changed implicitly by replacing it with another route 1003 or explicitly by withdrawal followed by the introduction of a new 1004 route. In either case the change may be an actual change, no change, 1005 or a duplicate. The notation and definition of individual 1006 categorizable route change events is adopted from [5] and given 1007 below. 1009 a) AADiff: Implicit withdrawal of a route and replacement by a route 1010 different in some path attribute. 1011 b) AADup: Implicit withdrawal of a route and replacement by route 1012 that is identical in all path attributes. 1013 c) WADiff: Explicit withdrawal of a route and replacement by a 1014 different route. 1015 d) WADup: Explicit withdrawal of a route and replacement by a route 1016 that is identical in all path attributes. 1018 To apply this taxonomy in the benchmarking context, we need both 1019 terms to describe the sequence of events from the update train 1020 perspective, as listed above, and event indications in the time 1021 domain so as to be able to measure activity from the perspective of 1022 the DUT. With this in mind, we incorporate and extend the definitions 1023 of [5] to the following: 1025 a) Tup (TDx): Route advertised to the DUT by Test Device x 1026 b) Tdown(TDx): Route being withdrawn by Device x 1027 c) Tupinit(TDx): The initial announcement of a route to a unique 1028 prefix 1029 d) TWF(TDx): Route fail over after an explicit withdrawal. 1031 But we need to take this a step further. Each of these events can 1032 involve a single route, a "short" packet train, or a "full" routing 1033 table. We further extend the notation to indicate how many routes are 1034 conveyed by the events above: 1036 a) Tup(1,TDx) means Device x sends 1 route 1037 b) Tup(S,TDx) means Device x sends a train, S, of routes 1038 c) Tup(DFT,TDx) means Device x sends an approximation of a full 1039 default-free table. 1041 The basic criterion for selecting a "better" route is the final 1042 tiebreaker defined in RFC1771, the router ID. As a consequence, this 1043 memorandum uses the following descriptor events, which are routes 1044 selected by the BGP selection process rather than simple updates: 1046 a) Tbest -- The current best path. 1047 b) Tbetter -- Advertise a path that is better than Tbest. 1048 c) Tworse -- Advertise a path that is worse than Tbest. 1050 5.2 Device Convergence in the Control Plane 1052 Definition 1053 A routing device is said to have converged at the point in 1054 time when the DUT has performed all actions in the control 1055 plane needed to react to changes in topology in the 1056 context of the test condition. 1058 Discussion: 1059 For example, when considering BGP convergence, a change 1060 that alters the best route instance for a single prefix at 1061 a router would be deemed to have converged when this route 1062 is advertised to its downstream peers. Similarly, OSPF 1063 convergence concludes when SPF calculations have been 1064 performed and the required link states advertised onwards. 1066 The convergence process, in general, can be subdivided 1067 into three distinct phases: 1068 - convergence across the entire Internet, 1069 - convergence within an Autonomous System, 1070 - convergence with respect to a single device. 1072 Convergence with respect to a single device can be 1073 - convergence with regard to data forwarding process(es) 1074 - convergence with regard to the routing process(es), the 1075 focus of this document. 1077 It is the latter, convergence with regard to the routing 1078 process, that we describe in this and the methodology 1079 documents. 1081 Because we are trying to benchmark the routing protocol 1082 performance which is only a part of the device overall, 1083 this definition is intended (so far as is possible) to 1084 exclude any additional time such as is needed to download 1085 and install the forwarding information base in the data 1086 plane. This definition should be usable for different 1087 families of protocols. 1089 It is of key importance to benchmark the performance of 1090 each phase of convergence separately before proceeding to 1091 a composite characterization of routing convergence, where 1092 implementation-specific dependencies are allowed to 1093 interact. 1095 The time resolution needed to measure the device 1096 convergence depends to some extent on the types of the 1097 interfaces on the router. For modern routers with gigabit 1098 or faster interfaces, an individual UPDATE may be 1099 processed and re-advertised in very much less than a 1100 millisecond so that time measurements must be made to a 1101 resolution of hundreds to tens of microseconds or better. 1103 Measurement Units: 1104 Time period. 1106 Issues: 1108 See Also: 1110 6. BGP Operation Events 1112 The BGP speaker process(es) in a device restarts completely, for 1113 example, because of operator intervention or a power failure, or 1114 fails partially because a TCP session has terminated for a particular 1115 link. Until recently the BGP process would have to re-advertise all 1116 relevant routes on reestablished links potentially triggering updates 1117 across the network. Recent work is focused on limiting the volume of 1118 updates due to operational events and the amount of processing 1119 resulting from these events: This work includes soft refresh[12], a 1120 graceful restart mechanism [13] and cooperative route filtering 1121 (e.g.[14]). 1123 6.1 Hard reset 1125 Definition: 1126 An event which triggers a complete re-initialization of 1127 the routing tables on one or more BGP sessions, resulting 1128 in exchange of a full routing table on one or more links 1129 to the router. 1131 Discussion: 1133 Measurement Units: N/A 1135 Issues: 1137 See Also: 1139 6.2 Soft reset 1141 Definition: 1142 An event which results in a complete or partial restart of 1143 the BGP session(s) on a BGP device, but which avoids the 1144 exchange of a full table by maintaining state across the 1145 restart. 1147 Discussion: 1149 Measurement Units: N/A 1151 Issues: 1153 See Also: 1155 7. Factors that impact the performance of the convergence process 1157 While this is not a complete list, all of the items discussed below 1158 have a significant affect on BGP convergence. Not all of them can be 1159 addressed in the baseline measurements described in this document. 1161 7.1 General factors affecting device convergence 1163 These factors are conditions of testing external to the router Device 1164 Under Test (DUT). 1166 7.1.1 Number of peers 1168 As the number of peers increases, the BGP route selection algorithm 1169 is increasingly exercised. In addition, the phasing and frequency of 1170 updates from the various peers will have an increasingly marked 1171 effect on the convergence process on a router as the number of peers 1172 grows. Increasing the number of peers also increases the processing 1173 workload for TCP and BGP keepalives. 1175 7.1.2 Number of routes per peer 1177 The number of routes per BGP peer is an obvious stressor to the 1178 convergence process. The number, and relative proportion, of multiple 1179 route instances and distinct routes being added or withdrawn by each 1180 peer will affect the convergence process, as will the mix of 1181 overlapping route instances, and IGP routes. 1183 7.1.3 Policy processing/reconfiguration 1185 The number of routes and attributes being filtered, and set, as a 1186 fraction of the target route table size is another parameter that 1187 will affect BGP convergence. 1189 Extreme examples are 1190 - Minimal Policy: receive all, send all, 1191 - Extensive policy: up to 100% of the total routes have applicable 1192 policy. 1194 7.1.4 Interactions with other protocols. 1196 There are interactions in the form of precedence, synchronization, 1197 duplication and the addition of timers, and route selection criteria. 1198 Ultimately, understanding BGP4 convergence must include understanding 1199 of the interactions with both the IGPs and the protocols associated 1200 with the physical media, such as Ethernet, SONET, DWDM. 1202 7.1.5 Flap Damping 1204 A router can use flap damping to respond to route flapping. Use of 1205 flap damping is not mandatory, so the decision to enable the feature, 1206 and to change parameters associated with it, can be considered a 1207 matter of routing policy. 1209 The timers are defined by RFC 2439 [2] and discussed in RIPE-229 [7]. 1210 If this feature is in effect, it requires that the device keep 1211 additional state to carry out the damping, which can have a direct 1212 impact on the control plane due to increased processing. In 1213 addition, flap damping may delay the arrival of real changes in a 1214 route, and affect convergence times 1216 7.1.6 Churn 1218 In theory, a BGP device could receive a set of updates that 1219 completely defined the Internet, and could remain in a steady state, 1220 only sending appropriate keepalives. In practice, the Internet will 1221 always be changing. 1223 Churn refers to control plane processor activity caused by 1224 announcements received and sent by the router. It does not include 1225 keepalives and TCP processing. 1227 Churn is caused by both normal and pathological events. For example, 1228 if an interface of the local router goes down and the associated 1229 prefix is withdrawn, that withdrawal is a normal activity, although 1230 it contributes to churn. If the local device receives a withdrawal 1231 of a route it already advertises, or an announcement of a route it 1232 did not previously know, and re-advertises this information, again 1233 these are normal constituents of churn. Routine updates can range 1234 from single announcement or withdrawals, to announcements of an 1235 entire default-free table. The latter is completely reasonable as an 1236 initialization condition. 1238 Flapping routes are a pathological contributor to churn, as is MED 1239 oscillation [16]. The goal of flap damping is to reduce the 1240 contribution of flapping to churn. 1242 The effect of churn on overall convergence depends on the processing 1243 power available to the control plane, and whether the same 1244 processor(s) are used for forwarding and for control. 1246 7.2 Implementation-specific and other factors affecting BGP convergence 1248 These factors are conditions of testing internal to the Device Under 1249 Test (DUT), although they may affect its interactions with test 1250 devices. 1252 7.2.1 Forwarded traffic 1254 The presence of actual traffic in the device may stress the control 1255 path in some fashion if both the offered load due to data and the 1256 control traffic (FIB updates and downloads as a consequence of 1257 flaps)are excessive. The addition of data traffic presents a more 1258 accurate reflection of realistic operating scenarios than if only 1259 control traffic is present. 1261 7.2.2 Timers 1263 Settings of delay and hold-down timers at the link level as well as 1264 for BGP4, can introduce or ameliorate delays. As part of a test 1265 report, all relevant timers should be reported if they use non- 1266 default value. 1268 7.2.3 TCP parameters underlying BGP transport 1270 Since all BGP traffic and interactions occur over TCP, all relevant 1271 parameters characterizing the TCP sessions should be provided: eg 1272 Slow start, max window size, maximum segment size, or timers. 1274 7.2.4 Authentication 1276 Authentication in BGP is currently done using the TCP MD5 Signature 1277 Option [8]. The processing of the MD5 hash, particularly in devices 1278 with a large number of BGP peers and a large amount of update traffic 1279 can have an impact on the control plane of the device. 1281 8. Security Considerations 1283 The document explicitly considers authentication as a performance- 1284 affecting feature, but does not consider the overall security of the 1285 routing system. 1287 9. References 1289 Normative 1291 [1] Rekhter, Y. and Li, T., "A Border Gateway 1292 Protocol 4 (BGP-4)", RFC 1771, March 1995. 1294 [2] Villamizar, C., Chandra, R. and Govindan, R., 1295 "BGP Route Flap Damping", RFC 2439, 1296 November 1998." 1298 [3] Baker, F.,"Requirements for IP Version 4 1299 Routers", RFC 1812. June 1995. 1301 [4] Ahuja, A., Jahanian, F., Bose, A. and Labovitz, 1302 C., 1303 "An Experimental Study of Delayed Internet 1304 Routing Convergence", RIPE 37 - Routing WG. 1306 [5] Labovitz, C., Malan, G.R. and Jahanian, F., 1307 "Origins of Internet Routing Instability," 1308 Infocom 99. 1310 [6] Alaettinoglu, C., Villamizar, C., Gerich, E., 1311 Kessens, D., Meyer, D., Bates, T., Karrenberg, 1312 D. and Terpstra, M., "Routing Policy 1313 Specification Language (RPSL)", RFC 2622, June 1314 1999. 1316 [7] Barber, T., Doran, S., Karrenberg, D., Panigl, 1317 C., Schmitz, J., "RIPE Routing-WG Recommendation 1318 for coordinated route-flap damping parameters", 1319 RIPE 210. 1321 [8] Heffernan, A., "Protection of BGP Sessions via 1322 the TCP MD5 Signature Option", RFC 2385, August 1323 1998. 1325 [9] Juniper Networks,"Junos(tm) Internet Software 1326 Configuration Guide Routing and Routing 1327 Protocols, Release 4.2" 1328 http://www.juniper.net/techpubs/software/junos42/ 1329 swconfig-routing42/html/glossary.html#1013039. 1330 September 2000 (and other releases). 1332 [10] Rosen, E. and Rekhter, Y., "BGP/MPLS VPNs", RFC 1333 2547, March 1999. 1335 [11] Jain, R. and Routhier, S.A., "Packet trains -- 1336 measurement and a new model for computer network 1337 traffic," IEEE Journal on Selected Areas in 1338 Communication, 4(6)September 1986. 1340 Illustrative 1342 [12] Chen, E., "Route Refresh for BGP-4", RFC 2918, 1343 September 2000. 1345 [13] Ramachandra, S., Rekhter, Y., Fernando, R., 1346 Scudder, J.G. and Chen, E., 1347 "Graceful Restart Mechanism for BGP", 1348 draft-ietf-idr-restart-02.txt, January 2002, 1349 work in progress. 1351 [14] Chen, E. and Rekhter, Y, "Cooperative Route 1352 Filtering Capability for BGP-4", 1353 draft-ietf-idr-route-filter-05.txt, January 2002, 1354 work in progress. 1356 [15] T. Anderson et al. "Requirements for Separation 1357 of IP Control and Forwarding", 1358 draft-ietf-forces-requirements-02.txt, 1359 February 2002, work in progress. 1361 [16] McPherson, Gill, Walton, Retana, "BGP Persistent 1362 Route Oscillation Condition", 1363 , 1364 February 2002, work In progress. 1366 [17] Bates, T., "The CIDR Report", 1367 http://www.employees.org/~tbates/cidr-report.html 1368 Internet statistics relevant to inter-domain 1369 routing updated daily. 1371 [18] Smith, P. (designer), APNIC Routing Table 1372 Statistics, http://www.apnic.net/stats/bgp/, 1373 Statistics derived from a daily analysis of a 1374 core router in Japan. 1376 [19] Huston, G., Telstra BGP table statistics, 1377 http://www.telstra.net/ops/bgp/index.html, 1378 Statistics derived daily from the BGP tables of 1379 Telstra and other AS's routers. 1381 For Internet Draft consistency purposes only 1383 [20] Bradner, S., "The Internet Standards Process -- 1384 Revision 3", BCP 9, RFC 2026, October 1996 1386 10.Acknowledgments 1387 Thanks to Francis Ovenden for review and Abha Ahuja for 1388 encouragement. Much appreciation to Jeff Haas, Matt Richardson, and 1389 Shane Wright at Nexthop for comments and input. Debby Stopp and Nick 1390 Ambrose contributed the concept of route packing. 1392 11.Author's Addresses 1394 Howard Berkowitz 1395 Gett Communications 1396 5012 S. 25th St 1397 Arlington VA 22206 1398 Phone: +1 703 998-5819 1399 Fax: +1 703 998-5058 1400 EMail: hcb@gettcomm.com 1402 Elwyn Davies 1403 Nortel Networks 1404 London Road 1405 Harlow, Essex CM17 9NA 1406 UK 1407 Phone: +44-1279-405498 1408 Email: elwynd@nortelnetworks.com 1410 Susan Hares 1411 Nexthop Technologies 1412 517 W. William 1413 Ann Arbor, Mi 48103 1414 Phone: 1415 Email: skh@nexthop.com 1417 Padma Krishnaswamy 1418 Email: kri1@earthlink.net 1420 Marianne Lepp 1421 Juniper Networks 1422 51 Sawyer Road 1423 Waltham, MA 02453 1424 Phone: 617 645 9019 1425 Email: mlepp@juniper.net 1427 Alvaro Retana 1428 Cisco Systems, Inc. 1429 7025 Kit Creek Rd. 1430 Research Triangle Park, NC 27709 1431 Email: aretana@cisco.com 1433 Full Copyright Statement 1435 Copyright (C) The Internet Society (2002). All Rights Reserved. 1437 This document and translations of it may be copied and furnished to 1438 others, and derivative works that comment on or otherwise explain it 1439 or assist in its implementation may be prepared, copied, published 1440 and distributed, in whole or in part, without restriction of any 1441 kind, provided that the above copyright notice and this paragraph are 1442 included on all such copies and derivative works. However, this 1443 document itself may not be modified in any way, such as by removing 1444 the copyright notice or references to the Internet Society or other 1445 Internet organizations, except as needed for the purpose of 1446 developing Internet standards in which case the procedures for 1447 copyrights defined in the Internet Standards process must be 1448 followed, or as required to translate it into languages other than 1449 English. 1451 The limited permissions granted above are perpetual and will not be 1452 revoked by the Internet Society or its successors or assigns. 1454 This document and the information contained herein is provided on an 1455 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1456 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN BUT 1457 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1458 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1459 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.