idnits 2.17.1 draft-hares-idrp-05.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-16) 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. ** 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 == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 63 lines 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 418 has weird spacing: '...ultiple proto...' -- 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 (September 1993) is 11171 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) -- Looks like a reference, but probably isn't: 'ISO 8473' on line 147 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1519 (ref. '7') (Obsoleted by RFC 4632) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Unknown state RFC: RFC 1104 (ref. '9') ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 1248 (ref. '12') (Obsoleted by RFC 1252) Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Susan Hares 2 INTERNET DRAFT Merit/NSFNET 3 John Scudder 4 Merit/NSFNET 5 September 1993 7 IDRP for IP 9 Status of this memo 11 This memo specifies the adaptation of the ISO Inter-Domain Routing 12 Protocol ([1]) that enables it to be used as an Inter-Autonomous 13 System routing protocol in the TCP/IP Internet. IDRP with this 14 adaptation will be called "IDRP for IP" in this document. Dual IDRP, 15 that is, a single instance of IDRP that can simultaneously support 16 Inter-Domain/Inter-Autonomous System routing in the TCP/IP and OSI 17 Internets is outside the scope of this document. 19 This document is an Internet Draft. Internet Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its Areas, 21 and its Working Groups. Note that other groups may also distribute 22 working documents as Internet Drafts. 24 Internet Drafts are draft documents valid for a maximum of six 25 months. Internet Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet 27 Drafts as reference material or to cite them other than as a "working 28 draft" or "work in progress." 30 1. Overview 32 IDRP ([1]) is defined as the protocol for exchange of Inter-Domain 33 routing information between routers to support forwarding of ISO 8473 34 (Connectionless Network Layer Protocol (CLNP))[2] PDUs. 36 The network reachability information exchanged via IDRP provides 37 sufficient information to detect routing loops and enforce routing 38 decisions based on performance preference and policy constraints as 39 outlined in RFC 1104 [9]. In particular, IDRP exchanges routing 40 information containing full domain-level paths and enforces routing 41 policies based on configuration information. 43 As the Internet has evolved and grown over in recent years, it has 44 become evident that it is soon to face several serious scaling 45 problems. These include: 47 Exhaustion of the class B network address space. One fundamental 48 cause of this problem is the lack of a network class of a size which 49 is appropriate for mid-sized organization; class C, with a maximum of 50 254 host addresses, is too small while class B, which allows up to 51 65534 addresses, is too large to be densely populated. Growth of 52 routing tables in Internet routers are beyond the ability of current 53 software (and people) to effectively manage. Eventual exhaustion of 54 the 32-bit IP address space. 56 It has become clear that the first two of these problems are likely 57 to become critical within the next one to three years. Classless 58 inter-domain routing (CIDR) [7], [10] attempts to deal with these 59 problems by proposing a mechanism to slow the growth of the routing 60 table and the need for allocating new IP network numbers. It does not 61 attempt to solve the third problem, which is of a more long-term 62 nature, but instead endeavors to ease enough of the short to mid-term 63 difficulties to allow the Internet to continue to function 64 efficiently while progress is made on a longer- term solution. 66 IDRP may be viewed as an extension of BGP-4 [11] that provides (among 67 other things) much better scaling with respect to support for routing 68 information aggregation and reduction based on CIDR, as well as 69 stronger capabilities for policy based routing (e.g. ability to 70 impose control over transit traffic). 72 This document specifies the appropriate adaptation of the IDRP 73 protocol definition that enables it to be used as a protocol for the 74 exchange of inter-autonomous system information among routers to 75 support the forwarding of IP packets across multiple autonomous 76 systems. 78 The adaptation is defined is such a way that a Dual IDRP will be able 79 to fully interoperate with IDRP for IP. 81 2. Terminology 83 This document assumes that the reader is familiar with the following 84 documents: 86 IP protocol specification (RFC 791)[5], and IDRP specification (IS 87 10747). 89 A few definitions are in order to aid the reader: 91 BIS - a Boundary Intermediate System (or border router) 93 BISPDU - an IDRP message exchanged between a pair of BISs 95 FIB - Forwarding Information Base (IP forwarding table) 97 IS - Intermediate System (router) 99 NET - Network Entity Title - an ISO network address for a router 100 NLRI - Network Layer Reachability Information (set of reachable 101 destinations) 103 NPDU - an IP packet 105 PDU - a packet 107 SNPA - subnetwork point of attachment (MAC address) 109 3. Assumptions 111 The IDRP for IP protocol assumes that within a single connected 112 internet network addresses are unique. The IDRP for IP protocol 113 cannot be guaranteed to work in an environment where network 114 addresses within a single connected internet are not unique. 116 All of the discussions in this document are based on the assumption 117 that the Internet is a collection of arbitrarily connected Autonomous 118 Systems. That is, the Internet will be modeled as a general graph 119 whose nodes are AS's and whose edges are connections between pairs of 120 AS's. 122 The classic definition of an Autonomous System is a set of routers 123 under a single technical administration, using an interior gateway 124 protocol and common metrics to route packets within the AS and using 125 an exterior gateway protocol to route packets to other AS's. Since 126 this classic definition was developed, it has become common for a 127 single AS to use several interior gateway protocols and sometimes 128 several sets of metrics within an AS. The use of the term Autonomous 129 System here stresses the fact that, even when multiple IGPs and 130 metrics are used, the administration of an AS appears to other AS's 131 to have a single coherent interior routing plan and presents a 132 consistent picture of which networks are reachable through it. 134 AS's are assumed to be administered by a single administrative 135 entity, at least for the purposes of representation of routing 136 information to systems outside of the AS. 138 4. The Adaptation Layer 140 The Inter-Domain Routing Protocol (IDRP) or, more formally, 142 "The Protocol for the Exchange of Inter-Domain Routeing 143 information among Intermediate Systems to support Forwarding of 144 ISO 8473 PDUs (IDRP)" 146 is the inter-domain routing protocol defined to support the 147 forwarding of Connectionless Network Layer Protocol (CLNP) [ISO 8473] 148 packets that traverse multiple routing domains. 150 While this protocol was developed within ISO, it makes few, if any, 151 ISO-specific assumptions. In particular, it does not require 152 participating domains to support any specific ISO Intra-Domain 153 protocol, such as IS-IS (ISO IS 10589)[3], nor does it require 154 participating routers to run ES-IS (ISO 9542) [4]. The only 155 requirements imposed by the protocol on the participating routers is 156 that the protocol information can be exchanged between them over a 157 connectionless network layer, which in the case of OSI is CLNP, and 158 that the network layer connectivity between routers within a single 159 routing domain should be provided by means outside of IDRP (e.g., via 160 some intra-domain routing protocol). IDRP does not place any 161 restrictions on the structure of reachability information, as long it 162 can be expressed as an arbitrary set of variable length address 163 prefixes. 165 Since IP can provide connectionless service between routers, and 166 since reachable IP destinations can be expressed as IP address 167 prefixes, IDRP can be easily adapted to be an Inter-Autonomous System 168 routing protocol which can be used in the pure TCP/IP Internet. 170 While conceptually it is possible to define a mapping between the 171 security field of an IP header and IDRP NPDU-derived distinguishing 172 attributes, this mapping is outside the scope of this document. In 173 addition, address-specific QoSs (Source Specific QoS and Destination 174 Specific QoS) have no counterparts in IP. Therefore, the use of the 175 following IDRP distinguishing attributes for IP packets will not be 176 defined in this document: Priority Locally Defined QoS Security 178 Mapping between the following IDRP distinguishing attributes: Transit 179 Delay Residual Error Expense 181 and the IP Type of Service (TOS) parameters is defined in Section 182 5.2.3 of this document. 184 Note that an implementation that does not support any of the NPDU- 185 derived distinguishing attributes can fully interoperate with an 186 implementation that does support them. Therefore, an IDRP for IP 187 implementation that will support routing sensitive to the parameters 188 present in the TOS field of the IP header will be compatible with the 189 implementation that does not provide such support. 191 5. Implementor's Guide for IP specific functions. 193 In order to implement IDRP for IP, only a subset of the features of 194 the IDRP protocol must be implemented. 196 5.1 Features in IDRP which need not be implemented 198 The functions of the IDRP protocol which shall not be implemented for 199 IDRP for IP are those functions which deal with the following (all 200 references are with respect to the IDRP document [1]): 202 Locally Defined QoS according to section 7.12.11 Security according 203 to section 7.12.14 Priority according to section 7.12.16 Forwarding 204 CLNP packets according to section 8 The interface to CLNP according 205 to section 9 support of the Network Management information described 206 in the IDRP GDMO according to section 11 208 Therefore, with IDRP for IP the following items dealing with CLNP in 209 the IDRP conformance clause (section 12.1 of [1]) shall not be 210 implemented: 212 clause (d): Locally Defined QoS, Security, Priority clause (r) clause 213 (s) clause (t) 215 5.1.1 PICS Table Information 217 The PICS (Protocol Implementation Conformance Statement) provides a 218 convenient and concise mechanism to define which functions need and 219 need not be implemented for IDRP for IP. All references in this 220 section are with respect to [1]. All items with PICS Status as 221 Optional need not be implemented in IDRP for IP. Specifically, IDRP 222 for IP does not require support for the following items: 224 A.4.3 Table 9: 225 MGT 227 A.4.8 (Table 14): 228 PSRCRT, DATTS, MATCH 230 A.4.11 (Table 17): 231 LQOSG, SECG, PRTY 233 A.4.11 (Table 18): 234 LQOSP, SECP, PRTYP 236 A.4.11 (Table 19): 237 LQOSR, SECR, PRTYR 239 Implementation of all other items with Optional Status not listed in 240 the previous paragraph is optional. 242 5.2 Features in IDRP which shall be implemented 244 An implementation of IDRP for IP shall contain all mandatory features 245 of IDRP, except those mentioned in Section 5.1 of this document. In 246 addition, a BIS for IDRP for IP shall implement: 248 an interface to the IP protocol described in section 5.2.1 of this 249 document the ability to identify and extract IP reachability and IP 250 forwarding information as described in section 5.2.2 of this document 251 IP packet forwarding functions described in section 5.2.9 of this 252 document domain configuration information listed in section 5.2.8 of 253 this document the advertisement of IP address information in NLRI as 254 described in section 5.3 of this document 256 5.2.1 Exchanging IDRP information between IP-only routers. 258 IDRP assumes pair-wise communication between participating BISs. 259 IDRP information is carried between a pair of BISs in the form of 260 BISPDUs. In the case of IDRP for IP, these BISPDUs are carried in 261 the data field of IP packets of protocol type 45. 263 5.2.2 Identifying IP reachability and IP forwarding information 265 NLRI passed by the UPDATE PDU has an indication of protocol type. An 266 implementation of IDRP for IP shall have the following values in the 267 NLRI field: 269 Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI) 271 Proto_Length: 1 273 Protocol: hexadecimal 'CC' 275 Addr_Length: variable (the value shall be between 4 and 32) 277 Addr_Info: IP address prefixes, encoded in binary, as follows: 279 This is a variable length field that contains a list of IP 280 address prefixes for the routes that are being advertised. 281 Each IP address prefix is encoded as a 2-tuple of the form 282 , whose fields are described below: 284 +---------------------------+ 285 | Length (1 octet) | 286 +---------------------------+ 287 | Prefix (variable) | 288 +---------------------------+ 290 The use and the meaning of these fields are as follows: 292 a) Length: 294 The Length field indicates the length in bits of the IP 295 address prefix. A length of zero indicates a prefix that 296 matches all IP addresses (with prefix, itself, of zero 297 octets). 299 b) Prefix: 301 The Prefix field contains IP address prefixes followed by 302 enough trailing bits to make the end of the field fall on an 303 octet boundary. Note that the value of trailing bits is 304 irrelevant. 306 An implementation of IDRP for IP shall ignore any NLRI indicating a 307 different protocol type. 309 The NEXT_HOP attribute in the UPDATE PDU also has a Type field which 310 indicates the protocol family for the address of the NEXT_HOP. An 311 implementation of IDRP for IP shall have the following values in the 312 NEXT_HOP field: 314 Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI) 316 Proto_Length: 1 318 Protocol: hexadecimal 'CC' 320 Length of NET: 4 322 NET of Next Hop: an IP address, encoded in binary as specified in 323 section 5.2.2. 325 SNPA information: as appropriate for the subnetwork type in use 327 An implementation of IDRP for IP shall ignore any NEXT_HOP 328 information indicating a different protocol type. 330 5.2.3 Mapping between IP Type Of Service parameters and IDRP 331 distinguishing attributes. 333 IP defines four distinct Type of Service (TOS) Parameters (see [12]): 334 minimize delay maximize throughput maximize reliability minimize 335 monetary cost 337 An IP packet can carry at most one of the above TOSs. Therefore, a 338 RIB in IDRP for IP can have at most one distinguishing attribute. 340 IDRP for IP supports the following distinguishing attributes: Transit 341 Delay Residual Error Expense 343 A conformant implementation is required to recognize these attributes 344 when received from an adjacent BIS. 346 An IP-derived distinguishing attribute is defined as the TOS 347 parameter extracted from an IP packet that needs to be forwarded by a 348 BIS. 350 The mapping between the IP-derived distinguishing attribute and a 351 RIB-Att is defined as follows: 353 IP TOS IDRP distinguishing attribute 355 ------ ----------------------------- 357 minimize delay Transit Delay 359 maximize reliability Residual Error 361 minimize monetary cost Expense 363 maximize throughput Default 365 5.2.4 ATOMIC_AGGREGATE Attribute 367 A new optional transitive attribute, ATOMIC_AGGREGATE, is defined for 368 use in IDRP for IP. This attribute is intended to facilitate 369 interoperation between IDRP for IP and BGP-4. The type code of this 370 attribute shall be 129. This attribute has a length of zero octets. 372 This attribute shall be handled as follows: 374 Any IDRP for IP router receiving a route with the ATOMIC_AGGREGATE 375 attribute shall not deaggregate that route. 377 5.2.5 AGGREGATE Attribute 379 A new optional transitive attribute, AGGREGATOR is defined for use in 380 IDRP for IP. This attribute is intended to facilitate interoperation 381 between IDRP for IP and BGP-4. The type code of this attribute shall 382 be 130. This attribute shall have the following encoding: 384 proto_type - 1 octet 386 proto_length - 1 octet 388 protocol (variable) 390 length of address in bytes - 1 octet 392 aggregator's address 394 For IP this encoding would be: 396 proto_type: 1 (ISO/IEC TR 9577 IPI/SPI) 398 proto_length: 1 400 protocol: hexadeicmal 'CC' 402 length of address: 4 404 address: IP address 406 This attribute shall be handled as follows: 408 An IDRP for IP speaker may add this attribute to indicate that it 409 performed aggregation. 411 5.2.6 SDRP Attribute 413 A new optional transitive attribute, SDRP is defined for use in IDRP 414 for IP. This attribute is intended to both facilitate interoperation 415 between IDRP for IP and BGP-4, and to allow SDRP speakers to be 416 identified in the network. The type code of this attribute shall be 417 131. This attribute shall have the following encoding for each 418 protocol family. Multiple protocol families may be included in the 419 attribute. 421 proto_type - 1 octet) 423 proto_length (1 octet) 425 protocol (variable) 427 count of SDRP speakers - 2 octets 429 addresses of SDRP speakers 431 (The address information is specific to protocol.) 433 For IP Address, the format of the rest of the attribute is 4 byte 434 octets, just like BGP. 436 For CLNP addresses, the format of the rest of the attribute is a set 437 of tuples with (length of NETs, NET) with the following format. 439 length of address of SDRP speaker - 1 octet 441 address of SDRP speaker - (variable) 442 For IP this encoding would be: 444 proto_type: 1 (ISO/IEC TR 9577 IPI/SPI) 446 proto_length: 1 448 protocol: hexadeicmal 'CC' 450 count of SDRP speakers 452 address: IP address list 454 This attribute shall be handled as follows: 456 An IDRP for IP speaker may add this attribute to if it is an SDRP 457 speaker for the domain. It may add its own address and other SDRP 458 speaker for the domain. 460 5.2.7 Confederations of Autonomous Systems. 462 IDRP supports the ability to group Routing Domains into a Routing 463 Domain Confederation. Likewise, IDRP for IP supports the ability to 464 group a collection of Autonomous Systems into a Confederation of 465 Autonomous Systems. With respect to the IDRP document in the context 466 of IDRP for IP, the terms "Routing Domain Confederation" and 467 "Confederation of Autonomous Systems" should be treated as 468 synonymous. 470 5.2.8 Domain Configuration Information 472 Correct Operation of IDRP described in [1] assumes that a minimum 473 amount of information is available to both the inter-domain and 474 intra-domain routing protocols. This information is static in nature, 475 and is not expected to change frequently. This document assumes that 476 this information is supplied via IDRP MIB ([6]). While the following 477 in phrased in terms of MIB, this document allows alternative 478 mechanisms (e.g. configuration files) as well. 480 The information required by a BIS that implements the IDRP for IP 481 protocol is: 483 a) Location and identity of adjacent Intra-Domain ISs (routers) 485 The MIB table INTRA-IS lists the IP addresses of the routers to 486 which the local BIS may deliver an inbound NPDU whose 487 destination lies within the BIS's routing domain. These 488 routers listed in the INTRA-IS table support the intra-domain 489 routing protocol of this autonomous system, and share at least 490 one common subnet with the BIS. 492 In particular, if the local BIS participates in both the 493 inter-domain routing protocol (IDRP) and the intra-domain 494 routing protocol, then the IP address of the local BIS will be 495 listed in the INTRA-IS table. 497 b) Location and identity of BISs in the BIS's domain 499 This information permits a BIS to identify all other BISs 500 located within its routing domain. This information is 501 contained in the MIB table INTERNAL-BIS, which contains a set 502 of IP addresses which identify the BISs in the domain. 504 c) Location and identity of BISs in adjacent domains: 506 Each BIS needs information to identify the IP address of each 507 BIS located in an adjacent RD and reachable via a single 508 subnetwork hop. This information is contained in the IDRP MIB 509 table EXTERNAL-BIS-NEIGHBORS, which is a table of IP addresses. 511 d) IP network address information for all systems in the routing 512 domain 514 This information is used by the BIS to construct its network 515 layer reachability information. This information is contained 516 in the MIB table INTERNAL-SYSTEMS. The IP network address 517 information shall be expressed in terms of IP address prefixes. 518 A single prefix can be used to describe: 520 - a host address, 522 - a subnetwork number, 524 - a network number, or 526 - a collection of contiguous network numbers 528 e) LOCAL RDI 530 This information is contained in managed object LOCAL-RDI; it 531 is the RDI of the routing domain in which the BIS is located. 532 As specified in section 7 of this document, the RDI for an IDRP 533 for IP routing domain has an NSAP Address format. This NSAP 534 Address format is built out of a fixed "header" and the 535 autonomous system number of this autonomous system (routing 536 domain). 538 f) RIB-AttSet 540 The RIB-AttSet contains information about the QoS functions a 541 BIS will support. As described in section 4, this can be none, 542 any, or all of the Transit Delay, Residual Error, and Expense 543 distinguishing attributes. 545 g) RDC-Config: 547 This information identifies all the routing domain 548 confederations (RDCs) to which the RD of the local BIS belongs, 549 and it describes the nesting relationships that are in force 550 between them. It is contained in the MIB table RDC-Config. 552 Each RDC is identified by an RDI which has the format described 553 in section 7 of this document. 555 Note that since a domain is not required to belong to a 556 confederation this information is optional and needs to be 557 present only at BISs of the domains that are part of one or 558 more of RDCs. 560 h) Local IP addresses 562 The LOCAL IP MIB table contains a list of IP addresses assigned 563 to the interfaces of a BIS. This information is used to 564 determine what interface should be used to forward outgoing 565 NPDUs. 567 5.2.9 Forwarding of IP packets 569 This section is intended to define the same function for IP packets 570 as is defined for CLNP packets in the "Forwarding Process for CLNS" 571 (Section 8 in [1]). 573 It is assumed that a BIS is capable of distinguishing between a FIB 574 constructed by means of an intra-autonomous system routing protocol 575 and a FIB constructed by means of IDRP. 577 After a BIS determines the packet's destination IP address, the BIS 578 shall proceed as follows: 580 a) If the destination address specifies a system located within 581 the autonomous system of the receiving BIS, then the BIS shall 582 forward the IP packet to any of the ISs listed in the managed 583 object INTRA-IS. That is, any further forwarding of the IP packet 584 is the responsibility of the intra-autonomous system routing 585 protocol; otherwise, 587 b) the destination system is located in a different autonomous 588 system, and the local BIS shall perform the following actions: 590 It shall determine the IP-Derived distinguishing attribute, 591 according to clause 5.2.3. It shall next apply the procedures 592 of clause 5.2.3 to determine if the IP-Derived distinguishing 593 attribute matches any of the RIB-Atts of the information 594 base(s) supported by the local BIS. If such a match is found, 595 then the FIB with the matched RIB-Atts is used for forwarding. 597 If the procedures of clause 5.2.3 identify a non-default IP- 598 Derived distinguishing attribute, but the local BIS does not 599 maintain a FIB with the matching RIB-Atts, or the local BIS 600 maintains a FIB with the matching RIB-Atts but this FIB does 601 not have a route to the destination, then the local system sets 602 the Type Of Service field in the IP packet to 0 and uses the 603 FIB with no distinguishing attributes. 605 The incoming IP packet shall be forwarded based on the FIB 606 entry that has the longest IP address prefix that matches the 607 destination of the incoming IP packet, as follows: 609 1) If the entry in the inter-domain FIB that corresponds to 610 the destination address of an incoming IP packet contains a 611 NEXT_HOP that identifies an interface of a BIS such that the 612 interface is attached to a subnet shared with the local BIS, 613 then the IP packet shall be forwarded directly to the BIS 614 indicated in the NEXT_HOP entry over that interface; 615 otherwise, 617 2) if the entry in the inter-domain FIB that corresponds to 618 the destination address of the incoming IP packet contains a 619 NEXT_HOP entry that identifies an interface of a BIS such 620 that the interface is not attached to any of the subnets 621 attached to the local BIS, then the local BIS has the 622 following options: 624 i) Encapsulate the IP packet 626 The local BIS may encapsulate the IP packet, using its 627 own IP address as the source address and the IP 628 address of the next-hop BIS contained in the NEXT_HOP 629 entry as the destination address. Since IP doesn't 630 have a standard encapsulation protocol, use of this 631 option should be discouraged. 633 ii) Use paths calculated by the intra-autonomous system 634 routing protocols 636 The local BIS may query the FIB constructed by the 637 intra-autonomous system routing protocols to ascertain 638 if that FIB contains a route to the destination 639 system. If that is the case, and if the path 640 constructed by the intra-autonomous system routing 641 protocols delivers the IP packet to the appropriate 642 next-hop BIS, then the IP packet may be forwarded 643 using the FIB constructed by the intra-autonomous 644 system routing protocols. 646 ITEM Questions/Features Refer. Status Support 648 ---------------------------------------------------------------- 650 IP_EXTFWD Does the BIS correctly forward 5.3 M Yes___ 652 IP packets with destinations 654 outside its routing domain? 656 IP_INTFWD Does the BIS correctly forward 5.3 M Yes___ 658 IP packets with destinations 660 inside its routing domain? --------- 661 ------------------------------------------------------ 663 Table 1: PICS Proforma for IDRP: IP packet forwarding 665 The "ITEM" column describes the feature in the IP forwarding function 666 that the IDRP implementation is to provide. The "Question/Feature" 667 section seeks to describe the feature. The Reference is the section 668 in this document that describes this feature. The status gives an 669 indication of "M" - Mandatory feature for an IDRP implementation or 670 "O" - optional feature. The "Support" column is a column for the 671 implementor to check whether this feature is available in a 672 particular implementation.) 674 5.3 Advertising NLRI information for IP addresses 676 The NLRI field in an UPDATE PDU contains IP address information about 677 systems that reside within a given routing domain or whose IP address 678 space is under the control of the administrator of the routing 679 domain. It should not be used to convey information about the 680 operational status of these systems. The information in the NLRI 681 field is intended to convey static administrative information rather 682 than dynamic transient information; for example, it is not necessary 683 to report that a given system has changed from offline to online. 685 End systems (hosts) and Intermediate systems (routers) within a RD 686 using IDRP may use any IP address that is valid within the IP 687 context. Within the NLRI, the address information for a set of IP 688 addresses may be represented by an IP prefix. An IP prefix is the 689 sequence of bits in a 4 byte IP address which are common between a 690 set of IP addresses. 692 For example, the addresses 192.5.0.0 through 192.5.255.255 have the 693 first 16 bits of the address information in common. These 16 bits of 694 the IP address may be called an IP prefix which represents the set of 695 IP addresses 192.5.0.0 through 192.5.255.255. 697 An IP prefix must contain a contiguous set of bits starting at the 698 most significant bit, but the bits may cover any part of the 4 byte 699 IP address. The following guidelines for inclusion of IP address 700 prefixes in the NLRI field of the UPDATE PDUs originated within a 701 routing domain will provide efficient use of this protocol: 703 a) Only IP prefixes representing IP addresses that are within the 704 control of the administrator of a given routing domain may be 705 reported in the NLRI field for a RD. These IP prefixes can 706 represent IP addresses for systems which are: 708 - online, 710 - offline, or 712 - allocated to the network, but not yet allocated to a machine. 714 b) IP prefixes representing IP addresses outside of the RD 715 administrator's control shall not be included in the NLRI. 717 c) For efficient use of the protocol, the WITHDRAW ROUTES field 718 should not be used to report the NLRI of systems that are offline. 719 This field should be used only to advertise IP prefixes for IP 720 addresses that are no longer under the control of the 721 administrator of the local routing domain, regardless of whether 722 the systems are online or offline. 724 A conformant implementation is required to have the ability to 725 specify when an aggregated route may be generated out of partial 726 routing information. A BIS at the border of an autonomous system (or 727 group of autonomous systems) must be able to generate an aggregated 728 route for a whole set of NLRIs over which is has administrative 729 control, even when not all of them are reachable at the same time. 731 6 Determining the forwarding address (Next Hop) 733 NEXT_HOP information associated with a particular route shall be 734 derived from the NEXT_HOP attribute in the UPDATE BISPDU that carries 735 the route. If that attribute is not present, it shall be derived from 736 the source IP address of the IP packet that carries the UPDATE BISPDU 737 containing the route. 739 7 Routing Domain Identifiers used for both IP and OSI 741 Routing Domain Identifiers (RDIs) are identifiers used in BISPDUs to 742 uniquely identify individual routing domains and routing domain 743 confederations. 745 For ease of administration, the RDI is taken out of the NSAP address 746 space. However, the RDI is just a number which identifies the 747 routing domain, and need not bear any relationship to any reachable 748 addresses within the domain. 750 For ease of interworking with other IP inter-autonomous system 751 routing protocols, The RDI used for an autonomous system running IDRP 752 for IP should be derived from an appropriately assigned Autonomous 753 System Number as follows: 755 47:00:05:c0:01:aa:aa 757 Where 47:00:05:c0:01 is a unique prefix assigned by a valid 758 addressing authority (NIST), and aa:aa is the autonomous system 759 number. 761 This encoding of the RDI contains a "fixed header" (the 762 47:00:05:c0:01 sequence) plus the AS value. 764 (Note: While AS values are currently 2 octets long, IDRP allows 765 Routing Domain Identifiers to be of arbitrary length. Thus, if the 766 space of AS numbers is expanded to be greater than two octets, this 767 may be accommodated by simply lengthening the above encoding--the AS 768 number following the fixed header is considered to be right 769 justified, and its size can be unambiguously determined from the RDI 770 length.) 772 8 Deployment Guidelines for IDRP for IP 774 The correct and efficient operation of the IDRP protocol requires 775 that certain guidelines are used for deployment with ISO routing 776 Domains. Some equivalent deployment guidelines for IDRP for IP are 777 required within Autonomous Systems. These guidelines represent only 778 the required deployment guidelines, and not details on the usage of 779 IDRP for IP in the Internet. 781 8.1 Minimum configuration of an Autonomous System 783 An autonomous system using IDRP for IP must as a minimum contain: 785 one BIS, and one BIS capable of delivering NPDUs to the intra-domain 786 routing function if the AS contains hosts. 788 8.2 Multiple IDRP sessions between the same pair of routers 790 An IP router may have multiple IP addresses, one for each interface. 791 In contrast, an OSI Intermediate System has only one Network Entity 792 Title (network address). An OSI BIS thus may not have multiple IDRP 793 sessions with another BIS, since the NET is unique and there is no 794 mechanism for multiplexing sessions. However, an IP router may 795 potentially have multiple IDRP sessions with another router, since 796 each BIS may have multiple IP addresses, and one BIS may not be able 797 to ascertain that those addresses correspond to the same BIS. 798 Multiple IDRP sessions between IP BISs may not be efficient, but they 799 are not illegal, nor do they impact the robustness of the IDRP for IP 800 protocol; they will simply appear as multiple paths to the same 801 neighboring AS. One possible way of avoiding multiple parallel IDRP 802 sessions between a pair of BISs within a single autonomous system is 803 to bind all source addresses of outgoing BISPDUs to the IP address of 804 a particular interface of the BIS. Likewise, for a pair of BISs 805 located in adjacent autonomous systems, binding the source addresses 806 to a single address of an interface attached to a common subnetwork 807 provides for the elimination of multiple parallel sessions. 809 9. Recommended set of supported routing policies. 811 Policies are provided to IDRP in the form of configuration 812 information. This information is not directly encoded in the 813 protocol. Therefore, IDRP can provide support for very complex 814 routing policies (an example of such policy is presented in Annex K 815 of [1]). However, it is not required that all IDRP implementations 816 support such policies. 818 We are not attempting to standardize the routing policies that must 819 be supported in every IDRP implementation, but we strongly encourage 820 all implementors to support the following set of routing policies: 822 IDRP implementations should allow an AS to control announcements of 823 IDRP-learned routes to adjacent AS's. Implementations should also 824 support such control with at least the granularity of a single 825 network. Implementations should also support such control with the 826 granularity of an autonomous system, where the autonomous system may 827 be either the autonomous system that originated the route, or the 828 autonomous system that advertised the route to the local system 829 (adjacent autonomous system). Care must be taken when a BIS selects 830 a new route that can't be announced to a particular external peer, 831 while the previously selected route was announced to that peer. 832 Specifically, the local system must explicitly indicate to the peer 833 that the previous route is now infeasible. IDRP implementations 834 should allow an AS to prefer a particular path to a destination when 835 more than one path is available. This function may be implemented by 836 allowing system administrators to assign "weights" to AS's and having 837 the route selection process select a route with the lowest "weight" 838 (where "weight" of a route is defined as a sum of "weights" of all 839 AS's in the RD_PATH path attribute associated with that route). IDRP 840 implementations should allow an AS to ignore routes with certain AS's 841 in the RD_PATH path attribute. Such function can be implemented by 842 using the technique outlined in [9], and by assigning "infinity" as 843 "weights" for such AS's. The route selection process must ignore 844 routes that have "weight" equal to "infinity". 846 10. Security Considerations 848 Security issues are not discussed in this document. 850 11. Acknowledgements 852 A large set of thanks to Dave Katz (cisco) who helped edit the 853 document. We would also like to express my thanks to Scott Brim 854 (Cornell University) for his review and constructive comments. 856 The authors would like to acknowledge contributions made by authors 857 of [8], Yakov Rekhter and Phill Gross. Certain sections of this 858 document are taken (sometimes almost verbatim) from their document. 860 12. References 862 [1] ISO/IEC IS 10747 - Information Processing Systems - 863 Telecommunications and Information Exchange between Systems - 864 Protocol for Exchange of Inter-domain Routeing Information among 865 Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1993. 867 [2] ISO 8473 - Information Processing Systems - Data Communications 868 - Protocol for Providing the Connectionless-mode Network Service, 869 1988. 871 [3] ISO/IEC 10589 - Information Processing Systems - 872 Telecommunications and Information Exchange between systems - 873 Intermediate System to Intermediate System Intra-Domain routeing 874 information exchange protocol for use in conjunction with the 875 Protocol for providing the Connectionless-mode Network Service (ISO 876 8473), 1992. 878 [4] ISO 9542 - Information Processing Systems - Telecommunications 879 and information exchange between systems - End system to Intermediate 880 system routeing exchange protocol for use in conjunction with the 881 Protocol for providing the connectionless-mode network service (ISO 882 8473) 884 [5] RFC 791 (Jon Postel, editor) - Internet Protocol - DARPA 885 Internet Program Protocol Specification (September 1981) 887 [6] Hares, S., "Definition of Managed Objects for the IDRP for IP", 889 [7] Fuller, V., Li, T., Yu, J, and Varadhan, K., "Supernetting: an 890 Address Assignment and Aggregation Strategy", RFC1519, September 1993 892 [8] Rekhter, Y., Gross, P., "Application of the Border Gateway 893 Protocol in the Internet", Internet Draft September 1992 895 [9] Braun, H-W., "Models of Policy Based Routing", RFC 1104, 896 Merit/NSFNET, June 1989. 898 [10] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation 899 with CIDR", RFC1518, September 1993 901 [11] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4), 902 Internet Draft, cisco Systems, T.J. Watson Research Center, IBM 903 Corp., September 1992. 905 [12] Almquist, P., "Type of Service Routing in the Internet Protocol 906 Suite", RFC 1248, July 1992. 908 Authors' Addresses 910 Susan Hares 911 Merit, Inc 912 1071 Beal Avenue 913 Ann Arbor, MI 4810x 915 Phone: (313) 936-2095 916 Email: skh@merit.edu 918 John Scudder 919 Merit, Inc 920 1071 Beal Avenue 921 Ann Arbor, MI 4810x 923 Phone: (313) 764-5384 924 Email: jgs@merit.edu 926 IETF IDRP for IP WG mailing list: idrp-for-ip@merit.edu 927 To be added: idrp-request@merit.edu