idnits 2.17.1 draft-kunzinger-idrp-ISO10747-01.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-19) 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. ** Bad filename characters: the document name given in the document, 'draft-kunzinger-idrp-ISO10747-01', contains other characters than digits, lowercase letters and dash. == 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.) ** There are 4211 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 8251: '...priority [0] EXPLICIT Priority OPTIONAL,...' RFC 2119 keyword, line 8252: '...security [1] EXPLICIT SEC OPTIONAL,...' RFC 2119 keyword, line 8253: '...qosmaint [2] EXPLICIT QOS OPTIONAL } Ribattribute ::= ENUMERATED { tRANSITDELAY (9), rESIDUALERROR (10), eXPENSE (11), locDefQOS (12), Security (17), priority (20)} Ribvalue ::= SEQUENCE {length Ribattlength, attr Ribattributes} Ribattlength ::= INTEGER Ribattvalue ::= CHOICE {...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 101 has weird spacing: '...Minimum confi...' == Line 461 has weird spacing: '...ss-mode trans...' == Line 2770 has weird spacing: '...Minimum confi...' == Line 5772 has weird spacing: '... second is th...' == Line 5834 has weird spacing: '... by the local...' == (11 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 (November 1994) is 10748 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'R' is mentioned on line 3915, but not defined == Missing Reference: 'A' is mentioned on line 3905, but not defined == Missing Reference: 'I' is mentioned on line 3916, but not defined -- Looks like a reference, but probably isn't: '8' on line 8272 -- Looks like a reference, but probably isn't: '7' on line 6804 -- Looks like a reference, but probably isn't: '6' on line 8269 -- Looks like a reference, but probably isn't: '5' on line 6804 -- Looks like a reference, but probably isn't: '4' on line 6804 -- Looks like a reference, but probably isn't: '3' on line 6804 -- Looks like a reference, but probably isn't: '2' on line 9286 -- Looks like a reference, but probably isn't: '1' on line 9313 -- Looks like a reference, but probably isn't: '0' on line 8265 == Missing Reference: 'N' is mentioned on line 9314, but not defined == Unused Reference: 'Round 1' is defined on line 9351, but no explicit reference was found in the text == Unused Reference: 'Round 2' is defined on line 9374, but no explicit reference was found in the text == Unused Reference: 'Round 3' is defined on line 9400, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Round 1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Round 2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Round 3' Summary: 11 errors (**), 0 flaws (~~), 14 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft 2 C. Kunzinger, Editor 3 November 1994 5 INTER-DOMAIN ROUTING PROTOCOL (IDRP) 6 8 Status of This Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. Internet-Drafts are draft 14 documents valid for a maximum of six months. Internet-Drafts may 15 be updated, replaced, or obsoleted by other documents at any time. 16 It is not appropriate to use Internet-Drafts as reference material 17 or to cite them other than as a "working draft" or "work in 18 progress." 20 This draft document contains the complete text of ISO/IEC 21 International Standard 10747, which specifies an inter-domain 22 routing protocol commonly referred to as "IDRP". It is made 23 available in this form as part of an agreement between the Internet 24 Society and ISO/IEC JTC1 (which is responsible for Information 25 Technology standards as a joint activity of ISO and IEC). Those 26 figures that could easily be rendered in ASCII are included, but it 27 was not possible to create ASCII replicas for all figures included 28 in the International Standard. The PostScript version of this 29 document that includes all the figures is available (URL = 30 ftp://merit.edu/pub/iso/idrp.ps.Z). 32 Security Considerations 34 Issues concerning the security of routing information exchange 35 among border inter-domain routers are discussed in this memo. 37 Author's Address 39 Charles A. Kunzinger 40 IBM Corporation (C70/673) 41 P.O. Box 12195 42 Research Triangle Park, NC 27709-2195 43 Phone: 919 254 4142 44 EMail: kunzinger@vnet.ibm.com 45 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 47 Contents 49 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 51 2. Normative references . . . . . . . . . . . . . . . . . . . 14 53 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 17 54 3.1 Reference model definitions . . . . . . . . . . . . . . . 17 55 3.2 Network layer architecture definitions . . . . . . . . . . 17 56 3.3 Network layer addressing definitions . . . . . . . . . . . 18 57 3.4 Routeing framework definitions . . . . . . . . . . . . . . 18 58 3.5 Intra-domain routeing definitions . . . . . . . . . . . . 18 59 3.6 Additional definitions . . . . . . . . . . . . . . . . . . 18 61 4. Symbols and abbreviations . . . . . . . . . . . . . . . . . 21 62 4.1 Data unit abbreviations . . . . . . . . . . . . . . . . . 21 63 4.2 Addressing abbreviations . . . . . . . . . . . . . . . . . 21 64 4.3 Other abbreviations . . . . . . . . . . . . . . . . . . . 22 66 5. General protocol information . . . . . . . . . . . . . . . 23 67 5.1 Inter-RD topology . . . . . . . . . . . . . . . . . . . . 25 68 5.2 Routeing policy . . . . . . . . . . . . . . . . . . . . . 25 69 5.3 Types of systems . . . . . . . . . . . . . . . . . . . . . 26 70 5.4 Types of routeing domains . . . . . . . . . . . . . . . . 27 71 5.5 Routeing domain confederations . . . . . . . . . . . . . . 27 72 5.6 Routes: advertisement and storage . . . . . . . . . . . . 27 73 5.7 Distinguishing path attributes and RIB-Atts . . . . . . . 28 74 5.8 Selecting the information bases . . . . . . . . . . . . . 29 75 5.9 Routeing information exchange . . . . . . . . . . . . . . 32 76 5.9.1 Internal neighbor BIS . . . . . . . . . . . . . . . . 33 77 5.9.2 External neighbor BIS . . . . . . . . . . . . . . . . 33 78 5.10 Routeing domain identifiers . . . . . . . . . . . . . . . 33 79 5.11 Formats of RDIs, NETs, and NSAP addresses . . . . . . . . 34 80 5.12 Design objectives . . . . . . . . . . . . . . . . . . . . 34 81 5.12.1 Within the scope of the protocol . . . . . . . . . . 34 82 5.12.2 Outside the scope of the protocol . . . . . . . . . . 36 83 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 85 6. Structure of BISPDUs . . . . . . . . . . . . . . . . . . . 37 86 6.1 Header of BISPDU . . . . . . . . . . . . . . . . . . . . . 37 87 6.2 OPEN PDU . . . . . . . . . . . . . . . . . . . . . . . . . 40 88 6.3 UPDATE PDU . . . . . . . . . . . . . . . . . . . . . . . . 45 89 6.3.1 Path attribute encoding . . . . . . . . . . . . . . . 47 90 6.3.2 Network layer reachability information . . . . . . . . 59 91 6.4 IDRP ERROR PDU . . . . . . . . . . . . . . . . . . . . . . 61 92 6.5 KEEPALIVE PDU . . . . . . . . . . . . . . . . . . . . . . 64 93 6.6 CEASE PDU . . . . . . . . . . . . . . . . . . . . . . . . 65 94 6.7 RIB REFRESH PDU . . . . . . . . . . . . . . . . . . . . . 65 96 7. Elements of procedure . . . . . . . . . . . . . . . . . . . 66 97 7.1 Naming and addressing conventions . . . . . . . . . . . . 66 98 7.1.1 Interpretation of address information . . . . . . . . 66 99 7.1.2 NSAP address prefixes . . . . . . . . . . . . . . . . 66 100 7.2 Deployment guidelines . . . . . . . . . . . . . . . . . . 68 101 7.2.1 Minimum configuration of an RD . . . . . . . . . . . 68 102 7.2.2 Deployment of ISs and ESs . . . . . . . . . . . . . . 68 103 7.3 Domain configuration information . . . . . . . . . . . . . 69 104 7.4 Advertising NLRI . . . . . . . . . . . . . . . . . . . . . 70 105 7.5 Receive process . . . . . . . . . . . . . . . . . . . . . 72 106 7.6 BIS-BIS connection management . . . . . . . . . . . . . . 73 107 7.6.1 BIS finite state machines . . . . . . . . . . . . . . 73 108 7.6.2 Closing a connection . . . . . . . . . . . . . . . . . 87 109 7.7 Validation of BISPDUs . . . . . . . . . . . . . . . . . . 87 110 7.7.1 Authentication type 1 . . . . . . . . . . . . . . . . 88 111 7.7.2 Authentication type 2 . . . . . . . . . . . . . . . . 88 112 7.7.3 Authentication type 3 . . . . . . . . . . . . . . . . 89 113 7.7.4 Sequence numbers . . . . . . . . . . . . . . . . . . . 90 114 7.7.5 Flow control . . . . . . . . . . . . . . . . . . . . . 91 115 7.8 Version negotiation . . . . . . . . . . . . . . . . . . . 95 116 7.9 Checksum algorithm . . . . . . . . . . . . . . . . . . . . 95 117 7.10 Routeing information bases . . . . . . . . . . . . . . . 95 118 7.10.1 Identifying an information base . . . . . . . . . . . 96 119 7.10.2 Validation of RIBs . . . . . . . . . . . . . . . . . 97 120 7.10.3 Use of the RIB REFRESH PDU . . . . . . . . . . . . . 99 121 7.11 Path attributes . . . . . . . . . . . . . . . . . . . . . 100 122 7.11.1 Categories of path attributes . . . . . . . . . . . . 102 123 7.11.2 Handling of distinguishing attributes . . . . . . . . 103 124 7.11.3 Equivalent distinguishing attributes . . . . . . . . 104 125 7.12 Path attribute usage . . . . . . . . . . . . . . . . . . 105 126 7.12.1 ROUTE_SEPARATOR . . . . . . . . . . . . . . . . . . . 105 127 7.12.2 EXT_INFO . . . . . . . . . . . . . . . . . . . . . . 106 128 7.12.3 RD_PATH . . . . . . . . . . . . . . . . . . . . . . . 107 129 7.12.4 NEXT_HOP . . . . . . . . . . . . . . . . . . . . . . 111 130 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 132 7.12.5 DIST_LIST_INCL . . . . . . . . . . . . . . . . . . . 115 133 7.12.6 DIST_LIST_EXCL . . . . . . . . . . . . . . . . . . . 116 134 7.12.7 MULTI-EXIT_DISC . . . . . . . . . . . . . . . . . . . 117 135 7.12.8 TRANSIT DELAY . . . . . . . . . . . . . . . . . . . . 118 136 7.12.9 RESIDUAL ERROR . . . . . . . . . . . . . . . . . . . 118 137 7.12.10 EXPENSE . . . . . . . . . . . . . . . . . . . . . . 119 138 7.12.11 LOCALLY DEFINED QOS . . . . . . . . . . . . . . . . 120 139 7.12.12 HIERARCHICAL RECORDING . . . . . . . . . . . . . . . 121 140 7.12.13 RD_HOP_COUNT . . . . . . . . . . . . . . . . . . . . 122 141 7.12.14 SECURITY . . . . . . . . . . . . . . . . . . . . . . 123 142 7.12.15 CAPACITY . . . . . . . . . . . . . . . . . . . . . . 123 143 7.12.16 PRIORITY . . . . . . . . . . . . . . . . . . . . . . 124 144 7.13 Routeing domain confederations . . . . . . . . . . . . . 125 145 7.13.1 RDC policies . . . . . . . . . . . . . . . . . . . . 125 146 7.13.2 RDC configuration information . . . . . . . . . . . . 125 147 7.13.3 Detecting confederation boundaries . . . . . . . . . 126 148 7.14 Update-Receive process . . . . . . . . . . . . . . . . . 126 149 7.15 Information consistency . . . . . . . . . . . . . . . . . 127 150 7.15.1 Detecting inconsistencies . . . . . . . . . . . . . . 128 151 7.16 Decision process . . . . . . . . . . . . . . . . . . . . 128 152 7.16.1 Phase 1: calculation of degree of preference . . . . 130 153 7.16.2 Phase 2: route selection . . . . . . . . . . . . . . 130 154 7.16.3 Phase 3: route dissemination . . . . . . . . . . . . 133 155 7.16.4 Interaction with update process . . . . . . . . . . . 135 156 7.17 Update-Send process . . . . . . . . . . . . . . . . . . . 136 157 7.17.1 Internal updates . . . . . . . . . . . . . . . . . . 136 158 7.17.2 External updates . . . . . . . . . . . . . . . . . . 138 159 7.17.3 Controlling routeing traffic overhead . . . . . . . . 139 160 7.18 Efficient organization of routeing information . . . . . 141 161 7.18.1 Information reduction . . . . . . . . . . . . . . . . 141 162 7.18.2 Aggregating routeing information . . . . . . . . . . 142 163 7.19 Maintenance of the forwarding information bases . . . . . 148 164 7.20 Error handling for BISPDUs . . . . . . . . . . . . . . . 149 165 7.20.1 BISPDU header error handling . . . . . . . . . . . . 150 166 7.20.2 OPEN PDU error handling . . . . . . . . . . . . . . . 150 167 7.20.3 UPDATE PDU error handling . . . . . . . . . . . . . . 152 168 7.20.4 IDRP ERROR PDU error handling . . . . . . . . . . . . 155 169 7.20.5 Hold timer expired error handling . . . . . . . . . . 155 170 7.20.6 KEEPALIVE PDU error handling . . . . . . . . . . . . 156 171 7.20.7 CEASE PDU error handling . . . . . . . . . . . . . . 156 172 7.20.8 RIB REFRESH PDU error handling . . . . . . . . . . . 156 174 8. Forwarding process for CLNS . . . . . . . . . . . . . . . . 156 175 8.1 Forwarding to internal destinations . . . . . . . . . . . 158 176 8.2 Determining the NPDU-derived distinguishing attributes . . 158 177 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 179 8.3 Matching RIB-Att to NPDU-derived distinguishing attributes 160 180 8.4 Forwarding to external destinations . . . . . . . . . . . 162 182 9. Interface to ISO 8473 . . . . . . . . . . . . . . . . . . . 163 183 9.1 Use of network layer security protocol over ISO 8473. . . 165 185 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . 165 187 11. System management and GDMO definitions . . . . . . . . . . 167 188 11.1 Name binding . . . . . . . . . . . . . . . . . . . . . . 167 189 11.2 Managed objects for IDRP . . . . . . . . . . . . . . . . 168 190 11.3 Packages for IDRP . . . . . . . . . . . . . . . . . . . . 168 191 11.4 Attribute definitions . . . . . . . . . . . . . . . . . . 175 192 11.5 Parameter definitions . . . . . . . . . . . . . . . . . . 185 193 11.6 Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 187 194 11.7 ASN.1 modules . . . . . . . . . . . . . . . . . . . . . . 188 196 12. Conformance . . . . . . . . . . . . . . . . . . . . . . . 193 197 12.1 Static conformance for all BISs . . . . . . . . . . . . . 193 198 12.2 Conformance to optional functions . . . . . . . . . . . . 195 199 12.2.1 Generation of information in reduced form . . . . . . 195 200 12.2.2 Generation of well-known discretionary attributes . . 195 201 12.2.3 Propagation of well-known discretionary attributes 196 202 12.2.4 Peer entity authentication . . . . . . . . . . . . . 196 204 Annex A. PICS proforma . . . . . . . . . . . . . . . . . . . . 197 205 A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 197 206 A.2 Abbreviations and special symbols . . . . . . . . . . . . 198 207 A.2.1 Status symbols . . . . . . . . . . . . . . . . . . . . 198 208 A.3 Instructions for completing the PICS proforma . . . . . . 198 209 A.3.1 General structure of the PICS proforma . . . . . . . . 198 210 A.3.2 Additional information . . . . . . . . . . . . . . . . 199 211 A.3.3 Exception information . . . . . . . . . . . . . . . . 200 212 A.3.4 Conditional status . . . . . . . . . . . . . . . . . . 200 213 A.4 Identification . . . . . . . . . . . . . . . . . . . . . . 203 214 A.4.1 PICS proforma: IDRP implementation identification . . 203 215 A.4.2 PICS proforma: IDRP protocol summary . . . . . . . . . 204 216 A.4.3 PICS proforma: IDRP general . . . . . . . . . . . . . 204 217 A.4.4 PICS proforma: IDRP update send process . . . . . . . 207 218 A.4.5 PICS proforma: IDRP update receive process . . . . . . 207 219 A.4.6 PICS proforma: IDRP decision process . . . . . . . . . 207 220 A.4.7 PICS proforma: IDRP receive process . . . . . . . . . 208 221 A.4.8 PICS proforma: IDRP CLNS forwarding . . . . . . . . . 210 222 A.4.9 PICS proforma: IDRP authentication . . . . . . . . . . 210 223 A.4.10 PICS proforma: IDRP optional transitive attributes 211 224 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 226 A.4.11 PICS proforma: Generating IDRP well-known 227 discretionary attributes . . . . . . . . . . . . . . . . . . 212 228 A.4.12 PICS proforma: Propagating IDRP well-known 229 discretionary attributes . . . . . . . . . . . . . . . . . . 214 230 A.4.13 PICS proforma: Receiving IDRP well-known discretionary 231 attributes . . . . . . . . . . . . . . . . . . . . . . . . . 216 233 Annex B. IDRP checksum generation algorithm . . . . . . . . . 218 234 B.1 Mathematical notation . . . . . . . . . . . . . . . . . . 218 235 B.2 Algorithm description . . . . . . . . . . . . . . . . . . 218 237 Annex C. Bibliography . . . . . . . . . . . . . . . . . . . . 223 239 Annex D. Example of authentication type 2 . . . . . . . . . . 224 240 D.1 Authentication mechanism . . . . . . . . . . . . . . . . . 224 242 Annex E. Jitter algorithm . . . . . . . . . . . . . . . . . . 228 244 Annex F. Computing a checksum for an Adj-RIB . . . . . . . . . 230 246 Annex G. RIB overload . . . . . . . . . . . . . . . . . . . . 231 248 Annex H. Processor overload . . . . . . . . . . . . . . . . . 233 250 Annex J. Formation of RDCs . . . . . . . . . . . . . . . . . . 234 251 J.1 Forming a new lower level confederation . . . . . . . . . 234 252 J.2 Forming a higher level confederation . . . . . . . . . . . 236 253 J.3 Deleting a lowest level confederation . . . . . . . . . . 237 254 J.4 Deleting a higher level confederation . . . . . . . . . . 238 256 Annex K. Example usage of MULTI-EXIT_DISC attribute . . . . . 239 258 Annex L. Syntax and semantics for policy . . . . . . . . . . . 244 259 L.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 244 260 L.1.1 Preference statement . . . . . . . . . . . . . . . . . 245 261 L.1.2 Aggregation statement . . . . . . . . . . . . . . . . 247 262 L.1.3 Distribution statement . . . . . . . . . . . . . . . . 249 263 L.2 Policy configuration language BNF . . . . . . . . . . . . 251 264 L.2.1 PREF statement BNF . . . . . . . . . . . . . . . . . . 251 265 L.2.2 AGGR statement BNF . . . . . . . . . . . . . . . . . . 252 266 L.2.3 DIST statement BNF . . . . . . . . . . . . . . . . . . 252 267 L.2.4 Common BNF symbols . . . . . . . . . . . . . . . . . . 253 268 L.3 Simple example . . . . . . . . . . . . . . . . . . . . . . 257 269 L.3.1 Transit domain 3 . . . . . . . . . . . . . . . . . . . 257 270 L.3.2 Policy configuration example . . . . . . . . . . . . . 259 271 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 273 L.3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . 259 275 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 276 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 278 Figures 280 1. Field of Application . . . . . . . . . . . . . . . . . . . 15 281 2. Intermediate Routeing Domains and End Routeing Domains . . 19 282 3. Position of IDRP within Network Layer . . . . . . . . . . 24 283 4. Inter-domain Routeing Components . . . . . . . . . . . . . 24 284 5. Structure of the UPDATE PDU . . . . . . . . . . . . . . . 46 285 6. Illustration of Authentication Types 1 and 3 . . . . . . . 88 286 7. Routeing Information Base . . . . . . . . . . . . . . . . 96 287 8. A Transitive Fully Connected Subnetwork . . . . . . . . . 112 288 9. IDRP Naming and Containment Hierarchy . . . . . . . . . . 168 289 10. An Example of the Authentication Type 2 . . . . . . . . . 227 290 11. Example 1 Configuration . . . . . . . . . . . . . . . . . 240 291 12. Example 2 Configuration . . . . . . . . . . . . . . . . . 241 292 13. A Portion of an Internet . . . . . . . . . . . . . . . . . 258 293 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 295 Tables 297 1. The IDRP Information Bases . . . . . . . . . . . . . . . . 29 298 2. BIS Finite State Machine . . . . . . . . . . . . . . . . . 76 299 3. Path Attribute Characteristics . . . . . . . . . . . . . . 100 300 4. NPDU-Derived Attribute Set . . . . . . . . . . . . . . . . 159 301 5. IDRP-CL Primitives . . . . . . . . . . . . . . . . . . . . 164 302 6. Architectural Constants of IDRP . . . . . . . . . . . . . 166 303 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 305 Foreword 307 ISO (the International Organization for Standardization) and IEC (the 308 International Electrotechnical Commission) form the specialized 309 system for worldwide standardization. National bodies that are 310 members of ISO or IEC participate in the development of International 311 Standards through technical committees established by the respective 312 organization to deal with particular fields of technical activity. 313 ISO and IEC technical committees collaborate in fields of mutual 314 interest. Other international organizations, governmental and 315 non-governmental, in liaison with ISO and IEC, also take part in the 316 work. 318 In the field of information technology, ISO and IEC have established 319 a joint technical committee, ISO/IEC JTC 1. Draft International 320 Standards adopted by the joint technical committee are circulated to 321 the national bodies for voting. Publication as an International 322 Standard requires approval by at least 75% of the national bodies 323 casting a vote. 325 International Standard ISO 10747 was prepared by Joint Technical 326 Committee ISO/IEC JTC 1, Information Technology. 328 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 330 Introduction 332 This Protocol is one of a set of International Standards which 333 facilitate the interconnection of open systems. They cover the 334 services and protocols required to achieve such interconnection. 336 This Protocol is positioned with respect to other related standards 337 by the layered structure defined in ISO 7498, and by the Network 338 layer organization defined in ISO 8648. It is located at the top of 339 the Network layer and relies on the services of ISO 8473. This 340 protocol permits a routeing domain to exchange information with other 341 routeing domains to facilitate the operation of the routeing and 342 relaying functions of the Network Layer. It applies to the following 343 categories of routeing, which are described in ISO/IEC TR 9575, 344 making no distinction between them: 346 - Intra-Administrative Domain routeing between routeing domains 347 - Inter-Administrative Domain routeing between routeing domains. 349 Within the hierarchical relations between routeing protocols, as 350 described in ISO/IEC TR 9575, this protocol is situated above the 351 intra-domain routeing protocols. That is, this Inter-domain IS-IS 352 protocol: 354 - maintains information about the interconnections between routeing 355 domains, but does not require detailed information about their 356 internal structures 358 - calculates path segments on a hop-by-hop basis 360 This protocol calculates path segments which consist of Boundary 361 Intermediate systems and the links that interconnect them. An NPDU 362 destined for an End system in another routeing domain will be routed 363 via Intra-domain routeing to a Boundary Intermediate system (BIS) in 364 the source routeing domain. Then, the BIS, using the methods of this 365 inter-domain routeing protocol, will calculate a path to a Boundary 366 Intermediate system in an adjacent routeing domain lying on a path to 367 the destination. After arriving at the next routeing domain, the 368 NPDU may also travel within that domain on its way towards a BIS 369 located in the next domain along its path. This process will 370 continue on a hop-by-hop basis until the NPDU arrives at a BIS in the 371 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 373 routeing domain which contains the destination End system. The 374 Boundary IS in this routeing domain will hand the incoming NPDU over 375 to the domain's intra-domain routeing protocol, which will construct 376 a path to the destination End system. 378 This inter-domain IS-IS routeing protocol places requirements on the 379 type of information that a routeing domain must provide and on the 380 methods by which this information will be distributed to other 381 routeing domains. These requirements are intended to be minimal, 382 addressing only the interactions between Boundary ISs; all other 383 internal operations of each routeing domain are outside the scope of 384 this protocol. That is, this Inter-domain routeing protocol does not 385 mandate that a routeing domain run a particular intra-domain routeing 386 protocol: for example, it would be a local choice as to whether a 387 domain implements a standard intra-domain protocol (such as ISO/IEC 388 10589) or a private protocol. 390 The methods of this protocol differ from those generally adopted for 391 an intra-domain routeing protocol because they emphasize the 392 interdependencies between efficient route calculation and the 393 preservation of legal, contractual, and administrative concerns. 394 This protocol calculates routes which will be efficient, loop-free, 395 and in compliance with the domain's local routeing policies. IDRP 396 may be used when routeing domains do not fully trust each other; it 397 imposes no upper limit on the number of routeing domains that can 398 participate in this protocol; and it provides isolation between its 399 operations and the internal operations of each routeing domain. 401 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 403 Information technology - Telecommunications and information exchange 404 between systems - Protocol for exchange of inter-domain routeing 405 information among intermediate systems to support forwarding of 406 ISO 8473 PDUs 408 1. Scope 410 This International Standard specifies a protocol to be used by 411 Boundary Intermediate systems (defined in 3.6) to acquire and 412 maintain information for the purpose of routeing NPDUs between 413 different routeing domains. Figure 1 illustrates the field of 414 application of this International Standard. 416 This International Standard specifies: 418 - the procedures for the exchange of inter-domain reachability and 419 path information between BISs 420 - the procedures for maintaining inter-domain routeing information 421 bases within a BIS 422 - the encoding of protocol data units used to distribute 423 inter-domain routeing information between BISs 424 - the functional requirements for implementations that claim 425 conformance to this International Standard 427 The procedures are defined in terms of: 429 - interactions between Boundary Intermediate systems through the 430 exchange of protocol data units 431 - interactions between this protocol and the underlying Network 432 Service through the exchange of service primitives 433 - constraints on policy feasibility and enforcement which must be 434 observed by each Boundary Intermediate system in a routeing 435 domain 436 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 438 The boundaries of Administrative Domains are realized as artifacts of 439 the placement of policy constraints and the aggregation of network 440 layer reachability information; they are not manifested explicitly in 441 the protocol. The protocol described in this International Standard 442 operates at the level of individual routeing domains. The 443 establishment of administrative domains is outside the scope of this 444 International Standard. 446 2. Normative references 448 The following standards contain provisions which, through reference 449 in this text, constitute provisions of this International Standard. 450 At the time of publication, the editions indicated were valid. All 451 standards are subject to revision, and parties to agreements based on 452 this International Standard are encouraged to investigate the 453 possibility of applying the most recent editions of the standards 454 listed below. Members of IEC and ISO maintain registers of currently 455 valid International Standards. 457 ISO 7498: 1984, Information Processing Systems - Open Systems 458 Interconnection - Basic Reference Model. 460 ISO 7498/Add. 1:1984, Information Processing Systems - Open Systems 461 Interconnection - Connectionless-mode transmission. 463 ISO 7498:1989, Information Processing Systems - Open Systems 464 Interconnection - Basic Reference Model - Part 3: Naming and 465 addressing. 467 ISO/IEC 7498, Information Processing Systems - Open Systems 468 Interconnection - Basic Reference Model - Part 4: Management 469 framework. 471 ISO/IEC 8208:1990, &it. Data communications - X.25 Packet Layer 472 Protocol for Data Terminal Equipment. 474 ISO/IEC 8348:1993, &it. Network Service Definition. 476 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 478 +----------------------------------------------------------------------+ 479 | | 480 | :psc=apa. | 481 | inter | 482 | +--------------+ +------------------+ +--------------+ | 483 | | End Routeing | | Transit Routeing | | End Routeing | | 484 | | Domain | | Domain | | Domain | | 485 | +--------------+ +------------------+ +--------------+ | 486 | \ / | - / | 487 | \ / | - / | 488 | \ / | - / | 489 | \ / | - / | 490 | +------------------+ | +------------------+ | 491 | | Transit Routeing | | | Transit Routeing | | 492 | | Domain | | | Domain | | 493 | +------------------+ | +------------------+ | 494 | / \ | | | 495 | / \ | | | 496 | / \ | | | 497 | +--------------+ +------------------+ | | 498 | | End Routeing | | Transit Routeing | | | 499 | | Domain | | Domain | | | 500 | +--------------+ +------------------+ | | 501 | | | | 502 | | | | 503 | | | | 504 | +--------------+ +--------------+ | 505 | | End Routeing | | End Routeing | | 506 | | Domain | | Domain | | 507 | +--------------+ +--------------+ | 508 | \ / | 509 | \ / | 510 | \ / | 511 | +------------------+ | 512 | | Transit Routeing | | 513 | | Domain | | 514 | +------------------+ | 515 | | 516 | | 517 +----------------------------------------------------------------------+ 518 Figure 1. Field of Application. The Inter-domain Routeing Protocol 519 operates between routeing domains; intra-domain routeing is 520 not within its scope. 522 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 524 ISO 8473:1988, Information Processing Systems - Data communications 525 - Protocol for providing the connectionless-mode network service. 527 ISO 8648: 1988, Information Processing Systems - Telecommunications 528 and Information Exchange between Systems - Internal organization of 529 the Network Layer. 531 ISO 9542:1988, Information Processing Systems - Telecommunications 532 and Information Exchange between Systems - End system to Intermediate 533 system routeing exchange protocol for use in conjunction with the 534 Protocol for providing the connectionless-mode network service (ISO 535 8473). 537 ISO/IEC TR 9575:1992, &it. Telecommunications and Information 538 Exchange between Systems - OSI Routeing Framework. 540 ISO/IEC TR 9577:1991, &it. Telecommunications and Information 541 Exchange between Systems - Protocol identification in the Network 542 Layer. 544 ISO/IEC 10030:1990, &it. Telecommunications and Information Exchange 545 between Systems - End System Routeing Information Exchange Protocol 546 for use in conjunction with ISO 8878. 548 ISO/IES 10589:1992, &it. Telecommunications and Information Exchange 549 between Systems - Intermediate system to intermediate system 550 intra-domain routeing information exchange protocol for use in 551 conjunction with the protocol for providing the connectionless-mode 552 Network Service (ISO 8473). 554 ISO/IEC 10165-4:1992, &it. Open Systems Interconnection - Structure 555 of management information - Part 4: Guidelines for the definition of 556 managed objects. 558 ISO/IEC 10165-2:1992, &it. Open Systems Interconnection - Structure 559 of management information: Definition of management information. 561 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 563 3. Definitions 565 For the purposes of this International Standard, the following 566 definitions apply. 568 3.1 Reference model definitions 570 This International Standard uses the following terms defined in 571 ISO 7498: 573 a) Network entity 574 b) Network Layer 575 c) Network Protocol 576 d) Network Protocol Data Unit 577 e) Network relay 578 f) Network Service Access Point 579 g) Network Service Access Point Address 580 h) Real system 581 i) Routeing 583 This International Standard uses the following term defined in ISO 584 7498-3: 586 a) (N)-entity title 588 3.2 Network layer architecture definitions 590 This International Standard uses the following terms defined in 591 ISO 8648: 593 a) End system 594 b) Intermediate System 595 c) Subnetwork 596 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 598 3.3 Network layer addressing definitions 600 This International Standard uses the following term defined in 601 ISO/IEC 8348: 603 a) Subnetwork point of attachment 605 3.4 Routeing framework definitions 607 This International Standard uses the following terms defined in 608 ISO 9575: 610 a) Administrative Domain 611 b) Common Domain 612 c) Fire wall 613 d) Routeing Domain 615 3.5 Intra-domain routeing definitions 617 This International Standard uses the following terms defined in ISO 618 10589: 620 a) Adjacency 621 b) Link 623 3.6 Additional definitions 625 For purposes of this International Standard, the following 626 definitions apply: 628 3.6.1 Intra-domain IS-IS routeing protocol: A routeing protocol that 629 is run between Intermediate systems in a single routeing domain to 630 determine routes that pass through only systems and links wholly 631 contained within the domain. 633 Note 1: Unless reference is made to a specific protocol, this term 634 is used as a general designator, encompassing both private 635 and internationally standardized protocols. 637 3.6.2 Inter-domain link: A real (physical) or virtual (logical) link 638 between two or more Boundary Intermediate systems (see Figure 2). A 639 link between two BISs in the same routeing domain carry both 640 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 642 +----------------------------------------------------------------------+ 643 | | 644 | irderd | 645 | | 646 +----------------------------------------------------------------------+ 647 Figure 2. Intermediate Routeing Domains and End Routeing Domains. The 648 classification of a routeing domain as an TRD or an ERD 649 depends upon its relaying policies. 651 intra-domain traffic and inter-domain traffic; a link between two 652 BISs located in adjacent routeing domains can carry inter-domain 653 traffic, but not intra-domain traffic. 655 3.6.3 Boundary Intermediate system: An intermediate system that runs 656 the protocol specified in this International Standard, has at least 657 one inter-domain link attached to it, and may optionally have 658 intra-domain links attached to it. 660 3.6.4 End Routeing Domain: A routeing domain whose local policies 661 permit its BISs to calculate inter-domain path segments only for PDUs 662 whose source is located within that routeing domain. There are two 663 varieties of End routeing domains: stub and multi-homed. A stub ERD 664 has inter-domain links to only one adjacent routeing domain, while a 665 multi-homed ERD has inter-domain links to several adjacent routeing 666 domains. 668 For example, the domains labelled as multi-homed ERDs in Figure 2 669 have policies which prohibit them from providing relaying functions; 670 it is these policies, not the topology of their interconnections, 671 that make them ERDs. 673 3.6.5 Transit Routeing Domain: A routeing domain whose policies 674 permit its BISs to calculate inter-domain path segments for PDUs 675 whose source is located either in the local routeing domain or in a 676 different routeing domain. That is, it can provide a relaying 677 service for such PDUs. See Figure 2 for an illustration of TRDs. 679 3.6.6 Adjacent RDs: Two RDs ("A" and "B") are adjacent to one another 680 if there is a at least one pair of BISs, one located in "A" and the 681 other in "B", that are attached to each other by means of a real 682 subnetwork. 684 3.6.7 RD Path: A list of the RDIs of the routeing domains and 685 routeing domain confederations through which a given UPDATE PDU has 686 travelled. 688 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 690 3.6.8 Routeing Domain Confederation: A set of routeing domains which 691 have agreed to join together and to conform to the rules in 7.13 of 692 this International Standard. To the outside world, a confederation 693 is indistinguishable from a routeing domain. 695 3.6.9 Nested RDCs: A routeing domain confederation "A" (RDC-A) is 696 nested within RDC-B when all of the following conditions are 697 satisfied simultaneously: 699 a) all members of RDC-A are also members of RDC-B 700 b) there are some members of RDC-B that are not members of RDC-A 702 3.6.10 Overlapping RDCs: A routeing domain confederation (RDC-A) 703 overlaps RDC-B when all the following conditions are satisfied 704 simultaneously: 706 a) there are some members of RDC-A that are also members of RDC-B, 707 and 708 b) there are some members of RDC-A that are not members of RDC-B, 709 and 710 c) there are some members of RDC-B that are not members of RDC-A. 712 3.6.11 Disjoint RDCs: Two routeing domain confederations, RDC-A and 713 RDC-B, are disjoint from one another when there are no routeing 714 domains which are simultaneously members of both RDC-A and RDC-B. 716 3.6.12 Policy Information Base: The collection of routeing policies 717 that a BIS will apply to the routeing information that it learns 718 using this International standard. It is not required that all 719 routeing domains use the same syntax and semantics to express policy; 720 that is, the format of the Policy Information Base is left as a local 721 option. 723 3.6.13 Route Origin: Each route or component of an aggregated route 724 has a single unique origin. This is the RD or RDC in which the 725 route's destinations are located. 727 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 729 4. Symbols and abbreviations 731 The symbols, acronyms, and abbreviations listed in the following 732 clauses are used in this International Standard. 734 4.1 Data unit abbreviations 736 BISPDU Boundary Intermediate System PDU 738 DT PDU ISO 8473 Data Protocol Data Unit 740 ER PDU ISO 8473 Error Protocol Data Unit 742 NPDU Network Protocol Data Unit 744 NSDU Network Service Data Unit 746 PDU Protocol Data Unit 748 4.2 Addressing abbreviations 750 AFI Authority and Format Identifier 752 DSP Domain Specific Part 754 IDI Initial Domain Identifier 756 IDP Initial Domain Part 758 LSAP Link Service Access Point 760 NET Network Entity Title 762 NPAI Network Protocol Address Information 764 NSAP Network Service Access Point 766 SNPA Subnetwork Point of Attachment 767 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 769 4.3 Other abbreviations 771 BIS Boundary Intermediate System 773 CL Connectionless Mode 775 CLNS Connectionless Mode Network Service 777 CM Confederation Member 779 ERD End Routeing Domain 781 ES End System 783 FIB Forwarding Information Base 785 FSM Finite State Machine 787 IDRP Inter-domain Routeing Protocol (an acronym for the protocol 788 described in this International Standard) 790 IPI Initial Protocol Identifier 792 MIB Management Information Base 794 NLRI Network layer reachability information 796 NLSP Network layer security protocol 798 OSIE OSI Environment 800 PCI Protocol Control Information 802 PIB Policy Information Base 804 QOS Quality of Service 806 RDC Routeing Domain Confederation 808 RDI Routeing Domain Identifier 810 RIB Routeing Information Base 812 SPI Subsequent Protocol Identifier 813 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 815 SNICP Subnetwork independent convergence protocol 817 TRD Transit Routeing Domain 819 5. General protocol information 821 IDRP is a routeing information exchange protocol which is located 822 within the Network layer and interfaces to ISO 8473, which serves as 823 a SNICP (see Figure 3). In particular, BISPDUs are encapsulated as 824 the data portion of ISO 8473 NPDUs. IDRP is a connection-oriented 825 protocol which is implemented only in Intermediate systems. Routeing 826 and control information is carried in BISPDUs (as in clause 6), which 827 flow on connections between pairs of BISs. Each BISPDU is packaged 828 within one or more NPDUs for transmission by the underlying Network 829 service. IDRP relies on the underlying Network service to provide 830 for fragmentation and reassembly of BISPDUs. IDRP queues Outbound 831 BISPDUs as input to the underlying Network Layer service, retaining a 832 copy of each BISPDU until an acknowledgement is received. Similarly, 833 inbound BISPDUs are queued as input to the BISPDU-Receive process. 835 IDRP exchanges BISPDUs in a reliable fashion. It provides mechanisms 836 for the ordered delivery of BISPDUs and for the detection and 837 retransmission of lost or corrupted BISPDUs. The mechanisms for 838 achieving reliable delivery of BISPDUs are described in 7.7; methods 839 for establishing BIS-BIS connections are described in 7.6. 841 IDRP is consistent with the routeing model presented in ISO TR 9575. 842 To emphasize its policy-based nature, the IDRP routeing model 843 includes a Policy Information Base, as shown in Figure 4. IDRP can 844 be described in terms of four major components: 846 a) BISPDU-Receive Process: responsible for accepting and processing 847 control and routeing information from the local environment and 848 from BISPDUs of other BISs. This information is used for a 849 variety of purposes, such as receiving error reports and 850 guaranteeing reliable reception of BISPDUs from neighboring BISs. 851 (For example, the Update-Receive process (see 7.14) is the part 852 of the BISPDU-Receive process that deals with the reception of 853 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 855 +----------------------------------------------------------------------+ 856 | | 857 | ---------- +-------------------+ | 858 | | | Inter-Domain | | 859 | | | Routeing Protocol | | 860 | | | (IDRP) | | 861 | | +-------------------+ | 862 | | | | | 863 | Network | ISO 8473 | | 864 | Layer | | | 865 | | | | | 866 | | | | | 867 | ---------- +-------------------+ | 868 | | 869 +----------------------------------------------------------------------+ 870 Figure 3. Position of IDRP within Network Layer 872 routeing information after a BIS-BIS connection has been 873 established.) 875 b) BISPDU-Send Process: responsible for constructing BISPDUs which 876 contain control and routeing information. BISPDUs are used by 877 the local BIS for a variety of purposes, such as advertising 878 routeing information to other BISs, initiating BIS-BIS 879 communication, and validating BIS routeing information bases. 881 c) Decision Process: responsible for calculating routes which will 882 be consistent with local routeing policies. It operates on 883 information in both the PIB and the Adj-RIBs, using it to create 884 the Local RIBs (Loc-RIBs) and the local Forwarding Information 885 Bases (see 7.10). 887 d) Forwarding Process: responsible for supplying resources to 888 accomplish relaying of NPDUs to their destinations. It uses the 889 FIB(s) created by the Decision Process. 891 +----------------------------------------------------------------------+ 892 | | 893 | tr95753 | 894 | | 895 +----------------------------------------------------------------------+ 896 Figure 4. Inter-domain Routeing Components 897 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 899 5.1 Inter-RD topology 901 This protocol views the overall global OSIE as an arbitrary 902 interconnection of Transit Routeing Domains and End Routeing Domains 903 which are connected by real inter-domain links placed between BISs 904 located in the respective routeing domains. This International 905 Standard provides for the direct exchange of routeing information 906 between BISs, which may be located either in the same routeing domain 907 or in adjacent routeing domains. 909 5.2 Routeing policy 911 The direct exchange of policy information is outside the scope of 912 IDRP. Instead, IDRP communicates policy information indirectly in 913 its UPDATE PDUs which reflect the effects of the local policies of 914 RDs on the path to the destination. Since all BISs within a routeing 915 domain must enforce consistent active routeing policies, IDRP 916 provides methods for detecting the existence of active inconsistent 917 policies within a routeing domain. However, the semantics of 918 routeing policies and the methods for establishing them are outside 919 the scope of this International Standard. 921 Note 2: Annex L illustrates a policy description method and its 922 associated semantics as one example of how policies might be 923 expressed. 925 Each routeing domain chooses its routeing policies independently, and 926 insures that all its BISs calculate inter-domain paths which satisfy 927 those policies. Local routeing policies are applied to information 928 in the Routeing Information Base (RIB) to determine a degree of 929 preference for potential paths (see 7.16). From those paths which 930 are not rejected by the routeing policy, a BIS selects the paths 931 which it will use locally; from the locally selected paths, the BIS 932 will then select the paths that it will advertise externally. 934 To enforce routeing policies and to insure that policies are both 935 feasible and consistent, this protocol: 937 - carries path information, expressed in terms of Routeing Domain 938 Identifiers (RDIs) and various path attributes, in its UPDATE 939 PDUs 940 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 942 - permits a routeing domain to selectively propagate its 943 reachability information to a limited set of other routeing 944 domains 946 - provides a method to detect policy inconsistencies within the set 947 of BISs located in a single routeing domain 949 - permits each routeing domain to set its policies individually: 950 that is, global coordination of policy is not required. 952 The set of rules that comprises the routing policy enforced by a BIS 953 are held in a Policy Information Base (PIB), which is separate from 954 the RIB. Depending on local Security and QOS requirements, the PIB 955 may also contain: 957 a) rules for the aggregation of routes that include the SECURITY and 958 LOCALLY DEFINED QOS path attributes (see 7.18.2) 960 b) rules for enforcing local QOS Maintenance Policies and the 961 effective Security Policy, during NPDU forwarding 963 c) rules for updating SECURITY and LOCALLY DEFINED QOS path 964 attributes in routes that are re-advertised to external routeing 965 domains. 967 5.3 Types of systems 969 An Intermediate system that implements the protocol described in this 970 International Standard is called a Boundary Intermediate system 971 (BIS). Each BIS resides in a single routeing domain, and may 972 optionally act simultaneously as a BIS and as an intra-domain IS 973 within its own routeing domain. For example, a single system could 974 simultaneously play the roles of a BIS for Inter-domain routeing and 975 a level-2 IS for Intra-domain routeing as described in ISO/IEC 10589. 977 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 979 5.4 Types of routeing domains 981 The protocol described in this International Standard recognizes two 982 types of routeing domains, end routeing domains and transit routeing 983 domains; each of them may contain both ISs and ESs. 985 5.5 Routeing domain confederations 987 IDRP provides support for Routeing Domain Confederations (RDCs); this 988 optional function permits groups of routeing domains to be organized 989 in a hierarchical fashion. 991 An RDC is formed by means outside the scope of this protocol, and 992 composed of a set of confederation members. Confederation members 993 (CMs) are either individual routeing domains or routeing domain 994 confederations. Thus, the definition of an RDC is recursive: a 995 confederation member may be a single routeing domain or another 996 confederation. 998 5.6 Routes: advertisement and storage 1000 For purposes of this protocol, a route is defined as a unit of 1001 information that pairs destinations with the attributes of a path to 1002 those destinations: 1004 - Routes are advertised between a pair of BISs in UPDATE PDUS: the 1005 destinations are the systems whose NSAP prefixes are reported in 1006 the NLRI field, and the path is the information reported in the 1007 path attributes fields of the same UPDATE PDU. 1009 - Routes are stored in the Routeing Information Bases: namely, the 1010 Adj-RIBs-In, the Loc-RIBs, and the Adj-RIBs-Out. Routes that 1011 will be advertised to other BISs must be present in the 1012 Adj-RIBs-Out; routes that will be used by the local BIS must be 1013 present in the Loc-RIBs, and the next hop for each of these 1014 routes must present in the local BIS's Forwarding Information 1015 Bases; and routes that are received from other BISs are present 1016 in the Adj-RIBs-In. 1018 - A Route-ID is assigned to each route that is advertised by a BIS. 1019 This identifier is unambiguous in the context of the BIS-BIS 1020 connection between the advertising BIS and the receiving BIS. 1022 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1024 A BIS can support multiple routes to the same destination by 1025 maintaining multiple RIBs and the corresponding multiple FIBs. Each 1026 Loc-RIB will be identified by a different RIB-Att (see 5.7 and 5.8); 1027 an Adj-RIB-Out shall contain at most one route to a particular 1028 destination. 1030 If the BIS chooses to advertise the route, it may add to or modify 1031 the path attributes of the route before advertising it to adjacent 1032 BISs. For example, it is possible under certain circumstances to 1033 aggregate path attributes, NLRI, or entire routes, as described more 1034 fully in 7.18.2; or, as another example, the further distribution of 1035 a route may be restricted through the use of the DIST_LIST_EXCL 1036 attribute, as described in 7.12.6. 1038 IDRP also provides mechanisms by which a BIS can inform its neighbor 1039 that a previously advertised route is no longer available for use. 1040 There are three methods by which a given BIS can indicate that a 1041 route has been withdrawn from service: 1043 a) the Route-ID for a previously advertised route can be advertised 1044 in the WITHDRAWN ROUTES field of an UPDATE PDU, thus marking the 1045 associated route as being no longer available for use 1046 b) a replacement route (with the same distinguishing attributes and 1047 NLRI) can be advertised, or 1048 c) the BIS-BIS connection can be closed, which implicitly removes 1049 from service all routes which the pair of BISs had advertised to 1050 each other. 1052 5.7 Distinguishing path attributes and RIB-Atts 1054 Certain path attributes are classified as Distinguishing Attributes. 1055 Each distinct combination of such attributes identifies a particular 1056 information base which will be used to store information about the 1057 route. Each combination of distinguishing attributes is called a 1058 RIB-Att (RIB attribute); the RIB-Att is a common identifier for the 1059 Adj-RIB-In, Loc-RIB, Adj-RIB-Out, and FIB with which the route 1060 information is associated. 1062 The number of RIB-Atts is limited by the number of distinct sets of 1063 permissible distinguishing attributes (see 7.11.2); this in turn 1064 limits the number of RIBs and FIBs that a BIS can support. The 1065 number of RIBs and FIBs can be further constrained by local 1066 decisions--a BIS may choose to support only a limited number of 1067 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1069 distinct routeing information bases (that is, a limited number of 1070 RIB-Atts, as described in 7.10.1). 1072 5.8 Selecting the information bases 1074 Each RIB is identified by a RIB-Att (RIB attribute), and the same 1075 RIB-Att also uniquely identifies the associated FIB. 1077 For an UPDATE PDU, the BIS determines the ROUTE_ID, LOCAL_PREF, and 1078 the set of distinguishing path attributes associated with each route 1079 that is advertised. The set of distinguishing path attributes 1080 contained between a pair of consecutively occurring ROUTE_SEPARATORs 1081 or between the last ROUTE_SEPARATOR and the end of the BISPDU 1082 unambiguously determine the RIB-Att for that route. 1084 For an NPDU, the BIS unambiguously determines the FIB that should be 1085 used for forwarding this NPDU. It maps certain fields in NPDU's 1086 header into a RIB-Att, which then unambiguously identifies a 1087 particular FIB (see 8.2 and 8.3). 1089 A summary of IDRP's information bases is presented in Table 1. 1091 +----------------------------------------------------------------------+ 1092 | Table 1 (Page 1 of 3). The IDRP Information Bases. The indexing | 1093 | variables and contents of the RIBs and FIBs | 1094 | are shown. | 1095 +-----------------+-----------------+----------------------------------+ 1096 | Information | Indexed by... | Contains... | 1097 | Base | | | 1098 +-----------------+-----------------+----------------------------------+ 1099 | Adj-RIB-In | - NET of | - Path attributes | 1100 | | adjacent | - NLRI | 1101 | | BIS | | 1102 | | - RIB-Atts | | 1103 | | - Route-ID | | 1104 +-----------------+-----------------+----------------------------------+ 1105 | Loc-RIB | - RIB-Atts | - Path attributes | 1106 | | | - NLRI | 1107 +-----------------+-----------------+----------------------------------+ 1108 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1110 +----------------------------------------------------------------------+ 1111 | Table 1 (Page 2 of 3). The IDRP Information Bases. The indexing | 1112 | variables and contents of the RIBs and FIBs | 1113 | are shown. | 1114 +-----------------+-----------------+----------------------------------+ 1115 | Information | Indexed by... | Contains... | 1116 | Base | | | 1117 +-----------------+-----------------+----------------------------------+ 1118 | Adj-RIB-Out | - NET of | - Path attributes | 1119 | | adjacent | - NLRI | 1120 | | BIS | | 1121 | | - RIB-Atts | | 1122 | | - Route-ID | | 1123 +-----------------+-----------------+----------------------------------+ 1124 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1126 +----------------------------------------------------------------------+ 1127 | Table 1 (Page 3 of 3). The IDRP Information Bases. The indexing | 1128 | variables and contents of the RIBs and FIBs | 1129 | are shown. | 1130 +-----------------+-----------------+----------------------------------+ 1131 | Information | Indexed by... | Contains... | 1132 | Base | | | 1133 +-----------------+-----------------+----------------------------------+ 1134 | FIB | - RIB-Atts | - NET of next hop BIS | 1135 | | - NLRI | - Output SNPA of local BIS | 1136 | | | - Input SNPA of next hop BIS | 1137 | | | - minimum priority associated | 1138 | | | with this subnetwork, when | 1139 | | | the RIB-Att contains the | 1140 | | | PRIORITY attribute | 1141 | | | - security related information | 1142 | | | associated with this | 1143 | | | subnetwork, when the RIB-Att | 1144 | | | contains the SECURITY | 1145 | | | attribute | 1146 | | | - QOS metric value, when the | 1147 | | | RIB-Att contains a RESIDUAL | 1148 | | | ERROR, TRANSIT DELAY, | 1149 | | | EXPENSE, or LOCALLY DEFINED | 1150 | | | QOS attribute | 1151 +-----------------+-----------------+----------------------------------+ 1152 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1154 +----------------------------------------------------------------------+ 1155 | Notes: | 1156 | | 1157 | a) As a local option, a BIS may elect to apply information | 1158 | reduction techniques to path attributes and NLRI information. | 1159 | | 1160 | b) For each adjacent BIS, a given BIS maintains an Adj-RIB-In for | 1161 | each RIB-Att (including the Empty RIB-Att) that it supports. | 1162 | | 1163 | c) A BIS maintains a separate Loc-RIB for each RIB-Att (including | 1164 | the Empty RIB-Att) that it supports. | 1165 | | 1166 | d) For each adjacent BIS, a given BIS maintains an Adj-RIB-Out for | 1167 | each set of RIB-Atts (including the Empty RIB-Att) that it | 1168 | advertises to that neighbor. | 1169 | | 1170 | e) A given BIS maintains a separate FIB for each set of RIB-Atts | 1171 | (including the empty RIB-Att) that it supports-- that is, each | 1172 | FIB corresponds to a Loc-RIB. | 1173 | | 1174 | To facilitate the forwarding process, a BIS can organize each of | 1175 | its FIBS into two conceptual parts: one containing information | 1176 | for NLRI located within its own RD, and another for NLRI located | 1177 | in other RDs (as in clause 8). For external NLRI, a BIS can | 1178 | further organize the FIB information based on whether the | 1179 | next-hop-BIS is located within its own RD or in another RD (see | 1180 | 8.4, items "a" and "b"). And finally, for those next-hop BISs | 1181 | located in its own RD, the local BIS can organize the | 1182 | information according to a specific forwarding mechanism (see | 1183 | 8.4, items "b1" and "b2"). | 1184 +----------------------------------------------------------------------+ 1186 5.9 Routeing information exchange 1188 This International Standard provides several rules governing the 1189 distribution and exchange of routeing information: 1191 - rules for distributing routeing information internally (to BISs 1192 within a routeing domain) 1194 - rules for distributing routeing information externally (to BISs 1195 in adjacent routeing domains) 1196 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1198 Routeing information is carried in the protocol's BISPDUs, which are 1199 generated on an event-driven basis whenever a BIS receives 1200 information which causes it advertise new paths. 1202 5.9.1 Internal neighbor BIS 1204 Each BIS establishes and maintains communications with all other BISs 1205 located in its routeing domain. The identity of all BISs within a 1206 routeing domain is contained in managed object INTERNAL_BIS described 1207 in 7.3. 1209 5.9.2 External neighbor BIS 1211 Each BIS may establish and maintain communications with other BISs in 1212 adjacent routeing domains. A BIS has no direct communications link 1213 with any BIS in another routeing domain unless that RD is adjacent to 1214 it, as defined in 3.6: that is, a BIS does not communicate directly 1215 with a BIS located in a different routeing domain unless the pair of 1216 BISs are attached to at least one common subnetwork. The identity of 1217 neighbor BISs in adjacent routeing domains is contained in managed 1218 object EXTERNAL-BIS-NEIGHBORS described in 7.3. 1220 Note 3: In the absence of an implementation specific method for 1221 ascertaining that a neighbor BIS listed in managed object 1222 EXTERNAL-BIS-NEIGHBORS is located on a common subnetwork 1223 with itself, a local BIS can include the ISO 8473 Complete 1224 Route Record parameter so that the recipient of the BISPDU 1225 can determine whether the sending BIS is located on the same 1226 subnetwork as itself. 1228 5.10 Routeing domain identifiers 1230 Each routeing domain (RD) and routeing domain confederations (RDC) 1231 whose BIS(s) implement the protocol described in this International 1232 Standard shall have an unambiguous routeing domain identifier (RDI), 1233 which is a generic Network entity title, as described in ISO 7498. 1235 An RDI is assigned statically in accordance with ISO/IEC 8348, and 1236 does not change based on the operational status of the routeing 1237 domain. An RDI identifies a routeing domain or a confederation 1238 uniquely, but does not necessarily convey any information about its 1239 policies or the identities of its members. 1241 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1243 5.11 Formats of RDIs, NETs, and NSAP addresses 1245 Within routeing domains whose BISs implement the protocol defined in 1246 this International Standard, RDIs, NETs and NSAP addresses shall be 1247 structured as described in 7.1. 1249 All Boundary Intermediate systems shall be able to generate and 1250 forward PDUs containing NSAP addresses or NETs whose abstract syntax 1251 is as described in ISO/IEC 8348. 1253 5.12 Design objectives 1255 The protocol described in this international standard was developed 1256 with a view towards satisfying certain design goals, while others 1257 specifically were not addressed by the mechanisms of this protocol. 1259 5.12.1 Within the scope of the protocol 1261 This International Standard supports the following design 1262 requirements: 1264 Control Transit through an RD: It provides mechanisms to permit a 1265 given routeing domain to control the ability of NPDUs from other 1266 routeing domains to transit through itself. 1268 Network Layer Protocol Compatibility: It does not require that any 1269 changes be made to the following existing Network layer protocols: 1270 ISO 8473, ISO 9542, ISO/IEC 10030, ISO/IEC 10589, and ISO/IEC 8208. 1272 Autonomous Operation: It provides stable operation in the global OSIE 1273 where significant sections of the interworking environment will be 1274 controlled by disjoint entities. 1276 Distributed Information Bases: It does not require a centralized 1277 global repository for either routeing information or policy 1278 information. 1280 QOS-based Routeing: It provides the ability to select routes based on 1281 the QOS characteristics of the NPDUs. 1283 Deliverability: It accepts and delivers NPDUs addressed to reachable 1284 routeing domains and rejects NPDUs addressed to routeing domains 1285 known to be unreachable. 1287 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1289 Adaptability: It adapts to topological changes between routeing 1290 domains, but not to traffic changes. 1292 Promptness: It provides a period of adaptation to topological changes 1293 between domains that is a reasonable function of the maximum 1294 logical distance between any pair of routeing domains participating 1295 in an instance of this protocol. 1297 Efficiency: It is efficient in the use of both processing resources 1298 and memory resources; it does not create excessive routeing traffic 1299 overhead. 1301 Robustness: It recovers from transient errors such as lost or 1302 temporarily incorrect routeing PDUs, and it tolerates imprecise 1303 parameter settings. 1305 Stability: It stabilizes in finite time to "good routes", as long as 1306 there are no continuous topological changes or corruptions of the 1307 routeing and policy information bases. 1309 Heterogeneity: It is designed to operate correctly over a set of 1310 routeing domains that may employ diverse intra-domain routeing 1311 protocols. It is capable of running over a wide variety of 1312 subnetworks, including but not limited to: ISO/IEC 8208 and X.25 1313 subnetworks, PSTN networks, and the OSI Data Link Service. 1315 Availability: It will not result in inability to calculate acceptable 1316 inter-domain paths when a single point of failure happens for a 1317 pairing of topology and policy that have a cut set greater than 1318 one. 1320 Fire walls: It will provide fire walls so that: 1322 - Problems within one routeing domain will not affect 1323 intra-domain routeing in any other routeing domain 1324 - Problems within one routeing domain will not affect 1325 inter-domain routeing, unless they occur on internal 1326 inter-domain links 1327 - Inter-domain routeing will not adversely affect intra-domain 1328 routeing. 1330 Scaling: It imposes no upper limit on the number of routeing domains 1331 that can participate in a single instance of this protocol. 1333 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1335 Multiple Routeing Administrations: It will accommodate inter-domain 1336 route calculations without regard to whether or not the 1337 participating routeing domains are under control of one or several 1338 administrative authorities. 1340 5.12.2 Outside the scope of the protocol 1342 The following requirements are not within the design scope of this 1343 protocol: 1345 User Data Security: The security of user data carried within an NPDU 1346 is outside the scope of this protocol. This protocol is not 1347 designed to serve as a substitute for conventional data security 1348 practices. However, it can provide a security-related facility to 1349 the extent that route computation can be based upon the contents of 1350 the ISO 8473 security parameter. 1352 Traffic Adaptation: It does not automatically modify routes based on 1353 the traffic load. 1355 Guaranteed delivery: It does not guarantee delivery of all offered 1356 NPDUs. 1358 Repair of Partitioned Routeing Domains: It does not use paths 1359 external to a partitioned routeing domain to repair the partition. 1361 Repair of Partitioned Routeing Domain Confederations: It does not use 1362 paths external to a partitioned routeing domain confederation to 1363 repair the partition. 1365 Shared Use of Inter-domain Links: It will not permit an external 1366 inter-domain link to carry intradomain traffic. 1368 Suppression of Transient Loops: Although it provides mechanisms to 1369 detect and suppress looping of routeing information, it provides no 1370 mechanisms to detect or suppress transient looping of ISO 8473 1371 NPDUs. 1373 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1375 6. Structure of BISPDUs 1377 In this document, the term BISPDU (Boundary IS PDU) is used as a 1378 general term to refer to any of the PDUs defined in this clause. 1380 Octets in a PDU are numbered starting from 1, in increasing order. 1381 Bits in an octet are numbered from 1 to 8, where bit 1 is the 1382 low-order bit and is pictured on the right. When consecutive octets 1383 are used to represent a number, the lower octet number has the most 1384 significant value. The more significant semi-octet of each pair of 1385 semi-octets in a given octet is encoded in the high order bit 1386 positions (8 through 5). 1388 Values are given in decimal, and all numeric fields are unsigned, 1389 unless otherwise noted. 1391 The types of PDUs used by this protocol are: 1393 - OPEN PDU 1394 - UPDATE PDU 1395 - IDRP ERROR PDU 1396 - KEEPALIVE PDU 1397 - CEASE PDU 1398 - RIB REFRESH PDU 1400 6.1 Header of BISPDU 1402 Each BISPDU has a fixed size header. There may or may not be a data 1403 portion following the header, depending on the PDU type. 1405 The layout of the header fields and their meanings are shown below: 1407 +-------------------------------------------------------------------+ 1408 | Inter-domain Routeing Protocol Identifier (1 octet) | 1409 +-------------------------------------------------------------------+ 1410 | BISPDU Length (2 octets) | 1411 +-------------------------------------------------------------------+ 1412 | BISPDU Type (1 octet) | 1413 +-------------------------------------------------------------------+ 1414 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1416 +-------------------------------------------------------------------+ 1417 | Sequence (4 octets) | 1418 +-------------------------------------------------------------------+ 1419 | Acknowledgement (4 octets) | 1420 +-------------------------------------------------------------------+ 1421 | Credit Offered (1 octet) | 1422 +-------------------------------------------------------------------+ 1423 | Credit Available (1 octet) | 1424 +-------------------------------------------------------------------+ 1425 | Validation Pattern (16 octets) | 1426 +-------------------------------------------------------------------+ 1428 The meaning and use of these fields are as follows: 1430 Inter-domain Routeing Protocol Identifier: An architectural constant 1431 for use in identifying the protocol by the methods of ISO DTR 9577. 1433 BISPDU Length: The BISPDU Length field is a 2 octet unsigned integer. 1434 It contains the total length in octets of this BISPDU, including 1435 both header and data portions. The value of the BISPDU Length 1436 field shall be at least MinBISPDULength octets, and no greater than 1437 the value carried in the Maximum_PDU_Size field of the OPEN PDU 1438 received from the remote BIS. 1440 Further, depending on the PDU type, there may be other constraints 1441 on the value of the Length field; for example, a KEEPALIVE PDU must 1442 have a length of exactly 30 octets. No padding after the end of 1443 BISPDU is allowed, so the value of the Length field must be the 1444 smallest value required given the rest of the BISPDU. 1446 BISPDU Type: The BISPDU Type field contains a one octet type code 1447 which identifies the specific type of the PDU. The supported type 1448 codes are: 1450 +----------------------------------------------------+------------+ 1451 | BISPDU Type | Code | 1452 +----------------------------------------------------+------------+ 1453 | OPEN PDU | 1 | 1454 +----------------------------------------------------+------------+ 1455 | UPDATE PDU | 2 | 1456 +----------------------------------------------------+------------+ 1457 | IDRP ERROR PDU | 3 | 1458 +----------------------------------------------------+------------+ 1459 | KEEPALIVE PDU | 4 | 1460 +----------------------------------------------------+------------+ 1461 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1463 +----------------------------------------------------+------------+ 1464 | BISPDU Type | Code | 1465 +----------------------------------------------------+------------+ 1466 | CEASE PDU | 5 | 1467 +----------------------------------------------------+------------+ 1468 | RIB REFRESH PDU | 6 | 1469 +----------------------------------------------------+------------+ 1471 All other BISPDU type codes are reserved for future extensions. 1473 Sequence: The Sequence field contains a 4 octet unsigned integer that 1474 is the sequence number of this PDU. The procedures for generating 1475 sequence numbers for the various types of BISPDU are described in 1476 7.7.4. 1478 Acknowledgement: The Acknowledgment field is a 4 octet unsigned 1479 integer that contains the sequence number of the PDU that the 1480 sender last received correctly and in sequence number order. 1482 Credit Offered: The contents of this field indicate the number of 1483 additional BISPDUs that the sender is willing to accept from the 1484 remote BIS; it is used by the flow control process described in 1485 7.7.5. 1487 Credit Available: The contents of this field indicate the number of 1488 additional BISPDUs that the sender is able to send to the remote 1489 BIS; it is used by the flow control process described in 7.7.5. 1491 Validation Pattern: This 16-octet field is used to provide a 1492 validation function for the BISPDU. Depending upon the contents of 1493 the field "Authentication Code" of the OPEN PDU, this field can 1494 provide: 1496 - data integrity for the contents of the BISPDU (see 7.7.1 and 1497 7.7.3), or 1498 - data integrity for the contents of the BISPDU plus 1499 authentication of the peer BIS (see 7.7.2). 1501 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1503 6.2 OPEN PDU 1505 The OPEN PDU is used by a BIS for starting a BIS-BIS connection. The 1506 first PDU sent by either side is an OPEN PDU. 1508 The OPEN PDU contains a fixed header and the additional fields shown 1509 below: 1511 +-------------------------------------------------------------------+ 1512 | Fixed Header | 1513 +-------------------------------------------------------------------+ 1514 | Version (1 octet) | 1515 +-------------------------------------------------------------------+ 1516 | Hold Time (2 octets) | 1517 +-------------------------------------------------------------------+ 1518 | Maximum PDU Size (2 octets) | 1519 +-------------------------------------------------------------------+ 1520 | Source RDI Length Indicator (1 octet) | 1521 +-------------------------------------------------------------------+ 1522 | Source RDI (variable) | 1523 +-------------------------------------------------------------------+ 1524 | RIB-AttsSet (variable) | 1525 +-------------------------------------------------------------------+ 1526 | Confed-IDs (variable) | 1527 +-------------------------------------------------------------------+ 1528 | Authentication Code (1 octet) | 1529 +-------------------------------------------------------------------+ 1530 | Authentication Data (variable) | 1531 +-------------------------------------------------------------------+ 1533 The meaning and use of these fields are as follows: 1535 Version: This one octet field contains the version number of the 1536 protocol. Its value is currently 1. 1538 Hold Time: This field contains a 2 octet unsigned integer that is the 1539 maximum number of seconds that this BIS will allow the FSM for a 1540 given BIS-BIS connection to remain in the ESTABLISHED state without 1541 receipt of a KEEPALIVE, UPDATE, or RIB REFRESH PDU from the peer 1542 BIS. (See 7.6.1.4 and 7.20.5.) 1544 Maximum PDU Size: This field contains a 2 octet unsigned integer that 1545 is the maximum number of octets that this BIS will accept in an 1546 incoming UPDATE PDU, IDRP ERROR PDU, or RIB REFRESH PDU. 1548 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1550 Independent of this value, every BIS shall accept KEEPALIVE PDUs or 1551 CEASE PDUs of length 30 octets; every BIS shall also accept any 1552 OPEN PDU with length less than or equal to 3000 octets. 1554 As a minimum, every BIS is required to support reception of all 1555 BISPDUs whose size is greater than or equal to MinBISPDULength 1556 octets and less than or equal to 1024 octets: that is, the minimum 1557 acceptable value for this field is 1024. 1559 Source RDI Length Indicator: This one octet field contains the length 1560 in octets of the Source RDI field. 1562 Source RDI: This variable length field contains the RDI of the 1563 routeing domain in which the BIS that is sending this BISPDU is 1564 located. 1566 RIB-AttsSet: This variable length field contains a list of all 1567 RIB-Atts that the local BIS is willing to support when 1568 communicating with the neighbor BIS (that is, the BIS to which this 1569 OPEN PDU is being sent). It contains an encoding of all or part of 1570 the information contained in managed object RIBAttsSet (See 7.3 and 1571 7.10.1). 1573 A BIS is not required to list all of its supported RIB-Atts in an 1574 OPEN PDU that is sent to a neighbor BIS located in an adjacent 1575 routeing domain. It must include only those RIB-Atts that 1576 correspond to Adj-RIBs-Out that the local BIS will use to 1577 communicate with the neighbor BIS, and those that correspond to the 1578 RIB-Atts of the Adj-RIBs-In that the local BIS supports for storing 1579 UPDATE PDUs received from that neighbor BIS. 1581 However, a BIS shall include all of the RIB-Atts listed in managed 1582 object RIBAttsSet in an OPEN PDU that is sent to another BIS 1583 located in its own routeing domain. Failure to do so will result 1584 in an OPEN PDU error, as described in 7.20.2. 1586 The encoding of this field is as follows: 1588 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1590 +-----------------------------------------------------------------+ 1591 | Number of Non-empty RIB-Atts | 1592 +-----------------------------------------------------------------+ 1593 | Number of Distinguishing Attributes in First RIB-Att | 1594 +-----------------------------------------------------------------+ 1595 | First attribute, first RIB-Att | 1596 +-----------------------------------------------------------------+ 1597 | .... | 1598 +-----------------------------------------------------------------+ 1599 | Last Attribute, first RIB-Att | 1600 +-----------------------------------------------------------------+ 1601 | Number of Distinguishing Attributes in Second RIB-Att | 1602 +-----------------------------------------------------------------+ 1603 | First attribute, second RIB-Att | 1604 +-----------------------------------------------------------------+ 1605 | .... | 1606 +-----------------------------------------------------------------+ 1607 | Last Attribute, second RIB-Att | 1608 +-----------------------------------------------------------------+ 1609 | ... | 1610 +-----------------------------------------------------------------+ 1611 | Number of Distinguishing Attributes in Nth RIB-Att | 1612 +-----------------------------------------------------------------+ 1613 | First attribute, Nth RIB-Att | 1614 +-----------------------------------------------------------------+ 1615 | .... | 1616 +-----------------------------------------------------------------+ 1617 | Last Attribute, Nth RIB-Att | 1618 +-----------------------------------------------------------------+ 1619 | ... | 1620 +-----------------------------------------------------------------+ 1621 | Number of Distinguishing Attributes in Last RIB-Att | 1622 +-----------------------------------------------------------------+ 1623 | First attribute, last RIB-Att | 1624 +-----------------------------------------------------------------+ 1625 | .... | 1626 +-----------------------------------------------------------------+ 1627 | Last Attribute, last RIB-Att | 1628 +-----------------------------------------------------------------+ 1630 The field Number of RIB-Atts is one octet long. It contains the 1631 total number of non-empty RIB-Atts supported by this BIS. Since 1632 every BIS supports an empty RIB-Att (see 7.10.1), the empty RIB-Att 1633 shall not be listed in the OPEN PDU. 1635 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1637 If a BIS supports no RIB-Atts other than the empty RIB-Att, then 1638 the field Number of Non-empty RIB-Atts shall contain 0. 1640 If the Number of Non-Empty RIB-Atts is non-zero, then the BIS 1641 supports all of the listed RIB-Atts plus the empty RIB-Att. 1643 Each field Number of Distinguishing Attributes in the Nth Set is 1644 one octet long, and it contains the number of distinguishing 1645 attributes that are contained in the Nth RIB-Att. Since a RIB-Att 1646 consists of a set of distinguishing attributes, there is no 1647 significance to the order in which the distinguishing attributes of 1648 a given RIB-Att are listed. 1650 Each of the individual attributes in a set is encoded as follows: 1652 - a type specific distinguishing attribute (see 7.11.2) is 1653 encoded as a single octet, using the type code specified in 6.3 1654 for the corresponding UPDATE PDU path attribute. 1656 - a type-value-specific distinguishing attribute (see 7.11.2) is 1657 encoded as a triple , using the type code 1658 for the attribute, the length in octets of the subsequent 1659 value, and the value itself. The value is encoded as follows 1660 for the following distinguishing attributes: 1662 SECURITY: The value shall contain the Security Registration 1663 Identifier that identifies the Security Authority for which 1664 security related information is supported by this RIB-Att, 1665 encoded identically to the encoding of the SECURITY attribute 1666 specified in 6.3.1.14 including length fields, but with a 1667 zero length security information. 1669 LOCALLY DEFINED QOS: The value shall comprise the NSAP Address 1670 Prefix of the QoS Authority and the QoS value that identifies 1671 the QoS measurement, encoded identically to the encoding of 1672 the LOCALLY DEFINED QOS attribute specified in 6.3.1.11 1673 including length fields, but with a zero length metric. 1675 Confed-IDs: This is a variable length field which reports the RDIs of 1676 all RDCs that this BIS is a member of. The encoding of this field 1677 is as follows: 1679 +-----------------------------------------------------------------+ 1680 | Number of RDCs (1 octet) | 1681 +-----------------------------------------------------------------+ 1682 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1684 +-----------------------------------------------------------------+ 1685 | Length of First RDI (1 octet) | 1686 +-----------------------------------------------------------------+ 1687 | RDI of first RDC | 1688 +-----------------------------------------------------------------+ 1689 | .... | 1690 +-----------------------------------------------------------------+ 1691 | Length of Last RDI (1 octet) | 1692 +-----------------------------------------------------------------+ 1693 | RDI of last confederation | 1694 +-----------------------------------------------------------------+ 1696 The 1 octet field Number of RDCs gives the number of RDCs of which 1697 this BIS is a member. A value of zero indicates that this BIS 1698 participates in no RDCs. 1700 For each such confederation, the following fields give the length 1701 and RDI for each confederation, where each RDI is encoded according 1702 to the preferred binary encoding of ISO/IEC 8348. 1704 Authentication Code: This 1-octet unsigned integer indicates the 1705 authentication mechanism being used: 1707 a) Code 1 indicates that the Validation Pattern field in the 1708 header of each BISPDU contains an unencrypted checksum that 1709 provides data integrity for the contents of that BISPDU. Its 1710 use is described in 7.7.1 Its use is described in 7.7.1. 1712 b) Code 2 indicates that the Validation Pattern field in the 1713 header of each BISPDU provides both peer-BIS authentication and 1714 data integrity for the contents of the BISPDU. The specific 1715 mechanism used to generate the validation pattern is mutually 1716 agreed to by the pair of BISs, but is not specified by this 1717 International Standard. Its use is described in 7.7.2. 1719 c) Code 3 indicates that the Validation Pattern field in the 1720 header of each BISPDU contains an unencrypted checksum covering 1721 the concatenation of the contents of the BISPDU with 1722 untransmitted password string(s). Its use is defined in 7.7.3. 1724 Authentication Data: The form and meaning of this field is a 1725 variable-length field that depends on the Authentication Code, as 1726 described in clause D.1. The length of the authentication data 1727 field can be determined from the Length field of the BISPDU header. 1729 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1731 6.3 UPDATE PDU 1733 An UPDATE PDU is used to advertise feasible routes to a neighbor BIS, 1734 or to withdraw multiple unfeasible routes from service (see 5.6). 1735 An UPDATE PDU may simultaneously advertise multiple feasible routes 1736 and withdraw multiple unfeasible routes from service. The UPDATE PDU 1737 always includes the fixed header, Unfeasible Route Count field, and 1738 Total Path Length Attributes field; it can optionally contain the 1739 other fields shown in Figure 5: 1741 - if routes are being explicitly withdrawn from service, then the 1742 UNFEASIBLE ROUTE COUNT field will be non-zero, and the WITHDRAWN 1743 ROUTES fields will be present 1745 - if feasible routes are being advertised, then the TOTAL PATH 1746 ATTRIBUTES LENGTH field will be non-zero, and the PATH ATTRIBUTES 1747 and NLRI fields will be present. 1749 An UPDATE PDU can advertise multiple routes; a route is described by 1750 several path attributes, each of which is encoded as a 4-tuple. All 1751 path attributes contained in a given UPDATE PDU apply to the 1752 destinations carried in the Network Layer Reachability Information 1753 field of the UPDATE PDU. 1755 An UPDATE PDU can list multiple routes to be withdrawn from service. 1756 Each such route is identified by its Route-ID, which unambiguously 1757 identifies the route in the context of the BIS-BIS connection in 1758 which it had been previously been advertised. 1760 An UPDATE PDU that is used only to withdraw routes from service (but 1761 not to advertise any feasible routes) will not include Path 1762 Attributes or NLRI. Conversely, if an UPDATE PDU does not withdraw 1763 any routes from service, the UNFEASIBLE ROUTE COUNT field will 1764 contain the value 0, and WITHDRAWN ROUTES field will not be present. 1766 The components of the UPDATE PDU are described below: 1768 +-------------------------------------------------------------------+ 1769 | Fixed Header | 1770 +-------------------------------------------------------------------+ 1771 | Unfeasible Route Count (2 octets) | 1772 +-------------------------------------------------------------------+ 1773 | Withdrawn Routes (variable) | 1774 +-------------------------------------------------------------------+ 1775 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1777 +----------------------------------------------------------------------+ 1778 | | 1779 | update4 | 1780 | | 1781 +----------------------------------------------------------------------+ 1782 Figure 5. Structure of the UPDATE PDU 1784 +-------------------------------------------------------------------+ 1785 | Total Path Attributes Length (2 octets) | 1786 +-------------------------------------------------------------------+ 1787 | Path Attributes (variable) | 1788 +-------------------------------------------------------------------+ 1789 | Network Layer Reachability Information (variable) | 1790 +-------------------------------------------------------------------+ 1792 The use of these fields is as follows: 1794 Unfeasible Route Count: This is a 2-octet long field that contains an 1795 integer whose value is equal to the number of ROUTE-IDs that are 1796 included in the subsequent WITHDRAWN ROUTES field. A value of 0 1797 indicates that no routes are being withdrawn from service, and that 1798 the WITHDRAWN ROUTES field is not present in this UPDATE PDU. 1800 Withdrawn Routes: This is a variable length field that contains a 1801 list of Route-IDs for the routes that are being withdrawn from 1802 service. Each Route-ID is 4 octets in length. 1804 Total Path Attribute Length: The length of this field is 2 octets. 1805 It is the total length of all Path Attributes in the UPDATE PDU in 1806 octets. 1808 Path Attributes: A variable length sequence of path attributes is 1809 present in every UPDATE PDU that is used to advertise a feasible 1810 route. 1812 Network Layer Reachability Information: A variable length field that 1813 lists the destinations for the feasible routes that are being 1814 advertised in this UPDATE PDU. 1816 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1818 6.3.1 Path attribute encoding 1820 Each path attribute is a 4-tuple of variable length--. The elements are used as follows: 1823 - Flag: 1825 The first element of each attribute is a one octet field: 1827 - The high-order bit (bit 8) of the attribute flags octet is 1828 the Optional bit. If it is set to 1, the attribute is 1829 optional; if set to 0, the attribute is well-known. 1831 - The second high-order bit (bit 7) of the attribute flags 1832 octet is the Transitive bit. It defines whether an optional 1833 attribute is transitive (if set to 1) or non-transitive (if 1834 set to 0). For well-known attributes, the Transitive bit 1835 shall be set to 1. 1837 - The third high-order bit (bit 6) of the attribute flags octet 1838 is the Partial bit. It defines whether the optional 1839 transitive attribute is partial (if set to 1) or complete (if 1840 set to 0). For well-known attributes and for optional 1841 non-transitive attributes the Partial bit shall be set to 0. 1843 - The lower order five bits (1 through 5) of the attribute 1844 flags octet are reserved. They shall be transmitted as 0 and 1845 shall be ignored when received. 1847 - Type: 1849 The second element of each attribute is a one octet field which 1850 contains the type code for the attribute. Currently defined 1851 attribute type codes are discussed in clause 7.11. 1853 Note 4: It is not the intention of this International Standard 1854 to define globally understood path attributes for type 1855 codes greater than value 128. Such codes are reserved 1856 for local use. 1858 - Length: 1860 The third field of each path attribute is 2 octets in length; it 1861 contains the length in octets of the immediately following Value 1862 field. 1864 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1866 - Value: 1868 The remaining octets of each path attribute field contain the 1869 value of the attribute, which is interpreted according to the 1870 attribute flags and the attribute type code. The supported 1871 attribute values and their encodings are defined below. 1873 6.3.1.1 ROUTE_SEPARATOR (Type Code 1) 1875 ROUTE_SEPARATOR is a well-known mandatory attribute whose length is 5 1876 octets. One ROUTE_SEPARATOR attribute shall be present for each 1877 feasible route that is advertised in an UPDATE PDU. Multiple 1878 ROUTE_SEPARATORs may appear in a single UPDATE PDU. Each one 1879 provides a 2-tuple for the route whose 1880 distinguishing attributes immediately follow. It is encoded as shown 1881 below: 1883 +-------------------------------------------------------------------+ 1884 | ROUTE-ID 1 (4 octets) | 1885 +-------------------------------------------------------------------+ 1886 | LOCAL-PREF 1 (1 octet) | 1887 +-------------------------------------------------------------------+ 1889 a) ROUTE-ID: 1891 A four octet field that contains the route identifier for the 1892 route associated with the RIB-Att composed of the set of 1893 distinguishing path attributes that appear between itself and 1894 either the next ROUTE_SEPARATOR attribute or the end of the 1895 UPDATE PDU. 1897 b) LOCAL_PREF: A one octet field that contains the local preference 1898 value for route. 1900 The usage of this attribute is defined in 7.12.1. 1902 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1904 6.3.1.2 EXT_INFO (Type Code 2) 1906 EXT_INFO is a well-known discretionary attribute that has a length of 1907 zero octets; its presence indicates that some (or all) of the path 1908 attributes or Network Layer Reachability Information contained in 1909 this UPDATE PDU have been obtained by methods not specified by IDRP. 1910 Conversely, its absence indicates that all path attributes and NLRI 1911 have been learned by methods defined within IDRP. Its usage is 1912 defined in 7.12.2 1914 6.3.1.3 RD_PATH (Type Code 3) 1916 The RD_PATH attribute is a well-known mandatory attribute composed of 1917 a series of RD path segments. Each path segment is represented by a 1918 triple . 1920 The path segment type is a 1-octet long field, with the following 1921 values defined: 1923 +------------------------------------------------------+------------+ 1924 | Segment Type | Value | 1925 +------------------------------------------------------+------------+ 1926 | RD_SET | 1 | 1927 +------------------------------------------------------+------------+ 1928 | RD_SEQ | 2 | 1929 +------------------------------------------------------+------------+ 1930 | ENTRY_SEQ | 3 | 1931 +------------------------------------------------------+------------+ 1932 | ENTRY_SET | 4 | 1933 +------------------------------------------------------+------------+ 1935 An RD_SEQ and a ENTRY_SEQ provide a list of RDIs, for routeing 1936 domains or for confederations respectively, in the order that the 1937 routeing information has travelled through them. An RD_SET and an 1938 ENTRY_SET provide an unordered list of RDIs, for routeing domains or 1939 for confederations respectively; the routeing information has not 1940 necessarily travelled through all of the listed domains or 1941 confederations. 1943 The path segment length is a two octet field containing the length in 1944 octets of the path segment value field. 1946 The path segment value field contains one or more 2-tuples . Length is a one octet long field that contains the length of 1948 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1950 the RDI in octets; RDI itself is encoded according to the preferred 1951 binary encoding of ISO/IEC 8348. 1953 Usage of this attribute is defined in 7.12.3. 1955 6.3.1.4 NEXT_HOP (Type Code 4) 1957 This is a well-known discretionary attribute that can be used for two 1958 principal purposes: 1960 a) to permit a BIS to advertise a different BIS's NET in the "NET of 1961 Next Hop" field 1963 b) to allow a given BIS to report some or all of the SNPAs that 1964 exist within the local system 1966 It is encoded as shown below: 1968 +-------------------------------------------------------------------+ 1969 | IDRP_Server_Allowed (1 octet) | 1970 +-------------------------------------------------------------------+ 1972 followed by one or more of the following: 1974 +-------------------------------------------------------------------+ 1975 | Proto_type (1 octet) | 1976 +-------------------------------------------------------------------+ 1977 | Proto_length (1 octet) | 1978 +-------------------------------------------------------------------+ 1979 | Protocol (variable) | 1980 +-------------------------------------------------------------------+ 1981 | Length of NET (1 octet) | 1982 +-------------------------------------------------------------------+ 1983 | NET of Next Hop (variable) | 1984 +-------------------------------------------------------------------+ 1985 | Number of SNPAs (1 octet) | 1986 +-------------------------------------------------------------------+ 1987 | Length of first SNPA(1 octet) | 1988 +-------------------------------------------------------------------+ 1989 | First SNPA (variable) | 1990 +-------------------------------------------------------------------+ 1991 | Length of second SNPA (1 octet) | 1992 +-------------------------------------------------------------------+ 1993 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 1995 +-------------------------------------------------------------------+ 1996 | Second SNPA (variable) | 1997 +-------------------------------------------------------------------+ 1998 | ... | 1999 +-------------------------------------------------------------------+ 2000 | Length of Last SNPA (1 octet) | 2001 +-------------------------------------------------------------------+ 2002 | Last SNPA (variable) | 2003 +-------------------------------------------------------------------+ 2005 The use and meaning of these fields are as follows: 2007 IDRP_Server_Allowed: The value X'FF' indicates the recipient of this 2008 UPDATE PDU has the option of advertising (in its own outbound 2009 UPDATE PDUs) the NET and SNPA information learned from this UPDATE 2010 PDU. If the value is not X'FF', then the recipient of this UPDATE 2011 PDU shall not advertise the NET and SNPA information learned from 2012 this UPDATE PDU. 2014 Proto_type: This field indicates the type of protocol identifier that 2015 follows: 2017 1 ISO/IEC TR 9577 IPI/SPI 2018 2 ISO 8802 LSAP 2020 For use with ISO 8473, this field shall contain the value 1. 2022 Proto_length: This field indicates the length in octets of the 2023 protocol identifier that follows. For use with ISO 8473, this 2024 field shall contain the value 1. 2026 Protocol: This field carries the identity of the protocol associated 2027 with the address information that follows. For use with ISO 8473, 2028 this field shall contain the value X'81'. 2030 Length of NET: A 1 octet field whose value expresses the length of 2031 the "NET of Next Hop" field as measured in octets 2033 NET of Next Hop: A variable length field that contains the NET of the 2034 next BIS on the path to the destination system 2036 Number of SNPAs: A 1 octet field which contains the number of 2037 distinct SNPAs to be listed in the following fields. The value 0 2038 may be used to indicate that no SNPAs are listed in this attribute. 2040 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2042 Length of Nth SNPA: A 1 octet field whose value expresses the length 2043 of the "Nth SNPA of Next Hop" field as measured in semi-octets 2045 Nth SNPA of Next Hop: A variable length field that contains an SNPA 2046 of the BIS whose NET is contained in the "NET of Next Hop" field. 2047 The field length is an integral number of octets in length, namely 2048 the rounded-up integer value of one half the SNPA length expressed 2049 in semi-octets; if the SNPA has an contains an odd number of 2050 semi-octets, a value in this field will be padded with a trailing 2051 all-zero semi-octet. 2053 Its usage is defined in 7.12.4. A conforming IDRP implementation may 2054 ignore next hop information for all protocols other than ISO 8473. 2055 The Decision and Forwarding processes of IDRP for use with protocols 2056 other than ISO 8473 are outside the scope of this international 2057 standard. 2059 Note 5: The ISO 8802 LSAP format is intended for use with protocols 2060 that are identified directly by the use of a particular LSAP 2061 value; in such cases, the value of the Proto_length field 2062 should be 1. 2064 The ISO/IEC TR 9577 IPI/SPI format may include additional 2065 information beyond the IPI/SPI value in the Protocol field; 2066 for example, if the IPI/SPI value is X'80', an IEEE 802.1a 2067 SNAP header might be included. 2069 6.3.1.5 DIST_LIST_INCL (Type Code 5) 2071 The DIST_LIST_INCL is a well-known discretionary attribute that 2072 contains a list of the RDIs of routeing domains and confederations to 2073 which the Network Layer Reachability Information contained in that 2074 UPDATE PDU may be distributed. Its usage is described in 7.12.5. 2076 Each RDI in the list is encoded as a pair, using the 2077 following fields: 2079 +-------------------------------------------------------------------+ 2080 | Count (1 octet) | 2081 +-------------------------------------------------------------------+ 2082 | Length (1 octet) | 2083 +-------------------------------------------------------------------+ 2084 | Value (variable) | 2085 +-------------------------------------------------------------------+ 2086 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2088 +-------------------------------------------------------------------+ 2089 | ... | 2090 +-------------------------------------------------------------------+ 2091 | Length (1 octet) | 2092 +-------------------------------------------------------------------+ 2093 | Value (variable) | 2094 +-------------------------------------------------------------------+ 2096 The use and meaning of these fields are as follows: 2098 a) Count: 2100 The count field is an integer that gives the number of RDIs in 2101 the list, where each RDI is represented by a pair 2102 as described below. 2104 b) Length: 2106 The length field indicates the length in octets of the following 2107 RDI. 2109 c) Value: 2111 The value field contains the RDI, encoded according to the 2112 preferred binary encoding of ISO/IEC 8348. 2114 The DIST_LIST_INCL attribute shall not be present together with the 2115 DIST_LIST_EXCL attribute in the same UPDATE PDU. 2117 6.3.1.6 DIST_LIST_EXCL (Type Code 6) 2119 The DIST_LIST_EXCL is a well-known discretionary attribute that 2120 contains a list of the RDIs of routeing domains and confederations to 2121 which the Network Layer Reachability Information contained in that 2122 UPDATE PDU shall not be distributed. Its usage is described in 2123 7.12.6. 2125 Each RDI in the list is encoded as a pair, using the 2126 following fields: 2128 +-------------------------------------------------------------------+ 2129 | Count (1 octet) | 2130 +-------------------------------------------------------------------+ 2131 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2133 +-------------------------------------------------------------------+ 2134 | Length (1 octet) | 2135 +-------------------------------------------------------------------+ 2136 | Value (variable) | 2137 +-------------------------------------------------------------------+ 2138 | ... | 2139 +-------------------------------------------------------------------+ 2140 | Length (1 octet) | 2141 +-------------------------------------------------------------------+ 2142 | Value (variable) | 2143 +-------------------------------------------------------------------+ 2145 The use and meaning of these fields are as follows: 2147 a) Count: 2149 The count field is an integer that gives the number of RDIs in 2150 the list, where each RDI is represented by a pair 2151 as described below. 2153 b) Length: 2155 The length field indicates the length in octets of the following 2156 RDI. 2158 c) Value: 2160 The value field contains the RDI, encoded according to the 2161 preferred binary encoding of ISO/IEC 8348. 2163 The DIST_LIST_EXCL attribute shall not be present together with the 2164 DIST_LIST_INCL attribute in the same UPDATE PDU. 2166 6.3.1.7 MULTI-EXIT_DISC (Type Code 7) 2168 MULTI-EXIT_DISC (Multi-exit Discriminator) is an optional 2169 non-transitive attribute that is a 1 octet non-negative integer. The 2170 value of this attribute may be used by a BIS's decision process to 2171 discriminate between multiple exit points to an adjacent routeing 2172 domain. Its usage is defined in 7.12.7. 2174 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2176 6.3.1.8 TRANSIT DELAY (Type Code 8) 2178 The TRANSIT DELAY is a well-known discretionary attribute that has a 2179 length of 2 octets, and is used to notify a BIS that the path to 2180 destination has transit delay determined by the value of the 2181 attribute. Its usage is defined in 7.12.8. 2183 6.3.1.9 RESIDUAL ERROR (Type Code 9) 2185 The RESIDUAL ERROR is a well-known discretionary attribute that has a 2186 length of 4 octets, and is used to notify a BIS that the path to 2187 destination has residual error probability determined by the value of 2188 the attribute. Its usage is defined in 7.12.9. 2190 6.3.1.10 EXPENSE (Type Code 10) 2192 The EXPENSE is a well-known discretionary attribute that has a length 2193 of 2 octets, and is used to notify a BIS that the path to destination 2194 has expense determined by the value of the attribute. Its usage is 2195 defined in 7.12.10. 2197 6.3.1.11 LOCALLY DEFINED QOS (Type Code 11) 2199 This is a well-known discretionary attribute whose variable length 2200 field contains the parameters associated with a QOS related path 2201 attribute defined by a QOS authority. 2203 The parameters of this attribute identify the QOS authority, the name 2204 of the QOS measurement, and, optionally, a metric associated with 2205 that measurement. The syntax and semantics of the QOS measurement 2206 and its metric are outside the scope of this International Standard, 2207 and are specified by the responsible QOS Authority. 2209 It is encoded as follows: 2211 +-------------------------------------------------------------------+ 2212 | NSAP prefix length (1 octet) | 2213 +-------------------------------------------------------------------+ 2214 | NSAP prefix (variable) | 2215 +-------------------------------------------------------------------+ 2216 | QOS length (1 octet) | 2217 +-------------------------------------------------------------------+ 2218 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2220 +-------------------------------------------------------------------+ 2221 | QOS value (variable) | 2222 +-------------------------------------------------------------------+ 2223 | Metric length (1 octet) | 2224 +-------------------------------------------------------------------+ 2225 | Metric value (variable) | 2226 +-------------------------------------------------------------------+ 2228 The use and meaning of the fields is as follows: 2230 a) NSAP prefix length: 2232 The length field indicates the length in bits of the NSAP address 2233 prefix (see 7.1.2.1). A length of zero indicates a prefix that 2234 matches all NSAPs. 2236 b) NSAP prefix: 2238 If the Length field specifies an integral number of octets, then 2239 the Prefix field shall contain only the NSAP address prefix 2240 encoded according to 7.1.2.1. If the Length field does not 2241 specify an integral number of octets, then the Prefix field shall 2242 contain the NSAP address prefix encoded according to 7.1.2.1, 2243 followed by enough trailing zeroes to make the end of the field 2244 fall on an octet boundary. 2246 This field identifies the QoS Authority and comprises an NSAP 2247 Address Prefix when the QoS Authority is also an NSAP Addressing 2248 Authority (see ISO 8473 clauses 7.5.6.1 and 7.5.6.2); the NSAP 2249 Address Prefix is that of the QoS Authority's Addressing 2250 Subdomain. When the QoS Authority is not also an NSAP Addressing 2251 Authority, then this field contains an NET that uniquely 2252 identifies the QoS Authority. 2254 c) QOS length: 2256 Gives the length in octets of the QOS value field. 2258 d) QOS value: 2260 Contains the value of the QOS parameter. 2262 e) Metric length: 2264 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2266 Gives the length in octets of the metric value field. A length 2267 of zero is a permitted value. 2269 f) Metric value: 2271 Contains a positive integer that is the value of the metric 2272 associated with the path being advertised (that is, its "cost") 2274 Its usage is defined in 7.12.11. 2276 6.3.1.12 HIERARCHICAL RECORDING (Type Code 12) 2278 This is a well-known discretionary attribute. It contains a 1-octet 2279 field used by members of a routeing domain confederation to control 2280 the transitivity of NPDUs through the confederation. It is encoded 2281 as follows: 2283 +-------------------------------------------------------------------+ 2284 | Flag (1 octet) | 2285 +-------------------------------------------------------------------+ 2287 Its usage is defined in 7.12.12. 2289 6.3.1.13 RD_HOP_COUNT (Type Code 13) 2291 The RD_HOP_COUNT is a well-known mandatory attribute that contains a 2292 1 octet long field. It contains an unsigned integer that is the 2293 upper bound on the number of routeing domains through which this 2294 UPDATE PDU has travelled. Its usage is defined in 7.12.13. 2296 6.3.1.14 SECURITY (Type Code 14) 2298 This is a well-known discretionary attribute whose variable length 2299 field contains the parameters associated with a security related path 2300 attribute defined by a Security Authority. 2302 The parameters of this attribute identify the Security Authority, and 2303 can also contain additional security related information, which may 2304 identify the protection provided by the route, a set of Security 2305 Labels associated with the route, or both. The syntax and semantics 2306 of the security related information are outside the scope of this 2307 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2309 International Standard, and are specified by the responsible Security 2310 Authority. 2312 The encoding of the attribute is as follows: 2314 +-------------------------------------------------------------------+ 2315 | Security Registration ID Length (1 octet) | 2316 +-------------------------------------------------------------------+ 2317 | Security Registration ID (variable) | 2318 +-------------------------------------------------------------------+ 2319 | Security Information Length (1 octet) | 2320 +-------------------------------------------------------------------+ 2321 | Security Information (variable) | 2322 +-------------------------------------------------------------------+ 2324 The use and meaning of the fields is as follows: 2326 a) Security Registration ID Length: 2328 This field contains the length in octets of the Security 2329 Authority's Security Registration Identifier. 2331 b) Security Registration ID: 2333 This variable length field contains the Security Registration 2334 Identifier of the Security Authority responsible for defining the 2335 following security information. 2337 c) Security Information Length: 2339 This field contains the length in octets of the Security 2340 Information, as a non-zero unsigned integer. A value of zero is 2341 not permitted. 2343 d) Security Information: 2345 This variable length field contains an integral number of octets 2346 comprising security related information specified by the Security 2347 Authority identified above. The syntax and semantics of this 2348 information are outside of the scope of this International 2349 Standard. 2351 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2353 6.3.1.15 CAPACITY (Type code 15) 2355 CAPACITY is a well-known mandatory attribute that has a length of 1 2356 octet, and is used to denote the relative capacity of the RD_PATH for 2357 handling traffic. High values indicate a lower traffic handling 2358 capacity than do low values. Its usage is defined in 7.12.15. 2360 6.3.1.16 PRIORITY (Type Code 16) 2362 PRIORITY is a well-known discretionary attribute that is 1 octet in 2363 length. The content of the field is an integer in the range from 0 2364 to 14. It enables paths to be distinguished on the basis of which 2365 values of the ISO 8473 priority parameter (see ISO 8473, subclause 2366 7.5.7). As in ISO 8473, the value 0 indicates the normal (default) 2367 priority, and the values 1 through 14 indicate higher priorities. A 2368 particular value of this parameter, m, means that the BIS will not 2369 forward any ISO 8473 PDUs whose priority parameter has a value less 2370 than m. Detailed usage rules are presented in 7.12.16. 2372 6.3.2 Network layer reachability information 2374 This variable length field contains a list of reachable destinations 2375 encoded as zero or more 5-tuples of the form , whose fields are 2377 described below: 2379 +-------------------------------------------------------------------+ 2380 | Proto_type (1 octet) | 2381 +-------------------------------------------------------------------+ 2382 | Proto_length (1 octet) | 2383 +-------------------------------------------------------------------+ 2384 | Protocol (variable) | 2385 +-------------------------------------------------------------------+ 2386 | Addr_length (2 octets) | 2387 +-------------------------------------------------------------------+ 2388 | Addr_info (variable) | 2389 +-------------------------------------------------------------------+ 2391 The use and meaning of these fields are as follows: 2393 Proto_type: This field indicates the type of protocol identifier that 2394 follows: 2396 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2398 1 ISO/IEC TR 9577 IPI/SPI 2399 2 ISO 8802 LSAP 2401 For use with ISO 8473, this field shall contain the value 1. 2403 Proto_length: This field indicates the length in octets of the 2404 protocol identifier that follows. For use with ISO 8473, this 2405 field shall contain the value 1. 2407 Protocol: This field carries the identity of the protocol associated 2408 with the address information that follows. For use with ISO 8473, 2409 this field shall contain the value X'81'. 2411 Addr_length: This field specifies the total length in octets of the 2412 address information that follows. 2414 Addr_info: This field contains a list of reachable address prefixes. 2415 The encoding of this field is specific to each protocol supported. 2417 For use with ISO 8473, this field shall be encoded as one or more 2418 2-tuples of the form , whose fields are described 2419 below: 2421 a) The Length field is one octet long, and it indicates the length 2422 in bits of the address prefix. A length of zero indicates a 2423 prefix that matches all addresses. 2425 b) The Prefix field has a variable length, and it contains an 2426 address prefix. If the Length field does not specify an 2427 integral number of octets, then the Prefix field shall be 2428 padded with trailing zero bits to the next octet boundary. For 2429 purposes of use with ISO 8473, this field shall contain an NSAP 2430 address prefix encoded according to 7.1.2.1. 2432 A conforming IDRP implementation may ignore NLRI for all protocols 2433 other than ISO 8473. The Decision and Forwarding processes of IDRP 2434 for use with protocols other than ISO 8473 are outside the scope of 2435 this international standard. 2437 Note 6: The ISO 8802 LSAP format is intended for use with protocols 2438 that are identified directly by the use of a particular LSAP 2439 value; in such cases, the value of the proto_length field 2440 should be 1. 2442 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2444 The ISO/IEC TR 9577 IPI/SPI format may include additional 2445 information beyond the IPI/SPI value in the Protocol field; 2446 for example, if the IPI/SPI value is X'80', an IEEE 802.1a 2447 SNAP header might be included. 2449 6.4 IDRP ERROR PDU 2451 IDRP ERROR PDUs report error conditions which have been detected by 2452 the local BIS. In addition to its fixed header, the IDRP ERROR PDU 2453 contains the following fields: 2455 +-------------------------------------------------------------------+ 2456 | Fixed Header | 2457 +-------------------------------------------------------------------+ 2458 | Error Code (1 octet) | 2459 +-------------------------------------------------------------------+ 2460 | Error Subcode (1 octet) | 2461 +-------------------------------------------------------------------+ 2462 | Data (variable) | 2463 +-------------------------------------------------------------------+ 2465 The use of these fields is as follows: 2467 Error code: The Error code field is 1 octet long, and shall be 2468 present in every IDRP ERROR PDU. It describes the type of error. 2469 The following error codes are defined: 2471 +----------------------------------------------------+------------+ 2472 | Error Code | Value | 2473 +----------------------------------------------------+------------+ 2474 | OPEN_PDU_Error | 1 | 2475 +----------------------------------------------------+------------+ 2476 | UPDATE_PDU_Error | 2 | 2477 +----------------------------------------------------+------------+ 2478 | Hold_Timer_Expired | 3 | 2479 +----------------------------------------------------+------------+ 2480 | FSM_Error | 4 | 2481 +----------------------------------------------------+------------+ 2482 | RIB_REFRESH_PDU_Error | 5 | 2483 +----------------------------------------------------+------------+ 2485 All errors are fatal to the BIS connection. 2487 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2489 Error subcode: The Error subcode is one octet long, and shall be 2490 present in every IDRP ERROR PDU. The error subcode provides more 2491 specific information about the nature of the reported error. A 2492 given IDRP ERROR PDU may report only one error subcode for the 2493 indicated error code. The supported error subcodes are as follows: 2495 a) OPEN PDU Error subcodes: 2497 +-------------------------------------------------+-----------+ 2498 | Subcode | Value | 2499 +-------------------------------------------------+-----------+ 2500 | Unsupported_Version_Number | 1 | 2501 +-------------------------------------------------+-----------+ 2502 | Bad_Max_PDU_Size | 2 | 2503 +-------------------------------------------------+-----------+ 2504 +-------------------------------------------------+-----------+ 2505 | Bad_Peer_RD | 3 | 2506 +-------------------------------------------------+-----------+ 2507 | Unsupported_Authentication_code | 4 | 2508 +-------------------------------------------------+-----------+ 2509 | Authentication_Failure | 5 | 2510 +-------------------------------------------------+-----------+ 2511 | Bad_RIB-AttsSet | 6 | 2512 +-------------------------------------------------+-----------+ 2513 | RDC_Mismatch | 7 | 2514 +-------------------------------------------------+-----------+ 2516 b) UPDATE PDU Error subcodes: 2518 +-------------------------------------------------+-----------+ 2519 | Subcode | Value | 2520 +-------------------------------------------------+-----------+ 2521 | Malformed_Attribute_List | 1 | 2522 +-------------------------------------------------+-----------+ 2523 | Unrecognized_Well-known_Attribute | 2 | 2524 +-------------------------------------------------+-----------+ 2525 | Missing_Well-known_Attribute | 3 | 2526 +-------------------------------------------------+-----------+ 2527 | Attribute_Flags_Error | 4 | 2528 +-------------------------------------------------+-----------+ 2529 | Attribute_Length_Error | 5 | 2530 +-------------------------------------------------+-----------+ 2531 | RD_Routeing_Loop | 6 | 2532 +-------------------------------------------------+-----------+ 2533 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2535 +-------------------------------------------------+-----------+ 2536 | Subcode | Value | 2537 +-------------------------------------------------+-----------+ 2538 | Invalid_NEXT_HOP_Attribute | 7 | 2539 +-------------------------------------------------+-----------+ 2540 | Optional_Attribute_error | 8 | 2541 +-------------------------------------------------+-----------+ 2542 | Invalid_Reachability_Information | 9 | 2543 +-------------------------------------------------+-----------+ 2544 | Misconfigured_RDCs | 10 | 2545 +-------------------------------------------------+-----------+ 2546 | Malformed_NLRI | 11 | 2547 +-------------------------------------------------+-----------+ 2548 | Duplicated_Attributes | 12 | 2549 +-------------------------------------------------+-----------+ 2550 | Illegal_RD_Path_Segment | 13 | 2551 +-------------------------------------------------+-----------+ 2553 c) Hold_Timer_Expired Error Subcodes: 2555 +-------------------------------------------------+-----------+ 2556 | Subcode | Value | 2557 +-------------------------------------------------+-----------+ 2558 | NULL | 0 | 2559 +-------------------------------------------------+-----------+ 2561 d) FSM_Error Error Subcodes: 2563 When an FSM Error (see 7.6.1) has occurred, the first 2564 semi-octet of the error subcode carries the type number of the 2565 BISPDU that should not have been received and the second 2566 semi-octet encodes the state that the FSM was in when the 2567 reception took place. The BISPDU type numbers are defined in 2568 6.1; the FSM states are encoded as follows: 2570 +-------------------------------------------------+-----------+ 2571 | FSM State | Encoded | 2572 | | Value | 2573 +-------------------------------------------------+-----------+ 2574 | CLOSED | 1 | 2575 +-------------------------------------------------+-----------+ 2576 | OPEN-RCVD | 2 | 2577 +-------------------------------------------------+-----------+ 2578 | OPEN-SENT | 3 | 2579 +-------------------------------------------------+-----------+ 2580 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2582 +-------------------------------------------------+-----------+ 2583 | FSM State | Encoded | 2584 | | Value | 2585 +-------------------------------------------------+-----------+ 2586 | CLOSE-WAIT | 4 | 2587 +-------------------------------------------------+-----------+ 2588 | ESTABLISHED | 5 | 2589 +-------------------------------------------------+-----------+ 2591 e) RIB_REFRESH_PDU_Error Subcodes: 2593 +-------------------------------------------------+-----------+ 2594 | Subcode | Value | 2595 +-------------------------------------------------+-----------+ 2596 | Invalid_OpCode | 1 | 2597 +-------------------------------------------------+-----------+ 2598 | Unsupported_RIB-Atts | 2 | 2599 +-------------------------------------------------+-----------+ 2601 Data: This variable length field contains zero or more octets of data 2602 to be used in diagnosing the reason for the IDRP ERROR PDU. The 2603 contents of the Data field depends upon the error code and error 2604 subcode. 2606 Note that the length of the Data field can be determined from the 2607 Length field of the BISPDU header. The minimum length of the IDRP 2608 ERROR PDU is 32 octets, including BISPDU header. 2610 6.5 KEEPALIVE PDU 2612 A KEEPALIVE PDU consists of only a PDU header and has a length of 30 2613 octets. 2615 A BIS can use the periodic exchange of KEEPALIVE PDUs with an 2616 adjacent BIS to verify that the peer BIS is reachable and active. 2617 KEEPALIVE PDUs are exchanged often enough as not to cause the hold 2618 time advertised in the OPEN PDU to expire. The maximum time between 2619 KEEPALIVE PDUs shall be one third of the Hold Time interval as 2620 advertised in the Hold Time field of the OPEN PDU. 2622 A KEEPALIVE PDU may be sent asynchronously to acknowledge the receipt 2623 of other BISPDUs. Sending a KEEPALIVE PDU does not cause the 2624 sender's sequence number to be incremented. 2626 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2628 6.6 CEASE PDU 2630 A CEASE PDU consists of only a PDU header and has length of 30 2631 octets. 2633 A CEASE PDU is used by the originating BIS to instruct the peer BIS 2634 to close the BIS-BIS connection. 2636 Receipt of a CEASE PDU will cause the BIS to close down the 2637 connection with the BIS that issued it, as described in 7.6.2. 2639 6.7 RIB REFRESH PDU 2641 The RIB REFRESH PDU is used to allow a BIS to send a refresh of the 2642 routeing information in an Adj-RIB-Out to a neighbor BIS, or to 2643 solicit a neighbor BIS to send a refresh of its Adj-RIB-Out to the 2644 local BIS. The RIB REFRESH PDU contains a fixed header and also the 2645 additional fields shown below: 2647 +-------------------------------------------------------------------+ 2648 | Fixed Header | 2649 +-------------------------------------------------------------------+ 2650 | OpCode (1 octet) | 2651 +-------------------------------------------------------------------+ 2652 | RIB-Atts (variable) | 2653 +-------------------------------------------------------------------+ 2655 The use and meaning of these fields is as follows: 2657 There are three OpCode values defined: 2659 +------------+------------------------------------------------------+ 2660 | Code | Operation | 2661 +------------+------------------------------------------------------+ 2662 | 1 | RIB Refresh Request | 2663 +------------+------------------------------------------------------+ 2664 | 2 | RIB Refresh Start | 2665 +------------+------------------------------------------------------+ 2666 | 3 | RIB Refresh End | 2667 +------------+------------------------------------------------------+ 2669 The RIB-Atts field contains the RIB-Atts of the Adj-RIB-In for which 2670 a refresh is being requested. This field is encoded in the same way 2671 that the RIB-AttsSet field of the OPEN PDU is encoded. 2673 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2675 Its usage is defined in 7.10.3. 2677 7. Elements of procedure 2679 This clause explains the elements of procedure used by the protocol 2680 specified in this International Standard; it also describes the 2681 naming conventions and system deployment practices assumed by this 2682 protocol. 2684 7.1 Naming and addressing conventions 2686 Correct operation of this protocol requires that all NSAP-addresses, 2687 NETs, and RDIs shall be encoded according to the preferred binary 2688 encoding method of ISO/IEC 8348. 2690 7.1.1 Interpretation of address information 2692 IDRP does not assume or require any particular internal structure for 2693 the address. That is, as long as the routeing domain administrator 2694 assigns values within this field that are consistent with the 2695 deployment constraints of 7.2.2, the protocol specified in this 2696 International Standard will operate correctly. 2698 7.1.2 NSAP address prefixes 2700 NSAP address prefixes provide a compact method for identifying groups 2701 of systems that reside in a given routeing domain or confederation. 2702 A prefix may have a length that is either smaller than, or the same 2703 size as, the base NSAP address. 2705 Note 7: At one extreme, for example, the largest NSAP address prefix 2706 will be identical with the full NSAP address--in this case, 2707 it would identify a single system rather than a group of 2708 systems. At another extreme, the NSAP prefix may be based 2709 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2711 on only a portion of NSAP address's IDP--in this case, it 2712 will identify a large group of systems. 2714 7.1.2.1 Encoding of prefixes 2716 The encoded form of an NSAP address prefix is obtained by encoding 2717 the prefix (expressed in its abstract syntax) according to the 2718 preferred binary encoding of ISO 8348, unless the end of the prefix 2719 falls within the IDP. In this case, each decimal digit in the prefix 2720 shall be encoded as the corresponding semi-octet in the range 2721 0000-1001 and no padding characters shall be inserted. 2723 The length of an encoded prefix is denominated in bits. The prefix 2724 shall end on a boundary that is legal in the abstract syntax of the 2725 address family from which it is derived. For example, the encoding 2726 of a prefix whose DSP is expressed in decimal syntax must end on a 2727 semi-octet boundary, while the encoding of a prefix whose DSP is 2728 expressed in binary syntax can end on an arbitrary bit boundary. 2730 7.1.2.2 Prefix matching 2732 As part of the forwarding process, a BIS must match the destination 2733 NSAP address from an ISO 8473 NPDU against the NSAP address prefixes 2734 that are used to identify the Forwarding Information Bases. An NSAP 2735 address prefix that extends into the DSP shall be compared directly 2736 against the encoded NSAP address, including any padding characters 2737 that may be present. An NSAP address prefix which does not extend 2738 into the DSP shall be compared against the derived quantity NSAP', 2739 which is obtained from the encoded NSAP address by removing all 2740 padding characters that were inserted by the binary encoding process 2741 of ISO 8348. 2743 The existence of a match shall be determined as follows: 2745 a) If the encoded NSAP address (or NSAP') contains fewer bits than 2746 the NSAP address prefix, then there is no match. 2748 b) If the encoded NSAP address (or NSAP') contains at least as many 2749 bits as the NSAP address prefix, and all bits of the NSAP address 2750 prefix are identical to the corresponding leading bits of the 2751 encoded NSAP address (or NSAP'), there is a match. Otherwise, 2752 there is no match. 2754 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2756 In cases where a given NSAP address matches several address prefixes, 2757 the match with the longest prefix shall take precedence. For 2758 purposes of prefix matching, the length of a prefix is defined to be 2759 the number of bits that it contains. 2761 Note 8: Any implementation of a matching process that satisfies the 2762 requirements listed above may be used. The key point is 2763 that matching process must be aware of whether or not the 2764 NSAP address prefix extends into the DSP, and must then 2765 either include or exclude padding characters from the 2766 encoded NSAP address, as defined above. 2768 7.2 Deployment guidelines 2770 7.2.1 Minimum configuration of an RD 2772 To participate in this inter-domain routeing protocol, a routeing 2773 domain must, as a minimum: 2775 - contain at least one Boundary Intermediate system 2777 - contain at least one BIS capable of delivering NPDUs to the 2778 intra-domain routeing function, if the RD contains End systems. 2780 7.2.2 Deployment of ISs and ESs 2782 End systems and intermediate systems may use any NSAP address or NET 2783 that has been assigned under ISO/IEC 8348 guidelines. However, 2784 correct and efficient operation of this protocol can only be 2785 guaranteed if the following additional guidelines are met: 2787 a) An NSAP prefix carried in the NLRI field of route originated by a 2788 BIS in a given routeing domain should be associated with only 2789 that routeing domain: that is, no system identified by the prefix 2790 should reside in a different routeing domain. Ambiguous routeing 2791 may result if several routeing domains originate routes whose 2792 NLRI fields contain identical NSAP address prefixes, since this 2793 would imply that the same system(s) are simultaneously located in 2794 several routeing domains. (As noted in 7.1.2.2, prefixes may be 2795 discriminated by both content and length.) 2796 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2798 b) Several different NSAP prefixes may be associated with a single 2799 routeing domain identifier (RDI). Thus, it is possible to 2800 construct a single routeing domain which contains a mix of 2801 systems which use NSAP addresses assigned by several different 2802 naming authorities. 2804 The protocol defined in this International Standard assumes that the 2805 guidelines listed above have been satisfied, but it contains no means 2806 to verify that this is so. Therefore, such verification will be the 2807 responsibility of the administrators of routeing domains. 2809 7.3 Domain configuration information 2811 Correct operation of the protocol described in this international 2812 standard assumes that a minimum amount of information is available to 2813 both the inter-domain and the intra-domain routeing protocols. The 2814 information is static in nature, and is not expected to change 2815 frequently. This protocol specifies the content of the information 2816 in terms of managed objects. 2818 The information required by a BIS that implements the protocol 2819 described in this International Standard is: 2821 a) Location and identity of adjacent intra-domain ISs: 2823 The managed object intraIS lists the NETs of systems to which the 2824 local BIS may deliver an inbound NPDU whose destination lies 2825 within the BIS's routeing domain. The managed object contains 2826 the NETs of ISs that support the intra-domain routeing protocol 2827 and are located on the same common subnetwork as the local BIS. 2828 In particular, if the BIS participates in the intra-domain 2829 routeing protocol (that is, the protocol machines for both intra- 2830 and inter-domain routeing are located in the same real system), 2831 then the NET of the local BIS will be listed in the managed 2832 object intraIS. 2834 b) Location and identity of BISs in the domain: 2836 This information permits a BIS to identify all other BISs located 2837 within its routeing domain. This information is contained in the 2838 managed object internalBIS, which contains a set of NETs which 2839 identify the BISs in the domain. 2841 c) Location and identity of BISs in adjacent domain: 2843 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2845 Each BIS needs information to identify the NETs of each BIS 2846 located in an adjacent RD and reachable via a single subnetwork 2847 hop. This information is contained in managed object 2848 externalBISNeighbor, which consists of a list of NETs. 2850 d) NETs and NSAP addresses of all systems in the routeing domain: 2852 This information is used by the BIS to construct its network 2853 layer reachability information. This information is contained 2854 within the managed object internalSystems, which lists the 2855 address prefixes of the systems contained within the routeing 2856 domain. 2858 e) Local RDI: 2860 This information is contained in managed object localRDI; it is 2861 the RDI of the routeing domain in which the BIS is located. 2863 f) RIBAttsSet: 2865 This managed object lists all of the RIB-Atts (RIB attributes) 2866 which are supported by BISs located in this routeing domain. As 2867 noted in 7.10.1, a RIB-Att is a set of Distinguishing Attributes. 2869 g) Routeing Domain Configuration: 2871 Managed object rdcConfig identifies all the routeing domain 2872 confederations (RDCs) to which the RD of the local BIS belongs, 2873 and it describes the nesting relationships that are in force 2874 between them. It is contained in managed object rdcConfig. 2876 h) Local SNPAs: 2878 Managed object localSNPA contains a list of the SNPAs of the BIS. 2880 7.4 Advertising NLRI 2882 The NLRI field in an UPDATE PDU contains information about the NSAP 2883 addresses of systems that reside within a given routeing domain or 2884 whose NSAP addresses are under control of the administrator of that 2885 routeing domain; it should not be used to convey information about 2886 the operational status of these systems. The information in the NLRI 2887 field is intended to convey static administrative information rather 2888 than dynamic transient information: for example, it is not necessary 2889 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2891 to report that a given system has changed its status from online to 2892 offline. 2894 The following guidelines for inclusion of NSAP address prefixes in 2895 the NLRI field of UPDATE PDUs originated within a given routeing 2896 domain will provide efficient operation of this protocol: 2898 a) NSAP addresses that are within the control of the administrator 2899 of a given routeing domain may be reported in the NLRI field for 2900 that routeing domain. The NSAP prefixes can provide information 2901 about systems that are online, systems that are offline, or 2902 unallocated NSAP addresses. The ability to include unallocated 2903 NSAP addresses and NSAP addresses of offline systems in the NLRI 2904 allows a routeing domain administrator to advertise compact 2905 prefixes, thus minimizing the amount of data carried in the 2906 BISPDUs. 2908 b) NSAP addresses that are known to correspond to systems that are 2909 not under control of the routeing domain administrator should not 2910 be included in the NLRI field for that routeing domain. By not 2911 listing NSAP address prefixes that identify systems that are not 2912 under his control, a routeing domain administrator will comply 2913 with the deployment guidelines for ISs and ESs as described in 2914 7.2.2, thus assuring correct operation of this protocol. 2916 c) For efficient operation of this protocol, the WITHDRAWN ROUTES 2917 field should not be used to report the NLRI of systems in the 2918 local routeing domain that are offline. This field should be 2919 used only to advertise NSAP prefixes that are no longer under 2920 control of the administrator of the local routeing domain, 2921 regardless of whether such systems are online or offline. 2923 Note 9: Although the protocol in this International Standard will 2924 operate correctly if each system is reported individually as 2925 a maximum-length NSAP address prefix, this will result in a 2926 large amount of routeing information, and hence can result 2927 in inefficient operation of this protocol. 2929 This protocol provides no means to verify that the preceding 2930 guidelines are followed. However, it is within the 2931 prerogative of the administrator of any routeing domain to 2932 implement policies that ignore UPDATE PDUs that contain an 2933 excessive amount of NLRI information or that can cause 2934 inefficient operation of this protocol. 2936 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2938 7.5 Receive process 2940 Within the Network layer, the IDRP protocol is located above the 2941 ISO 8473 protocol. Therefore, IDRP relies upon ISO 8473 to perform 2942 the initial processing of incoming PDUs. After processing the input 2943 NPDU, the ISO 8473 protocol machine that resides within the receiving 2944 BIS will deliver: 2946 a) BISPDUs to the IDRP Receive Process, or 2947 b) ISO 8473 NPDUs to the IDRP CLNS Forwarding Process. 2949 The ISO 8473 protocol machine shall process inbound NPDUs according 2950 to the appropriate ISO 8473 functions. 2952 If the NPDU contains an SPI that identifies IDRP, and the NPDU's 2953 source address identifies any system listed in managed objects 2954 internalBIS or externalBISNeighbor, then the data part of the NPDU 2955 contains a BISPDU. This BISPDU shall be passed to the IDRP finite 2956 state machine defined in 7.6.1. 2958 However, if the source address of the NPDU is not an NET listed in 2959 the internalBIS or the externalBISNeighbor attributes of the 2960 idrpConfig Managed Object, then: 2962 a) If the NPDU is an OPEN BISPDU without errors, then the BIS shall 2963 send a notification ("connectRequestBISUnknown") to Systems 2964 Management, 2965 b) If the NPDU is any other BISPDU with or without errors, then the 2966 BIS shall send a notification ("PacketBomb") to Systems 2967 Management. 2969 The NPDU shall then be discarded. 2971 If the SPI identifies ISO 8473, decapsulate the inner PDU and pass it 2972 back to the ISO 8473 protocol machine. (This step permits iterations 2973 on multiply encapsulated NPDUs, which may occur, for example, as 2974 described in 8.4, item b1.) 2975 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 2977 7.6 BIS-BIS connection management 2979 The protocol described in this International Standard relies on the 2980 underlying Network layer service to establish a full-duplex 2981 communications channel between each pair of BISs. 2983 7.6.1 BIS finite state machines 2985 A BIS shall maintain one finite state machine (FSM) for each BIS-BIS 2986 connection that it supports, and each FSM in a given BIS shall run 2987 independently of one another. A BIS-BIS connection will progress 2988 through a series of states during its lifetime, which are summarized 2989 in the state table shown in Table 2. 2991 +--- ----------------------------------------------+ 2992 | Notation Warning | 2993 | To create a readable table within the bounds of a flat ASCII file | 2994 | using a monospaced font at 10 characters/inch, the following | 2995 | abbreviated notation is used within the table: | 2996 | | 2997 | start activate | 2998 | | 2999 | stop deactivate | 3000 | | 3001 | CLSD CLOSED | 3002 | | 3003 | OPRC OPEN-RCVD | 3004 | | 3005 | OPSN OPEN-SENT | 3006 | | 3007 | CLWT CLOSED-WAIT | 3008 | | 3009 | ESTB ESTABLISHED | 3010 | | 3011 | KPALV KEEPALIVE | 3012 | | 3013 | ClWtD CloseWaitDelay | 3014 | | 3015 | LFO ListenForOPEN | 3016 | | 3017 +-------------------------------------------------------------------+ 3019 BISPDUs passed to this finite state machine are subject the flow 3020 control procedures of 7.7.5 if the FSM is in the ESTABLISHED state. 3022 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3024 When the FSM is in the ESTABLISHED state, only BISPDUs that are not 3025 discarded by the flow control process are processed by the FSM. In 3026 all other states, all BISPDUs are processed directly by the finite 3027 state machine without being subject to flow control procedures. 3029 In describing the FSM transitions in response to receipt of BISPDUs, 3030 the following shorthand notation is used: 3032 a) Receive with no errors means that the none of the error 3033 conditions defined in the appropriate subclause of 7.20 have been 3034 detected. 3036 b) Receive with errors means that an error condition defined in the 3037 appropriate subclause of 7.20 has been detected. 3039 It is possible to receive a BISPDU which is properly formed, but 3040 which normally should not be received while the FSM is in the given 3041 state. Such an event constitutes an FSM Error. If an FSM Error can 3042 occur for a given state, it is shown in the description of that 3043 state. 3045 7.6.1.1 CLOSED State 3047 Initially the BIS Finite State Machine is in the CLOSED state. The 3048 CLOSED state exists when no BIS-BIS connection exists and there is no 3049 connection record allocated. 3051 While in the CLOSED state, the BIS shall take the following actions: 3053 a) If the BIS receives a deactivate, no action shall be taken and 3054 the FSM shall remain in the CLOSED state. 3056 b) If the FSM receives an activate, the local BIS shall shall 3057 generate an initial sequence number (see 7.7.4), and shall send 3058 an OPEN PDU to the remote BIS. The sequence field of the OPEN 3059 PDU shall contain the Initial Sequence Number (ISN); the 3060 Acknowledgement and Credit Available fields shall contain the 3061 value 0; and the Credit Offered field shall contain the initial 3062 flow control credit. The FSM shall enter the OPEN-SENT state. 3064 c) If the managed object ListenForOPEN is TRUE, and the BIS receives 3065 an OPEN PDU with no errors, then the local BIS shall generate an 3066 initial sequence number (see 7.7.4) and shall send an OPEN PDU to 3067 the remote BIS. The sequence field of the OPEN PDU shall contain 3068 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3070 the Initial Sequence Number (ISN), the Acknowledgement field 3071 shall acknowledge the received OPEN PDU, the Credit Available 3072 field shall be set according to the procedures of 7.7.5b, and the 3073 Credit Offered field shall contain the initial flow control 3074 credit. The FSM shall then change its state to OPEN_RCVD. 3076 d) If the managed object ListenForOPEN is TRUE and the BIS receives 3077 any BISPDU other than an OPEN PDU with no errors, or if the 3078 managed object ListenForOPEN is FALSE and the BIS receives any 3079 BISPDU, with or without errors, the BIS shall ignore the BISPDU 3080 and the FSM shall remain in the CLOSED state. 3082 7.6.1.2 OPEN-SENT State 3084 While in the OPEN-SENT state, the BIS shall take the following 3085 actions: 3087 a) If the FSM receives an activate, the BIS shall ignore it, and the 3088 FSM shall remain in the OPEN-SENT state. 3090 b) If the FSM receives a deactivate, the BIS shall send a CEASE PDU 3091 to its peer, and the FSM shall enter the CLOSE-WAIT state. 3093 c) If the BIS receives a BISPDU with header errors (see 7.20.1), it 3094 shall log the error event, and the FSM shall remain in the 3095 OPEN-SENT state. 3097 d) If the BIS receives an OPEN PDU with errors (see 7.20.2), it 3098 shall send an IDRP ERROR PDU to the adjacent BIS, acknowledging 3099 the remote BIS's OPEN PDU. The FSM shall then enter the 3100 CLOSE-WAIT state. 3102 e) If the BIS receives an OPEN PDU with no errors that does not 3103 acknowledge its own previously sent OPEN PDU, then the local BIS 3104 shall resend its own OPEN PDU with the same sequence number and 3105 with an acknowledgement of the remote BIS's OPEN PDU. The value 3106 of the Credit Available field shall be set according to the 3107 procedures of 7.7.5b. The FSM shall then change its state to 3108 OPEN-RCVD. 3110 f) If the BIS receives an OPEN PDU with no errors that acknowledges 3111 its own previously sent OPEN PDU, the local BIS shall send a 3112 KEEPALIVE, RIB REFRESH, or UPDATE PDU that acknowledges the OPEN 3113 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3115 PDU received from the remote BIS. The FSM shall then enter the 3116 ESTABLISHED state. 3118 g) If the BIS receives an IDRP ERROR PDU, either with or without 3119 error, it shall send a CEASE PDU, and the FSM shall change its 3120 state to CLOSED. 3122 h) If the BIS receives a RIB REFRESH PDU or UPDATE PDU, either with 3123 or without errors, it shall issue an IDRP ERROR PDU, indicating 3124 "FSM Error". The FSM shall then enter the CLOSE-WAIT state. 3126 i) If the BIS receives a KEEPALIVE PDU, it shall issue an IDRP ERROR 3127 PDU, indicating "FSM Error". The FSM shall then enter the 3128 CLOSE-WAIT state. 3130 j) If the BIS receives a CEASE PDU, it shall issue a CEASE PDU in 3131 return, and then the FSM shall enter the CLOSED state. 3133 k) If the BIS does not receive an OPEN PDU within a period t[ R] 3134 after sending an OPEN PDU, the BIS shall resend the OPEN PDU. If 3135 the OPEN PDU is retransmitted n times, the local BIS shall issue 3136 a deactivate to close the BIS-BIS connection. 3138 Note 10: The value t[R] should be chosen to be large enough so 3139 that attempting to establish a connection to an 3140 unresponsive peer BIS does not consume significant 3141 network resources. The values of t[R] and n must be 3142 chosen so that * n is greater than the 3143 architectural constant CloseWaitDelay. 3145 +----------------------------------------------------------------------+ 3146 | Table 2 (Page 1 of 7). BIS Finite State Machine | 3147 +--------+-----------+-------------+-------------+----------+----------+ 3148 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 3149 | > | | | | | | 3150 +--------+ | | | | | 3151 | INPUT | | | | | | 3152 | V | | | | | | 3153 +--------+-----------+-------------+-------------+----------+----------+ 3154 | start | S=OPSN | S=OPRC | S=OPSN | S=CLWT | S=ESTB | 3155 | | A=send | A=none | A=none | A=none | A=none | 3156 | | OPEN PDU | | | | | 3157 +--------+-----------+-------------+-------------+----------+----------+ 3158 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3160 +----------------------------------------------------------------------+ 3161 | Table 2 (Page 2 of 7). BIS Finite State Machine | 3162 +--------+-----------+-------------+-------------+----------+----------+ 3163 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 3164 | > | | | | | | 3165 +--------+ | | | | | 3166 | INPUT | | | | | | 3167 | V | | | | | | 3168 +--------+-----------+-------------+-------------+----------+----------+ 3169 | stop | S=CLSD | S=CLWT | S=CLWT | S=CLWT | S=CLWT | 3170 | | A=none | A=send | A=send | A=none | A=send | 3171 | | | CEASE PDU | CEASE PDU | | CEASE | 3172 | | | | | | PDU | 3173 +--------+-----------+-------------+-------------+----------+----------+ 3174 | Expiry | S=CLSD | S=OPRC | S=OPSN | S=CLSD | S=ESTB | 3175 | of | A=none | A=none | A=none | A=7.6.2 | A=none | 3176 | ClWtD | | | | | | 3177 | Timer | | | | | | 3178 +--------+-----------+-------------+-------------+----------+----------+ 3179 | Expiry | S=CLSD | S=OPRC | S=OPSN | S=CLWT | S=CLWT | 3180 | of | A=none | A=none | A=none | A=none | A=Send | 3181 | Hold | | | | | IDRP | 3182 | Timer | | | | | ERROR | 3183 | | | | | | PDU to | 3184 | | | | | | report | 3185 | | | | | | error | 3186 +--------+-----------+-------------+-------------+----------+----------+ 3187 | Receive| S=CLSD | S=OPRC | S=OPSN | S=CLWT | S=ESTB | 3188 | BISPDU | A=none | A=log error | A=log error | A=none | A=log | 3189 | with | | event | event | | error | 3190 | Header | | | | | event | 3191 | Error | | | | | | 3192 +--------+-----------+-------------+-------------+----------+----------+ 3193 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3195 +----------------------------------------------------------------------+ 3196 | Table 2 (Page 3 of 7). BIS Finite State Machine | 3197 +--------+-----------+-------------+-------------+----------+----------+ 3198 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 3199 | > | | | | | | 3200 +--------+ | | | | | 3201 | INPUT | | | | | | 3202 | V | | | | | | 3203 +--------+-----------+-------------+-------------+----------+----------+ 3204 | Receive| S=CLSD | If ACK is | S=CLWT | S=CLWT | S=ESTB | 3205 | KPALV | A=none | correct, | A=Send IDRP | A=send | A=Restart| 3206 | PDU | | | ERROR PDU | CEASE, | Hold | 3207 | with | | S=ESTB | to report | restart | Timer | 3208 | no | | A=Restart | FSM Error | ClWtD | | 3209 | errors | | Hold Timer | | timer | | 3210 | | | | | | | 3211 | | | If ACK is | | | | 3212 | | | incorrect, | | | | 3213 | | | | | | | 3214 | | | S=CLWT | | | | 3215 | | | A=Send | | | | 3216 | | | IDRP ERROR | | | | 3217 | | | PDU to | | | | 3218 | | | peer BIS | | | | 3219 | | | to report | | | | 3220 | | | FSM Error | | | | 3221 +--------+-----------+-------------+-------------+----------+----------+ 3222 | Receive| S=CLSD | S=CLSD | S=CLSD | S=CLSD | S=CLSD | 3223 | CEASE | A=none | A=send | A=send | A=7.6.2 | A=send | 3224 | PDU | | CEASE, | CEASE, | | CEASE, | 3225 | with | | 7.6.2 | 7.6.2 | | 7.6.2 | 3226 | no | | | | | | 3227 | errors | | | | | | 3228 +--------+-----------+-------------+-------------+----------+----------+ 3229 | Receive| S=CLOSE | S=CLWT | S=CLWT | S=CLWT | S=CLWT | 3230 | OPEN | A=none | A=Send IDRP | A=Send IDRP | A=none | A=Send | 3231 | PDU | | ERROR PDU | ERROR PDU | | IDRP | 3232 | with | | to peer BIS | to peer BIS | | ERROR | 3233 | errors | | to report | to report | | PDU to | 3234 | | | OPEN PDU | OPEN PDU | | peer BIS | 3235 | | | error | error | | to | 3236 | | | | | | report | 3237 | | | | | | OPEN PDU | 3238 | | | | | | error | 3239 +--------+-----------+-------------+-------------+----------+----------+ 3240 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3242 +----------------------------------------------------------------------+ 3243 | Table 2 (Page 4 of 7). BIS Finite State Machine | 3244 +--------+-----------+-------------+-------------+----------+----------+ 3245 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 3246 | > | | | | | | 3247 +--------+ | | | | | 3248 | INPUT | | | | | | 3249 | V | | | | | | 3250 +--------+-----------+-------------+-------------+----------+----------+ 3251 | Receive| If LFO is | If ACK is | If ACK is | S=CLWT | S=CLWT | 3252 | OPEN | TRUE, | correct, | correct, | A=send | A=Send | 3253 | PDU | | | | CEASE, | IDRP | 3254 | with | S=OPRC | S=ESTB | S=ESTB | restart | ERROR | 3255 | no | A=send | A=send | A=send | ClWtD | PDU to | 3256 | errors | OPEN PDU | KPALV, | KPALV, | timer | peer BIS | 3257 | | | UPDATE, or | UPDATE, or | | to | 3258 | | If LFO is | RIB | RIB | | report | 3259 | | FALSE, | REFRESH | REFRESH | | FSM | 3260 | | | PDU | PDU | | error | 3261 | | S=CLSD | | | | | 3262 | | A=none | If ACK is | If ACK is | | | 3263 | | | incorrect, | incorrect, | | | 3264 | | | | | | | 3265 | | | S=OPRC, | S=OPRC | | | 3266 | | | A=send | A=send | | | 3267 | | | OPEN PDU | OPEN PDU | | | 3268 +--------+-----------+-------------+-------------+----------+----------+ 3269 | Receive| S=CLSD | S=CLWT | S=CLWT | S=CLWT | S=CLWT | 3270 | UPDATE | A=none | A=Send IDRP | A=Send IDRP | A=none | A=Send | 3271 | PDU | | ERROR PDU | ERROR PDU | | IDRP | 3272 | with | | to peer BIS | to peer BIS | | ERROR | 3273 | errors | | to report | to report | | PDU to | 3274 | | | UPDATE PDU | FSM error | | peer BIS | 3275 | | | error | | | to | 3276 | | | | | | report | 3277 | | | | | | UPDATE | 3278 | | | | | | PDU | 3279 | | | | | | error | 3280 +--------+-----------+-------------+-------------+----------+----------+ 3281 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3283 +----------------------------------------------------------------------+ 3284 | Table 2 (Page 5 of 7). BIS Finite State Machine | 3285 +--------+-----------+-------------+-------------+----------+----------+ 3286 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 3287 | > | | | | | | 3288 +--------+ | | | | | 3289 | INPUT | | | | | | 3290 | V | | | | | | 3291 +--------+-----------+-------------+-------------+----------+----------+ 3292 | Receive| S=CLSD | If ACK is | S=CLWT | S=CLWT | S=ESTB | 3293 | UPDATE | A=none | correct, | A=Send IDRP | A=send | A=7.14, | 3294 | PDU | | | ERROR PDU | CEASE, | restart | 3295 | with | | S=ESTB | to peer BIS | restart | Hold | 3296 | no | | A=7.14, | to report | ClWtD | Timer | 3297 | errors | | restart | FSM error | timer | | 3298 | | | Hold Timer | | | | 3299 | | | | | | | 3300 | | | If ACK is | | | | 3301 | | | incorrect, | | | | 3302 | | | | | | | 3303 | | | S=CLWT | | | | 3304 | | | A=Send | | | | 3305 | | | IDRP ERROR | | | | 3306 | | | PDU to | | | | 3307 | | | peer BIS | | | | 3308 | | | to report | | | | 3309 | | | FSM Error | | | | 3310 +--------+-----------+-------------+-------------+----------+----------+ 3311 | Receive| S=CLSD | S=CLSD | S=CLSD | S=CLSD | S=CLSD | 3312 | IDRP | A=none | A=Send | A=Send | A=Send | A=Send | 3313 | ERROR | | CEASE PDU, | CEASE PDU, | CEASE | CEASE | 3314 | PDU | | 7.6.2 | 7.6.2 | PDU, | PDU, | 3315 | with | | | | 7.6.2 | 7.6.2 | 3316 | errors | | | | | | 3317 +--------+-----------+-------------+-------------+----------+----------+ 3318 | Receive| S=CLSD | S=CLSD | S=CLSD | S=CLSD | S=CLSD | 3319 | IDRP | A=none | A=Send | A=Send | A=Send | A=Send | 3320 | ERROR | | CEASE PDU, | CEASE PDU, | CEASE | CEASE | 3321 | PDU | | 7.6.2 | 7.6.2 | PDU, | PDU, | 3322 | with | | | | 7.6.2 | 7.6.2 | 3323 | no | | | | | | 3324 | errors | | | | | | 3325 +--------+-----------+-------------+-------------+----------+----------+ 3326 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3328 +----------------------------------------------------------------------+ 3329 | Table 2 (Page 6 of 7). BIS Finite State Machine | 3330 +--------+-----------+-------------+-------------+----------+----------+ 3331 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 3332 | > | | | | | | 3333 +--------+ | | | | | 3334 | INPUT | | | | | | 3335 | V | | | | | | 3336 +--------+-----------+-------------+-------------+----------+----------+ 3337 | Receive| S=CLSD | S=CLWT | S=CLWT | S=CLWT | S=CLWT | 3338 | RIB | A=none | A=Send IDRP | A=Send IDRP | A=none | A=Send | 3339 | REFRESH| | ERROR PDU | ERROR PDU | | IDRP | 3340 | PDU | | to peer BIS | to peer BIS | | ERROR | 3341 | with | | to report | to report | | PDU to | 3342 | errors | | RIB REFRESH | FSM error | | peer BIS | 3343 | | | PDU error | | | to | 3344 | | | | | | report | 3345 | | | | | | RIB | 3346 | | | | | | REFRESH | 3347 | | | | | | PDU | 3348 | | | | | | error | 3349 +--------+-----------+-------------+-------------+----------+----------+ 3350 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3352 +----------------------------------------------------------------------+ 3353 | Table 2 (Page 7 of 7). BIS Finite State Machine | 3354 +--------+-----------+-------------+-------------+----------+----------+ 3355 | STATE | CLSD | OPRC | OPSN | CLWT | ESTB | 3356 | > | | | | | | 3357 +--------+ | | | | | 3358 | INPUT | | | | | | 3359 | V | | | | | | 3360 +--------+-----------+-------------+-------------+----------+----------+ 3361 | Receive| S=CLSD | If ACK is | S=CLWT | S=CLWT | S=ESTB | 3362 | RIB | A=none | correct, | A=Send IDRP | A=send | A=7.10.3,| 3363 | REFRESH| | | ERROR PDU | CEASE, | restart | 3364 | PDU | | S=ESTB | to report | restart | Hold | 3365 | with | | A=7.10.3, | FSM Error | ClWtD | Timer | 3366 | no | | restart | | timer | | 3367 | errors | | Hold Timer | | | | 3368 | | | | | | | 3369 | | | If ACK is | | | | 3370 | | | incorrect, | | | | 3371 | | | | | | | 3372 | | | S=CLWT | | | | 3373 | | | A=Send | | | | 3374 | | | IDRP ERROR | | | | 3375 | | | PDU to | | | | 3376 | | | peer BIS | | | | 3377 | | | to report | | | | 3378 | | | FSM Error | | | | 3379 +--------+-----------+-------------+-------------+----------+----------+ 3380 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3382 +----------------------------------------------------------------------+ 3383 | Notes: | 3384 | | 3385 | a) "S" indicates the state into which the FSM will make a | 3386 | transition after performing the indicated action. | 3387 | | 3388 | b) "A" indicates the action to be taken. | 3389 | | 3390 | c) "X.Y.Z" is shorthand notation for "do as specified in clause | 3391 | X.Y.Z". | 3392 | | 3393 | d) The phrase "no errors" for a given BISPDU type means that no | 3394 | condition described in the appropriate subclause of 7.20 has | 3395 | been detected. | 3396 | | 3397 | e) The phrase "with errors" for a given BISPDU type means that a | 3398 | condition described in the appropriate subclause of 7.20 has | 3399 | been detected. | 3400 | | 3401 | f) Since the KPALV PDU and the CEASE PDU consist of only a fixed | 3402 | BISPDU header, errors in these BISPDUs are handled as Header | 3403 | Errors. Hence, there are no explicit entries in the table for | 3404 | "KPALV with errors" or "CEASE with errors". | 3405 +----------------------------------------------------------------------+ 3407 7.6.1.3 OPEN-RCVD State 3409 While in the OPEN-RCVD state, the BIS shall take the following 3410 actions: 3412 a) If the BIS receives an activate, it shall ignore it and the FSM 3413 shall remain in the OPEN-RCVD state. 3415 b) If the BIS receives a deactivate, it shall send a CEASE PDU to 3416 the remote BIS, and the FSM shall enter the CLOSE-WAIT state. 3418 c) If the BIS receives a BISPDU with a header error, it shall log 3419 the error event, and the FSM shall remain in the OPEN-RCVD state. 3421 d) If the BIS receives a KEEPALIVE PDU that acknowledges its 3422 previously sent OPEN PDU, then the FSM shall enter the 3423 ESTABLISHED state. 3425 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3427 e) If the BIS receives a KEEPALIVE PDU that does not acknowledge its 3428 previously sent OPEN PDU, the BIS shall issue an IDRP ERROR PDU 3429 indicating "FSM Error", and the FSM shall change its state to 3430 CLOSE-WAIT. 3432 f) If the BIS receives a CEASE PDU, it shall issue a CEASE PDU in 3433 return, and then the FSM shall enter the CLOSED state. 3435 g) If the BIS receives an OPEN PDU with no errors from the remote 3436 BIS that acknowledges the local BIS's previously sent OPEN PDU, 3437 the BIS shall send a KEEPALIVE, RIB REFRESH, or UPDATE PDU that 3438 acknowledges the OPEN PDU received from the remote BIS. The FSM 3439 shall then enter the ESTABLISHED state. 3441 h) If the BIS receives an OPEN PDU with no errors that does not 3442 acknowledge the local BIS's previously sent OPEN PDU, then the 3443 local BIS shall resend its own OPEN PDU with the same sequence 3444 number, and shall also include an acknowledgement of the remote 3445 BIS's OPEN PDU. The FSM shall remain in the OPEN-RCVD state. 3447 i) If the BIS receives an UPDATE PDU or RIB REFRESH PDU with errors, 3448 theBIS shall send an IDRP ERROR PDU to the remote BIS, and the 3449 FSM shall enter the CLOSE-WAIT state. 3451 j) If the BIS receives an UPDATE PDU or RIB REFRESH PDU with no 3452 errors that acknowledges the OPEN PDU previously sent by the 3453 local BIS, the FSM shall enter the ESTABLISHED state. 3455 k) If the BIS receives an UPDATE PDU or RIB REFRESH PDU with no 3456 errors that does not acknowledge the OPEN PDU previously sent by 3457 the local BIS, the BIS shall issue an IDRP ERROR PDU indicating 3458 "FSM Error", and the FSM shall change its state to CLOSE-WAIT. 3460 l) If the BIS receives an IDRP ERROR PDU, either with or without 3461 errors, it shall send a CEASE PDU to the remote BIS, and the FSM 3462 shall enter the CLOSED state. 3464 m) If the BIS does not exit the OPEN-RCVD state within a period t[R] 3465 after sending an OPEN PDU, the BIS shall resend the OPEN PDU. If 3466 the OPEN PDU is transmitted n times, the local BIS shall issue a 3467 deactivate. 3469 Note 11: The value t[R] should be chosen to be large enough so 3470 that attempting to establish a connection to an 3471 unresponsive peer BIS does not consume significant 3472 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3474 network resources. The values of t[R] and n must be 3475 chosen so that * n is greater than the 3476 architectural constant CloseWaitDelay. 3478 7.6.1.4 ESTABLISHED State 3480 The ESTABLISHED state is entered from either the OPEN-SENT or the 3481 OPEN-RCVD states. It is entered when a connection has been 3482 established by the successful exchange of state information between 3483 two sides of the connection. Each side has exchanged and received 3484 such data as initial sequence number, maximum PDU size, credit 3485 offered, protocol version number, hold time, and RDI of the other 3486 side. In addition, the remote BIS may also have been authenticated. 3488 In ESTABLISHED state, both BISs that are involved in the connection 3489 may exchange UPDATE PDUs, KEEPALIVE PDUs, IDRP ERROR PDUs, RIB 3490 REFRESH PDUs, and CEASE PDUs. 3492 While in the ESTABLISHED state, the local BIS shall take the 3493 following actions: 3495 a) If the FSM receives an activate, the FSM shall ignore it, and the 3496 FSM shall remain in the ESTABLISHED state. 3498 b) If the FSM receives a deactivate, the BIS shall send a CEASE PDU 3499 to the peer BIS. The FSM shall enter the CLOSE-WAIT state. 3501 c) If the Hold Timer expires, the BIS shall issue an IDRP ERROR PDU 3502 to the remote BIS, reporting a Hold_Timer error. The FSM shall 3503 enter the CLOSE-WAIT state. 3505 d) If the BIS receives a BISPDU with a header error, it shall log 3506 the error event, and the FSM shall remain in the ESTABLISHED 3507 state. 3509 e) If the BIS receives a KEEPALIVE PDU, it shall restart its Hold 3510 Timer, and the FSM shall remain in the ESTABLISHED state. 3512 f) If the BIS receives a CEASE PDU, it shall issue a CEASE PDU in 3513 return, and then the FSM shall enter the CLOSED state. 3515 g) If an OPEN PDU with no errors is received from the peer BIS, it 3516 shall issue an IDRP ERROR PDU, indicating FSM error. The FSM 3517 shall enter the CLOSE-WAIT state. 3519 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3521 h) If the BIS receives an UPDATE PDU with no errors, the BIS shall 3522 perform the actions provided in 7.14, and shall restart its Hold 3523 Timer. The FSM shall remain in the ESTABLISHED state. 3525 i) If the BIS receives a RIB REFRESH PDU with no errors, the BIS 3526 shall perform the actions provided in 7.10.3, and shall restart 3527 its Hold Timer. The FSM shall remain in the ESTABLISHED state. 3529 j) If the BIS receives an UPDATE PDU with errors, an OPEN PDU with 3530 errors, or a RIB REFRESH PDU with errors, it shall send an IDRP 3531 ERROR PDU to the remote BIS to report the error, and the FSM 3532 shall enter the CLOSE-WAIT state. 3534 k) If the BIS receives an IDRP ERROR PDU, either with or without 3535 errors, it shall send a CEASE PDU to the remote BIS. The FSM 3536 shall enter the CLOSED state. 3538 7.6.1.5 CLOSE-WAIT State 3540 When an FSM enters the CLOSE-WAIT state, the local BIS is preparing 3541 to close the connection with the remote BIS. Upon entering this 3542 state, the local BIS shall mark all entries in the Adj-RIB-In 3543 associated with the adjacent BIS as unreachable, and shall then 3544 re-run its Decision Process. The CloseWaitDelay timer shall be 3545 started. 3547 While in the CLOSE-WAIT state, the BIS shall take the following 3548 actions: 3550 a) If the CloseWaitDelay timer expires, the connection ceases to 3551 exist. The FSM shall enter the CLOSED state. 3553 b) If the BIS receives a CEASE PDU, the FSM shall enter the CLOSED 3554 state. 3556 c) If the BIS receives an IDRP ERROR PDU, it shall send a CEASE PDU 3557 to the peer BIS. The FSM shall then enter the CLOSED state. 3559 d) If the BIS receives any other type of BISPDU, with or without 3560 errors, it shall issue a CEASE PDU. The FSM shall remain in the 3561 CLOSE-WAIT state, and the CloseWaitDelay timer shall be 3562 restarted. 3564 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3566 e) The BIS shall take no action for any of the following inputs, and 3567 the FSM shall remain in the CLOSE-WAIT state: 3569 - activate 3570 - deactivate 3571 - Expiration of Hold Timer 3573 7.6.2 Closing a connection 3575 The closing of a connection can be initiated by a deactivate 3576 generated by the local system, by receipt of an incorrect PDU, by 3577 receipt of a IDRP ERROR PDU, by expiration of the Hold Timer, or by 3578 receipt of a CEASE PDU. The actions taken in response to each of 3579 these stimuli are shown in Table 2 3581 When the connection enters the CLOSED state, the sequence number last 3582 used by the local BIS is recorded in managed object lastPriorSeqNo, 3583 and all routes that had been exchanged between the pair of BISs are 3584 implicitly withdrawn from service; hence, the local BIS should rerun 3585 its Decision Process. 3587 7.7 Validation of BISPDUs 3589 The protocol described in this International Standard is a connection 3590 oriented protocol in which the underlying Network Layer service is 3591 used to establish full-duplex communication channels between pairs of 3592 BISs, as described in 7.6. This International Standard supports the 3593 use of any of the following three mechanisms for validating BISPDUs. 3594 Types 1,2, and 3 provide data integrity for the contents of BISPDUs; 3595 in addition, types 2 and 3 provide peer BIS authentication. Each 3596 mechanism is described below. Figure 6 illustrates the data 3597 integrity mechanisms used for authentication types 1 and 3; 3598 informative Annex D describes an example approach that might be used 3599 to provide both data integrity and peer BIS authentication for 3600 authentication type 2. 3602 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3604 +----------------------------------------------------------------------+ 3605 | | 3606 | auth13 | 3607 | | 3608 +----------------------------------------------------------------------+ 3609 Figure 6. Illustration of Authentication Types 1 and 3 3611 7.7.1 Authentication type 1 3613 For all BISPDUs that flow on a connection that was established in 3614 response to an OPEN PDU whose authentication code field was equal to 3615 1, the validation field shall contain a 16-octet unencrypted 3616 checksum: 3618 a) Generating a Validation Pattern: 3620 The contents of the Validation Pattern field that is included in 3621 an outbound BISPDU shall be generated by applying the algorithm 3622 of Annex B to the input data stream that consists of the contents 3623 of the entire BISPDU with all bits of the Validation Pattern 3624 field initially set to 0. The output of this step is an 3625 unencrypted 16-octet long checksum, which shall be placed in the 3626 Validation Pattern field of the BISPDU. 3628 b) Checking the Validation Pattern of an Inbound BISPDU: 3630 The contents of the Validation Pattern field of an inbound BISPDU 3631 shall be checked by applying the algorithm of Annex B to the 3632 contents of the inbound BISPDU with its Validation Pattern set to 3633 all zeros. Call this quantity the "reference pattern". 3635 If the "reference pattern" matches the contents of the Validation 3636 Pattern field of the inbound BISPDU, then the BISPDU's checksum 3637 is correct; otherwise, it is incorrect. 3639 7.7.2 Authentication type 2 3641 When the authentication type code of the OPEN PDU is 2, the pattern 3642 carried in the 16-octet Validation Pattern field of the fixed header 3643 shall provide both peer-BIS authentication and data integrity for the 3644 contents of the BISPDU. The specific mechanisms used to provide 3645 these functions are not specified by this International Standard. 3646 However, they must be agreed to by the pair of communicating BISs as 3647 part of their security association. 3649 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3651 An example of type 2 authentication that uses an encrypted version of 3652 MD4 checksum is described in Annex D. 3654 Note 12: This International Standard includes as an optional 3655 function a mechanism that can be used for authentication of 3656 the source of a BISPDU. Other security-related facilities 3657 (for example, protection against replay of BISPDUs or the 3658 ability to re-key during a BIS_BIS connection) are not 3659 intended to be provided by this protocol, and therefore are 3660 not specified in this International Standard. 3662 All of the relevant security services identified in ISO 3663 7498-2, including authentication, could be achieved by the 3664 use of ISO/IEC 11577, a security protocol specified for the 3665 provision of secure ISO 8473 communications (for example, 3666 see 9.1). 3668 7.7.3 Authentication type 3 3670 When the authentication type code of the OPEN PDU is 3, the 3671 Validation Pattern field shall contain a 16-octet checksum covering 3672 both the contents of the BISPDU and some additional Password Text, 3673 which is not transmitted to the peer BIS. The checksum provides data 3674 integrity and the untransmitted Password Text provides peer BIS 3675 authentication. 3677 The mechanisms are as follows: 3679 a) Generating a Validation Pattern: 3681 The contents of the Validation Pattern field that is carried in 3682 the outbound BISPDU shall be generated by the following process, 3683 which is illustrated in Figure 6. 3685 1) Password text shall be appended to the BISPDU immediately 3686 after the final octet of the BISPDU (as defined by the BISPDU 3687 length field of the BISPDU header). Additional password text 3688 may also be prepended to the BISPDU immediately prior to the 3689 first octet of its header. 3690 2) A checksum that covers the concatenated contents of the 3691 BISPDU and the password text shall be generated using the 3692 methods of Annex B with all bits of the Validation Pattern 3693 initially set to zero. The resultant checksum shall then be 3694 placed in the Validation Pattern field of the BISPDU. 3696 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3698 3) The password text shall not be transmitted along with the 3699 BISPDU. 3701 b) Checking the Validation Pattern of an Inbound BISPDU: 3703 The contents of the Validation Pattern field of an inbound BISPDU 3704 shall be checked by the following procedure: 3706 1) Append the Password Text to the BISPDU immediately after the 3707 final octet of the BISPDU (as defined by the BISPDU Length 3708 field of the BISPDU header. If additional Password text was 3709 also prepended to the BISPDU by the sender, then prepend this 3710 text immediately prior to the first octet of the BISPDU. 3711 2) Apply the IDRP Checksum Algorithm to the data stream that 3712 consists of the concatenated contents of the BISPDU and the 3713 password text, with all bits of the BISPDU Validation Pattern 3714 set to zero. Call this value the "reference pattern". 3715 3) If the "reference pattern" is identical to the data carried 3716 in the Validation Pattern of the incoming BISPDU, then the 3717 peer BIS has been authenticated. If the "reference pattern" 3718 does not match the Validation Pattern, the receiving BIS 3719 shall inform system management that an authentication failure 3720 has occurred. The incoming BISPDU shall be ignored. The 3721 receiving BIS shall not send an IDRP ERROR PDU to the peer 3722 BIS because the identity of the peer has not been 3723 authenticated. 3725 7.7.4 Sequence numbers 3727 A sequence number is a 4-octet unsigned value. Sequence numbers 3728 shall increase linearly from 1 up to a maximum value of <2^32>-1. 3729 The value 0 is not a valid sequence number. 3731 The rules for manipulating sequence numbers are: 3733 a) When a BIS initially establishes a connection with an adjacent 3734 BIS, the first sequence number shall be set to 1 and shall 3735 increase linearly to a value of <2^32>-1. Before attempting to 3736 establish an initial BIS-BIS connection with an adjacent BIS, the 3737 local BIS must ensure that it has not sent a BISPDU to the 3738 adjacent BIS for at least CloseWaitDelay seconds. 3740 b) The sequence number shall not be incremented for the KEEPALIVE 3741 PDU, CEASE PDU, and the IDRP ERROR PDU. 3743 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3745 c) If the connection is subsequently closed under the conditions 3746 described in Table 2 and a subsequent connection is to be made to 3747 the same adjacent BIS, the local BIS shall, as a local matter, 3748 choose one of the following options: 3750 1) Maintain status of the sequence number space, and use any 3751 value greater than the value last used in the prior BIS-BIS 3752 connection (lastPriorSeqNo), or 3753 2) Ensure that at least CloseWaitDelay seconds have passed since 3754 the last BISPDU was sent to the adjacent BIS, and start with 3755 any sequence number. The choice of the initial value of the 3756 sequence number is a local matter. 3758 d) After a BIS sends a BISPDU with the maximum permissible sequence 3759 number (<2^32>-1) the BIS shall not send any further BISPDUs 3760 until the BISPDU with maximum sequence number and all outstanding 3761 BISPDUs have been acknowledged using the procedure of 7.7.5. The 3762 BIS then shall set its lower window edge (see 7.7.5) to one. 3763 When a BIS receives a BISPDU with a sequence number of one, after 3764 having acknowledged a BISPDU with the maximum permissible 3765 sequence number, it shall set the value of its next expected 3766 sequence number to one, prior to processing that BISPDU. 3768 Note 13: The maximum lifetime of an ISO 8473 NPDU is 128 s. 3769 Since the architectural constant CloseWaitDelay is 150 3770 s, it can be guaranteed that all outstanding BISPDUs 3771 (which are carried as user data within an encapsulating 3772 8473 NPDU) will have expired before the new BIS-BIS 3773 connection is established. 3775 7.7.5 Flow control 3777 After an IDRP connection is established, the BIS Finite State Machine 3778 is in state ESTABLISHED (see section 7.6.1), and flow control and 3779 packet sequencing is in effect. The IDRP flow control process shall 3780 obey the following rules: 3782 a) A separate series of sequence numbers shall be maintained for 3783 each direction of a BIS-BIS connection, with the initial sequence 3784 number value chosen by the sender of a BISPDU and declared in the 3785 Sequence field of its OPEN PDU. The local BIS will maintain a 3786 window to manage transmission of BISPDUs to the remote BIS. The 3787 sender's lower window edge shall be set to the initial sequence 3788 number plus one; the sender's upper window edge shall be set to 3789 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3791 the lower window edge plus the value of credit offered contained 3792 in the peer BIS's OPEN PDU. Record is also kept of the next 3793 expected sequence number for an inbound UPDATE, RIB REFRESH, 3794 KEEPALIVE, or OPEN PDU to be received from the peer BIS; this is 3795 initially set to the value of one plus Sequence that is carried 3796 in the peer BIS's OPEN PDU. 3798 b) An UPDATE PDU or RIB REFRESH PDU shall not be sent if the upper 3799 window edge is less than or equal to the lower window edge. When 3800 a BISPDU is sent, the value of Sequence in the fixed header shall 3801 be set to the current value of the lower window edge. When an 3802 UPDATE or RIB REFRESH PDU is to be sent, the local BIS shall 3803 generate the contents of the BISPDU based on the current value of 3804 the lower window edge. The local BIS shall increment the local 3805 window edge by one before it transmits the BISPDU to the peer BIS 3806 and before it generates any other BISPDUs or processes any 3807 received BISPDUs; when a BISPDU other than an UPDATE or RIB 3808 REFRESH PDU is to be sent, the lower window edge shall not be 3809 incremented. The value of Acknowledgement shall be set to the 3810 value of the next expected sequence number less one. The value 3811 of credit offered shall be set to the number of additional 3812 BISPDUs that the local BIS is currently able to accept from the 3813 peer BIS. Credit, once offered, can not be revoked (that is, the 3814 remote BIS's upper window edge can not be reduced). Therefore, 3815 the sum of Acknowledgement and credit offered must never decrease 3816 in successive BISPDUs. The value of credit available shall be 3817 set to the upper window edge less the lower window edge (after 3818 incrementing the lower window edge, if appropriate). 3820 The local BIS shall retain a copy of transmitted UPDATE and RIB 3821 REFRESH BISPDUs for possible retransmission. 3823 c) An incoming UPDATE PDU or RIB REFRESH PDU whose Sequence value 3824 corresponds to the next expected sequence number shall be 3825 accepted and passed to the Finite State Machine described in 3826 7.6.1; the next expected sequence number shall be incremented by 3827 one. 3829 An incoming UPDATE PDU or RIB REFRESH PDU whose Sequence is less 3830 than the next expected sequence number shall be discarded. An 3831 incoming UPDATE PDU or RIB REFRESH PDU whose Sequence is greater 3832 than the next expected sequence number shall be discarded, unless 3833 re-ordering is supported as a local implementation option, and 3834 the sequence number is not greater than the peer's upper window 3835 edge. 3837 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3839 An incoming KEEPALIVE PDU or OPEN PDU whose Sequence value 3840 corresponds to the next expected sequence number shall be 3841 accepted and passed to the Finite State Machine described in 3842 7.6.1. An incoming KEEPALIVE PDU or OPEN PDU whose Sequence does 3843 not correspond to the next expected sequence number shall be 3844 discarded. 3846 An Incoming CEASE PDU or IDRP ERROR PDU shall be accepted and 3847 passed to the Finite State Machine described in 7.6.1regardless 3848 of its Sequence value. 3850 Whenever a BIS receives an UPDATE PDU, RIB REFRESH PDU, or 3851 KEEPALIVE PDU, it shall inspect its Acknowledgement and credit 3852 offered fields. Any BISPDUs retained for retransmission whose 3853 sequence number is less than or equal to the value of the 3854 Acknowledgement field shall be discarded. If the sum of one plus 3855 the value of Acknowledgement plus the value of credit offered in 3856 the received BISPDU is greater than the local BIS's current upper 3857 window edge, then the BIS shall set its upper window edge to this 3858 sum. 3860 d) A BIS shall acknowledge receipt of incoming UPDATE PDUs and RIB 3861 REFRESH PDUs within a period t[A] of their receipt. The 3862 acknowledgement may be accomplished by means of an UPDATE PDU or 3863 a RIB REFRESH PDU sent as outlined in item b above. However, if 3864 no UPDATE PDU or RIB REFRESH PDU is available to be sent, then a 3865 KEEPALIVE PDU may be sent instead, with its Sequence set to the 3866 lower window edge and its Acknowledgement, credit offered, and 3867 credit available set as in step b above. 3869 e) If a retained BISPDU remains unacknowledged after a period t[R], 3870 then it shall again be transmitted and again retained for 3871 possible retransmission. If, for a retained BISPDU, t[R] expires 3872 after n retransmissions, the local BIS shall issue a deactivate 3873 to close the BIS-BIS connection. 3875 Note 14: The value t[R] should be chosen to be greater than the 3876 value + 2*L, where L is the transmission delay 3877 over the subnetwork or virtual link between the pair of 3878 communicating BISs. 3880 f) The local BIS shall provide its peer BIS with sufficient credit 3881 to send further BISPDUs as long as the local BIS has resources to 3882 receive them. Therefore, if the local BIS receives a BISPDU 3883 whose credit available is equal to zero (that is, the peer BIS 3884 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3886 believes itself unable to send additional BISPDUs), then as soon 3887 as resources are available locally, the local BIS shall send an 3888 UPDATE PDU or a RIB REFRESH PDU, if appropriate. If not, then a 3889 KEEPALIVE PDU shall be sent. 3891 Note 15: An UPDATE PDU of minimal size will contain the 3892 Unfeasible Route Count field with a value of zero, but 3893 will not contain any path attributes or NLRI. Thus, 3894 its size will be only 33 octets. 3896 A KEEPALIVE PDU that advertises a non-zero value of credit 3897 offered in response to a received BISPDU with a credit available 3898 of zero shall be retransmitted within a period t[R] until the 3899 local BIS receives any in-sequence BISPDU that reports a non-zero 3900 value of credit available. If t[R] expires after n 3901 retransmissions, then the local BIS shall issue a deactivate to 3902 close the connection. 3904 g) A BIS that has sent a BISPDU with zero credit available to its 3905 neighbor shall respond within a period t[A] to a BISPDU from that 3906 neighbor that causes its upper window edge to be increased. The 3907 response shall consist of an UPDATE PDU or a RIB REFRESH PDU, if 3908 available, or a KEEPALIVE PDU, if not. 3910 h) A BIS that has not sent any BISPDU for a period t[I] shall send a 3911 KEEPALIVE PDU, with Sequence equal to the lower window edge, and 3912 Acknowledgement, credit offered, and credit available set as in 3913 step b above. 3915 Note 16: The condition (t[I]) >> (t[R]) should be satisfied, 3916 where t[I] is one third of the Hold Timer value. 3918 i) A BIS that has sent a BISPDU containing a credit offered of zero 3919 shall, as soon as its local resources become available to process 3920 additional BISPDUs from its peer, send an UPDATE PDU or RIB 3921 REFRESH PDU, if appropriate, containing a non-zero value of 3922 credit offered. If neither of these BISPDU types is appropriate, 3923 then a KEEPALIVE PDU shall be sent. 3925 j) The BIS shall issue a deactivate to close the BIS-BIS connection 3926 if no BISPDUs are received for a period equal to the value of 3927 Hold Time that is carried in the OPEN PDU. 3929 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3931 7.8 Version negotiation 3933 BIS peers may negotiate the version number of IDRP by making 3934 successive attempts to open a BIS-BIS connection, starting with the 3935 highest supported version number (contained in managed object 3936 version) and decrementing the number each time a connection attempt 3937 fails. The lack of support for a particular IDRP version is 3938 indicated by an IDRP ERROR PDU with error code "OPEN_PDU_Error" and 3939 an error subcode of "Unsupported_Version_Number". One BIS may 3940 determine the highest version number supported by the other BIS (as 3941 advertised in its OPEN PDU) by examining the "Data" field of the 3942 received IDRP ERROR PDU. No further retries should be attempted if 3943 the version number reaches zero. 3945 7.9 Checksum algorithm 3947 The checksums used in this International Standard for authentication 3948 types 1 and 3 shall be generated in accordance with the procedures 3949 described in normative Annex B. For an input data stream of any 3950 length, this algorithm will generate a checksum that is 16 octets 3951 long. This algorithm shall be used to generate the checksums for 3952 both the BISPDUs and the RIBs. 3954 7.10 Routeing information bases 3956 The Routeing Information Base (RIB) within a BIS consists of three 3957 distinct parts, as shown in Figure 7: 3959 a) Adj-RIBs-In: The Adj-RIBs-In store routeing information that has 3960 been learned from inbound UPDATE PDUs. Their contents represent 3961 routes that are available as input to the Decision Process. A 3962 BIS must support at least one Adj-RIB-In for each of its neighbor 3963 BISs; it may optionally support several Adj-RIBs-In for a given 3964 neighbor BIS. Within the set of Adj-RIBs-In associated with a 3965 given neighbor BIS, no two shall have the same RIB-Att (see 3966 7.10.1). 3968 b) Loc-RIBs: The Loc-RIBs contain the local routeing information 3969 that the BIS has selected by applying its local policies to the 3970 routeing information contained in its Adj-RIBs-In. A BIS may 3971 support multiple Loc-RIBs. No two Loc-RIBs within a given BIS 3972 shall have the same RIB-Att (see clause 7.10.1). Information in 3973 the Loc-RIB is used to build the Adj-RIBs-Out. 3975 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 3977 +----------------------------------------------------------------------+ 3978 | | 3979 | yr2 | 3980 | | 3981 +----------------------------------------------------------------------+ 3982 Figure 7. Routeing Information Base. An RIB is comprised of 3983 Adj-RIBs-In, Adj-RIBs-Out, and Loc-RIBs 3985 c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the 3986 local BIS has selected for advertisement to its neighbors. A BIS 3987 must support at least one Adj-RIB-Out for each of its neighbor 3988 BISs; it may optionally support several Adj-RIBs-Out for a given 3989 neighbor BIS. Within the set of Adj-RIBs-Out associated with a 3990 given neighbor BIS, no two shall have the same RIB-Att (see 3991 7.10.1). The routeing information stored in the Adj-RIBs-Out 3992 will be carried in the local BIS's UPDATE PDUs and advertised to 3993 its neighbor BISs. 3995 In summary, the Adj-RIBs-In contain unprocessed routeing information 3996 that has been advertised to the local BIS by its neighbors; the 3997 Loc-RIBs contain the routes that have been selected by the local 3998 BIS's Decision Process; and the Adj-RIBs-Out organize the selected 3999 routes for advertisement to specific neighbor BISs by means of the 4000 local BIS's UPDATE PDUs. 4002 Note 17: Although the conceptual model distinguishes between 4003 Adj-RIBs-In, Adj-RIBs-Out, and Loc-RIBs, this does neither 4004 implies nor requires that an implementation must maintain 4005 three separate copies of the routeing information. The 4006 choice of implementation (for example, 3 copies of the 4007 information vs. 1 copy with pointers) is not constrained by 4008 this standard. 4010 7.10.1 Identifying an information base 4012 Each information base (a single Adj-RIB-In, a single Loc-RIB, or a 4013 single Adj-RIB-Out) has one and only one RIB-Att associated with it. 4014 A RIB-Att is composed of a set of Distinguishing Attributes that the 4015 local BIS supports: in particular, a RIB-Att may consist of one or 4016 more Distinguishing Attributes that form a permissible combination, 4017 as defined in 7.11.2. 4019 The managed object RIBAttsSet explicitly enumerates all the RIB-Atts 4020 that a BIS supports. Managed object RIB-AttsSet shall not contain 4021 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4023 any pairs of RIB-Atts that are identical, thus assuring that each 4024 RIB-Att is unambiguous within the BIS. 4026 All BISs located within a given routeing domain shall support the 4027 same RIB-Atts: that is, the managed object RIB-AttsSet of every BIS 4028 within an RD shall list the same RIB-Atts. When a BIS receives an 4029 OPEN PDU from another BIS located in its own routeing domain, it 4030 shall compare the information in the field RIB-AttsSet with the 4031 information in its local managed object RIBAttsSet. If they do not 4032 match, then the appropriate error handling procedure in 7.20.2 shall 4033 be followed. 4035 Each BIS shall support default information bases (Adj-RIBs-In, 4036 Adj-RIBs-Out, Loc-RIB, and FIB) that correspond to the RIB-Att that 4037 is composed of an empty set of Distinguishing Attributes. 4039 Note 18: Because policy is a local matter, IDRP does not specify the 4040 criterion used to select the information to be placed in 4041 the default Loc-RIB. However, since the following 4042 mandatory path attributes are present in every route, it is 4043 suggested that RD_PATH and RD_HOP_COUNT should be used for 4044 this purpose. 4046 7.10.2 Validation of RIBs 4048 A BIS shall not continue to operate for an extended period with 4049 corrupted routeing information. Therefore, the BIS shall operate in 4050 a "fail-stop" manner: when corruption of a RIB is detected, the BIS 4051 shall immediately take action to cease using the routes contained in 4052 the corrupted information base. 4054 In the absence of an implementation-specific method for insuring 4055 this, the BIS shall perform the following checks at least every 4056 maxRIBIntegrityCheck seconds: 4058 a) Upon expiration of its maxRIBIntegrityCheck timer, the BIS shall 4059 recheck the checksum of the routeing information contained in 4060 each of its Adj-RIBs-In in order to detect corruption of routeing 4061 information while in memory. 4063 If corruption is detected, the BIS shall purge the Adj-RIB-In, 4064 and shall notify System Management of a "Corrupted AdjRIBIn" 4065 event. 4067 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4069 Note 19: This International Standard does not prescribe a 4070 specific checksum algorithm but notes that the 4071 procedures described in Annex F satisfy the 4072 requirements given above. Other approaches can also be 4073 used: for example, it may be possible to use an 4074 incremental algorithm to compute the checksum for a 4075 given Adj-RIB-In when new information is received. 4077 After detection of a corrupted Adj-RIB-In, a BIS may 4078 choose to issue a RIB REFRESH PDU, asking for a 4079 solicited refresh of the routeing information from its 4080 peer BIS. 4082 b) On completion of its check of the Adj-RIBs-In, the BIS shall 4083 rerun its Decision Process, regardless of whether or not 4084 corruption of the Adj-RIBs-In has been detected. As a byproduct 4085 of running the Decision Process, the BIS will construct new 4086 information for its Loc-RIBs, and will then regenerate its 4087 Adj-RIBs-Out and its FIBs. Thus, any corrupted information that 4088 may have been present in the Adj-RIBs-Out or the FIBs will be 4089 replaced as a result. 4091 c) Upon completion of these checks, the BIS shall reset the timer to 4092 the value MaxRIBIntegrityCheck with jitter applied in accordance 4093 with 7.17.3.3. 4095 Since a given Adj-RIB-In that had been corrupted will have been 4096 purged before the Decision Process is re-executed, the defective 4097 information will not be used in the recalculation. 4099 An explicit integrity check on the contents of the Loc-RIBs, 4100 Adj-RIBs-Out, and the FIBs is not required, since corrupted 4101 information will be replaced periodically when the Decision Process 4102 is re-run. 4104 As a local option, a BIS may also choose to perform an explicit 4105 integrity check on the routeing information in its Loc-RIBs, 4106 Adj-RIBs-Out, and FIBs. If such an integrity check detects that the 4107 information base has become corrupted, then the BIS shall immediately 4108 rerun its Decision Process, and should notify System Management of 4109 "Corrupt Loc-RIB", "CorruptAdjRIBOut", or "CorruptFIB", as 4110 appropriate. 4112 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4114 7.10.3 Use of the RIB REFRESH PDU 4116 The RIB REFRESH PDU can be used by a BIS to solicit a refresh of its 4117 Adj-RIBs-In by a neighbor BIS, or to send an unsolicited refresh to a 4118 neighbor BIS: 4120 a) Solicited Refresh 4122 A BIS may request a neighbor BIS to refresh one or more of the 4123 local BIS's Adj-RIBs-In by sending a RIB-REFRESH PDU that 4124 contains the OpCode for RIB-Refresh-Request and the RIB-Atts of 4125 the Adj-RIBs-In that it wants to be refreshed. 4127 When the neighbor BIS receives a RIB-REFRESH PDU with OpCode 4128 RIB-Refresh-Request, it shall send back a RIB-REFRESH PDU with 4129 OpCode RIB-Refresh-Start, followed by a sequence of UPDATE PDUs 4130 that contain the information in its Adj-RIBs-Out associated with 4131 the requesting BIS. The neighbor BIS shall indicate the 4132 completion of the refresh by sending a RIB-REFRESH PDU with 4133 OpCode RIB-Refresh-End. 4135 b) Unsolicited Refresh 4137 A BIS may initiate an unsolicited refresh by sending a 4138 RIB-REFRESH PDU with OpCode RIB-Request-Start, followed by a 4139 sequence of UPDATE PDUs that contain the information in its 4140 Adj-RIBs-Out that been advertised to a given BIS. The completion 4141 of the refresh shall be indicated by sending the RIB-REFRESH PDU 4142 with OpCode RIB-Refresh-End. 4144 When a BIS receives a RIB REFRESH PDU with OpCode 2 (RIB Refresh 4145 Start), it shall not change any of the routeing information currently 4146 stored in the Adj-RIB-In which is identified by the distinguishing 4147 attributes of the RIB REFRESH PDU until the refresh cycle has been 4148 completed or has been aborted. 4150 The BIS shall accumulate the routeing information contained in all 4151 the UPDATE PDUs that are received in a completed refresh cycle. 4152 Completion of a refresh cycle is indicated by receipt of a RIB 4153 REFRESH PDU with OpCode 3 (RIB Refresh End). Then the BIS shall 4154 replace the previous routeing information in the associated 4155 Adj-RIB-In with the routeing information that was learned during the 4156 refresh cycle. 4158 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4160 Abortion of a refresh cycle is indicated by receipt of another RIB 4161 REFRESH PDU with OpCode 2 (RIB Refresh Start) before receipt of a RIB 4162 REFRESH PDU with OpCode 3 (RIB Refresh End). In this case, any 4163 routeing information learned in the time between receipt of the two 4164 successive RIB Refresh Starts shall be discarded, and a new refresh 4165 cycle (triggered by receipt of the second RIB Refresh Start) shall 4166 begin. 4168 If the refreshing BIS receives a new RIB-Refresh-Request while it is 4169 in the middle of refresh (after sending RIB-REFRESH PDU with OpCode 4170 RIB-Refresh-Start, but before sending RIB-REFRESH PDU with OpCode 4171 RIB-Refresh-End), then the current refresh shall be aborted and the 4172 new refresh is initiated. 4174 7.11 Path attributes 4176 An UPDATE PDU that carries an NLRI field also carries a set of path 4177 attributes. An UPDATE PDU that does not carry any NLRI field shall 4178 not carry any path attributes. Path attributes are summarized in 4179 Table 3; their encoding is described in 6.3. 4181 +-------------------------------------------------------------------+ 4182 | Table 3 (Page 1 of 2). Path Attribute Characteristics | 4183 +----------------+--------------+------+----------+-----------------+ 4184 | Attribute | Category | Type | Length | Distinguishing | 4185 | | | Code | (octets) | | 4186 +----------------+--------------+------+----------+-----------------+ 4187 | | | | | | 4188 +----------------+--------------+------+----------+-----------------+ 4189 | ROUTE_SEPARATOR| well-known | 1 | 5 | No | 4190 | | discretionary| | | | 4191 +----------------+--------------+------+----------+-----------------+ 4192 | EXT_INFO | well-known | 2 | 0 | No | 4193 | | discretionary| | | | 4194 +----------------+--------------+------+----------+-----------------+ 4195 | RD_PATH | well-known | 3 | variable | No | 4196 | | mandatory | | | | 4197 +----------------+--------------+------+----------+-----------------+ 4198 | NEXT_HOP | well-known | 4 | variable | No | 4199 | | discretionary| | | | 4200 +----------------+--------------+------+----------+-----------------+ 4201 | DIST_LIST_INCL | well-known | 5 | variable | No | 4202 | | discretionary| | | | 4203 +----------------+--------------+------+----------+-----------------+ 4204 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4206 +-------------------------------------------------------------------+ 4207 | Table 3 (Page 2 of 2). Path Attribute Characteristics | 4208 +----------------+--------------+------+----------+-----------------+ 4209 | Attribute | Category | Type | Length | Distinguishing | 4210 | | | Code | (octets) | | 4211 +----------------+--------------+------+----------+-----------------+ 4212 | DIST_LIST_EXCL | well-known | 6 | variable | No | 4213 | | discretionary| | | | 4214 +----------------+--------------+------+----------+-----------------+ 4215 | MULTI-EXIT | optional | 7 | 1 | No | 4216 | DISC | non-transitiv| | | | 4217 +----------------+--------------+------+----------+-----------------+ 4218 | TRANSIT DELAY | well-known | 8 | 2 | Yes | 4219 | | discretionary| | | | 4220 +----------------+--------------+------+----------+-----------------+ 4221 | RESIDUAL ERROR | well-known | 9 | 4 | Yes | 4222 | | discretionary| | | | 4223 +----------------+--------------+------+----------+-----------------+ 4224 | EXPENSE | well-known | 10 | 2 | Yes | 4225 | | discretionary| | | | 4226 +----------------+--------------+------+----------+-----------------+ 4227 | LOCALLY | well-known | 11 | variable | Yes | 4228 | DEFINED QOS | discretionary| | | | 4229 +----------------+--------------+------+----------+-----------------+ 4230 | HIERARCHICAL | well-known | 12 | 1 | No | 4231 | RECORDING | discretionary| | | | 4232 +----------------+--------------+------+----------+-----------------+ 4233 | RD_HOP_COUNT | well-known | 13 | 1 | No | 4234 | | mandatory | | | | 4235 +----------------+--------------+------+----------+-----------------+ 4236 | SECURITY | well-known | 14 | variable | Yes | 4237 | | discretionary| | | | 4238 +----------------+--------------+------+----------+-----------------+ 4239 | CAPACITY | well-known | 15 | 1 | No | 4240 | | mandatory | | | | 4241 +----------------+--------------+------+----------+-----------------+ 4242 | PRIORITY | well-known | 16 | 1 | Yes | 4243 | | discretionary| | | | 4244 +----------------+--------------+------+----------+-----------------+ 4245 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4247 7.11.1 Categories of path attributes 4249 Path attributes fall into four categories: 4251 a) Well-known mandatory: these attributes must be recognized upon 4252 receipt by all BISs, and must be present in every UPDATE PDU 4253 b) Well-known discretionary: these attributes must be recognized 4254 upon receipt by all BISs, but are not necessarily present in an 4255 UPDATE PDU 4256 c) Optional transitive: these attributes need not be recognized upon 4257 receipt by all BISs, and are not necessarily present in an UPDATE 4258 PDU. If a given BIS does not recognize an optional transitive 4259 attribute, it must pass it on to other BISs 4260 d) Optional non-transitive: these attributes need not be recognized 4261 upon receipt by all BISs, and are not necessarily present in an 4262 UPDATE PDU. If it does not recognize an optional non-transitive 4263 attribute, a BIS shall ignore it and shall not include it in any 4264 of its own UPDATE PDUs. 4266 A BIS shall handle optional attributes in the following manner: 4268 a) If a route with an unrecognized optional transitive attribute is 4269 received and the route is to be propagated to other BISs, the 4270 optional transitive attribute must be propagated with the route, 4271 and the Partial bit in the Flag field of the attribute shall be 4272 set to 1. 4274 b) If a route with a recognized optional transitive attribute is 4275 received and the route is to be propagated to other BISs, the 4276 optional transitive attribute may or may not be propagated with 4277 the route, according to the definition of the attribute. If the 4278 attribute is propagated, then the local BIS shall not modify the 4279 value of the PARTIAL bit in the Flag field of the attribute. 4281 c) If a route with an unrecognized optional non-transitive attribute 4282 is received, the receiving BIS shall ignore the attribute and 4283 shall not propagate that attribute to any other BIS. However, it 4284 may propagate the remainder of the route: that is, the route 4285 without the unrecognized optional non-transitive attribute. 4287 d) If a route with a recognized optional non-transitive attribute is 4288 received and the route is to be propagated to other BISs, the 4289 optional transitive attribute may or may not be propagated with 4290 the route, according to the definition of the attribute. If the 4291 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4293 attribute is propagated, then the local BIS shall not modify the 4294 value of the PARTIAL bit in the Flag field of the attribute. 4296 BISs shall observe the following rules for attaching and updating the 4297 values of optional attributes: 4299 - New optional transitive attributes may be attached to the path 4300 information by any BIS in the path, and that BIS shall then set 4301 the PARTIAL bit in the attributes flag of its UPDATE PDU to 1. 4303 - The rules for attaching new non-transitive optional attributes 4304 depend on the nature of each specific attribute. The definition 4305 of each non-transitive optional attribute specifies such rules. 4307 - Any optional attribute may be updated by any BIS in its path. 4309 7.11.2 Handling of distinguishing attributes 4311 Certain well-known discretionary path attributes are classified as 4312 Distinguishing Attributes (see 5.7), which can be used to 4313 discriminate among multiple routes to a destination, based on 4314 differences in quality between the routes. 4316 Distinguishing path attributes shall only be created by the BIS that 4317 originates the routeing information; they can be updated by any BIS 4318 that receives an UPDATE PDU that contains them. The rules for 4319 updating each of IDRP's distinguishing attributes are defined in the 4320 appropriate subclause of 7.12. 4322 A permissible set of distinguishing attributes is defined to be a set 4323 that can be derived from information that can be validly encoded in 4324 the header of an ISO 8473 NPDU, using the mappings described in 9.2. 4325 In turn, a valid RIB-Att (see 5.7) is also a permissible set of 4326 distinguishing attributes, which is used to identify the RIB that 4327 holds a route characterized by those distinguishing attributes. 4328 Therefore, a permissible set of distinguishing attributes and a 4329 corresponding valid RIB-Att: 4331 a) Can consist of an empty set (that is, the Empty Distinguishing 4332 Attribute) 4334 b) Can contain the SECURITY path attribute 4335 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4337 Note 20: This distinguishing attributes is derived from the ISO 4338 8473 Security parameter, as described in 8.2. 4340 c) Can contain at most one of the following attributes: RESIDUAL 4341 ERROR, TRANSIT DELAY, EXPENSE, and LOCALLY DEFINED QOS. 4343 Note 21: These distinguishing attributes are derived from the 4344 ISO 8473 Quality of Service Maintenance parameter, 4345 which can request only one of them (see 8.2). 4347 d) Can include the Priority Distinguishing Attribute. 4349 Note 22: This distinguished attribute is derived from the ISO 4350 8473 Priority parameter, as described in 8.2. 4352 e) Can not include any instance of equivalent distinguishing 4353 attributes, as defined in 7.11.3. 4355 Therefore, the number of distinguishing attributes that can comprise 4356 either a valid RIB-Att or a permissible set of distinguishing 4357 attributes is not unbounded: it is limited to at most three. 4359 7.11.3 Equivalent distinguishing attributes 4361 IDRP recognizes two categories of distinguishing attribute: type 4362 specific, and type-value specific. Certain Distinguishing Attributes 4363 are unambiguous by their type --namely, Capacity, Priority, Transit 4364 Delay, Expense, and Residual Error. These are called type specific. 4366 Others can not be disambiguated based solely on their type, but 4367 require knowledge of both type and a subset of the fields that 4368 comprise their value--namely, SECURITY and LOCALLY DEFINED QOS. 4369 These are called type-value specific. 4371 Within IDRP, two instances of Distinguishing Attributes are 4372 equivalent each other if either: 4374 a) they are both type specific and they both have the same type, or 4376 b) they are both type-value specific, and they both have the same 4377 type and the same value. 4379 In all other cases two instances of Distinguishing Attribute are not 4380 equivalent. 4382 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4384 7.12 Path attribute usage 4386 The usage of each of IDRP's path attributes is described in the 4387 following clauses. 4389 7.12.1 ROUTE_SEPARATOR 4391 ROUTE-SEPARATOR is a well-known mandatory attribute. Multiple 4392 instances of this attribute may appear in a single UPDATE PDU. The 4393 ROUTE_SEPARATOR serves as a delimiter between sets of distinguishing 4394 attributes. Each set of distinguishing attributes determines the 4395 routeing information base associated with the route. The ROUTE_ID 4396 and LOCAL_PREF values for a given route are contained in the 4397 ROUTE_SEPARATOR that immediately precedes the set of distinguishing 4398 attributes for that route. A BIS shall include a ROUTE_SEPARATOR for 4399 each feasible route carried in the UPDATE PDU: 4401 - The ROUTE-ID must be unambiguous within the context of the 4402 BIS-BIS connection over which the UPDATE PDU is transmitted. 4403 - The LOCAL-PREF field is used to detect inconsistent routeing 4404 decisions among a set of BISs that are all located in the same 4405 routeing domain. Its value shall be set as follows: 4407 a) For UPDATE PDUs sent to adjacent routeing domains, LOCAL-PREF 4408 shall contain the value 0; the receiving BIS (in the adjacent 4409 RD) shall ignore this field upon receipt. 4411 b) For UPDATE PDUS sent to BISs in the same routeing domain as 4412 the local BIS, its value shall be set in accordance with 4413 7.15.1; the receiving BIS (in the same RD) shall use this 4414 value to check for internal inconsistencies, in accordance 4415 with 7.15.1. 4417 All distinguishing attributes that appear after a given 4418 ROUTE_SEPARATOR and before the next ROUTE_SEPARATOR or the end of the 4419 BISPDU (whichever occurs first) form a set that determines the 4420 RIB-Att associated with the route. 4422 All non-distinguishing path attributes and the NLRI field apply to 4423 every route advertised in the UPDATE PDU, regardless of where they 4424 appear with respect to the ROUTE_SEPARATOR(s). 4426 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4428 The ROUTE_ID associated with a route received from an adjacent BIS 4429 bear no functional relationship to the ROUTE_ID that the local BIS 4430 will generate if it decides to propagate that route. Similarly, the 4431 ROUTE-ID for an aggregated route bears no functional relationship the 4432 individual ROUTE-IDs of the routes from which it was constructed. 4434 Note 23: The requirements on unambiguity within the context of a 4435 given BIS-BIS connection lead to the following 4436 observations: 4438 a) Since the ROUTE-ID must be unambiguous within each 4439 instance of BIS-BIS communication, a BIS can advertise 4440 the same route to different neighbor BISs, using 4441 different ROUTE-IDs in each instance of BIS-BIS 4442 communications. 4444 b) The ROUTE-IDs associated with routes to be advertised 4445 by a BIS (that is, the routes in its Adj-RIBs-Out) 4446 bears no relationship to the ROUTE-IDs associated with 4447 routes received from other BISs (that is, the routes in 4448 the local BIS's Adj-RIBs-In). 4450 7.12.2 EXT_INFO 4452 EXT_INFO is a well-known discretionary attribute. It shall be 4453 recognized upon receipt by all BISs. It shall be included in each 4454 UPDATE PDU that reports either an RD_PATH attribute or Network Layer 4455 Reachability Information that has been learned by methods not 4456 described in this International Standard. 4458 The EXT_INFO attribute shall be generated by the RD that originates 4459 the associated routeing information. If the EXT_INFO attribute was 4460 present in a received UPDATE PDU, then it shall also be included in 4461 the UPDATE PDUs of all BISs that choose to propagate this information 4462 to other BISs. 4464 Note 24: Information obtained from the managed object 4465 internalSystems or obtained from UPDATE PDUs which do not 4466 contain the EXT_INFO attribute has been learned by methods 4467 within IDRP's scope; however, manually configured 4468 reachability information for an RD which does not run IDRP 4469 is an example of information which is learned by means 4470 outside IDRP's scope. 4472 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4474 If a BIS selects a route which has been advertised with the 4475 EXT_INFO attribute, it is possible that there may be 4476 undetected looping of routeing information. Therefore, it 4477 is recommended that distribution of information not learned 4478 by the methods of IDRP be tightly controlled. The path 4479 attributes DIST_LIST_INCL and DIST_LIST_EXCL afford a 4480 convenient method for providing this control. Furthermore, 4481 a given RD may also enforce policies which prohibit any of 4482 its BISs from selecting routes which have the EXT_INFO 4483 attribute associated with them. 4485 7.12.3 RD_PATH 4487 RD_PATH is a well-known mandatory attribute. It shall be present in 4488 every UPDATE PDU, and shall be recognized on receipt by all BISs. 4489 This attribute consists of a concatenation of path segments that 4490 identifies the routeing domains and routeing domain confederations 4491 through which this route has passed. The path segments can be 4492 RD_SETs, RD_SEQs, ENTRY_SEQs, or ENTRY_SETs. 4494 7.12.3.1 Generating an RD_PATH attribute 4496 When a BIS originates a route to destinations contained within its 4497 own routeing domain or to destinations learned by means outside the 4498 protocol (see 7.12.2), it shall examine the information contained in 4499 its managed object rdcConfig to determine the ordering relationships 4500 among all the confederations of which the local routeing domain is a 4501 member. The local BIS shall then construct an RD_PATH attribute as 4502 follows: 4504 a) If the local routeing domain is a member of one or more 4505 confederations, the RD_PATH shall consist of an ENTRY_SEQ segment 4506 followed immediately by an RD_SEQ segment. The ENTRY_SEQ shall 4507 list the confederations, ordered as follows: 4509 1) If a confederation, RDC-B, is nested within another 4510 confederation, RDC-A, then the RDI of RDC-A shall precede 4511 that of RDC-B. 4513 2) The RDIs of overlapping confederations shall be listed in 4514 increasing order of the RDIs, as long as the order implied by 4515 any nesting relationships is maintained. For purposes of 4516 ordering, two RDIs are compared octet-by-octet from the left 4517 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4519 until differing octet values are found. The RDI with the 4520 lesser octet value (when treated as an unsigned integer) is 4521 considered to have the lesser RDI value. If there are two 4522 RDIs of different lengths, and the leading octets of the 4523 longer RDI are exactly the same as the octets of the 4524 (complete) shorter RDI, then the shorter RDI is considered to 4525 have the lesser value. 4527 The RD_SEQ shall list the RDI of the BIS's routeing domain. 4529 b) If the local routeing domain is not a member of any 4530 confederation, then the RD_PATH contains a single RD_SEQ segment 4531 that lists the RDI of the BIS's routeing domain. 4533 7.12.3.2 Updating a received RD_PATH attribute 4535 The local BIS shall update the RD_PATH attribute of a route received 4536 from another BIS according to the following rules: 4538 a) If the route was received from a BIS located in the same routeing 4539 domain as the local BIS, then the RD_PATH attribute shall not be 4540 updated. 4542 b) If the route was received from a BIS located in an adjacent 4543 routeing domain, the local BIS shall determine if the route has 4544 entered any confederations (see 7.13.3), and it shall examine the 4545 information contained in its managed object rdcConfig to 4546 determine the ordering relationships among all such 4547 confederations. The local BIS shall then amend the RD_PATH 4548 attribute as follows: 4550 1) If the route has entered any confederations, the BIS shall 4551 append a path segment of type ENTRY_SEQ that lists all the 4552 newly entered confederations, ordered as follows: 4554 i) If a confederation, RDC-B, is nested within another 4555 confederation, RDC-A, then the RDI of RDC-A shall precede 4556 that of RDC-B. 4558 ii) The RDIs of overlapping confederations shall be listed in 4559 increasing order of the RDIs, as long as the order 4560 implied by any nesting relationships is maintained. For 4561 purposes of ordering, two RDIs are compared 4562 octet-by-octet from the left until differing octet values 4563 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4565 are found. The RDI with the lesser octet value (when 4566 treated as an unsigned integer) is considered to have the 4567 lesser RDI value. If there are two RDIs of different 4568 lengths, and the leading octets of the longer RDI are 4569 exactly the same as the octets of the (complete) shorter 4570 RDI, then the shorter RDI is considered to have the 4571 lesser value. 4573 The ENTRY_SEQ segment shall be followed immediately by an 4574 RD_SEQ segment that lists the RDI of the BIS's routeing 4575 domain. 4577 2) If the route has not entered any confederations, the local 4578 BIS shall append a path segment of type RD_SEQ that lists the 4579 RDI of the BIS's routeing domain. 4581 7.12.3.3 Advertising a route received from another BIS 4583 After receiving a route, a BIS will have modified its RD_PATH 4584 attribute in accordance with 7.12.3.2; and when a route is generated 4585 locally, the BIS will have created an RD_PATH attribute in accordance 4586 with 7.12.3.1. If the local BIS selects a route for subsequent 4587 advertisement, the RD_PATH attribute of that route shall be amended 4588 as follows, based on the confederations which have been exited and on 4589 the nesting relationships among confederations of which the local BIS 4590 is a member (see managed object rdcConfig): 4592 a) If the adjacent BIS to which the route will be advertised can be 4593 reached without exiting any confederations, then no modification 4594 to the RD_PATH attribute shall be made. 4596 b) If the adjacent BIS to which the route will be advertised can 4597 only be reached by exiting one or more confederations, then the 4598 local BIS shall check the RD_PATH attribute for the presence of 4599 ENTRY_SEQ or ENTRY_SET path segments that contain the RDIs of the 4600 exited confederations. 4602 If there is any RDI of an exited confederation which is absent 4603 from all ENTRY_SEQ and ENTRY_SET segments, then the route is in 4604 error. The local BIS shall send an IDRP ERROR PDU to the BIS 4605 that advertised the route, reporting a Misconfigured_RDCs error. 4607 If two confederation, RDC-A and RDC-B, are listed in the same 4608 ENTRY_SEQ, and managed object rdcConfig indicates that RDC-B is 4609 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4611 nested within RDC-A, then the RDI of RDC-A shall precede that of 4612 RDC-B in the ENTRY_SEQ. If it does not, the local BIS shall send 4613 an IDRP ERROR to the BIS that advertised the route, reporting a 4614 Misconfigured_RDCs error. 4616 Otherwise, the local BIS shall scan the RD_PATH attribute from 4617 the back (right to left, starting at the highest numbered octet) 4618 looking for an ENTRY_SEQ or ENTRY_SET path segment that lists an 4619 exited confederation. Within a given ENTRY_SET or ENTRY_SEQ 4620 segment, the RDI for a given confederation can not be processed 4621 until the RDIs for all confederations nested within it have been 4622 processed. 4624 For each exited confederation (for example, the confederation 4625 whose RDI is "X"), the advertising BIS shall then update the 4626 RD_PATH of the route as follows: 4628 1) The entry for "X" shall be removed from the ENTRY_SEQ or 4629 ENTRY_SET segment 4631 2) If "X" is the only RDI contained in an ENTRY_SEQ or ENTRY_SET 4632 segment of the RD_PATH, then create a path segment of type 4633 RD_SEQ that lists "X" and insert it in front of the previous 4634 entry for "X". 4636 3) If the local BIS's routeing domain is a member of other 4637 confederations besides "X" that are listed in the ENTRY_SEQ 4638 or ENTRY_SET segments of the RD_PATH, then: 4640 i) If "X" occurs in an ENTRY_SEQ or ENTRY_SET segment, and 4641 "X" is nested within none of the other confederations, 4642 then create an RD_SET that lists "X" and insert it in 4643 front of the first ENTRY_SEQ or ENTRY_SET segment that 4644 occurs in the RD_PATH. 4646 ii) If "X" occurs in an ENTRY_SEQ and "X" is nested within 4647 all the other confederations, then create a path segment 4648 of type RD_SEQ that lists "X" and insert it immediately 4649 in front of the previous entry for "X" 4651 iii) If "X" occurs in an ENTRY_SEQ and "X" is nested within 4652 some but not all of the other confederations, then create 4653 a path segment of type RD_SET that lists "X", and insert 4654 it immediately after the closest prior entry for any 4655 confederation in which "X" is nested. 4657 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4659 iv) If "X" occurs in an ENTRY_SET and "X" is nested within 4660 all the other confederations, then create a path segment 4661 of type RD_SET that lists "X" and insert it immediately 4662 in front of the previous entry for "X" 4664 v) If "X" occurs in an ENTRY_SET and "X" is nested within 4665 some but not all of the other confederations, then create 4666 a path segment of type RD_SET that lists "X", and insert 4667 it immediately after the the closest prior entry for any 4668 confederation in which "X" is nested. 4670 If the procedures call for the insertion of an RD_SET or an 4671 RD_SEQ between entries that are contained in a single 4672 ENTRY_SET or ENTRY_SEQ, then break the ENTRY_SET or ENTRY_SEQ 4673 into two segments of identical type and perform the 4674 insertion. For example, if it is necessary to insert 4675 RD_SET(X) between entries for "A" and "B", where "A" and "B" 4676 are contained in ENTRY_SEQ(H,J,A,B,C), the result would be: 4677 ENTRY_SEQ(H,J,A) RD_SET(X) ENTRY_SEQ(B,C). 4679 If, after applying these procedures, the ENTRY_SEQ or ENTRY_SET 4680 segment in which "X" originally occurred is empty, then that path 4681 segment shall be deleted, together with any subsequent path 4682 segments between itself and the next occurring ENTRY_SEQ or 4683 ENTRY_SET segment, or between itself and the end of the RD_PATH 4684 attribute if there is no subsequent ENTRY_SEQ or ENTRY_SET 4685 segment. 4687 7.12.4 NEXT_HOP 4689 NEXT_HOP is a well-known discretionary attribute. It shall be 4690 recognized upon receipt by all BISs. 4692 For purposes of defining the usage rules for this attribute, a 4693 subnetwork is transitive with respect to system reachability if all 4694 of the following conditions are true: 4696 a) Systems A, B, and C are all attached to the same subnetwork, 4698 b) When A can reach B directly, and B can reach C directly, it 4699 follows that A can reach C directly. 4701 Verification of the above conditions should be accomplished by means 4702 outside of IDRP. For example, systems located on a common subnetwork 4703 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4705 +----------------------------------------------------------------------+ 4706 | | 4707 | +-----+ | 4708 | | B | | 4709 | +-----+ | 4710 | = | = | 4711 | BIS-BIS = | = BIS-BIS | 4712 | Connection = | = Connection | 4713 | = | = | 4714 | = | = | 4715 | = | = | 4716 | = | = | 4717 | +---+ | +---+ | 4718 | | A |--------+--------| C | | 4719 | +---+ +---+ | 4720 | | 4721 | | 4722 +----------------------------------------------------------------------+ 4723 Figure 8. A Transitive Fully Connected Subnetwork 4725 could use an ES-IS protocol (such as ISO 9542) to ascertain if there 4726 is direct reachability between them. Examples of such media are IEEE 4727 802.2 and SMDS. 4729 Consider three BISs attached to a fully connected transitive 4730 subnetwork, as shown in Figure 8: A and B share a BIS-BIS connection, 4731 B and C share a BIS-BIS connection, but A and C have no BIS-BIS 4732 connection between themselves. If C propagates an UPDATE PDU to B, 4733 then with respect to the UPDATE PDU advertised by B: 4735 - C is defined to be the source BIS 4736 - B is defined to be the first recipient BIS 4737 - A is defined to be the subsequent recipient BIS. 4739 In terms of these definitions, the following rules apply to the usage 4740 of the NEXT_HOP attribute: 4742 a) Generating the Attribute 4744 When a given BIS generates an UPDATE PDU: 4746 1) It may list its own NET and the SNPAs of subnetworks that 4747 connect itself to the remote BIS in the NEXT_HOP attribute of 4748 that UPDATE PDU. 4750 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4752 2) It may choose not to include a NEXT_HOP attribute in its 4753 UPDATE PDU. When the NEXT_HOP field is not present, it 4754 implies that the NET of the BIS that advertises the UPDATE 4755 PDU should be considered to be the NET of the next-hop BIS. 4757 3) It may set the value of the "IDRP_Server_Allowed" field in 4758 accordance with its local policies: 4760 - If the source BIS wants to allow the first recipient BIS 4761 to advertise the source BIS's NET and SNPA to a 4762 subsequent recipient BIS, then it shall set this field to 4763 X'FF' 4765 - If the source BIS does not want the first recipient BIS 4766 to advertise the source BIS's NET and SNPA, then it shall 4767 set this field to any value other than X'FF'. 4769 b) Advertising Routeing Information 4771 When a BIS chooses to advertise routeing information learned from 4772 an UPDATE PDU: 4774 1) The BIS may choose to list its own NET and the SNPAs of 4775 subnetworks that connect itself to the remote BIS in the 4776 NEXT_HOP attribute of an UPDATE PDU that propagates the 4777 routeing information 4779 2) The BIS may choose not to include a NEXT_HOP attribute in its 4780 UPDATE PDU. When the NEXT_HOP field is not present, it 4781 implies that the BIS that advertises the UPDATE PDU is also 4782 the next-hop BIS. 4784 3) If any condition listed below is not satisfied, then the 4785 recipient BIS shall not list the NET and SNPAs of the source 4786 BIS in its own UPDATE PDUs. If they are all satisfied, then 4787 instead of listing its own NET and SNPAs, the BIS may 4788 optionally list the NET and SNPAs of the source BIS (as 4789 contained in the UPDATE PDU received from the source BIS) 4790 when it propagates the information to a subsequent recipient 4791 BIS. The conditions are the following: 4793 i) The "IDRP_Server_Allowed" field of the UPDATE PDU of the 4794 source BIS was equal to X'FF'. 4796 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4798 ii) All three BISs (source, first recipient, and subsequent 4799 recipient) are located on a common subnetwork which is 4800 full-duplex and is transitive with respect to 4801 reachability of all three BISs. 4803 iii) The managed object routeServer is "true". 4805 iv) The first recipient and subsequent recipient are located 4806 in different routeing domains. 4808 v) Advertisement of this route to the subsequent recipient 4809 BIS does not conflict with any of the path attributes 4810 that were contained in the UPDATE PDU from the source 4811 BIS. (For example, it may not propagate the UPDATE PDU 4812 to a recipient that is listed in the DIST_LIST_EXCL 4813 attribute.) 4815 Note 25: The following observations should be noted with regard to 4816 the rules stated above: 4818 a) The rules do not remove the requirement that there must 4819 be a BIS-BIS connections between each pair of BISs 4820 located in the same routeing domain. 4822 b) The contents of the NEXT_HOP attribute have no effect 4823 upon the contents of the RD_PATH attribute: that is, 4824 the RD_PATH attribute will always be used in accordance 4825 with 7.12.3. 4827 c) If the NET and SNPAs are not available in an UPDATE 4828 PDU, then a BIS that receives it must learn them by 4829 means outside of this International Standard. For 4830 example, the value of the NET can be learned from the 4831 NUNITDATA.INDICATION, and IS 9542 can be used to 4832 associate an SNPA with that NET. 4834 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4836 7.12.5 DIST_LIST_INCL 4838 DIST_LIST_INCL is a well-known discretionary attribute. It shall be 4839 recognized upon receipt by all BISs. When present, this attribute 4840 lists the RDIs of the routeing domains and confederations to which 4841 the routeing information may be distributed. Since NPDUs usually 4842 flow in a direction opposite to the flow of UPDATE PDUs, 4843 DIST_LIST_INCL provides a means for a given RD or confederation to 4844 control use of its resources by other RDs. 4846 When a BIS receives an UPDATE PDU that contains the DIST_LIST_INCL 4847 attribute, then the receiving BIS shall not redistribute the 4848 associated routeing information to any BIS which is not a member of 4849 at least one RD or RDC whose RDI is contained in this attribute. 4851 A BIS shall redistribute only that information which has been locally 4852 selected as a route, and shall redistribute it only to RDs or RDCs 4853 which are both adjacent to it and are included in the distribution 4854 list. A BIS may distribute the information to any adjacent BIS that 4855 is a member of any routeing domain or confederation whose RDI is 4856 contained in DIST_LIST_INCL. A BIS is not required to distribute the 4857 routeing information to every RD or RDC whose RDI is listed: for 4858 example, it is possible for local policy considerations or the 4859 contents of the HIERARCHICAL_RECORDING path attribute to further 4860 restrict the set of RDIs to whom the routeing information will 4861 actually be redistributed. 4863 If a BIS receives an UPDATE PDU that contains neither the 4864 DIST_LIST_INCL nor DIST_LIST_EXCL attributes, then it may distribute 4865 the routeing information to all adjacent BISs. Alternatively, the 4866 local BIS may also add a DIST_LIST_INCL or DIST_LIST_EXCL attribute, 4867 but not both, to the route information. 4869 If the DIST_LIST_INCL attribute is present and has a length of zero 4870 octets, then the routeing information may be used locally, but shall 4871 not be advertised to any other BIS. 4873 When it originates an UPDATE PDU which describes a route to 4874 destinations located in its own routeing domain, a BIS may append the 4875 DIST_LIST_INCL attribute, in accordance with its local policies. 4877 If a BIS chooses to advertise a route which was learned from an 4878 UPDATE PDU which already contained the DIST_LIST_INCL attribute, the 4879 advertising BIS may modify this attribute by pruning the set of RDIs 4880 included in the list. If a BIS chooses to prune the set, it shall 4881 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4883 not delete the RDI of its own RD, nor shall it delete the RDI of any 4884 RDC to which it belongs. However, if the reduced list is empty (that 4885 is, has a length of zero), then the BIS shall not advertise the 4886 routeing information to any BIS located in a different routeing 4887 domain. 4889 7.12.5.1 Interaction with HIERARCHICAL_RECORDING 4891 When a given UPDATE PDU contains both the HIERARCHICAL_RECORDING 4892 attribute and the DIST_LIST_INCL attribute, the constraints imposed 4893 by the HIERARCHICAL_RECORDING, as specified in 7.12.12, shall take 4894 precedence over those imposed by DIST_LIST_INCL. 4896 7.12.6 DIST_LIST_EXCL 4898 DIST_LIST_EXCL is a well-known discretionary attribute. It shall be 4899 recognized upon receipt by all BISs. When present, this attribute 4900 lists the RDIs of routeing domains and confederations to which the 4901 routeing information may not be distributed. Since NPDUs usually 4902 flow in a direction opposite to the flow of UPDATE PDUs, 4903 DIST_LIST_EXCL provides a means for a given RD or confederation to 4904 control use of its resources by other RDs and RDCs. 4906 When a BIS receives an UPDATE PDU that contains the DIST_LIST_EXCL 4907 attribute, then the receiving BIS shall not redistribute the 4908 associated routeing information to any BIS located in an RD or RDC 4909 whose RDI is included in the list. A BIS shall not distribute the 4910 information to any adjacent BIS that is a member of any routeing 4911 domain or confederation whose RDI is contained in DIST_LIST_EXCL. 4912 Local policy considerations shall not override redistribution of the 4913 routeing information as dictated by the DIST_LIST_EXCL attribute. 4915 If a BIS receives an UPDATE PDU that contains neither the 4916 DIST_LIST_INCL nor the DIST_LIST_EXCL attributes associated with it, 4917 then it may distribute the routeing information to all adjacent BISs. 4918 Alternatively, the local BIS may also add a DIST_LIST_INCL or 4919 DIST_LIST_EXCL attribute, but not both, to the route information. 4921 If the DIST_LIST_EXCL attribute is absent and the DIST_LIST_INCL 4922 attribute is present, then the distribution of the routeing 4923 information is controlled by the DIST_LIST_INCL attribute. If the 4924 DIST_LIST_EXCL attribute is present and has a length of zero octets, 4925 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4927 then the routeing information may, in accordance with local policy, 4928 be advertised to any other BIS. 4930 When it originates an UPDATE PDU which describes a route to 4931 destinations located in its own routeing domain, a BIS may append the 4932 DIST_LIST_EXCL attribute, in accordance with its local policies. 4934 If a BIS chooses to advertise a route which was learned from an 4935 UPDATE PDU which already contained the DIST_LIST_EXCL attribute, the 4936 advertising BIS may modify this attribute by augmenting the set of 4937 RDIs included in the list. If a BIS chooses to augment the set, it 4938 shall not add the RDI of its own RD, nor shall it add the RDI of any 4939 RDC to which it belongs. 4941 7.12.6.1 Interaction with HIERARCHICAL RECORDING 4943 When a given UPDATE PDU contains both the HIERARCHICAL_RECORDING 4944 attribute and the DIST_LIST_EXCL attribute, the constraints imposed 4945 by DIST_LIST_EXCL, as specified in 7.12.6, shall take precedence over 4946 those imposed by the HIERARCHICAL_RECORDING attribute. 4948 7.12.7 MULTI-EXIT_DISC 4950 MULTI-EXIT_DISC is an optional non-transitive attribute. If the 4951 local BIS's managed object multiExit is "true", the BIS may use the 4952 attribute in its path selection algorithm. For example, a routeing 4953 domain may choose to implement a policy which mandates that if all 4954 other path attributes are equal, the exit point with the lowest value 4955 of MULTI-EXIT_DISC should be preferred. 4957 Each BIS that is connected to an adjacent RD by one or more common 4958 subnetworks may generate a MULTI-EXIT_DISC attribute for each link 4959 connecting itself to an adjacent RD. The value of this attribute is 4960 a local matter, which will be determined by the policies of the RD in 4961 which the originating BIS is located. 4963 A BIS that generates a value for this attribute may distribute it to 4964 all neighboring BISs which are located in adjacent RDs. 4966 If a MULTI-EXIT_DISC attribute is received from a BIS located in an 4967 adjacent RD, then the receiving BIS may distribute this attribute to 4968 all other BISs located in its own RD. However, the receiving BIS 4969 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 4971 shall not re-distribute the attribute to any BISs which are not 4972 located within its own RD. 4974 7.12.8 TRANSIT DELAY 4976 TRANSIT DELAY is a well-known discretionary attribute. A BIS shall 4977 include this attribute in its UPDATE PDU to indicate that it supports 4978 routeing based on the Transit Delay attribute, and that it maintains 4979 Adj-RIBs and a Loc-RIB distinguished by this attribute. 4981 The average transit delay associated with the local RD is obtained 4982 from the managed object rdTransitDelay and represents an average 4983 transit delay that would be experienced by SNSDU size of 512 octets 4984 while traversing the RD. rdTransitDelay is specified in units of 2 4985 ms. 4987 If A BIS advertises a route whose destinations are located in its own 4988 RD, then the originating BIS may append the Transit Delay attribute 4989 to the route, using the value contained in managed object 4990 rdTransitDelay. 4992 When a BIS re-distributes a route which has been learned in an UPDATE 4993 PDU that contains the Transit Delay attribute, it shall update the 4994 value of this attribute before advertising the route to a BIS located 4995 in another routeing domain. The updated value shall be computed by 4996 adding the value in rdTransitDelay to the value of the parameter that 4997 was received in the UPDATE PDU's Transit Delay attribute. 4999 If the route is re-distributed to another BIS located in the same RD 5000 as the advertising BIS, then the Transit Delay attribute shall not be 5001 modified, but shall be distributed with the same value that was 5002 present in the received UPDATE PDU. 5004 7.12.9 RESIDUAL ERROR 5006 RESIDUAL ERROR is a well-known discretionary attribute. A BIS shall 5007 include this attribute in its UPDATE PDU to indicate that it supports 5008 routeing based on the Residual Error attribute, and that it maintains 5009 Adj-RIBs and a Loc-RIB distinguished by this attribute. 5011 The value contained in the RESIDUAL ERROR attribute, in RRE, and in 5012 managed object rdLRE is a positive integer in the range from 0 to 5013 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5015 <2^32> -1; the actual probability of error can be obtained by 5016 dividing the value by <2^32> -1. 5018 If A BIS advertises a route whose destinations are located in its own 5019 RD, then the originating BIS may append the RESIDUAL ERROR attribute 5020 to the route, using the value contained in managed object rdLRE. The 5021 value of the rdLRE is an integer value derived from the average ratio 5022 of lost, duplicated, or incorrectly delivered SNSDU's to total SNSDUs 5023 transmitted by the SNDCF during a measurement period: this ratio is 5024 multiplied by <2^32> -1, and then rounded up to the next higher 5025 integer. 5027 When a BIS re-distributes a route which has been learned in an UPDATE 5028 PDU that contains the RESIDUAL ERROR attribute, it shall update the 5029 value of this attribute before advertising the route to a BIS located 5030 in another routeing domain. The updated value is computed by the 5031 following formula: 5033 K * (1 - ((1-(RRE/K))*(1-(RDLRE/K)))) 5035 where RRE is the value of the RESIDUAL ERROR attribute of the 5036 received route, RDLRE is the value of the average residual error 5037 probability associated with the local RD, K is the constant <2^32> 5038 -1, and the whole expression is rounded up to the nearest integer. 5040 If the route is re-distributed to another BIS located in the same RD 5041 as the advertising BIS, then the RESIDUAL ERROR attribute shall not 5042 be modified, but shall be distributed with the same value that was 5043 present in the received UPDATE PDU. 5045 7.12.10 EXPENSE 5047 EXPENSE is a well-known discretionary attribute. A BIS shall include 5048 this attribute in its UPDATE PDU to indicate that it supports 5049 routeing based on the Expense attribute, and that it maintains 5050 Adj-RIBs and a Loc-RIB distinguished by this attribute. The value of 5051 Expense associated with a given routeing domain is contained in 5052 managed object locExpense. It is related to monetary cost. 5053 Different routeing domains may use different values for this 5054 attribute: thus, the attribute must deal in relative monetary costs. 5056 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5058 If A BIS advertises a route whose destinations are located in its own 5059 RD, then the originating BIS may append the Expense attribute to the 5060 route, using the value contained in managed object locExpense. 5062 When a BIS re-distributes a route which has been learned in an UPDATE 5063 PDU that contains the Expense attribute, it shall update the value of 5064 this attribute before advertising the route to a BIS located in 5065 another routeing domain. The updated value is computed by adding the 5066 value of the expense contained in managed object locExpense to the 5067 value of the EXPENSE attribute of the received route. 5069 If the route is re-distributed to another BIS located in the same RD 5070 as the advertising BIS, then the Expense attribute shall not be 5071 modified, but shall be distributed with the same value that was 5072 present in the received UPDATE PDU. 5074 7.12.11 LOCALLY DEFINED QOS 5076 LOCALLY DEFINED QOS is a well known discretionary attribute that 5077 enables a QoS Authority to specify a QoS measurement that is not 5078 included in the set of QoS measurements specified in this 5079 International Standard. The QoS Measurement is identified within the 5080 context of the QoS Authority, which is also responsible for 5081 specifying its name (QoS Value) and its semantics. A QoS Authority 5082 may specify as many QoS measurements as necessary, each distinguished 5083 by the QoS Value field. 5085 When a BIS supports a LOCALLY DEFINED QOS measurement, this may be 5086 signalled to adjacent BISs in a RIB-Att as specified in 6.2. When 5087 support of a LOCALLY DEFINED QOS measurement is indicated in a 5088 RIB-Att, then the BIS shall support the Adj-RIBs-In, Adj-RIBs-Out, 5089 and a Loc-RIB and a FIB corresponding to this RIB-Att. A BIS may only 5090 include a LOCALLY DEFINED QOS measurement in a RIB-Att when its PIB 5091 contains the rules necessary to support this measurement. 5093 When a BIS re-distributes a route which has been learned in an UPDATE 5094 PDU that contains a LOCALLY DEFINED QOS path attributes, then the new 5095 UPDATE PDU shall contain the same QoS Value and NSAP Address Prefix 5096 fields in the LOCALLY DEFINED QOS path attribute, and the metric 5097 fields (if present) shall be modified in the following way: 5099 a) when the route is advertised to a BIS located in the same RD as 5100 the advertising BIS, the metric value shall not be modified 5101 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5103 b) when the route is advertised to a BIS located in a different RD 5104 from the advertising BIS, the metric value shall be modified 5105 according to the rules for that metric. Rules for modifying a 5106 given metric value field are defined by the authority responsible 5107 for assigning the addresses contained in the "address" field of 5108 this attribute; such rules shall be specified in the PIB. 5110 7.12.12 HIERARCHICAL RECORDING 5112 The HIERARCHICAL_RECORDING attribute provides an optional means for 5113 members of a routeing domain confederation to control transitivity. 5114 The transitivity constraints are based upon two factors: 5116 a) the value of the HIERARCHICAL ATTRIBUTE that was contained in a 5117 received UPDATE PDU 5119 b) knowledge of whether it is necessary to enter or exit a 5120 confederation in order to reach an adjacent RD. 5122 If an RD wishes to support this attribute, then it shall obey the 5123 following usage rules: 5125 a) Destination BIS in a Disjoint RDC: 5127 The HIERARCHICAL_RECORDING attribute shall not be included in an 5128 UPDATE PDU that is transmitted to a BIS that can be reached only 5129 by exiting all of the confederations in which the advertising BIS 5130 resides. 5132 b) Destination BIS in Same, Nested, or Overlapping RDC: 5134 1) If a given BIS chooses to advertise routeing information that 5135 it learned from an inbound UPDATE PDU whose 5136 HIERARCHICAL_RECORDING attribute was equal to 1, or if it is 5137 the originator of the routeing information, it may advertise 5138 this information to BISs located in any adjacent routeing 5139 domain, as follows: 5141 i) If it is necessary to enter a confederation in order to 5142 reach the destination BIS, then the advertising BIS shall 5143 include the HIERARCHICAL RECORDING attribute in its 5144 outbound UPDATE PDU, and shall set its value to 0. 5146 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5148 ii) If the destination BIS can be reached without entering 5149 any confederation, then the advertising BIS shall include 5150 the HIERARCHICAL RECORDING attribute in its outbound 5151 UPDATE PDU, and shall set its value to 1. 5153 2) If a given BIS chooses to advertise routeing information that 5154 it learned from an inbound UPDATE PDU whose 5155 HIERARCHICAL_RECORDING attribute was equal to 0, it may 5156 advertise that information only to BISs that can be reached 5157 without exiting any confederation to which the advertising 5158 BIS belongs. The HIERARCHICAL_RECORDING attribute shall be 5159 included in the outbound UPDATE PDU, and its value shall be 5160 set to 0. 5162 7.12.12.1 Interaction with DIST_LIST_INCL and DIST_LIST_EXCL 5164 When a given UPDATE PDU contains both the HIERARCHICAL_RECORDING 5165 attribute and the DIST_LIST_EXCL attribute, the constraints imposed 5166 by DIST_LIST_EXCL, as specified in 7.12.6, shall take precedence over 5167 those imposed by the HIERARCHICAL_RECORDING attribute. 5169 When a given UPDATE PDU contains both the HIERARCHICAL_RECORDING 5170 attribute and the DIST_LIST_INCL attribute, the constraints imposed 5171 by the HIERARCHICAL_RECORDING, as specified in 7.12.12, shall take 5172 precedence over those imposed by DIST_LIST_INCL. 5174 7.12.13 RD_HOP_COUNT 5176 This is a well-known mandatory attribute whose usage is as follows: 5178 a) The initial value of this attribute is 0. 5180 b) Before sending an UPDATE PDU to a BIS located in an adjacent 5181 routeing domain, a BIS shall increment the value of this 5182 attribute by 1, and shall place the result in the RD_HOP_COUNT 5183 field of the outbound UPDATE PDU. 5185 c) A BIS shall not increment the value of this attribute when it 5186 sends an UPDATE PDU to another BIS located in its own routeing 5187 domain. 5189 Note 26: ISO 8473 limits the maximum lifetime of an NPDU to 256 5190 counts, and requires each Network entity processing a given 5191 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5193 NPDU to decrement that NPDU's lifetime by at least 1 count. 5194 In the limiting case of one BIS per routeing domain, this 5195 implies that a NPDU's lifetime will expire before it can 5196 reach the 257th RD. Hence, there is no need to provide an 5197 RD_HOP_COUNT greater than 256. 5199 7.12.14 SECURITY 5201 SECURITY is a well known discretionary attribute that enables a 5202 Security Authority to specify security related information concerning 5203 a route. The security related information is identified within the 5204 context of the Security Authority, which is also responsible for 5205 specifying its semantics. Only one security attribute may be included 5206 in each route. 5208 When a BIS is able to interpret and act on security related 5209 information specified by a given Security Authority, this may be 5210 signalled to adjacent BISs in a RIB-Att as specified in 6.2. When 5211 support of the SECURITY attribute is indicated in a RIB-Att, then the 5212 BIS shall support the Adj-RIBs-In, Adj-RIBs-out, a Loc-RIB and a FIB 5213 corresponding to this RIB-Att. A BIS may only include a SECURITY 5214 distinguishing attribute in a RIB-Att when its PIB contains the rules 5215 necessary to interpret and act on the security related information 5216 for the identified Security Authority. 5218 When a BIS re-distributes a route which has been learned in an UPDATE 5219 PDU that contains a SECURITY distinguishing attribute, then the new 5220 UPDATE PDU shall contain the same Security Authority identification 5221 fields, and the security related information shall be modified 5222 according to the rules specified in the PIB. Any such modification 5223 may only reduce the protection level indicated, or add additional 5224 restrictions on access to the route. 5226 7.12.15 CAPACITY 5228 This is a well-known mandatory attribute that is used to denote the 5229 traffic handling capacity of the RD_PATH listed in the same UPDATE 5230 PDU. Different routeing domains may use different values for this 5231 attribute: thus, the attribute shall deal in relative capacities. 5233 Note 27: The semantics of this attribute must be agreed on a 5234 bilateral basis using mechnaisms outsdide the scope of this 5235 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5237 International Standard before a BIS-BIS connection is 5238 established. 5240 The value of capacity that is associated with a given routeing domain 5241 is contained in managed object capacity. 5243 If a BIS advertises a route whose destinations are located in its own 5244 routeing domain, then the originating BIS shall include this 5245 attribute in its outbound UPDATE PDUs, and its value shall be equal 5246 to that of managed object capacity. 5248 If a BIS redistributes a route, it shall include the CAPACITY 5249 attribute in its outbound UPDATE PDU, and shall reflect the higher of 5250 the following two quantities: the value of the CAPACITY attribute 5251 contained in the UPDATE PDU that advertised the route, or the value 5252 of local managed object capacity. 5254 7.12.16 PRIORITY 5256 This well-known discretionary attribute is a distinguishing 5257 attribute, used to indicate the minimum priority value that the BIS 5258 will support. It is an unsigned integer in the range from 0 to 14, 5259 with higher priority indicated by higher values. 5261 The value of this parameter is the same for all BISs in a given 5262 routeing domain, and is equal to the value contained in managed 5263 object priority. 5265 If a BIS originates a route to destinations located in its own 5266 routeing domain, then the originating BIS may include this attribute 5267 in its outbound UPDATE PDUs; if present, its value shall be equal to 5268 that of managed object priority. 5270 If a BIS redistributes a route that was advertised with the PRIORITY 5271 attribute present, it shall include the PRIORITY attribute in its 5272 outbound UPDATE PDU, and shall set its value equal to the higher of 5273 the following two quantities: the value of the PRIORITY attribute 5274 contained in the UPDATE PDU that advertised the route, or the value 5275 of local managed object priority. 5277 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5279 7.13 Routeing domain confederations 5281 Formation of an RDC is done via a private arrangement between its 5282 members without any need for global coordination; the methods for 5283 doing so are not within the scope of this International Standard. 5285 From the outside, an RDC looks similar to a single routeing domain: 5286 for example, it has an identifier which is an RDI. Other RDs can 5287 develop policies with respect to the confederation as a whole, as 5288 opposed to the individual RDs that are members of the confederation. 5289 Confederations can be disjoint, nested, or overlapping (see 3.6). 5291 7.13.1 RDC policies 5293 Each RD within a confederation may have its own set of policies; that 5294 is, different RDs in the same confederation can have different 5295 policies. For BISs located within the same RD, the methods of 7.15.1 5296 will detect both internal and external routeing inconsistencies. 5298 Since a confederation appears to the external world as if it were an 5299 individual RD, IDRP's loop detection methods will detect routeing 5300 information loops through a given confederation. In particular, a 5301 route which leaves the confederation and then later re-enters it will 5302 be detected as a loop: thus, a route between two RDs that are members 5303 of the same confederation will be constrained to remain within that 5304 confederation. 5306 7.13.2 RDC configuration information 5308 Each BIS that participates in one or more RDCs must be aware of the 5309 RDIs of all confederations of which it is a member, and it must know 5310 the partial order which prevails between these confederations: that 5311 is, it must know the nesting and overlap relationships between all 5312 confederations to which it belongs. This information shall be 5313 contained in managed object rdcConfig, which consists of a list of 5314 confederation RDIs and the partial order that prevails among those 5315 confederations. 5317 Since RDCs are formed via private arrangement between their members, 5318 the partial order of a given confederation is a local matter for that 5319 confederation, and bears no relationship to the partial orders that 5320 may prevail in different confederations. The RDI of its own routeing 5321 domain is contained in managed object localRDI, as defined in 7.3. 5323 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5325 7.13.3 Detecting confederation boundaries 5327 A given BIS can tell which confederations are common to itself and an 5328 adjacent BIS by comparing information obtained from the Confed-IDs 5329 field of the adjacent BIS's OPEN PDU with the local BIS's rdcConfig 5330 managed object. This knowledge determines when an outbound UPDATE 5331 PDU exits a given confederation and when an inbound UPDATE PDU enters 5332 a given confederation: 5334 Exiting a Confederation: An UPDATE PDU sent by a given BIS to an 5335 adjacent BIS is defined to have exited all those confederations 5336 whose RDIs are present in the advertising BIS's rdcConfig managed 5337 object but were not reported in the Confed-IDs field of the 5338 adjacent BIS's OPEN PDU. 5340 Entering a Confederation: An UPDATE PDU received from an adjacent BIS 5341 is defined to have entered all those confederations whose RDIs are 5342 present in the receiving BIS's rdcConfig managed object but were 5343 not reported in the Confed-IDs field of the sending BIS's OPEN PDU. 5345 7.14 Update-Receive process 5347 The Update-Receive process is initiated when an UPDATE PDU with no 5348 errors is received while the FSM is in the ESTABLISHED state. When 5349 this occurs, the BIS shall update the appropriate Adj-RIB-In. 5351 For each feasible route, the Adj-RIB-In is identified by the set of 5352 distinguishing path attributes contained between consecutive 5353 instances of ROUTE_SEPARATORs or between the last ROUTE_SEPARATOR and 5354 the end of the UPDATE PDU. For an unfeasible route, the Adj-RIB-In 5355 is identified by the ROUTE-ID carried in the WITHDRAWN ROUTES field 5356 of the UPDATE PDU. The actions to be taken for each route are: 5358 a) If the UPDATE PDU contains a non-empty WITHDRAWN ROUTES field, 5359 the previously advertised feasible routes associated with the 5360 ROUTE-IDs contained in this field shall be removed from the 5361 Adj-RIB-In. The BIS shall run its Decision Process since the 5362 previously advertised route is no longer available for use. 5364 b) If the UPDATE PDU contains feasible routes, they shall each be 5365 placed in the appropriate Adj-RIB-In, and the following 5366 additional actions shall be taken for each route: 5368 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5370 1) If its NLRI and distinguishing attributes are identical to 5371 those of a route currently stored in the Adj-RIB-In, then the 5372 new route shall replace the older route in the Adj-RIB-In, 5373 thus implicitly withdrawing the older route from service. 5374 The BIS shall run its Decision Process since the older route 5375 is no longer available for use. 5377 2) If the new route is an overlapping route that is more 5378 specific (see 7.16.3.1) than an earlier route contained in 5379 the Adj-RIB-In, and the non-distinguishing path attributes of 5380 the new route differ from those of the earlier route, the BIS 5381 shall run its Decision Process since the more specific route 5382 has implicitly made a portion of the less specific route 5383 unavailable for use. 5385 3) If the new route has identical path attributes (both 5386 distinguishing and non-distinguishing) to an earlier route 5387 contained in the Adj-RIB-In, and is more specific (see 5388 7.16.3.1) than the earlier route, no further actions are 5389 necessary. 5391 4) If a new route has different NLRI from any of the routes 5392 currently in the Adj-RIB-In, it shall be placed in the 5393 Adj-RIB-In. 5395 5) If a new route is an overlapping route that is less specific 5396 (see 7.16.3.1) than an earlier route in an Adj-RIB-In, the 5397 BIS shall place the new route in the appropriate Adj-RIB-In. 5398 The earlier, more specific route remains unaffected. 5400 7.15 Information consistency 5402 Correct operation of this protocol requires that all BISs within a 5403 routeing domain apply a consistent set of policies for calculating 5404 the degree of preference for an RD-path. An internal inconsistency 5405 can occur when there is more than a single path to a particular 5406 destination. The hop-by-hop routeing methodology then requires a BIS 5407 to select only one of these paths for each distinguishable QOS 5408 category. Internal inconsistency arises if different BISs within the 5409 same routeing domain make different selections when presented with 5410 exactly the same set of routeing information. 5412 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5414 7.15.1 Detecting inconsistencies 5416 The Update-Receive and Update-Send processes of each BIS shall 5417 support the LOCAL_PREF field of the ROUTE_SEPARATOR attribute, which 5418 is a well-known discretionary attribute. Its value shall be set to 5419 zero in UPDATE PDUs transmitted to BISs that are located in adjacent 5420 routeing domains. In UPDATE PDUs transmitted to BISs that are 5421 located in the same routeing domain as the local BIS, its value shall 5422 be set to the degree of preference for the route as computed by the 5423 advertising (local) BIS. 5425 A BIS shall detect inconsistent routeing decisions (and, therefore, 5426 internal inconsistencies) by calculating a degree of preference for 5427 each route carried in an UPDATE PDU that it receives as part of the 5428 internal update process (see 7.17.1). If the degree of preference 5429 calculated by the local BIS is different from the value carried in 5430 the LOCAL_PREF field of the UPDATE PDU's ROUTE_SEPARATOR attribute, 5431 the routeing policies of the two BISs have internal inconsistencies. 5432 The BIS that detects the inconsistency shall report it to system 5433 management. 5435 7.16 Decision process 5437 The Decision Process selects routes for subsequent advertisement by 5438 applying the policies in its Policy Information Base to the routes 5439 stored in its Adj-RIBs-In. The output of the Decision Process is the 5440 set of routes that will be advertised to adjacent BISs; the selected 5441 routes will be stored in the local BIS's Loc-RIBs and Adj-RIBs-Out. 5443 The selection process is formalized by defining a function that takes 5444 the attributes of a given route as an argument and returns a 5445 non-negative integer denoting the degree of preference for the route. 5446 The function that calculates the degree of preference for a given 5447 route shall not use as its inputs any of the following: the existence 5448 of other routes, the non-existence of other routes, or the path 5449 attributes of other routes. Route selection then consists of 5450 individual application of the degree of preference function to each 5451 feasible route, followed by the choice of the one with the highest 5452 degree of preference. 5454 Routes that could form routeing loops must be ignored by the Decision 5455 Process. Therefore, any route that was a) received from a BIS located 5456 in an adjacent routeing domain and b) contains in its RD_PATH 5457 attribute a path segment of type RD_SEQ or RD_SET that contains the 5458 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5460 RDI of the local routeing domain or any RDC of which the local RD is 5461 a member is unfeasible, and shall be discarded by the Decision 5462 Process. 5464 IDRP does not require a universally agreed-upon metric to exist 5465 between multiple RDs. Instead, IDRP allows each RD to apply its own 5466 set of criteria for route selection, as determined by its local PIB. 5467 An example of the syntax and semantics of a routeing policy that 5468 could be used to calculate a degree of preference is described in 5469 informative Annex L. 5471 The Decision process operates on routes contained in each Adj-RIB-In, 5472 and is responsible for: 5474 - selection of routes to be advertised to BISs located in local 5475 BIS's routeing domain 5476 - selection of routes to be advertised to BISs located in adjacent 5477 routeing domains 5478 - route aggregation and route information reduction 5480 The Decision process takes place in three distinct phases, each 5481 triggered by a different event: 5483 a) Phase 1 is responsible for calculating the degree of preference 5484 for each route received from a BIS located in an adjacent 5485 routeing domain, and for advertising to the other BISs in the 5486 local Routing Domain the routes that have the highest degree of 5487 preference for each distinct destination. 5489 b) Phase 2 is invoked on completion of Phase 1. It is responsible 5490 for choosing the best route out of all those available for each 5491 distinct destination, and for installing each chosen route into 5492 the appropriate Loc-RIB. 5494 c) Phase 3 is invoked after the Loc-RIB has been modified. It is 5495 responsible for disseminating routes in the Loc-RIB to each 5496 adjacent BIS located in an adjacent routeing domain, according to 5497 the policies contained in the PIB. Route aggregation, information 5498 reduction and the modification of QOS path attributes can 5499 optionally be performed within this phase. 5501 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5503 7.16.1 Phase 1: calculation of degree of preference 5505 The Phase 1 decision function shall be invoked whenever the local BIS 5506 receives an UPDATE PDU from a neighbor BIS that advertises a new 5507 route, a replacement route, or a withdrawn route. 5509 The Phase 1 decision function is a separate process which completes 5510 when it has no further work to do. 5512 The Phase 1 decision function shall be blocked from running while the 5513 Phase 2 decision function for the same RIB-Att is in process. 5515 The Phase 1 decision function shall lock an Adj-RIB-In prior to 5516 operating on any route contained within it, and shall unlock it after 5517 operating on all new or unfeasible routes contained within it. 5519 For each newly received or replacement feasible route, the local BIS 5520 shall compute a degree of preference. Then, the local BIS shall run 5521 the internal update process of 7.17.1 to select and advertise the 5522 most preferable routes. 5524 A route received from another BIS in the local routeing domain always 5525 carries the degree of preference calculated by that BIS in the 5526 LOCAL_PREF field of the ROUTE_SEPARATOR attribute. If the value in 5527 the LOCAL_PREF field differs from the degree of preference computed 5528 above, then an internal inconsistency has occurred, and the local BIS 5529 shall report it to system management. 5531 7.16.2 Phase 2: route selection 5533 The Phase 2 decision function shall be invoked on completion of Phase 5534 1. The Phase 2 function is a separate process which completes when 5535 it has no further work to do. The Phase 2 process shall consider all 5536 routes that are present in the Adj-RIBs-In, including those received 5537 from BISs located in its own routeing domain and those received from 5538 BISs located in adjacent routeing domains. 5540 The Phase 2 decision function shall be blocked from running while the 5541 Phase 3 decision function is in process. The Phase 2 function shall 5542 lock all Adj-RIBs-In with the RIB- Att associated with this instance 5543 of the process prior to commencing its function, and shall unlock 5544 them on completion. 5546 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5548 For each set of destinations for which a feasible route exists in the 5549 Adj-RIBs-In identified by the RIB-Att on which this instance of the 5550 function operates, the local BIS shall identify the route that has: 5552 a) the highest degree of preference of any route to the same set of 5553 destinations, or 5555 b) is the only route to that destination, or 5557 c) is selected as a result of the Phase 2 tie breaking rules 5558 specified in 7.16.2.1. 5560 The local BIS shall then install that route in the Loc-RIB, replacing 5561 any route to the same destination that is currently held in the 5562 Loc-RIB. 5564 When the RIB-Att includes the priority attribute then all routes with 5565 the same NLRI shall be copied to the Loc-RIB unless their computed 5566 preference is less than another such route with the same or lower 5567 priority. 5569 When the RIB-Att includes the SECURITY attribute then all routes with 5570 the same NLRI shall be copied to the Loc-RIB unless their computed 5571 preference is less than another such route which the applicable PIB 5572 Security Policy rules identify as providing equivalent or poorer 5573 protection and are usable by the same or more NPDUs. 5575 If a route copied to a Loc-RIB does not have a NEXT_HOP path 5576 attribute, then the local BIS shall add that attribute to the entry 5577 in the Loc-RIB. The value of the attribute shall be the NET of the 5578 adjacent BIS from which the route was received. 5580 Unfeasible routes shall be removed from the Loc-RIB, and 5581 corresponding unfeasible routes shall then be removed from the 5582 Adj-RIBs-In. 5584 Note 28: The decision process should not select a route to 5585 destinations located within the local routeing domain if 5586 that route would exit the local routeing domain and later 5587 re-enter it. Such routes would be rejected by other RDs 5588 due to the existence of an RD-loop. Furthermore, the IDRP 5589 CLNS Forwarding Process will not forward NPDUs (destined to 5590 internal destinations) outside of the local RD, but will 5591 instead hand them over to the intra-domain routeing 5592 protocol. 5594 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5596 7.16.2.1 Breaking ties (phase 2) 5598 In its Adj-RIBs-In, a BIS may have several routes to the same 5599 destination that have the same degree of preference and also have an 5600 equivalent set of distinguishing attributes. The local BIS can 5601 select only one of these routes for inclusion in the associated 5602 Loc-RIB. The local BIS considers all equally preferable routes, both 5603 those received from BISs located in adjacent RDs and those received 5604 from other BISs located in the local BIS's own RD. 5606 Ties shall be broken according to the following rules: 5608 a) If the candidate routes have identical path attributes or differ 5609 only in the NEXT_HOP attribute, select the route that was 5610 advertised by the BIS in an adjacent routeing domain whose NET 5611 has the lowest value. If none of the candidate routes were 5612 received from a BIS located in an adjacent routeing domain, 5613 select the route that was advertised by the BIS in the local 5614 routeing domain whose NET has the lowest value. 5616 b) If all candidate routes contain the MULTI-EXIT_DISC attribute, 5617 the candidate routes differ only in their NEXT_HOP and 5618 MULTI-EXIT_DISC attributes, and the local BIS's managed object 5619 multiExit is TRUE, select the route that has the lowest value of 5620 the MULTI-EXIT_DISC attribute. If multiple candidate routes 5621 remain, select the route that was advertised by the BIS whose NET 5622 has the lowest value. 5624 If the managed object multiExit is false, select the route 5625 advertised by the BIS in an adjacent RD whose NET has the lowest 5626 value. If none of the candidate routes were received from a BIS 5627 located in an adjacent routeing domain, select the route that was 5628 advertised by the BIS in the local routeing domain whose NET has 5629 the lowest value. 5631 c) If the candidate routes differ in any path attributes other than 5632 NEXT_HOP and MULTI-EXIT_DISC, select the route that was 5633 advertised by the BIS whose NET has the lowest value. When 5634 comparing NETs, if one of the candidate routes was received from 5635 a BIS in an adjacent routeing domain, use the NET of the local 5636 BIS for the comparison. 5638 For purposes of determining the lowest-valued NET, each 5639 binary-encoded NET shall be padded with trailing 0's in order to 5640 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5642 bring its length up to 20 octets. The encoded (and possibly padded) 5643 NETs shall then be treated as unsigned binary integers. 5645 7.16.3 Phase 3: route dissemination 5647 The Phase 3 decision function shall be invoked on completion of Phase 5648 2, or when any of the following events occur: 5650 a) when routes in a Loc-RIB to local destinations have changed 5652 b) when locally generated routes with the EXT_INFO attribute (that 5653 is, routes learned by means outside of IDRP) have changed 5655 c) when a new BIS-BIS connection has been established 5657 d) when directed to do so by system management. 5659 The Phase 3 function is a separate process which completes when it 5660 has no further work to do. 5662 The Phase 3 Routing Decision function shall be blocked from running 5663 while the Phase 2 decision function is in process. 5665 All routes in the Loc-RIB shall be processed into a corresponding 5666 entry in the associated Adj-RIBs-Out and FIBs (which are identified 5667 by the same RIB-Att), replacing the current entries., The path 5668 attributes are updated in accordance with the appropriate subclause 5669 of 7.12. Route aggregation and information reduction techniques (see 5670 7.18) may optionally be applied. Routes with identical NLRI 5671 extracted from the same Loc-RIB shall always be aggregated before 5672 being copied to an Adj-RIB-Out, and may be aggregated with other 5673 routes according to the local Routing Policy. Every FIB shall have 5674 an entry for every destination for which a route exists in a Loc-RIB. 5676 A locking scheme should be implemented to prevent simultaneous access 5677 to an FIB by both the phase 3 function and forwarding engine. The 5678 phase 3 function should first lock an FIB before entering, replacing 5679 or deleting an entry, and then unlock that FIB once the operation is 5680 complete. 5682 When the updating of the Adj-RIBs-Out and the FIBs is complete, the 5683 local BIS shall run the external update process of 7.17.2. 5685 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5687 7.16.3.1 Overlapping routes 5689 A BIS may transmit routes with overlapping NLRI to another BIS. NLRI 5690 overlap occurs when a set of destinations are identified in 5691 non-matching multiple routes, all of which have the same set of 5692 distinguishing attributes. Since IDRP encodes NLRI using prefixes, 5693 overlaps will always exhibit subset relationships. A route 5694 describing a smaller set of destinations (a longer prefix) is said to 5695 be more specific than a route describing a larger set of destinations 5696 (a shorter prefix); similarly, a route describing a larger set of 5697 destinations (a shorter prefix) is said to be less specific than a 5698 route describing a smaller set of destinations (a longer prefix). 5700 When overlapping routes are present in the same Adj-RIB-In, the more 5701 specific routes shall take precedence, in order from most specific to 5702 least specific. 5704 This precedence relationship effectively decomposes less specific 5705 routes into two parts: 5707 - a set of destinations described only by the less specific route, 5708 and 5709 - a set of destinations described by the overlap of the less 5710 specific and the more specific routes 5712 The set of destinations described by the overlap represent a portion 5713 of the less specific route that is feasible, but is not currently in 5714 use. If a more specific route is later withdrawn, the set of 5715 destinations described by the overlap will still be reachable using 5716 the less specific route. 5718 If a BIS receives overlapping routes from a given neighbor, the 5719 Decision Process shall not simultaneously reject the more specific 5720 route from neighbor BIS (A) and install A's less specific route 5721 unless the contents of the local BIS's Adj-RIBs-Out and FIBs insure 5722 that NPDUs with destinations listed in the NLRI of A's more specific 5723 route can not be forwarded to the neighbor BIS (A). 5725 Therefore, when presented with overlapping routes from a given 5726 neighbor BIS (A), the local BIS could select any of the following 5727 options, all of which satisfy the criterion stated above: 5729 a) Install both the less specific and more specific routes received 5730 from the given neighbor (A) 5731 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5733 b) Install the more specific route received from the given neighbor 5734 (A) and reject A's less specific route 5735 c) Install the non-overlapping part of the less specific and more 5736 specific routes received from the given neighbor (A) 5737 d) Install a route formed by the aggregation of the less specific 5738 and the more specific route received from the given neighbor (A) 5739 e) Install the less specific route received from the given neighbor 5740 (A), and also install another route received from a different 5741 neighbor (B) that is simultaneously: 5742 1) more specific than A's less specific route, and 5743 2) less specific than A's more specific route. 5744 f) Install neither of the routes received from A. 5746 7.16.4 Interaction with update process 5748 Since the Adj-RIBs-In are used both to receive inbound UPDATE PDUs 5749 and to provide input to the Decision Process, care must be taken that 5750 their contents are not modified while the Decision Process is 5751 running. That is, the input to the Decision Process shall remain 5752 stable while a computation is in progress. 5754 Two examples of approaches that could be taken to accomplish this: 5756 a) The Decision Process can signal when it is running. During this 5757 time, any incoming UPDATE PDUs will be queued and will not be 5758 written into the Adj-RIBs-In. If more UPDATE PDUs arrive than 5759 can be fit into the allotted queue, they will be dropped and will 5760 not be acknowledged. 5762 b) A BIS can maintain two copies of the Adj-RIBs-In--one used by the 5763 Decision Process for its computation (call this the Comp-Adj-RIB) 5764 and the other to receive inbound UPDATE PDUs (call this the 5765 Holding-Adj-RIB). Each time the Decision begins a new 5766 computation, the contents of the Holding-Adj-RIB will be copied 5767 to the Comp-Adj-RIB: that is, the a snapshot of the Comp-Adj-RIB 5768 is used as the input for the Decision Process. The contents of 5769 the Comp-Adj-RIB remain stable until a new computation is begun. 5771 The advantage of the first approach is that it takes less memory; the 5772 advantage of the second is that inbound UPDATE PDUs will not be 5773 dropped. This international standard does not mandate the use of 5774 either of these methods. Any method that guarantees that the input 5775 data to the Decision Process will remain stable while a computation 5776 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5778 is in progress and that is consistent with the conformance 5779 requirements of this International Standard may be used. 5781 7.17 Update-Send process 5783 The Update-Send process is responsible for advertising BISPDUs to 5784 adjacent BISs. For example, it distributes the routes chosen by the 5785 Decision Process to other BISs which may be located in either the 5786 same RD or an adjacent RD. Rules for information exchange between 5787 BIS located in different routeing domains are given in 7.17.2; rules 5788 for information exchange between BIS located in the same domain are 5789 given in 7.17.1. 5791 Distribution of reachability information between a set of BISs, all 5792 of which are located in the same routeing domain, is referred to as 5793 internal distribution. All BISs located in a single RD must present 5794 consistent reachability information to adjacent RDs, thus requiring 5795 that they have consistent routeing and policy information among them. 5797 Note 29: This requirement on consistency does not preclude an RD 5798 from distributing different reachability information to 5799 each of its adjacent routeing domains. It does mean that 5800 all of a domain's BISs which are attached to a given 5801 adjacent domain must provide identical reachability to that 5802 domain. 5804 When this protocol is run between BISs located in different routeing 5805 domains, the communicating BISs must be located in adjacent routeing 5806 domains--that is, they must be attached to a common subnetwork. 5808 7.17.1 Internal updates 5810 The internal update process is concerned with the distribution of 5811 routeing information to BISs located in the local BIS's own routeing 5812 domain. Each BIS selects the most preferable route, if any, that it 5813 has received from a BIS in an adjacent routeing domain, and 5814 distributes that route to every other BIS in its own routeing domain. 5815 This process ensures that all BISs in a routeing domain will select 5816 the same set of routes. 5818 The following procedures shall be applied separately for each set of 5819 Distinguishing Attributes supported by the BIS: 5821 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5823 a) When a BIS receives an UPDATE PDU from another BIS located in its 5824 own routeing domain, the receiving BIS shall not re-distribute 5825 the routeing information contained in that UPDATE PDU to other 5826 BISs located in its own routeing domain. 5828 b) When a BIS receives a new feasible route from a BIS in an 5829 adjacent routeing domain, it shall advertise that route to all 5830 other BISs in its routeing domain by means of an UPDATE PDU if 5831 any of the following conditions occur: 5833 1) the degree of preference assigned to the newly received route 5834 by the local BIS is higher than the degrees of preference 5835 that the local BIS has assigned to other routes--with the 5836 same destinations and the same Distinguishing 5837 Attributes--that have been received from BISs in adjacent 5838 routeing domains. 5840 2) there are no other routes--with the same destinations and the 5841 same Distinguishing Attributes--that have been received from 5842 BISs in adjacent routeing domains. 5844 3) the newly received route is selected as a result of breaking 5845 a tie between several routes that were received from BISs in 5846 adjacent routeing domains and that have the highest degree of 5847 preference, the same destinations, and the same 5848 distinguishing attributes (see 7.17.1.1). 5850 c) When a BIS receives an UPDATE PDU with a non-empty WITHDRAWN 5851 ROUTES field, it shall remove from its Adj-RIBs-In all routes 5852 whose ROUTE-ID was carried in this field. The BIS shall take the 5853 following additional steps: 5855 1) if the corresponding feasible route had not been previously 5856 advertised, then no further action is necessary 5858 2) if the corresponding feasible route had been previously 5859 advertised, then: 5861 i) if a new route is selected for advertisement that has the 5862 same distinguishing attributes and NLRI as the unfeasible 5863 route, then the local BIS shall advertise the replacement 5864 route 5866 ii) if a replacement route is not available for 5867 advertisement, then the BIS shall include the ROUTE-ID of 5868 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5870 the unfeasible route in the WITHDRAWN ROUTES field of an 5871 UPDATE PDU, and shall send this PDU to each neighbor BIS 5872 to whom it had previously advertised the corresponding 5873 feasible route. 5875 All feasible routes which are advertised shall be placed in the 5876 appropriate Adj-RIB-Out, and all unfeasible routes which are 5877 advertised shall be removed from the Adj-RIBs-Out. 5879 7.17.1.1 Breaking ties (internal updates) 5881 If a local BIS has connections to several BISs in adjacent domains, 5882 there will be multiple Adj-RIBs-In associated with these neighbors. 5883 These Adj-RIBs-In might contain several equally preferable routes to 5884 the same destination, all of which have the same set of 5885 distinguishing attributes and all of which were advertised by BISs 5886 located in adjacent routeing domains. The local BIS shall select one 5887 of these routes, according to the following rules: 5889 a) If all candidate routes contain the MULTI-EXIT_DISC attribute, 5890 the candidate routes differ only in their NEXT_HOP and 5891 MULTI-EXIT_DISC attributes, and the local BIS's managed object 5892 Multiexit is TRUE, select the route that has the lowest value of 5893 the MULTI-EXIT_DISC attribute. If multiple candidate routes 5894 remain, select the route that was advertised by the BIS whose NET 5895 has the lowest value. 5896 b) In all other cases, select the route that was advertised by the 5897 BIS whose NET has the lowest value. 5899 For purposes of determining the lowest-valued NET, each 5900 binary-encoded NET shall be padded with trailing 0's in order to 5901 bring its length up to 20 octets. The encoded (and possibly padded) 5902 NETs shall then be treated as unsigned binary integers. 5904 7.17.2 External updates 5906 The external update process is concerned with the distribution of 5907 routeing information to BISs located in adjacent routeing domains. 5908 As part of the Phase 3 route selection process, the BIS has updated 5909 its Adj-RIBs-Out and its FIBs. All newly installed routes and all 5910 newly unfeasible routes for which there is no replacement route shall 5911 be advertised to BISs located in adjacent routeing domains by means 5912 of UPDATE PDUs. 5914 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5916 Any routes in the Loc-RIB marked as infeasible shall be removed. 5917 Changes to the reachable destinations within its own RD shall also be 5918 advertised in an UPDATE PDU. 5920 However, advertisement of a given UPDATE PDU shall not violate any 5921 distribution constraint imposed by the path attributes of the route 5922 contained therein. (For example, DIST_LIST_INCL, DIST_LIST_EXCL, and 5923 HIERARCHICAL _RECORDING are attributes that impose distribution 5924 constraints on the UPDATE PDU that contains them.) 5926 A BIS shall not propagate an UPDATE PDU that contains a set of 5927 distinguishing path attributes that were not listed in the 5928 RIB-AttsSet field of the neighbor BIS's OPEN PDU. If such 5929 distinguishing attributes are advertised, it will cause the BIS-BIS 5930 connection to be closed, as described in 7.20.3. 5932 7.17.3 Controlling routeing traffic overhead 5934 The inter-domain routeing protocol constrains the amount of routeing 5935 traffic (that is, BISPDUs) in order to limit both the link bandwidth 5936 needed to advertise BISPDUs and the processing power needed by the 5937 Decision Process to digest the information contained in the BISPDUs. 5939 7.17.3.1 Frequency of route advertisement 5941 The managed object minRouteAdvertisementInterval determines the 5942 minimum amount of time that must elapse between advertisements of 5943 routes to a particular destination from a single BIS. This rate 5944 limiting procedure applies on a per-destination basis, although the 5945 value of minRouteAdvertisementInterval is set on a per-BIS basis. 5947 Two UPDATE PDUs sent from a single BIS that advertise feasible routes 5948 to some common set of destinations received from BISs in other 5949 routeing domains must be separated in time by at least 5950 minRouteAdvertisementInterval. For example, any technique that 5951 ensures that the separation will be between one and two times the 5952 value minRouteAdvertisementInterval is acceptable. 5954 Since fast convergence is needed within an RD, this procedure does 5955 not apply for routes received from other BISs in the same routeing 5956 domain. To avoid long-lived black holes, the procedure does not 5957 apply to the explicit withdrawal of unfeasible routes (that is, 5958 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5960 routes whose ROUTE_ID is listed in the Withdrawn Routes field of an 5961 UPDATE PDU). 5963 This procedure does not limit the rate of route selection, but only 5964 the rate of route advertisement. If new routes are selected multiple 5965 times while awaiting the expiration of minRouteAdvertisementInterval, 5966 the last route selected shall be advertised at the end of 5967 minRouteAdvertisementInterval. 5969 7.17.3.2 Frequency of route origination 5971 The architectural constant MinRDOriginationInterval determines the 5972 minimum amount of time that must elapse between successive 5973 advertisements of UPDATE PDUs that report changes within the 5974 advertising BIS's own routeing domain. 5976 7.17.3.3 Jitter 5978 To minimize the likelihood that the distribution of BISPDUs by a 5979 given BIS will contain peaks, jitter should be applied to the timers 5980 associated with minRouteAdvertisementInterval and 5981 MinRDOriginationInterval. A given BIS shall apply the same jitter to 5982 each of these quantities regardless of the destinations to which the 5983 updates are being sent: that is, jitter will not be applied on a "per 5984 peer" basis. 5986 The amount of jitter to be introduced shall be determined by 5987 multiplying the base value in the appropriate managed object by a 5988 random factor which is uniformly distributed in the range from 1-J to 5989 1, where J is the value of the architectural constant Jitter. The 5990 result shall be rounded up to the nearest 100 millisecond increment. 5992 An example of a suitable algorithm is shown in informative Annex E, 5993 using the architectural constant jitter. 5995 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 5997 7.18 Efficient organization of routeing information 5999 Having selected the routeing information which it will advertise, a 6000 BIS may avail itself of several methods to organize this information 6001 in an efficient manner. 6003 7.18.1 Information reduction 6005 Information reduction may imply a reduction in granularity of policy 6006 control--after information is collapsed, the same policies will apply 6007 to all destinations and paths in the equivalence class. 6009 The Decision Process may optionally reduce the amount of information 6010 that it will place in the Adj-RIBs-Out by any of the following 6011 methods: 6013 a) Network Layer Reachability Information: 6015 Destination NSAP addresses can be represented as NSAP address 6016 prefixes. In cases where there is a correspondence between the 6017 address structure and the systems under control of a routeing 6018 domain administrator, it will be possible to reduce the size of 6019 the network layer reachability information that is carried in the 6020 UPDATE PDUs. 6022 b) RD_PATHS: 6024 RD path information can be represented as ordered RD-SEQUENCES or 6025 unordered RD_SETs. RD_SETs are used in the route aggregation 6026 algorithm described in 7.18.2. They reduce the size of the 6027 RD_PATH information by listing each RDI only once, regardless of 6028 how many times it may have appeared in the multiple RD_PATHS that 6029 were aggregated. 6031 An RD_SET implies that the destinations listed in the NLRI can be 6032 reached through paths that traverse at least some of its 6033 constituent RDs. RD_SETs provide sufficient information to avoid 6034 routeing loops; however, their use may prune potentially useful 6035 paths, since such paths are no longer listed individually as in 6036 the form of RD_SEQUENCES. In practice this is not likely to be a 6037 problem, since once an NPDU arrives at the edge of a group of 6038 RDs, the BIS at that point is likely to have more detailed path 6039 information and can distinguish individual paths to destinations. 6041 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6043 7.18.2 Aggregating routeing information 6045 Aggregation is the process of combining the characteristics of 6046 several different routes (or components of a route such as an 6047 individual path attribute) in such a way that a single route can be 6048 advertised. Aggregation can occur as part of the decision process to 6049 reduce the amount of information that will be placed in the 6050 Adj-RIBs-Out. For example, at the boundary of a routeing domain 6051 confederation an exit BIS can aggregate several intra-confederation 6052 routes into a single route that will be advertised externally. 6054 Aggregation reduces the amount of information that BISs must store 6055 and exchange with each other. Routes can be aggregated by applying 6056 the following procedures separately to path attributes of like type 6057 and to the NLRI information. 6059 7.18.2.1 Route aggregation 6061 Several routes shall not be aggregated into a single route unless the 6062 Distinguishing Attributes of each of these route are equivalent, as 6063 defined in 7.11.3. 6065 Routes that contain the DIST_LIST_INCL attribute may not be 6066 aggregated with routes that contain the DIST_LIST_EXCL attribute. 6068 Routes that have the following attributes shall not be aggregated 6069 unless the corresponding attributes of each route are identical: 6070 MULTI-EXIT_DISC and NEXT_HOP. 6072 An aggregated route is constructed from one or more component routes. 6073 If a component of an aggregated route that has been advertised in an 6074 UPDATE PDU becomes unfeasible, then all component routes that 6075 comprise the aggregated route, except for the unfeasible component, 6076 shall be advertised again, either as separate routes or as a new 6077 aggregated route. If the new aggregated route has the same NLRI as 6078 the previous aggregated route, then no further actions are necessary, 6079 since advertisement of the new aggregated route implicitly marks the 6080 old aggregated route as having been withdrawn from use. In all other 6081 cases, the original aggregated route must be withdrawn explicitly by 6082 means of the Withdrawn Routes field of an UPDATE PDU. 6084 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6086 7.18.2.2 NLRI aggregation 6088 The aggregation of the NLRI fields from several routes is 6089 straightforward: 6091 - If a shorter NSAP address prefix can be used to represent the 6092 NSAPs (and only those NSAPs) listed in several individual NSAP 6093 address prefixes, this may be done. However, a shorter NSAP 6094 prefix which would be associated with more NSAPs than were 6095 associated with the individual prefixes being aggregated shall 6096 not be used. 6098 - Individual NSAP address prefixes from the routes whose NLRI is to 6099 be aggregated can be listed individually in a single NLRI field. 6101 7.18.2.3 Path attribute aggregation 6103 Path attributes that have different type codes can not be aggregated 6104 together. Path attributes of the same type code may be aggregated, 6105 according to the following rules: 6107 ROUTE_SEPARATOR attributes: When several routes are aggregated, the 6108 ROUTE_SEPARATOR attribute of the aggregated route shall contain an 6109 unambiguous ROUTE-ID for the aggregated route, in accordance with 6110 7.12.1; the advertising BIS shall also compute a degree of 6111 preference for the aggregated route, and shall carry this value in 6112 the LOCAL_PREF field, in accordance with 7.12.1. 6114 EXT_INFO attributes: If at least one route among routes that are 6115 aggregated has the EXT_INFO attribute, then the aggregated route 6116 must have the EXT_INFO attribute as well. 6118 RD_PATH attributes: The individual RD_PATH attributes from which the 6119 aggregated RD_PATH attribute will be constructed are called the 6120 component attributes, and the ENTRY_SEQ and ENTRY_SET path 6121 segments contain the RDIs of confederations that have been entered 6122 but not yet exited. If the RDIs of all such confederations appear 6123 in the same relative order of entry in every component route, then 6124 aggregation may be performed without pre-processing the component 6125 routes. If they appear in different orders of entry in the 6126 component routes, then the pre-processing step outlined below must 6127 be performed in order to create the same order of entry in every 6128 component route before applying the aggregation procedures. 6130 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6132 If routes to be aggregated have identical RD_PATH attributes, then 6133 the aggregated route has the same RD_PATH attribute as each 6134 individual route, and no further processing is necessary. 6136 Pre-processing to Attain Identical Order of Entry: Apply the 6137 following procedure to each component route individually. Replace 6138 all path segments, from the first ENTRY_SET or ENTRY_SEQ segment 6139 to the last path segment, inclusive, with a path segment of type 6140 ENTRY_SET followed by a path segment of type RD_SET: 6142 - The path segment of type ENTRY_SET shall contain the union of 6143 the all the RDIs listed in the individual ENTRY_SET and 6144 ENTRY_SEQ segments. The RDIs must be listed in the same order 6145 in each component route. The specific ordering algorithm is 6146 left as a local matter, but it shall guarantee that the RDI of 6147 a given confederation does not precede the RDI of any 6148 confederation within which it it is nested. 6150 - The path segment of type RD_SET shall contain the union of the 6151 RDIs contained in all RD_SETs and RD_SEQs that appear after 6152 the first ENTRY_SET or ENTRY_SEQ of the component route. 6154 Aggregation Procedures: For purposes of this procedure, a path 6155 segment that lists multiple RDIs shall be treated as if it were 6156 multiple consecutive path segments, where each path segment lists 6157 a single RDI and the order of appearance of RDIs is maintained. 6158 For example, a path segment that listed RDIs X, Y, and Z (in that 6159 order) is treated as if it were a path segment listing X, followed 6160 by a path segment listing Y, followed by a path segment listing Z. 6161 If all the RD_PATH attributes of all component routes are 6162 identical, the aggregated path attribute is equal to the original 6163 RD_PATH attribute. 6165 The main procedure of 7.18.2.3.1 calls the subroutine of 6166 7.18.2.3.2 for aggregating RD_PATH attributes that contain no 6167 ENTRY_SEQs or ENTRY_SETs (generically called an "Entry Marker"). 6168 In effect, the main procedure applies the subroutine to all 6169 segments that are located between Entry Markers, between an Entry 6170 Marker and the end of a component attribute, or between the start 6171 of a component attribute and its first Entry Marker. 6173 The main procedure is described in 7.18.2.3.1, and the subroutine 6174 is described in 7.18.2.3.2. 6176 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6178 DIST_LIST_INCL attributes: The DIST_LIST_INCL attribute of the 6179 aggregated route is formed by the set intersection of the RDIs 6180 listed in the DIST_LIST_INCL attributes of the individual routes. 6181 If the set intersection consists of an empty set, then the routes 6182 shall not be aggregated. 6184 DIST_LIST_EXCL attributes: The DIST_LIST_EXCL attribute of the 6185 aggregated route is formed by the set union of the RDIs listed in 6186 the DIST_LIST_EXCL attribute of the individual routes. A route 6187 that contains no DIST_LIST_EXCL attribute is treated as if it 6188 contained a DIST_LIST_EXCL attribute that lists no RDIs. 6190 TRANSIT DELAY attributes: The value of the Transit Delay attribute of 6191 the aggregated route is set to the maximum value of the Transit 6192 Delay attribute of the individual routes that are aggregated. 6194 RESIDUAL ERROR attributes: The value of the Residual Error attribute 6195 of the aggregated route is set to the maximum value of the 6196 Residual Error attribute of the individual routes that are 6197 aggregated. 6199 EXPENSE attributes: The value of the Expense attribute of the 6200 aggregated route is set to the maximum value of the Expense 6201 attribute of the individual routes that are aggregated. 6203 LOCALLY DEFINED QOS attributes: Routes that contain the LOCALLY 6204 SPECIFIED QOS attribute shall only be aggregated if their LOCALLY 6205 SPECIFIED QOS attributes have an identical NSAP Address Prefix 6206 field and an identical QoS Value field. 6208 The rules for determining the value of the metric field of each 6209 such LOCALLY SPECIFIED QOS attribute of the aggregated route are 6210 specific for each QoS Value and are specified by the responsible 6211 QoS Authority. They shall be held in the PIB. If no suitable rule 6212 exists in the PIB then the routes shall not be aggregated. 6214 HIERARCHICAL RECORDING attributes: If any of the routes to be 6215 aggregated contains the HIERARCHICAL_RECORDING attribute, the 6216 aggregated route shall also contain a HIERARCHICAL_RECORDING 6217 attribute: 6219 - If the routes to be aggregated contain different values for 6220 this attribute, then it shall be set to a value of 0 in the 6221 aggregated route 6222 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6224 - If all routes to be aggregated contain the same value for this 6225 attribute, then it shall be set to that value in the 6226 aggregated route. 6228 RD_HOP COUNT attribute: The value of the RD_HOP_COUNT of the 6229 aggregated route shall be set equal to the largest RD_HOP_COUNT 6230 that was contained in the routes being aggregated. 6232 SECURITY attribute: Routes that contain the SECURITY attribute shall 6233 only be aggregated if their SECURITY attributes identify the same 6234 Security Authority. 6236 The rules for determining the value of the SECURITY attribute of 6237 the aggregated route are specified by the responsible Security 6238 Authority. They shall be held in the PIB. If no suitable rule 6239 exists in the PIB then the routes shall not be aggregated. 6241 PRIORITY attributes: The value of the PRIORITY attribute of the 6242 aggregated route shall be equal to the maximum value of the values 6243 of the PRIORITY attributes of the routes being aggregated, unless 6244 the NLRI of component routes are identical. In this case, the 6245 value of the PRIORITY attribute of the aggregated route shall be 6246 the minimum value of the values of the PRIORITY attributes of the 6247 routes being aggregated. 6249 CAPACITY Attributes: The value of the CAPACITY attribute of the 6250 aggregated route shall be equal to the smallest integer value 6251 contained in the CAPACITY fields of the routes being aggregated. 6253 7.18.2.3.1 Main procedure for RD_PATH aggregation: This procedure 6254 is used to aggregate the RD_PATH attributes of component routes: 6256 a) Set the aggregated RD_PATH to "empty". 6258 b) Scanning from the back of each non-empty component attribute, 6259 locate the first Entry Marker. If the type of marker in any 6260 component route is ENTRY_SET, then change the type of the 6261 corresponding Entry Marker in all component attributes to 6262 ENTRY_SET. 6264 c) If no Entry Marker is found, apply the subroutine for aggregating 6265 RD_PATHs with no Entry Markers (see 7.18.2.3.2), and prepend the 6266 result to the aggregated RD_PATH attribute. 6268 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6270 d) If a Entry Marker is found, prepend the following to the 6271 aggregated RD_PATH attribute, in the order indicated: the located 6272 Entry Marker, followed immediately by the path segments obtained 6273 by applying the subroutine for aggregation of RD_PATHs with no 6274 Entry Markers (see 7.18.2.3.2) to the path segments that follow 6275 the located Entry Marker in each component attribute. If a 6276 component attribute has no path segments following the located 6277 Entry Marker, pass it to the subroutine as an empty set. 6279 e) Delete from each component attribute all the path segments that 6280 were appended to the aggregated attribute in steps c or d. 6282 f) Repeat steps b through e until every component attribute is 6283 empty. 6285 If there are consecutive path segments of the same type, they shall 6286 be combined into a single path segment of the same type. 6288 7.18.2.3.2 Aggregating routes with no entry markers: The subroutine 6289 for aggregating RD_PATH attributes with no entry markers is as 6290 follows: 6292 a) Set the aggregated RD_PATH to "empty". 6294 b) Scanning from the back of each component attribute, locate the 6295 first identical longest sequence of path segments that occurs in 6296 every component attribute, including any that are empty. 6298 Note 30: It will not be possible to find an identical sequence 6299 in every component attribute if one or more of them are 6300 empty. 6302 c) If there is no identical sequence, form a path segment of type 6303 RD_SET that contains every RDI in every non-empty component 6304 attribute. Prepend this list to the aggregated RD_PATH 6305 attribute. 6307 d) If the identical sequence is the final sequence of every 6308 component attribute, prepend it to the aggregated route. 6310 e) If the identical sequence is not the final sequence of every 6311 component attribute, form a path segment of type RD_SET that 6312 lists every RDI that occurs between the end of the identical 6313 sequence and the end of each non-empty component attribute. 6314 Prepend this list to the aggregated RD_PATH attribute. 6316 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6318 f) Delete from each component attribute all path segments that were 6319 added to the aggregated RD_PATH attribute in step c, d, or e. 6321 g) If, after the deletions in step f have been made, an RDI is 6322 present in both the aggregated RD_PATH attribute and in any of 6323 the component attributes, then the accumulated RD_PATH attribute 6324 shall be replaced by a single path segment of type RD_SET that 6325 lists every RDI that was present in the component routes that 6326 were the input to this subroutine (before any deletions were 6327 made), and the subroutine terminates. Otherwise, repeat steps b 6328 through f until every component attribute is empty. 6330 7.19 Maintenance of the forwarding information bases 6332 As summarized in Table 1, the Forwarding Information Bases contain 6333 the following information for a given RIB-Att (set of distinguishing 6334 attributes) and set of destinations (NLRI): 6336 a) the NET of the next-hop BIS, 6338 b) the local SNPA used by the local BIS to forward traffic to the 6339 next-hop BIS, 6341 c) the minimum priority supported by this subnetwork hop, if the 6342 FIB's RIB-Att contains the PRIORITY attribute 6344 d) security related information associated with this subnetwork hop, 6345 if the FIB's RIB-Att contains the SECURITY attribute 6347 e) if available, the SNPA in the next-hop BIS to which NPDUs will be 6348 forwarded. 6350 f) the QoS metric value if the FIB's RIB-Att contains the RESIDUAL 6351 ERROR, TRANSIT DELAY, EXPENSE, or LOCALLY DEFINED QOS attribute. 6353 The RIB-Att of the Loc-RIB which contains a route is also the RIB-Att 6354 of the corresponding FIB; the NLRI for the associated FIB is the same 6355 as the NLRI of the corresponding route that is stored in the Loc-RIB. 6356 Therefore, the destination address of an incoming NPDU and its 6357 NPDU-derived distinguishing attributes (see 8.3) allow a BIS to 6358 determine the FIB which contains the forwarding information to be 6359 used for this NPDU. 6361 The forwarding information consists of three parts. 6363 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6365 a) Net of Next-hop BIS: For each route in the Loc-RIB, the next-hop 6366 BIS has been determined, and is carried as a tag, as described in 6367 7.16.2. The same tag is then carried over into the corresponding 6368 entry in the FIB. This information is always present. 6370 b) Output SNPA: The SNPA that will be used by the local BIS for 6371 forwarding traffic to the destinations identified in the NLRI 6372 field of the FIB is established locally, and is one of the SNPAs 6373 identified in managed object localSNPA. 6375 c) Input SNPA: The SNPA that will be used by the remote BIS to 6376 receive traffic that is the NEXT_HOP attribute of the 6377 corresponding route stored in the Loc-RIB. If the NEXT-HOP 6378 attribute contains an empty SNPA list, or if the NEXT_HOP 6379 attribute itself is not included in the route, then the Input 6380 SNPA field in the FIB will be empty. 6382 d) priority: The minimum priority that an NPDU shall have for it to 6383 be forwarded over this subnetwork hop. If omitted, then the NPDU 6384 may have any priority. 6386 e) security related information: identifies the protection 6387 available over the subnetwork hop and the NPDUs that may use it 6388 with reference to a known Security Policy. 6390 f) QoS Metric: provides the value of the route's QoS metric for the 6391 corresponding QoS distinguishing path attribute, for use in 6392 additional matching rules during the NPDU forwarding process. 6394 7.20 Error handling for BISPDUs 6396 This section describes actions to be taken when errors are detected 6397 while processing BISPDUs. Error handling procedures apply 6398 individually to each FSM in the BIS. 6400 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6402 7.20.1 BISPDU header error handling 6404 If BIS-BIS connection was established using authentication code 2 6405 (checksum plus authentication) and the validation pattern in the 6406 BISPDU header does not match the locally computed pattern, then the 6407 BISPDU shall be discarded without any further actions. 6409 If any of the following error conditions are detected, the BISPDU 6410 shall be discarded, and the appropriate error event shall be logged 6411 by the receiving BIS: 6413 a) Length field of a PDU header less than 30 octets or greater than 6414 the Segment Size specified by the remote system's OPEN PDU, 6416 b) Length field of an OPEN PDU less than minimum length of an OPEN_ 6417 PDU 6419 c) Length field of an UPDATE PDU less than minimum length of an 6420 UPDATE PDU 6422 d) Length field of KEEPALIVE PDU not equal to 30 6424 e) Length of an IDRP ERROR PDU less than the minimum length of 32 6426 f) Length of a CEASE PDU less than the minimum length of 30 6428 g) The BIS-BIS connection was established using authentication code 6429 1 (checksum without authentication) and the validation pattern in 6430 the BISPDU header does not match the locally computed pattern 6432 h) Type field in the BISPDU is not recognized 6434 7.20.2 OPEN PDU error handling 6436 The following errors detected while processing the OPEN PDU shall be 6437 indicated by sending an IDRP ERROR PDU with error code 6438 OPEN_PDU_Error. The error subcode of the IDRP ERROR PDU shall 6439 elaborate on the specific nature of the error. 6441 a) If the version number of the received OPEN PDU is not supported, 6442 then the error subcode of the IDRP ERROR PDU shall be set to 6443 Unsupported_Version_Number. The Data field of the IDRP ERROR PDU 6444 is a 2-octet unsigned integer, which indicates the highest 6445 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6447 supported version number less than the version of the remote BIS 6448 peer's bid (as indicated in the received OPEN PDU). 6450 b) If the Maximum PDU Size field of the OPEN PDU is less than 6451 MinBISPDULength octets, the error subcode of the IDRP ERROR PDU 6452 is set to Bad_Maximum PDU_Size. The Data field of the IDRP ERROR 6453 PDU is a 2 octet unsigned integer which contains the erroneous 6454 Maximum PDU Size field. 6456 c) If the Routeing Domain Identifier field of the OPEN PDU is not 6457 the expected one, the error subcode of the IDRP ERROR PDU is set 6458 to Bad_Peer_RD. The expected values of the Routeing Domain 6459 Identifier may be obtained by means outside the scope of this 6460 protocol (usually it is a configuration parameter). The value of 6461 the erroneous RDI is returned in the Data field of the IDRP ERROR 6462 PDU, encoded as a pair. "Length" is a one octet 6463 field containing a positive integer that gives the number of 6464 octets used for the following "RDI" field. 6466 d) If a BIS receives an OPEN PDU from a BIS located in the same RD, 6467 and the RIB-AttsSet field contained in that PDU is different from 6468 the receiving BIS's managed object RIBAttsSet, then the error 6469 subcode of the IDRP ERROR PDU shall be set to Bad-RIB-AttsSet. 6471 e) If the value of the Authentication Code field of the OPEN PDU is 6472 any value other than 1 or 2, the error subcode of the IDRP ERROR 6473 PDU is set to Unsupported_Authentication_Code. 6475 f) If a given BIS receives an OPEN PDU from another BIS located in 6476 the same routeing domain, then the RDIs reported in the 6477 Confed-IDs field of the OPEN PDU (received from the remote BIS) 6478 should match the Confed-IDs of the local BIS. If they do not 6479 match exactly, then an IDRP ERROR PDU shall be issued, indicating 6480 an OPEN PDU error with an error subcode of RDC_Mismatch. The 6481 data field of the IDRP ERROR PDU shall report the offending 6482 Confed-IDs field from the rejected OPEN PDU. 6484 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6486 7.20.3 UPDATE PDU error handling 6488 All errors detected while processing the UPDATE PDU are indicated by 6489 sending an IDRP ERROR PDU with error code UPDATE_PDU_Error. The 6490 error subcode of the IDRP ERROR PDU elaborates on the specific nature 6491 of the error. 6493 a) If the Total Attribute Length is inconsistent with the Length 6494 field of the PDU header, then the error subcode of the IDRP ERROR 6495 PDU shall be set to Malformed_Attribute_List. No further 6496 processing shall be done and all information in the UPDATE PDU 6497 shall be discarded. 6499 b) If any recognized attribute has attribute flags that conflict 6500 with the attribute type code, then the error subcode of the IDRP 6501 ERROR PDU shall be set to Attribute_Flags_Error. The Data field 6502 of the IDRP ERROR PDU shall contain the incorrect attribute 6503 (type, length and value). No further processing shall be done, 6504 and all information in the UPDATE PDU shall be discarded. 6506 c) If any recognized attribute has a length that conflicts with the 6507 expected length (based on the attribute type code), then the 6508 error subcode of the IDRP ERROR PDU shall be set to 6509 Attribute_Length_Error. The Data field of the IDRP ERROR PDU 6510 contains the incorrect attribute (type, length and value). No 6511 further processing shall be done, and all information in the 6512 UPDATE PDU shall be discarded. 6514 d) If any of the mandatory well-known attributes are not present, 6515 then the error subcode of the IDRP ERROR PDU shall be set to 6516 Missing_Well-known_Attribute. The Data field of the IDRP ERROR 6517 PDU contains the attribute type code of the missing well-known 6518 attribute. 6520 e) If any well-known attribute (so designated by the attribute 6521 flags) is not recognized, then the error subcode of the IDRP 6522 ERROR PDU shall be set to Unrecognized_Well-known_Attribute. The 6523 Data field of the IDRP ERROR PDU shall report the unrecognized 6524 attribute (type, length and value). In both cases no further 6525 processing shall be done, and all information in the UPDATE PDU 6526 shall be discarded. 6528 f) If the NEXT_HOP attribute field is invalid, then the error 6529 subcode of the IDRP ERROR PDU shall be set to 6530 Invalid_NEXT_HOP_Attribute. The Data field of the IDRP ERROR PDU 6531 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6533 contains the incorrect attribute (type, length and value). No 6534 further processing shall be done and all information in the 6535 UPDATE PDU shall be discarded. 6537 g) The sequence of RD path segments shall be checked for RD loops. 6538 RD loop detection shall be done by scanning the complete list of 6539 RD path segments (as specified in the RD_PATH attribute) and 6540 checking that each RDI in this list occurs only once. If an RD 6541 loop is detected, then the error subcode of the IDRP ERROR PDU 6542 shall be set to RD_Routeing_Loop. 6544 The data field of the IDRP ERROR PDU shall report the first RDI 6545 that indicated a loop. This RDI shall be followed immediately by 6546 the complete RD_PATH attribute. The encoding shall be: length, 6547 RDI, Offending RD_PATH attribute>, where: 6549 - "length" is a one octet field that gives the length of the in 6550 octets of the immediately following RDI field 6551 - "RDI" is the RDI that was detected as creating the loop 6552 - RD_PATH is the octet string that encoded the value field of 6553 the offending RD_PATH attribute in the received UPDATE PDU 6554 (see 6.3. 6556 No further processing shall be done, and all information in the 6557 UPDATE PDU shall be discarded. 6559 h) If any non-empty set of distinguishing attributes for any route 6560 advertised in an UPDATE PDU received from a BIS located in a 6561 different routeing domain does not match any of the RIB-Atts that 6562 the local (receiving) BIS had advertised to that neighbor in the 6563 RIB-AttsSet field of its OPEN PDU, then the receiving BIS shall 6564 send an IDRP Error PDU that reports an error subcode of 6565 Malformed_Attribute_List. All information in the UPDATE PDU 6566 shall be discarded, and no further processing shall be done. 6568 i) If the UPDATE PDU contains both the DIST_LIST_INCL and the 6569 DIST_LIST_EXCL attributes, then the error subcode of the IDRP 6570 ERROR PDU shall be set to Malformed_Attribute_List. No further 6571 processing shall be done, and all information in the UPDATE PDU 6572 shall be discarded. 6574 j) If a BIS receives an UPDATE PDU that has a DIST_LIST_EXCL 6575 attribute with the RDI of the receiving BIS or the RDI of any RDC 6576 to which the BIS belongs, the subcode of the IDRP ERROR PDU shall 6577 be set to Malformed_Attribute_List. The Data field of the IDRP 6578 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6580 ERROR PDU shall report the incorrect attribute (type, length and 6581 value). No further processing shall be done, and all information 6582 in the UPDATE PDU shall be discarded. 6584 k) If a BIS receives an UPDATE PDU that has a DIST_LIST_INCL 6585 attribute without the RDI of the receiving BIS or the RDI of any 6586 RDC to which the BIS belongs, the subcode of the IDRP ERROR PDU 6587 shall be set to Malformed_Attribute_List. The Data field of the 6588 IDRP ERROR PDU shall report the incorrect attribute (type, length 6589 and value). No further processing shall be done, and all 6590 information in the UPDATE PDU shall be discarded. 6592 Note 31: It is permissible for an UPDATE PDU to contain neither 6593 the DIST_LIST_INCL nor the DIST_LIST_EXCL attributes. 6594 According to 7.12.5, the absence of both the 6595 DIST_LIST_INCL and DIST_LIST_EXCL attributes implies 6596 that all RDs and all RDCs may receive the routeing 6597 information. 6599 l) If the length of the NLRI is inconsistent with the Length field 6600 of the PDU header, then the error subcode of the IDRP ERROR PDU 6601 shall be set to Malformed_NLRI. No further processing shall be 6602 done, and all information in the UPDATE PDU shall be discarded. 6604 m) If an optional attribute is recognized, then the value of this 6605 attribute shall be checked. If an error is detected, the 6606 attribute shall be discarded, and the error subcode of the IDRP 6607 ERROR PDU shall be set to Optional_Attribute_Error. The Data 6608 field of the IDRP ERROR PDU shall report the attribute (type, 6609 length and value). No further processing shall be done, and all 6610 information in the UPDATE PDU shall be discarded. 6612 n) If RDCs are supported and any of the error conditions noted in 6613 7.12.3.3 occur, no further processing of the UPDATE PDU shall be 6614 done, all information in the UPDATE PDU shall be discarded, and 6615 the error code of the NOTIFICATION PDU shall be set to 6616 Misconfigured_RDCs. 6618 o) If a route carried in an UPDATE PDU contains more than a single 6619 instance of a distinguishing path attribute, then the error 6620 subcode shall be set to Malformed_Attribute_List. No further 6621 processing shall be done, and all information in the UPDATE PDU 6622 shall be discarded. 6624 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6626 Note 32: This error condition refers to duplicated attributes 6627 within a single route. It is not an error if a 6628 distinguishing attribute of the same type appears in 6629 several of the routes carried in an UPDATE PDU that 6630 advertises multiple routes. 6632 p) If an UPDATE PDU contains more than one instance of a 6633 non-distinguishing path attribute of the same type, except for 6634 ROUTE_SEPARATOR, the BIS shall send an IDRP ERROR PDU with error 6635 subcode Duplicated_Attributes. The data field of the IDRP ERROR 6636 PDU shall list the type codes of all such duplicated attributes. 6638 q) If the RD_PATH attribute contains an illegal segment type, the 6639 BIS shall send an IDRP ERROR PDU, with error subcode 6640 Illegal_RD_Path_Segment. The data field of the IDRP ERROR PDU 6641 shall reproduce the encoding of the offending segment of the 6642 RD_PATH attribute, as it appeared in the received UPDATE PDU. 6644 7.20.4 IDRP ERROR PDU error handling 6646 If a BIS receives an IDRP ERROR PDU with a correct validation pattern 6647 but which contains an unrecognized error code or error subcode, the 6648 local BIS shall close the connection as described in 7.6.2. 6650 Note 33: Any error (such as unrecognized Error Code or Error 6651 Subcode, or an incorrect Length field in the PDU header) 6652 should be logged locally and brought to the attention of 6653 the administration of the peer. The means to do this are, 6654 however, outside the scope of this protocol. 6656 7.20.5 Hold timer expired error handling 6658 If the FSM for a given BIS-BIS connection is in the ESTABLISHED state 6659 and the local BIS does not receive successive PDUs of types 6660 KEEPALIVE, UPDATE, or RIB REFRESH, within the period specified in the 6661 Hold Time field of the OPEN PDU previously sent to the remote BIS, 6662 then an IDRP ERROR PDU with error code Hold_Timer_Expired shall be 6663 sent to the remote BIS and the FSM for the associated BIS-BIS 6664 connection shall enter the CLOSE-WAIT state. 6666 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6668 7.20.6 KEEPALIVE PDU error handling 6670 The KEEPALIVE PDU consists of only the BISPDU Header. Error 6671 conditions are handled according to 7.20.1. 6673 7.20.7 CEASE PDU error handling 6675 The CEASE PDU consists of only the BISPDU Header. Error conditions 6676 are handled according to 7.20.1 6678 7.20.8 RIB REFRESH PDU error handling 6680 If any of the following error conditions are detected, the BIS shall 6681 issue an IDRP ERROR PDU with the following error indications: 6683 a) Invalid OpCode not in Range 1 to 3: indicate RIB REFRESH error 6684 with error subcode "Invalid OpCode" 6686 b) Receipt of an OpCode 3 (RIB Refresh End) without prior receipt of 6687 OpCode 2 (Rib Refresh Start): indicate FSM Error 6689 c) Receipt of an unsupported RIB-Att in the Rib-Atts variable length 6690 field in the RIB REFRESH PDU for a RIB Refresh Start OpCode: 6691 indicate RIB REFRESH error with error subcode "Unsupported 6692 RIB-Atts" 6694 8. Forwarding process for CLNS 6696 The forwarding process for CLNS operation is driven by the header 6697 information carried in an ISO 8473 NPDU: 6699 a) If the NPDU contains an ISO 8473 complete source route parameter, 6700 then further forwarding of this NPDU shall be handled by the 6701 ISO 8473 protocol, not by the mechanisms defined in this 6702 International Standard. 6704 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6706 b) If the NPDU contains an ISO 8473 partial source route parameter, 6707 the NPDU shall be forwarded on a path to the next system listed 6708 in the partial source route parameter. 6710 c) If the NPDU does not contain an ISO 8473 source route parameter, 6711 the NPDU shall be forwarded on a path to the system listed in the 6712 destination address field of the NPDU. 6714 Having determined the system to which a path is needed, the BIS shall 6715 proceed as follows: 6717 a) If the destination system is located in its own RD, the local BIS 6718 shall proceed as defined in 8.1. 6720 b) If the destination system is located in a different RD, the local 6721 BIS shall perform the following actions: 6723 1) It shall determine the NPDU-Derived Distinguishing Attributes 6724 of the NPDU, according to 8.2. 6726 2) It shall next apply the procedures of 8.3 to determine if the 6727 NPDU-derived Distinguishing Attributes match any of the 6728 FIB-Atts of the Forwarding Information Bases of the local 6729 BIS: 6731 i) If the NPDU-derived Distinguishing Attributes match the 6732 FIB-Att of a local FIB, then the NPDU shall select that 6733 FIB and shall forward the NPDU using the methods of 8.4. 6735 ii) Otherwise, perform the ISO 8473 "Discard PDU Function" 6736 and generate an ER PDU with the parameter value set to 6737 "Unsupported Option not Specified". 6739 If the underlying data protocol permits the modification or 6740 removal of the QOS or Priority parameters of the data PDU, then 6741 the BIS may modify such information appropriately and forward the 6742 data PDU. 6744 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6746 8.1 Forwarding to internal destinations 6748 If the destination address of an incoming NPDU depicts a system 6749 located within the routeing domain of the receiving BIS, then it 6750 shall forward that NPDU to any of the ISs listed in managed object 6751 INTRA-IS. That is, any further forwarding of the NPDU is the 6752 responsibility of the intra-domain routeing protocol. 6754 8.2 Determining the NPDU-derived distinguishing attributes 6756 As the first step in forwarding an NPDU to a destination located in 6757 another routeing domain, the receiving BIS shall determine the 6758 NPDU-derived Distinguishing Attributes of the incoming ISO 8473 NPDU. 6759 This determination shall be based on an examination of the priority 6760 parameter, security parameter, and QOS maintenance parameter in the 6761 NPDU's header: 6763 - The 8473 priority parameter corresponds to the PRIORITY path 6764 attribute. 6766 - The first two bits of the ISO 8473 security parameter are 6767 decoded: 6769 - if they equal '11', then the parameter identifies a globally 6770 unique and unambiguous security level (see ISO 8473, 6771 subclause 7.5.3.3) 6772 - if they equal '01' then the responsible Security Authority is 6773 identified by the NPDU's source NSAP Address 6774 - if they equal '10' then the responsible Security Authority is 6775 identified by the NPDU's destination NSAP Address. 6777 The corresponding NPDU-Derived Distinguishing attribute is then a 6778 SECURITY attribute identifying the same Security Authority. 6780 - The first two bits of the ISO 8473 QoS Maintenance parameter are 6781 decoded: 6783 a) If they equal '01' then the responsible QoS Authority is 6784 indicated by the source NSAP Address, and the NPDU-Derived 6785 Distinguishing attribute is determined using the remaining 6786 octets of the QoS Maintenance parameter and by applying the 6787 rules specified by the QoS Authority and contained in the PIB 6788 for selection of the NPDU-Derived Distinguishing attribute. 6789 If no such rules exist then no NPDU-Derived Distinguishing 6790 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6792 +----------------------------------------------------------------------+ 6793 | | 6794 | +------------------------------------------------------------------+ | 6795 | | Table 4. NPDU-Derived Attribute Set. Some NPDU-derived | | 6796 | | Distinguishing attributes are derived by examining the | | 6797 | | QOS Maintenance Parameter octet for 1 or 0 in the bit | | 6798 | | positions shown below. The symbol "-" indicates that | | 6799 | | the corresponding bit does not enter into the | | 6800 | | determination. | | 6801 | +------------------------------------------------+-----------------+ | 6802 | | QOS Maintenance Parameter | NPDU-Derived | | 6803 | +-----+-----+-----+-----+-----+------+-----+-----+ Attributes | | 6804 | | b[8]| b[7]| b[6]| b[5]| b[4]| b[3] | b[2]| b[1]| | | 6805 | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ | 6806 | | 1 | 1 | - | - | - | 1 | 0 | 0 | Transit Delay | | 6807 | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ | 6808 | | 1 | 1 | - | - | - | 1 | 0 | 1 | Transit Delay | | 6809 | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ | 6810 | | 1 | 1 | - | - | - | 0 | 0 | 0 | Expense | | 6811 | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ | 6812 | | 1 | 1 | - | - | - | 0 | 1 | 0 | Expense | | 6813 | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ | 6814 | | 1 | 1 | - | - | - | 0 | 1 | 1 | Residual Error | | 6815 | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ | 6816 | | 1 | 1 | - | - | - | 1 | 1 | 1 | Residual Error | | 6817 | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ | 6818 | | 6819 +----------------------------------------------------------------------+ 6821 attribute shall be associated with this QoS Maintenance 6822 parameter. 6824 b) If they equal '10' then the responsible QoS Authority is 6825 indicated by the destination NSAP Address, and the 6826 NPDU-Derived Distinguishing attribute is determined using the 6827 remaining octets of the QoS Maintenance parameter and by 6828 applying the rules specified by the QoS Authority and 6829 contained in the PIB for selection of the NPDU-Derived 6830 Distinguishing attribute. If no such rules exist then no 6831 NPDU-Derived Distinguishing attribute shall be associated 6832 with this QoS Maintenance parameter. 6834 c) If they equal '11' then the NPDU-Derived Distinguishing 6835 attribute is as shown in Table 4. 6837 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6839 If examination of the 8473 header shows that no NPDU-Derived 6840 Distinguished Attributes are present, then the NPDU shall be 6841 associated with the Empty Distinguishing Attribute. 6843 8.3 Matching RIB-Att to NPDU-derived distinguishing attributes 6845 Within the BIS, each of its FIB(s) has an unambiguous RIB-Att (see 6846 7.10.1) which is constructed from the set of Distinguishing 6847 Attributes that the local BIS supports. The set of NPDU-derived 6848 Distinguishing Attributes matches a given RIB-Att (which is itself a 6849 set of Distinguishing Attributes) when all of the following 6850 conditions are satisfied: 6852 a) Both sets contain the same number of attributes. 6854 b) Each instance of a type-specific attribute in the NPDU-derived 6855 Distinguishing Attributes must have an equivalent instance in the 6856 FIB-Att. The type-specific path attributes supported by IDRP 6857 are: 6859 - Transit delay 6860 - Residual error 6861 - Expense 6862 - Priority 6864 c) Each instance of a type-value specific attribute in the 6865 NPDU-Derived Distinguishing Attributes has a corresponding 6866 instance in an FIB's RIB-Att, and, depending on the type of the 6867 NPDU-Derived Distinguishing Attribute: 6869 LOCALLY DEFINED QOS: The NSAP Address prefixes and QoS Values are 6870 identical. 6872 SECURITY: The same Security Authority is identified in each case. 6874 Provided that such a RIB-Att can be found then the contents is 6875 inspected to find an entry such that: 6877 a) the NLRI contains the NPDU's destination NSAP Address, or an NSAP 6878 Address prefix which is a prefix of the NPDU's destination NSAP 6879 Address; 6881 b) the subnetwork hop's priority, if present, is less than or equal 6882 to the NPDU's priority 6883 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6885 c) with reference to the applicable Security Policy rules contained 6886 in the PIB, the subnetwork hop provides sufficient protection for 6887 the NPDU, and the NPDU is permitted to use the subnetwork hop. 6889 d) when a type specific NPDU-Derived Distinguishing Attribute has 6890 been selected by a rule specified by a QoS Authority from a 6891 source or destination specific QoS Maintenance parameter, then an 6892 additional matching rule may also be specified that determines 6893 whether the value of the QoS metric is acceptable. 6895 If such a RIB-Att or entry cannot be found, then perform the 6896 following procedure in the order indicated, terminating when either a 6897 match is found or all three steps have been executed: 6899 a) if the NPDU's security parameter does not express a requirement 6900 for protection, the SECURITY attribute may be removed from the 6901 NPDU- Derived Distinguishing attributes, and the above procedures 6902 repeated in order to find a match. 6904 b) the PRIORITY attribute may be removed from the NPDU-Derived 6905 Distinguishing attributes, and the above procedures repeated in 6906 order to find a match. 6908 c) LOCALLY DEFINED QOS, EXPENSE, TRANSIT DELAY, or RESIDUAL ERROR 6909 (only one of which can be present in a valid set of 6910 distinguishing attributes) may be removed from the NPDU-Derived 6911 Distinguishing attributes, and the above procedures repeated to 6912 find a match. 6914 Note 34: If no match was found in the first two steps, the third 6915 step will reduce the NPDU-Derived distinguishing 6916 attributes to either an empty set or a single security 6917 attribute. In the first case, the empty set will 6918 match the Empty RIB-Att; in the second case, there can 6919 be either a match or a mismatch with the security 6920 parameter. 6922 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6924 8.4 Forwarding to external destinations 6926 If the destination address of the incoming NPDU depicts a system 6927 located in a different routeing domain from the receiving BIS, then 6928 the receiving BIS shall use the FIB identified by the FIB-Att that 6929 matches the NDPU-derived Distinguishing Attributes of the incoming 6930 NPDU. The incoming NPDU shall be forwarded based on the longest 6931 address prefix that matches (as in 7.1.2.2) the destination NSAP 6932 address of the incoming NPDU, as follows: 6934 a) If the entry in the inter-domain FIB that corresponds to the 6935 destination address of the incoming NPDU contains a NEXT_HOP 6936 entry that identifies a BIS which is located on at least one 6937 common subnetwork with the local BIS, then the NPDU shall be 6938 forwarded directly to the BIS indicated in the NEXT_HOP entry. 6940 b) If the entry in the inter-domain FIB that corresponds to the 6941 destination address of the incoming NPDU contains a NEXT_HOP 6942 entry that identifies a BIS which is not located on at least one 6943 common subnetwork with the local BIS, then the local BIS has the 6944 following options: 6946 1) Encapsulate the NPDU: The local BIS may encapsulate the 6947 NPDU, using its own NET as the source address and the NET of 6948 the next-hop BIS as the destination address. Copy the 6949 following, when present in the header of the encapsulated 6950 (inner) NPDU, to the header of the encapsulating (outer) 6951 NPDU: QOS Maintenance parameter, Segmentation Permitted 6952 Flag, Error Report Flag, and PDU Lifetime field. When the 6953 inner NPDU is decapsulated, replace its PDU Lifetime field 6954 with PDU Lifetime field of the outer NPDU. The encapsulated 6955 NPDU shall then be handed over to the intra-domain routeing 6956 protocol. 6958 Note 35: It is a local responsibility to insure that the 6959 NPDU is encapsulated appropriately for the RD's 6960 intra-domain protocol. Since this International 6961 Standard does not mandate the use of a specific 6962 intra-domain protocol, encapsulation details for 6963 specific intra-domain protocols are outside its 6964 scope. 6966 2) Use Paths Provided by the Intra-domain Routeing Protocol: 6967 The local BIS may query the intra-domain FIB to ascertain if 6968 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 6970 the intra-domain protocol is aware of a route to the 6971 destination system. 6973 Note 36: For example, if ISO/IEC 10589 were used as the 6974 intra-domain routeing protocol, it would be able to 6975 calculate path segments through the RD for systems 6976 contained in its "reachable address prefixes". 6978 If there is an intra-domain route that supports the QOS 6979 Maintenance parameter of the NPDU and will deliver the NPDU 6980 to the appropriate next-hop BIS, then the NPDU may be 6981 forwarded along this route. 6983 Note 37: This case makes use of the intra-domain protocol's 6984 knowledge of suitable paths through the local RD 6985 which support the specified QOS parameter. It does 6986 not require encapsulation of the NPDU. 6988 Details of the mapping between the QOS parameters 6989 of used by a given intra-domain protocol and the 6990 QOS Maintenance parameter of the NPDU must be 6991 determined by the intra-domain routeing protocol; 6992 this mapping is not within the scope of IDRP. 6994 9. Interface to ISO 8473 6996 For the purposes of its interface to ISO 8473, a BIS shall be 6997 regarded as being comprised of a co-resident ES and IS. The protocol 6998 described in this International Standard, although still within the 6999 Network layer, shall access the service provided by ISO 8473 through 7000 an NSAP in the ES part of the BIS. Hence, a BIS's NET shall, for the 7001 purposes of communication using ISO 8473, be regarded as NSAP 7002 address. 7004 The protocol described in this International Standard interfaces at 7005 its lower boundary to ISO 8473 using the ISO 8473 primitives shown in 7006 Table 5. 7008 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7010 +-------------------------------------------------------------------+ 7011 | Table 5. IDRP-CL Primitives | 7012 +-------------------------+-----------------------------------------+ 7013 | Primitive | Parameters | 7014 +-------------------------+-----------------------------------------+ 7015 | | | 7016 +-------------------------+-----------------------------------------+ 7017 | N-UNITDATA Request | Destination NSAP Address | 7018 | | Source NSAP Address | 7019 | | QOS | 7020 | | Userdata | 7021 +-------------------------+-----------------------------------------+ 7022 | | | 7023 +-------------------------+-----------------------------------------+ 7024 | N-UNITDATA Indication | Destination NSAP Address | 7025 | | Source NSAP Address | 7026 | | QOS | 7027 | | Userdata | 7028 +-------------------------+-----------------------------------------+ 7029 | | | 7030 +-------------------------+-----------------------------------------+ 7032 The parameters associated with the N-UNITDATA request primitive are: 7034 - Destination NSAP Address is the NET of the BIS to which this 7035 BISPDU is being sent (that is, the remote BIS) 7037 - Source NSAP Address is the NET the BIS that is sending this 7038 BISPDU (that is, the local BIS) 7040 - QOS is the quality of service parameter for this BIS-BIS 7041 connection 7043 - Userdata is an ordered sequence of octets which comprise the 7044 BISPDU to be sent to the remote BIS 7046 The parameters associated with the N-UNITDATA indication primitive 7047 are: 7049 - Destination NSAP Address is the NET of the BIS to which this 7050 BISPDU is being sent 7052 - Source NSAP Address is the NET the BIS that is sending this 7053 BISPDU (that is, the remote BIS) 7054 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7056 - QOS is the quality of service parameter for this BIS-BIS 7057 connection 7059 - Userdata is an ordered sequence of octets which comprise the 7060 BISPDU being delivered to the local BIS 7062 9.1 Use of network layer security protocol over ISO 8473. 7064 The network layer security protocol described in ISO/IEC 11577 may be 7065 used over the ISO 8473 protocol to provide security protection of 7066 IDRP exchanges. In this case, the NLSP-UNITDATA request and 7067 indication service primitives are used instead of the N-UNITDATA 7068 service primitives as described in clause 9. The use of BN-UNITDATA 7069 notional service primitives by CD 11577 is then mapped onto the use 7070 by ISO 8473 of the equivalent N-UNITDATA primitives. 7072 IDRP may control the protection requirements through the use of the 7073 NLSP-UNITDATA request and indication primitives or the NLSP QOS 7074 Protection parameter; or protection may be imposed by NLSP through 7075 the use of security association management. 7077 10. Constants 7079 This constants used by the protocol defined in this International 7080 Standard are enumerated in Table 6. 7082 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7084 +----------------------------------------------------------------------+ 7085 | Table 6. Architectural Constants of IDRP | 7086 +---------------------------+--------------+---------------------------+ 7087 | Name of Constant | Value | Description | 7088 +---------------------------+--------------+---------------------------+ 7089 | Inter-domain Routeing | X'85' | The SPI for the protocol | 7090 | Protocol Identifier | | described in this | 7091 | | | International Standard | 7092 +---------------------------+--------------+---------------------------+ 7093 | MinBISPDULength | 30 | The size in octets of the | 7094 | | | smallest allowable | 7095 | | | BISPDU. | 7096 +---------------------------+--------------+---------------------------+ 7097 | MinRDOriginationInterval | 15 min | The minimum time between | 7098 | | | successive UPDATE PDUs | 7099 | | | advertising routeing | 7100 | | | information about the | 7101 | | | local RD | 7102 +---------------------------+--------------+---------------------------+ 7103 | Jitter | 0,25 | The factor used to | 7104 | | | compute jitter according | 7105 | | | to 7.17.3.3. | 7106 +---------------------------+--------------+---------------------------+ 7107 | MaxCPUOverloadPeriod | 1 hr | Maximum time in which a | 7108 | | | BIS can remain | 7109 | | | CPU-overloaded before | 7110 | | | terminating its BIS-BIS | 7111 | | | connections. | 7112 +---------------------------+--------------+---------------------------+ 7113 | CloseWaitDelay | 150 s | The time that a FSM | 7114 | | | remains in CLOSE-WAIT | 7115 | | | state before entering the | 7116 | | | CLOSED state. | 7117 +---------------------------+--------------+---------------------------+ 7118 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7120 11. System management and GDMO definitions 7122 The operation of the inter-domain routeing functions in a BIS may be 7123 monitored and controlled using System Management. This clause 7124 contains management specification for IDRP, expressed in the GDMO 7125 notation defined in ISO/IEC 10165-4. The naming and containment 7126 hierarchy is shown in Figure 9. 7128 11.1 Name binding 7130 idrpConfig-networkEntity NAME BINDING 7132 SUBORDINATE OBJECT CLASS idrpConfig AND SUBCLASSES; 7133 NAMED BY SUPERIOR OBJECT CLASS "ISO/IEC 10733 : 19xx": 7134 networkEntity; 7135 WITH ATTRIBUTE idrpConfigId; 7136 CREATE WITH-AUTOMATIC-INSTANCE-NAMING; 7137 DELETE ONLY-IF-NO-CONTAINED-OBJECTS; 7138 REGISTERED AS { IDRP.nboi idrpConfig-networkEntity(1) }; 7140 adjacentBIS-idrpConfig NAME BINDING 7142 SUBORDINATE OBJECT CLASS adjacentBIS AND SUBCLASSES; 7143 NAMED BY SUPERIOR OBJECT CLASS idrpConfig AND SUBCLASSES; 7144 WITH ATTRIBUTE bisNet; 7145 BEHAVIOUR adjacentBIS-idrpConfig-B BEHAVIOUR 7147 DEFINED AS This name binding attribute identifies a BIS to BIS 7148 connection information block. One of these blocks of data should 7149 exist per remote BIS that this local BIS exchanges BISPDUs with.;; 7151 REGISTERED AS { IDRP.nboi adjacentBIS-idrpConfig(2) }; 7152 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7154 +----------------------------------------------------------------------+ 7155 | | 7156 | contain | 7157 | | 7158 +----------------------------------------------------------------------+ 7159 Figure 9. IDRP Naming and Containment Hierarchy 7161 11.2 Managed objects for IDRP 7163 idrpConfig MANAGED OBJECT CLASS 7165 DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992": top; 7166 CHARACTERIZED BY idrpConfigPkg-P PACKAGE; 7167 REGISTERED AS { IDRP.moi idrpConfig (1)}; 7169 adjacentBIS MANAGED OBJECT CLASS 7171 DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2: 1992": top; 7172 CHARACTERIZED BY adjacentBISPkg-P PACKAGE; 7173 REGISTERED AS { IDRP.moi adjacentBIS(2) }; 7175 11.3 Packages for IDRP 7177 idrpConfigPkg-P PACKAGE 7179 BEHAVIOUR iDRPBasicImportedAlarmNotifications-B 7181 BEHAVIOUR DEFINED AS %Imports the communicationsAlarm notification 7182 from ISO/IEC 10165-2. It is used to report the following protocol 7183 events: 7185 errorBISPDUsent: Generated when a BISPDU is received with an 7186 error in its format. The significance sub-parameter of each item 7187 of additionalInformation shall be set to the value `False' (i.e., 7188 not significant) so that a managing system receiving the event 7189 report will be less likely to reject it. The probableCause shall 7190 be set to NLM.communicationsProtocolError. The perceivedSeverity 7191 shall be set to 'Minor'. A subsequent communicationsAlarm with a 7192 perceivedSeverity value of 'Cleared' shall not be generated. No 7193 other fields or parameters shall be used, with the exception of 7194 further parameters in the AdditionalInformation field, as follows: 7196 a) RemoteBISNET for BIS-BIS connection--using the 7197 notificationRemoteBISNET parameter 7198 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7200 b) BISPDU error code (see 6.4 and 7.20)--this reports the error 7201 code that will be sent in the ERROR PDU using the parameter 7202 "notificationBISPDUerrorcode". 7203 c) BIS error subcode (see 6.4 and 7.20)--this reports the subcode 7204 that will be sent using the parameter 7205 "notificationBISerrorsubcode". 7206 d) BISPDU error information (see 6.4 and 7.20)--this reports the 7207 data from the received BISPDU that will be used to diagnose 7208 the problem for the Notification. The parameter 7209 "notificationBISPDUerrorinfo" will be used to report this 7210 information. 7212 OpenBISpduRDCError: generated when an OPEN BISPDU is received 7213 from another BIS in the same routeing domain, and the remote BIS 7214 is not a member of identically the same confederations as the 7215 local BIS. The significance sub-parameter of each item of 7216 additionalInformation shall be set to the value 'False' (i.e., not 7217 significant) so that a managing system receiving the event report 7218 will be less likely to reject it. The probableCause shall be set 7219 to NLM.communicationsProtocolError. The perceivedSeverity shall 7220 be set to 'Minor'. A subsequent communicationsAlarm with a 7221 perceivedSeverity value of 'Cleared' shall not be generated. No 7222 other fields or parameters shall be used, with the exception of 7223 further parameters in the AdditionalInformation field, as follows: 7225 a) Remote BIS NET for this BIS-BIS connection--using the 7226 "notificationRemoteBISNET" parameter. 7227 b) Remote BIS Routeing Domain Confederation (RDC) information 7228 using the "notificationRemoteRDCConfig" parameter. 7229 c) Local BIS Routeing Domain Confederation (RDC) information 7230 using the "notificationLocalRDCConfig" parameter. 7232 errorBISPDUconnectionclose: generated when an ERROR PDU has been 7233 received from a remote BIS. The significance sub-parameter of 7234 each item of additionalInformation shall be set to the value 7235 'False' (i.e., not significant) so that a managing system 7236 receiving the event report will be less likely to reject it. The 7237 probableCause shall be set to NLM.communicationsProtocolError. 7238 The perceivedSeverity shall be set to 'Minor'. A subsequent 7239 communicationsAlarm with a perceivedSeverity value of 'Cleared' 7240 shall not be generated. No other fields or parameters shall be 7241 used, with the exception of further parameters in the 7242 AdditionalInformation field, as follows: 7244 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7246 a) RemoteBISNET for BIS-BIS connection--using the 7247 "notificationRemoteBISNET" parameter 7248 b) BISPDU error code (see 6.4 and 7.20)--this reports the error 7249 code that will be sent in the ERROR PDU using the parameter 7250 "notificationBISPDUerrorcode". 7251 c) BIS error subcode (see 6.4 and 7.20)--this reports the subcode 7252 that will be sent using the parameter 7253 "notificationBISerrorsubcode". 7254 d) BISPDU error information (see 6.4 and 7.20)--this reports the 7255 data from the received BISPDU that will be used to diagnose 7256 the problem for the Notification. The parameter 7257 "notificationBISPDUerrorinfo" will be used to report this 7258 information. 7260 CorruptAdjRIBIn: generated when the local method of checking the 7261 Adj-RIB-In has found an error. All Adj-RIBs-In are being purged. 7262 The significance sub-parameter of each item of 7263 additionalInformation shall be set to the value 'False' (i.e., not 7264 significant) so that a managing system receiving the event report 7265 will be less likely to reject it. The probableCause shall be set 7266 to NLM.communicationsProtocolError. The perceivedSeverity shall 7267 be set to 'Minor'. A subsequent communicationsAlarm with a 7268 perceivedSeverity value of 'Cleared' shall not be generated. No 7269 other fields or parameters shall be used, with the exception of 7270 further parameters in the AdditionalInformation field, as follows: 7272 a) The number of integrity check failures detected in the 7273 parameter "notificationtRIBIntegrityFailure" 7274 b) The remote BIS associated with this Adjacent RIB in the 7275 parameter "notificationRemoteBISNET". 7277 PacketBomb: generated when the local BIS received a BISPDU other 7278 than an OPEN PDU, from an unknown BIS. The Source-BIS-NET is 7279 reported in the AdditionalInformation field using the 7280 "notificationSourceBIS-NET parameter. The significance 7281 sub-parameter of each item of additionalInformation shall be set 7282 to the value 'False' (i.e., not significant) so that a managing 7283 system receiving the event report will be less likely to reject 7284 it. The probableCause shall be set to 7285 NLM.communicationsProtocolError. The perceivedSeverity shall be 7286 set to 'Minor'. A subsequent communicationsAlarm with a 7287 perceivedSeverity value of 'Cleared' shall not be generated. No 7288 other fields or parameters shall be used, with the exception of 7289 further parameters in the AdditionalInformation field, as follows. 7290 These parameters are created from the OPEN PDU values: 7292 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7294 a) notificationSourceBISNET--NET of remote BIS sending packet 7295 bomb 7296 b) notificationSourceBISrdi--RDI of remote BIS sending packet 7297 bomb 7298 c) notificationSourceBISrdc--RDC information for remote BIS 7299 sending packet bomb 7301 connectRequestBISUnknown: generated when the local BIS has 7302 received an OPEN BISPDU from an unknown BIS. The significance 7303 sub-parameter of each item of additionalInformation shall be set 7304 to the value 'False' (i.e., not significant) so that a managing 7305 system receiving the event report will be less likely to reject 7306 it. The probableCause shall be set to 7307 NLM.communicationsProtocolError. The perceivedSeverity shall be 7308 set to 'Minor'. A subsequent communicationsAlarm with a 7309 perceivedSeverity value of 'Cleared' shall not be generated. No 7310 other fields or parameters shall be used, with the exception of 7311 further parameters in the AdditionalInformation field, as follows. 7312 These parameters are created from the OPEN PDU values: 7314 a) notificationSourceBISNET--NET of remote BIS sending OPEN PDU 7315 b) notificationSourceBISrdi--RDI of remote BIS sending OPEN PDU 7316 c) notificationSourceBISrdc--RDC information for remote BIS 7317 sending OPEN PDU 7319 connectionRequested: generated when the local BIS has received an 7320 OPEN BISPDU from an adjacent BIS, the FSM for the for the BIS-BIS 7321 connection is in the CLOSED state, and the managed object 7322 ListenForOpen has the value TRUE. The significance sub-parameter 7323 of each item of additionalInformation shall be set to the value 7324 'False' (i.e., not significant) so that a managing system 7325 receiving the event report will be less likely to reject it. The 7326 probableCause shall be set to NLM.communicationsProtocolError. 7327 The perceivedSeverity shall be set to 'Minor'. A subsequent 7328 communicationsAlarm with a perceivedSeverity value of 'Cleared' 7329 shall not be generated. No other fields or parameters shall be 7330 used, with the exception of further parameters in the 7331 AdditionalInformation field, as follows. These parameters are 7332 created from the OPEN PDU values: 7334 a) notificationSourceBISNET--NET of remote BIS sending OPEN PDU 7335 b) notificationSourceBISNET--NET of remote BIS sending OPEN PDU 7336 c) notificationSourceBISrdi--RDI of remote BIS sending OPEN PDU 7337 d) notificationSourceBISrdc--RDC information for remote BIS 7338 sending OPEN PDU 7339 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7341 EnterFSMStateMachine: generated when the IDRP FSM state machine 7342 used to communicate with another BIS is started. The 7343 RemoteBis-NET is reported in the additionalInformation field using 7344 the "notificationRemoteBISNET" parameter. The significance 7345 sub-parameter of each item of additionalInformation shall be set 7346 to the value 'False' (i.e., not significant) so that a managing 7347 system receiving the event report will be less likely to reject 7348 it. The probableCause shall be set to 7349 NLM.communicationsProtocolError. The perceivedSeverity shall be 7350 set to 'Minor'. A subsequent communicationsAlarm with a 7351 perceivedSeverity value of 'Cleared' shall not be generated. No 7352 other fields or parameters shall be used.%;, 7354 iDRPBasicImportedInfoNotifications-B 7355 BEHAVIOUR DEFINED AS %Imports the communicationsInformation 7356 notification from ISO/IEC 10165-5. It is used to report the 7357 following protocol events: 7359 EnterFSMState: generated when a BIS starts the IDRP FSM state 7360 machine to establish a connection with a remote BIS. The 7361 RemoteBis-NET is reported in the AdditionalInformation field using 7362 the "notificationRemoteBISNET" parameter. The significant 7363 subparameter of each item of AdditionalInformation shall be set to 7364 "false" (that is, not significant) so that a managing system 7365 receiving the event report will be less likely to reject it. 7367 FSMStateChange: generated when the IDRP FSM used to communicate 7368 with another BIS transitions from one state to another. The 7369 RemoteBis-NET is reported in the AdditionalInformation field using 7370 the "notificationRemoteBISNET" parameter. The significant 7371 sub-parameter of each item ofAdditionalInformation shall be set to 7372 "false" (that is, not significant) so that a managing system 7373 receiving the event report will be less likely to reject it.%;; 7375 ATTRIBUTES 7376 authenticationTypeCode 7377 INITIAL VALUE DERIVATION RULE 7378 supplyOnCreate-B 7379 GET, 7380 capacity GET, 7381 externalBISNeighbor GET-REPLACE, 7382 holdTime GET, 7383 idrpConfigID 7384 INITIAL VALUE DERIVATION RULE 7385 supplyOnCreate-B 7386 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7388 GET, 7389 internalBIS GET-REPLACE, 7390 internalSystems GET-REPLACE, 7391 intraIS GET-REPLACE, 7392 localRDI GET-REPLACE, 7393 localSNPA GET-REPLACE, 7394 locExpense GET, 7395 maxCPUOverloadTimer GET, 7396 maxPDULocal GET, 7397 maxRIBIntegrityCheck GET, 7398 maxRIBIntegrityTimer GET, 7399 minRDOriginationTimer GET, 7400 multiExit GET-REPLACE, 7401 priority GET, 7402 rdcConfig GET-REPLACE, 7403 rdLRE GET, 7404 rdTransitDelay GET, 7405 retransmissionTime GET, 7406 ribAttsSet GET, 7407 routeServer GET-REPLACE, 7408 version GET; 7409 ACTIONS 7410 "GMI":activate, 7411 "GMI":deactivate; 7412 NOTIFICATIONS "REC X.721 | ISO/IEC 10165-2:1992": 7413 communicationsAlarm 7414 notificationBISerrorssubcode 7415 notificationBISPDUerrorcode 7416 notificationBISPDUerrorinfo 7417 notificationLocalRDCconfig 7418 notificationRIBIntegrityFailure 7419 notificationRemoteBISNET 7420 notificationRemoteRDCconfig 7421 notificationSourceBISNET 7422 notificationSourceBISrdc 7423 notificationSourceBISrdi, 7424 "REC X.723 | ISO/IEC 10165-5: 1992": communicationsInformation 7425 notificationRemoteBISNET; 7426 REGISTERED AS {IDRP.poi idrpConfigPkg-P (1)}; 7428 adjacentBISPkg-P PACKAGE 7430 ATTRIBUTES 7431 bisNegotiatedVersion GET, 7432 bisNet GET, 7433 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7435 bisPeerSNPAs GET, 7436 bisRDC GET 7437 REPLACE-WITH-DEFAULT 7438 DEFAULT VALUE IDRP.nullRDC 7439 GET-REPLACE, 7440 bisRDI GET 7441 REPLACE-WITH-DEFAULT 7442 DEFAULT VALUE IDRP.nullRDI 7443 GET-REPLACE, 7444 closeWaitDelayTimer GET, 7445 holdTimer GET, 7446 keepAlivesSinceLastUpdate GET, 7447 keepAliveTimer GET, 7448 lastAckRecv GET 7449 INITIAL VALUE IDRP.zero, 7450 lastAckSent GET 7451 INITIAL VALUE IDRP.zero, 7452 lastSeqNoRecv GET 7453 INITIAL VALUE IDRP.zero, 7454 lastPriorSeqNo GET-REPLACE, 7455 lastSeqNoSent GET 7456 INITIAL VALUE IDRP.zero, 7457 listenForOPEN GET, 7458 maxPDUPeer GET, 7459 minRouteAdvertisementInterval GET, 7460 minRouteAdvertisementTimer GET, 7461 outstandingPDUs GET, 7462 state GET, 7463 totalBISPDUsIn GET, 7464 totalBISPDUsOut GET, 7465 updatesIn GET, 7466 updatesOut GET; 7467 ATTRIBUTE GROUPS 7468 "GMI":counters 7469 updatesIn 7470 updatesOut 7471 totalBISPDUsIn 7472 totalBISPDUsOut 7473 keepAlivesSinceLastUpdate, 7474 "DMI":state 7475 state; 7476 ACTIONS 7477 "GMI":activate, 7478 "GMI":deactivate; 7479 REGISTERED AS { IDRP.poi adjacentBISPkg-P (2) } 7480 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7482 11.4 Attribute definitions 7484 authenticationTypeCode ATTRIBUTE 7486 WITH ATTRIBUTE SYNTAX IDRP.AuthenticationCode; 7487 MATCHES FOR EQUALITY, ORDERING; 7488 BEHAVIOUR authenticationTypeCode-B 7489 BEHAVIOUR DEFINED AS Indication of which authentication mechanism 7490 will be used;; 7491 REGISTERED AS { IDRP.atoi authenticationTypeCode(1) }; 7493 bisNegotiatedVersion ATTRIBUTE 7495 WITH ATTRIBUTE SYNTAX IDRP.BisNegotiatedVersion; 7496 MATCHES FOR EQUALITY, ORDERING; 7497 BEHAVIOUR bisNegotiatedVersion-B 7498 BEHAVIOUR DEFINED AS The negotiated version of IDRP protocol this 7499 BIS to BIS connection is using.;; 7500 REGISTERED AS { IDRP.atoi bisNegotiatedVersion(2) }; 7502 bisNet ATTRIBUTE 7504 WITH ATTRIBUTE SYNTAX IDRP.BisNet; 7505 MATCHES FOR EQUALITY; 7506 BEHAVIOUR bisNet-B 7507 BEHAVIOUR DEFINED AS The NET of the remote BIS of this BIS to BIS 7508 connection.;; 7509 REGISTERED AS { IDRP.atoi bisNet(3) }; 7511 bisPeerSNPAs ATTRIBUTE 7513 WITH ATTRIBUTE SYNTAX IDRP.BisPeersSNPAs; 7514 MATCHES FOR EQUALITY; 7515 BEHAVIOUR bisPeerSNPAs-B 7516 BEHAVIOUR DEFINED AS The SNPAs announced by the remote BIS of this 7517 BIS to BIS connection.;; 7518 REGISTERED AS { IDRP.atoi bisPeerSNPAs(4) }; 7520 bisRDC ATTRIBUTE 7522 WITH ATTRIBUTE SYNTAX IDRP.Rdcgroup; 7523 MATCHES FOR EQUALITY; 7524 BEHAVIOUR bisRDC-B 7525 BEHAVIOUR DEFINED AS The RDCs the remote BIS belong to, as reported 7526 in the OPEN PDU received from the remote BIS;; 7527 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7529 REGISTERED AS { IDRP.atoi bisRDC(5) }; 7531 bisRDI ATTRIBUTE 7533 WITH ATTRIBUTE SYNTAX IDRP.Rdi; 7534 MATCHES FOR EQUALITY; 7535 BEHAVIOUR bisRDI-B 7536 BEHAVIOUR DEFINED AS The RDI of the remote BIS participating in 7537 this BIS-BIS connection.;; 7538 REGISTERED AS { IDRP.atoi bisRDI(6) }; 7540 capacity ATTRIBUTE 7542 WITH ATTRIBUTE SYNTAX IDRP.Capacity; 7543 MATCHES FOR EQUALITY, ORDERING; 7544 BEHAVIOUR capacity-B 7545 BEHAVIOUR DEFINED AS The traffic carrying capacity of this Routeing 7546 Domain.;; 7547 REGISTERED AS { IDRP.atoi capacity(7) }; 7549 closeWaitDelayTimer ATTRIBUTE 7551 DERIVED FROM "GMI":timer; 7552 BEHAVIOUR closeWaitDelayTimer-B 7553 BEHAVIOUR DEFINED AS The timer that measures in seconds the time 7554 that has elapsed since the BIS FSM entered the CLOSE-WAIT state. 7555 Upon timer expiration, the BIS FSM will enter the CLOSED state;; 7556 REGISTERED AS { IDRP.atoi closeWaitDelayTimer(8) }; 7558 externalBISNeighbor ATTRIBUTE 7560 WITH ATTRIBUTE SYNTAX IDRP.BISGroup; 7561 MATCHES FOR EQUALITY; 7562 BEHAVIOUR externalBISNeighbor-B 7563 BEHAVIOUR DEFINED AS The set of NETs which identify the BISs in 7564 adjacent routeing domain that are reachable via a single subnetwork 7565 hop.;; 7566 REGISTERED AS { IDRP.atoi externalBISNeighbor(9) }; 7568 holdTime ATTRIBUTE 7570 WITH ATTRIBUTE SYNTAX IDRP.Holdtime; 7571 MATCHES FOR EQUALITY, ORDERING; 7572 BEHAVIOUR holdTime-B 7573 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7575 BEHAVIOUR DEFINED AS The maximum number of seconds that may elapse 7576 between the receipt of two successive BISPDUs from the adjacent BIS 7577 of any of the following types: KEEPALIVE, UPDATE, RIB CHECKSUM 7578 PDUs or RIB REFRESH PDUs;; 7580 REGISTERED AS { IDRP.atoi holdTime(10) }; 7582 holdTimer ATTRIBUTE 7584 DERIVED FROM "GMI":timer; 7585 BEHAVIOUR holdTimer-B 7586 BEHAVIOUR DEFINED AS The timer that measures in seconds the time 7587 that has elapsed since the local BIS's most recent reception from 7588 the peer BIS of any of the following types of BISPDUs: KEEPALIVE, 7589 UPDATE, RIB REFRESH;; 7590 REGISTERED AS { IDRP.atoi holdTimer(11) }; 7592 idrpConfigID ATTRIBUTE 7594 WITH ATTRIBUTE SYNTAX IDRP.NetworkEntityTitle; 7595 MATCHES FOR EQUALITY; 7596 BEHAVIOUR idrpConfigID-B 7597 BEHAVIOUR DEFINED AS The NET of the local BIS.;; 7598 REGISTERED AS { IDRP.atoi idrpConfigID(50) }; 7600 internalBIS ATTRIBUTE 7602 WITH ATTRIBUTE SYNTAX IDRP.BISGroup; 7603 MATCHES FOR EQUALITY; 7604 BEHAVIOUR internalBIS-B 7605 BEHAVIOUR DEFINED AS The set of NETs which identify the BISs in 7606 this routeing domain;; 7607 REGISTERED AS { IDRP.atoi internalBIS(12) }; 7609 internalSystems ATTRIBUTE 7611 WITH ATTRIBUTE SYNTAX IDRP.SystemIdGroup; 7612 MATCHES FOR EQUALITY; 7613 BEHAVIOUR internalSystems-B 7614 BEHAVIOUR DEFINED AS The set of NET and NSAP prefixes that identify 7615 the systems in this routeing domain for which the BIS constructs 7616 this routeing domain from which the BIS constructs network layer 7617 reachability information;; 7618 REGISTERED AS { IDRP.atoi internalSystems(13) }; 7619 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7621 intraIS ATTRIBUTE 7623 WITH ATTRIBUTE SYNTAX IDRP.BISGroup; 7624 MATCHES FOR EQUALITY; 7625 BEHAVIOUR intraIS-B 7626 BEHAVIOUR DEFINED AS The set of NETs of the ISs to which the local 7627 BIS may deliver an inbound NPDU whose destination lies within the 7628 BIS's routeing domain. These ISs must be located on the same 7629 common subnetwork as this local BIS, and must be capable of 7630 delivering NPDUs to destinations that are located within the local 7631 BIS's routeing domain.;; 7632 REGISTERED AS { IDRP.atoi intraIS(14) }; 7634 keepAlivesSinceLastUpdate ATTRIBUTE 7636 DERIVED FROM "GMI":nonWrapping64BitCounter; 7637 BEHAVIOUR keepAlivesSinceLastUpdate-B 7638 BEHAVIOUR DEFINED AS The number of KEEPALIVE BISPDUS received by 7639 this BIS from the remote BIS since this last UPDATE BISPDU.;; 7640 REGISTERED AS { IDRP.atoi keepAlivesSinceLastUpdate(15) }; 7642 keepAliveTimer ATTRIBUTE 7644 DERIVED FROM "GMI":timer; 7645 BEHAVIOUR keepAliveTimer-B 7646 BEHAVIOUR DEFINED AS The timer that measures in seconds the time 7647 that has elapsed since the previous KEEPALIVE PDU from the adjacent 7648 BIS was received by the local BIS. Upon its expiration, the BIS 7649 will send a BISPDU to its peer BIS;; 7650 REGISTERED AS { IDRP.atoi keepAliveTimer(16) }; 7652 lastAckRecv ATTRIBUTE 7654 WITH ATTRIBUTE SYNTAX IDRP.Integer; 7655 MATCHES FOR EQUALITY, ORDERING; 7656 BEHAVIOUR lastAckRecv-B 7657 BEHAVIOUR DEFINED AS The number of the last ack received from the 7658 remote BIS by this local BIS on this BIS to BIS connection.;; 7659 REGISTERED AS { IDRP.atoi lastAckRecv(17) }; 7661 lastAckSent ATTRIBUTE 7663 WITH ATTRIBUTE SYNTAX IDRP.Integer; 7664 MATCHES FOR EQUALITY, ORDERING; 7665 BEHAVIOUR lastAckSent-B 7666 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7668 BEHAVIOUR DEFINED AS The number of the last ack sent to the remote 7669 BIS from this local BIS on this BIS to BIS connection.;; 7670 REGISTERED AS { IDRP.atoi lastAckSent(18) }; 7672 lastSeqNoRecv ATTRIBUTE 7674 WITH ATTRIBUTE SYNTAX IDRP.Integer; 7675 MATCHES FOR EQUALITY, ORDERING; 7676 BEHAVIOUR lastSeqNoRecv-B 7677 BEHAVIOUR DEFINED AS The last sequence number received from the 7678 remote BIS by this local BIS on this BIS to BIS connection.;; 7679 REGISTERED AS { IDRP.atoi lastSeqNoRecv(19) }; 7681 lastPriorSeqNo ATTRIBUTE 7683 WITH ATTRIBUTE SYNTAX IDRP.Integer; 7684 MATCHES FOR EQUALITY, ORDERING; 7685 BEHAVIOUR lastPriorSeqNo-B 7686 BEHAVIOUR DEFINED AS The last sequence number sent to the remote 7687 BIS immediately before the local BIS enters the CLOSED state;; 7688 REGISTERED AS { IDRP.atoi lastPriorSeqNo(49) }; 7690 lastSeqNoSent ATTRIBUTE 7692 WITH ATTRIBUTE SYNTAX IDRP.Integer; 7693 MATCHES FOR EQUALITY, ORDERING; 7694 BEHAVIOUR lastSeqNoSent-B 7695 BEHAVIOUR DEFINED AS The last sequence number sent to the remote 7696 BIS from this local BIS on this BIS to BIS connection.;; 7697 REGISTERED AS { IDRP.atoi lastSeqNoSent(20) }; 7699 listenForOPEN ATTRIBUTE 7701 WITH ATTRIBUTE SYNTAX IDRP.Boolean; 7702 MATCHES FOR EQUALITY; 7703 BEHAVIOUR listenForOPEN-B 7704 BEHAVIOUR DEFINED AS The boolean value determines how the Finite 7705 State machnine will react to reception of an OPEN PDU while it is 7706 in the CLOSED state;; 7707 REGISTERED AS { IDRP.atoi listenForOPEN(21) }; 7709 localRDI ATTRIBUTE 7711 WITH ATTRIBUTE SYNTAX IDRP.Rdi; 7712 MATCHES FOR EQUALITY; 7713 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7715 BEHAVIOUR localRDI-B 7716 BEHAVIOUR DEFINED AS The Routing Domain Identifier for the routeing 7717 domain where this BIS is located;; 7718 REGISTERED AS { IDRP.atoi localRDI(22) }; 7720 localSNPA ATTRIBUTE 7722 WITH ATTRIBUTE SYNTAX IDRP.LocalSNPAs; 7723 MATCHES FOR EQUALITY; 7724 BEHAVIOUR localSNPA-B 7725 BEHAVIOUR DEFINED AS The list of SNPAs of this BIS;; 7726 REGISTERED AS { IDRP.atoi localSNPA(23) }; 7728 locExpense ATTRIBUTE 7730 WITH ATTRIBUTE SYNTAX IDRP.LocExpense; 7731 MATCHES FOR EQUALITY, ORDERING; 7732 BEHAVIOUR locExpense-B 7733 BEHAVIOUR DEFINED AS The monetary expense of transiting this 7734 Routeing Domain. The attribute contains an indication of cost and 7735 the units in which it is calculated;; 7736 REGISTERED AS { IDRP.atoi locExpense(24) }; 7738 maxCPUOverloadTimer ATTRIBUTE 7740 DERIVED FROM "GMI":timer; 7741 BEHAVIOUR maxCPUOverloadTimer-B 7742 BEHAVIOUR DEFINED AS The timer that measures in seconds the time 7743 that has elapsed since the local BIS has detected that its CPU has 7744 become overloaded. See Annex H;; 7745 REGISTERED AS { IDRP.atoi maxCPUOverloadTimer(25) }; 7747 maxPDULocal ATTRIBUTE 7749 WITH ATTRIBUTE SYNTAX IDRP.MaxPDUSize; 7750 MATCHES FOR EQUALITY, ORDERING; 7751 BEHAVIOUR maxPDULocal-B 7753 BEHAVIOUR DEFINED AS The maximum number of octets that a peer BIS 7754 can include in a BISPDU that it sends to this BIS. The local BIS 7755 informs its peer of this value via the OPEN PDU sent to the peer;; 7757 REGISTERED AS { IDRP.atoi maxPDULocal(26) }; 7759 maxPDUPeer ATTRIBUTE 7760 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7762 WITH ATTRIBUTE SYNTAX IDRP.MaxPDUSize; 7763 MATCHES FOR EQUALITY, ORDERING; 7764 BEHAVIOUR maxPDUPeer-B 7766 BEHAVIOUR DEFINED AS The maximum number of octets that this BIS 7767 will include in a BISPDU that it sends to its peer BIS. This value 7768 is obtained from information in the header of the peer BIS's OPEN 7769 PDU;; 7771 REGISTERED AS { IDRP.atoi maxPDUPeer(27) }; 7773 maxRIBIntegrityCheck ATTRIBUTE 7775 WITH ATTRIBUTE SYNTAX IDRP.MaxRIBIntegrityCheck; 7776 MATCHES FOR EQUALITY, ORDERING; 7777 BEHAVIOUR maxRIBIntegrityCheck-B 7778 BEHAVIOUR DEFINED AS The maximum time in seconds between checking 7779 of the Adj-RIBs-In by a local mechanism. If corrupt Adj-RIB-In is 7780 detected, the BIS shall purge the offending Adj-RIB-In;; 7781 REGISTERED AS { IDRP.atoi maxRIBIntegrityCheck(28) }; 7783 maxRIBIntegrityTimer ATTRIBUTE 7785 DERIVED FROM "GMI":timer; 7786 BEHAVIOUR maxRIBIntegrityTimer-B 7787 BEHAVIOUR DEFINED AS The timer that measures in seconds the time 7788 remaining until the Adj-RIBs-In must be checked by a local 7789 mechanism. If a corrupt Adj-RIB-In is detected, the BIS shall 7790 purge the offending Adj-RIB-In;; 7791 REGISTERED AS { IDRP.atoi maxRIBIntegrityTimer(29) }; 7793 minRDOriginationTimer ATTRIBUTE 7795 DERIVED FROM "GMI":timer; 7796 BEHAVIOUR minRDOriginationTimer-B 7797 BEHAVIOUR DEFINED AS The timer that measures in seconds the time 7798 that has elapsed since the advertisement by the local BIS of an 7799 UPDATE PDU that reported changes within the local BIS's routeing 7800 domain. See 7.17.3.2;; 7801 REGISTERED AS { IDRP.atoi minRDOriginationTimer(30) }; 7803 minRouteAdvertisementInterval ATTRIBUTE 7805 WITH ATTRIBUTE SYNTAX IDRP.MinRouteAdvertisementInterval; 7806 MATCHES FOR EQUALITY, ORDERING; 7807 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7809 BEHAVIOUR minRouteAdvertisementInterval-B 7810 BEHAVIOUR DEFINED AS The minimum time in seconds that must elapse 7811 between successive advertisements by a single BIS to the adjacent 7812 BIS of routes to a particular destination;; 7813 REGISTERED AS { IDRP.atoi minRouteAdvertisementInterval(48) }; 7815 minRouteAdvertisementTimer ATTRIBUTE 7817 DERIVED FROM "GMI":timer; 7818 BEHAVIOUR minRouteAdvertisementTimer-B 7819 BEHAVIOUR DEFINED AS The timer that measures in seconds the time 7820 that has elapsed since the advertisement by the local BIS to the 7821 adjacent BIS of a better route that was received from a BIS located 7822 in another routeing domain. See 7.17.3.2. The minimum value is 5 7823 seconds, and the maximum value is 1800 seconds;; 7824 REGISTERED AS { IDRP.atoi minRouteAdvertisementTimer(31) }; 7826 multiExit ATTRIBUTE 7828 WITH ATTRIBUTE SYNTAX IDRP.Boolean; 7829 MATCHES FOR EQUALITY; 7830 BEHAVIOUR multiExit-B 7831 BEHAVIOUR DEFINED AS The indication whether this BIS will use the 7832 MULTI_EXIT_DISC attribute to decide between otherwise identical 7833 routes. The multiExit parameter is used as the default value for 7834 the "multi_exit_disc" function in policy decisions.;; 7835 REGISTERED AS { IDRP.atoi multiExit(32) }; 7837 outstandingPDUs ATTRIBUTE 7839 WITH ATTRIBUTE SYNTAX IDRP.OutstandingPdus; 7840 MATCHES FOR EQUALITY, ORDERING; 7841 BEHAVIOUR outstandingPDUs-B 7842 BEHAVIOUR DEFINED AS The maximum number of BISPDUs that may be sent 7843 to this BIS without receiving an acknowledgement;; 7844 REGISTERED AS { IDRP.atoi outstandingPDUs(33) }; 7846 priority ATTRIBUTE 7848 WITH ATTRIBUTE SYNTAX IDRP.Priority; 7849 MATCHES FOR EQUALITY, ORDERING; 7850 BEHAVIOUR priority-B 7851 BEHAVIOUR DEFINED AS The lowest value of ISO 8473 priority 7852 parameter that this RD will provide forwarding services for;; 7853 REGISTERED AS { IDRP.atoi priority(34) }; 7854 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7856 rdcConfig ATTRIBUTE 7858 WITH ATTRIBUTE SYNTAX IDRP.RdcNest; 7859 MATCHES FOR EQUALITY; 7860 BEHAVIOUR rdcConfig-B 7861 BEHAVIOUR DEFINED AS A depiction of the nesting relationships that 7862 exist between the confederations to which the local BIS belongs. 7863 Each nesting relationship identifies a top level confederation to 7864 which the local routeing domain belongs; it also lists in order, 7865 from outermost to innernmost, a set of nested RDCs on a path 7866 between the local RDI and the top level confederation. Since 7867 confederations can overlap one another, there may several paths 7868 between a given bottom level confederation and a given top level 7869 confederation. Hence, same top level confederation and bottom 7870 level confederation could be contained in several of the elements 7871 that comprise this attribute.;; 7872 REGISTERED AS { IDRP.atoi rdcConfig(35) }; 7874 rdLRE ATTRIBUTE 7876 WITH ATTRIBUTE SYNTAX IDRP.Rdlre; 7877 MATCHES FOR EQUALITY, ORDERING; 7878 BEHAVIOUR rdLRE-B 7879 BEHAVIOUR DEFINED AS A quantity that is proportional to the average 7880 error rate of a Routeing Domain and is expressed as an an integer 7881 in the range from 0 to <2^32> - 1. The actual error rate is equal 7882 to the integer value divided by <2^32> -1.;; 7883 REGISTERED AS { IDRP.atoi rdLRE(36) }; 7885 rdTransitDelay ATTRIBUTE 7887 WITH ATTRIBUTE SYNTAX IDRP.RDTransitDelay; 7888 MATCHES FOR EQUALITY, ORDERING; 7889 BEHAVIOUR rdTransitDelay-B 7890 BEHAVIOUR DEFINED AS The estimated average delay across a Routeing 7891 Domain in units of 2 ms.;; 7892 REGISTERED AS { IDRP.atoi rdTransitDelay(37) }; 7894 retransmissionTime ATTRIBUTE 7896 WITH ATTRIBUTE SYNTAX IDRP.RetransmissionTime; 7897 MATCHES FOR EQUALITY, ORDERING; 7898 BEHAVIOUR retransmissionTime-B 7899 BEHAVIOUR DEFINED AS The Number of seconds between KEEPALIVE 7900 messages if no other traffic is sent;; 7901 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7903 REGISTERED AS { IDRP.atoi retransmissionTime(38) }; 7905 ribAttsSet ATTRIBUTE 7907 WITH ATTRIBUTE SYNTAX IDRP.RibAttsSet; 7908 MATCHES FOR EQUALITY; 7909 BEHAVIOUR ribAttsSet-B 7910 BEHAVIOUR DEFINED AS The set of Rib Attributes supported by this 7911 BIS.;; 7912 REGISTERED AS { IDRP.atoi ribAttsSet(39) }; 7914 routeServer ATTRIBUTE 7916 WITH ATTRIBUTE SYNTAX IDRP.Boolean; 7917 MATCHES FOR EQUALITY; 7918 BEHAVIOUR routeServer-B 7919 BEHAVIOUR DEFINED AS The indication whether this BIS may set the 7920 "IDRP_Server_Allowed" field in the NEXT_HOP attribute to X"FF" for 7921 BIS to BIS UPDATE BISPDUs. If this variable is true then in 7922 accordance with local policy, the IDRP_Server_Allowed field may be 7923 set on some UPDATE BISPDUs that this BIS sends. If this attribute 7924 is set to false, then no UPDATE BISPDUs will be sent by this BIS 7925 with NEXT_HOP attributes containing an "IDRP_Server flag" equal to 7926 X"FF".;; 7927 REGISTERED AS { IDRP.atoi routeServer(40) }; 7929 state ATTRIBUTE 7931 WITH ATTRIBUTE SYNTAX IDRP.State; 7932 MATCHES FOR EQUALITY, ORDERING; 7933 BEHAVIOUR state-B 7934 BEHAVIOUR DEFINED AS The current state of BIS to BIS communication 7935 in the local BIS.;; 7936 REGISTERED AS { IDRP.atoi state(41) }; 7938 totalBISPDUsIn ATTRIBUTE 7940 DERIVED FROM "GMI":nonWrapping64BitCounter; 7941 BEHAVIOUR totalBISPDUsIn-B 7942 BEHAVIOUR DEFINED AS The number of BISPDUS received by this BIS 7943 from the remote BIS on this BIS to BIS connection.;; 7944 REGISTERED AS { IDRP.atoi totalBISPDUsIn(42) }; 7946 totalBISPDUsOut ATTRIBUTE 7947 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7949 DERIVED FROM "GMI":nonWrapping64BitCounter; 7950 BEHAVIOUR totalBISPDUsOut-B 7951 BEHAVIOUR DEFINED AS The number of BISPDUS received by this BIS 7952 from the remote BIS on this BIS to BIS connection.;; 7953 REGISTERED AS { IDRP.atoi totalBISPDUsOut(43) }; 7955 updatesIn ATTRIBUTE 7957 DERIVED FROM "GMI":nonWrapping64BitCounter; 7958 MATCHES FOR EQUALITY, ORDERING; 7959 BEHAVIOUR updatesIn-B 7960 BEHAVIOUR DEFINED AS The number of UPDATE BISPDUs received by this 7961 BIS on this BIS to BIS connection.;; 7962 REGISTERED AS { IDRP.atoi updatesIn(44) }; 7964 updatesOut ATTRIBUTE 7966 DERIVED FROM "GMI":nonWrapping64BitCounter; 7967 BEHAVIOUR updatesOut-B 7968 BEHAVIOUR DEFINED AS The number of UPDATE BISPDUs sent by this BIS 7969 on this BIS to BIS connection.;; 7970 REGISTERED AS { IDRP.atoi updatesOut(45) }; 7972 version ATTRIBUTE 7974 WITH ATTRIBUTE SYNTAX IDRP.Version; 7975 MATCHES FOR EQUALITY, ORDERING; 7976 BEHAVIOUR version-B 7977 BEHAVIOUR DEFINED AS The version of IDRP protocol this machine 7978 defaults to using.;; 7979 REGISTERED AS { IDRP.atoi version(46) }; 7981 11.5 Parameter definitions 7983 notificationRemoteBISNET PARAMETER 7985 CONTEXT EVENT-INFO; 7986 WITH SYNTAX IDRP.RemoteBISNetActionReply; 7987 BEHAVIOUR notificationRemoteBISNET-B 7988 BEHAVIOUR DEFINED AS The NET of the Remote BIS that this local BIS 7989 is starting IDRP protocol communication with.;; 7990 REGISTERED AS { IDRP.proi notificationRemoteBISNET(1) }; 7992 notificationBISPDUerrorcode PARAMETER 7993 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 7995 CONTEXT EVENT-INFO; 7996 WITH SYNTAX IDRP.BispduErrorCode; 7997 BEHAVIOUR notificationBISPDUerrorcode-B 7998 BEHAVIOUR DEFINED AS The error code indicating what type of error 7999 occurred in the BIS PDU.;; 8000 REGISTERED AS { IDRP.proi notificationBISPDUerrorcode(2) }; 8002 notificationBISerrorsubcode PARAMETER 8004 CONTEXT EVENT-INFO; 8005 WITH SYNTAX IDRP.BispduErrorSubcode; 8006 BEHAVIOUR notificationBISerrorsubcode-B 8007 BEHAVIOUR DEFINED AS The error code indicating what type of error 8008 within the major error type occurred in the BIS PDU.;; 8009 REGISTERED AS { IDRP.proi notificationBISerrorsubcode(3) }; 8011 notificationBISPDUerrorinfo PARAMETER 8013 CONTEXT EVENT-INFO; 8014 WITH SYNTAX IDRP.BispduErrorInfo; 8015 BEHAVIOUR notificationBISPDUerrorinfo-B 8016 BEHAVIOUR DEFINED AS The additional information from original PDU 8017 that indicated an error in the BIS PDU.;; 8018 REGISTERED AS { IDRP.proi notificationBISPDUerrorinfo(4) }; 8020 notificationRemoteRDCConfig PARAMETER 8022 CONTEXT EVENT-INFO; 8023 WITH SYNTAX IDRP.RemoteRDCConfig; 8024 BEHAVIOUR notificationRemoteRDCConfig-B 8025 BEHAVIOUR DEFINED AS The Routing Domain Confederation (RDC) 8026 information from the remote BIS on this BIS to BIS communication.;; 8027 REGISTERED AS { IDRP.proi notificationRemoteRDCConfig(5) }; 8029 notificationLocalRDCConfig PARAMETER 8031 CONTEXT EVENT-INFO; 8032 WITH SYNTAX IDRP.LocalRDCConfig; 8033 BEHAVIOUR notificationLocalRDCConfig-B 8034 BEHAVIOUR DEFINED AS The Routing Domain Confederation (RDC) 8035 information from this local BIS on this BIS to BIS communcation.;; 8036 REGISTERED AS { IDRP.proi notificationLocalRDCConfig(6) }; 8038 notificationRIBIntegrityFailure PARAMETER 8039 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8041 CONTEXT EVENT-INFO; 8042 WITH SYNTAX IDRP.RIBIntegrityFailure; 8043 BEHAVIOUR notificationRIBIntegrityFailure-B 8044 BEHAVIOUR DEFINED AS The maximum number of integrity checks 8045 detected before reporting the event to systems management;; 8046 REGISTERED AS { IDRP.proi notificationRIBIntegrityFailure(7) }; 8048 notificationSourceBISNET PARAMETER 8050 CONTEXT EVENT-INFO; 8051 WITH SYNTAX IDRP.NetworkEntityTitle; 8052 BEHAVIOUR notificationSourceBISNET-B 8053 BEHAVIOUR DEFINED AS NET of the remote BIS that sent a packet bomb 8054 to the local BIS;; 8055 REGISTERED AS { IDRP.proi notificationSourceBISNET(8) }; 8057 notificationSourceBISrdi PARAMETER 8059 CONTEXT EVENT-INFO; 8060 WITH SYNTAX IDRP.Rdi; 8061 BEHAVIOUR notificationSourceBISRdi-B 8062 BEHAVIOUR DEFINED AS RDI of the remote BIS that sent a packet bomb 8063 to the local BIS;; 8064 REGISTERED AS { IDRP.proi notificationSourceBISrdi(9) }; 8066 notificationSourceBISrdc PARAMETER 8068 CONTEXT EVENT-INFO; 8069 WITH SYNTAX IDRP.Rdi; 8070 BEHAVIOUR notificationSourceBISrdc-B 8071 BEHAVIOUR DEFINED AS RDC of the remote BIS that sent a packet bomb 8072 to the local BIS;; 8073 REGISTERED AS { IDRP.proi notificationSourceBISrdc(10) }; 8075 11.6 Behaviour 8077 supplyOnCreate-B BEHAVIOUR 8079 DEFINED AS Value is supplied by the protocol machine when the MO is 8080 created, or supplied via CREATE operation. The value can not be 8081 changed thereafter; 8082 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8084 11.7 ASN.1 modules 8086 IDRP{joint-iso-ccitt network-layer(13) 8087 management(0) iDRP(3) asn1Module(2) 0} 8089 DEFINITIONS::=BEGIN 8090 -- object identifier definitions 8092 idrpoi OBJECT IDENTIFIER ::= {NLM.nl iDRP(3)} 8093 sseoi OBJECT IDENTIFIER ::= 8094 {idrpoi standSpecificExtensions(0)} 8095 moi OBJECT IDENTIFIER ::= 8096 {idrpoi objectClass (3)} 8097 poi OBJECT IDENTIFIER ::= 8098 {idrpoi package (4)} 8099 proi OBJECT IDENTIFIER ::= 8100 {idrpoi parameter(5)} 8101 nboi OBJECT IDENTIFIER ::= 8102 {idrpoi nameBinding (6)} 8103 atoi OBJECT IDENTIFIER ::= 8104 {idrpoi attribute (7)} 8105 agoi OBJECT IDENTIFIER ::= 8106 {idrpoi attributeGroup (8)} 8107 acoi OBJECT IDENTIFIER ::= 8108 {idrpoi action (9)} 8109 noi OBJECT IDENTIFIER ::= 8110 {idrpoi notification (10)} 8112 -- 8113 --object identifiers for notification parameters 8114 -- 8116 se OBJECT IDENTIFIER ::= 8117 {sseoi specificProblems(3)} 8118 errorBISPDUsent OBJECT IDENTIFIER ::= 8119 {se errorBISPDU0(0)} 8120 openBISpduRDCerror OBJECT IDENTIFIER ::= 8121 {se errorBISPDU1(1)} 8122 errorBISPDUconnectionclose OBJECT IDENTIFIER ::= {se 8123 errorBISPDU2(2)} 8124 corruptAdjRIBIn OBJECT IDENTIFIER ::= 8125 {se errorBISPDU3(3)} 8126 packetBomb OBJECT IDENTIFIER ::= 8127 {se errorBISPDU4(4)} 8128 enterFSMstate OBJECT IDENTIFIER ::= 8129 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8131 {se errorBISPDU5(5)} 8132 fSMStateChange OBJECT IDENTIFIER ::= 8133 {se errorBISPDU6(6)} 8135 -- 8136 --ASN1 Types and Values 8137 -- 8139 AuthenticationCode ::=ENUMERATED{ 8140 integrityOnly(0), 8141 integrityPlusAuthentication(1) 8142 integrityPlusSecretText(2)} 8143 Authtype ::=AuthenticationCode 8144 BISGroup ::= SET OF NetworkEntityTitle 8145 BisNet ::= NetworkEntityTitle 8146 BisNegotiatedVersion ::=Version 8147 BispduErrorCode::= ENUMERATED { 8148 oPENPDUerror (1), 8149 uPDATEPDUError (2), 8150 holdtimerExpired (3)} 8151 BispduErrorSubcode ::= CHOICE { 8152 operr [] IMPLICIT Openerrorsubcode, 8153 uperr [1] IMPLICIT Updateerrorsubcode} 8154 BispduErrorInfo ::=OCTET STRING(SIZE(1..50)) 8155 --50 bytes of original message are saved 8156 BisPeersSNPAs ::= SNPAaddresses 8157 Boolean ::= BOOLEAN 8158 Capacity ::=INTEGER(1..255) 8159 EndSystemNSAP ::= OCTET STRING(SIZE(1..20)) 8160 ESPrefix ::= NSAPprefix 8161 Expensevalue ::=Locexpense 8162 GLOBAL ::= ENUMERATED { 8163 delay(0), 8164 expense(1), 8165 capacity(3), 8166 error(4) } 8167 Holdtime ::=INTEGER(1..65535) 8168 Integer ::=INTEGER 8169 KeepaliveSincelastupdupdate ::= 8170 INTEGER(1..4294967295) 8171 Lastseqnosent ::=INTEGER(1..4294967295) 8172 Lastseqnorecv ::=INTEGER(1..4294967295) 8173 Lastacksent ::=INTEGER(1..4294967295) 8174 Lastackrecv ::=INTEGER(1..4294967295) 8175 LocExpense ::= INTEGER(1..65535) 8176 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8178 LocalRDCConfig ::=Rdcgroup 8179 LocalSNPAs ::= SNPAaddresses 8180 MaxPDUSize ::=INTEGER(1..65535) 8181 MaxRIBIntegrityCheck ::=INTEGER(1..65535) 8182 Metriclength ::=INTEGER(1..255) 8183 Metricvalue ::=OCTET STRING(SIZE(1..255)) 8184 MinRouteAdvertisementInterval ::=INTEGER(1..65535) 8185 NSAPprefixLength ::=INTEGER(1..160) 8186 NSAPprefix ::= BIT STRING(SIZE(1..160)) 8187 NetworkEntityTitle ::=OCTET STRING(SIZE(1..20)) 8188 NETPrefix ::= NSAPprefix 8189 NotificationInfo ::=SET OF Parameter 8190 nullRDC Rdcgroup ::= {}--empty set 8191 nullRDI Rdi ::= OCTET STRING(SIZE(0)) 8192 Openerrorsubcode ::=ENUMERATED { 8193 unsupportedVersionnumber (1), 8194 badMaxPDUsize (2), 8195 badOutstandingPDUs (3), 8196 badPeerRD (4), 8197 unsupportedAuthenticationcode (5), 8198 authenticationFailure (6), 8199 badRIB-AttrsSet (7), 8200 rDCmismatch (8)} 8201 OutstandingPdus ::=INTEGER(0..255) 8202 Parameter ::= SEQUENCE { 8203 paramID OBJECT IDENTIFIER, 8204 paramInfo ANY DEFINED BY paramID} 8205 Priority ::= INTEGER(0..14) 8206 QOS ::= CHOICE { global[0] EXPLICIT GLOBAL, 8207 ssQOS[1] EXPLICIT QOSTV, 8208 dsQOS[2] EXPLICIT QOSTV } 8209 QOSlength ::= INTEGER(1..255) 8210 QOSTV ::= SEQUENCE { preflgth NSAPrefixLength, 8211 prefix NSAPpreifx, 8212 qOSlgth QOSlength, 8213 qOSval QOSvalue } 8214 QOSvalue ::= OCTET STRING(SIZE(1..255)) 8215 Rdi ::=OCTET STRING(SIZE(0..20)) 8216 --assigned from the NSAP address space 8217 Rdcgroup::= SET OF Rdi 8218 RdcNest ::=SET OF RdcHierarchy 8219 --each nested path from top to bottom is 8220 --identified by the confederation at the top. 8221 --Because of overlapping confederations, a 8222 --given top level confederation may appear 8223 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8225 --in several 'RdcHierarchy' elements 8226 RdcHierarchy ::= SEQUENCE { 8227 confed Rdcsetid, 8228 ConfedID Rdi, --RDI of top level RDC 8229 SubordinateRDCs SEQUENCE OF Rdi} 8230 --order of RDIs specifies a single 8231 --nesting relationships between the top 8232 --level RDC and a bottom level RDC 8233 --RDC in which the local routeing 8234 --domain is situated. 8235 Rdcsetid ::=INTEGER(1..255) 8236 RDTransitDelay ::=INTEGER(0..65535) 8237 Rdlre ::=INTEGER(0..4294967295) 8238 RetransmissionTime ::= INTEGER(0..65535) 8239 RemoteBISNET ::=NetworkEntityTitle 8240 RemoteRDCConfig ::=Rdcgroup 8241 RemoteBISNetActionReply ::=SEQUENCE{ 8242 responseCode OBJECT IDENTIFIER, 8243 responseArgs SET OF Parameter OPTIONAL} 8244 RibAttsSet ::= SEQUENCE { confed Ribsetid, 8245 count Ribsetcount, 8246 attribs SET OF Ribattributes} 8247 RIBIntegrityFailure ::=INTEGER(1..65535) 8248 Ribsetid ::=INTEGER(1..255) 8249 Ribsetcount ::=INTEGER(0..255) 8250 Ribattributes ::= SEQUENCE { 8251 priority [0] EXPLICIT Priority OPTIONAL, 8252 security [1] EXPLICIT SEC OPTIONAL, 8253 qosmaint [2] EXPLICIT QOS OPTIONAL } 8254 Ribattribute ::= ENUMERATED { 8255 tRANSITDELAY (9), 8256 rESIDUALERROR (10), 8257 eXPENSE (11), 8258 locDefQOS (12), 8259 Security (17), 8260 priority (20)} 8261 Ribvalue ::= SEQUENCE {length Ribattlength, 8262 attr Ribattributes} 8263 Ribattlength ::= INTEGER 8264 Ribattvalue ::= CHOICE { 8265 transitdelayvalue [0] IMPLICIT INTEGER, 8266 residualerrorvalue [1] IMPLICIT INTEGER, 8267 expensevalue [2] IMPLICIT INTEGER, 8268 locDefQOS [3]IMPLICIT INTEGER, 8269 security [6] IMPLICIT INTEGER, 8270 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8272 priorityvalue [8] IMPLICIT INTEGER} 8273 Ribattqos ::= SEQUENCE { 8274 preflgth NSAPprefixLength, 8275 prefix NSAPprefix, 8276 qOSlgth QOSlength, 8277 qOSval QOSvalue, 8278 metriclgth Metriclength, 8279 metricval Metricvalue} 8280 Ribattsec ::= SEQUENCE { 8281 preflgth NSAPprefixLength, 8282 prefix NSAPprefix, 8283 seclgth Securitylength, 8284 secval Securitylevel} 8285 RouteAdvertisementInterval ::=INTEGER(30..900) 8286 --IS 10589 imposes minimum value of 30 seconds 8287 --and maximum value of 900 seconds in clause 8288 --12.2.4.3, part e) 8289 SEC ::= SEQUENCE { secIDLgth SecurityLength, 8290 secID Securitylevel, 8291 secInfoLgth SecurityLength, 8292 secInfo SecurityInfo } 8293 SecurityInfo ::= OCTET STRING(SIZE(1..255)) 8294 Securitylength ::= INTEGER(0..255) 8295 Securitylevel ::= OCTET STRING(SIZE(1..255)) 8296 SNPAaddress ::= OCTET STRING (FROM 8297 ('1'H|'2'H|'3'H|'4'H|'5'H|'6'H|'7'H|'8'H|'9'H| 8298 'A'H|'B'H|'C'H|'D'H|'E'H|'F'H)) 8299 --integral number of hexadecimal digits 8300 SNPAaddresses ::= SET OF SNPAaddress 8301 State ::= ENUMERATED { 8302 closed (0), 8303 open-recv(1), 8304 established(2), 8305 open-sent(3), 8306 close-wait(4)} 8307 StopEventreply ::= Parameter 8308 StartEventreply::=Parameter 8309 SystemIdGroup ::= SEQUENCE { nETS SET OF NETprefix, nSAPs SET OF 8310 ESprefix } 8311 Updateerrorsubcode ::=ENUMERATED { 8312 malformedAttributelist (1), 8313 unrecognizedWell-knownAttribute (2), 8314 missingWell-knownAttribute (3), 8315 attributeFlagsError (4), 8316 attributeLengthError (5), 8317 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8319 rDRouteingLoop (6), 8320 invalidNEXTHOPAttribute (7), 8321 optionalAttributeerror (8), 8322 invalidReachabilityInformation (9), 8323 misconfiguredRDCs (10)} 8324 Version ::=INTEGER (1..255) 8325 zero INTEGER ::= 0 8327 END 8329 12. Conformance 8331 A Protocol Implementation Conformance Statement (PICS) shall be 8332 completed with respect to any claim for conformance of an 8333 implementation to this International Standard. The PICS shall be 8334 produced in accordance with the relevant PICS-proforma in Annex A. 8336 Note 38: Since it is only Boundary ISs that implement the elements 8337 of procedure of this International Standard, this clause 8338 does not address deployment guidelines or addressing 8339 guidelines for systems in general. Since distribution of 8340 policies is outside the scope of this International 8341 Standard, this topic also is not addressed in the following 8342 conformance clauses. 8344 12.1 Static conformance for all BISs 8346 Each IS claiming conformance to this International Standard shall be 8347 capable of each of the following: 8349 a) generating and parsing BISPDUs with the following structure and 8350 formats described in: 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, and 6.7 8352 b) transmitting and receiving NSAP prefixes that have been encoded 8353 as single values according to 7.1.2.1 8354 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8356 c) generating, recognizing upon receipt, and updating each of the 8357 following path attributes as described in the indicated 8358 subclauses: 8360 - ROUTE_SEPARATOR in 6.3.1.1, 7.12.1 8361 - RD_PATH in 6.3.1.3, 7.12.3 8362 - RD_HOP_COUNT in 6.3.1.13, 7.12.4 8363 - CAPACITY in 6.3.1.15, 7.12.15 8365 d) recognizing upon receipt each of the following well-known 8366 discretionary path attributes that are contained in any incoming 8367 UPDATE PDU, as described in the indicated subclauses: 8369 - EXT_INFO in 6.3.1.2, 7.12.2 8370 - NEXT_HOP in 6.3.1.4, 7.12.4 8371 - DIST_LIST_INCL in 6.3.1.5, 7.12.5 8372 - DIST_LIST_EXCL in 6.3.1.6, 7.12.6 8373 - TRANSIT DELAY in 6.3.1.8, 7.12.8 8374 - RESIDUAL ERROR in 6.3.1.9, 7.12.9 8375 - EXPENSE in 6.3.1.10, 7.12.10 8376 - LOCALLY DEFINED QOS in 6.3.1.11, 7.12.11 8377 - HIERARCHICAL RECORDING in 6.3.1.12, 7.12.12 8378 - SECURITY in 6.3.1.14, 7.12.14 8379 - CAPACITY in 6.3.1.15, 7.12.15 8380 - PRIORITY in 6.3.1.16, 7.12.16 8382 e) utilizing domain configuration information in the format 8383 described in 7.3 8385 f) providing reliable delivery of BISPDUs using sequence numbering 8386 and flow control as described in 7.7.4 and 7.7.5. 8388 g) establishing, closing, and maintaining BIS-BIS connections in 8389 accordance with the procedures of 7.6 8391 h) responding to error conditions in BISPDUs according to 7.20 8393 i) negotiating the protocol version number according to 7.8 8395 j) operating in a "fail-stop" manner in regard to corrupted routeing 8396 information, according to 7.10.2 8398 k) maintaining RIBs as described in 7.10. 8400 l) handling incoming BISPDUs as described in 7.14. 8402 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8404 m) detecting inconsistent routeing information in accordance with 8405 7.15.1. 8407 n) receiving and recognizing information which has been reduced in 8408 size according to the methods of 7.18.1. 8410 o) distributing network reachability information within a routeing 8411 domain according to 7.17.1. 8413 p) distributing network reachability information outside a routeing 8414 domain according to 7.17.2. 8416 q) selecting routes according to 7.16 8418 r) forwarding ISO 8473 NPDUs according to clause 8. 8420 s) supporting the interface to ISO 8473 using the service primitives 8421 according to clause 9. 8423 t) providing the managed objects described in 11. 8425 12.2 Conformance to optional functions 8427 12.2.1 Generation of information in reduced form 8429 A BIS that claims to support generation of information in a reduced 8430 form shall be capable of producing information in accordance with the 8431 reduction techniques of 7.18.1 and 7.18.2. 8433 12.2.2 Generation of well-known discretionary attributes 8435 A BIS that claims to support generation of any of the following 8436 well-known discretionary attributes shall do so in accordance with 8437 the indicated subclauses: 8439 - ROUTE_SEPARATOR in 6.3.1.1, 7.12.1 8440 - EXT_INFO in 6.3.1.2, 7.12.2 8441 - NEXT_HOP in 6.3.1.4, 7.12.4 8442 - DIST_LIST_INCL in 6.3.1.5, 7.12.5 8443 - DIST_LIST_EXCL in 6.3.1.6, 7.12.6 8444 - TRANSIT DELAY in 6.3.1.8, 7.12.8 8445 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8447 - RESIDUAL ERROR in 6.3.1.9, 7.12.9 8448 - EXPENSE in 6.3.1.10, 7.12.10 8449 - LOCALLY DEFINED QOS in 6.3.1.11, 7.12.11 8450 - HIERARCHICAL RECORDING in 6.3.1.12, 7.12.12 8451 - SECURITY in 6.3.1.14, 7.12.14 8452 - CAPACITY in 6.3.1.15, 7.12.15 8453 - PRIORITY in 6.3.1.16, 7.12.16 8455 12.2.3 Propagation of well-known discretionary attributes 8457 A BIS that claims to support updating and propagation of any of the 8458 following well-known discretionary attributes after having received 8459 them in an UPDATE PDU shall do so in accordance with the indicated 8460 subclauses: 8462 - ROUTE_SEPARATOR in 6.3.1.1, 7.12.1 8463 - EXT_INFO in 6.3.1.2, 7.12.2 8464 - NEXT_HOP in 6.3.1.4, 7.12.4 8465 - DIST_LIST_INCL in 6.3.1.5, 7.12.5 8466 - DIST_LIST_EXCL in 6.3.1.6, 7.12.6 8467 - TRANSIT DELAY in 6.3.1.8, 7.12.8 8468 - RESIDUAL ERROR in 6.3.1.9, 7.12.9 8469 - EXPENSE in 6.3.1.10, 7.12.10 8470 - LOCALLY DEFINED QOS in 6.3.1.11, 7.12.11 8471 - HIERARCHICAL RECORDING in 6.3.1.12, 7.12.12 8472 - SECURITY in 6.3.1.14, 7.12.14 8473 - CAPACITY in 6.3.1.15, 7.12.15 8474 - PRIORITY in 6.3.1.16, 7.12.16 8476 12.2.4 Peer entity authentication 8478 A BIS that claims to support peer entity authentication shall do so 8479 in accordance with 7.7.2. 8481 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8483 Annex A. PICS proforma 8485 (normative) 8487 A.1 Introduction 8489 The supplier of a protocol implementation which is claimed to conform 8490 to International Standard XXX shall complete the applicable Protocol 8491 Implementation Conformance Statement (PICS) proforma. 8493 A completed PICS proforma is the PICS for the implementation in 8494 question. The PICS is a statement of which capabilities and options 8495 of the protocol have been implemented. The PICS can have a number of 8496 uses, including use: 8498 - by the protocol implementer, as a check list to reduce the risk 8499 of failure to conform to the standard through oversight; 8501 - by the supplier and acquirer--or potential acquirer-- of the 8502 implementation, as a detailed indication of the capabilities of 8503 the implementation, stated relative to the common basis of 8504 understanding provided by the standard PICS proforma; 8506 - by the user--or potential user-- the implementation, as a basis 8507 for initially checking the possibility of interworking unit 8508 another implementation (note that, while interworking can never 8509 be guaranteed, failure to interwork can often be predicted from 8510 incompatible PICSs); 8512 - by a protocol tester, as the basis for selecting appropriate 8513 tests against which to assess the claim for conformance of the 8514 implementation. 8516 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8518 A.2 Abbreviations and special symbols 8520 A.2.1 Status symbols 8522 The following status symbols are used in the PICS: 8524 Symbol Meaning 8526 M mandatory 8528 O optional 8530 O. optional, but support of at least one of the group of 8531 options labelled by the same numeral is required 8533 X prohibited 8535 c. conditional requirement, according to the condition 8536 identified by 8538 simple-predicate condition, dependent on the support marked 8539 for or X, respectively, for cross-referencing purposes, 8576 where is any unambiguous identification for the item (e.g., 8577 simply a numeral): there are no other restrictions on its format and 8578 presentation. 8580 A completed PICS proforma, including any Additional Information and 8581 Exception Information, is the Protocol Implementation Conformance 8582 Statement for the implementation in question. 8584 Note 39: Where an implementation is capable of being configured in 8585 more than one way, a single PICS may be able to describe 8586 all such configurations. However, the supplier has the 8587 choice of providing more than one PICS, each covering some 8588 subset of the implementation's configuration capabilities, 8589 in case that makes for easier and clearer presentation of 8590 the information. 8592 A.3.2 Additional information 8594 Items of Additional Information allow a supplier to provide further 8595 information intended to assist the interpretation of the PICS. It is 8596 not intended or expected that a large quantity will be supplied, and 8597 a PICS can be considered complete without any such information. 8598 Examples might be an outline of the ways in which a (single) 8599 implementation can be set up to operate in a variety of environments 8600 and configurations, or a brief rationale--based perhaps upon specific 8601 application needs--for the exclusion of features which, although 8602 optional, are nonetheless commonly present in implementations of the 8603 protocol. 8605 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8607 References to items of Additional Information may be entered next to 8608 any answer in the questionnaire, and may be included in items of 8609 Exception Information. 8611 A.3.3 Exception information 8613 It may occasionally happen that a supplier will wish to answer an 8614 item with mandatory or prohibited status (after any conditions have 8615 been applied) in a way that conflicts with the indicated requirement. 8616 No pre-printed answer will be found in the Support column for this: 8617 instead, the supplier is required to write into the Support column an 8618 X reference to an item of Exception Information, and to provide 8619 the appropriate rationale in the Exception item itself. 8621 An implementation for which an Exception item is required in this way 8622 does not conform to ISO/IEC XXX. 8624 Note 40: A possible reason for the situation described above is that 8625 a defect in the standard has been reported, a correction 8626 for which is expected to change the requirement not met by 8627 the implementation. 8629 A.3.4 Conditional status 8631 A.3.4.1 Conditional items 8633 The PICS proforma contains a number of conditional items. These are 8634 items for which the status that applies--mandatory, optional, or 8635 prohibited--is dependent upon whether or not certain other items are 8636 supported, or upon the values supported for other items. 8638 In many cases, whether or not the item applies at all is conditional 8639 in this way, as well as the status when the item does apply. 8641 Individual conditional items are indicated by a conditional symbol in 8642 the Status column as described in A.3.4.2 and A.3.4.3 below. Where a 8643 group of items is subject to the same condition for applicability, a 8644 separate preliminary question about the condition appears at the head 8645 of the group, with an instruction to skip to a later point in the 8646 questionnaire if the "Not Applicable" answer is selected. 8648 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8650 A.3.4.2 Conditional symbols and conditions 8652 A conditional symbol is either of the form C. or C.G, where 8653 is a numeral or is an abbreviated condition of the form described in 8654 A.3.4.3 below. For the C. form, the numeral identifies a 8655 condition appearing in a list as the end of the subclause containing 8656 the item. For the C.G form, the numeral identifies a condition 8657 appearing in a list of global conditions. 8659 A simple condition is of the form 8661 if then else 8663 where is a predicate (see A.3.4.4 below) and and are 8664 either basic status symbols (M, O, O., or X) or the symbol "--". 8666 An extended condition is of the form 8668 if then 8669 else if then 8670 [else if ...] 8671 else 8673 where the quantities are predicates, and the quantities are 8674 either basic status symbols or "--". 8676 The symbol (either a basic status symbol or "--") applicable to an 8677 item governed by a simple condition is if the predicate of the 8678 condition is true, and is otherwise. The symbol applicable to 8679 an item governed by an extended condition is where is the 8680 first true predicate, if any, in the sequence , ,...; and it 8681 is if no predicate is true. 8683 A.3.4.3 Abbreviated conditions 8685 The abbreviated condition : in the status column is 8686 equivalent to a conditional symbol with corresponding condition if 8687 then else "--". 8689 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8691 A.3.4.4 Predicates 8693 A simple predicate in a condition is either: 8695 a) a single item reference; or 8697 b) a relation containing a comparison operator (=,<,etc.) with one 8698 (or both) of its operands being an item reference for an item 8699 taking numerical values as its answer. In case (a), the 8700 predicate is true if the item referred to is marked as supported, 8701 and false otherwise. In case (b), the predicate is true if the 8702 relation holds when each item reference is replaced by the value 8703 entered in the Support column as the answer to the item referred 8704 to. 8706 Compound predicates are boolean expressions constructed by combining 8707 simple predicates using the boolean operators AND, OR, and NOT, and 8708 parentheses, in the usual way. A compound predicate is true if and 8709 only if the boolean expression evaluates to "true" when the simple 8710 predicates are interpreted as described above. 8712 Items whose references are used in predicates are indicated by an 8713 asterisk in the Item column. 8715 A.3.4.5 Answering conditional items 8717 To answer a conditional item, the predicate(s) of the condition is 8718 (are) evaluated as described in A.3.4.4 above, and the applicable 8719 symbol is determined as described in A.3.4.2. If the result is 8720 "N/A", the Not Applicable answer column is to be marked; otherwise, 8721 the Support column is to be completed in the usual way. 8723 When two or more status symbols appear in the condition for an item, 8724 the Support column for the item contains one line for each such 8725 symbol, labelled by the relevant method. The answer for the item is 8726 to be marked in the line labelled by the symbol selected according to 8727 the condition (unselected lines may be crossed out for added 8728 clarity). 8730 For example, in the illustration below, the N/A column would be 8731 marked if neither predicate of C.2 was true; the answer line labelled 8732 "M:" would be marked if item A4 was marked as supported; and the 8733 answer line labelled "O:" would be marked if item A4 was not marked 8734 as supported but item D1 was supported. 8736 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8738 +----------------------------------------------------------------------+ 8739 | | 8740 | +---------+---------------+---------+----------+----+--------------+ | 8741 | | Item | Questions/Feat|rReferenc|sStatus | N/A| Support | | 8742 | +---------+---------------+---------+----------+----+--------------+ | 8743 | | H3 | Is ... | 42.3(d) | C.2 | __ | M: Yes__ | | 8744 | | | supported? | | | | O: Yes__ | | 8745 | | | | | | | No__ | | 8746 | +---------+---------------+---------+----------+----+--------------+ | 8747 | | 8748 | | 8749 | C.2: If A4 then M else if D1 or (B52>2) then O else N/A | 8750 | | 8751 +----------------------------------------------------------------------+ 8753 A.4 Identification 8755 A.4.1 PICS proforma: IDRP implementation identification 8757 +-----------------------------------------------+----------------------+ 8758 | Supplier | | 8759 +-----------------------------------------------+----------------------+ 8760 | Contact point for queries about this PICS | | 8761 +-----------------------------------------------+----------------------+ 8762 | Implementation Name(s) and Version(s) | | 8763 +-----------------------------------------------+----------------------+ 8764 | Other information necessary for full | | 8765 | identification (e.g., Name's and Version(s) | | 8766 | for machines and operating systems, System | | 8767 | Name(s)) | | 8768 +-----------------------------------------------+----------------------+ 8770 Note 41: Only the first three items are required for all 8771 implementations; other information may be completed as 8772 appropriate in meeting the requirement for full 8773 identification. The terms Name and Version should be 8774 interpreted appropriately to correspond with a supplier's 8775 terminology (using, e.g., Type,Series, MODEL). 8777 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8779 A.4.2 PICS proforma: IDRP protocol summary 8781 +-----------------------------------------------+----------------------+ 8782 | Protocol Version | | 8783 +-----------------------------------------------+----------------------+ 8784 | Addenda Implemented (if applicable) | | 8785 +-----------------------------------------------+----------------------+ 8786 | Amendments Implemented | | 8787 +-----------------------------------------------+----------------------+ 8788 | Have any Exception items been required? (See | Yes__ No__ | 8789 | A.3.3.) | | 8790 | | Note: The answer | 8791 | | Yes means | 8792 | | that the | 8793 | | implementation| 8794 | | does not | 8795 | | conform to | 8796 | | this | 8797 | | International | 8798 | | Standard.) | 8799 +-----------------------------------------------+----------------------+ 8801 A.4.3 PICS proforma: IDRP general 8803 +---------+-----------------------+-------------+---------+------------+ 8804 | Item | Questions/Features | References | Status | Support | 8805 +---------+-----------------------+-------------+---------+------------+ 8806 | BASIC | Are all basic BIS | 12.1 | M | Yes__ | 8807 | | functions | | | | 8808 | | implemented? | | | | 8809 +---------+-----------------------+-------------+---------+------------+ 8810 | MGT | Is this system | 11 | M | Yes__ | 8811 | | capable of being | | | | 8812 | | managed by the | | | | 8813 | | specified management | | | | 8814 | | information? | | | | 8815 +---------+-----------------------+-------------+---------+------------+ 8816 | VER | Does this BIS support | 7.8 | M | Yes__ | 8817 | | version negotiation? | | | | 8818 +---------+-----------------------+-------------+---------+------------+ 8819 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8821 +---------+-----------------------+-------------+---------+------------+ 8822 | Item | Questions/Features | References | Status | Support | 8823 +---------+-----------------------+-------------+---------+------------+ 8824 | RTSEP | Does this BIS support | 6.3.1.1, | M | Yes__ | 8825 | | the ROUTE_SEPARATOR | 7.12.1 | | | 8826 | | attribute? | | | | 8827 +---------+-----------------------+-------------+---------+------------+ 8828 | HOPS | Does this BIS support | 6.3.1.13, | M | Yes__ | 8829 | | the RD_HOP_COUNT | 7.12.13 | | | 8830 | | attribute? | | | | 8831 +---------+-----------------------+-------------+---------+------------+ 8832 | PATH | Does this BIS support | 6.3.1.3, | M | Yes__ | 8833 | | the RD_PATH | 7.12.3 | | | 8834 | | attribute? | | | | 8835 +---------+-----------------------+-------------+---------+------------+ 8836 | CAPY | Does this BIS support | 6.3.1.15, | M | Yes__ | 8837 | | the CAPACITY | 7.12.15 | | | 8838 | | attribute? | | | | 8839 +---------+-----------------------+-------------+---------+------------+ 8840 | FSM | Does this BIS manage | 7.6.1 | M | Yes__ | 8841 | | BIS-BIS connections | | | | 8842 | | according to the BIS | | | | 8843 | | FSM description? | | | | 8844 +---------+-----------------------+-------------+---------+------------+ 8845 | FCTL | Does this BIS provide | 7.7.5 | M | Yes__ | 8846 | | flow control? | | | | 8847 +---------+-----------------------+-------------+---------+------------+ 8848 | SEQNO | Does this BIS provide | 7.7.4 | M | Yes__ | 8849 | | sequence number | | | | 8850 | | support? | | | | 8851 +---------+-----------------------+-------------+---------+------------+ 8852 | INTG1 | Does this BIS provide | 7.7.1 | O.1 | Yes__ No__ | 8853 | | data integrity using | | | | 8854 | | authentication type | | | | 8855 | | 1? | | | | 8856 +---------+-----------------------+-------------+---------+------------+ 8857 | INTG2 | Does this BIS provide | 7.7.2 | O.1 | Yes__ No__ | 8858 | | data integrity using | | | | 8859 | | authentication type | | | | 8860 | | 2? | | | | 8861 +---------+-----------------------+-------------+---------+------------+ 8862 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8864 +---------+-----------------------+-------------+---------+------------+ 8865 | Item | Questions/Features | References | Status | Support | 8866 +---------+-----------------------+-------------+---------+------------+ 8867 | INTG3 | Does this BIS provide | 7.7.3 | O.1 | Yes__ No__ | 8868 | | data integrity using | | | | 8869 | | authentication type | | | | 8870 | | 3? | | | | 8871 +---------+-----------------------+-------------+---------+------------+ 8872 | ERROR | Does this BIS handle | 7.20 | M | Yes__ | 8873 | | error handling for | | | | 8874 | | IDRP? | | | | 8875 +---------+-----------------------+-------------+---------+------------+ 8876 | RIBCHK | Does this BIS operate | 7.10.2 | M | Yes__ | 8877 | | in a "fail-stop" | | | | 8878 | | manner with respect | | | | 8879 | | to corrupted routeing | | | | 8880 | | information? | | | | 8881 +---------+-----------------------+-------------+---------+------------+ 8882 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8884 A.4.4 PICS proforma: IDRP update send process 8886 +---------+-----------------------+-------------+---------+------------+ 8887 | Item | Questions/Features | References | Status | Support | 8888 +---------+-----------------------+-------------+---------+------------+ 8889 | INT | Does this BIS provide | 7.17.1 | M | Yes__ | 8890 | | the internal update | | | | 8891 | | procedures? | | | | 8892 +---------+-----------------------+-------------+---------+------------+ 8893 | RTSEL | Does this BIS support | 7.17.3.1 | M | Yes__ | 8894 | | the | | | | 8895 | | MinRouteSelectionInter|al | | | 8896 | | timer? | | | | 8897 +---------+-----------------------+-------------+---------+------------+ 8898 | RTORG | Does this BIS support | 7.17.3.2 | M | Yes__ | 8899 | | the | | | | 8900 | | MinRDOriginationInterv|l | | | 8901 | | timer? | | | | 8902 +---------+-----------------------+-------------+---------+------------+ 8903 | JITTER | Does this BIS provide | 7.17.3.3 | M | Yes__ | 8904 | | jitter on its timers? | | | | 8905 +---------+-----------------------+-------------+---------+------------+ 8907 A.4.5 PICS proforma: IDRP update receive process 8909 +---------+-----------------------+-------------+---------+------------+ 8910 | Item | Questions/Features | References | Status | Support | 8911 +---------+-----------------------+-------------+---------+------------+ 8912 | INPDU | Does the BIS handle | 7.14 | M | Yes__ | 8913 | | inbound BISPDUs | | | | 8914 | | correctly? | | | | 8915 +---------+-----------------------+-------------+---------+------------+ 8916 | INCONS | Does this BIS detect | 7.15.1 | M | Yes__ | 8917 | | inconsistent routeing | | | | 8918 | | information? | | | | 8919 +---------+-----------------------+-------------+---------+------------+ 8921 A.4.6 PICS proforma: IDRP decision process 8922 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8924 +---------+-----------------------+-------------+---------+------------+ 8925 | Item | Questions/Features | References | Status | Support | 8926 +---------+-----------------------+-------------+---------+------------+ 8927 | TIES | Does the BIS break | 7.16.2.1 | M | Yes__ | 8928 | | ties between | | | | 8929 | | candidate routes | | | | 8930 | | correctly? | | | | 8931 +---------+-----------------------+-------------+---------+------------+ 8932 | RIBUPD | Does this BIS update | 7.16.2 | M | Yes__ | 8933 | | the correct Loc-RIBs? | | | | 8934 +---------+-----------------------+-------------+---------+------------+ 8935 | AGGRT | Does this BIS support | 7.18.2.1, | O | Yes__ No__ | 8936 | | route aggregation? | 7.18.2.2, | | | 8937 | | | 7.18.2.3 | | | 8938 +---------+-----------------------+-------------+---------+------------+ 8939 | LOCK | Does this BIS provide | 7.16.4 | M | Yes__ | 8940 | | interlocks between | | | | 8941 | | its decision process | | | | 8942 | | and the updating of | | | | 8943 | | the information in | | | | 8944 | | its Adj-RIBs-In? | | | | 8945 +---------+-----------------------+-------------+---------+------------+ 8947 A.4.7 PICS proforma: IDRP receive process 8949 +---------+-----------------------+-------------+---------+------------+ 8950 | Item | Questions/Features | References | Status | Support | 8951 +---------+-----------------------+-------------+---------+------------+ 8952 | RCV | Does the BIS process | 7.14, 7.20 | M | Yes__ | 8953 | | incoming BISPDUs and | | | | 8954 | | respond correctly to | | | | 8955 | | error conditions? | | | | 8956 +---------+-----------------------+-------------+---------+------------+ 8957 | OSIZE | Does the BIS accept | 6.2, 7.20 | M | Yes__ | 8958 | | incoming OPEN PDUs | | | | 8959 | | whose size in octets | | | | 8960 | | is between | | | | 8961 | | minBISPDULength and | | | | 8962 | | 3000? | | | | 8963 +---------+-----------------------+-------------+---------+------------+ 8964 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8966 +---------+-----------------------+-------------+---------+------------+ 8967 | Item | Questions/Features | References | Status | Support | 8968 +---------+-----------------------+-------------+---------+------------+ 8969 | MXPDU | Does the BIS accept | 6.2, 7.20 | M | Yes__ | 8970 | | incoming UPDATE, IDRP | | | | 8971 | | ERROR and RIB REFRESH | | | | 8972 | | PDUs whose size in | | | | 8973 | | octets is between | | | | 8974 | | minBISPDULength and | | | | 8975 | | maxBISPDULength? | | | | 8976 +---------+-----------------------+-------------+---------+------------+ 8977 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 8979 A.4.8 PICS proforma: IDRP CLNS forwarding 8981 +---------+-----------------------+-------------+---------+------------+ 8982 | Item | Questions/Features | References | Status | Support | 8983 +---------+-----------------------+-------------+---------+------------+ 8984 | PSRCRT | Does the BIS | 8 | M | Yes__ | 8985 | | correctly handle 8473 | | | | 8986 | | NPDUs that contain a | | | | 8987 | | partial source route? | | | | 8988 +---------+-----------------------+-------------+---------+------------+ 8989 | DATTS | Does the BIS | 8.2 | M | Yes__ | 8990 | | correctly extract the | | | | 8991 | | NPDU-derived | | | | 8992 | | Distinguishing | | | | 8993 | | Attributes from an | | | | 8994 | | 8473 NPDU? | | | | 8995 +---------+-----------------------+-------------+---------+------------+ 8996 | MATCH | Does the BIS | 8.3 | M | Yes__ | 8997 | | correctly match the | | | | 8998 | | NPDU-derived | | | | 8999 | | Distinguishing | | | | 9000 | | Attributes with the | | | | 9001 | | corresponding | | | | 9002 | | FIB-Atts? | | | | 9003 +---------+-----------------------+-------------+---------+------------+ 9004 | EXTF | Does the BIS | 8.4 | M | Yes__ | 9005 | | correctly forward | | | | 9006 | | NPDUs with | | | | 9007 | | destinations outside | | | | 9008 | | its own routeing | | | | 9009 | | domain? | | | | 9010 +---------+-----------------------+-------------+---------+------------+ 9011 | INTF | Does the BIS | 8.1 | M | Yes__ | 9012 | | correctly forward | | | | 9013 | | NPDUs with | | | | 9014 | | destinations inside | | | | 9015 | | its own routeing | | | | 9016 | | domain? | | | | 9017 +---------+-----------------------+-------------+---------+------------+ 9019 A.4.9 PICS proforma: IDRP authentication 9020 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 9022 +---------+-----------------------+-------------+---------+------------+ 9023 | Item | Questions/Features | References | Status | Support | 9024 +---------+-----------------------+-------------+---------+------------+ 9025 | AUTH | Does the BIS | 7.7.2 | O | Yes__ No__ | 9026 | | correctly | | | | 9027 | | authenticate the | | | | 9028 | | source of a BISPDU? | | | | 9029 +---------+-----------------------+-------------+---------+------------+ 9031 A.4.10 PICS proforma: IDRP optional transitive attributes 9033 +---------+-----------------------+-------------+---------+------------+ 9034 | Item | Questions/Features | References | Status | Support | 9035 +---------+-----------------------+-------------+---------+------------+ 9036 | MEXIT | Does the BIS support | 6.3.1.7, | O | Yes__ No__ | 9037 | | use of the MULTI-EXIT | 7.12.7 | | | 9038 | | DISC attribute? | | | | 9039 +---------+-----------------------+-------------+---------+------------+ 9040 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 9042 A.4.11 PICS proforma: Generating IDRP well-known discretionary 9043 attributes 9045 +---------+-----------------------+-------------+---------+------------+ 9046 | Item | Questions/Features | References | Status | Support | 9047 +---------+-----------------------+-------------+---------+------------+ 9048 | EXTG | Does the BIS support | 6.3.1.2, | O | Yes__ No__ | 9049 | | generation of the | 7.12.2 | | | 9050 | | EXT_INFO attribute? | | | | 9051 +---------+-----------------------+-------------+---------+------------+ 9052 | NHRS | Does the BIS support | 6.3.1.4, | O | Yes__ No__ | 9053 | | generation of the | 7.12.4 | | | 9054 | | NEXT_HOP attribute in | | | | 9055 | | support of route | | | | 9056 | | servers? | | | | 9057 +---------+-----------------------+-------------+---------+------------+ 9058 | NHSN | Does the BIS support | 6.3.1.4, | O | Yes__ No__ | 9059 | | generation of the | 7.12.4 | | | 9060 | | NEXT_HOP attribute to | | | | 9061 | | advertise SNPAs? | | | | 9062 +---------+-----------------------+-------------+---------+------------+ 9063 | DLI | Does the BIS support | 6.3.1.5, | O | Yes__ No__ | 9064 | | generation of the | 7.12.5 | | | 9065 | | DIST_LIST_INCL | | | | 9066 | | attribute? | | | | 9067 +---------+-----------------------+-------------+---------+------------+ 9068 | DLE | Does the BIS support | 6.3.1.6, | O | Yes__ No__ | 9069 | | generation of the | 7.12.6 | | | 9070 | | DIST_LIST_EXCL | | | | 9071 | | attribute? | | | | 9072 +---------+-----------------------+-------------+---------+------------+ 9073 | TDLY | Does the BIS support | 6.3.1.8, | O | Yes__ No__ | 9074 | | generation of the | 7.12.8 | | | 9075 | | TRANSIT DELAY | | | | 9076 | | attribute? | | | | 9077 +---------+-----------------------+-------------+---------+------------+ 9078 | RERR | Does the BIS support | 6.3.1.9, | O | Yes__ No__ | 9079 | | generation of the | 7.12.9 | | | 9080 | | RESIDUAL ERROR | | | | 9081 | | attribute? | | | | 9082 +---------+-----------------------+-------------+---------+------------+ 9083 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 9085 +---------+-----------------------+-------------+---------+------------+ 9086 | Item | Questions/Features | References | Status | Support | 9087 +---------+-----------------------+-------------+---------+------------+ 9088 | EXP | Does the BIS support | 6.3.1.10, | O | Yes__ No__ | 9089 | | generation of the | 7.12.10 | | | 9090 | | EXPENSE attribute? | | | | 9091 +---------+-----------------------+-------------+---------+------------+ 9092 | LQOSG | Does the BIS support | 6.3.1.11, | O | Yes__ No__ | 9093 | | generation of the | 7.12.11 | | | 9094 | | LOCALLY DEFINED QOS | | | | 9095 | | attribute? | | | | 9096 +---------+-----------------------+-------------+---------+------------+ 9097 | HREC | Does the BIS support | 6.3.1.12, | O | Yes__ No__ | 9098 | | generation of the | 7.12.12 | | | 9099 | | HIERARCHICAL | | | | 9100 | | RECORDING attribute? | | | | 9101 +---------+-----------------------+-------------+---------+------------+ 9102 | SECG | Does the BIS support | 6.3.1.14, | O | Yes__ No__ | 9103 | | generation of the | 7.12.14 | | | 9104 | | SECURITY attribute? | | | | 9105 +---------+-----------------------+-------------+---------+------------+ 9106 | PRTY | Does the BIS support | 6.3.1.16, | O | Yes__ No__ | 9107 | | generation of the | 7.12.16 | | | 9108 | | PRIORITY attribute? | | | | 9109 +---------+-----------------------+-------------+---------+------------+ 9110 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 9112 A.4.12 PICS proforma: Propagating IDRP well-known discretionary 9113 attributes 9115 +---------+-----------------------+-------------+---------+------------+ 9116 | Item | Questions/Features | References | Status | Support | 9117 +---------+-----------------------+-------------+---------+------------+ 9118 | EXTGP | Does the BIS support | 6.3.1.2, | M | Yes__ No__ | 9119 | | propagation of the | 7.12.2 | | | 9120 | | EXT_INFO attribute? | | | | 9121 +---------+-----------------------+-------------+---------+------------+ 9122 | NHRSP | Does the BIS support | 6.3.1.4, | O | Yes__ No__ | 9123 | | propagation of the | 7.12.4 | | | 9124 | | NEXT_HOP attribute in | | | | 9125 | | support of route | | | | 9126 | | servers? | | | | 9127 +---------+-----------------------+-------------+---------+------------+ 9128 | NHSNP | Does the BIS support | 6.3.1.4, | O | Yes__ No__ | 9129 | | propagation of the | 7.12.4 | | | 9130 | | NEXT_HOP attribute to | | | | 9131 | | advertise SNPAs? | | | | 9132 +---------+-----------------------+-------------+---------+------------+ 9133 | DLIP | Does the BIS support | 6.3.1.5, | O | Yes__ No__ | 9134 | | propagation of the | 7.12.5 | | | 9135 | | DIST_LIST_INCL | | | | 9136 | | attribute? | | | | 9137 +---------+-----------------------+-------------+---------+------------+ 9138 | DLEP | Does the BIS support | 6.3.1.6, | O | Yes__ No__ | 9139 | | propagation of the | 7.12.6 | | | 9140 | | DIST_LIST_EXCL | | | | 9141 | | attribute? | | | | 9142 +---------+-----------------------+-------------+---------+------------+ 9143 | TDLYP | Does the BIS support | 6.3.1.8, | O | Yes__ No__ | 9144 | | propagation of the | 7.12.8 | | | 9145 | | TRANSIT DELAY | | | | 9146 | | attribute? | | | | 9147 +---------+-----------------------+-------------+---------+------------+ 9148 | RERRP | Does the BIS support | 6.3.1.9, | O | Yes__ No__ | 9149 | | propagation of the | 7.12.9 | | | 9150 | | RESIDUAL ERROR | | | | 9151 | | attribute? | | | | 9152 +---------+-----------------------+-------------+---------+------------+ 9153 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 9155 +---------+-----------------------+-------------+---------+------------+ 9156 | Item | Questions/Features | References | Status | Support | 9157 +---------+-----------------------+-------------+---------+------------+ 9158 | EXPP | Does the BIS support | 6.3.1.10, | O | Yes__ No__ | 9159 | | propagation of the | 7.12.10 | | | 9160 | | EXPENSE attribute? | | | | 9161 +---------+-----------------------+-------------+---------+------------+ 9162 | LQOSP | Does the BIS support | 6.3.1.11, | O | Yes__ No__ | 9163 | | propagation of the | 7.12.11 | | | 9164 | | LOCALLY DEFINED QOS | | | | 9165 | | attribute? | | | | 9166 +---------+-----------------------+-------------+---------+------------+ 9167 | HRECP | Does the BIS support | 6.3.1.12, | O | Yes__ No__ | 9168 | | propagation of the | 7.12.12 | | | 9169 | | HIERARCHICAL | | | | 9170 | | RECORDING attribute? | | | | 9171 +---------+-----------------------+-------------+---------+------------+ 9172 | SECP | Does the BIS support | 6.3.1.14, | O | Yes__ No__ | 9173 | | propagation of the | 7.12.14 | | | 9174 | | SECURITY attribute? | | | | 9175 +---------+-----------------------+-------------+---------+------------+ 9176 | PRTYP | Does the BIS support | 6.3.1.16, | O | Yes__ No__ | 9177 | | propagation of the | 7.12.16 | | | 9178 | | PRIORITY attribute? | | | | 9179 +---------+-----------------------+-------------+---------+------------+ 9180 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 9182 A.4.13 PICS proforma: Receiving IDRP well-known discretionary 9183 attributes 9185 +---------+-----------------------+-------------+---------+------------+ 9186 | Item | Questions/Features | References | Status | Support | 9187 +---------+-----------------------+-------------+---------+------------+ 9188 | EXTR | Does the BIS | 6.3.1.2, | M | Yes__ No__ | 9189 | | recognize upon | 7.12.2 | | X: | 9190 | | receipt the EXT_INFO | | | | 9191 | | attribute? | | | | 9192 +---------+-----------------------+-------------+---------+------------+ 9193 | NHRSR | Does the BIS | 6.3.1.4, | M | Yes__ No__ | 9194 | | recognize upon | 7.12.4 | | X: | 9195 | | receipt the NEXT_HOP | | | | 9196 | | attribute? | | | | 9197 +---------+-----------------------+-------------+---------+------------+ 9198 | DLIR | Does the BIS | 6.3.1.5, | M | Yes__ No__ | 9199 | | recognize upon | 7.12.5 | | X: | 9200 | | receipt the | | | | 9201 | | DIST_LIST_INCL | | | | 9202 | | attribute? | | | | 9203 +---------+-----------------------+-------------+---------+------------+ 9204 | DLER | Does the BIS | 6.3.1.6, | M | Yes__ No__ | 9205 | | recognize upon | 7.12.6 | | X: | 9206 | | receipt the | | | | 9207 | | DIST_LIST_EXCL | | | | 9208 | | attribute? | | | | 9209 +---------+-----------------------+-------------+---------+------------+ 9210 | TDLYR | Does the BIS | 6.3.1.8, | M | Yes__ No__ | 9211 | | recognize upon | 7.12.8 | | X: | 9212 | | receipt the TRANSIT | | | | 9213 | | DELAY attribute? | | | | 9214 +---------+-----------------------+-------------+---------+------------+ 9215 | RERRR | Does the BIS | 6.3.1.9, | M | Yes__ No__ | 9216 | | recognize upon | 7.12.9 | | X: | 9217 | | receipt the RESIDUAL | | | | 9218 | | ERROR attribute? | | | | 9219 +---------+-----------------------+-------------+---------+------------+ 9220 | EXPR | Does the BIS | 6.3.1.10, | M | Yes__ No__ | 9221 | | recognize upon | 7.12.10 | | X: | 9222 | | receipt the EXPENSE | | | | 9223 | | attribute? | | | | 9224 +---------+-----------------------+-------------+---------+------------+ 9225 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 9227 +---------+-----------------------+-------------+---------+------------+ 9228 | Item | Questions/Features | References | Status | Support | 9229 +---------+-----------------------+-------------+---------+------------+ 9230 | LQOSR | Does the BIS | 6.3.1.11, | M | Yes__ No__ | 9231 | | recognize upon | 7.12.11 | | X: | 9232 | | receipt the LOCALLY | | | | 9233 | | DEFINED QOS | | | | 9234 | | attribute? | | | | 9235 +---------+-----------------------+-------------+---------+------------+ 9236 | HRECR | Does the BIS | 6.3.1.12, | M | Yes__ No__ | 9237 | | recognize upon | 7.12.12 | | X: | 9238 | | receipt the | | | | 9239 | | HIERARCHICAL | | | | 9240 | | RECORDING attribute? | | | | 9241 +---------+-----------------------+-------------+---------+------------+ 9242 | SECR | Does the BIS | 6.3.1.14, | M | Yes__ No__ | 9243 | | recognize upon | 7.12.14 | | X: | 9244 | | receipt the SECURITY | | | | 9245 | | attribute? | | | | 9246 +---------+-----------------------+-------------+---------+------------+ 9247 | PRTYR | Does the BIS | 6.3.1.16, | M | Yes__ No__ | 9248 | | recognize upon | 7.12.16 | | X: | 9249 | | receipt the PRIORITY | | | | 9250 | | attribute? | | | | 9251 +---------+-----------------------+-------------+---------+------------+ 9252 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 9254 Annex B. IDRP checksum generation algorithm 9256 (normative) 9258 This annex describes the IDRP checksum algorithm, which accepts an a 9259 message of arbitrary length as its input and produces a 128-bit 9260 digital signature as its output. It is based upon the message digest 9261 algorithm described in RFC 1186. 9263 B.1 Mathematical notation 9265 In this annex, the following notation is used: 9267 Symbol Meaning 9269 X+Y Addition of two quantities, modulo 2^32 9271 X< [] [] 10152 = 10154 A PREF statement assigns a value to any route (from a BIS neighbor in 10155 an external domain) that matches the specified pattern. The assigned 10156 value determines the degree of preference that will be used in the 10157 Decision Process. This value is also used to generate the LOC_PREF 10158 attribute. Note that it is possible for the assigned value to be 10159 less than zero or greater than 255. Conversion from the assigned 10160 value to an eight-bit LOC_PREF field is a local matter. Routes 10161 received from internal BIS neighbors will already have a LOC_PREF 10162 field. The use of the LOC_PREF field as a basis for selecting the 10163 most preferred route is described in 7.12.1. 10165 The components of a are: 10167 - 10168 - [] 10169 - [] 10170 - [] 10171 - [], where:. 10173 : Reachable destinations; matches if the actual route's NLRI 10174 is a subset of the destinations specified by this template. 10175 The must be present in the route pattern of every policy 10176 statement. 10178 : Can be "idrp"|"ext"|"info_any", which is matched base d 10179 on the presence/absence of the EXT_INFO attribute in a route. 10180 These tokens are optional; if not present, the default match is 10181 "idrp". 10183 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10185 : Regular expression over RDIs to match against the content 10186 of the RD_PATH attribute. A is optional; if not 10187 present, the default matches any RD_PATH attribute. 10189 : Specifies a set of distinguished attributes for a route 10190 match. The is optional; if not present, the pattern 10191 matches routes with any set of distinguished attributes. 10193 : Provides matching/control for all other attributes, i.e. 10194 other than what is carried in RD_PATH, EXT_INFO path attribute, 10195 and the presence of distinguished attributes. This specifies 10196 conditions of route attributes that must be met for a route to 10197 match, e.g. (EXPENSE() < 10) && (! present(DIST_INCL)) might be 10198 the condition if the intent is to match a low-cost route which 10199 does not have certain re-distribution restrictions. No 10200 need be specified; if not present, the route pattern 10201 matches routes with any attributes. 10203 Note that the route pattern template is found in all three types of 10204 policy statement (preference, aggregation, and distribution). A 10205 slightly different form is used in the aggregation policy statement, 10206 which is discussed below. 10208 The PREF statement (actually, all policy statements) may also include 10209 "local condition tests", which allow policy to be sensitive to 10210 criteria not related to a route's attributes (e.g. time of day). A 10211 is optional; if not present, routes are matched under 10212 any local conditions. 10214 The specification of allows routes from different BIS neighbors 10215 to be assigned preferences differently. Any number of external BIS 10216 neighbors may be specified, and only routes received from these 10217 neighbors will be assigned a preference value by the statement. 10219 The is an integer arithmetic expression 10220 with operators '+', '-', '*', '/', and (similar to the C language) a 10221 conditional operator '?'. The basic operands are constants, or 10222 pre-defined functions which return values based on the attributes of 10223 a route, e.g. hopcount(), capacity(), weighted_list(EXCL,). 10224 The condition expression for the condition operator includes the 10225 logic operators "&&" and "||", and may include (1) tests for the 10226 presence of an attribute, (2) comparisons of integer expressions 10227 including attribute values, and (3) local condition tests. A is required in all preference statements. 10230 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10232 The order of PREF statements in a configuration file is significant; 10233 the first that matches an incoming route will assign 10234 the preference value. The list of PREF statements can be thought of 10235 as filters, each acting on particular routes; a routing domain 10236 administrator can make effective use of this first-match 10237 functionality by listing more specific route patterns early and more 10238 general patterns later. Hence, the "filters" start at a fine degree 10239 of granularity to assign preference to routes of particular 10240 importance, while other routes are handled by increasingly general 10241 "filters". 10243 If a route does not match any , it is dropped and not 10244 considered by the IDRP Decision Process. Note that there may be 10245 over-riding operational criteria that dictate that the non-matched 10246 routes can not be handled in this manner. 10248 The concept of decreasingly specific filters is useful for all of the 10249 policy sections: preference, aggregation, and distribution. As 10250 described below, more flexible control of the processing sequence for 10251 aggregation and distribution statements is possible, and necessary to 10252 concisely express policy. 10254 L.1.2 Aggregation statement 10256 The aggregation statement is identified by the "AGGR" keyword, and 10257 has the following format: 10259 AGGR = 10260 [] ["DONE"|"CONT"] 10262 The specification of the aggregation statement is 10263 slightly different than the PREF statement . The only 10264 difference is that the template will consist of two NLRI 10265 specifications separated by the "MUST" token, i.e. "MUST" 10266 . The first is used to match routes that can be 10267 aggregated, while the second specifies NLRI which must be 10268 present for the aggregate route to be instantiated. Either of the 10269 specifications may omitted, but not both. If the second 10270 is omitted, the "MUST" token is not required. 10272 The AGGR statement's template has the same syntax 10273 and semantics as the PREF statement. 10275 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10277 The of the aggregation statement indicates which 10278 external BIS's Adj-RIBs-Out are to receive the results of the 10279 statement's route aggregation. One, several, or all external BISs 10280 may be specified to receive the aggregate route "manufactured" by an 10281 AGGR statement. In addition, an administrator can specify 10282 "internal_bis" to affect aggregation to all other BISs internal to 10283 the routing domain. 10285 If a BIS is included in the recipient list, it will receive the 10286 aggregated route but not the component routes; if an aggregate is not 10287 instantiated to a particular BIS, it will receive all of the 10288 component routes. Note that by using additional AGGR statements 10289 (with more specific route matching templates), particular component 10290 routes may be advertised separately from the aggregate route. If the 10291 list is not specified, the default action is to 10292 announce the aggregate route to all external neighbor BISs; the 10293 default action will announce component routes to internal BISs. 10295 The specifies how the BIS determines which NLRI to 10296 advertise for the aggregate route. The two primary specifications 10297 are manual ("man") or automatic ("auto"), with two additional tokens 10298 ("auto_short" and "auto_subset") to specify variations of "auto"; 10299 "auto" includes both of these variations. Automatically aggregated 10300 NLRI will only reduce routes if there is no loss of reachability 10301 information, i.e. it will only advertise a more general NLRI if it 10302 can algorithmically determine that the aggregate is not advertising 10303 NLRI other than those of the component routes. Domain administrators 10304 can also "manually" override the automatic aggregation and specify 10305 that aggregated route NLRI may include destinations not included in 10306 any component of the aggregate route. The "manual" option is 10307 primarily intended for use when additional (complete) information is 10308 known about the NLRI (e.g. when it is part of the address space under 10309 control of the routing domain). It is assumed such information is 10310 obtained by means outside of IDRP. For instance, using "manual" NLRI 10311 configuration, a domain that acts as an address assignment authority 10312 may announce a single prefix for all routes containing longer 10313 extensions of this prefix, even though portions of the address space 10314 may be unassigned, with no route available to some destinations 10315 advertised by the NLRI. Manually aggregated NLRI is determined by 10316 taking the longest common prefix of the set of NLRI specified by the 10317 route pattern . Using automatic aggregation, the aggregate 10318 NLRI is computed to be the shortest NLRI prefix necessary to announce 10319 the component route's NLRI (the aggregate NLRI is also the longest 10320 common prefix of the component routes). The two variations of "auto" 10321 are as follows: (1) "auto_short" will collapse several longer NLRI 10322 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10324 prefixes into a single common prefix based on the binary 10325 representation, e.g. XX:YY:0xF601:* - XX:YY:0xF60F:* will be 10326 advertised as XX:YY:0xF60:*, and (2) "auto_subset" will permit longer 10327 prefixes to be aggregated with shorter ones, e.g. XX:YY:ZZ:* would be 10328 aggregated with XX:YY:* into XX:YY:*. 10330 Like PREF statements, the AGGR statements are applied in sequence 10331 (they are applied to the set of routes in the LOC-RIB). "DONE" and 10332 "CONT" provide control over additional processing of routes by 10333 subsequent AGGR statements. "CONT" is used to indicate that the 10334 aggregate route may be treated as a component route by later AGGR 10335 statements, and thus may be matched and further aggregated. "DONE" 10336 indicates that the aggregate is to be advertised as-is, and will not 10337 be considered as a component route for further aggregation. 10338 Specification of "DONE" or "CONT" is optional; the default case is 10339 "DONE". 10341 [Note: Aggregated routes will have a preference value assigned by the 10342 policy PREF statements; just as incoming routes from other BISs, 10343 aggregated routes are processed by the route preference statements. 10344 If an aggregate route does not match a PREF statement template, no 10345 value is assigned and the aggregate is not instantiated.] 10347 L.1.3 Distribution statement 10349 The distribution statement is identified by the "DIST" keyword, and 10350 has the following format: 10352 DIST [] = [] 10353 [] ["DONE"|"CONT]"] 10355 The for the DIST statement is the same as the PREF 10356 statement , and serves the same function 10357 for the DIST statement as it does for the AGGR and PREF statements. 10359 Similar to the AGGR statement, the specifies which 10360 Adj-RIBs-Out are effected by the statement. The Adj-RIBs-Out 10361 associated with the neighbors specified in may be 10362 affected in three ways by a DIST statement: (1) the route may be 10363 modified in these Adj-RIBs-Out, (2) the route may be placed in, or 10364 removed from, the Adj-RIBs-Out, and (3) the route may be marked as 10365 "DONE", so that it remains unaffected by further DIST statements. 10367 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10369 The can be "select_on", "select_off", "select_only", 10370 or "modify"; these control whether a route is distributed to an 10371 adjacent BIS. If a route is selected for advertisement to a 10372 particular BIS neighbor, it will be placed in the associated RIB-OUT. 10373 By default, routes are not selected for advertisement until selected 10374 by a DIST statement. The semantics of the effect 10375 this distribution as follows: 10377 "select_on" The route should be placed in Adj-RIBs-Out associated 10378 with all specified neighbors, unless "selected off" by 10379 later DIST statement. 10381 "select_off" The route should not be placed in Adj-RIBs-Out 10382 associated with the specified neighbors, unless "selected 10383 on" by a later DIST statement. 10385 "select_only" The route should be placed in Adj-RIBs-Out associated 10386 with all specified neighbors, unless "selected off" by 10387 later DIST stmt; in addition, the route should not be 10388 placed in Adj-RIBs-Out associated with BISs not in 10389 , unless "selected on" by a later DIST 10390 statement. 10392 "modify" Modify only; the selection status of routes are not 10393 effected by this DIST statement. Presumably, some routes 10394 matching this statement will also match, and be selected 10395 for distribution by, other DIST statements. 10397 The effects of a is applied only when 10398 indicates a BIS in an adjacent domain. It has no effect on 10399 distribution to BISs within the same domain as the local system. 10401 Note that in most cases, only the routes in Adj-RIBs-Out specified by 10402 will be affected by a DIST statement, however, there 10403 is one exception. The "select_only" action also indicates routes are 10404 not to appear in the Adj-RIBs-Out associated with BISs not in 10405 list, and that these routes may or may not be 10406 considered for further DIST statement processing (in the excluded 10407 BISs) based on the DIST statement's DONE/CONT token. Using 10408 "select_only" along with "DONE" allows one to concisely specify that 10409 only certain BISs are to receive particular routes, and as an 10410 additional effect, make certain these routes are not inadvertently 10411 selected for other BISs by a subsequent DIST statement that matches a 10412 more general route pattern. 10414 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10416 A list of statements indicates policy-driven changes 10417 to route attributes (e.g. DIST_LISTs, HIERARCHICAL RECORDING changes, 10418 etc). No need be present; the default leaves routes 10419 unchanged. 10421 "CONT" and "DONE" have similar function as in the aggregation 10422 statement; they control whether routes matching a particular DIST 10423 statement may be affected by later DIST statements. "CONT" indicates 10424 that a matched route in a specified RIB-OUT is eligible for further 10425 modifications, "DONE" indicates no further DIST statement processing. 10426 Specification of "DONE" or "CONT" is optional; the default case is 10427 "DONE". 10429 L.2 Policy configuration language BNF 10431 This section specifies the basic syntax for this example IDRP 10432 configuration language. This BNF tree does not include all 10433 terminal-symbol leaves; it is sufficient as an illustration of some 10434 minimal useful functionality, however, it is not complete. 10436 The policy configuration language uses a '#' to denote a comment to 10437 the end of line. This convention is also used to provide comments 10438 throughout the BNF specification. This BNF uses square brackets, '[' 10439 and ']', as a notational convenience to indicate optional (zero or 10440 one occurrence) syntactic symbols. This BNF also uses curly braces, 10441 '{' and '}' and a '|' to indicate a choice of symbols. 10443 A discussion of the semantics of this language can be found in L.1.1 10444 above.. 10446 L.2.1 PREF statement BNF 10448 ::= 10449 ::= ';' | 10450 ::= "PREF" [] 10451 '=' 10453 All of the symbols used by the are also used in other 10454 places, and are defined in L.2.4. 10456 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10458 L.2.2 AGGR statement BNF 10460 ::= 10461 ::= ';' | 10462 ::= "AGGR" 10463 '=' [] 10465 ::= '{' [ "MUST" '}'] 10466 ::= "auto" | "auto_subset" | "auto_short" | "man" 10468 L.2.3 DIST statement BNF 10470 ::= 10471 ::= ';' | 10472 ::= "DIST" 10473 '=' [] 10474 ::= "select_on" | "select_off" | 10475 "select_only" | "modify" 10477 Policy- defined changes to route attributes are distinct from 10478 attribute updates that occur due to basic "operational" processing 10479 (e.g. HOP_COUNT is updated without regard to policy). 10481 ::= '{' '}' | 10482 ::= ';' | 10483 ::= | 10484 | 10485 | 10486 10488 ::= "set_multi_exit" '(' ')' 10490 init_hr() - If HIERARCHICAL_RECORDING attribute is not already 10491 present in route, add attribute to route and initialize to one (1) to 10492 limit distribution within RDC. 10494 ::= "init_hr" '(' ')' 10496 Add RDIs to INCL or EXCL list. 10498 ::= 10499 "allow_dist" '(' ')' | 10500 "prohibit_dist" '(' ')' 10501 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10503 ::= 10504 "set_next_hop" '(' ')' 10506 L.2.4 Common BNF symbols 10508 This section describes common syntax components used by all three 10509 types of policy statements. 10511 L.2.4.1 Route attribute matching template 10513 Reachability: 10515 ::= '{' '}' 10516 ::= ',' | 10517 ::= "nlri_any" | 10518 ["not"] ':' '*' | ## prefix match 10519 ["not"] | ## exact match 10520 10522 Route matching template 10524 ::= 10525 ::= "idrp" | "ext" | "info_any" 10526 ::= '/' <> '/' 10528 Distinguished attributes 10530 ::= | 10531 "dist_att_none" | 10532 "dist_att_any" | 10533 '(' ')' 10534 (If , default is "dist_att_any".) 10536 ::= "qos_any" | 10537 ::= | 10538 (If , default is "qos_any".) 10540 ::= "qos_none" | "error" | "expense" | "delay" | 10541 "capacity" | | 10542 ::= "srcqos" 10543 ::= "dstqos" 10544 ::= ## TO BE DEFINED ## 10545 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10547 ::= "security_any" | ::= 10548 | 10549 (If , default is "security_any".) 10551 :: = "security_none" | | 10552 ::= "srcsec" 10553 ::= "dstsec" 10555 Security-related BNF is subject to change as the protocol continues 10556 to develop. 10558 ::= "priority_any" | "priority" | "priority_none"| 10559 10561 The "priority_any" token matches routes in either case, whether; thef 10562 priority attribute is present, or if it is not. If , default 10563 is "priority_any". 10565 L.2.4.2 BNF: numerical expressions 10567 ::= 10568 | 10569 | 10570 '(' ')' | 10571 | 10572 10573 ::= '(' '?' ':' ')' 10574 ::= 10575 "hopcount" "()" | ## rd_hopcount 10576 "pathweight" '('
')' | ## weighted path 10577 "listlen" '(' {"INCL"|"EXCL"} ')' | 10578 "listweight" '(' {"INCL|"EXCL"} ','
')' | 10579 "()" 10581 Returns the value carried by the attribute specified by the 10582 . 10584 ::= "multi_exit" | "loc_pref" | "priority" 10585 | "delay" | "expense" | "error" | "capacity" 10586 | "hier_rec" 10588 This example of the PIB BNF does not deal with the following 10589 attributes: SRC_QOS, DST_QOS, SRC_SECURITY, and DST_SECURITY. 10591 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10593 L.2.4.3 BNF: conditional specification 10595 There are three related types of conditions: 10597 a) used when doing a route match; only tests/examines 10598 attributes of a route 10599 b) used in policy actions; tests "other" (TBD) criteria 10600 (e.g. time of day) 10601 c) used in case statement; may test attribute or local 10602 criteria 10604 ::= 10605 | 10606 '!' | 10607 '(' ')' | 10608 "&&" | 10609 "||" 10611 ::= ## TO BE DEFINED 10613 This is currently a place holder reserved for future use; one 10614 potential example is time of day. 10616 ::= 10617 | 10618 '!' | 10619 '(' ')' | 10620 "&&" | 10621 "||" 10623 ::= | 10624 "present" '(' ')' | 10625 10627 ::= | 10628 '!' | 10629 '(' ')' | 10630 "&&" | 10631 "||" 10633 ::= | 10635 ::= "src_qos" | "dst_qos" | 10636 "dst_sec" | "src_sec" | 10637 "dist_incl" | "dist_excl" | 10638 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10640 "ext_info" | "next_hop" | 10641 10643 ::= 10645 This PIB BNF only defines the next_hop_test; others may be defined. 10647 ::= "next_hop" '(' ')' 10648 ::= ',' | 10649 10650 ::= "next_hop_any" | 10651 ["not"] ':' '*' | 10652 ["not"] [] | 10653 ["not"] | 10655 One can attempt to match NEXT_HOP attribute against "any", a set of 10656 BISs (NET prefix), a particular BIS and optionally specific 10657 interfaces. Also one can match routes against local interface over 10658 which route was received. 10660 L.2.4.4 Other common BNF symbols 10662 ::= "bis_all" | '{' '}' ::= 10663 ',' | ::= "rdi" | "bis" 10664 | 10665 "internal_bis" | "external_bis" 10667 One can specify all BIS neighbors in an adjacent RDIrdi, single out a 10668 particular bis by NET, specify all internal BIS neighbors, or all 10669 external BIS neighbors. 10671 ::= "DONE" | "CONT" | 10672 (Default is DONE) 10674
::= '{' '}' 10675 ::= | 10676 ::= '(' ',' ')' 10677 ::= '(' "default" ',' ')' | p.List 10678 of interfaces of this BIS; 10680 ::= '{' '}' 10681 ::= ',' | 10683 Routing Domain Identifiers; 10684 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10686 ::= '{' '}' 10687 ::= ',' | 10689 L.3 Simple example 10691 This example is provided to make the intended use of the policy 10692 configuration language more clear. Note that this example is 10693 incomplete, and at best only marginally realistic; it is intended to 10694 illustrate the basics of the policy configuration statements for 10695 purposes of this overview. 10697 Throughout this text we refer to the set of distinguished attributes 10698 which has no QOS attribute, no priority attribute, and no security 10699 attribute as the default set of distinguished attributes. This is 10700 the distinguished attribute set specified by "dist_att_none". 10702 Consider the portion of an internet shown in Figure 13. Assume that 10703 each routing domain has exactly one BIS that communicates with all 10704 adjacent domains' BISs. 10706 L.3.1 Transit domain 3 10708 Example policies of transit domain RD #3 might be as follows: 10710 a) RD #3 only accepts IDRP originated routes. It supports two sets 10711 of distinguished RIB_ATTs: the default set (no distinguished 10712 attributes) and the set having only the CAPACITY QOS attribute. 10714 b) Routes with CAPACITY QOS must travel via RD#6; CAPACITY must be 10715 greater than 15. 10717 c) For routes with no distinguished attributes, prefer routes 10718 through transit domain 1, however preference should be given to 10719 routes with short paths; large hop counts on a route via RD#1 may 10720 cause a shift to another transit domain. 10722 d) CAPACITY QOS routes are only offered to some domains (RDs #5, 10723 #8), and are restricted from being propagated further (i.e. via 10724 the DIST_LIST_INCL attribute). 10726 e) All routes with no distinguished attributes are re-distributed to 10727 every neighbor RD; hierarchical recording is desired to limit 10728 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10730 +----------------------------------------------------------------------+ 10731 | | 10732 | \ / | 10733 | Transit Domains: \ / | 10734 | 1, 2, 3, 5, 6, 7 +---+ +---+ +---+ | 10735 | | 1 |------| 2 |-----| 4 | | 10736 | +---+ +---+ +---+ | 10737 | Stub Domains: | | | 10738 | 4, 8 | | | 10739 | | | | 10740 | +---+ +---+ +---+ | 10741 | | 3 |------| 5 |-----| 8 | | 10742 | +---+ +---+ +---+ | 10743 | / | | 10744 | / | | 10745 | / | | 10746 | / | | 10747 | / | | 10748 | +---+ +---+ | 10749 | | 6 | | 7 | | 10750 | +---+ +---+ | 10751 | / \ | 10752 | / \ | 10753 | / \ | 10754 | | 10755 | | 10756 +----------------------------------------------------------------------+ 10757 Figure 13. A Portion of an Internet 10759 distribution of all of these routes (the specific RDC membership 10760 information is irrelevant for this example). 10762 f) Any route (default or CAPACITY) which pass through transit RD#9 10763 (not pictured) can only be redistributed to some domains (RD#2, 10764 RD#5, RD#8). 10766 g) All routes carrying NLRI of the address space controlled by 10767 domain #3 (XX:YY:3:*) will be aggregated (regardles s whether 10768 or not aggregated routes include NLRI for all of this space). In 10769 addition, routes carrying NLRI for RD#5 NSAPs (XX:YY:3 :5:*) 10770 will be announced separately. All routes for default dist_atts 10771 will be aggregated algorithmically. A "default route" (zero 10772 length NSAP) will be advertised for CAPACITY QOS routes (although 10773 distribution of this route will be limited to particular domains, 10774 i.e. RD#5, by the select/modify policy section). 10776 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10778 L.3.2 Policy configuration example 10780 The following is one example of an expression of the above policies 10781 using this configuration language. The next subclause examines and 10782 discusses each line of this configuration example in detail. 10784 This example assumes that the policy language is case insensitive. 10786 PREF {nlri_any} / .* 6 / (CAPACITY security_none priority_none) 10788 (CAPACITY() > 15) = 50; 10790 PREF {nlri_any} / .* 1 / dist_att_none = 255 - hopcount(); 10792 PREF {nlri_any} /.*/ dist_att_none = 245 - hopcount(); 10794 AGGR {XX:YY:3:5:*} /.*/ dist_att_none = man; 10796 AGGR {XX:YY:3:*} /.*/ dist_att_none = man; 10798 AGGR {nlri_any} /.*/ dist_att_none = auto; 10800 AGGR {nlri_any} /.*/ (CAPACITY security_none priority_none) = man; 10802 DIST {nlri_any} /.* 9 .*/ = 10804 modify {allow_dist({RD#2, RD#5, RD#8});} CONT; 10806 DIST {nlri_any} /.* 6/ (CAPACITY security_none priority_none) 10808 CAPACITY() > 15) = {BIS#5} select_only {allow_dist(RD#5, RD#8);}; 10810 DIST {nlri_any} /.*/ = select_on {init_hr();}; 10812 L.3.3 Discussion 10814 Each policy statement given in subclause L.3.2 is discussed. In most 10815 cases, the optional parts of the BNF have been omitted if the default 10816 action is appropriate to represent the example policy. For brevity, 10817 these defaults will be mentioned in the discussion only once, at the 10818 statement where they are first encountered. 10820 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10822 L.3.3.1 Preference statement discussion 10824 Recall that the sequence of statements is significant for determining 10825 the application and processing of all types of policy statements. 10826 Preference statements are the least complex of the three; routes are 10827 simply assigned the preference associated with the first that is matched (the other statements' processing and 10829 application sequence are discussed later in this text). 10831 The first PREF statement matches routes to any destination, indicated 10832 by {nlri_any}. No token for information source is present, so by 10833 default only routes where the information source was IDRP are matched 10834 (i.e. routes where no EXT_INFO attribute is present). The third 10835 expression "/ .* 6 /" matches any RD_PATH attribute where the last 10836 "hop" was from RD#6. 10838 PREF {nlri_any} / .* 6 / (CAPACITY security_none priority_none) 10839 (CAPACITY() > 15) = 50; 10841 The 3-tuple (CAPACITY security_none priority_none) indicates a route 10842 is to match if it corresponds to the RIB_ATT which has CAPACITY QOS, 10843 no security, and no priority. Finally, the attribute conditions only 10844 allow routes with CAPACITY attribute greater than 15 to be matched. 10845 There are no local conditions to be considered, so nothing is 10846 specified and by default routes are matched under any local 10847 conditions. Note that none of the actions in this example are 10848 dependent on local conditions, so this will be ignored for the rest 10849 of the example. Routes matched by this pattern are simply assigned a 10850 preference of 50. 10852 The second PREF statement also matches routes to any destination, if 10853 the routing information source was IDRP. The statement matches 10854 routes received directly from RD#1, by examining the route's RD_PATH 10855 attribute. The "dist_att_none" is specified, so only routes which 10856 have no QOS attribute, no priority attribute, and no security 10857 attribute will be matched. There are no other attribute or local 10858 conditions to meet, which is the default if nothing is specified. 10860 PREF {nlri_any} / .* 1 / dist_att_none = 255 - hopcount(); 10862 This statement assigns a route preference based on the HOP_COUNT 10863 value plus a constant. The constant (255) is relatively "good" 10864 (relative to 245 in the next statement) so that routes through RD#1 10865 are preferred (per policy C above). Since routes will be assigned 10866 preference by the the first matched, a path through 10867 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10869 RD#1 matching this pattern will not have a value assigned by the next 10870 statement, even though it has a more general and also 10871 would be a correct match. 10873 The next PREF statement matches any route with no distinguished 10874 attributes, again, only if the information source was IDRP. 10876 PREF {nlri_any} /.*/ dist_att_none = 245 - hopcount(); 10878 Routes matching this pattern are assigned a preference based on the 10879 hop count and a relatively "bad" constant (245), so that these routes 10880 are preferred less than routes through RD#1 (which match a previous 10881 PREF statement). 10883 Examining the last two preference statements, per policy C routes 10884 through RD#1 are preferred unless the path length (hop count) is 10885 worse (by ten hops or more). 10887 L.3.3.2 Aggregation statement discussion 10889 Aggregation statements are also processed in the order that they 10890 appear, however, their processing and application is not simply based 10891 on first match. An AGGR statement may be marked with "CONT" to 10892 indicate that the aggregate route may act as a component for 10893 subsequent AGGR statements. Alternatively, "DONE" indicates that an 10894 aggregate should be installed/advertised, and not considered in 10895 further aggregation processing. 10897 The first aggregation statement matches routes with a specific set of 10898 destinations, {XX:YY:3:5:*}, and announces the aggregate route with 10899 manually configured NLRI. The longest common NLRI prefix specified 10900 is XX:YY:3:5, so this will serve as the NLRI for the aggregate route. 10901 Using "manual" aggregation, this aggregate is instantiated whether or 10902 not the NLRI of the matched component routes include all destinations 10903 implied by the prefix XX:YY:3:5. 10905 AGGR {XX:YY:3:5:*} /.*/ dist_att_none = man; 10907 Any number of routes may match this pattern, and are replaced by a 10908 single aggregate route. No recipient are specified, so by 10909 default the aggregate route (rather than the components) is announced 10910 to all external BIS neighbors. The default action, "DONE", requires 10911 that the aggregate route be distributed without undergoing further 10912 aggregation. Hence, routes to these destination NSAPs are announced 10913 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10915 separately from the rest of the XX:YY:3:* NSAPs (which are aggregated 10916 below). 10918 The second AGGR statement is almost identical to the first. 10920 AGGR {XX:YY:3:*} /.*/ dist_att_none = man; 10922 Routes to a specific set of NSAPs are matched and aggregated; these 10923 destinations are a superset of those matched by the previous AGGR 10924 statement. This construct (two AGGR statements with overlapping 10925 NLRI) can be used to make certain that particular longer prefixes are 10926 announced separately from a more general aggregate prefix. 10928 The third aggregation statement matches routes to any destination, 10929 with any RD_PATH, with no distinguished attributes, and no additional 10930 attribute or local conditions. 10932 AGGR {nlri_any} /.*/ dist_att_none = auto; 10934 These routes are to be aggregated automatically; that is safely and 10935 algorithmically such that the aggregated NLRI does not include more 10936 NSAPs than the component routes did. By default, this statement 10937 affects the routes that are announced to all external BIS neighbors. 10939 The fourth AGGR statement matches routes to any destination, with any 10940 RD_PATH, if they have distinguished attributes that include only 10941 CAPACITY QOS. 10943 AGGR {nlri_any} /.*/ (CAPACITY security_none priority_none) = man; 10945 Manual aggregation will use the longest common prefix of the 10946 specified NLRI as the aggregate route's NLRI. This statement matches 10947 routes to any destination, so the aggregate NLRI is a "default" route 10948 (route with zero length NLRI). 10950 L.3.3.3 Distribution statement discussion 10952 Distribution statements are the most complex of the policy 10953 statements; they control both the selection and modification of 10954 routes for re-distribution. DIST statement processing is sequential, 10955 and like the AGGR statement, "CONT" and "DONE" affect the processing 10956 of a route by policy statements. If a DIST statement specifies 10957 "DONE", routes will not be affected by any subsequent DIST 10958 statements. A "CONT" token indicates that routes should be affected 10959 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 10961 by the next DIST statement that is matched. Using the idea of 10962 increasingly or decreasingly specific templates in 10963 combination with "DONE" and "CONT" to selectively prohibit further 10964 processing of some routes, a wide range of policy requirements can be 10965 concisely expressed. 10967 The first DIST statement from the example matches routes to any 10968 destination, originated by IDRP (the default match), where RD#9 is in 10969 the RD_PATH. These routes can have any distinguished attribute set 10970 (any distinguished attribute is the default match), and no additional 10971 attribute or local conditions need to be satisfied. 10973 DIST {nlri_any} /.* 9 .*/ = 10974 modify {allow_dist({RD#2, RD#5, RD#8});} CONT; 10976 This statement does not indicate a list, so by default all 10977 external BIS neighbors' Adj-RIBs-Out are affected by this statement. 10978 The "modify" indicates that route attributes are to be modified, but 10979 the route's "selected status" will remain unchanged by this DIST 10980 statement. One modification is performed which restricts the 10981 distribution of these routes (per policy F above) by altering the 10982 DIST_LISTs to only allow certain domains to receive this route. The 10983 statement indicates "CONT", so these routes may be further modified, 10984 and/or selected for distribution to adjacent BIS, by subsequent DIST 10985 statements. 10987 The second DIST statement matches routes to any destination with 10988 distinguished attributes (CAPACITY security_none priority_none). 10990 DIST {nlri_any} /.* 6/ (CAPACITY security_none priority_none) 10991 (CAPACITY() > 15) = {BIS#5} select_only {allow_dist(RD#5, RD#8);}; 10993 The {BIS#5} indication along with "select_only" specifies that the 10994 matched routes are to be selected for distribution only to BIS#5; an 10995 additional effect of "select_only" is to explicitly mark these routes 10996 as NOT distributable to all other BISs (all but BIS#5). The default 10997 action, "DONE", will keep these routes from being affected by other 10998 DIST statements. The "DONE" combined with the "select_only" will 10999 also prevent these routes from being matched and possibly placed in 11000 the RIB-OUT for distribution to other BISs (i.e. other than BIS#5). 11001 Using the "allow_dist()" function, this statement modifies the 11002 DIST_LISTs of matched routes to restrict further redistribution to 11003 domains RD#5 and RD#8. 11005 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 11007 The third DIST statement matches routes to any destination, with any 11008 RD_PATH; these routes can have any distinguished attributes, and no 11009 additional attribute or local conditions need to be satisfied. 11011 DIST {nlri_any} /.*/ = select_on {init_hr();}; 11013 The Adj-RIBs-Out for all neighboring BISs are affected by this 11014 statement, which selects the matched routes for distribution 11015 ("select_on") and modifies the hierarchical recording attribute so it 11016 is initialized to "1" (only if the attribute is not already present 11017 and thus can be initialized according to operational procedures). 11019 L.3.3.4 Operational example 11021 Consider a route with the following attributes that arrives at our 11022 BIS configured with the above Policy Information Base (PIB): 11024 nlri(10:66:*) rd_path(6 22 10) hopcount(15) 11026 It is a route with no distinguished attributes, which matches only 11027 one of the PREF statement route patterns: 11029 PREF {nlri_any} /.*/ dist_att_none 11031 and is assigned a preference of 230 (245-hopcount()) by the this PREF 11032 statement. Consider a second route to the same destination NLRI with 11033 attributes: 11035 nlri(10:66:*) rd_path(1 44 9 16 10) hopcount(20) 11037 It also has no distinguished attributes. It matches two PREF route 11038 patterns, however, only the first match is considered (first match). 11040 PREF {nlri_any} idrp /.* 1/ dist_att_none 11042 Because the route is through RD#1 it is a preferred route, and is 11043 assigned a preference of 235 (255-hopcount()). Both of these two 11044 routes are for the same set of destination NLRI; the second route, 11045 with preference value of 235 would be chosen over the route with 11046 preference value 230. If these were the only two routes to these 11047 destinations, the preferred route would be installed in our LOC_RIB 11048 and FIB. 11050 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 11052 Now aggregation policy must be considered to see how the route is to 11053 be announced. The preferred route that was placed in the LOC_RIB: 11055 nlri(10:66:*) rd_path(1 44 9 16 10) hopcount(20) 11057 matches one AGGR statement route pattern, which specifies automatic 11058 aggregation for those routes where it is possible: 11060 AGGR {nlri_any} /.*/ dist_att_none = auto; 11062 Depending on what other routes and aggregates are installed, this 11063 route may be announced individually, may result in a new aggregation, 11064 or it may be part of an already instantiated aggregate. For 11065 instance, if there is already an (aggregate) route to nlri(10:*), the 11066 example route could be included in the nlri(10:*) aggregate; the 11067 example route would be installed in the LOC-RIB and FIB (so packets 11068 are forwarded correctly), and then a new aggregate (made up of this 11069 route and the old aggregate) would be composed. If a new aggregate 11070 were to be generated, a new preference value would be assigned by the 11071 PREF policy statement processing. Whether this route is aggregated 11072 with other routes, or maintained individually, it must be selected by 11073 a DIST statement before it will be announced. 11075 Assuming that there is no aggregate for this route, it is installed 11076 in the LOC-RIB and FIB as-is, and must be considered for 11077 redistribution. Again, the route: 11079 nlri(10:66:*) rd_path(1 44 9 16 10) hopcount(20) 11081 is matched against route patterns. It matches the first DIST 11082 statement: 11084 DIST {nlri_any} /.* 9 .*/ = 11085 modify {allow_dist({RD#2, RD#5, RD#8});} CONT; 11087 which requires the route be modified before it is re-distributed. 11088 Applying the modifications the route becomes: 11090 nlri(10:*) rd_path(1 44 9 16 10) dist_list_incl(2,5,8) hopcount(20) 11092 Since this DIST statement does not terminate distribution processing, 11093 ("CONT"), other DIST statements may be matched. At this point the 11094 route has been modified, but has not been selected for distribution 11095 ("modify" rather than "select_on" or "select_only" was specified). 11096 The route also matches the following DIST statement: 11098 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 11100 DIST {nlri_any} /.*/ = select_on {init_hr();}; 11102 which modifies the route (initializing the HIERARCHICAL_RECORDING 11103 attribute since it's not already set), and selects the route for 11104 distribution (to all external BIS neighbors). This DIST statement 11105 (by default) specifies "DONE", so no further distribution processing 11106 is applied to this route. Note that other changes to the route 11107 attributes (i.e. update of RD_PATH) will be performed as part of 11108 "operational processing". h4 id=defxmp.Simple Default Policy 11110 Among the concerns about configuring administrative policy is ease of 11111 configuration for the majority of domains which may have very simple 11112 policy. A simple policy configuration must include a preference 11113 statement: 11115 (Assign a preference to all routes based on the number of hops.) 11117 PREF {nlri_any} / .*/ = 255 - hopcount(); 11119 If the routing domain will carry transit traffic, then the following 11120 minimal aggregation and distribution statements are also needed: 11122 (Automatic aggregation to reduce the amount of information.) 11124 AGGR {nlri_any} / .*/ = auto; 11126 (Select all routes for distribution; no modifications.) 11128 DIST {nlri_any} / .*/ = select_on; 11130 This illustrates that the configuration of the policy information 11131 base does not necessarily have to be extensive or complex. A complex 11132 configuration will be the case only to the extent that the domain's 11133 administrative policy has extensive requirements and specifications. 11135 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 11137 Index 11139 +---+ authentication 39, 44, 87, 88, 11140 | A | 89, 150, 151, 224 11141 +---+ authenticationTypeCode 175 11143 Adj-RIB-In 24, 27, 28, 41, 65, 11144 95, 96, 100 +---+ 11145 and withdrawn routes 137 | B | 11146 as used by Decision +---+ 11147 Process 128--136 11148 default identified by Empty bisNegotiatedVersion 175 11149 RIB-Att 97 bisNet 175 11150 solicited refresh of 99 BISPDU 37--65 11151 unsolicited refresh of 99 BISPDU fixed header 37 11152 updating by Update-Receive bisPeerSNPAs 175 11153 process 126 bisRDC 175 11154 validation of 97 bisRDI 176 11155 Adj-RIB-Out 24, 27, 28, 41, 65, boundary IS 11156 95, 96, 100, 138 definition 19 11157 and information reduction 141 breaking ties 138 11158 and route aggregation 142 11159 and withdrawn routes 137 11160 as used by Decision +---+ 11161 Process 128--136 | C | 11162 default identified by Empty +---+ 11163 RIB-Att 97 11164 validation of 97 CAPACITY 59, 123, 146, 176 11165 adjacentBIS 168 CEASE PDU 65, 76, 84, 85, 87, 11166 adjacentBISPkg 173 149, 156 11167 administrative domain 14 checksum 11168 advertisement intervals for algorithm for generation 218 11169 routes 139, 140 encrypted, in BISPDU 11170 aggregating routes header 88, 224 11171 See route aggregation field in BISPDU header 39 11172 architectural constants 165 for RIB validation 97 11173 in BISPDU header 150 11174 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 11176 checksum (continued) distinguishing attributes 11177 unencrypted, in BISPDU derived from NPDU 158 11178 header 88 matching with RIB-Att 160 11179 CLOSE-WAIT State 86--87 distinguishing path attributes 11180 CLOSED State 74--75 in UPDATE PDU 28 11181 CloseWaitDelay 76, 84, 86, 90, as identifier of RIBs and 11182 91 FIBs 96 11183 closeWaitDelayTimer 176 type specific 104 11184 closing a BIS-BIS connection 87 type-value specific 104 11185 confederations equivalence of 104 11186 See RDC (Routeing Domain origination and update 103 11187 Confederation) permissible sets of 103 11188 configuration information 69 11189 conformance 11190 requirements 193--196 +---+ 11191 connection management between | E | 11192 BISs 73--87 +---+ 11193 connectionRequested 171 11194 connectRequestBISUnknown 171 empty RIB-Att 41 11195 CorruptAdjRIBIn 170 encryption 224 11196 EnterFSMState 172 11197 EnterFSMStateMachine 171 11198 +---+ ENTRY_SEQ 49, 107, 108, 109, 143 11199 | D | ENTRY_SET 49, 107, 108, 109, 11200 +---+ 143, 146 11201 error codes and subcodes 61 11202 decision process error handling 149 11203 overview of three phases 129 errorBISPDUconnectionclose 169 11204 phase 1 130 errorBISPDUsent 168 11205 phase 2 130 ESTABLISHED State 85--86 11206 phase 3 133 EXPENSE 55, 119, 145, 160 11207 degree of preference 25, 128, EXT_INFO 49, 106, 143 11208 130, 132 external updates 138 11209 deployment guidelines externalBISNeighbor 69, 72, 176 11210 for ESs and ISs 68 11211 for RDs 68 11212 DIST_LIST_EXCL 53, 115, 116, 11213 142, 145 11214 DIST_LIST_INCL 52, 115, 116, 11215 142, 145 11216 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 11218 +---+ +---+ 11219 | F | | I | 11220 +---+ +---+ 11222 finite state machines 73--87 IDRP ERROR PDU 61 11223 flow control of BISPDUs 91 idrpConfig 168 11224 Forwarding Information Base idrpConfigID 177 11225 (FIB) 24, 27, 28, 29, 138 idrpConfigPkg-P 168 11226 default identified by Empty inter-domain link 11227 RIB-Att 97 definition 18 11228 maintenance of 148 real links and inter-domain 11229 validation of 97 traffic 18 11230 forwarding of NPDUs virtual links and inter-domain 11231 and NPDU-derived traffic 18 11232 Distinguishing virtual links and intra-domain 11233 Attributes 157 traffic 18 11234 to external destinations 162 internal updates 136 11235 to internal destinations 158 internalBIS 69, 72, 177 11236 FSM error 74 internalSystems 70, 106, 177 11237 FSMStateChange 172 intra-domain routeing 11238 protocol 11, 18, 35, 69 11239 intraIS 69, 178 11240 +---+ ISO/IEC 10589 26 11241 | G | ISO/IEC TR 9577 60 11242 +---+ 11244 GDMO descriptions 167--193 +---+ 11245 | J | 11246 +---+ 11247 +---+ 11248 | H | jitter 140, 228 11249 +---+ 11251 header of BISPDU 37 11252 HIERARCHICAL_RECORDING 57, 121 11253 hold time 11254 of OPEN PDU 40 11255 holdTime 176 11256 holdTimer 177 11257 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 11259 +---+ +---+ 11260 | K | | M | 11261 +---+ +---+ 11263 KEEPALIVE PDU 64, 156 maxCPUOverloadTimer 180 11264 keepAlivesSinceLastUpdate 178 maxPDULocal 180 11265 keepAliveTimer 178 maxPDUPeer 180 11266 maxRIBIntegrityCheck 97, 98, 181 11267 maxRIBntegrityTimer 181 11268 +---+ MinBISPDULength 38, 41, 151 11269 | L | MinRDOriginationInterval 140 11270 +---+ minRDOriginationTimer 181 11271 minRouteAdvertisementInterval 139, 11272 lastAckRecv 178 140, 181 11273 lastAckSent 178 minRouteAdvertisementTimer 182 11274 lastPriorSeqNo 179 more specific routes 134 11275 lastSeqNoRecv 179 MULTI-EXIT_DISC 54, 117, 142, 11276 lastSeqNoSent 179 239 11277 less specific routes 134 multi-homed end routeing 11278 ListenForOPEN 74, 179 domain 19 11279 Loc-RIB 24, 27, 28, 95, 96, 100, multiExit 117, 132, 182 11280 148 multiple routes in an UPDATE PDU 11281 as used by Decision distinguishing attributes of 11282 Process 128--136 individual route 105 11283 default identified by Empty LOCAL_PREF of individual 11284 RIB-Att 97 route 105 11285 validation of 97 non-distinguishing attributes 11286 LOCAL_PREF 48, 128, 143 of individual route 105 11287 LOCALLY DEFINED QOS 55, 120, ROUTE_ID of individual 11288 145, 160 route 105 11289 localRDI 70, 125, 179 ROUTE_SEPARATOR as 11290 localSNPA 149, 180 delimiter 29, 48, 105 11291 locExpense 119, 180 selecting information base for 11292 LSAP 51, 60 individual route 29 11293 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 11295 +---+ NSAP Addresses 11296 | N | syntax and encoding 34 11297 +---+ 11299 naming and containment +---+ 11300 hierarchy 167 | O | 11301 neighbor BIS 33, 72 +---+ 11302 NET (Network entity title) 11303 syntax and encoding 34 OPEN PDU 40, 150 11304 network layer reachability OPEN-RCVD State 83--85 11305 information OPEN-SENT State 75--76 11306 as encoded in UPDATE PDU 59 OpenBISpduRDCError 169 11307 as related to configuration origination intervals for 11308 information 70 routes 140 11309 information reduction of 141 outstandingPDUs 182 11310 NEXT_HOP 50, 111, 142 overlapping routes 134 11311 NLRI overload conditions 11312 See network layer reachability processor overload 233 11313 information RIB overload 231 11314 Non-transitive attribute 47 11315 notificationBISerrorsubcode 168, 11316 169, 186 +---+ 11317 notificationBISPDUerrorcode 168, | P | 11318 169, 185 +---+ 11319 notificationBISPDUerrorinfo 168, 11320 169, 186 packet bomb 72 11321 notificationLocalRDCConfig 169, PacketBomb 170 11322 186 partial bit 47 11323 notificationRemoteBISNET 168, passive opening of BIS-BIS 11324 169, 170, 172, 185 connection 11325 notificationRemoteRDCConfif 169 See ListenForOPEN 11326 notificationRemoteRDCConfig 186 password text, untransmitted 89 11327 notificationRIBIntegrityFailure 170path attributes 11328 186 See also individual attributes 11329 notificationSourceBISNET 170, aggregation rules 143--146 11330 171 as identifier for a FIB 28 11331 notificationSourceBISrdc 170, as identifier for a RIB 28 11332 171, 187 as part of a route 27 11333 notificationSourceBISrdi 170, categories of 102 11334 171, 187 encoding in UPDATE PDU 47--59 11335 usage rules 105--124 11336 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 11338 policy, routeing RDC (Routeing Domain 11339 detecting inconsistencies 25, Confederation) (continued) 11340 128 and HIERARCHICAL RECORDING 11341 external attribute 121 11342 inconsistencies 128 associated managed object 70 11343 internal boundary of 126 11344 inconsistencies 128 configuration information 11345 indirect expression in UPDATE for 125 11346 PDUs 25 definition 20 11347 local setting of 25 disjoint 20, 121 11348 policy information base entering a confederation 121, 11349 (PIB) 20, 26, 128, 145, 146 126 11350 syntax and semantics exiting a confederation 121, 11351 of 244--266 126 11352 positioning of IDRP formation and deletion 11353 with respect to ISO 8473 11 of 234, 242 11354 within the Network layer 11, in OPEN PDU 43 11355 23 nested 20, 107, 108, 109, 121 11356 PRIORITY 59, 124, 146, 182 overlapping 20, 107, 108, 109 11357 permissible policies of 125 11358 recursive nature of 27 11359 +---+ updating the RD_PATH attribute 11360 | Q | on entry or exit 107, 108, 11361 +---+ 109 11362 use of RDI to identify 27, 33 11363 quality of service (QOS) rdcConfig 107, 108, 109, 125, 11364 See LOCALLY DEFINED QOS 126, 183 11365 RDI (routeing domain identifier) 11366 as encoded in RD_PATH 11367 +---+ attribute 49 11368 | R | conformance to ISO 8348 33 11369 +---+ in updated RD_PATH 11370 attributes 107, 108, 109 11371 RD_HOP_COUNT 57, 122 syntax and encoding 34 11372 RD_PATH 49, 107, 143, 146, 147 rdLRE 118, 183 11373 as encoded in UPDATE PDU 49 rdTransitDelay 118, 183 11374 RD_SEQ 49, 107, 108, 109, 143 real link 11375 RD_SET 49, 107, 108, 109, 143, See inter-domain link 11376 147 RESIDUAL ERROR 55, 118, 145, 160 11377 RDC (Routeing Domain retransmissionTime 183 11378 Confederation) 20, 27, 125 11379 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 11381 RIB REFRESH PDU 65, 99, 156 routeServer 114, 184 11382 RIB-Attributes (RIB-Att) 27, 29, 11383 96, 100, 148, 151, 153 11384 as coded in OPEN PDU 41 +---+ 11385 as identifier for information | S | 11386 bases 28 +---+ 11387 empty RIB-Att 41, 97 11388 in RIB REFRESH PDU 65 SECURITY 57, 123, 146, 160 11389 matching to NPDU-derived sequence numbers of BISPDUs 90 11390 distinguishing attribute 160 size of BISPDUs 11391 type specific 43 maximum, of OPEN PDU 38, 40 11392 type-value specific 43 of the entire BISPDU 38 11393 validity 103 state 184 11394 RibAttsSet 41, 70, 96, 97, 151, stub end routeing domain 19 11395 184 supplyOnCreate-B 187 11396 route aggregation 11397 of NLRI 143 11398 of path attributes 142--143 +---+ 11399 of the RD_PATH | T | 11400 attribute 143--147 +---+ 11401 ROUTE-ID 48, 105, 143 11402 ROUTE_SEPARATOR 48, 128, 143 tie breaking 132 11403 routeing domains totalBISPDUsIn 184 11404 adjacent (definition) 19 totalBISPDUsOut 184 11405 as part of global OSIE 25 TR 9575 (Routeing Framework) 11, 11406 end routeing domain 19, 27 23 11407 transit routeing domain 19, TRANSIT DELAY 55, 118, 145, 160 11408 27 transitive attribute 47 11409 routeing information bases 11410 See Adj-RIB-In 11411 See Adj-RIB-Out 11412 See Loc-RIB 11413 See RIB-Attributes (RIB-Att) 11414 routeing policy 11415 See policy, routeing 11416 routes 11417 as expressed in UPDATE PDU 45 11418 definition of 27 11419 destinations 27 11420 path attributes 27 11421 October 1993 Inter-Domain Routing Protocol (IDRP) RFC 14xx 11423 +---+ 11424 | U | 11425 +---+ 11427 UPDATE PDU 45, 152 11428 updatesIn 185 11429 updatesOut 185 11431 +---+ 11432 | V | 11433 +---+ 11435 validation of BISPDUs 87 11436 version 185 11437 version negotiation 95 11438 virtual link 11439 See inter-domain link 11441 +---+ 11442 | W | 11443 +---+ 11445 withdrawing routes from 11446 service 45, 46, 126