idnits 2.17.1 draft-ietf-idr-idrp2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 655 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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. RFC 2119 keyword, line 1432: '... this value MUST NOT be advertise...' RFC 2119 keyword, line 1440: '... this value MUST NOT be advertise...' RFC 2119 keyword, line 1445: '... this value MUST NOT be advertise...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1764 has weird spacing: '...eration of ID...' == Line 1765 has weird spacing: '...rmation is a...' == Line 1766 has weird spacing: '...rmation is st...' == Line 1772 has weird spacing: '...equired by a ...' == Line 1784 has weird spacing: '...in both the...' == (2 more instances...) -- 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 (June 1996) is 10176 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? 'R' on line 2799 looks like a reference -- Missing reference section? 'A' on line 2789 looks like a reference -- Missing reference section? 'I' on line 2800 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Yakov Rekhter 2 Internet Draft Cisco Systems, Inc. 3 Paul Traina 4 Juniper Networks, Inc. 5 Expiration Date: January 1997 June 1996 7 Inter-Domain Routing Protocol, Version 2 9 draft-ietf-idr-idrp2-00.txt 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 2. Introduction 31 The Inter-Domain Routing Protocol (IDRP) permits a routing domain to 32 exchange information with other routing domains to facilitate the 33 operation of the routing and relaying functions of the Network Layer. 35 This protocol calculates path segments which consist of Boundary 36 Intermediate systems (BIS aka border routers) and the links that 37 interconnect them. A packet destined for an end system in another 38 routing domain will be routed via Intra-domain routing to a Boundary 39 Intermediate system in the current routing domain. Then, the BIS, 40 using the methods of this inter-domain routing protocol, will 41 calculate a path to a Boundary Intermediate system in an adjacent 42 routing domain lying on a path to the destination. After arriving at 43 the next routing domain, the packet may also travel within that 44 domain on its way towards a BIS located in the next domain along its 45 path. This process will continue on a hop-by-hop basis until the 46 packet arrives at a BIS in the routing domain which contains the 47 destination End system. The Boundary IS in this routing domain will 48 hand the incoming NPDU over to the domain's intra-domain routing 49 protocol, which will construct a path to the destination End system. 51 Inter-domain routing protocols place requirements on the type of 52 information that a routing domain must provide and on the methods by 53 which this information will be distributed to other routing domains. 54 These requirements are intended to be minimal, addressing only the 55 interactions between Boundary ISs; all other internal operations of 56 each routing domain are outside the scope of this protocol. That is, 57 this Inter-domain routing protocol does not mandate that a routing 58 domain run a particular intra-domain routing protocol. 60 The methods of this protocol differ from those generally adopted for 61 an intra-domain routing protocol because they emphasize the 62 interdependencies between efficient route calculation and the 63 preservation of legal, contractual, and administrative concerns. 64 This protocol calculates routes which will be efficient, loop-free, 65 and in compliance with the domain's local routing policies. IDRP may 66 be used when routing domains do not fully trust each other; it 67 imposes no upper limit on the number of routing domains that can 68 participate in this protocol; and it provides isolation between its 69 operations and the internal operations of each routing domain. 71 3. Scope 73 This document specifies a protocol to be used by Boundary 74 Intermediate systems (defined in 6 ) to acquire and maintain 75 information for the purpose of routing NPDUs between different 76 routing domains. Figure 1 illustrates the field of application of 77 this protocol. 79 This document specifies: 81 - the procedures for the exchange of inter-domain reachability and 82 path information between BISs 84 - the procedures for maintaining inter-domain routing information 85 bases within a BIS 87 - the encoding of protocol data units used to distribute inter- 88 domain routing information between BISs 89 +--------------+ +------------------+ +--------------+ 90 | End Routing | | Transit Routing | | End Routing | 91 | Domain | | Domain | | Domain | 92 +--------------+ +------------------+ +--------------+ 93 | / | | / 94 | / | | / 95 | / | | / 96 | / | | / 97 +------------------+ | +------------------+ 98 | Transit Routing | | | Transit Routing | 99 | Domain | | | Domain | 100 +------------------+ | +------------------+ 101 / | | | 102 / | | | 103 / | | | 104 +--------------+ +------------------+ | 105 | End Routing | | Transit Routing | | 106 | Domain | | Domain | | 107 +--------------+ +------------------+ | 108 | | 109 | | 110 | | 111 +--------------+ +--------------+ 112 | End Routing | | End Routing | 113 | Domain | | Domain | 114 +--------------+ +--------------+ 115 | / 116 | / 117 | / 118 +------------------+ 119 | Transit Routing | 120 | Domain | 121 +------------------+ 123 Figure 1. Field of Application. The Inter-domain Routing Protocol 124 operates between routing domains; intra-domain routing is 125 not within its scope. 127 The procedures are defined in terms of: 129 - interactions between Boundary Intermediate systems through the 130 exchange of protocol data units 132 - interactions between this protocol and the underlying Network 133 Service 134 - constraints on policy feasibility and enforcement which must be 135 observed by each Boundary Intermediate system in a routing domain 137 The boundaries of Administrative Domains are realized as artifacts of 138 the placement of policy constraints and the aggregation of network 139 layer reachability information; they are not manifested explicitly in 140 the protocol. The protocol described in this document operates at 141 the level of individual routing domains. The establishment of 142 administrative domains is outside the scope of this standard. 144 4. Definitions 146 For the purposes of this document, the following definitions apply. 148 4.1. Intra-domain routing protocol 150 A routing protocol that is run between Intermediate systems in a 151 single routing domain to determine routes that pass through only 152 systems and links wholly contained within the domain. 154 4.2. Inter-domain link 156 A real (physical) or virtual (logical) link between two or more 157 Boundary Intermediate systems. A link between two BISs in the same 158 routing domain carry both intra-domain traffic and inter-domain 159 traffic; a link between two BISs located in adjacent routing domains 160 can carry inter-domain traffic, but not intra-domain traffic. 162 4.3. Boundary Intermediate system 164 An intermediate system that runs the protocol specified in this 165 standard, has at least one inter-domain link attached to it, and may 166 optionally have intra-domain links attached to it. 168 4.4. End Routing Domain 170 A routing domain whose local policies permit its BISs to calculate 171 inter-domain path segments only for PDUs whose source is located 172 within that routing domain. There are two varieties of End routing 173 domains: stub and multi-homed. A stub ERD has inter-domain links to 174 only one adjacent routing domain, while a multi-homed ERD has inter- 175 domain links to several adjacent routing domains. 177 4.5. Transit Routing Domain 179 A routing domain whose policies permit its BISs to calculate inter- 180 domain path segments for PDUs whose source is located either in the 181 local routing domain or in a different routing domain. That is, it 182 can provide a relaying service for such PDUs. 184 4.6. Adjacent RDs 186 Two RDs ("A" and "B") are adjacent to one another if there is a at 187 least one pair of BISs, one located in "A" and the other in "B", that 188 are attached to each other by means of a real subnetwork. 190 4.7. RD Path 192 A list of the RDIs of the routing domains and routing domain 193 confederations through which a given UPDATE PDU has travelled. 195 4.8. Routing Domain Confederation 197 A set of routing domains which have agreed to join together and to 198 conform to the rules in 8.13 of this document. To the outside world, 199 a confederation is indistinguishable from a routing domain. 201 4.9. Nested RDCs 203 A routing domain confederation "A" (RDC-A) is nested within RDC-B 204 when all of the following conditions are satisfied simultaneously: 206 a) all members of RDC-A are also members of RDC-B 208 b) there are some members of RDC-B that are not members of RDC-A 210 4.10. Overlapping RDCs 212 A routing domain confederation (RDC-A) overlaps RDC-B when all the 213 following conditions are satisfied simultaneously: 215 a) there are some members of RDC-A that are also members of RDC-B, 216 and 218 b) there are some members of RDC-A that are not members of RDC-B, 219 and 221 c) there are some members of RDC-B that are not members of RDC-A. 223 4.11. Disjoint RDCs 225 Two routing domain confederations, RDC-A and RDC-B, are disjoint from 226 one another when there are no routing domains which are 227 simultaneously members of both RDC-A and RDC-B. 229 4.12. Policy Information Base 231 The collection of routing policies that a BIS will apply to the 232 routing information that it learns using the protocol described in 233 this document. It is not required that all routing domains use the 234 same syntax and semantics to express policy; that is, the format of 235 the Policy Information Base is left as a local option. 237 4.13. Route Origin 239 Each route or component of an aggregated route has a single unique 240 origin. This is the RD or RDC in which the route's destinations are 241 located. 243 5. Symbols and abbreviations 245 The symbols, acronyms, and abbreviations listed in the following 246 clauses are used in this document. 248 5.1. Data unit abbreviations 250 BISPDU Boundary Intermediate System PDU (IDRP message) 252 NPDU Network Protocol Data Unit (IPv4 or IPv6 packet) 254 PDU Protocol Data Unit (a packet) 256 5.2. Addressing abbreviations 258 SNPA Subnetwork Point of Attachment (data link address) 260 5.3. Other abbreviations 262 BIS Boundary Intermediate System (border router) 264 CM Confederation Member 266 ERD End Routing Domain 268 ES End System 270 FIB Forwarding Information Base 272 FSM Finite State Machine 274 IDRP Inter-domain Routing Protocol (an acronym for the protocol 275 described in this document) 277 IS Intermediate System (router) 279 MIB Management Information Base 281 NLRI Network layer reachability information (set of reachable 282 destinations) 283 PIB Policy Information Base 285 RDC Routing Domain Confederation 287 RDI Routing Domain Identifier 289 RIB Routing Information Base 291 TRD Transit Routing Domain 293 6. General protocol information 295 IDRP uses IP (either v4 or v6) as its transport protocol. In 296 particular, BISPDUs are encapsulated as the data portion of IP 297 packets. 299 IDRP is a connection-oriented protocol which is implemented only in 300 Intermediate systems. Routing and control information is carried in 301 BISPDUs (as specified in Section 7 ), which flow on connections 302 between pairs of BISs. Each BISPDU is packaged within one or more 303 NPDUs for transmission by the underlying Network service. IDRP relies 304 on the underlying Network service to provide for fragmentation and 305 reassembly of BISPDUs. IDRP queues outbound BISPDUs as input to the 306 underlying Network Layer service, retaining a copy of each BISPDU 307 until an acknowledgement is received. Similarly, inbound BISPDUs are 308 queued as input to the BISPDU-Receive process. 310 IDRP exchanges BISPDUs in a reliable fashion. It provides mechanisms 311 for the ordered delivery of BISPDUs and for the detection and 312 retransmission of lost or corrupted BISPDUs. The mechanisms for 313 achieving reliable delivery of BISPDUs are described in 8.7 ; methods 314 for establishing BIS-BIS connections are described in 8.6 316 To emphasize its policy-based nature, the IDRP routing model includes 317 a Policy Information Base. 319 IDRP can be described in terms of following major components: 321 a) BISPDU-Receive Process: 323 responsible for accepting and processing control and routing 324 information from the local environment and from BISPDUs of 325 other BISs. This information is used for a variety of purposes, 326 such as receiving error reports and guaranteeing reliable 327 reception of BISPDUs from neighboring BISs. (For example, the 328 Update-Receive process (see 8.14 ) is the part of the BISPDU- 329 Receive process that deals with the reception of routing 330 information after a BIS-BIS connection has been established.) 332 b) BISPDU-Send Process: 334 responsible for constructing BISPDUs which contain control and 335 routing information. BISPDUs are used by the local BIS for a 336 variety of purposes, such as advertising routing information to 337 other BISs, initiating BIS-BIS communication, and validating 338 BIS routing information bases. 340 c) Decision Process: 342 responsible for calculating routes which will be consistent 343 with local routing policies. It operates on information in both 344 the PIB and the Adj-RIBs, using it to create the Local RIBs 345 (Loc-RIBs) and the local Forwarding Information Bases (see 8.10 346 ). 348 d) Forwarding Process: 350 responsible for supplying resources to accomplish relaying of 351 NPDUs to their destinations. It uses the FIB(s) created by the 352 Decision Process. 354 6.1. Inter-RD topology 356 This protocol views an internet as an arbitrary interconnection of 357 Transit Routing Domains and End Routing Domains which are connected 358 by real inter-domain links placed between BISs located in the 359 respective routing domains. This standard provides for the direct 360 exchange of routing information between BISs, which may be located 361 either in the same routing domain or in adjacent routing domains. 363 6.2. Routing policy 365 The direct exchange of policy information is outside the scope of 366 IDRP. Instead, IDRP communicates policy information indirectly in its 367 UPDATE PDUs which reflect the effects of the local policies of RDs on 368 the path to the destination. 370 Each routing domain chooses its routing policies independently, and 371 insures that all its BISs calculate inter-domain paths which satisfy 372 those policies. Local routing policies are applied to information in 373 the Routing Information Base (RIB) to determine a degree of 374 preference for potential paths (see 8.15 ). From those paths which 375 are not rejected by the routing policy, a BIS selects the paths which 376 it will use locally; from the locally selected paths, the BIS will 377 then select the paths that it will advertise externally. 379 To enforce routing policies and to insure that policies are both 380 feasible and consistent, this protocol: 382 - carries path information, expressed in terms of Routing Domain 383 Identifiers (RDIs) and various path attributes, in its UPDATE PDUs 385 - permits a routing domain to selectively propagate its 386 reachability information to a limited set of other routing domains 388 - provides a method to detect policy inconsistencies within the 389 set of BISs located in a single routing domain. 391 - permits each routing domain to set its policies individually: 392 that is, global coordination of policy is not required. 394 The set of rules that comprises the routing policy enforced by a BIS 395 are held in a Policy Information Base (PIB), which is separate from 396 the RIB. 398 6.3. Types of systems 400 An Intermediate system that implements the protocol described in this 401 document is called a Boundary Intermediate system (BIS). Each BIS 402 resides in a single routing domain, and may optionally act 403 simultaneously as a BIS and as an intra-domain IS within its own 404 routing domain. 406 6.4. Types of routing domains 408 The protocol described in this document recognizes two types of 409 routing domains, end routing domains and transit routing domains; 410 each of them may contain both ISs and ESs. 412 6.5. Routing domain confederations 414 IDRP provides support for Routing Domain Confederations (RDCs); this 415 optional function permits groups of routing domains to be organized 416 in a hierarchical fashion. 418 An RDC is formed by means outside the scope of this protocol, and 419 composed of a set of confederation members. Confederation members 420 (CMs) are either individual routing domains or routing domain 421 confederations. Thus, the definition of an RDC is recursive: a 422 confederation member may be a single routing domain or another 423 confederation. 425 6.6. Routes: advertisement and storage 427 For purposes of this protocol, a route is defined as a unit of 428 information that pairs destinations with the attributes of a path to 429 those destinations: 431 - Routes are advertised between a pair of BISs in UPDATE PDUs: the 432 destinations are the systems whose address matches address 433 prefixes reported in the NLRI field, and the path is the 434 information reported in the path attributes fields of the same 435 UPDATE PDU. 437 - Routes are stored in the Routing Information Bases: namely, the 438 Adj-RIBs-In, the Loc-RIBs, and the Adj-RIBs-Out. Routes that will 439 be advertised to other BISs must be present in the Adj-RIBs-Out; 440 routes that will be used by the local BIS must be present in the 441 Loc-RIBs, and the next hop for each of these routes must present 442 in the local BIS's Forwarding Information Bases; and routes that 443 are received from other BISs are present in the Adj-RIBs-In. 445 A BIS can support multiple routes to the same destination by 446 maintaining multiple RIBs and the corresponding multiple FIBs. Each 447 Loc-RIB will be identified by a different RIB-Tag (see 6.7 and 6.8 ); 448 an Adj-RIB-Out shall contain at most one route to a particular 449 destination. 451 If the BIS chooses to advertise the route, it may add to or modify 452 the path attributes of the route before advertising it to adjacent 453 BISs. 455 IDRP also provides mechanisms by which a BIS can inform its neighbor 456 that a previously advertised route is no longer available for use. 458 There are three methods by which a given BIS can indicate that a 459 route has been withdrawn from service: 461 a) the NLRI for a previously advertised route can be advertised in 462 the WITHDRAWN ROUTES field of an UPDATE PDU, thus marking the 463 associated route as being no longer available for use 465 b) a replacement route (with the same FIB-Tag and NLRI) can be 466 advertised, or 468 c) the BIS-BIS connection can be closed, which implicitly removes 469 from service all routes which the pair of BISs had advertised to 470 each other. 472 6.7. RIB-Tag 474 Each RIB-Tag identifies a particular information base which will be 475 used to store information about the route. The RIB-tag is a common 476 identifier for the Adj-RIB-In, Loc-RIB, Adj-RIB-Out, and FIB with 477 which the route information is associated. 479 The number of RIB-tags is limited by local decisions - a BIS may 480 choose to support only a limited number of RIB-tags. 482 6.8. Selecting the information bases 484 Each RIB is identified by a RIB-Tag, and the same RIB-Tag also 485 uniquely identifies the associated FIB. 487 For an UPDATE PDU, the BIS determines the RIB-Tag, and the LOCAL_PREF 488 associated with each route that is advertised. 490 For an NPDU, the BIS unambiguously determines the FIB that should be 491 used for forwarding this NPDU. It maps certain fields in NPDU's 492 header into a RIB-Tag, which then unambiguously identifies a 493 particular FIB. 495 A summary of IDRP's information bases is presented in Table 1. 497 +----------------------------------------------------------------------+ 498 | Table 1 The IDRP Information Bases. The indexing | 499 | variables and contents of the RIBs and FIBs | 500 | are shown. | 501 +-----------------+-----------------+----------------------------------+ 502 | Information | Indexed by... | Contains... | 503 | Base | | | 504 +-----------------+-----------------+----------------------------------+ 505 | Adj-RIB-In | - BIS-Ident | - Path attributes | 506 | | of adjacent | - NLRI | 507 | | BIS | | 508 | | - RIB-Tag | | 509 | | - NLRI | | 510 +-----------------+-----------------+----------------------------------+ 511 | Loc-RIB | - RIB-Tag | - Path attributes | 512 | | | - NLRI | 513 +-----------------+-----------------+----------------------------------+ 514 | Adj-RIB-Out | - BIS-Ident | - Path attributes | 515 | | of adjacent | - NLRI | 516 | | BIS | | 517 | | - RIB-Tag | | 518 | | - NLRI | | 519 +-----------------+-----------------+----------------------------------+ 520 | FIB | - RIB-Tag | - IP addr of next hop BIS | 521 | | - NLRI | - Output SNPA of local BIS | 522 | | | - Input SNPA of next hop BIS | 523 +-----------------+-----------------+----------------------------------+ 525 6.9. Routing information exchange 527 This document provides several rules governing the distribution and 528 exchange of routing information: 530 - rules for distributing routing information internally (to BISs 531 within a routing domain) 533 - rules for distributing routing information externally (to BISs 534 in adjacent routing domains) 536 Routing information is carried in the protocol's BISPDUs, which are 537 generated on an event-driven basis whenever a BIS receives 538 information which causes it advertise new paths. 540 +----------------------------------------------------------------------+ 541 | Notes: | 542 | | 543 | a) As a local option, a BIS may elect to apply information | 544 | reduction techniques to path attributes and NLRI information. | 545 | | 546 | b) For each adjacent BIS, a given BIS maintains an Adj-RIB-In for | 547 | each RIB-Tag (including the null RIB-Tag) that it supports. | 548 | | 549 | c) A BIS maintains a separate Loc-RIB for each RIB-Tag (including | 550 | the null RIB-Tag) that it supports. | 551 | | 552 | d) For each adjacent BIS, a given BIS maintains an Adj-RIB-Out for | 553 | each RIB-Tag (including the null RIB-Tag) that it | 554 | advertises to that neighbor. | 555 | | 556 | e) A given BIS maintains a separate FIB for each RIB-Tag | 557 | (including the null RIB-Tag) that it supports - that is, each | 558 | FIB corresponds to a Loc-RIB. | 559 | | 560 | To facilitate the forwarding process, a BIS can organize each of | 561 | its FIBS into two conceptual parts: one containing information | 562 | for NLRI located within its own RD, and another for NLRI located | 563 | in other RDs (as in clause 8). For external NLRI, a BIS can | 564 | further organize the FIB information based on whether the | 565 | next-hop-BIS is located within its own RD or in another RD (see | 566 | 8.4, items "a" and "b"). And finally, for those next-hop BISs | 567 | located in its own RD, the local BIS can organize the | 568 | information according to a specific forwarding mechanism (see | 569 | 8.4, items "b1" and "b2"). | 570 +----------------------------------------------------------------------+ 572 6.9.1. Internal neighbor BIS 574 Each BIS establishes and maintains communications with all other BISs 575 located in its routing domain. The identity of all BISs within a 576 routing domain is contained in managed object internalBISNeighbors 577 described in 8.3 579 6.9.2. External neighbor BIS 581 Each BIS may establish and maintain communications with other BISs in 582 adjacent routing domains. A BIS has no direct communications link 583 with any BIS in another routing domain unless that RD is adjacent to 584 it, as defined in 6 : that is, a BIS does not communicate directly 585 with a BIS located in a different routing domain unless the pair of 586 BISs are attached to at least one common subnetwork. The identity of 587 neighbor BISs in adjacent routing domains is contained in managed 588 object externalBISNeighbors described in 8.3 590 6.10. Design objectives 592 The protocol described in this document was developed with a view 593 towards satisfying certain design goals, while others specifically 594 were not addressed by the mechanisms of this protocol. 596 6.10.1. Within the scope of the protocol 598 This document supports the following design requirements: 600 Control Transit through an RD: It provides mechanisms to permit a 601 given routing domain to control the ability of NPDUs from other 602 routing domains to transit through itself. 604 Autonomous Operation: It provides stable operation in an internet 605 where significant sections of the interworking environment will be 606 controlled by disjoint entities. 608 Distributed Information Bases: It does not require a centralized 609 global repository for either routing information or policy 610 information. 612 Deliverability: It accepts and delivers NPDUs addressed to 613 reachable routing domains and rejects NPDUs addressed to routing 614 domains known to be unreachable. 616 Adaptability: It adapts to topological changes between routing 617 domains, but not to traffic changes. 619 Promptness: It provides a period of adaptation to topological 620 changes between domains that is a reasonable function of the 621 maximum logical distance between any pair of routing domains 622 participating in an instance of this protocol. 624 Efficiency: It is efficient in the use of both processing 625 resources and memory resources; it does not create excessive 626 routing traffic overhead. 628 Robustness: It recovers from transient errors such as lost or 629 temporarily incorrect routing PDUs, and it tolerates imprecise 630 parameter settings. 632 Stability: It stabilizes in finite time to "good routes", as long 633 as there are no continuous topological changes or corruptions of 634 the routing and policy information bases. 636 Heterogeneity: It is designed to operate correctly over a set of 637 routing domains that may employ diverse intra-domain routing 638 protocols. It is capable of running over a wide variety of 639 subnetworks. 641 Availability: It will not result in inability to calculate 642 acceptable inter-domain paths when a single point of failure 643 happens for a pairing of topology and policy that have a cut set 644 greater than one. 646 Fault isolation: It will provide fault isolation so that: 648 - Problems within one routing domain will not affect intra- 649 domain routing in any other routing domain 651 - Problems within one routing domain will not affect inter- 652 domain routing, unless they occur on internal inter-domain 653 Links 655 - Inter-domain routing will not adversely affect intra-domain 656 routing. 658 Scaling: It imposes no upper limit on the number of routing 659 domains that can participate in a single instance of this 660 protocol. 662 Multiple Routing Administrations: It will accommodate inter-domain 663 route calculations without regard to whether or not the 664 participating routing domains are under control of one or several 665 administrative authorities. 667 6.10.2. Outside the scope of the protocol 669 The following requirements are not within the design scope of this 670 protocol: 672 Traffic Adaptation: It does not automatically modify routes based 673 on the traffic load. 675 Guaranteed delivery: It does not guarantee delivery of all offered 676 NPDUs. 678 Suppression of Transient Loops: Although it provides mechanisms to 679 detect and suppress looping of routing information, it provides no 680 mechanisms to detect or suppress transient looping of NPDUs. 682 7. Structure of BISPDUs 684 In this document, the term BISPDU (Boundary IS PDU) is used as a 685 general term to refer to any of the PDUs defined in this clause. 687 Octets in a PDU are numbered starting from 1, in increasing order. 688 Bits in an octet are numbered from 1 to 8, where bit 1 is the low- 689 order bit and is pictured on the right. When consecutive octets are 690 used to represent a number, the lower octet number has the most 691 significant value. The more significant semi-octet of each pair of 692 semi-octets in a given octet is encoded in the high order bit 693 positions (8 through 5). 695 Values are given in decimal, and all numeric fields are unsigned, 696 unless otherwise noted. 698 The types of PDUs used by this protocol are: 700 - OPEN PDU 702 - UPDATE PDU 704 - IDRP ERROR PDU 706 - KEEPALIVE PDU 708 - CEASE PDU 710 - RIB REFRESH PDU 712 7.1. Header of BISPDU 714 Each BISPDU has a fixed size header. There may or may not be a data 715 portion following the header, depending on the PDU type. 717 The layout of the header fields and their meanings are shown below: 719 +-------------------------------------------------------------------+ 720 | BISPDU Length (2 octets) | 721 +-------------------------------------------------------------------+ 722 | BISPDU Type (1 octet) | 723 +-------------------------------------------------------------------+ 724 | Sequence (4 octets) | 725 +-------------------------------------------------------------------+ 726 | Acknowledgement (4 octets) | 727 +-------------------------------------------------------------------+ 728 | Credit Offered (1 octet) | 729 +-------------------------------------------------------------------+ 730 | Credit Available (1 octet) | 731 +-------------------------------------------------------------------+ 732 | Validation Pattern (16 octets) | 733 +-------------------------------------------------------------------+ 735 The meaning and use of these fields are as follows: 737 BISPDU Length: 739 The BISPDU Length field is a 2 octet unsigned integer. It 740 contains the total length in octets of this BISPDU, including 741 both header and data portions. The value of the BISPDU Length 742 field shall be at least MinBISPDULength octets, and no greater 743 than the value carried in the Maximum_PDU_Size field of the 744 OPEN PDU received from the remote BIS. 746 Further, depending on the PDU type, there may be other 747 constraints on the value of the Length field; for example, a 748 KEEPALIVE PDU must have a length of exactly 30 octets. No 749 padding after the end of BISPDU is allowed, so the value of the 750 Length field must be the smallest value required given the rest 751 of the BISPDU. 753 BISPDU Type: 755 The BISPDU Type field contains a one octet type code which 756 identifies the specific type of the PDU. The supported type 757 codes are: 759 +----------------------------------------------------+------------+ 760 | BISPDU Type | Code | 761 +----------------------------------------------------+------------+ 762 | OPEN PDU | 1 | 763 +----------------------------------------------------+------------+ 764 | UPDATE PDU | 2 | 765 +----------------------------------------------------+------------+ 766 | IDRP ERROR PDU | 3 | 767 +----------------------------------------------------+------------+ 768 | KEEPALIVE PDU | 4 | 769 +----------------------------------------------------+------------+ 770 | CEASE PDU | 5 | 771 +----------------------------------------------------+------------+ 772 | RIB REFRESH PDU | 6 | 773 +----------------------------------------------------+------------+ 775 All other BISPDU type codes are reserved for future extensions. 777 Sequence: 779 The Sequence field contains a 4 octet unsigned integer that is 780 the sequence number of this PDU. The procedures for generating 781 sequence numbers for the various types of BISPDU are described 782 in 8.7.4 784 Acknowledgement: 786 The Acknowledgment field is a 4 octet unsigned integer that 787 contains the sequence number of the PDU that the sender last 788 received correctly and in sequence number order. 790 Credit Offered: 792 The contents of this field indicate the number of additional 793 BISPDUs that the sender is willing to accept from the remote 794 BIS; it is used by the flow control process described in 8.7.5 796 Credit Available: 798 The contents of this field indicate the number of additional 799 BISPDUs that the sender is able to send to the remote BIS; it 800 is used by the flow control process described in 8.7.5 802 Validation Pattern: 804 This 16-octet field is used to provide a validation function 805 for the BISPDU. Depending upon the contents of the field 806 "Authentication Code" of the OPEN PDU, this field can provide: 808 - data integrity for the contents of the BISPDU (see 8.7.1 809 and 8.7.3 ), or 811 - data integrity for the contents of the BISPDU plus 812 authentication of the peer BIS (see 8.7.2 ). 814 7.2. OPEN PDU 816 The OPEN PDU is used by a BIS for starting a BIS-BIS connection. The 817 first PDU sent by either side is an OPEN PDU. 819 The OPEN PDU contains a fixed header and the additional fields shown 820 below: 822 +-------------------------------------------------------------------+ 823 | Fixed Header | 824 +-------------------------------------------------------------------+ 825 | Version (1 octet) | 826 +-------------------------------------------------------------------+ 827 | Hold Time (2 octets) | 828 +-------------------------------------------------------------------+ 829 | Maximum PDU Size (2 octets) | 830 +-------------------------------------------------------------------+ 831 | BIS-Identifier Length Indicator (1 octet) | 832 +-------------------------------------------------------------------+ 833 | BIS-Identifier (variable) | 834 +-------------------------------------------------------------------+ 835 | Source RDI Length Indicator (1 octet) | 836 +-------------------------------------------------------------------+ 837 | Source RDI (variable) | 838 +-------------------------------------------------------------------+ 839 | RIB-TagsSet (variable) | 840 +-------------------------------------------------------------------+ 841 | Confed-IDs (variable) | 842 +-------------------------------------------------------------------+ 843 | Optional Parameters Length (2 octets) | 844 +-------------------------------------------------------------------+ 845 | Optional Parameters (variable) | 846 +-------------------------------------------------------------------+ 848 The meaning and use of these fields are as follows: 850 Version: 852 This one octet field contains the version number of the 853 protocol. Its value is currently 1. 855 Hold Time: 857 This 2-octet unsigned integer indicates the number of seconds 858 that the sender proposes for the value of the Hold Timer. Upon 859 receipt of an OPEN PDU, a BIS shall calculate the value of the 860 Hold Timer by using the smaller of its configured Hold Time and 861 the Hold Time received in the OPEN PDU. The Hold Time shall be 862 either zero or at least three seconds. An implementation may 863 reject connections on the basis of the Hold Time. The 864 calculated value indicates the maximum number of seconds that 865 may elapse between the receipt of successive KEEPALIVE, and/or 866 UPDATE messages by the sender (see 8.6.1.4 and 8.18.5 ) 868 Maximum PDU Size: 870 This field contains a 2 octet unsigned integer that is the 871 maximum number of octets that this BIS will accept in an 872 incoming UPDATE PDU, IDRP ERROR PDU, or RIB REFRESH PDU. 874 Independent of this value, every BIS shall accept KEEPALIVE 875 PDUs or CEASE PDUs of length 30 octets; every BIS shall also 876 accept any OPEN PDU with length less than or equal to 3000 877 octets. 879 As a minimum, every BIS is required to support reception of all 880 BISPDUs whose size is greater than or equal to MinBISPDULength 881 octets and less than or equal to 1024 octets: that is, the 882 minimum acceptable value for this field is 1024. 884 BIS-Identifier Length Indicator: 886 This one octet field contains the length in octets of the BIS- 887 Identifier field. 889 BIS-Identifier 891 This field indicates the BIS Identifier of the sender. A given 892 BIS sets the value of its BIS Identifier to an IP address 893 assigned to that BIS speaker. The value of the BIS Identifier 894 is determined on startup and is the same for every local 895 interface and every BIS peer. 897 Source RDI Length Indicator: 899 This one octet field contains the length in octets of the 900 Source RDI field. 902 Source RDI: 904 This variable length field contains the RDI of the routing 905 domain in which the BIS that is sending this BISPDU is located. 907 RIB-TagsSet: 909 This variable length field contains a list of all RIB-Tags that 910 the local BIS is willing to support when communicating with the 911 neighbor BIS (that is, the BIS to which this OPEN PDU is being 912 sent). It contains an encoding of all or part of the 913 information contained in managed object RIBTagsSet (See clauses 914 8.3 and 8.10.1 ). 916 A BIS is not required to list all of its supported RIB-Tags in 917 an OPEN PDU that is sent to a neighbor BIS located in an 918 adjacent routing domain. It must include only those RIB-Tags 919 that correspond to Adj-RIBs-Out that the local BIS will use to 920 communicate with the neighbor BIS, and those that correspond to 921 the RIB-Tags of the Adj-RIBs-In that the local BIS supports for 922 storing UPDATE PDUs received from that neighbor BIS. 924 However, a BIS shall include all of the RIB-Tags listed in 925 managed object RIBTagsSet in an OPEN PDU that is sent to 926 another BIS located in its own routing domain. Failure to do so 927 will result in an OPEN PDU error, as described in 8.18.2 929 The encoding of this field is as follows: 931 +-----------------------------------------------------------------+ 932 | Number of Non-null RIB-Tags (1 octet) | 933 +-----------------------------------------------------------------+ 934 | First RIB-Tag (1 octet) | 935 +-----------------------------------------------------------------+ 936 | .... | 937 +-----------------------------------------------------------------+ 938 | Last RIB-Tag (1 octet) | 939 +-----------------------------------------------------------------+ 941 The field Number of RIB-Tags is one octet long. It contains the total 942 number of non-null RIB-Tags supported by this BIS. Since every BIS 943 supports a null RIB-Tag (see clause 8.10.1 ), the null RIB-Tag shall 944 not be listed in the OPEN PDU. 946 If a BIS supports no RIB-Tags other than the null RIB-Tag, then the 947 field Number of Non-empty RIB-Tags shall contain 0. 949 If the Number of Non-null RIB-Tags is non-zero, then the BIS supports 950 all of the listed RIB-Tags plus the null RIB-Tag. 952 Confed-IDs: 954 This is a variable length field which reports the RDIs of all 955 RDCs that this BIS is a member of. The encoding of this field 956 is as follows: 958 The 1 octet field Number of RDCs gives the number of RDCs of 959 which this BIS is a member. A value of zero indicates that this 960 BIS participates in no RDCs. 962 For each such confederation, the following fields give the 963 length and RDI for each confederation. 965 +-----------------------------------------------------------------+ 966 | Number of RDCs (1 octet) | 967 +-----------------------------------------------------------------+ 968 | Length of First RDI (1 octet) | 969 +-----------------------------------------------------------------+ 970 | RDI of first RDC | 971 +-----------------------------------------------------------------+ 972 | .... | 973 +-----------------------------------------------------------------+ 974 | Length of Last RDI (1 octet) | 975 +-----------------------------------------------------------------+ 976 | RDI of last confederation | 977 +-----------------------------------------------------------------+ 979 Optional Parameters Length: 981 This 2-octet unsigned integer indicates the total length of the 982 Optional Parameters following this field in octets. If the 983 value of this field is zero, no Optional Parameters are 984 present. 986 Optional Parameters: 988 This field may contain a list of optional parameters, where 989 each parameter is encoded as a vector. 992 +-----------------------------------------------------------------+ 993 | Parameter Flags (1 octet) | 994 +-----------------------------------------------------------------+ 995 | Parameter Type (1 octet) | 996 +-----------------------------------------------------------------+ 997 | Parameter Length (1 or 2 octets) | 998 +-----------------------------------------------------------------+ 999 | Parameter Value (variable) | 1000 +-----------------------------------------------------------------+ 1002 Parameter Flags is a one octet field. The high-order bit (bit 1003 8) of the Parameter Flags octet is the Optional bit. If it is 1004 set to 1, the parameter is optional; if set to 0, the parameter 1005 is well-known. The second high-order bit (bit 7) of the 1006 Parameter Flags is the Extended Length bit. It defines whether 1007 the Parameter Length is one octet (if set to 0), or two octets 1008 (if set to 1). Extended Length may be used only if the length 1009 of the parameter is greater than 255 octets. 1011 Parameter Type is a one octet field that unambiguously 1012 identifies individual parameters. 1014 Parameter Length is a one or two octets field (depending on the 1015 value of the Extended Length in the Parameter Flags field) that 1016 contains the length of the Parameter Value field in octets. 1018 Parameter Value is a variable length field that is interpreted 1019 according to the value of the Parameter Type field. 1021 This document defines the following Optional Parameters: 1023 a) Authentication Information (Parameter Type 1): 1025 This well-known parameter may be used to authenticate a BIS 1026 peer. The Parameter Value field contains a 1-octet 1027 Authentication Code followed by a variable length 1028 Authentication Data. 1030 Authentication Code: 1032 This 1-octet unsigned integer indicates the 1033 authentication mechanism being used: 1035 a) Code 1 indicates that the Validation Pattern field 1036 in the header of each BISPDU contains an unencrypted 1037 checksum that provides data integrity for the contents 1038 of that BISPDU. Its use is described in 8.7.1 1040 b) Code 2 indicates that the Validation Pattern field 1041 in the header of each BISPDU provides both peer-BIS 1042 authentication and data integrity for the contents of 1043 the BISPDU. The specific mechanism used to generate 1044 the validation pattern is mutually agreed to by the 1045 pair of BISs, but is not specified by this document. 1046 Its use is described in 8.7.2 1048 c) Code 3 indicates that the Validation Pattern field 1049 in the header of each BISPDU contains an unencrypted 1050 checksum covering the concatenation of the contents of 1051 the BISPDU with untransmitted password string(s). Its 1052 use is defined in 8.7.3 1054 Authentication Data: 1056 The form and meaning of this field is a variable-length 1057 field that depends on the Authentication Code. The length 1058 of the authentication data field can be determined from 1059 the Length field of the BISPDU header. 1061 Absence of any Authentication Information in an OPEN PDU shall 1062 be treated as if the PDU carries Authentication Information 1063 with Authentication Type 1 (see 8.7.1 ). 1065 7.3. UPDATE PDU 1067 An UPDATE PDU is used to advertise feasible routes to a neighbor BIS, 1068 or to withdraw multiple unfeasible routes from service (see 6.6 ). 1069 An UPDATE PDU may simultaneously advertise multiple feasible routes 1070 and withdraw multiple unfeasible routes from service. The UPDATE PDU 1071 always includes the fixed header, Unfeasible Route Count field, and 1072 Total Path Length Attributes field; it can optionally contain the 1073 other fields: 1075 - if routes are being explicitly withdrawn from service, then the 1076 UNFEASIBLE ROUTE COUNT field will be non-zero, and the WITHDRAWN 1077 ROUTES fields will be present 1079 - if feasible routes are being advertised, then the TOTAL PATH 1080 ATTRIBUTES LENGTH field will be non-zero, and the PATH ATTRIBUTES 1081 and NLRI fields will be present. 1083 An UPDATE PDU can advertise multiple routes; a route is described by 1084 several path attributes, each of which is encoded as a 4-tuple. All 1085 path attributes contained in a given UPDATE PDU apply to the 1086 destinations carried in the Network Layer Reachability Information 1087 field of the UPDATE PDU. 1089 An UPDATE PDU can list multiple routes to be withdrawn from service. 1090 Each such route is identified by its NLRI, which unambiguously 1091 identifies the route in the context of the BIS-BIS connection in 1092 which it had been previously been advertised. 1094 An UPDATE PDU that is used only to withdraw routes from service (but 1095 not to advertise any feasible routes) will not include Path 1096 Attributes or NLRI. Conversely, if an UPDATE PDU does not withdraw 1097 any routes from service, the UNFEASIBLE ROUTE COUNT field will 1098 contain the value 0, and WITHDRAWN ROUTES field will not be present. 1100 The components of the UPDATE PDU are described below: 1102 +-------------------------------------------------------------------+ 1103 | Fixed Header | 1104 +-------------------------------------------------------------------+ 1105 | FIB Tag (1 octet) | 1106 +-------------------------------------------------------------------+ 1107 | Unfeasible Route Count (2 octets) | 1108 +-------------------------------------------------------------------+ 1109 | Withdrawn Routes (variable) | 1110 +-------------------------------------------------------------------+ 1111 | Total Path Attributes Length (2 octets) | 1112 +-------------------------------------------------------------------+ 1113 | Path Attributes (variable) | 1114 +-------------------------------------------------------------------+ 1115 | Network Layer Reachability Information (variable) | 1116 +-------------------------------------------------------------------+ 1118 The use of these fields is as follows: 1120 FIB Tag: 1122 This is a 1-octet long field that contains the FIB Tag 1123 associated with the routes carried in this UPDATE PDU. 1125 Unfeasible Route Count: 1127 This is a 2-octet long field that contains an unsigned integer 1128 whose value is equal to the number of routes that are included 1129 in the subsequent WITHDRAWN ROUTES field. A value of 0 1130 indicates that no routes are being withdrawn from service, and 1131 that the WITHDRAWN ROUTES field is not present in this UPDATE 1132 PDU. 1134 Withdrawn Routes: 1136 This is a variable length field that contains a list of NLRIs 1137 for the routes that are being withdrawn from service. Each NLRI 1138 is encoded as specified in 7.3.2 withdrawn from service. Each 1139 such route is identified by its NLRI, which unambiguously 1140 identifies the route in the context of the BIS-BIS connection 1141 in which it had been previously been advertised. 1143 Total Path Attribute Length: 1145 This is a 2-octet long field that contains an unsigned integer 1146 whose value is the total length of all Path Attributes in the 1147 UPDATE PDU in octets. 1149 Path Attributes: 1151 A variable length sequence of path attributes is present in 1152 every UPDATE PDU that is used to advertise a feasible route. 1154 Network Layer Reachability Information: 1156 A variable length field that lists the destinations for the 1157 feasible routes that are being advertised in this UPDATE PDU. 1159 7.3.1. Path attribute encoding 1161 Each path attribute is a 4-tuple of variable length - . The elements are used as follows: 1164 - Flag: 1166 The first element of each attribute is a one octet field: 1168 - The high-order bit (bit 8) of the attribute flags octet is 1169 the Optional bit. If it is set to 1, the attribute is 1170 optional; if set to 0, the attribute is well-known. 1172 - The second high-order bit (bit 7) of the attribute flags 1173 octet is the Transitive bit. It defines whether an optional 1174 attribute is transitive (if set to 1) or non-transitive (if 1175 set to 0). For well-known attributes, the Transitive bit 1176 shall be set to 1. 1178 - The third high-order bit (bit 6) of the attribute flags 1179 octet is the Partial bit. It defines whether the optional 1180 transitive attribute is partial (if set to 1) or complete 1181 (if set to 0). For well-known attributes and for optional 1182 non-transitive attributes the Partial bit shall be set to 0. 1184 - The lower order five bits (1 through 5) of the attribute 1185 flags octet are reserved. They shall be transmitted as 0 and 1186 shall be ignored when received. 1188 - Type: 1190 The second element of each attribute is a one octet field which 1191 contains the type code for the attribute. Currently defined 1192 attribute type codes are discussed in clause 8.11 1194 Note 4: It is not the intention of this document to define 1195 globally understood path attributes for type codes greater than 1196 value 128. Such codes are reserved for local use. 1198 - Length: 1200 The third field of each path attribute is 2 octets in length; 1201 it contains the length in octets of the immediately following 1202 Value field. 1204 - Value: 1206 The remaining octets of each path attribute field contain the 1207 value of the attribute, which is interpreted according to the 1208 attribute flags and the attribute type code. The supported 1209 attribute values and their encodings are defined below. 1211 7.3.1.1. LOCAL_PREF (Type Code 1) 1213 LOCAL_PREF is a well-known discretionary attribute that is a four 1214 octet non-negative integer. It is used by a BIS to inform other BISs 1215 in its own RD of the originating BIS's degree of preference for an 1216 advertised route. Usage of this attribute is described in 7.3.1.1 1218 7.3.1.2. INCOMPLETE_PATH (Type Code 2) 1220 INCOMPLETE_PATH is a well-known discretionary attribute that has a 1221 length of zero octets; its presence indicates that some (or all) of 1222 the path attributes or Network Layer Reachability Information 1223 contained in this UPDATE PDU have been obtained by methods not 1224 specified by IDRP. Conversely, its absence indicates that all path 1225 attributes and NLRI have been learned by methods defined within IDRP. 1226 Its usage is defined in 7.3.1.2 1228 7.3.1.3. RD_PATH (Type Code 3) 1230 The RD_PATH attribute is a well-known mandatory attribute composed of 1231 a series of RD path segments. Each path segment is represented by a 1232 triple . 1234 The path segment type is a 1-octet long field, with the following 1235 values defined: 1237 +------------------------------------------------------+------------+ 1238 | Segment Type | Value | 1239 +------------------------------------------------------+------------+ 1240 | RD_SET | 1 | 1241 +------------------------------------------------------+------------+ 1242 | RD_SEQ | 2 | 1243 +------------------------------------------------------+------------+ 1244 | ENTRY_SEQ | 3 | 1245 +------------------------------------------------------+------------+ 1246 | ENTRY_SET | 4 | 1247 +------------------------------------------------------+------------+ 1249 An RD_SEQ and a ENTRY_SEQ provide a list of RDIs, for routing domains 1250 or for confederations respectively, in the order that the routing 1251 information has travelled through them. An RD_SET and an ENTRY_SET 1252 provide an unordered list of RDIs, for routing domains or for 1253 confederations respectively; the routing information has not 1254 necessarily travelled through all of the listed domains or 1255 confederations. 1257 The path segment length is a two octet field containing the length in 1258 octets of the path segment value field. 1260 The path segment value field contains one or more 2-tuples . Length is a one octet long field that contains the length of 1262 the RDI in octets. 1264 Usage of this attribute is defined in clause 7.3.1.3 1266 7.3.1.4. NEXT_HOP (Type Code 4) 1268 This is a well-known discretionary attribute that can be used for two 1269 principal purposes: 1271 a) to permit a BIS to advertise a different BIS's IP address in 1272 the "Network Address of Next Hop" field 1274 b) to allow a given BIS to report some or all of the SNPAs that 1275 exist within the local system 1277 It is encoded as shown below: 1279 +-------------------------------------------------------------------+ 1280 | Address Family (2 octets) | 1281 +-------------------------------------------------------------------+ 1282 | Length of Network Address (1 octet) | 1283 +-------------------------------------------------------------------+ 1284 | Network Address of Next Hop (variable) | 1285 +-------------------------------------------------------------------+ 1286 | Number of SNPAs (1 octet) | 1287 +-------------------------------------------------------------------+ 1288 | Length of first SNPA(1 octet) | 1289 +-------------------------------------------------------------------+ 1290 | First SNPA (variable) | 1291 +-------------------------------------------------------------------+ 1292 | Length of second SNPA (1 octet) | 1293 +-------------------------------------------------------------------+ 1294 | Second SNPA (variable) | 1295 +-------------------------------------------------------------------+ 1296 | ... | 1297 +-------------------------------------------------------------------+ 1298 | Length of Last SNPA (1 octet) | 1299 +-------------------------------------------------------------------+ 1300 | Last SNPA (variable) | 1301 +-------------------------------------------------------------------+ 1303 The use and meaning of these fields are as follows: 1305 Address Family 1306 This field carries the identity of the protocol associated with 1307 the address information that follows. Presently defined values 1308 for this field are specified in RFC1700. 1310 A conformant implementation of IDRP for IPv6 may ignore any 1311 address information indicating other than IPv6. A conformant 1312 implementation of IDRP for IPv4 may ignore any address 1313 information indicating other than IPv4. 1315 Length of Network Address: 1317 A 1 octet field whose value expresses the length of the 1318 "Network Address of Next Hop" field as measured in octets 1320 Network Address of Next Hop: 1322 A variable length field that contains the Network Address of 1323 the next BIS on the path to the destination system 1325 An implementation of IDRP for IPv4 or IPv6 shall have the 1326 following values in the Network Address field: 1328 IPv6: 1330 Length of Network Address: 16 1332 Network Address of Next Hop: an IPv6 unicast address 1334 IPv4: 1336 Length of Network Address: 4 1338 Network Address of Next Hop: an IPv4 unicast address 1340 Number of SNPAs: 1342 A 1 octet field which contains the number of distinct SNPAs to 1343 be listed in the following fields. The value 0 may be used to 1344 indicate that no SNPAs are listed in this attribute. 1346 Length of Nth SNPA: 1348 A 1 octet field whose value expresses the length of the "Nth 1349 SNPA of Next Hop" field as measured in semi-octets 1351 Nth SNPA of Next Hop: 1353 A variable length field that contains an SNPA of the BIS whose 1354 Network Address is contained in the "Network Address of Next 1355 Hop" field. The field length is an integral number of octets in 1356 length, namely the rounded-up integer value of one half the 1357 SNPA length expressed in semi-octets; if the SNPA has an 1358 contains an odd number of semi-octets, a value in this field 1359 will be padded with a trailing all-zero semi-octet. 1361 Usage of this attribute is defined in clause 7.3.1.4 1363 7.3.1.5. AGGREGATOR (Type Code 5) 1365 AGGREGATOR is an optional transitive attribute of length 32. The 1366 attribute contains the last RDI that formed the aggregate route 1367 (encoded as 16 octets), followed by the IP address of the BIS that 1368 formed the aggregate route (encoded as 16 octets, IPv4 addresses are 1369 prefixed with 12 octets of zeros). The BIS that formed the aggregate 1370 route may decline to encode its address and instead insert a value of 1371 all zeros into that field. 1373 Usage of this attribute is defined in clause 7.3.1.5 1375 7.3.1.6. ATOMIC_AGGREGATE (Type Code 6) 1377 ATOMIC_AGGREGATE is a well-known discretionary attribute of length 0. 1378 It is used by a BIS to inform other BISs that the local system 1379 selected for advertisement a less specific route without selecting a 1380 more specific route which is included in it. 1382 Usage of this attribute is defined in clause 7.3.1.6 1384 7.3.1.7. MULTI-EXIT_DISC (Type Code 7) 1386 MULTI-EXIT_DISC (Multi-exit Discriminator) is an optional non- 1387 transitive attribute that is a 4 octets non-negative integer. The 1388 value of this attribute may be used by a BIS's decision process to 1389 discriminate between multiple exit points to an adjacent routing 1390 domain. Its usage is defined in 7.3.1.7 1392 7.3.1.8. RD_HOP_COUNT (Type Code 13) 1394 The RD_HOP_COUNT is a well-known mandatory attribute that contains a 1395 1 octet long field. It contains an unsigned integer that is the 1396 upper bound on the number of routing domains through which this 1397 UPDATE PDU has travelled. Its usage is defined in 7.3.1.8 1399 7.3.1.9. CAPACITY (Type code 15) 1401 CAPACITY is a well-known mandatory attribute that has a length of 1 1402 octet, and is used to denote the relative capacity of the RD_PATH for 1403 handling traffic. High values indicate a lower traffic handling 1404 capacity than do low values. Its usage is defined in 7.3.1.9 1406 7.3.1.10. COMMUNITIES (Type Code 16) 1408 COMMUNITIES is an optional transitive attribute of variable length. 1409 The attribute is a tuple , where the first 1410 component specifies a particular community, and the second component 1411 specifies the scope within which the community is defined. All routes 1412 with this attribute belong to the communities listed in the 1413 attribute. 1415 Communities are treated as 32 bit values, however for administrative 1416 assignment, the following presumptions may be made: communities 1417 values ranging from 0x0000000 through 0x0000FFFF and 0xFFFF0000 1418 through 0xFFFFFFFF are hereby reserved. 1420 Scope of a community is either an RD, or RDC. Scope is specified by 1421 an RDI of the associated RD or RDC, encoded as a tuple . 1422 Length is a one octet long field that contains the length of the RDI 1423 in octets. 1425 The following communities have global significance and their 1426 operations shall be implemented in any community-attribute-aware BGP 1427 speaker. 1429 NO_EXPORT (0xFFFFFF01) 1431 All routes received carrying a communities attribute containing 1432 this value MUST NOT be advertised outside an RDC (as specified 1433 in the Scope component of the attribute) boundary. A stand- 1434 alone RD that is not part of an RDC should be considered an RDC 1435 itself). 1437 NO_ADVERTISE (0xFFFFFF02) 1439 All routes received carrying a communities attribute containing 1440 this value MUST NOT be advertised to other BISs. 1442 NO_EXPORT_SUBCONFED (0xFFFFFF03) 1444 All routes received carrying a communities attribute containing 1445 this value MUST NOT be advertised to external neighbors. 1447 7.3.2. Network layer reachability information 1449 The Network Layer Reachability information is a variable length field 1450 that contains a list of reachable destinations encoded as zero or 1451 more triples of the form
, 1452 whose fields are described below: 1454 +---------------------------+ 1455 | Address Family (2 octets) | 1456 +---------------------------+ 1457 | Addr_length (2 octets) | 1458 +---------------------------+ 1459 | Addr_info (variable) | 1460 +---------------------------+ 1462 The use and meaning of these fields are as follows: 1464 Address Family: 1466 This field carries the identity of the protocol associated with 1467 the address information that follows. Presently defined values 1468 for this field are specified in RFC1700. A conformant 1469 implementation of IDRP for IPv6 may ignore any address 1470 information indicating other than IPv6. A conformant 1471 implementation of IDRP for IPv4 may ignore any address 1472 information indicating other than IPv4. 1474 Addr_Length: 1476 This field specifies the total length in octets of the address 1477 information that follows. 1479 Addr_Info: 1481 This is a variable length field that contains a list of Network 1482 Layer address prefixes for the routes that are being 1483 advertised. Each address prefix is encoded as a 2-tuple of the 1484 form , whose fields are described below: 1486 +---------------------------+ 1487 | Length (1 octet) | 1488 +---------------------------+ 1489 | Prefix (variable) | 1490 +---------------------------+ 1492 The use and the meaning of these fields are as follows: 1494 a) Length: 1496 The Length field indicates the length in bits of the address 1497 prefix. A length of zero indicates a prefix that matches all 1498 (as specified by the address family) addresses (with prefix, 1499 itself, of zero octets). 1501 b) Prefix: 1503 The Prefix field contains address prefixes followed by 1504 enough trailing bits to make the end of the field fall on an 1505 octet boundary. Note that the value of trailing bits is 1506 irrelevant. 1508 7.4. IDRP ERROR PDU 1510 IDRP ERROR PDUs report error conditions which have been detected by 1511 the local BIS. In addition to its fixed header, the IDRP ERROR PDU 1512 contains the following fields: 1514 The use of these fields is as follows: 1516 Error code: The Error code field is 1 octet long, and shall be 1517 present in every IDRP ERROR PDU. It describes the type of error. 1518 The following error codes are defined: 1520 All errors are fatal to the BIS connection. 1522 +-------------------------------------------------------------------+ 1523 | Fixed Header | 1524 +-------------------------------------------------------------------+ 1525 | Error Code (1 octet) | 1526 +-------------------------------------------------------------------+ 1527 | Error Subcode (1 octet) | 1528 +-------------------------------------------------------------------+ 1529 | Data (variable) | 1530 +-------------------------------------------------------------------+ 1532 +----------------------------------------------------+------------+ 1533 | Error Code | Value | 1534 +----------------------------------------------------+------------+ 1535 | OPEN_PDU_Error | 1 | 1536 +----------------------------------------------------+------------+ 1537 | UPDATE_PDU_Error | 2 | 1538 +----------------------------------------------------+------------+ 1539 | Hold_Timer_Expired | 3 | 1540 +----------------------------------------------------+------------+ 1541 | FSM_Error | 4 | 1542 +----------------------------------------------------+------------+ 1543 | RIB_REFRESH_PDU_Error | 5 | 1544 +----------------------------------------------------+------------+ 1546 Error subcode: The Error subcode is one octet long, and shall be 1547 present in every IDRP ERROR PDU. The error subcode provides more 1548 specific information about the nature of the reported error. A 1549 given IDRP ERROR PDU may report only one error subcode for the 1550 indicated error code. The supported error subcodes are as follows: 1552 a) OPEN PDU Error subcodes: 1554 b) UPDATE PDU Error subcodes: 1556 c) Hold_Timer_Expired Error Subcodes: 1558 d) FSM_Error Error Subcodes: 1560 When an FSM Error (see 8.6.1 ) has occurred, the first semi- 1561 octet of the error subcode carries the type number of the 1562 BISPDU that should not have been received and the second semi- 1563 octet encodes the state that the FSM was in when the reception 1564 took place. The BISPDU type numbers are defined in 7.1 ; the 1565 +-------------------------------------------------+-----------+ 1566 | Subcode | Value | 1567 +-------------------------------------------------+-----------+ 1568 | Unsupported_Version_Number | 1 | 1569 +-------------------------------------------------+-----------+ 1570 | Bad_Max_PDU_Size | 2 | 1571 +-------------------------------------------------+-----------+ 1572 | Bad_Peer_RD | 3 | 1573 +-------------------------------------------------+-----------+ 1574 | Unsupported_Authentication_code | 4 | 1575 +-------------------------------------------------+-----------+ 1576 | Authentication_Failure | 5 | 1577 +-------------------------------------------------+-----------+ 1578 | Bad_RIB-TagsSet | 6 | 1579 +-------------------------------------------------+-----------+ 1580 | RDC_Mismatch | 7 | 1581 +-------------------------------------------------+-----------+ 1582 | Unacceptable Hold Time | 8 | 1583 +-------------------------------------------------+-----------+ 1584 | Unsupported well-known parameter | 9 | 1585 +-------------------------------------------------+-----------+ 1586 FSM states are encoded as follows: 1588 +-------------------------------------------------+-----------+ 1589 | FSM State | Encoded | 1590 | | Value | 1591 +-------------------------------------------------+-----------+ 1592 | CLOSED | 1 | 1593 +-------------------------------------------------+-----------+ 1594 | OPEN-RCVD | 2 | 1595 +-------------------------------------------------+-----------+ 1596 | OPEN-SENT | 3 | 1597 +-------------------------------------------------+-----------+ 1598 | CLOSE-WAIT | 4 | 1599 +-------------------------------------------------+-----------+ 1600 | ESTABLISHED | 5 | 1601 +-------------------------------------------------+-----------+ 1603 e) RIB_REFRESH_PDU_Error Subcodes: 1605 +-------------------------------------------------+-----------+ 1606 | Subcode | Value | 1607 +-------------------------------------------------+-----------+ 1608 | Invalid_OpCode | 1 | 1609 +-------------------------------------------------+-----------+ 1610 | Unsupported_RIB-Tags | 2 | 1611 +-------------------------------------------------+-----------+ 1612 +-------------------------------------------------+-----------+ 1613 | Subcode | Value | 1614 +-------------------------------------------------+-----------+ 1615 | Malformed_Attribute_List | 1 | 1616 +-------------------------------------------------+-----------+ 1617 | Unrecognized_Well-known_Attribute | 2 | 1618 +-------------------------------------------------+-----------+ 1619 | Missing_Well-known_Attribute | 3 | 1620 +-------------------------------------------------+-----------+ 1621 | Attribute_Flags_Error | 4 | 1622 +-------------------------------------------------+-----------+ 1623 | Attribute_Length_Error | 5 | 1624 +-------------------------------------------------+-----------+ 1625 | RD_Routing_Loop | 6 | 1626 +-------------------------------------------------+-----------+ 1627 | Invalid_NEXT_HOP_Attribute | 7 | 1628 +-------------------------------------------------+-----------+ 1629 | Optional_Attribute_error | 8 | 1630 +-------------------------------------------------+-----------+ 1631 | Invalid_Reachability_Information | 9 | 1632 +-------------------------------------------------+-----------+ 1633 | Misconfigured_RDCs | 10 | 1634 +-------------------------------------------------+-----------+ 1635 | Malformed_NLRI | 11 | 1636 +-------------------------------------------------+-----------+ 1637 | Duplicated_Attributes | 12 | 1638 +-------------------------------------------------+-----------+ 1639 | Illegal_RD_Path_Segment | 13 | 1640 +-------------------------------------------------+-----------+ 1642 +-------------------------------------------------+-----------+ 1643 | Subcode | Value | 1644 +-------------------------------------------------+-----------+ 1645 | NULL | 0 | 1646 +-------------------------------------------------+-----------+ 1647 Data: This variable length field contains zero or more octets 1648 of data to be used in diagnosing the reason for the IDRP ERROR 1649 PDU. The contents of the Data field depends upon the error code 1650 and error subcode. 1652 Note that the length of the Data field can be determined from 1653 the Length field of the BISPDU header. The minimum length of 1654 the IDRP ERROR PDU is 32 octets, including BISPDU header. 1656 7.5. KEEPALIVE PDU 1658 A KEEPALIVE PDU consists of only a PDU header and has a length of 30 1659 octets. 1661 A BIS can use the periodic exchange of KEEPALIVE PDUs with an 1662 adjacent BIS to verify that the peer BIS is reachable and active. 1663 KEEPALIVE PDUs are exchanged often enough as not to cause the hold 1664 time advertised in the OPEN PDU to expire. A reasonable maximum time 1665 between KEEPALIVE PDUs would be one third of the Hold Time interval. 1666 An implementation may adjust the rate at which it sends KEEPALIVE 1667 PDUs as a function of the Hold Time interval. 1669 If the negotiated Hold Time interval is zero, then periodic KEEPALIVE 1670 PDUs shall not be sent. 1672 A KEEPALIVE PDU may be sent asynchronously to acknowledge the receipt 1673 of other BISPDUs. Sending a KEEPALIVE PDU does not cause the sender's 1674 sequence number to be incremented. 1676 7.6. CEASE PDU 1678 A CEASE PDU consists of only a PDU header and has length of 30 1679 octets. 1681 A CEASE PDU is used by the originating BIS to instruct the peer BIS 1682 to close the BIS-BIS connection. 1684 Receipt of a CEASE PDU will cause the BIS to close down the 1685 connection with the BIS that issued it, as described in 8.6.2 1687 7.7. RIB REFRESH PDU 1689 The RIB REFRESH PDU is used to allow a BIS to send a refresh of the 1690 routing information in an Adj-RIB-Out to a neighbor BIS, or to 1691 solicit a neighbor BIS to send a refresh of its Adj-RIB-Out to the 1692 local BIS. The RIB REFRESH PDU contains a fixed header and also the 1693 additional fields shown below: 1695 The use and meaning of these fields is as follows: 1697 There are three OpCode values defined: 1699 +-------------------------------------------------------------------+ 1700 | Fixed Header | 1701 +-------------------------------------------------------------------+ 1702 | OpCode (1 octet) | 1703 +-------------------------------------------------------------------+ 1704 | RIB-Tags (variable) | 1705 +-------------------------------------------------------------------+ 1707 +------------+------------------------------------------------------+ 1708 | Code | Operation | 1709 +------------+------------------------------------------------------+ 1710 | 1 | RIB Refresh Request | 1711 +------------+------------------------------------------------------+ 1712 | 2 | RIB Refresh Start | 1713 +------------+------------------------------------------------------+ 1714 | 3 | RIB Refresh End | 1715 +------------+------------------------------------------------------+ 1717 The RIB-Tags field contains the RIB-Tags of the Adj-RIB-In for which 1718 a refresh is being requested. This field is encoded in the same way 1719 that the RIB-TagsSet field of the OPEN PDU is encoded. 1721 Its usage is defined in 8.10.2 1723 8. Elements of procedure 1725 This clause explains the elements of procedure used by the protocol 1726 specified in this document; it also describes the naming conventions 1727 and system deployment practices assumed by this protocol. 1729 8.1. Naming and addressing conventions 1731 IDRP for IPv4 and IPv6 does not assume or require any particular 1732 structure for IP addresses. That is, as long as the domain 1733 administrator assigns addresses that are consistent with the 1734 deployment constraints of section 7 of this document, the protocol 1735 will operate correctly. 1737 IP address prefixes provide a compact way for identifying groups of 1738 systems that reside in a given domain or confederation. A prefix may 1739 have a length that is either smaller than, or the same size as the IP 1740 address (an IPv4 or IPv6 address is a special case of an address 1741 prefix). The length of an encoded prefix is specified in bits. 1743 Each routing domain and routing domain confederation whose BIS(s) 1744 implement IDRP for IPv4 and IPv6 shall have an unambiguous routing 1745 domain identifier (RDI), which is an IPv4 or IPv6 address prefix. In 1746 the case of IPv4 address prefixes, the prefix value shall be 1747 prepended with 12 octets of zeros. 1749 An RDI is assigned statically and does not change based on the 1750 operational status of a routing domain. An RDI identifies routing 1751 domain or confederation uniquely, but does not necessarily convey any 1752 information about policies or identities of its members. 1754 8.2. Deployment guidelines 1756 Hosts and routers may use any IP unicast addresses, provided that 1757 these addresses are globally unambiguous. However correct and 1758 efficient operation of this protocol can only be guaranteed if the 1759 address assignment reflects the actual topology -- addresses are 1760 topologically significant. 1762 8.3. Domain configuration information 1764 Correct Operation of IDRP assumes that a minimum amount of 1765 information is available to both the inter-domain and intra-domain 1766 routing protocols. This information is static in nature, and is not 1767 expected to change frequently. This document assumes that this 1768 information is supplied via IDRP MIB. While the following in phrased 1769 in terms of MIB, this document allows alternative mechanisms (e.g. 1770 configuration files) as well. 1772 The information required by a BIS that implements the IDRP for IPv4 1773 and IPv6 protocol is: 1775 a) Location and identity of adjacent Intra-Domain routers: 1777 The MIB table IntraIS lists the IP addresses of the routers to 1778 which the local BIS may deliver an inbound NPDU whose 1779 destination lies within the BIS's routing domain. These routers 1780 listed in the IntraIS table support the intra-domain routing 1781 protocol of this domain, and share at least one common subnet 1782 with the BIS. 1784 In particular, if the local BIS participates in both the 1785 inter-domain routing protocol (IDRP) and the intra-domain 1786 routing protocol, then the IP address of the local BIS will be 1787 listed in the IntraIS table. 1789 b) Location and identity of BISs in the BIS's domain: 1791 This information permits a BIS to identify all other BISs 1792 located within its routing domain. This information is 1793 contained in the MIB table internalBISNeighbors, which contains 1794 a set of IP addresses which identify the BISs in the domain. 1796 c) Location and identity of BISs in adjacent domains: 1798 Each BIS needs information to identify the IP address of each 1799 BIS located in an adjacent RD and reachable via a single 1800 subnetwork hop. This information is contained in the IDRP MIB 1801 table externalBISNeighbors, which is a table of IP addresses. 1803 d) IP network address information for all systems in the routing 1804 domain: 1806 This information is used by the BIS to construct its network 1807 layer reachability information. This information is contained 1808 in the MIB table internalSystems, which lists NLRI (expressed 1809 as address prefixes) of the systems within the routing domain. 1811 e) Local RDI: 1813 This information is contained in managed object localRDI; it is 1814 the RDI of the routing domain in which the BIS is located. 1816 f) RDC-Config: 1818 This information identifies all the routing domain 1819 confederations (RDCs) to which the RD of the local BIS belongs, 1820 and it describes the nesting relationships that are in force 1821 between them. It is contained in the MIB table rdcConfig. 1823 Note that since a domain is not required to belong to a 1824 confederation this information is optional and needs to be 1825 present only at BISs of the domains that are part of one or 1826 more of RDCs. 1828 g) RIBTagsSet 1830 This managed object lists all of the RIB-Tags which are 1831 supported by the BISs located in this routing domain. 1833 8.4. Advertising NLRI 1835 The NLRI field in an UPDATE PDU contains information about the 1836 addresses of systems that reside within a given routing domain or 1837 whose Network Layer addresses are under control of the administrator 1838 of that routing domain; it should not be used to convey information 1839 about the operational status of these systems. The information in the 1840 NLRI field is intended to convey static administrative information 1841 rather than dynamic transient information: for example, it is not 1842 necessary to report that a given system has changed its status from 1843 online to offline. 1845 The following guidelines for inclusion of Network Layer address 1846 prefixes in the NLRI field of UPDATE PDUs originated within a given 1847 routing domain will provide efficient operation of this protocol: 1849 a) Network Layer addresses that are within the control of the 1850 administrator of a given routing domain may be reported in the 1851 NLRI field for that routing domain. The Network Layer address 1852 prefixes can provide information about systems that are online, 1853 systems that are offline, or unallocated Network Layer addresses. 1854 The ability to include unallocated Network Layer addresses and 1855 Network Layer addresses of offline systems in the NLRI allows a 1856 routing domain administrator to advertise compact prefixes, thus 1857 minimizing the amount of data carried in the BISPDUs. 1859 b) Network Layer addresses that are known to correspond to systems 1860 that are not under control of the routing domain administrator 1861 should not be included in the NLRI field for that routing domain. 1863 c) For efficient operation of this protocol, the WITHDRAWN ROUTES 1864 field should not be used to report the NLRI of systems in the 1865 local routing domain that are offline. This field should be used 1866 only to advertise Network Layer address prefixes that are no 1867 longer under control of the administrator of the local routing 1868 domain, regardless of whether such systems are online or offline. 1870 Note 9: Although the protocol in this document will operate 1871 correctly if each system is reported individually as a 1872 maximum-length Network Layer address prefix, this will result 1873 in a large amount of routing information, and hence can result 1874 in inefficient operation of this protocol. 1876 This protocol provides no means to verify that the preceding 1877 guidelines are followed. However, it is within the prerogative 1878 of the administrator of any routing domain to implement 1879 policies that ignore UPDATE PDUs that contain an excessive 1880 amount of NLRI information or that can cause inefficient 1881 operation of this protocol. 1883 8.5. An interface to IP 1885 IDRP information is carried between a pair of BISs in the form of 1886 BISPDUs. For IDRP for IPv6 these BISPDUs are carried in the data 1887 field of IP packets of protocol type 45. 1889 IDRP relies on IP to perform the initial processing of incoming 1890 BISPDUs. The IP protocol machine shall process inbound packets 1891 according to the appropriate IP functions. 1893 If a fixed header of an IP packet contains a protocol type that 1894 identifies IDRP, and the packet's source address identifies any 1895 system listed in managed objects internalBISNeighbors or 1896 externalBISNeighbors, then the packet contains a BISPDU. The BISPDU 1897 shall be passed to the IDRP finite state machine defined in 8.6.1 1899 8.6. BIS-BIS connection management 1901 The protocol described in this document relies on the underlying 1902 Network layer service to establish a full-duplex communications 1903 channel between each pair of BISs. 1905 8.6.1. BIS finite state machines 1907 A BIS shall maintain one finite state machine (FSM) for each BIS-BIS 1908 connection that it supports, and each FSM in a given BIS shall run 1909 independently of one another. A BIS-BIS connection will progress 1910 through a series of states during its lifetime, which are summarized 1911 in the state table shown in Table 2. 1913 BISPDUs passed to this finite state machine are subject the flow 1914 control procedures of 8.7.5 if the FSM is in the ESTABLISHED state. 1915 When the FSM is in the ESTABLISHED state, only BISPDUs that are not 1916 discarded by the flow control process are processed by the FSM. In 1917 all other states, all BISPDUs are processed directly by the finite 1918 state machine without being subject to flow control procedures. 1920 In describing the FSM transitions in response to receipt of BISPDUs, 1921 +--- Notation Warning ----------------------------------------------+ 1922 | | 1923 | To create a readable table within the bounds of a flat ASCII file | 1924 | using a monospaced font at 10 characters/inch, the following | 1925 | abbreviated notation is used within the table: | 1926 | | 1927 | start activate | 1928 | | 1929 | stop deactivate | 1930 | | 1931 | CLSD CLOSED | 1932 | | 1933 | OPRC OPEN-RCVD | 1934 | | 1935 | OPSN OPEN-SENT | 1936 | | 1937 | CLWT CLOSED-WAIT | 1938 | | 1939 | ESTB ESTABLISHED | 1940 | | 1941 | KPALV KEEPALIVE | 1942 | | 1943 | ClWtD CloseWaitDelay | 1944 | | 1945 | LFO ListenForOPEN | 1946 | | 1947 +-------------------------------------------------------------------+ 1949 the following shorthand notation is used: 1951 a) Receive with no errors means that the none of the error 1952 conditions defined in the appropriate subclause of 8.18 have been 1953 detected. 1955 b) Receive with errors means that an error condition defined in 1956 the appropriate subclause of 8.18 has been detected. 1958 It is possible to receive a BISPDU which is properly formed, but 1959 which normally should not be received while the FSM is in the given 1960 state. Such an event constitutes an FSM Error. If an FSM Error can 1961 occur for a given state, it is shown in the description of that 1962 state. 1964 8.6.1.1. CLOSED State 1966 Initially the BIS Finite State Machine is in the CLOSED state. The 1967 CLOSED state exists when no BIS-BIS connection exists and there is no 1968 connection record allocated. 1970 While in the CLOSED state, the BIS shall take the following actions: 1972 a) If the BIS receives a deactivate, no action shall be taken and 1973 the FSM shall remain in the CLOSED state. 1975 b) If the FSM receives an activate, the local BIS shall shall 1976 generate an initial sequence number (see 8.7.4 ), and shall send 1977 an OPEN PDU to the remote BIS. The sequence field of the OPEN PDU 1978 shall contain the Initial Sequence Number (ISN); the 1979 Acknowledgement and Credit Available fields shall contain the 1980 value 0; and the Credit Offered field shall contain the initial 1981 flow control credit. The FSM shall enter the OPEN-SENT state. 1983 c) If the managed object ListenForOPEN is TRUE, and the BIS 1984 receives an OPEN PDU with no errors, then the local BIS shall 1985 generate an initial sequence number (see 8.7.4 ) and shall send an 1986 OPEN PDU to the remote BIS. The sequence field of the OPEN PDU 1987 shall contain the Initial Sequence Number (ISN), the 1988 Acknowledgement field shall acknowledge the received OPEN PDU, the 1989 Credit Available field shall be set according to the procedures of 1990 8.7.5 (b), and the Credit Offered field shall contain the initial 1991 flow control credit. The FSM shall then change its state to 1992 OPEN_RCVD. 1994 d) If the managed object ListenForOPEN is TRUE and the BIS 1995 receives any BISPDU other than an OPEN PDU with no errors, or if 1996 the managed object ListenForOPEN is FALSE and the BIS receives any 1997 BISPDU, with or without errors, the BIS shall ignore the BISPDU 1998 and the FSM shall remain in the CLOSED state. 2000 8.6.1.2. OPEN-SENT State 2002 While in the OPEN-SENT state, the BIS shall take the following 2003 actions: 2005 a) If the FSM receives an activate, the BIS shall ignore it, and 2006 the FSM shall remain in the OPEN-SENT state. 2008 b) If the FSM receives a deactivate, the BIS shall send a CEASE 2009 PDU to its peer, and the FSM shall enter the CLOSE-WAIT state. 2011 c) If the BIS receives a BISPDU with header errors (see 8.18.1 ), 2012 it shall log the error event, and the FSM shall remain in the 2013 OPEN-SENT state. 2015 d) If the BIS receives an OPEN PDU with errors (see 8.18.2 ), it 2016 shall send an IDRP ERROR PDU to the adjacent BIS, acknowledging 2017 the remote BIS's OPEN PDU. The FSM shall then enter the CLOSE-WAIT 2018 state. 2020 e) If the BIS receives an OPEN PDU with no errors that does not 2021 acknowledge its own previously sent OPEN PDU, then the local BIS 2022 shall resend its own OPEN PDU with the same sequence number and 2023 with an acknowledgement of the remote BIS's OPEN PDU. The value of 2024 the Credit Available field shall be set according to the 2025 procedures of 8.7.5 (b). The FSM shall then change its state to 2026 OPEN-RCVD. 2028 f) If the BIS receives an OPEN PDU with no errors that 2029 acknowledges its own previously sent OPEN PDU, the local BIS shall 2030 send a KEEPALIVE, RIB REFRESH, or UPDATE PDU that acknowledges the 2031 OPEN PDU received from the remote BIS. The FSM shall then enter 2032 the ESTABLISHED state. 2034 g) If the BIS receives an IDRP ERROR PDU, either with or without 2035 error, it shall send a CEASE PDU, and the FSM shall change its 2036 state to CLOSED. 2038 h) If the BIS receives a RIB REFRESH PDU or UPDATE PDU, either 2039 with or without errors, it shall issue an IDRP ERROR PDU, 2040 indicating "FSM Error". The FSM shall then enter the CLOSE-WAIT 2041 state. 2043 i) If the BIS receives a KEEPALIVE PDU, it shall issue an IDRP 2044 ERROR PDU, indicating "FSM Error". The FSM shall then enter the 2045 CLOSE-WAIT state. 2047 j) If the BIS receives a CEASE PDU, it shall issue a CEASE PDU in 2048 return, and then the FSM shall enter the CLOSED state. 2050 k) If the BIS does not receive an OPEN PDU within a period t[ R] 2051 after sending an OPEN PDU, the BIS shall resend the OPEN PDU. If 2052 the OPEN PDU is retransmitted n times, the local BIS shall issue a 2053 deactivate to close the BIS-BIS connection. 2055 Note 10: The value t[R] should be chosen to be large enough so 2056 that attempting to establish a connection to an unresponsive 2057 peer BIS does not consume significant network resources. The 2058 values of t[R] and n must be chosen so that * n is 2059 greater than the architectural constant CloseWaitDelay. 2061 8.6.1.3. OPEN-RCVD State 2063 While in the OPEN-RCVD state, the BIS shall take the following 2064 actions: 2066 a) If the BIS receives an activate, it shall ignore it and the FSM 2067 shall remain in the OPEN-RCVD state. 2069 b) If the BIS receives a deactivate, it shall send a CEASE PDU to 2070 the remote BIS, and the FSM shall enter the CLOSE-WAIT state. 2072 c) If the BIS receives a BISPDU with a header error, it shall log 2073 the error event, and the FSM shall remain in the OPEN-RCVD state. 2075 d) If the BIS receives a KEEPALIVE PDU that acknowledges its 2076 previously sent OPEN PDU, then the FSM shall enter the ESTABLISHED 2077 state. 2079 e) If the BIS receives a KEEPALIVE PDU that does not acknowledge 2080 its previously sent OPEN PDU, the BIS shall issue an IDRP ERROR 2081 PDU indicating "FSM Error", and the FSM shall change its state to 2082 CLOSE-WAIT. 2084 f) If the BIS receives a CEASE PDU, it shall issue a CEASE PDU in 2085 return, and then the FSM shall enter the CLOSED state. 2087 g) If the BIS receives an OPEN PDU with no errors from the remote 2088 BIS that acknowledges the local BIS's previously sent OPEN PDU, 2089 the BIS shall send a KEEPALIVE, RIB REFRESH, or UPDATE PDU that 2090 acknowledges the OPEN PDU received from the remote BIS. The FSM 2091 shall then enter the ESTABLISHED state. 2093 h) If the BIS receives an OPEN PDU with no errors that does not 2094 acknowledge the local BIS's previously sent OPEN PDU, then the 2095 local BIS shall resend its own OPEN PDU with the same sequence 2096 number, and shall also include an acknowledgement of the remote 2097 BIS's OPEN PDU. The FSM shall remain in the OPEN-RCVD state. 2099 i) If the BIS receives an UPDATE PDU or RIB REFRESH PDU with 2100 errors, theBIS shall send an IDRP ERROR PDU to the remote BIS, and 2101 the FSM shall enter the CLOSE-WAIT state. 2103 j) If the BIS receives an UPDATE PDU or RIB REFRESH PDU with no 2104 errors that acknowledges the OPEN PDU previously sent by the local 2105 BIS, the FSM shall enter the ESTABLISHED state. 2107 k) If the BIS receives an UPDATE PDU or RIB REFRESH PDU with no 2108 errors that does not acknowledge the OPEN PDU previously sent by 2109 the local BIS, the BIS shall issue an IDRP ERROR PDU indicating 2110 "FSM Error", and the FSM shall change its state to CLOSE-WAIT. 2112 l) If the BIS receives an IDRP ERROR PDU, either with or without 2113 errors, it shall send a CEASE PDU to the remote BIS, and the FSM 2114 shall enter the CLOSED state. 2116 m) If the BIS does not exit the OPEN-RCVD state within a period 2117 t[R] after sending an OPEN PDU, the BIS shall resend the OPEN PDU. 2118 If the OPEN PDU is transmitted n times, the local BIS shall issue 2119 a deactivate. 2121 Note 11: The value t[R] should be chosen to be large enough so 2122 that attempting to establish a connection to an unresponsive 2123 peer BIS does not consume significant network resources. The 2124 values of t[R] and n must be chosen so that * n is 2125 greater than the architectural constant CloseWaitDelay. 2127 8.6.1.4. ESTABLISHED State 2129 The ESTABLISHED state is entered from either the OPEN-SENT or the 2130 OPEN-RCVD states. It is entered when a connection has been 2131 established by the successful exchange of state information between 2132 two sides of the connection. Each side has exchanged and received 2133 +----------------------------------------------------------------------+ 2134 | Table 2 (Page 1 of 7). BIS Finite State Machine. This table | 2135 | summarizes the effects that its inputs will | 2136 | have on an IDRP FSM, giving both state | 2137 | transitions and the actions to be taken. | 2138 +--------+-----------+-------------+-------------+----------+----------+ 2139 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 2140 | > | | | | | | 2141 +--------+ | | | | | 2142 | INPUT | | | | | | 2143 | V | | | | | | 2144 +--------+-----------+-------------+-------------+----------+----------+ 2145 | start | S=OPSN | S=OPRC | S=OPSN | S=CLWT | S=ESTB | 2146 | | A=send | A=none | A=none | A=none | A=none | 2147 | | OPEN PDU | | | | | 2148 +--------+-----------+-------------+-------------+----------+----------+ 2149 | stop | S=CLSD | S=CLWT | S=CLWT | S=CLWT | S=CLWT | 2150 | | A=none | A=send | A=send | A=none | A=send | 2151 | | | CEASE PDU | CEASE PDU | | CEASE | 2152 | | | | | | PDU | 2153 +--------+-----------+-------------+-------------+----------+----------+ 2154 | Expiry | S=CLSD | S=OPRC | S=OPSN | S=CLSD | S=ESTB | 2155 | of | A=none | A=none | A=none | A=7.6.2 | A=none | 2156 | ClWtD | | | | | | 2157 | Timer | | | | | | 2158 +--------+-----------+-------------+-------------+----------+----------+ 2160 such data as initial sequence number, maximum PDU size, credit 2161 offered, protocol version number, hold time, and RDI of the other 2162 side. In addition, the remote BIS may also have been authenticated. 2164 In ESTABLISHED state, both BISs that are involved in the connection 2165 may exchange UPDATE PDUs, KEEPALIVE PDUs, IDRP ERROR PDUs, RIB 2166 REFRESH PDUs, and CEASE PDUs. 2168 While in the ESTABLISHED state, the local BIS shall take the 2169 following actions: 2171 a) If the FSM receives an activate, the FSM shall ignore it, and 2172 the FSM shall remain in the ESTABLISHED state. 2174 b) If the FSM receives a deactivate, the BIS shall send a CEASE 2175 PDU to the peer BIS. The FSM shall enter the CLOSE-WAIT state. 2177 c) If the Hold Timer expires, the BIS shall issue an IDRP ERROR 2178 PDU to the remote BIS, reporting a Hold_Timer error. The FSM shall 2179 enter the CLOSE-WAIT state. 2181 +----------------------------------------------------------------------+ 2182 | Table 2 (Page 2 of 7). BIS Finite State Machine. This table | 2183 | summarizes the effects that its inputs will | 2184 | have on an IDRP FSM, giving both state | 2185 | transitions and the actions to be taken. | 2186 +--------+-----------+-------------+-------------+----------+----------+ 2187 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 2188 | > | | | | | | 2189 +--------+ | | | | | 2190 | INPUT | | | | | | 2191 | V | | | | | | 2192 +--------+-----------+-------------+-------------+----------+----------+ 2193 | Expiry | S=CLSD | S=OPRC | S=OPSN | S=CLWT | S=CLWT | 2194 | of | A=none | A=none | A=none | A=none | A=Send | 2195 | Hold | | | | | IDRP | 2196 | Timer | | | | | ERROR | 2197 | | | | | | PDU to | 2198 | | | | | | report | 2199 | | | | | | error | 2200 +--------+-----------+-------------+-------------+----------+----------+ 2201 | Receive| S=CLSD | S=OPRC | S=OPSN | S=CLWT | S=ESTB | 2202 | BISPDU | A=none | A=log error | A=log error | A=none | A=log | 2203 | with | | event | event | | error | 2204 | Header | | | | | event | 2205 | Error | | | | | | 2206 +--------+-----------+-------------+-------------+----------+----------+ 2207 | Receive| S=CLSD | If ACK is | S=CLWT | S=CLWT | S=ESTB | 2208 | KPALV | A=none | correct, | A=Send IDRP | A=send | A=Restart| 2209 | PDU | | | ERROR PDU | CEASE, | Hold | 2210 | with | | S=ESTB | to report | restart | Timer | 2211 | no | | A=Restart | FSM Error | ClWtD | | 2212 | errors | | Hold Timer | | timer | | 2213 | | | | | | | 2214 | | | If ACK is | | | | 2215 | | | incorrect, | | | | 2216 | | | | | | | 2217 | | | S=CLWT | | | | 2218 | | | A=Send | | | | 2219 | | | IDRP ERROR | | | | 2220 | | | PDU to | | | | 2221 | | | peer BIS | | | | 2222 | | | to report | | | | 2223 | | | FSM Error | | | | 2224 +--------+-----------+-------------+-------------+----------+----------+ 2226 d) If the BIS receives a BISPDU with a header error, it shall log 2227 the error event, and the FSM shall remain in the ESTABLISHED 2228 state. 2230 +----------------------------------------------------------------------+ 2231 | Table 2 (Page 3 of 7). BIS Finite State Machine. This table | 2232 | summarizes the effects that its inputs will | 2233 | have on an IDRP FSM, giving both state | 2234 | transitions and the actions to be taken. | 2235 +--------+-----------+-------------+-------------+----------+----------+ 2236 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 2237 | > | | | | | | 2238 +--------+ | | | | | 2239 | INPUT | | | | | | 2240 | V | | | | | | 2241 +--------+-----------+-------------+-------------+----------+----------+ 2242 | Receive| S=CLSD | S=CLSD | S=CLSD | S=CLSD | S=CLSD | 2243 | CEASE | A=none | A=send | A=send | A=7.6.2 | A=send | 2244 | PDU | | CEASE, | CEASE, | | CEASE, | 2245 | with | | 7.6.2 | 7.6.2 | | 7.6.2 | 2246 | no | | | | | | 2247 | errors | | | | | | 2248 +--------+-----------+-------------+-------------+----------+----------+ 2249 | Receive| S=CLOSE | S=CLWT | S=CLWT | S=CLWT | S=CLWT | 2250 | OPEN | A=none | A=Send IDRP | A=Send IDRP | A=none | A=Send | 2251 | PDU | | ERROR PDU | ERROR PDU | | IDRP | 2252 | with | | to peer BIS | to peer BIS | | ERROR | 2253 | errors | | to report | to report | | PDU to | 2254 | | | OPEN PDU | OPEN PDU | | peer BIS | 2255 | | | error | error | | to | 2256 | | | | | | report | 2257 | | | | | | OPEN PDU | 2258 | | | | | | error | 2259 +--------+-----------+-------------+-------------+----------+----------+ 2261 e) If the BIS receives a KEEPALIVE PDU, it shall restart its Hold 2262 Timer, and the FSM shall remain in the ESTABLISHED state. 2264 f) If the BIS receives a CEASE PDU, it shall issue a CEASE PDU in 2265 return, and then the FSM shall enter the CLOSED state. 2267 g) If an OPEN PDU with no errors is received from the peer BIS, it 2268 shall issue an IDRP ERROR PDU, indicating FSM error. The FSM shall 2269 enter the CLOSE-WAIT state. 2271 h) If the BIS receives an UPDATE PDU with no errors, the BIS shall 2272 perform the actions provided in 8.14 , and shall restart its Hold 2273 Timer. The FSM shall remain in the ESTABLISHED state. 2275 i) If the BIS receives a RIB REFRESH PDU with no errors, the BIS 2276 shall perform the actions provided in 8.10.2 , and shall restart 2277 its Hold Timer. The FSM shall remain in the ESTABLISHED state. 2279 +----------------------------------------------------------------------+ 2280 | Table 2 (Page 4 of 7). BIS Finite State Machine. This table | 2281 | summarizes the effects that its inputs will | 2282 | have on an IDRP FSM, giving both state | 2283 | transitions and the actions to be taken. | 2284 +--------+-----------+-------------+-------------+----------+----------+ 2285 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 2286 | > | | | | | | 2287 +--------+ | | | | | 2288 | INPUT | | | | | | 2289 | V | | | | | | 2290 +--------+-----------+-------------+-------------+----------+----------+ 2291 | Receive| If LFO is | If ACK is | If ACK is | S=CLWT | S=CLWT | 2292 | OPEN | TRUE, | correct, | correct, | A=send | A=Send | 2293 | PDU | | | | CEASE, | IDRP | 2294 | with | S=OPRC | S=ESTB | S=ESTB | restart | ERROR | 2295 | no | A=send | A=send | A=send | ClWtD | PDU to | 2296 | errors | OPEN PDU | KPALV, | KPALV, | timer | peer BIS | 2297 | | | UPDATE, or | UPDATE, or | | to | 2298 | | If LFO is | RIB | RIB | | report | 2299 | | FALSE, | REFRESH | REFRESH | | FSM | 2300 | | | PDU | PDU | | error | 2301 | | S=CLSD | | | | | 2302 | | A=none | If ACK is | If ACK is | | | 2303 | | | incorrect, | incorrect, | | | 2304 | | | | | | | 2305 | | | S=OPRC, | S=OPRC | | | 2306 | | | A=send | A=send | | | 2307 | | | OPEN PDU | OPEN PDU | | | 2308 +--------+-----------+-------------+-------------+----------+----------+ 2309 | Receive| S=CLSD | S=CLWT | S=CLWT | S=CLWT | S=CLWT | 2310 | UPDATE | A=none | A=Send IDRP | A=Send IDRP | A=none | A=Send | 2311 | PDU | | ERROR PDU | ERROR PDU | | IDRP | 2312 | with | | to peer BIS | to peer BIS | | ERROR | 2313 | errors | | to report | to report | | PDU to | 2314 | | | UPDATE PDU | FSM error | | peer BIS | 2315 | | | error | | | to | 2316 | | | | | | report | 2317 | | | | | | UPDATE | 2318 | | | | | | PDU | 2319 | | | | | | error | 2320 +--------+-----------+-------------+-------------+----------+----------+ 2322 j) If the BIS receives an UPDATE PDU with errors, an OPEN PDU with 2323 errors, or a RIB REFRESH PDU with errors, it shall send an IDRP 2324 ERROR PDU to the remote BIS to report the error, and the FSM shall 2325 enter the CLOSE-WAIT state. 2327 +----------------------------------------------------------------------+ 2328 | Table 2 (Page 5 of 7). BIS Finite State Machine. This table | 2329 | summarizes the effects that its inputs will | 2330 | have on an IDRP FSM, giving both state | 2331 | transitions and the actions to be taken. | 2332 +--------+-----------+-------------+-------------+----------+----------+ 2333 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 2334 | > | | | | | | 2335 +--------+ | | | | | 2336 | INPUT | | | | | | 2337 | V | | | | | | 2338 +--------+-----------+-------------+-------------+----------+----------+ 2339 | Receive| S=CLSD | If ACK is | S=CLWT | S=CLWT | S=ESTB | 2340 | UPDATE | A=none | correct, | A=Send IDRP | A=send | A=7.14, | 2341 | PDU | | | ERROR PDU | CEASE, | restart | 2342 | with | | S=ESTB | to peer BIS | restart | Hold | 2343 | no | | A=7.14, | to report | ClWtD | Timer | 2344 | errors | | restart | FSM error | timer | | 2345 | | | Hold Timer | | | | 2346 | | | | | | | 2347 | | | If ACK is | | | | 2348 | | | incorrect, | | | | 2349 | | | | | | | 2350 | | | S=CLWT | | | | 2351 | | | A=Send | | | | 2352 | | | IDRP ERROR | | | | 2353 | | | PDU to | | | | 2354 | | | peer BIS | | | | 2355 | | | to report | | | | 2356 | | | FSM Error | | | | 2357 +--------+-----------+-------------+-------------+----------+----------+ 2358 | Receive| S=CLSD | S=CLSD | S=CLSD | S=CLSD | S=CLSD | 2359 | IDRP | A=none | A=Send | A=Send | A=Send | A=Send | 2360 | ERROR | | CEASE PDU, | CEASE PDU, | CEASE | CEASE | 2361 | PDU | | 7.6.2 | 7.6.2 | PDU, | PDU, | 2362 | with | | | | 7.6.2 | 7.6.2 | 2363 | errors | | | | | | 2364 +--------+-----------+-------------+-------------+----------+----------+ 2365 | Receive| S=CLSD | S=CLSD | S=CLSD | S=CLSD | S=CLSD | 2366 | IDRP | A=none | A=Send | A=Send | A=Send | A=Send | 2367 | ERROR | | CEASE PDU, | CEASE PDU, | CEASE | CEASE | 2368 | PDU | | 7.6.2 | 7.6.2 | PDU, | PDU, | 2369 | with | | | | 7.6.2 | 7.6.2 | 2370 | no | | | | | | 2371 | errors | | | | | | 2372 +--------+-----------+-------------+-------------+----------+----------+ 2373 +----------------------------------------------------------------------+ 2374 | Table 2 (Page 6 of 7). BIS Finite State Machine. This table | 2375 | summarizes the effects that its inputs will | 2376 | have on an IDRP FSM, giving both state | 2377 | transitions and the actions to be taken. | 2378 +--------+-----------+-------------+-------------+----------+----------+ 2379 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 2380 | > | | | | | | 2381 +--------+ | | | | | 2382 | INPUT | | | | | | 2383 | V | | | | | | 2384 +--------+-----------+-------------+-------------+----------+----------+ 2385 | Receive| S=CLSD | S=CLWT | S=CLWT | S=CLWT | S=CLWT | 2386 | RIB | A=none | A=Send IDRP | A=Send IDRP | A=none | A=Send | 2387 | REFRESH| | ERROR PDU | ERROR PDU | | IDRP | 2388 | PDU | | to peer BIS | to peer BIS | | ERROR | 2389 | with | | to report | to report | | PDU to | 2390 | errors | | RIB REFRESH | FSM error | | peer BIS | 2391 | | | PDU error | | | to | 2392 | | | | | | report | 2393 | | | | | | RIB | 2394 | | | | | | REFRESH | 2395 | | | | | | PDU | 2396 | | | | | | error | 2397 +--------+-----------+-------------+-------------+----------+----------+ 2399 k) If the BIS receives an IDRP ERROR PDU, either with or without 2400 errors, it shall send a CEASE PDU to the remote BIS. The FSM shall 2401 enter the CLOSED state. 2403 CLOSE-WAIT State 2405 When an FSM enters the CLOSE-WAIT state, the local BIS is preparing 2406 to close the connection with the remote BIS. Upon entering this 2407 state, the local BIS shall mark all entries in the Adj-RIB-In 2408 associated with the adjacent BIS as unreachable, and shall then re- 2409 run its Decision Process. The CloseWaitDelay timer shall be started. 2411 While in the CLOSE-WAIT state, the BIS shall take the following 2412 actions: 2414 a) If the CloseWaitDelay timer expires, the connection ceases to 2415 exist. The FSM shall enter the CLOSED state. 2417 b) If the BIS receives a CEASE PDU, the FSM shall enter the CLOSED 2418 state. 2420 c) If the BIS receives an IDRP ERROR PDU, it shall send a CEASE 2421 +----------------------------------------------------------------------+ 2422 | Table 2 (Page 7 of 7). BIS Finite State Machine. This table | 2423 | summarizes the effects that its inputs will | 2424 | have on an IDRP FSM, giving both state | 2425 | transitions and the actions to be taken. | 2426 +--------+-----------+-------------+-------------+----------+----------+ 2427 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 2428 | > | | | | | | 2429 +--------+ | | | | | 2430 | INPUT | | | | | | 2431 | V | | | | | | 2432 +--------+-----------+-------------+-------------+----------+----------+ 2433 | Receive| S=CLSD | If ACK is | S=CLWT | S=CLWT | S=ESTB | 2434 | RIB | A=none | correct, | A=Send IDRP | A=send | A=7.10.3,| 2435 | REFRESH| | | ERROR PDU | CEASE, | restart | 2436 | PDU | | S=ESTB | to report | restart | Hold | 2437 | with | | A=7.10.3, | FSM Error | ClWtD | Timer | 2438 | no | | restart | | timer | | 2439 | errors | | Hold Timer | | | | 2440 | | | | | | | 2441 | | | If ACK is | | | | 2442 | | | incorrect, | | | | 2443 | | | | | | | 2444 | | | S=CLWT | | | | 2445 | | | A=Send | | | | 2446 | | | IDRP ERROR | | | | 2447 | | | PDU to | | | | 2448 | | | peer BIS | | | | 2449 | | | to report | | | | 2450 | | | FSM Error | | | | 2451 +--------+-----------+-------------+-------------+----------+----------+ 2453 PDU to the peer BIS. The FSM shall then enter the CLOSED state. 2455 d) If the BIS receives any other type of BISPDU, with or without 2456 errors, it shall issue a CEASE PDU. The FSM shall remain in the 2457 CLOSE-WAIT state, and the CloseWaitDelay timer shall be restarted. 2459 e) The BIS shall take no action for any of the following inputs, 2460 and the FSM shall remain in the CLOSE-WAIT state: 2462 - activate 2464 - deactivate 2466 - Expiration of Hold Timer 2468 +----------------------------------------------------------------------+ 2469 | Notes: | 2470 | | 2471 | a) "S" indicates the state into which the FSM will make a | 2472 | transition after performing the indicated action. | 2473 | | 2474 | b) "A" indicates the action to be taken. | 2475 | | 2476 | c) "X.Y.Z" is shorthand notation for "do as specified in clause | 2477 | X.Y.Z". | 2478 | | 2479 | d) The phrase "no errors" for a given BISPDU type means that no | 2480 | condition described in the appropriate subclause of 7.20 has | 2481 | been detected. | 2482 | | 2483 | e) The phrase "with errors" for a given BISPDU type means that a | 2484 | condition described in the appropriate subclause of 7.20 has | 2485 | been detected. | 2486 | | 2487 | f) Since the KPALV PDU and the CEASE PDU consist of only a fixed | 2488 | BISPDU header, errors in these BISPDUs are handled as Header | 2489 | Errors. Hence, there are no explicit entries in the table for | 2490 | "KPALV with errors" or "CEASE with errors". | 2491 +----------------------------------------------------------------------+ 2493 8.6.2. Closing a connection 2495 The closing of a connection can be initiated by a deactivate 2496 generated by the local system, by receipt of an incorrect PDU, by 2497 receipt of a IDRP ERROR PDU, by expiration of the Hold Timer, or by 2498 receipt of a CEASE PDU. The actions taken in response to each of 2499 these stimuli are shown in Table 2. 2501 When the connection enters the CLOSED state, the sequence number last 2502 used by the local BIS is recorded in managed object lastPriorSeqNo, 2503 and all routes that had been exchanged between the pair of BISs are 2504 implicitly withdrawn from service; hence, the local BIS should rerun 2505 its Decision Process. 2507 8.7. Validation of BISPDUs 2509 The protocol described in this document is a connection oriented 2510 protocol in which the underlying Network Layer service is used to 2511 establish full-duplex communication channels between pairs of BISs, 2512 as described in 8.6 use of any of the following three mechanisms for 2513 validating BISPDUs. Types 1,2, and 3 provide data integrity for the 2514 contents of BISPDUs; in addition, types 2 and 3 provide peer BIS 2515 authentication. Each mechanism is described below. 2517 8.7.1. Authentication type 1 2519 For all BISPDUs that flow on a connection that was established in 2520 response to an OPEN PDU whose authentication code field was equal to 2521 1, the validation field shall contain a 16-octet unencrypted 2522 checksum: 2524 a) Generating a Validation Pattern: 2526 The contents of the Validation Pattern field that is included 2527 in an outbound BISPDU shall be generated by applying the MD5 2528 Message-Digest algorithm (RFC1321) to the input data stream 2529 that consists of the contents of the entire BISPDU with all 2530 bits of the Validation Pattern field initially set to 0. The 2531 output of this step is an unencrypted 16-octet long checksum, 2532 which shall be placed in the Validation Pattern field of the 2533 BISPDU. 2535 b) Checking the Validation Pattern of an Inbound BISPDU: 2537 The contents of the Validation Pattern field of an inbound 2538 BISPDU shall be checked by applying the MD5 Message-Digest 2539 algorithm (RFC1321) to the contents of the inbound BISPDU with 2540 its Validation Pattern set to all zeros. Call this quantity the 2541 "reference pattern". 2543 If the "reference pattern" matches the contents of the 2544 Validation Pattern field of the inbound BISPDU, then the 2545 BISPDU's checksum is correct; otherwise, it is incorrect. 2547 8.7.2. Authentication type 2 2549 When the authentication type code of the OPEN PDU is 2, the pattern 2550 carried in the 16-octet Validation Pattern field of the fixed header 2551 shall provide both peer-BIS authentication and data integrity for the 2552 contents of the BISPDU. The specific mechanisms used to provide these 2553 functions are not specified by this document. However, they must be 2554 agreed to by the pair of communicating BISs as part of their security 2555 association. 2557 Note 12: This document includes as an optional function a 2558 mechanism that can be used for authentication of the source of a 2559 BISPDU. Other security-related facilities (for example, protection 2560 against replay of BISPDUs or the ability to re-key during a 2561 BIS_BIS connection) are not intended to be provided by this 2562 protocol, and therefore are not specified in this document. 2564 8.7.3. Authentication type 3 2566 When the authentication type code of the OPEN PDU is 3, the 2567 Validation Pattern field shall contain a 16-octet checksum covering 2568 both the contents of the BISPDU and some additional Password Text, 2569 which is not transmitted to the peer BIS. The method for encoding 2570 this data is specified in MD5 HMAC (RFC XXXX) The checksum provides 2571 data integrity and the untransmitted Password Text provides peer BIS 2572 authentication. 2574 The mechanisms are as follows: 2576 a) Generating a Validation Pattern: 2578 The contents of the Validation Pattern field that is carried in 2579 the outbound BISPDU shall be generated by the following 2580 process: 2582 1) Password text shall be appended to the BISPDU immediately 2583 after the final octet of the BISPDU (as defined by the 2584 BISPDU length field of the BISPDU header). Additional 2585 password text may also be prepended to the BISPDU 2586 immediately prior to the first octet of its header. 2588 2) A checksum that covers the contents of the BISPDU and the 2589 password text as specified by MD5 HMAC (RFC XXXX) shall be 2590 generated using the MD5 Message-Digest algorithm (RFC1331) 2591 with all bits of the Validation Pattern initially set to 2592 zero. The resultant checksum shall then be placed in the 2593 Validation Pattern field of the BISPDU. 2595 3) The password text shall not be transmitted along with the 2596 BISPDU. 2598 b) Checking the Validation Pattern of an Inbound BISPDU: 2600 The contents of the Validation Pattern field of an inbound 2601 BISPDU shall be checked by the following procedure: 2603 1) Append the Password Text to the BISPDU immediately after 2604 the final octet of the BISPDU (as defined by the BISPDU 2605 Length field of the BISPDU header. 2607 2) Apply the IDRP Checksum Algorithm to the data stream that 2608 consists of the concatenated contents of the BISPDU and the 2609 password text, with all bits of the BISPDU Validation 2610 Pattern set to zero. Call this value the "reference 2611 pattern". 2613 3) If the "reference pattern" is identical to the data 2614 carried in the Validation Pattern of the incoming BISPDU, 2615 then the peer BIS has been authenticated. If the "reference 2616 pattern" does not match the Validation Pattern, the 2617 receiving BIS shall inform system management that an 2618 authentication failure has occurred. The incoming BISPDU 2619 shall be ignored. The receiving BIS shall not send an IDRP 2620 ERROR PDU to the peer BIS because the identity of the peer 2621 has not been authenticated. 2623 8.7.4. Sequence numbers 2625 A sequence number is a 4-octet unsigned value. Sequence numbers shall 2626 increase linearly from 1 up to a maximum value of <2^32>-1. The 2627 value 0 is not a valid sequence number. 2629 The rules for manipulating sequence numbers are: 2631 a) When a BIS initially establishes a connection with an adjacent 2632 BIS, the first sequence number shall be set to 1 and shall 2633 increase linearly to a value of <2^32>-1. Before attempting to 2634 establish an initial BIS-BIS connection with an adjacent BIS, the 2635 local BIS must ensure that it has not sent a BISPDU to the 2636 adjacent BIS for at least CloseWaitDelay seconds. 2638 b) The sequence number shall not be incremented for the KEEPALIVE 2639 PDU, CEASE PDU, and the IDRP ERROR PDU. 2641 c) If the connection is subsequently closed under the conditions 2642 described in Table 2 and a subsequent connection is to be made to 2643 the same adjacent BIS, the local BIS shall, as a local matter, 2644 choose one of the following options: 2646 1) Maintain status of the sequence number space, and use any 2647 value greater than the value last used in the prior BIS-BIS 2648 connection (lastPriorSeqNo), or 2650 2) Ensure that at least CloseWaitDelay seconds have passed 2651 since the last BISPDU was sent to the adjacent BIS, and start 2652 with any sequence number. The choice of the initial value of 2653 the sequence number is a local matter. 2655 d) After a BIS sends a BISPDU with the maximum permissible 2656 sequence number (<2^32>-1) the BIS shall not send any further 2657 BISPDUs until the BISPDU with maximum sequence number and all 2658 outstanding BISPDUs have been acknowledged using the procedure of 2659 8.7.5 BIS then shall set its lower window edge (see 8.7.5 ) to 2660 one. When a BIS receives a BISPDU with a sequence number of one, 2661 after having acknowledged a BISPDU with the maximum permissible 2662 sequence number, it shall set the value of its next expected 2663 sequence number to one, prior to processing that BISPDU. 2664 Alternatively, after a BIS sends a BISPDU with the maximum 2665 permissible sequence number, the BIS may issue a CEASE BISPDU and 2666 restart the BIS-BIS connection. 2668 8.7.5. Flow control 2670 After an IDRP connection is established, the BIS Finite State Machine 2671 is in state ESTABLISHED (see section 8.6.1 ), and flow control and 2672 packet sequencing is in effect. The IDRP flow control process shall 2673 obey the following rules: 2675 a) A separate series of sequence numbers shall be maintained for 2676 each direction of a BIS-BIS connection, with the initial sequence 2677 number value chosen by the sender of a BISPDU and declared in the 2678 Sequence field of its OPEN PDU. The local BIS will maintain a 2679 window to manage transmission of BISPDUs to the remote BIS. The 2680 sender's lower window edge shall be set to the initial sequence 2681 number plus one; the sender's upper window edge shall be set to 2682 the lower window edge plus the value of credit offered contained 2683 in the peer BIS's OPEN PDU. Record is also kept of the next 2684 expected sequence number for an inbound UPDATE, RIB REFRESH, 2685 KEEPALIVE, or OPEN PDU to be received from the peer BIS; this is 2686 initially set to the value of one plus Sequence that is carried in 2687 the peer BIS's OPEN PDU. 2689 b) An UPDATE PDU or RIB REFRESH PDU shall not be sent if the upper 2690 window edge is less than or equal to the lower window edge. When a 2691 BISPDU is sent, the value of Sequence in the fixed header shall be 2692 set to the current value of the lower window edge. When an UPDATE 2693 or RIB REFRESH PDU is to be sent, the local BIS shall generate the 2694 contents of the BISPDU based on the current value of the lower 2695 window edge. The local BIS shall increment the local window edge 2696 by one before it transmits the BISPDU to the peer BIS and before 2697 it generates any other BISPDUs or processes any received BISPDUs; 2698 when a BISPDU other than an UPDATE or RIB REFRESH PDU is to be 2699 sent, the lower window edge shall not be incremented. The value of 2700 Acknowledgement shall be set to the value of the next expected 2701 sequence number less one. The value of credit offered shall be set 2702 to the number of additional BISPDUs that the local BIS is 2703 currently able to accept from the peer BIS. Credit, once offered, 2704 can not be revoked (that is, the remote BIS's upper window edge 2705 can not be reduced). Therefore, the sum of Acknowledgement and 2706 credit offered must never decrease in successive BISPDUs. The 2707 value of credit available shall be set to the upper window edge 2708 less the lower window edge (after incrementing the lower window 2709 edge, if appropriate). 2711 The local BIS shall retain a copy of transmitted UPDATE and RIB 2712 REFRESH BISPDUs for possible retransmission. 2714 c) An incoming UPDATE PDU or RIB REFRESH PDU whose Sequence value 2715 corresponds to the next expected sequence number shall be accepted 2716 and passed to the Finite State Machine described in 8.6.1 ; the 2717 next expected sequence number shall be incremented by one. 2719 An incoming UPDATE PDU or RIB REFRESH PDU whose Sequence is less 2720 than the next expected sequence number shall be discarded. An 2721 incoming UPDATE PDU or RIB REFRESH PDU whose Sequence is greater 2722 than the next expected sequence number shall be discarded, unless 2723 re-ordering is supported as a local implementation option, and the 2724 sequence number is not greater than the peer's upper window edge. 2726 An incoming KEEPALIVE PDU or OPEN PDU whose Sequence value 2727 corresponds to the next expected sequence number shall be accepted 2728 and passed to the Finite State Machine described in 7.6.1. An 2729 incoming KEEPALIVE PDU or OPEN PDU whose Sequence does not 2730 correspond to the next expected sequence number shall be 2731 discarded. 2733 An Incoming CEASE PDU or IDRP ERROR PDU shall be accepted and 2734 passed to the Finite State Machine described in 7.6.1regardless of 2735 its Sequence value. 2737 Whenever a BIS receives an UPDATE PDU, RIB REFRESH PDU, or 2738 KEEPALIVE PDU, it shall inspect its Acknowledgement and credit 2739 offered fields. Any BISPDUs retained for retransmission whose 2740 sequence number is less than or equal to the value of the 2741 Acknowledgement field shall be discarded. If the sum of one plus 2742 the value of Acknowledgement plus the value of credit offered in 2743 the received BISPDU is greater than the local BIS's current upper 2744 window edge, then the BIS shall set its upper window edge to this 2745 sum. 2747 d) A BIS shall acknowledge receipt of incoming UPDATE PDUs and RIB 2748 REFRESH PDUs within a period t[A] of their receipt. The 2749 acknowledgement may be accomplished by means of an UPDATE PDU or a 2750 RIB REFRESH PDU sent as outlined in item b above. However, if no 2751 UPDATE PDU or RIB REFRESH PDU is available to be sent, then a 2752 KEEPALIVE PDU may be sent instead, with its Sequence set to the 2753 lower window edge and its Acknowledgement, credit offered, and 2754 credit available set as in step b above. 2756 e) If a retained BISPDU remains unacknowledged after a period 2757 t[R], then it shall again be transmitted and again retained for 2758 possible retransmission. If, for a retained BISPDU, t[R] expires 2759 after n retransmissions, the local BIS shall issue a deactivate to 2760 close the BIS-BIS connection. 2762 Note 14: The value t[R] should be chosen to be greater than the 2763 value + 2*L, where L is the transmission delay over the 2764 subnetwork or virtual link between the pair of communicating 2765 BISs. 2767 f) The local BIS shall provide its peer BIS with sufficient credit 2768 to send further BISPDUs as long as the local BIS has resources to 2769 receive them. Therefore, if the local BIS receives a BISPDU whose 2770 credit available is equal to zero (that is, the peer BIS believes 2771 itself unable to send additional BISPDUs), then as soon as 2772 resources are available locally, the local BIS shall send an 2773 UPDATE PDU or a RIB REFRESH PDU, if appropriate. If not, then a 2774 KEEPALIVE PDU shall be sent. 2776 Note 15: An UPDATE PDU of minimal size will contain the 2777 Unfeasible Route Count field with a value of zero, but will not 2778 contain any path attributes or NLRI. Thus, its size will be 2779 only 33 octets. 2781 A KEEPALIVE PDU that advertises a non-zero value of credit offered 2782 in response to a received BISPDU with a credit available of zero 2783 shall be retransmitted within a period t[R] until the local BIS 2784 receives any in-sequence BISPDU that reports a non-zero value of 2785 credit available. If t[R] expires after n retransmissions, then 2786 the local BIS shall issue a deactivate to close the connection. 2788 g) A BIS that has sent a BISPDU with zero credit available to its 2789 neighbor shall respond within a period t[A] to a BISPDU from that 2790 neighbor that causes its upper window edge to be increased. The 2791 response shall consist of an UPDATE PDU or a RIB REFRESH PDU, if 2792 available, or a KEEPALIVE PDU, if not. 2794 h) A BIS that has not sent any BISPDU for a period t[I] shall send 2795 a KEEPALIVE PDU, with Sequence equal to the lower window edge, and 2796 Acknowledgement, credit offered, and credit available set as in 2797 step b above. 2799 Note 16: The condition (t[I]) >> (t[R]) should be satisfied, 2800 where t[I] is one third of the Hold Timer value. 2802 i) A BIS that has sent a BISPDU containing a credit offered of 2803 zero shall, as soon as its local resources become available to 2804 process additional BISPDUs from its peer, send an UPDATE PDU or 2805 RIB REFRESH PDU, if appropriate, containing a non-zero value of 2806 credit offered. If neither of these BISPDU types is appropriate, 2807 then a KEEPALIVE PDU shall be sent. 2809 j) The BIS shall issue a deactivate to close the BIS-BIS 2810 connection if no BISPDUs are received for a period equal to the 2811 value of Hold Time that is carried in the OPEN PDU. 2813 8.8. Version negotiation 2815 BIS peers may negotiate the version number of IDRP by making 2816 successive attempts to open a BIS-BIS connection, starting with the 2817 highest supported version number (contained in managed object 2818 version) and decrementing the number each time a connection attempt 2819 fails. The lack of support for a particular IDRP version is indicated 2820 by an IDRP ERROR PDU with error code "OPEN_PDU_Error" and an error 2821 subcode of "Unsupported_Version_Number". One BIS may determine the 2822 highest version number supported by the other BIS (as advertised in 2823 its OPEN PDU) by examining the "Data" field of the received IDRP 2824 ERROR PDU. No further retries should be attempted if the version 2825 number reaches zero. 2827 8.9. Checksum algorithm 2829 The checksums used in this document for authentication types 1 and 3 2830 shall be generated in accordance with the MD5 Message-Digest 2831 algorithm described in RFC1321 and MD5 HMAC described in RFCXXXX. 2832 For an input data stream of any length, this algorithm will generate 2833 a checksum that is 16 octets long. This algorithm shall be used to 2834 generate the checksums for both the BISPDUs and the RIBs. 2836 8.10. Routing information bases 2838 The Routing Information Base (RIB) within a BIS consists of three 2839 distinct parts: 2841 a) Adj-RIBs-In: The Adj-RIBs-In store routing information that has 2842 been learned from inbound UPDATE PDUs. Their contents represent 2843 routes that are available as input to the Decision Process. A BIS 2844 must support at least one Adj-RIB-In for each of its neighbor 2845 BISs; it may optionally support several Adj-RIBs-In for a given 2846 neighbor BIS. Within the set of Adj-RIBs-In associated with a 2847 given neighbor BIS, no two shall have the same RIB-Tag (see 8.10.1 2848 ). 2850 b) Loc-RIBs: The Loc-RIBs contain the local routing information 2851 that the BIS has selected by applying its local policies to the 2852 routing information contained in its Adj-RIBs-In. A BIS may 2853 support multiple Loc-RIBs. No two Loc-RIBs within a given BIS 2854 shall have the same RIB-Tag (see clause 8.10.1 ). Information in 2855 the Loc-RIB is used to build the Adj-RIBs-Out. 2857 c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the 2858 local BIS has selected for advertisement to its neighbors. A BIS 2859 must support at least one Adj-RIB-Out for each of its neighbor 2860 BISs; it may optionally support several Adj-RIBs-Out for a given 2861 neighbor BIS. Within the set of Adj-RIBs-Out associated with a 2862 given neighbor BIS, no two shall have the same RIB-Tag (see 8.10.1 2863 ). The routing information stored in the Adj-RIBs-Out will be 2864 carried in the local BIS's UPDATE PDUs and advertised to its 2865 neighbor BISs. 2867 In summary, the Adj-RIBs-In contain unprocessed routing information 2868 that has been advertised to the local BIS by its neighbors; the Loc- 2869 RIBs contain the routes that have been selected by the local BIS's 2870 Decision Process; and the Adj-RIBs-Out organize the selected routes 2871 for advertisement to specific neighbor BISs by means of the local 2872 BIS's UPDATE PDUs. 2874 Note 17: Although the conceptual model distinguishes between Adj- 2875 RIBs-In, Adj-RIBs-Out, and Loc-RIBs, this does neither implies nor 2876 requires that an implementation must maintain three separate 2877 copies of the routing information. The choice of implementation 2878 (for example, 3 copies of the information vs. 1 copy with 2879 pointers) is not constrained by this standard. 2881 8.10.1. Identifying an information base 2883 Each information base (a single Adj-RIB-In, a single Loc-RIB, or a 2884 single Adj-RIB-Out) has one and only one RIB-Tag associated with it. 2886 The managed object RIBTagsSet explicitly enumerates all the RIB-Tags 2887 that a BIS supports. Managed object RIBTagsSet shall not contain any 2888 pairs of RIB-Tags that are identical, thus assuring that each RIB-Tag 2889 is unambiguous within the BIS. 2891 All BISs located within a given routing domain shall support the same 2892 RIB-Tags: that is, the managed object RIB-TagsSet of every BIS within 2893 an RD shall list the same RIB-Tags. When a BIS receives an OPEN PDU 2894 from another BIS located in its own routing domain, it shall compare 2895 the information in the field RIB-TagsSet with the information in its 2896 local managed object RIBTagsSet. If they do not match, then the 2897 appropriate error handling procedure in 8.18.2 shall be followed. 2899 Each BIS shall support default information bases (Adj-RIBs-In, Adj- 2900 RIBs-Out, Loc-RIB, and FIB) that correspond to the null RIB-Tag. 2902 8.10.2. Use of the RIB REFRESH PDU 2904 The RIB REFRESH PDU can be used by a BIS to solicit a refresh of its 2905 Adj-RIBs-In by a neighbor BIS, or to send an unsolicited refresh to a 2906 neighbor BIS: 2908 a) Solicited Refresh 2910 A BIS may request a neighbor BIS to refresh one or more of the 2911 local BIS's Adj-RIBs-In by sending a RIB-REFRESH PDU that 2912 contains the OpCode for RIB-Refresh-Request and the RIB-Tags of 2913 the Adj-RIBs-In that it wants to be refreshed. 2915 When the neighbor BIS receives a RIB-REFRESH PDU with OpCode 2916 RIB-Refresh-Request, it shall send back a RIB-REFRESH PDU with 2917 OpCode RIB-Refresh-Start, followed by a sequence of UPDATE PDUs 2918 that contain the information in its Adj-RIBs-Out associated 2919 with the requesting BIS. The neighbor BIS shall indicate the 2920 completion of the refresh by sending a RIB-REFRESH PDU with 2921 OpCode RIB-Refresh-End. 2923 b) Unsolicited Refresh 2924 A BIS may initiate an unsolicited refresh by sending a RIB- 2925 REFRESH PDU with OpCode RIB-Request-Start, followed by a 2926 sequence of UPDATE PDUs that contain the information in its 2927 Adj-RIBs-Out that been advertised to a given BIS. The 2928 completion of the refresh shall be indicated by sending the 2929 RIB-REFRESH PDU with OpCode RIB-Refresh-End. 2931 When a BIS receives a RIB REFRESH PDU with OpCode 2 (RIB Refresh 2932 Start), it shall not change any of the routing information currently 2933 stored in the Adj-RIB-In which is identified by the FIB-Tag of the 2934 RIB REFRESH PDU until the refresh cycle has been completed or has 2935 been aborted. 2937 The BIS shall accumulate the routing information contained in all the 2938 UPDATE PDUs that are received in a completed refresh cycle. 2939 Completion of a refresh cycle is indicated by receipt of a RIB 2940 REFRESH PDU with OpCode 3 (RIB Refresh End). Then the BIS shall 2941 replace the previous routing information in the associated Adj-RIB-In 2942 with the routing information that was learned during the refresh 2943 cycle. 2945 Abortion of a refresh cycle is indicated by receipt of another RIB 2946 REFRESH PDU with OpCode 2 (RIB Refresh Start) before receipt of a RIB 2947 REFRESH PDU with OpCode 3 (RIB Refresh End). In this case, any 2948 routing information learned in the time between receipt of the two 2949 successive RIB Refresh Starts shall be discarded, and a new refresh 2950 cycle (triggered by receipt of the second RIB Refresh Start) shall 2951 begin. 2953 If the refreshing BIS receives a new RIB-Refresh-Request while it is 2954 in the middle of refresh (after sending RIB-REFRESH PDU with OpCode 2955 RIB-Refresh-Start, but before sending RIB-REFRESH PDU with OpCode 2956 RIB-Refresh-End), then the current refresh shall be aborted and the 2957 new refresh is initiated. 2959 8.11. Path attributes 2961 An UPDATE PDU that carries an NLRI field also carries a set of path 2962 attributes. An UPDATE PDU that does not carry any NLRI field shall 2963 not carry any path attributes. Path attributes are summarized in 2964 Table 3; their encoding is described in 7.3 2965 +-------------------------------------------------+ 2966 | Table 3. Path Attribute Characteristics | 2967 +----------------+--------------+------+----------+ 2968 | Attribute | Category | Type | Length | 2969 | | | Code | (octets) | 2970 +----------------+--------------+------+----------+ 2971 | LOCAL_PREF | well-known | 1 | 4 | 2972 | | discretionary| | | 2973 +----------------+--------------+------+----------+ 2974 |INCOMPLETE_PATH | well-known | 2 | 0 | 2975 | | discretionary| | | 2976 +----------------+--------------+------+----------+ 2977 | RD_PATH | well-known | 3 | variable | 2978 | | mandatory | | | 2979 +----------------+--------------+------+----------+ 2980 | NEXT_HOP | well-known | 4 | variable | 2981 | | discretionary| | | 2982 +----------------+--------------+------+----------+ 2983 | AGGREGATOR | optional | 5 | 32 | 2984 | | transitive | | | 2985 +----------------+--------------+------+----------+ 2986 | ATOMIC_AGGREG | well-known | 6 | 0 | 2987 | | discretionary| | | 2988 +----------------+--------------+------+----------+ 2989 | MULTI-EXIT | optional | 7 | 4 | 2990 | DISC | non-transitiv| | | 2991 +----------------+--------------+------+----------+ 2992 | RD_HOP_COUNT | well-known | 13 | 1 | 2993 | | mandatory | | | 2994 +----------------+--------------+------+----------+ 2995 | CAPACITY | well-known | 15 | 1 | 2996 | | discretionary| | | 2997 +----------------+--------------+------+----------+ 2998 | COMMUNITIES | well-known | 16 | variable | 2999 | | discretionary| | | 3000 +----------------+--------------+------+----------+ 3002 8.11.1. Categories of path attributes 3004 Path attributes fall into four categories: 3006 a) Well-known mandatory: these attributes must be recognized upon 3007 receipt by all BISs, and must be present in every UPDATE PDU 3009 b) Well-known discretionary: these attributes must be recognized 3010 upon receipt by all BISs, but are not necessarily present in an 3011 UPDATE PDU 3013 c) Optional transitive: these attributes need not be recognized 3014 upon receipt by all BISs, and are not necessarily present in an 3015 UPDATE PDU. If a given BIS does not recognize an optional 3016 transitive attribute, it must pass it on to other BISs 3018 d) Optional non-transitive: these attributes need not be 3019 recognized upon receipt by all BISs, and are not necessarily 3020 present in an UPDATE PDU. If it does not recognize an optional 3021 non-transitive attribute, a BIS shall ignore it and shall not 3022 include it in any of its own UPDATE PDUs. 3024 A BIS shall handle optional attributes in the following manner: 3026 a) If a route with an unrecognized optional transitive attribute 3027 is received and the route is to be propagated to other BISs, the 3028 optional transitive attribute must be propagated with the route, 3029 and the Partial bit in the Flag field of the attribute shall be 3030 set to 1. 3032 b) If a route with a recognized optional transitive attribute is 3033 received and the route is to be propagated to other BISs, the 3034 optional transitive attribute may or may not be propagated with 3035 the route, according to the definition of the attribute. If the 3036 attribute is propagated, then the local BIS shall not modify the 3037 value of the PARTIAL bit in the Flag field of the attribute. 3039 c) If a route with an unrecognized optional non-transitive 3040 attribute is received, the receiving BIS shall ignore the 3041 attribute and shall not propagate that attribute to any other BIS. 3042 However, it may propagate the remainder of the route: that is, the 3043 route without the unrecognized optional non-transitive attribute. 3045 d) If a route with a recognized optional non-transitive attribute 3046 is received and the route is to be propagated to other BISs, the 3047 optional transitive attribute may or may not be propagated with 3048 the route, according to the definition of the attribute. If the 3049 attribute is propagated, then the local BIS shall not modify the 3050 value of the PARTIAL bit in the Flag field of the attribute. 3052 BISs shall observe the following rules for attaching and updating the 3053 values of optional attributes: 3055 - New optional transitive attributes may be attached to the path 3056 information by any BIS in the path, and that BIS shall then set 3057 the PARTIAL bit in the attributes flag of its UPDATE PDU to 1. 3059 - The rules for attaching new non-transitive optional attributes 3060 depend on the nature of each specific attribute. The definition of 3061 each non-transitive optional attribute specifies such rules. 3063 - Any optional attribute may be updated by any BIS in its path. 3065 8.12. Path attribute usage 3067 The usage of each of IDRP's path attributes is described in the 3068 following clauses. 3070 8.12.1. LOCAL_PREF 3072 LOCAL_PREF is a well-known discretionary attribute that shall be 3073 included in all UPDATE PDUsthat a given BIS sends to the other BIS 3074 located in its own RD. A BIS shall calculate the degree of preference 3075 for each external route and include the degree of preference when 3076 advertising a route to BISs that are located in the same RD. The 3077 higher degree of preference should be preferred. A BIS shall use the 3078 degree of preference learned via LOCAL_PREF in its decision process 3079 (see section 8.15.1 ). 3081 A BIS shall not include this attribute in UPDATE PDUs that it sends 3082 to BISs located in adjacent RDs. If it is contained in an UPDATE PDU 3083 that is received from a BIS which is not located in the same RD as 3084 the receiving BIS, then this attribute shall be ignored by the 3085 receiving BIS. 3087 8.12.2. INCOMPLETE_PATH 3089 INCOMPLETE_PATH is a well-known discretionary attribute. It shall be 3090 recognized upon receipt by all BISs. It shall be included in each 3091 UPDATE PDU that reports either an RD_PATH attribute or Network Layer 3092 Reachability Information that has been learned by methods not 3093 described in this document. 3095 The INCOMPLETE_PATH attribute shall be generated by the RD that 3096 originates the associated routing information. If the INCOMPLETE_PATH 3097 attribute was present in a received UPDATE PDU, then it shall also be 3098 included in the UPDATE PDUs of all BISs that choose to propagate this 3099 information to other BISs. 3101 Note 24: Information obtained from the managed object internalSystems 3102 or obtained from UPDATE PDUs which do not contain the INCOMPLETE_PATH 3103 attribute has been learned by methods within IDRP's scope; however, 3104 manually configured reachability information for an RD which does not 3105 run IDRP is an example of information which is learned by means 3106 outside IDRP's scope. 3108 If a BIS selects a route which has been advertised with the 3109 INCOMPLETE_PATH attribute, it is possible that there may be 3110 undetected looping of routing information. Therefore, it is 3111 recommended that distribution of information not learned by the 3112 methods of IDRP be tightly controlled. Furthermore, a given RD may 3113 also enforce policies which prohibit any of its BISs from selecting 3114 routes which have the INCOMPLETE_PATH attribute associated with them. 3116 8.12.3. RD_PATH 3118 RD_PATH is a well-known mandatory attribute. It shall be present in 3119 every UPDATE PDU, and shall be recognized on receipt by all BISs. 3120 This attribute consists of a concatenation of path segments that 3121 identifies the routing domains and routing domain confederations 3122 through which this route has passed. The path segments can be 3123 RD_SETs, RD_SEQs, ENTRY_SEQs, or ENTRY_SETs. 3125 8.12.3.1. Generating an RD_PATH attribute 3127 When a BIS originates a route to destinations contained within its 3128 own routing domain or to destinations learned by means outside the 3129 protocol (see 7.3.1.2 ), it shall examine the information contained 3130 in its managed object rdcConfig to determine the ordering 3131 relationships among all the confederations of which the local routing 3132 domain is a member. The local BIS shall then construct an RD_PATH 3133 attribute as follows: 3135 a) If the local routing domain is a member of one or more 3136 confederations, the RD_PATH shall consist of an ENTRY_SEQ segment 3137 followed immediately by an RD_SEQ segment. The ENTRY_SEQ shall 3138 list the confederations, ordered as follows: 3140 1) If a confederation, RDC-B, is nested within another 3141 confederation, RDC-A, then the RDI of RDC-A shall precede that 3142 of RDC-B. 3144 2) The RDIs of overlapping confederations shall be listed in 3145 increasing order of the RDIs, as long as the order implied by 3146 any nesting relationships is maintained. For purposes of 3147 ordering, two RDIs are compared octet-by-octet from the left 3148 until differing octet values are found. The RDI with the lesser 3149 octet value (when treated as an unsigned integer) is considered 3150 to have the lesser RDI value. If there are two RDIs of 3151 different lengths, and the leading octets of the longer RDI are 3152 exactly the same as the octets of the (complete) shorter RDI, 3153 then the shorter RDI is considered to have the lesser value. 3155 The RD_SEQ shall list the RDI of the BIS's routing domain. 3157 b) If the local routing domain is not a member of any 3158 confederation, then the RD_PATH contains a single RD_SEQ segment 3159 that lists the RDI of the BIS's routing domain. 3161 8.12.3.2. Updating a received RD_PATH attribute 3163 The local BIS shall update the RD_PATH attribute of a route received 3164 from another BIS according to the following rules: 3166 a) If the route was received from a BIS located in the same 3167 routing domain as the local BIS, then the RD_PATH attribute shall 3168 not be updated. 3170 b) If the route was received from a BIS located in an adjacent 3171 routing domain, the local BIS shall determine if the route has 3172 entered any confederations (see 8.13.3 ), and it shall examine the 3173 information contained in its managed object rdcConfig to determine 3174 the ordering relationships among all such confederations. The 3175 local BIS shall then amend the RD_PATH attribute as follows: 3177 1) If the route has entered any confederations, the BIS shall 3178 append a path segment of type ENTRY_SEQ that lists all the 3179 newly entered confederations, ordered as follows: 3181 i) If a confederation, RDC-B, is nested within another 3182 confederation, RDC-A, then the RDI of RDC-A shall precede 3183 that of RDC-B. 3185 ii) The RDIs of overlapping confederations shall be listed 3186 in increasing order of the RDIs, as long as the order 3187 implied by any nesting relationships is maintained. For 3188 purposes of ordering, two RDIs are compared octet-by-octet 3189 from the left until differing octet values are found. The 3190 RDI with the lesser octet value (when treated as an unsigned 3191 integer) is considered to have the lesser RDI value. If 3192 there are two RDIs of different lengths, and the leading 3193 octets of the longer RDI are exactly the same as the octets 3194 of the (complete) shorter RDI, then the shorter RDI is 3195 considered to have the lesser value. 3197 The ENTRY_SEQ segment shall be followed immediately by an 3198 RD_SEQ segment that lists the RDI of the BIS's routing domain. 3200 2) If the route has not entered any confederations, the local 3201 BIS shall append a path segment of type RD_SEQ that lists the 3202 RDI of the BIS's routing domain. 3204 8.12.3.3. Advertising a route received from another BIS 3206 After receiving a route, a BIS will have modified its RD_PATH 3207 attribute in accordance with 8.12.3.2 ; and when a route is generated 3208 locally, the BIS will have created an RD_PATH attribute in accordance 3209 with 8.12.3.1 advertisement, the RD_PATH attribute of that route 3210 shall be amended as follows, based on the confederations which have 3211 been exited and on the nesting relationships among confederations of 3212 which the local BIS is a member (see managed object rdcConfig): 3214 a) If the adjacent BIS to which the route will be advertised can 3215 be reached without exiting any confederations, then no 3216 modification to the RD_PATH attribute shall be made. 3218 b) If the adjacent BIS to which the route will be advertised can 3219 only be reached by exiting one or more confederations, then the 3220 local BIS shall check the RD_PATH attribute for the presence of 3221 ENTRY_SEQ or ENTRY_SET path segments that contain the RDIs of the 3222 exited confederations. 3224 If there is any RDI of an exited confederation which is absent 3225 from all ENTRY_SEQ and ENTRY_SET segments, then the route is in 3226 error. The local BIS shall send an IDRP ERROR PDU to the BIS that 3227 advertised the route, reporting a Misconfigured_RDCs error. 3229 If two confederation, RDC-A and RDC-B, are listed in the same 3230 ENTRY_SEQ, and managed object rdcConfig indicates that RDC-B is 3231 nested within RDC-A, then the RDI of RDC-A shall precede that of 3232 RDC-B in the ENTRY_SEQ. If it does not, the local BIS shall send 3233 an IDRP ERROR to the BIS that advertised the route, reporting a 3234 Misconfigured_RDCs error. 3236 Otherwise, the local BIS shall scan the RD_PATH attribute from the 3237 back (right to left, starting at the highest numbered octet) 3238 looking for an ENTRY_SEQ or ENTRY_SET path segment that lists an 3239 exited confederation. Within a given ENTRY_SET or ENTRY_SEQ 3240 segment, the RDI for a given confederation can not be processed 3241 until the RDIs for all confederations nested within it have been 3242 processed. 3244 For each exited confederation (for example, the confederation 3245 whose RDI is "X"), the advertising BIS shall then update the 3246 RD_PATH of the route as follows: 3248 1) The entry for "X" shall be removed from the ENTRY_SEQ or 3249 ENTRY_SET segment 3251 2) If "X" is the only RDI contained in an ENTRY_SEQ or 3252 ENTRY_SET segment of the RD_PATH, then create a path segment of 3253 type RD_SEQ that lists "X" and insert it in front of the 3254 previous entry for "X". 3256 3) If the local BIS's routing domain is a member of other 3257 confederations besides "X" that are listed in the ENTRY_SEQ or 3258 ENTRY_SET segments of the RD_PATH, then: 3260 i) If "X" occurs in an ENTRY_SEQ or ENTRY_SET segment, and 3261 "X" is nested within none of the other confederations, then 3262 create an RD_SET that lists "X" and insert it in front of 3263 the first ENTRY_SEQ or ENTRY_SET segment that occurs in the 3264 RD_PATH. 3266 ii) If "X" occurs in an ENTRY_SEQ and "X" is nested within 3267 all the other confederations, then create a path segment of 3268 type RD_SEQ that lists "X" and insert it immediately in 3269 front of the previous entry for "X" 3271 iii) If "X" occurs in an ENTRY_SEQ and "X" is nested within 3272 some but not all of the other confederations, then create a 3273 path segment of type RD_SET that lists "X", and insert it 3274 immediately after the closest prior entry for any 3275 confederation in which "X" is nested. 3277 iv) If "X" occurs in an ENTRY_SET and "X" is nested within 3278 all the other confederations, then create a path segment of 3279 type RD_SET that lists "X" and insert it immediately in 3280 front of the previous entry for "X" 3282 v) If "X" occurs in an ENTRY_SET and "X" is nested within 3283 some but not all of the other confederations, then create a 3284 path segment of type RD_SET that lists "X", and insert it 3285 immediately after the the closest prior entry for any 3286 confederation in which "X" is nested. 3288 If the procedures call for the insertion of an RD_SET or an 3289 RD_SEQ between entries that are contained in a single ENTRY_SET 3290 or ENTRY_SEQ, then break the ENTRY_SET or ENTRY_SEQ into two 3291 segments of identical type and perform the insertion. For 3292 example, if it is necessary to insert RD_SET(X) between entries 3293 for "A" and "B", where "A" and "B" are contained in 3294 ENTRY_SEQ(H,J,A,B,C), the result would be: ENTRY_SEQ(H,J,A) 3295 RD_SET(X) ENTRY_SEQ(B,C). 3297 If, after applying these procedures, the ENTRY_SEQ or ENTRY_SET 3298 segment in which "X" originally occurred is empty, then that path 3299 segment shall be deleted, together with any subsequent path 3300 segments between itself and the next occurring ENTRY_SEQ or 3301 ENTRY_SET segment, or between itself and the end of the RD_PATH 3302 attribute if there is no subsequent ENTRY_SEQ or ENTRY_SET 3303 segment. 3305 8.12.4. NEXT_HOP 3307 NEXT_HOP is a well-known discretionary attribute. It shall be 3308 recognized upon receipt by all BISs. 3310 For purposes of defining the usage rules for this attribute, a 3311 subnetwork is transitive with respect to system reachability if all 3312 of the following conditions are true: 3314 a) Systems A, B, and C are all attached to the same subnetwork, 3316 b) When A can reach B directly, and B can reach C directly, it 3317 follows that A can reach C directly. 3319 Verification of the above conditions should be accomplished by means 3320 outside of IDRP. 3322 Consider three BISs attached to a fully connected transitive 3323 subnetwork, as shown in Figure 8: A and B share a BIS-BIS connection, 3324 B and C share a BIS-BIS connection, but A and C have no BIS-BIS 3325 connection between themselves. If C propagates an UPDATE PDU to B, 3326 then with respect to the UPDATE PDU advertised by B: 3328 +----------------------------------------------------------------------+ 3329 | | 3330 | +-----+ | 3331 | | B | | 3332 | +-----+ | 3333 | = | = | 3334 | BIS-BIS = | = BIS-BIS | 3335 | Connection = | = Connection | 3336 | = | = | 3337 | = | = | 3338 | = | = | 3339 | = | = | 3340 | +---+ | +---+ | 3341 | | A |--------+--------| C | | 3342 | +---+ +---+ | 3343 | | 3344 | nhop2 | 3345 | | 3346 +----------------------------------------------------------------------+ 3347 Figure 8. A Transitive Fully Connected Subnetwork 3349 - C is defined to be the source BIS 3351 - B is defined to be the first recipient BIS 3353 - A is defined to be the subsequent recipient BIS. 3355 In terms of these definitions, the following rules apply to the usage 3356 of the NEXT_HOP attribute: 3358 a) Generating the Attribute 3360 When a given BIS generates an UPDATE PDU: 3362 1) It may list its own Network Layer address and the SNPAs 3363 of subnetworks that connect itself to the remote BIS in the 3364 NEXT_HOP attribute of that UPDATE PDU. 3366 2) It may choose not to include a NEXT_HOP attribute in its 3367 UPDATE PDU. When the NEXT_HOP field is not present, it 3368 implies that the Network Layer address of the BIS that 3369 advertises the UPDATE PDU should be considered to be the 3370 Network Layer address of the next-hop BIS. 3372 b) Advertising Routing Information 3374 When a BIS chooses to advertise routing information learned 3375 from an UPDATE PDU: 3377 1) The BIS may choose to list its own Network Layer address 3378 and the SNPAs of subnetworks that connect itself to the 3379 remote BIS in the NEXT_HOP attribute of an UPDATE PDU that 3380 propagates the routing information 3382 2) The BIS may choose not to include a NEXT_HOP attribute in 3383 its UPDATE PDU. When the NEXT_HOP field is not present, it 3384 implies that the BIS that advertises the UPDATE PDU is also 3385 the next-hop BIS. 3387 3) If any condition listed below is not satisfied, then the 3388 recipient BIS shall not list the Network Layer address and 3389 SNPAs of the source BIS in its own UPDATE PDUs. If they are 3390 all satisfied, then instead of listing its own Network Layer 3391 address and SNPAs, the BIS may optionally list the Network 3392 Layer address and SNPAs of the source BIS (as contained in 3393 the UPDATE PDU received from the source BIS) when it 3394 propagates the information to a subsequent recipient BIS. 3395 The conditions are the following: 3397 ii) All three BISs (source, first recipient, and 3398 subsequent recipient) are located on a common subnetwork 3399 which is full-duplex and is transitive with respect to 3400 reachability of all three BISs. 3402 iii) The managed object routeServer is "true". 3404 iv) The first recipient and subsequent recipient are 3405 located in different routing domains. 3407 v) Advertisement of this route to the subsequent 3408 recipient BIS does not conflict with any of the path 3409 attributes that were contained in the UPDATE PDU from the 3410 source BIS. 3412 Note 25: The following observations should be noted with regard to 3413 the rules stated above: 3415 a) The rules do not remove the requirement that there must be a 3416 BIS-BIS connections between each pair of BISs located in the same 3417 routing domain. 3419 b) The contents of the NEXT_HOP attribute have no effect upon the 3420 contents of the RD_PATH attribute: that is, the RD_PATH attribute 3421 will always be used in accordance with 7.3.1.3 3423 c) If the Network Layer address and SNPAs are not available in an 3424 UPDATE PDU, then a BIS that receives it must learn them by means 3425 outside of this document. 3427 A BIS must never install a route with itself as the next hop. 3429 When a BIS advertises the route to a BIS located in its own domain, 3430 the advertising BIS should not modify the NEXT_HOP attribute 3431 associated with the route. 3433 When a BIS receives the route from an internal neighbor BIS, it may 3434 use the NEXT_HOP address as the forwarding address, provided that the 3435 address is on a common subnet with the local BIS. 3437 8.12.5. AGGREGATOR 3439 AGGREGATOR is an optional transitive attribute which may be included 3440 in updates which are formed by aggregation (see 8.16.2 ). A BIS which 3441 performs route aggregation may add the AGGREGATOR attribute which 3442 shall contain BIS's own RDI and IP address. 3444 8.12.6. ATOMIC_AGGREGATE 3446 ATOMIC_AGGREGATE is a well-known discretionary attribute. If a BIS, 3447 when presented with a set of overlapping routes from one of its peers 3448 (see 8.15.4 ), selects the less specific route without selecting the 3449 more specific one, then the local system shall attach the 3450 ATOMIC_AGGREGATE attribute to the route when propagating it to other 3451 BISs (if that attribute is not already present in the received less 3452 specific route). A BIS that receives a route with the 3453 ATOMIC_AGGREGATE attribute shall not remove the attribute from the 3454 route when propagating it to other BISs. A BIS that receives a route 3455 with the ATOMIC_AGGREGATE attribute shall not make any NLRI of that 3456 route more specific (as defined in 8.15.4 ) when advertising this 3457 route to other BISs. A BIS that receives a route with the 3458 ATOMIC_AGGREGATE attribute needs to be cognizant of the fact that the 3459 actual path to destinations, as specified in the NLRI of the route, 3460 while having the loop-free property, may traverse 3461 domains/confederations that are not listed in the RD_PATH attribute. 3463 8.12.7. MULTI-EXIT_DISC 3465 MULTI-EXIT_DISC is an optional non-transitive attribute. If the local 3466 BIS's managed object multiExit is "true", the BIS may use the 3467 attribute in its path selection algorithm. For example, a routing 3468 domain may choose to implement a policy which mandates that if all 3469 other path attributes are equal, the exit point with the lowest value 3470 of MULTI-EXIT_DISC should be preferred. 3472 Each BIS that is connected to an adjacent RD by one or more common 3473 subnetworks may generate a MULTI-EXIT_DISC attribute for each link 3474 connecting itself to an adjacent RD. The value of this attribute is a 3475 local matter, which will be determined by the policies of the RD in 3476 which the originating BIS is located. 3478 A BIS that generates a value for this attribute may distribute it to 3479 all neighboring BISs which are located in adjacent RDs. 3481 If a MULTI-EXIT_DISC attribute is received from a BIS located in an 3482 adjacent RD, then the receiving BIS may distribute this attribute to 3483 all other BISs located in its own RD. However, the receiving BIS 3484 shall not re-distribute the attribute to any BISs which are not 3485 located within its own RD. 3487 8.12.8. RD_HOP_COUNT 3489 This is a well-known mandatory attribute whose usage is as follows: 3491 a) The initial value of this attribute is 0. 3493 b) Before sending an UPDATE PDU to a BIS located in an adjacent 3494 routing domain, a BIS shall increment the value of this attribute 3495 by 1, and shall place the result in the RD_HOP_COUNT field of the 3496 outbound UPDATE PDU. 3498 c) A BIS shall not increment the value of this attribute when it 3499 sends an UPDATE PDU to another BIS located in its own routing 3500 domain. 3502 d) This attribute may be modified by administrative proceedures. 3504 8.12.9. CAPACITY 3506 This is a well-known discretionary attribute that is used to denote 3507 the traffic handling capacity of the RD_PATH listed in the same 3508 UPDATE PDU. Different routing domains may use different values for 3509 this attribute: thus, the attribute shall deal in relative 3510 capacities. 3512 Note 27: The semantics of this attribute must be agreed on a 3513 bilateral basis using mechnaisms outside the scope of this document 3514 before a BIS-BIS connection is established. 3516 The value of capacity that is associated with a given routing domain 3517 is contained in managed object capacity. 3519 If a BIS advertises a route whose destinations are located in its own 3520 routing domain, then the originating BIS shall include this attribute 3521 in its outbound UPDATE PDUs, and its value shall be equal to that of 3522 managed object capacity. 3524 If a BIS redistributes a route and the route includes the CAPACITY 3525 attribute, the attribute shall reflect the lower of the following two 3526 quantities: the value of the CAPACITY attribute contained in the 3527 UPDATE PDU that advertised the route, or the value of local managed 3528 object capacity. 3530 8.13. Routing domain confederations 3532 Formation of an RDC is done via a private arrangement between its 3533 members without any need for global coordination; the methods for 3534 doing so are not within the scope of this document. 3536 From the outside, an RDC looks similar to a single routing domain: 3537 for example, it has an identifier which is an RDI. Other RDs can 3538 develop policies with respect to the confederation as a whole, as 3539 opposed to the individual RDs that are members of the confederation. 3540 Confederations can be disjoint, nested, or overlapping (see 6 ). 3542 8.13.1. RDC policies 3544 Each RD within a confederation may have its own set of policies; that 3545 is, different RDs in the same confederation can have different 3546 policies. 3548 Since a confederation appears to the external world as if it were an 3549 individual RD, IDRP's loop detection methods will detect routing 3550 information loops through a given confederation. In particular, a 3551 route which leaves the confederation and then later re-enters it will 3552 be detected as a loop: thus, a route between two RDs that are members 3553 of the same confederation will be constrained to remain within that 3554 confederation. 3556 8.13.2. RDC configuration information 3558 Each BIS that participates in one or more RDCs must be aware of the 3559 RDIs of all confederations of which it is a member, and it must know 3560 the partial order which prevails between these confederations: that 3561 is, it must know the nesting and overlap relationships between all 3562 confederations to which it belongs. This information shall be 3563 contained in managed object rdcConfig, which consists of a list of 3564 confederation RDIs and the partial order that prevails among those 3565 confederations. 3567 Since RDCs are formed via private arrangement between their members, 3568 the partial order of a given confederation is a local matter for that 3569 confederation, and bears no relationship to the partial orders that 3570 may prevail in different confederations. The RDI of its own routing 3571 domain is contained in managed object localRDI, as defined in 8.3 3573 8.13.3. Detecting confederation boundaries 3575 A given BIS can tell which confederations are common to itself and an 3576 adjacent BIS by comparing information obtained from the Confed-IDs 3577 field of the adjacent BIS's OPEN PDU with the local BIS's rdcConfig 3578 managed object. This knowledge determines when an outbound UPDATE PDU 3579 exits a given confederation and when an inbound UPDATE PDU enters a 3580 given confederation: 3582 Exiting a Confederation: An UPDATE PDU sent by a given BIS to an 3583 adjacent BIS is defined to have exited all those confederations 3584 whose RDIs are present in the advertising BIS's rdcConfig managed 3585 object but were not reported in the Confed-IDs field of the 3586 adjacent BIS's OPEN PDU. 3588 Entering a Confederation: An UPDATE PDU received from an adjacent 3589 BIS is defined to have entered all those confederations whose RDIs 3590 are present in the receiving BIS's rdcConfig managed object but 3591 were not reported in the Confed-IDs field of the sending BIS's 3592 OPEN PDU. 3594 8.14. Update-Receive process 3596 The Update-Receive process is initiated when an UPDATE PDU with no 3597 errors is received while the FSM is in the ESTABLISHED state. When 3598 this occurs, the BIS shall update the appropriate Adj-RIB-In. 3600 For each route (either feasible or unfeasible), the Adj-RIB-In is 3601 identified by the FIB-Tag carried in the UPDATE PDU. The actions to 3602 be taken for each route are: 3604 a) If the UPDATE PDU contains a non-empty WITHDRAWN ROUTES field, 3605 the previously advertised feasible routes associated with the 3606 NLRIs contained in this field shall be removed from the Adj-RIB- 3607 In. The BIS shall run its Decision Process since the previously 3608 advertised route is no longer available for use. 3610 b) If the UPDATE PDU contains feasible routes, they shall each be 3611 placed in the appropriate Adj-RIB-In, and the following additional 3612 actions shall be taken for each route: 3614 1) If its NLRI is identical to those of a route currently 3615 stored in the Adj-RIB-In, then the new route shall replace the 3616 older route in the Adj-RIB-In, thus implicitly withdrawing the 3617 older route from service. The BIS shall run its Decision 3618 Process since the older route is no longer available for use. 3620 2) If the new route is an overlapping route that is more 3621 specific (see 8.15.4 ) than an earlier route contained in the 3622 Adj-RIB-In, and the path attributes of the new route differ 3623 from those of the earlier route, the BIS shall run its Decision 3624 Process since the more specific route has implicitly made a 3625 portion of the less specific route unavailable for use. 3627 3) If the new route has identical path attributes to an earlier 3628 route contained in the Adj-RIB-In, and is more specific (see 3629 8.15.4 ) than the earlier route, no further actions are 3630 necessary. 3632 4) If a new route has different NLRI from any of the routes 3633 currently in the Adj-RIB-In, it shall be placed in the Adj- 3634 RIB-In. 3636 5) If a new route is an overlapping route that is less specific 3637 (see 8.15.4 ) than an earlier route in an Adj-RIB-In, the BIS 3638 shall place the new route in the appropriate Adj-RIB-In. The 3639 earlier, more specific route remains unaffected. 3641 8.15. Decision process 3643 The Decision Process selects routes for subsequent advertisement by 3644 applying the policies in its Policy Information Base to the routes 3645 stored in its Adj-RIBs-In. The output of the Decision Process is the 3646 set of routes that will be advertised to adjacent BISs; the selected 3647 routes will be stored in the local BIS's Loc-RIBs and Adj-RIBs-Out. 3649 The selection process is formalized by defining a function that takes 3650 the attributes of a given route as an argument and returns a non- 3651 negative integer denoting the degree of preference for the route. 3652 The function that calculates the degree of preference for a given 3653 route shall not use as its inputs any of the following: the existence 3654 of other routes, the non-existence of other routes, or the path 3655 attributes of other routes. Route selection then consists of 3656 individual application of the degree of preference function to each 3657 feasible route, followed by the choice of the one with the highest 3658 degree of preference. 3660 Routes that could form routing loops must be ignored by the Decision 3661 Process. Therefore, any route that was a) received from a BIS located 3662 in an adjacent routing domain and b) contains in its RD_PATH 3663 attribute a path segment of type RD_SEQ or RD_SET that contains the 3664 RDI of the local routing domain or any RDC of which the local RD is a 3665 member is unfeasible, and shall be discarded by the Decision Process. 3667 IDRP does not require a universally agreed-upon metric to exist 3668 between multiple RDs. Instead, IDRP allows each RD to apply its own 3669 set of criteria for route selection, as determined by its local PIB. 3671 The Decision process operates on routes contained in each Adj-RIB-In, 3672 and is responsible for: 3674 - selection of routes to be advertised to BISs located in local 3675 BIS's routing domain 3677 - selection of routes to be advertised to BISs located in adjacent 3678 routing domains 3680 - route aggregation and route information reduction 3682 The Decision process takes place in three distinct phases, each 3683 triggered by a different event: 3685 a) Phase 1 is responsible for calculating the degree of preference 3686 for each route received from a BIS located in an adjacent routing 3687 domain, and for advertising to the other BISs in the local Routing 3688 Domain the routes that have the highest degree of preference for 3689 each distinct destination. 3691 b) Phase 2 is invoked on completion of Phase 1. It is responsible 3692 for choosing the best route out of all those available for each 3693 distinct destination, and for installing each chosen route into 3694 the appropriate Loc-RIB. 3696 c) Phase 3 is invoked after the Loc-RIB has been modified. It is 3697 responsible for disseminating routes in the Loc-RIB to each 3698 adjacent BIS located in an adjacent routing domain, according to 3699 the policies contained in the PIB. Route aggregation, information 3700 reduction and the modification of QOS path attributes can 3701 optionally be performed within this phase. 3703 8.15.1. Phase 1: calculation of degree of preference 3705 The Phase 1 decision function shall be invoked whenever the local BIS 3706 receives an UPDATE PDU from a neighbor BIS that advertises a new 3707 route, a replacement route, or a withdrawn route. 3709 The Phase 1 decision function is a separate process which completes 3710 when it has no further work to do. 3712 The Phase 1 decision function shall be blocked from running while the 3713 Phase 2 decision function for the same RIB-Tag is in process. 3715 The Phase 1 decision function shall lock an Adj-RIB-In prior to 3716 operating on any route contained within it, and shall unlock it after 3717 operating on all new or unfeasible routes contained within it. 3719 For each newly received or replacement feasible route, the local BIS 3720 shall determine a degree of preference as follow. If the route is 3721 learned from a BIS in the local RD, the value of the LOCAL_PREF 3722 attribute shall be taken as the degree of preference. If the route is 3723 learned from a BGP speaker in a neighboring autonomous system, then 3724 the degree of preference shall be computed based on preconfigured 3725 policy information. The exact nature of this policy information and 3726 the computation involved is a local matter. After a degree of 3727 preference is determined, the local BIS shall run the internal update 3728 process of 8.15.7 to select and advertise the most preferable routes. 3730 8.15.2. Phase 2: route selection 3732 The Phase 2 decision function shall be invoked on completion of Phase 3733 1. The Phase 2 function is a separate process which completes when it 3734 has no further work to do. The Phase 2 process shall consider all 3735 routes that are present in the Adj-RIBs-In, including those received 3736 from BISs located in its own routing domain and those received from 3737 BISs located in adjacent routing domains. 3739 The Phase 2 decision function shall be blocked from running while the 3740 Phase 3 decision function is in process. The Phase 2 function shall 3741 lock all Adj-RIBs-In with the RIB-Tag associated with this instance 3742 of the process prior to commencing its function, and shall unlock 3743 them on completion. 3745 For each set of destinations for which a feasible route exists in the 3746 Adj-RIBs-In identified by the RIB-Tag on which this instance of the 3747 function operates, the local BIS shall identify the route that has: 3749 a) the highest degree of preference of any route to the same set 3750 of destinations, or 3752 b) is the only route to that destination, or 3754 c) is selected as a result of the Phase 2 tie breaking rules 3755 specified in 95 3757 The local BIS shall then install that route in the Loc-RIB, replacing 3758 any route to the same destination that is currently held in the Loc- 3759 RIB. The local BIS shall determine the immediate next hop to the 3760 address depicted by the NEXT_HOP attribute of the selected route by 3761 performing a lookup in the intra-domain routing and selecting one of 3762 the possible paths in the intra-domain routing. This immediate next 3763 hop shall be used when installing the selected route in the Loc-RIB. 3764 If the route to the address depicted by the NEXT_HOP attribute 3765 changes such that the immediate next hop changes, route selection 3766 should be recalculated as specified above. 3768 If a route copied to a Loc-RIB does not have a NEXT_HOP path 3769 attribute, then the local BIS shall add that attribute to the entry 3770 in the Loc-RIB. The value of the attribute shall be the Network Layer 3771 address of the adjacent BIS from which the route was received. 3773 Unfeasible routes shall be removed from the Loc-RIB, and 3774 corresponding unfeasible routes shall then be removed from the Adj- 3775 RIBs-In. 3777 Note 28: The decision process should not select a route to 3778 destinations located within the local routing domain if that route 3779 would exit the local routing domain and later re-enter it. Such 3780 routes would be rejected by other RDs due to the existence of an RD- 3781 loop. 3783 8.15.2.1. Breaking ties (phase 2) 3785 In its Adj-RIBs-In a BIS may have several routes to the same 3786 destination that have the same degree of preference. The local BIS 3787 can select only one of these routes for inclusion in the associated 3788 Loc-RIB. The local BIS considers all equally preferable routes, both 3789 those received from BISs located in adjacent RDs, and those received 3790 from other BISs located in the local BIS's own RD. 3792 The following tie-breaking procedure assumes that for each candidate 3793 route all the BGP speakers within an autonomous system can ascertain 3794 the cost of a path (interior distance) to the address depicted by the 3795 NEXT_HOP attribute of the route. Ties shall be broken according to 3796 the following algorithm: 3798 a) If the local BIS is configured to take into account 3799 MULTI_EXIT_DISC, and the candidate routes differ in their 3800 MULTI_EXIT_DISC attribute, select the route that has the lowest 3801 value of the MULTI_EXIT_DISC attribute. If the local BIS is 3802 configured to take into account MULTI_EXIT_DISC, but that 3803 attribute is not present, a locally defined "default" 3804 MULTI_EXIT_DISC may be assumed as a basis for performing tie- 3805 breaking. 3807 b) Otherwise, if the local BIS can ascertain the cost of a path to 3808 the entity depicted by the NEXT_HOP attribute of the candidate 3809 route, select the route with the lowest cost (interior distance) 3810 to the entity depicted by the NEXT_HOP attribute of the route. If 3811 there are several routes with the same cost, then the tie-breaking 3812 shall be broken as follows: 3814 - if at least one of the candidate routes was advertised by the 3815 BIS in an adjacent RD, select the route that was advertised by 3816 the BIS in an adjacent RD whose IDRP Identifier has the lowest 3817 value among all other BIS in adjacent RDs; 3819 - otherwise, select the route that was advertised by the BIS 3820 whose IDRP Identifier has the lowest value. 3822 8.15.3. Phase 3: route dissemination 3824 The Phase 3 decision function shall be invoked on completion of Phase 3825 2, or when any of the following events occur: 3827 a) when routes in a Loc-RIB to local destinations have changed 3829 b) when locally generated routes with the INCOMPLETE_PATH 3830 attribute (that is, routes learned by means outside of IDRP) have 3831 changed 3833 c) when a new BIS-BIS connection has been established 3835 d) when directed to do so by system management. 3837 The Phase 3 function is a separate process which completes when it 3838 has no further work to do. 3840 The Phase 3 Routing Decision function shall be blocked from running 3841 while the Phase 2 decision function is in process. 3843 All routes in the Loc-RIB shall be processed into a corresponding 3844 entry in the associated Adj-RIBs-Out and FIBs (which are identified 3845 by the same RIB-Tag), replacing the current entries., The path 3846 attributes are updated in accordance with the appropriate subclause 3847 of 8.12 8.16 - 96 ) may optionally be applied. Routes with identical 3848 NLRI extracted from the same Loc-RIB shall always be aggregated 3849 before being copied to an Adj-RIB-Out, and may be aggregated with 3850 other routes according to the local Routing Policy. Every FIB shall 3851 have an entry for every destination for which a route exists in a 3852 Loc-RIB. 3854 A locking scheme should be implemented to prevent simultaneous access 3855 to an FIB by both the phase 3 function and forwarding engine. The 3856 phase 3 function should first lock an FIB before entering, replacing 3857 or deleting an entry, and then unlock that FIB once the operation is 3858 complete. 3860 When the updating of the Adj-RIBs-Out and the FIBs is complete, the 3861 local BIS shall run the external update process of 97 3863 8.15.4. Overlapping routes 3865 A BIS may transmit routes with overlapping NLRI to another BIS. NLRI 3866 overlap occurs when a set of destinations are identified in non- 3867 matching multiple routes, all of which have the same set of FIB-Tags. 3868 Since IDRP encodes NLRI using prefixes, overlaps will always exhibit 3869 subset relationships. A route describing a smaller set of 3870 destinations (a longer prefix) is said to be more specific than a 3871 route describing a larger set of destinations (a shorter prefix); 3872 similarly, a route describing a larger set of destinations (a shorter 3873 prefix) is said to be less specific than a route describing a smaller 3874 set of destinations (a longer prefix). 3876 When overlapping routes are present in the same Adj-RIB-In, the more 3877 specific routes shall take precedence, in order from most specific to 3878 least specific. 3880 This precedence relationship effectively decomposes less specific 3881 routes into two parts: 3883 - a set of destinations described only by the less specific route, 3884 and 3886 - a set of destinations described by the overlap of the less 3887 specific and the more specific routes 3889 The set of destinations described by the overlap represent a portion 3890 of the less specific route that is feasible, but is not currently in 3891 use. If a more specific route is later withdrawn, the set of 3892 destinations described by the overlap will still be reachable using 3893 the less specific route. 3895 If a BIS receives overlapping routes from a given neighbor, the 3896 Decision Process shall not simultaneously reject the more specific 3897 route from neighbor BIS (A) and install A's less specific route 3898 unless the contents of the local BIS's Adj-RIBs-Out and FIBs insure 3899 that NPDUs with destinations listed in the NLRI of A's more specific 3900 route can not be forwarded to the neighbor BIS (A). 3902 Therefore, when presented with overlapping routes from a given 3903 neighbor BIS (A), the local BIS could select any of the following 3904 options, all of which satisfy the criterion stated above: 3906 a) Install both the less specific and more specific routes 3907 received from the given neighbor (A) 3909 b) Install the more specific route received from the given 3910 neighbor (A) and reject A's less specific route 3911 c) Install the non-overlapping part of the less specific and more 3912 specific routes received from the given neighbor (A) 3914 d) Install a route formed by the aggregation of the less specific 3915 and the more specific route received from the given neighbor (A) 3917 e) Install the less specific route received from the given 3918 neighbor (A), and also install another route received from a 3919 different neighbor (B) that is simultaneously: 3921 1) more specific than A's less specific route, and 3923 2) less specific than A's more specific route. 3925 f) Install neither of the routes received from A. 3927 8.15.5. Interaction with update process 3929 Since the Adj-RIBs-In are used both to receive inbound UPDATE PDUs 3930 and to provide input to the Decision Process, care must be taken that 3931 their contents are not modified while the Decision Process is 3932 running. That is, the input to the Decision Process shall remain 3933 stable while a computation is in progress. 3935 Two examples of approaches that could be taken to accomplish this: 3937 a) The Decision Process can signal when it is running. During this 3938 time, any incoming UPDATE PDUs will be queued and will not be 3939 written into the Adj-RIBs-In. If more UPDATE PDUs arrive than can 3940 be fit into the allotted queue, they will be dropped and will not 3941 be acknowledged. 3943 b) A BIS can maintain two copies of the Adj-RIBs-In - one used by 3944 the Decision Process for its computation (call this the Comp-Adj- 3945 RIB) and the other to receive inbound UPDATE PDUs (call this the 3946 Holding-Adj-RIB). Each time the Decision begins a new computation, 3947 the contents of the Holding-Adj-RIB will be copied to the Comp- 3948 Adj-RIB: that is, the a snapshot of the Comp-Adj-RIB is used as 3949 the input for the Decision Process. The contents of the Comp-Adj- 3950 RIB remain stable until a new computation is begun. 3952 The advantage of the first approach is that it takes less memory; the 3953 advantage of the second is that inbound UPDATE PDUs will not be 3954 dropped. This document does not mandate the use of either of these 3955 methods. Any method that guarantees that the input data to the 3956 Decision Process will remain stable while a computation is in 3957 progress and that is consistent with the conformance requirements of 3958 this document may be used. 3960 8.15.6. Update-Send process 3962 The Update-Send process is responsible for advertising BISPDUs to 3963 adjacent BISs. For example, it distributes the routes chosen by the 3964 Decision Process to other BISs which may be located in either the 3965 same RD or an adjacent RD. Rules for information exchange between BIS 3966 located in different routing domains are given in 97 ; rules for 3967 information exchange between BIS located in the same domain are given 3968 in 8.15.7 3970 Distribution of reachability information between a set of BISs, all 3971 of which are located in the same routing domain, is referred to as 3972 internal distribution. All BISs located in a single RD must present 3973 consistent reachability information to adjacent RDs, thus requiring 3974 that they have consistent routing and policy information among them. 3976 Note 29: This requirement on consistency does not preclude an RD from 3977 distributing different reachability information to each of its 3978 adjacent routing domains. It does mean that all of a domain's BISs 3979 which are attached to a given adjacent domain must provide identical 3980 reachability to that domain. 3982 When this protocol is run between BISs located in different routing 3983 domains, the communicating BISs must be located in adjacent routing 3984 domains - that is, they must be attached to a common subnetwork. 3986 8.15.7. Internal updates 3988 The internal update process is concerned with the distribution of 3989 routing information to BISs located in the local BIS's own routing 3990 domain. Each BIS selects the most preferable route, if any, that it 3991 has received from a BIS in an adjacent routing domain, and 3992 distributes that route to every other BIS in its own routing domain. 3993 This process ensures that all BISs in a routing domain will select 3994 the same set of routes. 3996 The following procedures shall be applied separately for each set of 3997 FIB-Tags supported by the BIS: 3999 a) When a BIS receives an UPDATE PDU from another BIS located in 4000 its own routing domain, the receiving BIS shall not re-distribute 4001 the routing information contained in that UPDATE PDU to other BISs 4002 located in its own routing domain. 4004 b) When a BIS receives a new feasible route from a BIS in an 4005 adjacent routing domain, it shall advertise that route to all 4006 other BISs in its routing domain by means of an UPDATE PDU if any 4007 of the following conditions occur: 4009 1) the degree of preference assigned to the newly received 4010 route by the local BIS is higher than the degrees of 4011 preference that the local BIS has assigned to other routes - 4012 with the same destinations and the same FIB-Tag - that have 4013 been received from BISs in adjacent routing domains. 4015 2) there are no other routes - with the same destinations and 4016 the same FIB-Tag - that have been received from BISs in 4017 adjacent routing domains. 4019 3) the newly received route is selected as a result of 4020 breaking a tie between several routes that were received from 4021 BISs in adjacent routing domains and that have the highest 4022 degree of preference, the same destinations, and the same FIB- 4023 Tag (see 8.15.7.1 ). 4025 c) When a BIS receives an UPDATE PDU with a non-empty WITHDRAWN 4026 ROUTES field, it shall remove from its Adj-RIBs-In all routes 4027 whose NLRIs was carried in this field. The BIS shall take the 4028 following additional steps: 4030 1) if the corresponding feasible route had not been previously 4031 advertised, then no further action is necessary 4033 2) if the corresponding feasible route had been previously 4034 advertised, then: 4036 i) if a new route is selected for advertisement that has 4037 the same FIB-Tag and NLRI as the unfeasible route, then the 4038 local BIS shall advertise the replacement route 4040 ii) if a replacement route is not available for 4041 advertisement, then the BIS shall include the NLRI of the 4042 unfeasible route in the WITHDRAWN ROUTES field of an UPDATE 4043 PDU, and shall send this PDU to each neighbor BIS to whom it 4044 had previously advertised the corresponding feasible route. 4046 All feasible routes which are advertised shall be placed in the 4047 appropriate Adj-RIB-Out, and all unfeasible routes which are 4048 advertised shall be removed from the Adj-RIBs-Out. 4050 8.15.7.1. Breaking ties (internal updates) 4052 If a local BIS has connections to several BISs in adjacent domains, 4053 there will be multiple Adj-RIBs-In associated with these neighbors. 4054 These Adj-RIBs-In might contain several equally preferable routes to 4055 the same destination, all of which have the same FIB-Tag an all of 4056 which were advertised by BISs located in adjacent routing domains. 4057 The local BIS shall select one of these routes, according to the 4058 following rules: 4060 a) If all candidate routes contain the MULTI-EXIT_DISC attribute, 4061 the candidate routes differ only in their NEXT_HOP and MULTI- 4062 EXIT_DISC attributes, and the local BIS's managed object Multiexit 4063 is TRUE, select the route that has the lowest value of the MULTI- 4064 EXIT_DISC attribute. 4066 b) If the local system can ascertain the cost of a path to the 4067 entity depicted by the NEXT_HOP attribute of the candidate route, 4068 select the route with the lowest cost. 4070 c) In all other cases, select the route that was advertised by the 4071 BIS whose IDRP Identifier has the lowest value. 4073 8.15.8. External updates 4075 The external update process is concerned with the distribution of 4076 routing information to BISs located in adjacent routing domains. As 4077 part of the Phase 3 route selection process, the BIS has updated its 4078 Adj-RIBs-Out and its FIBs. All newly installed routes and all newly 4079 unfeasible routes for which there is no replacement route shall be 4080 advertised to BISs located in adjacent routing domains by means of 4081 UPDATE PDUs. 4083 Any routes in the Loc-RIB marked as infeasible shall be removed. 4084 Changes to the reachable destinations within its own RD shall also be 4085 advertised in an UPDATE PDU. 4087 However, advertisement of a given UPDATE PDU shall not violate any 4088 distribution constraint imposed by the path attributes of the route 4089 contained therein. 4091 A BIS shall not propagate an UPDATE PDU that contains routes with 4092 FIB-Tag that was not listed in the RIB-TagsSet field of the neighbor 4093 BIS's OPEN PDU. If such routes are advertised, it will cause the 4094 BIS-BIS connection to be closed, as described in 8.18.3 4096 8.15.9. Controlling routing traffic overhead 4098 The inter-domain routing protocol constrains the amount of routing 4099 traffic (that is, BISPDUs) in order to limit both the link bandwidth 4100 needed to advertise BISPDUs and the processing power needed by the 4101 Decision Process to digest the information contained in the BISPDUs. 4103 8.15.9.1. Frequency of route advertisement 4105 The managed object minRouteAdvertisementInterval determines the 4106 minimum amount of time that must elapse between advertisements of 4107 routes to a particular destination from a single BIS. This rate 4108 limiting procedure applies on a per-destination basis, although the 4109 value of minRouteAdvertisementInterval is set on a per-BIS basis. 4111 Two UPDATE PDUs sent from a single BIS that advertise feasible routes 4112 to some common set of destinations received from BISs in other 4113 routing domains must be separated in time by at least 4114 minRouteAdvertisementInterval. For example, any technique that 4115 ensures that the separation will be between one and two times the 4116 value minRouteAdvertisementInterval is acceptable. 4118 Since fast convergence is needed within an RD, this procedure does 4119 not apply for routes received from other BISs in the same routing 4120 domain. To avoid long-lived black holes, the procedure does not apply 4121 to the explicit withdrawal of unfeasible routes (that is, routes 4122 whose NLRI is listed in the Withdrawn Routes field of an UPDATE PDU). 4124 This procedure does not limit the rate of route selection, but only 4125 the rate of route advertisement. If new routes are selected multiple 4126 times while awaiting the expiration of minRouteAdvertisementInterval, 4127 the last route selected shall be advertised at the end of 4128 minRouteAdvertisementInterval. 4130 8.15.9.2. Frequency of route origination 4132 The architectural constant MinRDOriginationInterval determines the 4133 minimum amount of time that must elapse between successive 4134 advertisements of UPDATE PDUs that report changes within the 4135 advertising BIS's own routing domain. 4137 8.15.9.3. Jitter 4139 To minimize the likelihood that the distribution of BISPDUs by a 4140 given BIS will contain peaks, jitter should be applied to the timers 4141 associated with minRouteAdvertisementInterval and 4142 MinRDOriginationInterval. A given BIS shall apply the same jitter to 4143 each of these quantities regardless of the destinations to which the 4144 updates are being sent: that is, jitter will not be applied on a "per 4145 peer" basis. 4147 The amount of jitter to be introduced shall be determined by 4148 multiplying the base value in the appropriate managed object by a 4149 random factor which is uniformly distributed in the range from 1-J to 4150 1, where J is the value of the architectural constant Jitter. The 4151 result shall be rounded up to the nearest 100 millisecond increment. 4153 8.16. Efficient organization of routing information 4155 Having selected the routing information which it will advertise, a 4156 BIS may avail itself of several methods to organize this information 4157 in an efficient manner. 4159 8.16.1. Information reduction 4161 Information reduction may imply a reduction in granularity of policy 4162 control - after information is collapsed, the same policies will 4163 apply to all destinations and paths in the equivalence class. 4165 The Decision Process may optionally reduce the amount of information 4166 that it will place in the Adj-RIBs-Out by any of the following 4167 methods: 4169 a) Network Layer Reachability Information: 4171 Destination addresses can be represented as address prefixes. 4172 In cases where there is a correspondence between the address 4173 structure and the systems under control of a routing domain 4174 administrator, it will be possible to reduce the size of the 4175 network layer reachability information that is carried in the 4176 UPDATE PDUs. 4178 b) RD_PATHS: 4180 RD path information can be represented as ordered RD-SEQUENCES 4181 or unordered RD_SETs. RD_SETs are used in the route aggregation 4182 algorithm described in 8.16.2 They reduce the size of the 4183 RD_PATH information by listing each RDI only once, regardless 4184 of how many times it may have appeared in the multiple RD_PATHS 4185 that were aggregated. 4187 An RD_SET implies that the destinations listed in the NLRI can 4188 be reached through paths that traverse at least some of its 4189 constituent RDs. RD_SETs provide sufficient information to 4190 avoid routing loops; however, their use may prune potentially 4191 useful paths, since such paths are no longer listed 4192 individually as in the form of RD_SEQUENCES. In practice this 4193 is not likely to be a problem, since once an NPDU arrives at 4194 the edge of a group of RDs, the BIS at that point is likely to 4195 have more detailed path information and can distinguish 4196 individual paths to destinations. 4198 8.16.2. Aggregating routing information 4200 Aggregation is the process of combining the characteristics of 4201 several different routes (or components of a route such as an 4202 individual path attribute) in such a way that a single route can be 4203 advertised. Aggregation can occur as part of the decision process to 4204 reduce the amount of information that will be placed in the Adj- 4205 RIBs-Out. For example, at the boundary of a routing domain 4206 confederation an exit BIS can aggregate several intra-confederation 4207 routes into a single route that will be advertised externally. 4209 Aggregation reduces the amount of information that BISs must store 4210 and exchange with each other. Routes can be aggregated by applying 4211 the following procedures separately to path attributes of like type 4212 and to the NLRI information. 4214 8.16.2.1. Route aggregation 4216 Several routes shall not be aggregated into a single route unless the 4217 FIB-Tags of each of these route are the same. 4219 Routes that have the following attributes shall not be aggregated 4220 unless the corresponding attributes of each route are identical: 4221 MULTI-EXIT_DISC and NEXT_HOP. 4223 An aggregated route is constructed from one or more component routes. 4224 If a component of an aggregated route that has been advertised in an 4225 UPDATE PDU becomes unfeasible, then all component routes that 4226 comprise the aggregated route, except for the unfeasible component, 4227 shall be advertised again, either as separate routes or as a new 4228 aggregated route. If the new aggregated route has the same NLRI as 4229 the previous aggregated route, then no further actions are necessary, 4230 since advertisement of the new aggregated route implicitly marks the 4231 old aggregated route as having been withdrawn from use. In all other 4232 cases, the original aggregated route must be withdrawn explicitly by 4233 means of the Withdrawn Routes field of an UPDATE PDU. 4235 8.16.2.2. Path attribute aggregation 4237 Path attributes that have different type codes can not be aggregated 4238 together. Path attributes of the same type code may be aggregated, 4239 according to the following rules: 4241 LOCAL_PREF attributes: 4243 When several routes are aggregated, the advertising BIS shall 4244 compute a degree of preference for the aggregated route, and 4245 shall carry this value in the LOCAL_PREF attribute of the 4246 aggregated route. 4248 INCOMPLETE_PATH attributes: 4250 If at least one route among routes that are aggregated has the 4251 INCOMPLETE_PATH attribute, then the aggregated route must have 4252 the INCOMPLETE_PATH attribute as well. 4254 RD_PATH attributes: 4256 The individual RD_PATH attributes from which the aggregated 4257 RD_PATH attribute will be constructed are called the component 4258 attributes, and the ENTRY_SEQ and ENTRY_SET path segments 4259 contain the RDIs of confederations that have been entered but 4260 not yet exited. If the RDIs of all such confederations appear 4261 in the same relative order of entry in every component route, 4262 then aggregation may be performed without pre-processing the 4263 component routes. If they appear in different orders of entry 4264 in the component routes, then the pre-processing step outlined 4265 below must be performed in order to create the same order of 4266 entry in every component route before applying the aggregation 4267 procedures. 4269 If routes to be aggregated have identical RD_PATH attributes, 4270 then the aggregated route has the same RD_PATH attribute as 4271 each individual route, and no further processing is necessary. 4273 Pre-processing to Attain Identical Order of Entry: 4275 Apply the following procedure to each component route 4276 individually. Replace all path segments, from the first 4277 ENTRY_SET or ENTRY_SEQ segment to the last path segment, 4278 inclusive, with a path segment of type ENTRY_SET followed by 4279 a path segment of type RD_SET: 4281 - The path segment of type ENTRY_SET shall contain the 4282 union of the all the RDIs listed in the individual 4283 ENTRY_SET and ENTRY_SEQ segments. The RDIs must be listed 4284 in the same order in each component route. The specific 4285 ordering algorithm is left as a local matter, but it 4286 shall guarantee that the RDI of a given confederation 4287 does not precede the RDI of any confederation within 4288 which it it is nested. 4290 - The path segment of type RD_SET shall contain the union 4291 of the RDIs contained in all RD_SETs and RD_SEQs that 4292 appear after the first ENTRY_SET or ENTRY_SEQ of the 4293 component route. 4295 Aggregation Procedures: For purposes of this procedure, a 4296 path segment that lists multiple RDIs shall be treated as if 4297 it were multiple consecutive path segments, where each path 4298 segment lists a single RDI and the order of appearance of 4299 RDIs is maintained. For example, a path segment that listed 4300 RDIs X, Y, and Z (in that order) is treated as if it were a 4301 path segment listing X, followed by a path segment listing 4302 Y, followed by a path segment listing Z. If all the RD_PATH 4303 attributes of all component routes are identical, the 4304 aggregated path attribute is equal to the original RD_PATH 4305 attribute. 4307 The main procedure of 8.16.2.2.1 calls the subroutine of 4308 8.16.2.2.2 for aggregating RD_PATH attributes that contain 4309 no ENTRY_SEQs or ENTRY_SETs (generically called an "Entry 4310 Marker"). In effect, the main procedure applies the 4311 subroutine to all segments that are located between Entry 4312 Markers, between an Entry Marker and the end of a component 4313 attribute, or between the start of a component attribute and 4314 its first Entry Marker. 4316 The main procedure is described in 8.16.2.2.1 , and the 4317 subroutine is described in 8.16.2.2.2 4319 RD_HOP COUNT attribute: 4321 The value of the RD_HOP_COUNT of the aggregated route shall be 4322 set equal to the largest RD_HOP_COUNT that was contained in the 4323 routes being aggregated. 4325 CAPACITY Attributes: 4327 The value of the CAPACITY attribute of the aggregated route 4328 shall be equal to the smallest integer value contained in the 4329 CAPACITY fields of the routes being aggregated. 4331 8.16.2.2.1. Main procedure for RD_PATH aggregation 4333 This procedure is used to aggregate the RD_PATH attributes of 4334 component routes: 4336 a) Set the aggregated RD_PATH to "empty". 4338 b) Scanning from the back of each non-empty component attribute, 4339 locate the first Entry Marker. If the type of marker in any 4340 component route is ENTRY_SET, then change the type of the 4341 corresponding Entry Marker in all component attributes to 4342 ENTRY_SET. 4344 c) If no Entry Marker is found, apply the subroutine for 4345 aggregating RD_PATHs with no Entry Markers (see 8.16.2.2.2 ), and 4346 prepend the result to the aggregated RD_PATH attribute. 4348 d) If a Entry Marker is found, prepend the following to the 4349 aggregated RD_PATH attribute, in the order indicated: the located 4350 Entry Marker, followed immediately by the path segments obtained 4351 by applying the subroutine for aggregation of RD_PATHs with no 4352 Entry Markers (see 8.16.2.2.2 ) to the path segments that follow 4353 the located Entry Marker in each component attribute. If a 4354 component attribute has no path segments following the located 4355 Entry Marker, pass it to the subroutine as an empty set. 4357 e) Delete from each component attribute all the path segments that 4358 were appended to the aggregated attribute in steps c or d. 4360 f) Repeat steps b through e until every component attribute is 4361 empty. 4363 If there are consecutive path segments of the same type, they shall 4364 be combined into a single path segment of the same type. 4366 8.16.2.2.2. Aggregating routes with no entry markers 4368 The subroutine for aggregating RD_PATH attributes with no entry 4369 markers is as follows: 4371 a) Set the aggregated RD_PATH to "empty". 4373 b) Scanning from the back of each component attribute, locate the 4374 first identical longest sequence of path segments that occurs in 4375 every component attribute, including any that are empty. 4377 Note 30: It will not be possible to find an identical sequence 4378 in every component attribute if one or more of them are empty. 4380 c) If there is no identical sequence, form a path segment of type 4381 RD_SET that contains every RDI in every non-empty component 4382 attribute. Prepend this list to the aggregated RD_PATH attribute. 4384 d) If the identical sequence is the final sequence of every 4385 component attribute, prepend it to the aggregated route. 4387 e) If the identical sequence is not the final sequence of every 4388 component attribute, form a path segment of type RD_SET that lists 4389 every RDI that occurs between the end of the identical sequence 4390 and the end of each non-empty component attribute. Prepend this 4391 list to the aggregated RD_PATH attribute. 4393 f) Delete from each component attribute all path segments that 4394 were added to the aggregated RD_PATH attribute in step c, d, or e. 4396 g) If, after the deletions in step f have been made, an RDI is 4397 present in both the aggregated RD_PATH attribute and in any of the 4398 component attributes, then the accumulated RD_PATH attribute shall 4399 be replaced by a single path segment of type RD_SET that lists 4400 every RDI that was present in the component routes that were the 4401 input to this subroutine (before any deletions were made), and 4402 the subroutine terminates. Otherwise, repeat steps b through f 4403 until every component attribute is empty. 4405 8.17. 7.19 Maintenance of the forwarding information bases 4407 As summarized in Table 1, the Forwarding Information Bases contain 4408 the following information: 4410 a) the Network Layer address of the next-hop BIS, 4412 b) the local SNPA used by the local BIS to forward traffic to the 4413 next-hop BIS, 4415 e) if available, the SNPA in the next-hop BIS to which NPDUs will 4416 be forwarded. 4418 The RIB-Tag of the Loc-RIB which contains a route is also the RIB-Tag 4419 of the corresponding FIB; the NLRI for the associated FIB is the same 4420 as the NLRI of the corresponding route that is stored in the Loc-RIB. 4422 The forwarding information consists of three parts. 4424 a) Network Layer address of Next-hop BIS: For each route in the Loc- 4425 RIB, the next-hop BIS has been determined, and is carried as a tag, 4426 as described in 8.15.2 entry in the FIB. This information is always 4427 present. 4429 b) Output SNPA: The SNPA that will be used by the local BIS for 4430 forwarding traffic to the destinations identified in the NLRI field 4431 of the FIB is established locally, and is one of the SNPAs identified 4432 in managed object localSNPA. 4434 c) Input SNPA: The SNPA that will be used by the remote BIS to 4435 receive traffic that is the NEXT_HOP attribute of the corresponding 4436 route stored in the Loc-RIB. If the NEXT-HOP attribute contains an 4437 empty SNPA list, or if the NEXT_HOP attribute itself is not included 4438 in the route, then the Input SNPA field in the FIB will be empty. 4440 8.18. Error handling for BISPDUs 4442 This section describes actions to be taken when errors are detected 4443 while processing BISPDUs. Error handling procedures apply 4444 individually to each FSM in the BIS. 4446 8.18.1. BISPDU header error handling 4448 If BIS-BIS connection was established using authentication code 2 4449 (checksum plus authentication) and the validation pattern in the 4450 BISPDU header does not match the locally computed pattern, then the 4451 BISPDU shall be discarded without any further actions. 4453 If any of the following error conditions are detected, the BISPDU 4454 shall be discarded, and the appropriate error event shall be logged 4455 by the receiving BIS: 4457 a) Length field of a PDU header less than 30 octets or greater 4458 than the Segment Size specified by the remote system's OPEN PDU, 4460 b) Length field of an OPEN PDU less than minimum length of an 4461 OPEN_ PDU 4463 c) Length field of an UPDATE PDU less than minimum length of an 4464 UPDATE PDU 4466 d) Length field of KEEPALIVE PDU not equal to 30 4468 e) Length of an IDRP ERROR PDU less than the minimum length of 32 4470 f) Length of a CEASE PDU less than the minimum length of 30 4472 g) The BIS-BIS connection was established using authentication 4473 code 1 (checksum without authentication) and the validation 4474 pattern in the BISPDU header does not match the locally computed 4475 pattern 4477 h) Type field in the BISPDU is not recognized 4479 8.18.2. OPEN PDU error handling 4481 The following errors detected while processing the OPEN PDU shall be 4482 indicated by sending an IDRP ERROR PDU with error code 4483 OPEN_PDU_Error. The error subcode of the IDRP ERROR PDU shall 4484 elaborate on the specific nature of the error. 4486 a) If the version number of the received OPEN PDU is not 4487 supported, then the error subcode of the IDRP ERROR PDU shall be 4488 set to Unsupported_Version_Number. The Data field of the IDRP 4489 ERROR PDU is a 2-octet unsigned integer, which indicates the 4490 highest supported version number less than the version of the 4491 remote BIS peer's bid (as indicated in the received OPEN PDU). 4493 b) If the Maximum PDU Size field of the OPEN PDU is less than 4494 MinBISPDULength octets, the error subcode of the IDRP ERROR PDU is 4495 set to Bad_Maximum PDU_Size. The Data field of the IDRP ERROR PDU 4496 is a 2 octet unsigned integer which contains the erroneous Maximum 4497 PDU Size field. 4499 c) If the Routing Domain Identifier field of the OPEN PDU is not 4500 the expected one, the error subcode of the IDRP ERROR PDU is set 4501 to Bad_Peer_RD. The expected values of the Routing Domain 4502 Identifier may be obtained by means outside the scope of this 4503 protocol (usually it is a configuration parameter). The value of 4504 the erroneous RDI is returned in the Data field of the IDRP ERROR 4505 PDU, encoded as a pair. "Length" is a one octet 4506 field containing a positive integer that gives the number of 4507 octets used for the following "RDI" field. 4509 d) If a BIS receives an OPEN PDU from a BIS located in the same 4510 RD, and the RIB-TagsSet field contained in that PDU is different 4511 from the receiving BIS's managed object RIBTagsSet, then the error 4512 subcode of the IDRP ERROR PDU shall be set to Bad-RIB-TagsSet. 4514 e) If the value of the Authentication Code field of the OPEN PDU 4515 is any value other than 1 or 2, the error subcode of the IDRP 4516 ERROR PDU is set to Unsupported_Authentication_Code. 4518 f) If a given BIS receives an OPEN PDU from another BIS located in 4519 the same routing domain, then the RDIs reported in the Confed-IDs 4520 field of the OPEN PDU (received from the remote BIS) should match 4521 the Confed-IDs of the local BIS. If they do not match exactly, 4522 then an IDRP ERROR PDU shall be issued, indicating an OPEN PDU 4523 error with an error subcode of RDC_Mismatch. The data field of the 4524 IDRP ERROR PDU shall report the offending Confed-IDs field from 4525 the rejected OPEN PDU. 4527 g) If the Hold Time field of the OPEN PDU is unacceptable, then 4528 the Error Subcode shall be set to Unacceptable Hold Time. An 4529 implementation shall reject Hold Time values of one or two 4530 seconds. An implementation may reject any proposed Hold Time. An 4531 implementation which accepts a Hold Time shall use the negotiated 4532 value for the Hold Time. 4534 h) If the OPEN PDU carries one or more well-known optional 4535 parameters, and if any of these parameters is not recognized, then 4536 the error subcode of the IDRP ERROR PDU shall be set to 4537 Unsupported well-known parameter. The Data field of the IDRP ERROR 4538 PDU shall report the unrecognized parameter (type, length and 4539 value). 4541 8.18.3. UPDATE PDU error handling 4543 All errors detected while processing the UPDATE PDU are indicated by 4544 sending an IDRP ERROR PDU with error code UPDATE_PDU_Error. The error 4545 subcode of the IDRP ERROR PDU elaborates on the specific nature of 4546 the error. 4548 a) If the Total Attribute Length is inconsistent with the Length 4549 field of the PDU header, then the error subcode of the IDRP ERROR 4550 PDU shall be set to Malformed_Attribute_List. No further 4551 processing shall be done and all information in the UPDATE PDU 4552 shall be discarded. 4554 b) If any recognized attribute has attribute flags that conflict 4555 with the attribute type code, then the error subcode of the IDRP 4556 ERROR PDU shall be set to Attribute_Flags_Error. The Data field of 4557 the IDRP ERROR PDU shall contain the incorrect attribute (type, 4558 length and value). No further processing shall be done, and all 4559 information in the UPDATE PDU shall be discarded. 4561 c) If any recognized attribute has a length that conflicts with 4562 the expected length (based on the attribute type code), then the 4563 error subcode of the IDRP ERROR PDU shall be set to 4564 Attribute_Length_Error. The Data field of the IDRP ERROR PDU 4565 contains the incorrect attribute (type, length and value). No 4566 further processing shall be done, and all information in the 4567 UPDATE PDU shall be discarded. 4569 d) If any of the mandatory well-known attributes are not present, 4570 then the error subcode of the IDRP ERROR PDU shall be set to 4571 Missing_Well-known_Attribute. The Data field of the IDRP ERROR PDU 4572 contains the attribute type code of the missing well-known 4573 attribute. 4575 e) If any well-known attribute (so designated by the attribute 4576 flags) is not recognized, then the error subcode of the IDRP ERROR 4577 PDU shall be set to Unrecognized_Well-known_Attribute. The Data 4578 field of the IDRP ERROR PDU shall report the unrecognized 4579 attribute (type, length and value). In both cases no further 4580 processing shall be done, and all information in the UPDATE PDU 4581 shall be discarded. 4583 f) If the NEXT_HOP attribute field is invalid, then the error 4584 subcode of the IDRP ERROR PDU shall be set to 4585 Invalid_NEXT_HOP_Attribute. The Data field of the IDRP ERROR PDU 4586 contains the incorrect attribute (type, length and value). No 4587 further processing shall be done and all information in the UPDATE 4588 PDU shall be discarded. 4590 g) The sequence of RD path segments shall be checked for RD loops. 4591 RD loop detection shall be done by scanning the complete list of 4592 RD path segments (as specified in the RD_PATH attribute) and 4593 checking that each RDI in this list occurs only once. If an RD 4594 loop is detected, then the error subcode of the IDRP ERROR PDU 4595 shall be set to RD_Routing_Loop. 4597 The data field of the IDRP ERROR PDU shall report the first RDI 4598 that indicated a loop. This RDI shall be followed immediately by 4599 the complete RD_PATH attribute. The encoding shall be: length, 4600 RDI, Offending RD_PATH attribute>, where: 4602 - "length" is a one octet field that gives the length of the in 4603 octets of the immediately following RDI field 4605 - "RDI" is the RDI that was detected as creating the loop 4607 - RD_PATH is the octet string that encoded the value field of 4608 the offending RD_PATH attribute in the received UPDATE PDU (see 4609 6.3). 4611 No further processing shall be done, and all information in the 4612 UPDATE PDU shall be discarded. 4614 h) If any non-null FIB-Tag advertised in an UPDATE PDU received 4615 from a BIS located in a different routing domain does not match 4616 any of the RIB-Tags that the local (receiving) BIS had advertised 4617 to that neighbor in the RIB-TagsSet field of its OPEN PDU, then 4618 the receiving BIS shall send an IDRP Error PDU that reports an 4619 error subcode of Malformed_Attribute_List. All information in the 4620 UPDATE PDU shall be discarded, and no further processing shall be 4621 done. 4623 l) If the length of the NLRI is inconsistent with the Length 4624 field of the PDU header, then the error subcode of the IDRP ERROR 4625 PDU shall be set to Malformed_NLRI. No further processing shall 4626 be done, and all information in the UPDATE PDU shall be discarded. 4628 m) If an optional attribute is recognized, then the value of this 4629 attribute shall be checked. If an error is detected, the 4630 attribute shall be discarded, and the error subcode of the IDRP 4631 ERROR PDU shall be set to Optional_Attribute_Error. The Data 4632 field of the IDRP ERROR PDU shall report the attribute (type, 4633 length and value). No further processing shall be done, and all 4634 information in the UPDATE PDU shall be discarded. 4636 n) If RDCs are supported and any of the error conditions noted in 4637 8.12.3.3 occur, no further processing of the UPDATE PDU shall be 4638 done, all information in the UPDATE PDU shall be discarded, and 4639 the error code of the NOTIFICATION PDU shall be set to 4640 Misconfigured_RDCs. 4642 Note 32: This error condition refers to duplicated attributes 4643 within a single route. 4645 p) If an UPDATE PDU contains more than one instance of a path 4646 attribute of the same type, the BIS shall send an IDRP ERROR PDU 4647 with error subcode Duplicated_Attributes. The data field of the 4648 IDRP ERROR PDU shall list the type codes of all such duplicated 4649 attributes. 4651 q) If the RD_PATH attribute contains an illegal segment type, the 4652 BIS shall send an IDRP ERROR PDU, with error subcode 4653 Illegal_RD_Path_Segment. The data field of the IDRP ERROR PDU 4654 shall reproduce the encoding of the offending segment of the 4655 RD_PATH attribute, as it appeared in the received UPDATE PDU. 4657 8.18.4. IDRP ERROR PDU error handling 4659 If a BIS receives an IDRP ERROR PDU with a correct validation pattern 4660 but which contains an unrecognized error code or error subcode, the 4661 local BIS shall close the connection as described in clause 8.6.2 4663 Note 33: Any error (such as unrecognized Error Code or Error Subcode, 4664 or an incorrect Length field in the PDU header) should be logged 4665 locally and brought to the attention of the administration of the 4666 peer. The means to do this are, however, outside the scope of this 4667 protocol. 4669 8.18.5. Hold timer expired error handling 4671 If the FSM for a given BIS-BIS connection is in the ESTABLISHED state 4672 and the local BIS does not receive successive PDUs of types 4673 KEEPALIVE, UPDATE, or RIB REFRESH, within the period specified in the 4674 Hold Time field of the OPEN PDU previously sent to the remote BIS, 4675 then an IDRP ERROR PDU with error code Hold_Timer_Expired shall be 4676 sent to the remote BIS and the FSM for the associated BIS-BIS 4677 connection shall enter the CLOSE-WAIT state. 4679 8.18.6. KEEPALIVE PDU error handling 4681 The KEEPALIVE PDU consists of only the BISPDU Header. Error 4682 conditions are handled according to 8.18.1 4684 8.18.7. CEASE PDU error handling 4686 The CEASE PDU consists of only the BISPDU Header. Error conditions 4687 are handled according to 8.18.1 4689 8.18.8. RIB REFRESH PDU error handling 4691 If any of the following error conditions are detected, the BIS shall 4692 issue an IDRP ERROR PDU with the following error indications: 4694 a) Invalid OpCode not in Range 1 to 3: indicate RIB REFRESH error 4695 with error subcode "Invalid OpCode" 4697 b) Receipt of an OpCode 3 (RIB Refresh End) without prior receipt 4698 of OpCode 2 (Rib Refresh Start): indicate FSM Error 4700 c) Receipt of an unsupported RIB-Tag in the Rib-Tags variable 4701 length field in the RIB REFRESH PDU for a RIB Refresh Start 4702 OpCode: indicate RIB REFRESH error with error subcode "Unsupported 4703 RIB-Tags" 4705 9. Constants 4707 This constants used by the protocol defined in this document are 4708 enumerated in Table 6. 4710 10. Required set of supported routing policies 4712 Policies are provided to IDRP in the form of configuration 4713 information. This information is not directly encoded in the 4714 protocol. Therefore, IDRP can provide support for very complex 4715 routing policies. However, it is not required that all IDRP 4716 implementations support such policies. 4718 We are not attempting to standardize the routing policies that must 4719 be supported in every IDRP implementation; we strongly encourage all 4720 implementors to support the following set of routing policies: 4722 IDRP implementations should allow a domain to control 4723 announcements of IDRP-learned routes to adjacent domains. 4724 Implementations should also support such control with at least the 4725 +----------------------------------------------------------------------+ 4726 | Table 6. Architectural Constants of IDRP | 4727 +---------------------------+--------------+---------------------------+ 4728 | Name of Constant | Value | Description | 4729 +---------------------------+--------------+---------------------------+ 4730 | Inter-domain Routing | 45 | The Protocol the protocol | 4731 | Protocol Number | | described in this | 4732 | | | document | 4733 +---------------------------+--------------+---------------------------+ 4734 | MinBISPDULength | 30 | The size in octets of the | 4735 | | | smallest allowable | 4736 | | | BISPDU. | 4737 +---------------------------+--------------+---------------------------+ 4738 | MinRDOriginationInterval | 15 min | The minimum time between | 4739 | | | successive UPDATE PDUs | 4740 | | | advertising routing | 4741 | | | information about the | 4742 | | | local RD | 4743 +---------------------------+--------------+---------------------------+ 4744 | Jitter | 0,25 | The factor used to | 4745 | | | compute jitter according | 4746 | | | to clause 7.17.3.3. | 4747 +---------------------------+--------------+---------------------------+ 4748 | MaxCPUOverloadPeriod | 1 hr | Maximum time in which a | 4749 | | | BIS can remain | 4750 | | | CPU-overloaded before | 4751 | | | terminating its BIS-BIS | 4752 | | | connections. | 4753 +---------------------------+--------------+---------------------------+ 4754 | CloseWaitDelay | 150 s | The time that a FSM | 4755 | | | remains in CLOSE-WAIT | 4756 | | | state before entering the | 4757 | | | CLOSED state. | 4758 +---------------------------+--------------+---------------------------+ 4760 granularity of a single address prefix. Implementations should 4761 also support such control with the granularity of a domain, where 4762 the domain may be either the domain that originated the route, or 4763 the domain that advertised the route to the local system (adjacent 4764 domain). Care must be taken when a BIS selects a new route that 4765 can't be announced to a particular external peer, while the 4766 previously selected route was announced to that peer. 4767 Specifically, the local system must explicitly indicate to the 4768 peer that the previous route is now infeasible. 4770 IDRP implementations should allow a domain to prefer a particular 4771 path to a destination (when more than one path is available). At 4772 the minimum an implementation shall support this functionality by 4773 allowing to administratively assign a degree of preference to a 4774 route based solely on the IP address of the neighbor the route is 4775 received from. The allowed range of the assigned degree of 4776 preference shall be between 0 and 2^(31) - 1. 4778 IDRP implementations should allow a domain to ignore routes with 4779 certain domains in the RD_PATH path attribute. Such function can 4780 be implemented by assigning "infinity" as "weights" for such 4781 domains. The route selection process must ignore routes that have 4782 "weight" equal to "infinity". 4784 11. Operations over Switched Virtual Circuits 4786 When using IDRP over Switched Virtual Circuit (SVC) subnetworks it 4787 may be desirable to minimize traffic generated by IDRP. 4788 Specifically, it may be desirable to eliminate traffic associated 4789 with periodic KEEPALIVE messages. IDRP includes a mechanism for 4790 operation over switched virtual circuit (SVC) services which avoids 4791 keeping SVCs permanently open and allows it to eliminates periodic 4792 sending of KEEPALIVE messages. 4794 This section describes how to operate without periodic KEEPALIVE 4795 messages to minimize SVC usage when using an intelligent SVC circuit 4796 manager. The proposed scheme may also be used on "permanent" 4797 circuits, which support a feature like link quality monitoring or 4798 echo request to determine the status of link connectivity. 4800 The mechanism described in this section is suitable only between the 4801 BISs that are directly connected over a common virtual circuit. 4803 11.1. Establishing an IDRP Connection 4805 The feature is selected by specifying zero Hold Time in the OPEN 4806 BISPDU. 4808 11.2. Circuit Manager Properties 4810 The circuit manager must have sufficient functionality to be able to 4811 compensate for the lack of periodic KEEPALIVE BISPDU: 4813 It must be able to determine link layer unreachability in a 4814 predictable finite period of a failure occurring. 4816 On determining unreachability it should: 4818 - start a configurable dead timer (comparable to a typical Hold 4819 timer value). 4821 - attempt to re-establish the Link Layer connection. 4823 If the dead timer expires it should: 4825 - send a deactivate indication to IDRP FSM. 4827 If the connection is re-established it should: 4829 - cancel the dead timer. 4831 - transmit any queued BISPDUs. 4833 11.3. Combined Properties 4835 Some implementations may not be able to guarantee that the IDRP 4836 process and the circuit manager will operate as a single entity; i.e. 4837 they can have a separate existence when the other has been stopped or 4838 has crashed. 4840 If this is the case, a periodic two-way poll between the IDRP process 4841 and the circuit manager should be implemented. If the IDRP process 4842 discovers the circuit manager has gone away it should close all 4843 relevant BIS-BIS connections. If the circuit manager discovers the 4844 IDRP process has gone away it should close all its BIS-BIS 4845 connections associated with the IDRP process and reject any further 4846 incoming BIS-BIS connections. 4848 12. Security Considerations 4850 Security issues are not discussed in this document. 4852 13. Acknowledgements 4854 This document is based on a combination of of IDRP version 1 4855 (ISO10747) and BGP-4. As such, it borrows heavily from both of its 4856 ancestors. Note that during their development both of the ancestors 4857 (IDRP and BGP-4) borrowed heaviliy from each other. Thus we would 4858 like to acknowledge all the individuals who contributed to the design 4859 of both BGP and IDRP. We also like to acknowledge all the members of 4860 both the Inter-Domain Routing Working Group of the IETF and the 4861 X3S3.3 Working Group of ANSI where BGP and IDRP were designed. 4863 14. References 4865 15. Editors's Addresses 4867 Yakov Rekhter 4868 cisco Systems, Inc. 4869 170 Tasman Dr. 4870 San Jose, CA 95134 4871 Phone: (914) 528-0090 4872 email: yakov@cisco.com 4874 Paul Traina 4875 Juniper Networks, Inc. 4876 101 University Ave. 4877 Suite 240 4878 Palo Alto, CA 94301 4879 Phone: (415) 614-4140 4880 email: pst@jnx.com