Internet Draft
Expires May 1995
                                                       C. Kunzinger, Editor
                                                              November 1994


                   INTER-DOMAIN ROUTING PROTOCOL (IDRP)
                  <draft-kunzinger-idrp-ISO10747-01.txt>

   Status of This Memo

      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its Areas,
      and its Working Groups.  Note that other groups may also distribute
      working documents as Internet-Drafts.  Internet-Drafts are draft
      documents valid for a maximum of six months.  Internet-Drafts may
      be updated, replaced, or obsoleted by other documents at any time.
      It is not appropriate to use Internet-Drafts as reference material
      or to cite them other than as a "working draft" or "work in
      progress."

      This draft document contains the complete text of ISO/IEC
      International Standard 10747, which specifies an inter-domain
      routing protocol commonly referred to as "IDRP".  It is made
      available in this form as part of an agreement between the Internet
      Society and ISO/IEC JTC1 (which is responsible for Information
      Technology standards as a joint activity of ISO and IEC).  Those
      figures that could easily be rendered in ASCII are included, but it
      was not possible to create ASCII replicas for all figures included
      in the International Standard. The PostScript version of this
      document that includes all the figures is available (URL =
      ftp://merit.edu/pub/iso/idrp.ps.Z).

   Security Considerations

      Issues concerning the security of routing information exchange
      among border inter-domain routers are discussed in this memo.

   Author's Address

      Charles A. Kunzinger
      IBM Corporation (C70/673)
      P.O. Box 12195
      Research Triangle Park, NC 27709-2195

   Kunzinger                     ISO/IEC 10747                   [ Page 1 ]

      Phone: 919 254 4142
      EMail: kunzinger@vnet.ibm.com
















   Kunzinger                     ISO/IEC 10747                   [ Page 2 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx


   Contents


      1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . .   13

      2.  Normative references   . . . . . . . . . . . . . . . . . . .   14

      3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . .   17
      3.1  Reference model definitions   . . . . . . . . . . . . . . .   17
      3.2  Network layer architecture definitions  . . . . . . . . . .   17
      3.3  Network layer addressing definitions  . . . . . . . . . . .   18
      3.4  Routeing framework definitions  . . . . . . . . . . . . . .   18
      3.5  Intra-domain routeing definitions   . . . . . . . . . . . .   18
      3.6  Additional definitions  . . . . . . . . . . . . . . . . . .   18

      4.  Symbols and abbreviations  . . . . . . . . . . . . . . . . .   21
      4.1  Data unit abbreviations   . . . . . . . . . . . . . . . . .   21
      4.2  Addressing abbreviations  . . . . . . . . . . . . . . . . .   21
      4.3  Other abbreviations   . . . . . . . . . . . . . . . . . . .   22

      5.  General protocol information   . . . . . . . . . . . . . . .   23
      5.1  Inter-RD topology   . . . . . . . . . . . . . . . . . . . .   25
      5.2  Routeing policy   . . . . . . . . . . . . . . . . . . . . .   25
      5.3  Types of systems  . . . . . . . . . . . . . . . . . . . . .   26
      5.4  Types of routeing domains   . . . . . . . . . . . . . . . .   27
      5.5  Routeing domain confederations  . . . . . . . . . . . . . .   27
      5.6  Routes: advertisement and storage   . . . . . . . . . . . .   27
      5.7  Distinguishing path attributes and RIB-Atts   . . . . . . .   28
      5.8  Selecting the information bases   . . . . . . . . . . . . .   29
      5.9  Routeing information exchange   . . . . . . . . . . . . . .   32
        5.9.1  Internal neighbor BIS   . . . . . . . . . . . . . . . .   33
        5.9.2  External neighbor BIS   . . . . . . . . . . . . . . . .   33
      5.10  Routeing domain identifiers  . . . . . . . . . . . . . . .   33
      5.11  Formats of RDIs, NETs, and NSAP addresses  . . . . . . . .   34
      5.12  Design objectives  . . . . . . . . . . . . . . . . . . . .   34
        5.12.1  Within the scope of the protocol   . . . . . . . . . .   34
        5.12.2  Outside the scope of the protocol  . . . . . . . . . .   36

   Kunzinger                     ISO/IEC 10747                   [ Page 2 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      6.  Structure of BISPDUs   . . . . . . . . . . . . . . . . . . .   37
      6.1  Header of BISPDU  . . . . . . . . . . . . . . . . . . . . .   37
      6.2  OPEN PDU  . . . . . . . . . . . . . . . . . . . . . . . . .   40
      6.3  UPDATE PDU  . . . . . . . . . . . . . . . . . . . . . . . .   45
        6.3.1  Path attribute encoding   . . . . . . . . . . . . . . .   47
        6.3.2  Network layer reachability information  . . . . . . . .   59
      6.4  IDRP ERROR PDU  . . . . . . . . . . . . . . . . . . . . . .   61
      6.5  KEEPALIVE PDU   . . . . . . . . . . . . . . . . . . . . . .   64
      6.6  CEASE PDU   . . . . . . . . . . . . . . . . . . . . . . . .   65
      6.7  RIB REFRESH PDU   . . . . . . . . . . . . . . . . . . . . .   65

      7.  Elements of procedure  . . . . . . . . . . . . . . . . . . .   66
      7.1  Naming and addressing conventions   . . . . . . . . . . . .   66
        7.1.1  Interpretation of address information   . . . . . . . .   66
        7.1.2  NSAP address prefixes   . . . . . . . . . . . . . . . .   66
      7.2  Deployment guidelines   . . . . . . . . . . . . . . . . . .   68
        7.2.1  Minimum  configuration of an RD   . . . . . . . . . . .   68
        7.2.2  Deployment of ISs and ESs   . . . . . . . . . . . . . .   68
      7.3  Domain configuration information  . . . . . . . . . . . . .   69
      7.4  Advertising NLRI  . . . . . . . . . . . . . . . . . . . . .   70
      7.5  Receive process   . . . . . . . . . . . . . . . . . . . . .   72
      7.6  BIS-BIS connection management   . . . . . . . . . . . . . .   73
        7.6.1  BIS finite state machines   . . . . . . . . . . . . . .   73
        7.6.2  Closing a connection  . . . . . . . . . . . . . . . . .   87
      7.7  Validation of BISPDUs   . . . . . . . . . . . . . . . . . .   87
        7.7.1  Authentication type 1   . . . . . . . . . . . . . . . .   88
        7.7.2  Authentication type 2   . . . . . . . . . . . . . . . .   88
        7.7.3  Authentication type 3   . . . . . . . . . . . . . . . .   89
        7.7.4  Sequence numbers  . . . . . . . . . . . . . . . . . . .   90
        7.7.5  Flow control  . . . . . . . . . . . . . . . . . . . . .   91
      7.8  Version negotiation   . . . . . . . . . . . . . . . . . . .   95
      7.9  Checksum algorithm  . . . . . . . . . . . . . . . . . . . .   95
      7.10  Routeing information bases   . . . . . . . . . . . . . . .   95
        7.10.1  Identifying an information base  . . . . . . . . . . .   96
        7.10.2  Validation of RIBs   . . . . . . . . . . . . . . . . .   97
        7.10.3  Use of the RIB REFRESH PDU   . . . . . . . . . . . . .   99
      7.11  Path attributes  . . . . . . . . . . . . . . . . . . . . .  100
        7.11.1  Categories of path attributes  . . . . . . . . . . . .  102
        7.11.2  Handling of distinguishing attributes  . . . . . . . .  103
        7.11.3  Equivalent distinguishing attributes   . . . . . . . .  104
      7.12  Path attribute usage   . . . . . . . . . . . . . . . . . .  105
        7.12.1  ROUTE_SEPARATOR  . . . . . . . . . . . . . . . . . . .  105
        7.12.2  EXT_INFO   . . . . . . . . . . . . . . . . . . . . . .  106
        7.12.3  RD_PATH  . . . . . . . . . . . . . . . . . . . . . . .  107
        7.12.4  NEXT_HOP   . . . . . . . . . . . . . . . . . . . . . .  111

   Kunzinger                     ISO/IEC 10747                   [ Page 3 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        7.12.5  DIST_LIST_INCL   . . . . . . . . . . . . . . . . . . .  115
        7.12.6  DIST_LIST_EXCL   . . . . . . . . . . . . . . . . . . .  116
        7.12.7  MULTI-EXIT_DISC  . . . . . . . . . . . . . . . . . . .  117
        7.12.8  TRANSIT DELAY  . . . . . . . . . . . . . . . . . . . .  118
        7.12.9  RESIDUAL ERROR   . . . . . . . . . . . . . . . . . . .  118
        7.12.10  EXPENSE   . . . . . . . . . . . . . . . . . . . . . .  119
        7.12.11  LOCALLY DEFINED QOS   . . . . . . . . . . . . . . . .  120
        7.12.12  HIERARCHICAL RECORDING  . . . . . . . . . . . . . . .  121
        7.12.13  RD_HOP_COUNT  . . . . . . . . . . . . . . . . . . . .  122
        7.12.14  SECURITY  . . . . . . . . . . . . . . . . . . . . . .  123
        7.12.15  CAPACITY  . . . . . . . . . . . . . . . . . . . . . .  123
        7.12.16  PRIORITY  . . . . . . . . . . . . . . . . . . . . . .  124
      7.13  Routeing domain confederations   . . . . . . . . . . . . .  125
        7.13.1  RDC policies   . . . . . . . . . . . . . . . . . . . .  125
        7.13.2  RDC configuration information  . . . . . . . . . . . .  125
        7.13.3  Detecting confederation boundaries   . . . . . . . . .  126
      7.14  Update-Receive process   . . . . . . . . . . . . . . . . .  126
      7.15  Information consistency  . . . . . . . . . . . . . . . . .  127
        7.15.1  Detecting inconsistencies  . . . . . . . . . . . . . .  128
      7.16  Decision process   . . . . . . . . . . . . . . . . . . . .  128
        7.16.1  Phase 1: calculation of degree of preference   . . . .  130
        7.16.2  Phase 2: route selection   . . . . . . . . . . . . . .  130
        7.16.3  Phase 3: route dissemination   . . . . . . . . . . . .  133
        7.16.4  Interaction with update process  . . . . . . . . . . .  135
      7.17  Update-Send process  . . . . . . . . . . . . . . . . . . .  136
        7.17.1  Internal updates   . . . . . . . . . . . . . . . . . .  136
        7.17.2  External updates   . . . . . . . . . . . . . . . . . .  138
        7.17.3  Controlling routeing traffic overhead  . . . . . . . .  139
      7.18  Efficient organization of routeing information   . . . . .  141
        7.18.1  Information reduction  . . . . . . . . . . . . . . . .  141
        7.18.2  Aggregating routeing information   . . . . . . . . . .  142
      7.19  Maintenance of the forwarding information bases  . . . . .  148
      7.20  Error handling for BISPDUs   . . . . . . . . . . . . . . .  149
        7.20.1  BISPDU header error handling   . . . . . . . . . . . .  150
        7.20.2  OPEN PDU error handling  . . . . . . . . . . . . . . .  150
        7.20.3  UPDATE PDU error handling  . . . . . . . . . . . . . .  152
        7.20.4  IDRP ERROR PDU error handling  . . . . . . . . . . . .  155
        7.20.5  Hold timer expired error handling  . . . . . . . . . .  155
        7.20.6  KEEPALIVE PDU error handling   . . . . . . . . . . . .  156
        7.20.7  CEASE PDU error handling   . . . . . . . . . . . . . .  156
        7.20.8  RIB REFRESH PDU error handling   . . . . . . . . . . .  156

      8.  Forwarding process for CLNS  . . . . . . . . . . . . . . . .  156
      8.1  Forwarding to internal destinations   . . . . . . . . . . .  158
      8.2  Determining the NPDU-derived distinguishing attributes  . .  158

   Kunzinger                     ISO/IEC 10747                   [ Page 4 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      8.3  Matching RIB-Att to NPDU-derived distinguishing attributes   160
      8.4  Forwarding to external destinations   . . . . . . . . . . .  162

      9.  Interface to ISO 8473  . . . . . . . . . . . . . . . . . . .  163
      9.1  Use of network layer security protocol over ISO 8473.   . .  165

      10.  Constants   . . . . . . . . . . . . . . . . . . . . . . . .  165

      11.  System management and GDMO definitions  . . . . . . . . . .  167
      11.1  Name binding   . . . . . . . . . . . . . . . . . . . . . .  167
      11.2  Managed objects for IDRP   . . . . . . . . . . . . . . . .  168
      11.3  Packages for IDRP  . . . . . . . . . . . . . . . . . . . .  168
      11.4  Attribute definitions  . . . . . . . . . . . . . . . . . .  175
      11.5  Parameter definitions  . . . . . . . . . . . . . . . . . .  185
      11.6  Behaviour  . . . . . . . . . . . . . . . . . . . . . . . .  187
      11.7  ASN.1 modules  . . . . . . . . . . . . . . . . . . . . . .  188

      12.  Conformance   . . . . . . . . . . . . . . . . . . . . . . .  193
      12.1  Static conformance for all BISs  . . . . . . . . . . . . .  193
      12.2  Conformance to optional functions  . . . . . . . . . . . .  195
        12.2.1  Generation of information in reduced form  . . . . . .  195
        12.2.2  Generation of well-known discretionary attributes  . .  195
        12.2.3  Propagation of well-known discretionary attributes      196
        12.2.4  Peer entity authentication   . . . . . . . . . . . . .  196

      Annex A.  PICS proforma  . . . . . . . . . . . . . . . . . . . .  197
      A.1  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  197
      A.2  Abbreviations and special symbols   . . . . . . . . . . . .  198
        A.2.1  Status symbols  . . . . . . . . . . . . . . . . . . . .  198
      A.3  Instructions for completing the PICS proforma   . . . . . .  198
        A.3.1  General structure of the PICS proforma  . . . . . . . .  198
        A.3.2  Additional information  . . . . . . . . . . . . . . . .  199
        A.3.3  Exception information   . . . . . . . . . . . . . . . .  200
        A.3.4  Conditional status  . . . . . . . . . . . . . . . . . .  200
      A.4  Identification  . . . . . . . . . . . . . . . . . . . . . .  203
        A.4.1  PICS proforma: IDRP implementation identification   . .  203
        A.4.2  PICS proforma: IDRP protocol summary  . . . . . . . . .  204
        A.4.3  PICS proforma: IDRP general   . . . . . . . . . . . . .  204
        A.4.4  PICS proforma: IDRP update send process   . . . . . . .  207
        A.4.5  PICS proforma: IDRP update receive process  . . . . . .  207
        A.4.6  PICS proforma: IDRP decision process  . . . . . . . . .  207
        A.4.7  PICS proforma: IDRP receive process   . . . . . . . . .  208
        A.4.8  PICS proforma: IDRP CLNS forwarding   . . . . . . . . .  210
        A.4.9  PICS proforma: IDRP authentication  . . . . . . . . . .  210
        A.4.10  PICS proforma: IDRP optional transitive attributes      211

   Kunzinger                     ISO/IEC 10747                   [ Page 5 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        A.4.11  PICS proforma: Generating IDRP well-known
         discretionary attributes  . . . . . . . . . . . . . . . . . .  212
        A.4.12  PICS proforma: Propagating IDRP well-known
         discretionary attributes  . . . . . . . . . . . . . . . . . .  214
        A.4.13  PICS proforma: Receiving IDRP well-known discretionary
         attributes  . . . . . . . . . . . . . . . . . . . . . . . . .  216

      Annex B.  IDRP checksum generation algorithm   . . . . . . . . .  218
      B.1  Mathematical notation   . . . . . . . . . . . . . . . . . .  218
      B.2  Algorithm description   . . . . . . . . . . . . . . . . . .  218

      Annex C.  Bibliography   . . . . . . . . . . . . . . . . . . . .  223

      Annex D.  Example of authentication type 2   . . . . . . . . . .  224
      D.1  Authentication mechanism  . . . . . . . . . . . . . . . . .  224

      Annex E.  Jitter algorithm   . . . . . . . . . . . . . . . . . .  228

      Annex F.  Computing a checksum for an Adj-RIB  . . . . . . . . .  230

      Annex G.  RIB overload   . . . . . . . . . . . . . . . . . . . .  231

      Annex H.  Processor overload   . . . . . . . . . . . . . . . . .  233

      Annex J.  Formation of RDCs  . . . . . . . . . . . . . . . . . .  234
      J.1  Forming a new lower level confederation   . . . . . . . . .  234
      J.2  Forming a higher level confederation  . . . . . . . . . . .  236
      J.3  Deleting a lowest level confederation   . . . . . . . . . .  237
      J.4  Deleting a higher level confederation   . . . . . . . . . .  238

      Annex K.  Example usage of MULTI-EXIT_DISC attribute   . . . . .  239

      Annex L.  Syntax and semantics for policy  . . . . . . . . . . .  244
      L.1  Overview  . . . . . . . . . . . . . . . . . . . . . . . . .  244
        L.1.1  Preference statement  . . . . . . . . . . . . . . . . .  245
        L.1.2  Aggregation statement   . . . . . . . . . . . . . . . .  247
        L.1.3  Distribution statement  . . . . . . . . . . . . . . . .  249
      L.2  Policy configuration language BNF   . . . . . . . . . . . .  251
        L.2.1  PREF statement BNF  . . . . . . . . . . . . . . . . . .  251
        L.2.2  AGGR statement BNF  . . . . . . . . . . . . . . . . . .  252
        L.2.3  DIST statement BNF  . . . . . . . . . . . . . . . . . .  252
        L.2.4  Common BNF symbols  . . . . . . . . . . . . . . . . . .  253
      L.3  Simple example  . . . . . . . . . . . . . . . . . . . . . .  257
        L.3.1  Transit domain 3  . . . . . . . . . . . . . . . . . . .  257
        L.3.2  Policy configuration example  . . . . . . . . . . . . .  259

   Kunzinger                     ISO/IEC 10747                   [ Page 6 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        L.3.3  Discussion  . . . . . . . . . . . . . . . . . . . . . .  259

      Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  267















   Kunzinger                     ISO/IEC 10747                   [ Page 7 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Figures


       1.  Field of Application  . . . . . . . . . . . . . . . . . . .   15
       2.  Intermediate Routeing Domains and End Routeing Domains  . .   19
       3.  Position of IDRP within Network Layer   . . . . . . . . . .   24
       4.  Inter-domain Routeing Components  . . . . . . . . . . . . .   24
       5.  Structure of the UPDATE PDU   . . . . . . . . . . . . . . .   46
       6.  Illustration of Authentication Types 1 and 3  . . . . . . .   88
       7.  Routeing Information Base   . . . . . . . . . . . . . . . .   96
       8.  A Transitive Fully Connected Subnetwork   . . . . . . . . .  112
       9.  IDRP Naming and Containment Hierarchy   . . . . . . . . . .  168
      10.  An Example of the Authentication Type 2   . . . . . . . . .  227
      11.  Example 1 Configuration   . . . . . . . . . . . . . . . . .  240
      12.  Example 2 Configuration   . . . . . . . . . . . . . . . . .  241
      13.  A Portion of an Internet  . . . . . . . . . . . . . . . . .  258










   Kunzinger                     ISO/IEC 10747                   [ Page 8 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Tables


       1.  The IDRP Information Bases  . . . . . . . . . . . . . . . .   29
       2.  BIS Finite State Machine  . . . . . . . . . . . . . . . . .   76
       3.  Path Attribute Characteristics  . . . . . . . . . . . . . .  100
       4.  NPDU-Derived Attribute Set  . . . . . . . . . . . . . . . .  159
       5.  IDRP-CL Primitives  . . . . . . . . . . . . . . . . . . . .  164
       6.  Architectural Constants of IDRP   . . . . . . . . . . . . .  166












   Kunzinger                     ISO/IEC 10747                   [ Page 9 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Foreword


      ISO (the International Organization for Standardization) and IEC (the
      International Electrotechnical Commission) form the specialized
      system for worldwide standardization.  National bodies that are
      members of ISO or IEC participate in the development of International
      Standards through technical committees established by the respective
      organization to deal with particular fields of technical activity.
      ISO and IEC technical committees collaborate in fields of mutual
      interest.  Other international organizations, governmental and
      non-governmental, in liaison with ISO and IEC, also take part in the
      work.

      In the field of information technology, ISO and IEC have established
      a joint technical committee, ISO/IEC JTC 1.  Draft International
      Standards adopted by the joint technical committee are circulated to
      the national bodies for voting.  Publication as an International
      Standard requires approval by at least 75% of the national bodies
      casting a vote.

      International Standard ISO 10747 was prepared by Joint Technical
      Committee ISO/IEC JTC 1, Information Technology.







   Kunzinger                     ISO/IEC 10747                  [ Page 10 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Introduction


      This Protocol is one of a set of International Standards which
      facilitate the interconnection of open systems.  They cover the
      services and protocols required to achieve such interconnection.

      This Protocol is positioned with respect to other related standards
      by the layered structure defined in ISO 7498, and by the Network
      layer organization defined in ISO 8648.  It is located at the top of
      the Network layer and relies on the services of ISO 8473.  This
      protocol permits a routeing domain to exchange information with other
      routeing domains to facilitate the operation of the routeing and
      relaying functions of the Network Layer.  It applies to the following
      categories of routeing, which are described in ISO/IEC TR 9575,
      making no distinction between them:

      -   Intra-Administrative Domain routeing between routeing domains
      -   Inter-Administrative Domain routeing between routeing domains.

      Within the hierarchical relations between routeing protocols, as
      described in ISO/IEC TR 9575, this protocol is situated above the
      intra-domain routeing protocols.  That is, this Inter-domain IS-IS
      protocol:

      -   maintains information about the interconnections between routeing
          domains, but does not require detailed information about their
          internal structures

      -   calculates path segments on a hop-by-hop basis

      This protocol calculates path segments which consist of Boundary
      Intermediate systems and the links that interconnect them.  An NPDU
      destined for an End system in another routeing domain will be routed
      via Intra-domain routeing to a Boundary Intermediate system (BIS) in
      the source routeing domain.  Then, the BIS, using the methods of this
      inter-domain routeing protocol, will calculate a path to a Boundary
      Intermediate system in an adjacent routeing domain lying on a path to
      the destination.  After arriving at the next routeing domain, the
      NPDU may also travel within that domain on its way towards a BIS
      located in the next domain along its path.  This process will
      continue on a hop-by-hop basis until the NPDU arrives at a BIS in the

   Kunzinger                     ISO/IEC 10747                  [ Page 11 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      routeing domain which contains the destination End system.  The
      Boundary IS in this routeing domain will hand the incoming NPDU over
      to the domain's intra-domain routeing protocol, which will construct
      a path to the destination End system.

      This inter-domain IS-IS routeing protocol places requirements on the
      type of information that a routeing domain must provide and on the
      methods by which this information will be distributed to other
      routeing domains.  These requirements are intended to be minimal,
      addressing only the interactions between Boundary ISs; all other
      internal operations of each routeing domain are outside the scope of
      this protocol.  That is, this Inter-domain routeing protocol does not
      mandate that a routeing domain run a particular intra-domain routeing
      protocol:  for example, it would be a local choice as to whether a
      domain implements a standard intra-domain protocol (such as ISO/IEC
      10589) or a private protocol.

      The methods of this protocol differ from those generally adopted for
      an intra-domain routeing protocol because they emphasize the
      interdependencies between efficient route calculation and the
      preservation of legal, contractual, and administrative concerns.
      This protocol calculates routes which will be efficient, loop-free,
      and in compliance with the domain's local routeing policies.  IDRP
      may be used when routeing domains do not fully trust each other; it
      imposes no upper limit on the number of routeing domains that can
      participate in this protocol; and it provides isolation between its
      operations and the internal operations of each routeing domain.







   Kunzinger                     ISO/IEC 10747                  [ Page 12 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Information technology - Telecommunications and information exchange
   between systems - Protocol for exchange of inter-domain routeing
   information among intermediate systems to support forwarding of
   ISO 8473 PDUs



   1.  Scope


      This International Standard specifies a protocol to be used by
      Boundary Intermediate systems (defined in 3.6) to acquire and
      maintain information for the purpose of routeing NPDUs between
      different routeing domains.  Figure 1 illustrates the field of
      application of this International Standard.

      This International Standard specifies:

      -   the procedures for the exchange of inter-domain reachability and
          path information between BISs
      -   the procedures for maintaining inter-domain routeing information
          bases within a BIS
      -   the encoding of protocol data units used to distribute
          inter-domain routeing information between BISs
      -   the functional requirements for implementations that claim
          conformance to this International Standard

      The procedures are defined in terms of:

      -   interactions between Boundary Intermediate systems through the
          exchange of protocol data units
      -   interactions between this protocol and the underlying Network
          Service through the exchange of service primitives
      -   constraints on policy feasibility and enforcement which must be
          observed by each Boundary Intermediate system in a routeing
          domain

   Kunzinger                     ISO/IEC 10747                  [ Page 13 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      The boundaries of Administrative Domains are realized as artifacts of
      the placement of policy constraints and the aggregation of network
      layer reachability information; they are not manifested explicitly in
      the protocol.  The protocol described in this International Standard
      operates at the level of individual routeing domains.  The
      establishment of administrative domains is outside the scope of this
      International Standard.


   2.  Normative references


      The following standards contain provisions which, through reference
      in this text, constitute provisions of this International Standard.
      At the time of publication, the editions indicated were valid.  All
      standards are subject to revision, and parties to agreements based on
      this International Standard are encouraged to investigate the
      possibility of applying the most recent editions of the standards
      listed below.  Members of IEC and ISO maintain registers of currently
      valid International Standards.

      ISO 7498: 1984,  Information Processing Systems - Open Systems
      Interconnection - Basic Reference Model.

      ISO 7498/Add. 1:1984,  Information Processing Systems - Open Systems
      Interconnection - Connectionless-mode  transmission.

      ISO 7498:1989,  Information Processing Systems - Open Systems
      Interconnection - Basic Reference Model - Part 3: Naming and
      addressing.

      ISO/IEC 7498,  Information Processing Systems - Open Systems
      Interconnection - Basic Reference Model - Part 4:  Management
      framework.

      ISO/IEC 8208:1990,  &it. Data communications - X.25 Packet Layer
      Protocol for Data Terminal Equipment.

      ISO/IEC 8348:1993,  &it. Network Service Definition.

   Kunzinger                     ISO/IEC 10747                  [ Page 14 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   | :psc=apa.                                                            |
   |                                 inter                                |
   |   +--------------+   +------------------+         +--------------+   |
   |   | End Routeing |   | Transit Routeing |         | End Routeing |   |
   |   |   Domain     |   |      Domain      |         |    Domain    |   |
   |   +--------------+   +------------------+         +--------------+   |
   |          \                  /  |   -                   /             |
   |           \                /   |    -                 /              |
   |            \              /    |     -               /               |
   |             \            /     |      -             /                |
   |        +------------------+    |     +------------------+            |
   |        | Transit Routeing |    |     | Transit Routeing |            |
   |        |      Domain      |    |     |      Domain      |            |
   |        +------------------+    |     +------------------+            |
   |                /     \         |              |                      |
   |               /       \        |              |                      |
   |              /         \       |              |                      |
   |   +--------------+  +------------------+      |                      |
   |   | End Routeing |  | Transit Routeing |      |                      |
   |   |   Domain     |  |      Domain      |      |                      |
   |   +--------------+  +------------------+      |                      |
   |                              |                |                      |
   |                              |                |                      |
   |                              |                |                      |
   |                       +--------------+   +--------------+            |
   |                       | End Routeing |   | End Routeing |            |
   |                       |   Domain     |   |   Domain     |            |
   |                       +--------------+   +--------------+            |
   |                               \               /                      |
   |                                \             /                       |
   |                                 \           /                        |
   |                             +------------------+                     |
   |                             | Transit Routeing |                     |
   |                             |      Domain      |                     |
   |                             +------------------+                     |
   |                                                                      |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 1. Field of Application.   The Inter-domain Routeing Protocol
             operates between routeing domains; intra-domain routeing is
             not within its scope.


   Kunzinger                     ISO/IEC 10747                  [ Page 15 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      ISO 8473:1988,  Information Processing Systems - Data communications
      - Protocol for providing the connectionless-mode network service.

      ISO 8648: 1988,  Information Processing Systems - Telecommunications
      and Information Exchange between Systems - Internal organization of
      the Network Layer.

      ISO 9542:1988,  Information Processing Systems - Telecommunications
      and Information Exchange between Systems - End system to Intermediate
      system routeing exchange protocol for use in conjunction with the
      Protocol for providing the connectionless-mode network service (ISO
      8473).

      ISO/IEC TR 9575:1992,  &it. Telecommunications and Information
      Exchange between Systems - OSI Routeing Framework.

      ISO/IEC TR 9577:1991,  &it. Telecommunications and Information
      Exchange between Systems - Protocol identification in the Network
      Layer.

      ISO/IEC 10030:1990,  &it. Telecommunications and Information Exchange
      between Systems - End System Routeing Information Exchange Protocol
      for use in conjunction with ISO 8878.

      ISO/IES 10589:1992,  &it. Telecommunications and Information Exchange
      between Systems - Intermediate system to intermediate system
      intra-domain routeing information exchange protocol for use in
      conjunction with the protocol for providing the connectionless-mode
      Network Service (ISO 8473).

      ISO/IEC 10165-4:1992,  &it. Open Systems Interconnection - Structure
      of management information - Part 4: Guidelines for the definition of
      managed objects.

      ISO/IEC 10165-2:1992,  &it. Open Systems Interconnection - Structure
      of management information: Definition of management information.




   Kunzinger                     ISO/IEC 10747                  [ Page 16 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   3.  Definitions


      For the purposes of this International Standard, the following
      definitions apply.

   3.1  Reference model definitions

      This International Standard uses the following terms defined in
      ISO 7498:

      a)  Network entity
      b)  Network Layer
      c)  Network Protocol
      d)  Network Protocol Data Unit
      e)  Network relay
      f)  Network Service Access Point
      g)  Network Service Access Point Address
      h)  Real system
      i)  Routeing

      This International Standard uses the following term defined in ISO
      7498-3:

      a)  (N)-entity title

   3.2  Network layer architecture definitions

      This International Standard uses the following terms defined in
      ISO 8648:

      a)  End system
      b)  Intermediate System
      c)  Subnetwork



   Kunzinger                     ISO/IEC 10747                  [ Page 17 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   3.3  Network layer addressing definitions

      This International Standard uses the following term defined in
      ISO/IEC 8348:

      a)  Subnetwork point of attachment

   3.4  Routeing framework definitions

      This International Standard uses the following terms defined in
      ISO 9575:

      a)  Administrative Domain
      b)  Common Domain
      c)  Fire wall
      d)  Routeing Domain

   3.5  Intra-domain routeing definitions

      This International Standard uses the following terms defined in ISO
      10589:

      a)  Adjacency
      b)  Link

   3.6  Additional definitions

      For purposes of this International Standard, the following
      definitions apply:

      3.6.1 Intra-domain IS-IS routeing protocol: A routeing protocol that
      is run between Intermediate systems in a single routeing domain to
      determine routes that pass through only systems and links wholly
      contained within the domain.

      Note 1:  Unless reference is made to a specific protocol, this term
               is used as a general designator, encompassing both private
               and internationally standardized protocols.

      3.6.2 Inter-domain link: A real (physical) or virtual (logical) link
      between two or more Boundary Intermediate systems (see Figure 2).  A
      link between two BISs in the same routeing domain carry both

   Kunzinger                     ISO/IEC 10747                  [ Page 18 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   |                                 irderd                               |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 2. Intermediate Routeing Domains and End Routeing Domains.  The
             classification of a routeing domain as an TRD or an ERD
             depends upon its relaying policies.

      intra-domain traffic and inter-domain traffic; a link between two
      BISs located in adjacent routeing domains can carry inter-domain
      traffic, but not intra-domain traffic.

      3.6.3 Boundary Intermediate system: An intermediate system that runs
      the protocol specified in this International Standard, has at least
      one inter-domain link attached to it, and may optionally have
      intra-domain links attached to it.

      3.6.4 End Routeing Domain: A routeing domain whose local policies
      permit its BISs to calculate inter-domain path segments only for PDUs
      whose source is located within that routeing domain.  There are two
      varieties of End routeing domains: stub and multi-homed.  A stub ERD
      has inter-domain links to only one adjacent routeing domain, while a
      multi-homed ERD has inter-domain links to several adjacent routeing
      domains.

      For example, the domains labelled as multi-homed ERDs in Figure 2
      have policies which prohibit them from providing relaying functions;
      it is these policies, not the topology of their interconnections,
      that make them ERDs.

      3.6.5 Transit Routeing Domain: A routeing domain whose policies
      permit its BISs to calculate inter-domain path segments for PDUs
      whose source is located either in the local routeing domain or in a
      different routeing domain.  That is, it can provide a relaying
      service for such PDUs.  See Figure 2 for an illustration of TRDs.

      3.6.6 Adjacent RDs: Two RDs ("A" and "B") are adjacent to one another
      if there is a at least one pair of BISs, one located in "A" and the
      other in "B", that are attached to each other by means of a real
      subnetwork.

      3.6.7 RD Path: A list of the RDIs of the routeing domains and
      routeing domain confederations through which a given UPDATE PDU has
      travelled.

   Kunzinger                     ISO/IEC 10747                  [ Page 19 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      3.6.8 Routeing Domain Confederation: A set of routeing domains which
      have agreed to join together and to conform to the rules in 7.13 of
      this International Standard.  To the outside world, a confederation
      is indistinguishable from a routeing domain.

      3.6.9 Nested RDCs: A routeing domain confederation "A" (RDC-A) is
      nested within RDC-B when all of the following conditions are
      satisfied simultaneously:

      a)  all members of RDC-A are also members of RDC-B
      b)  there are some members of RDC-B that are not members of RDC-A

      3.6.10 Overlapping RDCs: A routeing domain confederation (RDC-A)
      overlaps RDC-B when all the following conditions are satisfied
      simultaneously:

      a)  there are some members of RDC-A that are also members of RDC-B,
          and
      b)  there are some members of RDC-A that are not members of RDC-B,
          and
      c)  there are some members of RDC-B that are not members of RDC-A.

      3.6.11 Disjoint RDCs: Two routeing domain confederations, RDC-A and
      RDC-B, are disjoint from one another when there are no routeing
      domains which are simultaneously members of both RDC-A and RDC-B.

      3.6.12 Policy Information Base: The collection of routeing policies
      that a BIS will apply to the routeing information that it learns
      using this International standard.  It is not required that all
      routeing domains use the same syntax and semantics to express policy;
      that is, the format of the Policy Information Base is left as a local
      option.

      3.6.13 Route Origin: Each route or component of an aggregated route
      has a single unique origin.  This is the RD or RDC in which the
      route's destinations are located.




   Kunzinger                     ISO/IEC 10747                  [ Page 20 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   4.  Symbols and abbreviations


      The symbols, acronyms, and abbreviations listed in the following
      clauses are used in this International Standard.

   4.1  Data unit abbreviations

      BISPDU  Boundary Intermediate System PDU

      DT PDU  ISO 8473 Data Protocol Data Unit

      ER PDU  ISO 8473 Error Protocol Data Unit

      NPDU    Network Protocol Data Unit

      NSDU    Network Service Data Unit

      PDU     Protocol Data Unit

   4.2  Addressing abbreviations

      AFI     Authority and Format Identifier

      DSP     Domain Specific Part

      IDI     Initial Domain Identifier

      IDP     Initial Domain Part

      LSAP    Link Service Access Point

      NET     Network Entity Title

      NPAI    Network Protocol Address Information

      NSAP    Network Service Access Point

      SNPA    Subnetwork Point of Attachment

   Kunzinger                     ISO/IEC 10747                  [ Page 21 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   4.3  Other abbreviations

      BIS     Boundary Intermediate System

      CL      Connectionless Mode

      CLNS    Connectionless Mode Network Service

      CM      Confederation Member

      ERD     End Routeing Domain

      ES      End System

      FIB     Forwarding Information Base

      FSM     Finite State Machine

      IDRP    Inter-domain Routeing Protocol (an acronym for the protocol
              described in this International Standard)

      IPI     Initial Protocol Identifier

      MIB     Management Information Base

      NLRI    Network layer reachability information

      NLSP    Network layer security protocol

      OSIE    OSI Environment

      PCI     Protocol Control Information

      PIB     Policy Information Base

      QOS     Quality of Service

      RDC     Routeing Domain Confederation

      RDI     Routeing Domain Identifier

      RIB     Routeing Information Base

      SPI     Subsequent Protocol Identifier

   Kunzinger                     ISO/IEC 10747                  [ Page 22 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      SNICP   Subnetwork independent convergence protocol

      TRD     Transit Routeing Domain


   5.  General protocol information


      IDRP is a routeing information exchange protocol which is located
      within the Network layer and interfaces to ISO 8473, which serves as
      a SNICP (see Figure 3).  In particular, BISPDUs are encapsulated as
      the data portion of ISO 8473 NPDUs.  IDRP is a connection-oriented
      protocol which is implemented only in Intermediate systems.  Routeing
      and control information is carried in BISPDUs (as in clause 6), which
      flow on connections between pairs of BISs.  Each BISPDU is packaged
      within one or more NPDUs for transmission by the underlying Network
      service.  IDRP relies on the underlying Network service to provide
      for fragmentation and reassembly of BISPDUs.  IDRP queues Outbound
      BISPDUs as input to the underlying Network Layer service, retaining a
      copy of each BISPDU until an acknowledgement is received.  Similarly,
      inbound BISPDUs are queued as input to the BISPDU-Receive process.

      IDRP exchanges BISPDUs in a reliable fashion.  It provides mechanisms
      for the ordered delivery of BISPDUs and for the detection and
      retransmission of lost or corrupted BISPDUs.  The mechanisms for
      achieving reliable delivery of BISPDUs are described in 7.7; methods
      for establishing BIS-BIS connections are described in 7.6.

      IDRP is consistent with the routeing model presented in ISO TR 9575.
      To emphasize its policy-based nature, the IDRP routeing model
      includes a Policy Information Base, as shown in Figure 4.  IDRP can
      be described in terms of four major components:

      a)  BISPDU-Receive Process:  responsible for accepting and processing
          control and routeing information from the local environment and
          from BISPDUs of other BISs.  This information is used for a
          variety of purposes, such as receiving error reports and
          guaranteeing reliable reception of BISPDUs from neighboring BISs.
          (For example, the Update-Receive process (see 7.14) is the part
          of the BISPDU-Receive process that deals with the reception of

   Kunzinger                     ISO/IEC 10747                  [ Page 23 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   |         ----------     +-------------------+                         |
   |              |         |   Inter-Domain    |                         |
   |              |         | Routeing Protocol |                         |
   |              |         |       (IDRP)      |                         |
   |              |         +-------------------+                         |
   |              |         |                   |                         |
   |           Network      |     ISO 8473      |                         |
   |            Layer       |                   |                         |
   |              |         |                   |                         |
   |              |         |                   |                         |
   |         ----------     +-------------------+                         |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 3. Position of IDRP within Network Layer

          routeing information after a BIS-BIS connection has been
          established.)

      b)  BISPDU-Send Process: responsible for constructing BISPDUs which
          contain control and routeing information.  BISPDUs are used by
          the local BIS for a variety of purposes, such as advertising
          routeing information to other BISs, initiating BIS-BIS
          communication, and validating BIS routeing information bases.

      c)  Decision Process: responsible for calculating routes which will
          be consistent with local routeing policies.  It operates on
          information in both the PIB and the Adj-RIBs, using it to create
          the Local RIBs (Loc-RIBs) and the local Forwarding Information
          Bases (see 7.10).

      d)  Forwarding Process: responsible for supplying resources to
          accomplish relaying of NPDUs to their destinations.  It uses the
          FIB(s) created by the Decision Process.


   +----------------------------------------------------------------------+
   |                                                                      |
   |                                tr95753                               |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 4. Inter-domain Routeing Components

   Kunzinger                     ISO/IEC 10747                  [ Page 24 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   5.1  Inter-RD topology

      This protocol views the overall global OSIE as an arbitrary
      interconnection of Transit Routeing Domains and End Routeing Domains
      which are connected by real inter-domain links placed between BISs
      located in the respective routeing domains.  This International
      Standard provides for the direct exchange of routeing information
      between BISs, which may be located either in the same routeing domain
      or in adjacent routeing domains.

   5.2  Routeing policy

      The direct exchange of policy information is outside the scope of
      IDRP.  Instead, IDRP communicates policy information indirectly in
      its UPDATE PDUs which reflect the effects of the local policies of
      RDs on the path to the destination.  Since all BISs within a routeing
      domain must enforce consistent active routeing policies, IDRP
      provides methods for detecting the existence of active inconsistent
      policies within a routeing domain.  However, the semantics of
      routeing policies and the methods for establishing them are outside
      the scope of this International Standard.

      Note 2:  Annex L illustrates a policy description method and its
               associated semantics as one example of how policies might be
               expressed.

      Each routeing domain chooses its routeing policies independently, and
      insures that all its BISs calculate inter-domain paths which satisfy
      those policies.  Local routeing policies are applied to information
      in the Routeing Information Base (RIB) to determine a degree of
      preference for potential paths (see 7.16).  From those paths which
      are not rejected by the routeing policy, a BIS selects the paths
      which it will use locally; from the locally selected paths, the BIS
      will then select the paths that it will advertise externally.

      To enforce routeing policies and to insure that policies are both
      feasible and consistent, this protocol:

      -   carries path information, expressed in terms of Routeing Domain
          Identifiers (RDIs) and various path attributes, in its UPDATE
          PDUs


   Kunzinger                     ISO/IEC 10747                  [ Page 25 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      -   permits a routeing domain to selectively propagate its
          reachability information to a limited set of other routeing
          domains

      -   provides a method to detect policy inconsistencies within the set
          of BISs located in a single routeing domain

      -   permits each routeing domain to set its policies individually:
          that is, global coordination of policy is not required.

      The set of rules that comprises the routing policy enforced by a BIS
      are held in a Policy Information Base (PIB), which is separate from
      the RIB.  Depending on local Security and QOS requirements, the PIB
      may also contain:

      a)  rules for the aggregation of routes that include the SECURITY and
          LOCALLY DEFINED QOS path attributes (see 7.18.2)

      b)  rules for enforcing local QOS Maintenance Policies and the
          effective Security Policy, during NPDU forwarding

      c)  rules for updating SECURITY and LOCALLY DEFINED QOS path
          attributes in routes that are re-advertised to external routeing
          domains.

   5.3  Types of systems

      An Intermediate system that implements the protocol described in this
      International Standard is called a Boundary Intermediate system
      (BIS).  Each BIS resides in a single routeing domain, and may
      optionally act simultaneously as a BIS and as an intra-domain IS
      within its own routeing domain.  For example, a single system could
      simultaneously play the roles of a BIS for Inter-domain routeing and
      a level-2 IS for Intra-domain routeing as described in ISO/IEC 10589.




   Kunzinger                     ISO/IEC 10747                  [ Page 26 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   5.4  Types of routeing domains

      The protocol described in this International Standard recognizes two
      types of routeing domains, end routeing domains and transit routeing
      domains; each of them may contain both ISs and ESs.

   5.5  Routeing domain confederations

      IDRP provides support for Routeing Domain Confederations (RDCs); this
      optional function permits groups of routeing domains to be organized
      in a hierarchical fashion.

      An RDC is formed by means outside the scope of this protocol, and
      composed of a set of confederation members.  Confederation members
      (CMs) are either individual routeing domains or routeing domain
      confederations.  Thus, the definition of an RDC is recursive: a
      confederation member may be a single routeing domain or another
      confederation.

   5.6  Routes: advertisement and storage

      For purposes of this protocol, a route is defined as a unit of
      information that pairs destinations with the attributes of a path to
      those destinations:

      -   Routes are advertised between a pair of BISs in UPDATE PDUS: the
          destinations are the systems whose NSAP prefixes are reported in
          the NLRI field, and the path is the information reported in the
          path attributes fields of the same UPDATE PDU.

      -   Routes are stored in the Routeing Information Bases:  namely, the
          Adj-RIBs-In, the Loc-RIBs, and the Adj-RIBs-Out.  Routes that
          will be advertised to other BISs must be present in the
          Adj-RIBs-Out; routes that will be used by the local BIS must be
          present in the Loc-RIBs, and the next hop for each of these
          routes must present in the local BIS's Forwarding Information
          Bases; and routes that are received from other BISs are present
          in the Adj-RIBs-In.

      -   A Route-ID is assigned to each route that is advertised by a BIS.
          This identifier is unambiguous in the context of the BIS-BIS
          connection between the advertising BIS and the receiving BIS.

   Kunzinger                     ISO/IEC 10747                  [ Page 27 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      A BIS can support multiple routes to the same destination by
      maintaining multiple RIBs and the corresponding multiple FIBs.  Each
      Loc-RIB will be identified by a different RIB-Att (see 5.7 and 5.8);
      an Adj-RIB-Out shall contain at most one route to a particular
      destination.

      If the BIS chooses to advertise the route, it may add to or modify
      the path attributes of the route before advertising it to adjacent
      BISs.  For example, it is possible under certain circumstances to
      aggregate path attributes, NLRI, or entire routes, as described more
      fully in 7.18.2; or, as another example, the further distribution of
      a route may be restricted through the use of the DIST_LIST_EXCL
      attribute, as described in 7.12.6.

      IDRP also provides mechanisms by which a BIS can inform its neighbor
      that a previously advertised route is no longer available for use.
      There are three methods by which a given BIS can indicate that a
      route has been withdrawn from service:

      a)  the Route-ID for a previously advertised route can be advertised
          in the WITHDRAWN ROUTES field of an UPDATE PDU, thus marking the
          associated route as being no longer available for use
      b)  a replacement route (with the same distinguishing attributes and
          NLRI) can be advertised, or
      c)  the BIS-BIS connection can be closed, which implicitly removes
          from service all routes which the pair of BISs had advertised to
          each other.

   5.7  Distinguishing path attributes and RIB-Atts

      Certain path attributes are classified as Distinguishing Attributes.
      Each distinct combination of such attributes identifies a particular
      information base which will be used to store information about the
      route.  Each combination of distinguishing attributes is called a
      RIB-Att (RIB attribute); the RIB-Att is a common identifier for the
      Adj-RIB-In, Loc-RIB, Adj-RIB-Out, and FIB with which the route
      information is associated.

      The number of RIB-Atts is limited by the number of distinct sets of
      permissible distinguishing attributes (see 7.11.2); this in turn
      limits the number of RIBs and FIBs that a BIS can support.  The
      number of RIBs and FIBs can be further constrained by local
      decisions--a BIS may choose to support only a limited number of

   Kunzinger                     ISO/IEC 10747                  [ Page 28 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      distinct routeing information bases (that is, a limited number of
      RIB-Atts, as described in 7.10.1).

   5.8  Selecting the information bases

      Each RIB is identified by a RIB-Att (RIB attribute), and the same
      RIB-Att also uniquely identifies the associated FIB.

      For an UPDATE PDU, the BIS determines the ROUTE_ID, LOCAL_PREF, and
      the set of distinguishing path attributes associated with each route
      that is advertised.  The set of distinguishing path attributes
      contained between a pair of consecutively occurring ROUTE_SEPARATORs
      or between the last ROUTE_SEPARATOR and the end of the BISPDU
      unambiguously determine the RIB-Att for that route.

      For an NPDU, the BIS unambiguously determines the FIB that should be
      used for forwarding this NPDU.  It maps certain fields in NPDU's
      header into a RIB-Att, which then unambiguously identifies a
      particular FIB (see 8.2 and 8.3).

      A summary of IDRP's information bases is presented in Table 1.

   +----------------------------------------------------------------------+
   | Table 1 (Page 1 of 3). The IDRP Information Bases.  The indexing     |
   |                        variables and contents of the RIBs and FIBs   |
   |                        are shown.                                    |
   +-----------------+-----------------+----------------------------------+
   | Information     | Indexed by...   | Contains...                      |
   | Base            |                 |                                  |
   +-----------------+-----------------+----------------------------------+
   |  Adj-RIB-In     | -   NET of      | -   Path attributes              |
   |                 |     adjacent    | -   NLRI                         |
   |                 |     BIS         |                                  |
   |                 | -   RIB-Atts    |                                  |
   |                 | -   Route-ID    |                                  |
   +-----------------+-----------------+----------------------------------+
   |  Loc-RIB        | -   RIB-Atts    | -   Path attributes              |
   |                 |                 | -   NLRI                         |
   +-----------------+-----------------+----------------------------------+



   Kunzinger                     ISO/IEC 10747                  [ Page 29 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   | Table 1 (Page 2 of 3). The IDRP Information Bases.  The indexing     |
   |                        variables and contents of the RIBs and FIBs   |
   |                        are shown.                                    |
   +-----------------+-----------------+----------------------------------+
   | Information     | Indexed by...   | Contains...                      |
   | Base            |                 |                                  |
   +-----------------+-----------------+----------------------------------+
   |  Adj-RIB-Out    | -   NET of      | -   Path attributes              |
   |                 |     adjacent    | -   NLRI                         |
   |                 |     BIS         |                                  |
   |                 | -   RIB-Atts    |                                  |
   |                 | -   Route-ID    |                                  |
   +-----------------+-----------------+----------------------------------+











   Kunzinger                     ISO/IEC 10747                  [ Page 30 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   | Table 1 (Page 3 of 3). The IDRP Information Bases.  The indexing     |
   |                        variables and contents of the RIBs and FIBs   |
   |                        are shown.                                    |
   +-----------------+-----------------+----------------------------------+
   | Information     | Indexed by...   | Contains...                      |
   | Base            |                 |                                  |
   +-----------------+-----------------+----------------------------------+
   |  FIB            | -   RIB-Atts    | -   NET of next hop BIS          |
   |                 | -   NLRI        | -   Output SNPA of local BIS     |
   |                 |                 | -   Input SNPA of next hop BIS   |
   |                 |                 | -   minimum priority associated  |
   |                 |                 |     with this subnetwork, when   |
   |                 |                 |     the RIB-Att contains the     |
   |                 |                 |     PRIORITY attribute           |
   |                 |                 | -   security related information |
   |                 |                 |     associated with this         |
   |                 |                 |     subnetwork, when the RIB-Att |
   |                 |                 |     contains the SECURITY        |
   |                 |                 |     attribute                    |
   |                 |                 | -   QOS metric value, when the   |
   |                 |                 |     RIB-Att contains a RESIDUAL  |
   |                 |                 |     ERROR, TRANSIT DELAY,        |
   |                 |                 |     EXPENSE, or LOCALLY DEFINED  |
   |                 |                 |     QOS attribute                |
   +-----------------+-----------------+----------------------------------+







   Kunzinger                     ISO/IEC 10747                  [ Page 31 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   | Notes:                                                               |
   |                                                                      |
   | a)  As a local option, a BIS may elect to apply information          |
   |     reduction techniques to path attributes and NLRI information.    |
   |                                                                      |
   | b)  For each adjacent BIS, a given BIS maintains an Adj-RIB-In for   |
   |     each RIB-Att (including the Empty RIB-Att) that it supports.     |
   |                                                                      |
   | c)  A BIS maintains a separate Loc-RIB for each RIB-Att (including   |
   |     the Empty RIB-Att) that it supports.                             |
   |                                                                      |
   | d)  For each adjacent BIS, a given BIS maintains an Adj-RIB-Out for  |
   |     each set of RIB-Atts (including the Empty RIB-Att) that it       |
   |     advertises to that neighbor.                                     |
   |                                                                      |
   | e)  A given BIS maintains a separate FIB for each set of RIB-Atts    |
   |     (including the empty RIB-Att) that it supports-- that is, each   |
   |     FIB corresponds to a Loc-RIB.                                    |
   |                                                                      |
   |     To facilitate the forwarding process, a BIS can organize each of |
   |     its FIBS into two conceptual parts:  one containing information  |
   |     for NLRI located within its own RD, and another for NLRI located |
   |     in other RDs (as in clause 8).  For external NLRI, a BIS can     |
   |     further organize the FIB information based on whether the        |
   |     next-hop-BIS is located within its own RD or in another RD (see  |
   |     8.4, items "a" and "b").  And finally, for those next-hop BISs   |
   |     located in its own RD, the local BIS can organize the            |
   |     information according to a specific forwarding mechanism (see    |
   |     8.4, items "b1" and  "b2").                                      |
   +----------------------------------------------------------------------+

   5.9  Routeing information exchange

      This International Standard provides several rules governing the
      distribution and exchange of routeing information:

      -   rules for distributing routeing information internally (to BISs
          within a routeing domain)

      -   rules for distributing routeing information externally (to BISs
          in adjacent routeing domains)

   Kunzinger                     ISO/IEC 10747                  [ Page 32 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Routeing information is carried in the protocol's BISPDUs, which are
      generated on an event-driven basis whenever a BIS receives
      information which causes it advertise new paths.

   5.9.1  Internal neighbor BIS

      Each BIS establishes and maintains communications with all other BISs
      located in its routeing domain.  The identity of all BISs within a
      routeing domain is contained in managed object INTERNAL_BIS described
      in 7.3.

   5.9.2  External neighbor BIS

      Each BIS may establish and maintain communications with other BISs in
      adjacent routeing domains.  A BIS has no direct communications link
      with any BIS in another routeing domain unless that RD is adjacent to
      it, as defined in 3.6: that is, a BIS does not communicate directly
      with a BIS located in a different routeing domain unless the pair of
      BISs are attached to at least one common subnetwork.  The identity of
      neighbor BISs in adjacent routeing domains is contained in managed
      object EXTERNAL-BIS-NEIGHBORS described in 7.3.

      Note 3:  In the absence of an implementation specific method for
               ascertaining that a neighbor BIS listed in managed object
               EXTERNAL-BIS-NEIGHBORS is located on a common subnetwork
               with itself, a local BIS can include the ISO 8473 Complete
               Route Record parameter so that the recipient of the BISPDU
               can determine whether the sending BIS is located on the same
               subnetwork as itself.

   5.10  Routeing domain identifiers

      Each routeing domain (RD) and routeing domain confederations (RDC)
      whose BIS(s) implement the protocol described in this International
      Standard shall have an unambiguous routeing domain identifier (RDI),
      which is a generic Network entity title, as described in ISO 7498.

      An RDI is assigned statically in accordance with ISO/IEC 8348, and
      does not change based on the operational status of the routeing
      domain.  An RDI identifies a routeing domain or a confederation
      uniquely, but does not necessarily convey any information about its
      policies or the identities of its members.

   Kunzinger                     ISO/IEC 10747                  [ Page 33 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   5.11  Formats of RDIs, NETs, and NSAP addresses

      Within routeing domains whose BISs implement the protocol defined in
      this International Standard, RDIs, NETs and NSAP addresses shall be
      structured as described in 7.1.

      All Boundary Intermediate systems shall be able to generate and
      forward PDUs containing NSAP addresses or NETs whose abstract syntax
      is as described in ISO/IEC 8348.

   5.12  Design objectives

      The protocol described in this international standard was developed
      with a view towards satisfying certain design goals, while others
      specifically were not addressed by the mechanisms of this protocol.

   5.12.1  Within the scope of the protocol

      This International Standard supports the following design
      requirements:

      Control Transit through an RD: It provides mechanisms to permit a
        given routeing domain to control the ability of NPDUs from other
        routeing domains to transit through itself.

      Network Layer Protocol Compatibility: It does not require that any
        changes be made to the following existing Network layer protocols:
        ISO 8473, ISO 9542, ISO/IEC 10030, ISO/IEC 10589, and ISO/IEC 8208.

      Autonomous Operation: It provides stable operation in the global OSIE
        where significant sections of the interworking environment will be
        controlled by disjoint entities.

      Distributed Information Bases: It does not require a centralized
        global repository for either routeing information or policy
        information.

      QOS-based Routeing: It provides the ability to select routes based on
        the QOS characteristics of the NPDUs.

      Deliverability: It accepts and delivers NPDUs addressed to reachable
        routeing domains and rejects NPDUs addressed to routeing domains
        known to be unreachable.

   Kunzinger                     ISO/IEC 10747                  [ Page 34 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Adaptability: It adapts to topological changes between routeing
        domains, but not to traffic changes.

      Promptness: It provides a period of adaptation to topological changes
        between domains that is a reasonable function of the maximum
        logical distance between any pair of routeing domains participating
        in an instance of this protocol.

      Efficiency: It is efficient in the use of both processing resources
        and memory resources; it does not create excessive routeing traffic
        overhead.

      Robustness: It recovers from transient errors such as lost or
        temporarily incorrect routeing PDUs, and it tolerates imprecise
        parameter settings.

      Stability: It stabilizes in finite time to "good routes", as long as
        there are no continuous topological changes or corruptions of the
        routeing and policy information bases.

      Heterogeneity: It is designed to operate correctly over a set of
        routeing domains that may employ diverse intra-domain routeing
        protocols. It is capable of running over a wide variety of
        subnetworks, including but not limited to:  ISO/IEC 8208 and X.25
        subnetworks, PSTN networks, and the OSI Data Link Service.

      Availability: It will not result in inability to calculate acceptable
        inter-domain paths when a single point of failure happens for a
        pairing of topology and policy that have a cut set greater than
        one.

      Fire walls: It will provide fire walls so that:

        -   Problems within one routeing domain will not affect
            intra-domain routeing in any other routeing domain
        -   Problems within one routeing domain will not affect
            inter-domain routeing, unless they occur on internal
            inter-domain links
        -   Inter-domain routeing will not adversely affect intra-domain
            routeing.

      Scaling: It imposes no upper limit on the number of routeing domains
        that can participate in a single instance of this protocol.


   Kunzinger                     ISO/IEC 10747                  [ Page 35 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Multiple Routeing Administrations: It will accommodate inter-domain
        route calculations without regard to whether or not the
        participating routeing domains are under control of one or several
        administrative authorities.

   5.12.2  Outside the scope of the protocol

      The following requirements are not within the design scope of this
      protocol:

      User Data Security: The security of user data carried within an NPDU
        is outside the scope of this protocol.  This protocol is not
        designed to serve as a substitute for conventional data security
        practices.  However, it can provide a security-related facility to
        the extent that route computation can be based upon the contents of
        the ISO 8473 security parameter.

      Traffic Adaptation: It does not automatically modify routes based on
        the traffic load.

      Guaranteed delivery: It does not guarantee delivery of all offered
        NPDUs.

      Repair of Partitioned Routeing Domains: It does not use paths
        external to a partitioned routeing domain to repair the partition.

      Repair of Partitioned Routeing Domain Confederations: It does not use
        paths external to a partitioned routeing domain confederation to
        repair the partition.

      Shared Use of Inter-domain Links: It will not permit an external
        inter-domain link to carry intradomain traffic.

      Suppression of Transient Loops: Although it provides mechanisms to
        detect and suppress looping of routeing information, it provides no
        mechanisms to detect or suppress transient looping of ISO 8473
        NPDUs.



   Kunzinger                     ISO/IEC 10747                  [ Page 36 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   6.  Structure of BISPDUs


      In this document, the term BISPDU  (Boundary IS PDU) is used as a
      general term to refer to any of the PDUs defined in this clause.

      Octets in a PDU are numbered starting from 1, in increasing order.
      Bits in an octet are numbered from 1 to 8, where bit 1 is the
      low-order bit and is pictured on the right.  When consecutive octets
      are used to represent a number, the lower octet number has the most
      significant value.  The more significant semi-octet of each pair of
      semi-octets in a given octet is encoded in the high order bit
      positions (8 through 5).

      Values are given in decimal, and all numeric fields are unsigned,
      unless otherwise noted.

      The types of PDUs used by this protocol are:

      -   OPEN PDU
      -   UPDATE PDU
      -   IDRP ERROR PDU
      -   KEEPALIVE PDU
      -   CEASE PDU
      -   RIB REFRESH PDU

   6.1  Header of BISPDU

      Each BISPDU has a fixed size header.  There may or may not be a data
      portion following the header, depending on the PDU type.

      The layout of the header fields and their meanings are shown below:

      +-------------------------------------------------------------------+
      | Inter-domain Routeing Protocol Identifier (1 octet)               |
      +-------------------------------------------------------------------+
      | BISPDU Length (2 octets)                                          |
      +-------------------------------------------------------------------+
      | BISPDU Type (1 octet)                                             |
      +-------------------------------------------------------------------+

   Kunzinger                     ISO/IEC 10747                  [ Page 37 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      +-------------------------------------------------------------------+
      | Sequence (4 octets)                                               |
      +-------------------------------------------------------------------+
      | Acknowledgement (4 octets)                                        |
      +-------------------------------------------------------------------+
      | Credit Offered (1 octet)                                          |
      +-------------------------------------------------------------------+
      | Credit Available (1 octet)                                        |
      +-------------------------------------------------------------------+
      | Validation Pattern (16 octets)                                    |
      +-------------------------------------------------------------------+

      The meaning and use of these fields are as follows:

      Inter-domain Routeing Protocol Identifier: An architectural constant
        for use in identifying the protocol by the methods of ISO DTR 9577.

      BISPDU Length: The BISPDU Length field is a 2 octet unsigned integer.
        It contains the total length in octets of this BISPDU, including
        both header and data portions.  The value of the BISPDU Length
        field shall be at least MinBISPDULength octets, and no greater than
        the value carried in the Maximum_PDU_Size field of the OPEN PDU
        received from the remote BIS.

        Further, depending on the PDU type, there may be other constraints
        on the value of the Length field; for example, a KEEPALIVE PDU must
        have a length of exactly 30 octets.  No padding after the end of
        BISPDU is allowed, so the value of the Length field must be the
        smallest value required given the rest of the BISPDU.

      BISPDU Type: The BISPDU Type field contains a one octet type code
        which identifies the specific type of the PDU.  The supported type
        codes are:

        +----------------------------------------------------+------------+
        | BISPDU Type                                        | Code       |
        +----------------------------------------------------+------------+
        | OPEN PDU                                           | 1          |
        +----------------------------------------------------+------------+
        | UPDATE PDU                                         | 2          |
        +----------------------------------------------------+------------+
        | IDRP ERROR PDU                                     | 3          |
        +----------------------------------------------------+------------+
        | KEEPALIVE PDU                                      | 4          |
        +----------------------------------------------------+------------+

   Kunzinger                     ISO/IEC 10747                  [ Page 38 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        +----------------------------------------------------+------------+
        | BISPDU Type                                        | Code       |
        +----------------------------------------------------+------------+
        | CEASE PDU                                          | 5          |
        +----------------------------------------------------+------------+
        | RIB REFRESH PDU                                    | 6          |
        +----------------------------------------------------+------------+

        All other BISPDU type codes are reserved for future extensions.

      Sequence: The Sequence field contains a 4 octet unsigned integer that
        is the sequence number of this PDU.  The procedures for generating
        sequence numbers for the various types of BISPDU are described in
        7.7.4.

      Acknowledgement: The Acknowledgment field is a 4 octet unsigned
        integer that contains the sequence number of the PDU that the
        sender last received correctly and in sequence number order.

      Credit Offered: The contents of this field indicate the number of
        additional BISPDUs that the sender is willing to accept from the
        remote BIS; it is used by the flow control process described in
        7.7.5.

      Credit Available: The contents of this field indicate the number of
        additional BISPDUs that the sender is able to send to the remote
        BIS; it is used by the flow control process described in 7.7.5.

      Validation Pattern: This 16-octet field is used to provide a
        validation function for the BISPDU.  Depending upon the contents of
        the field "Authentication Code" of the OPEN PDU, this field can
        provide:

        -   data integrity for the contents of the BISPDU (see 7.7.1 and
            7.7.3), or
        -   data integrity for the contents of the BISPDU plus
            authentication of the peer BIS (see 7.7.2).




   Kunzinger                     ISO/IEC 10747                  [ Page 39 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   6.2  OPEN PDU

      The OPEN PDU is used by a BIS for starting a BIS-BIS connection.  The
      first PDU sent by either side is an OPEN PDU.

      The OPEN PDU contains a fixed header and the additional fields shown
      below:

      +-------------------------------------------------------------------+
      | Fixed Header                                                      |
      +-------------------------------------------------------------------+
      | Version (1 octet)                                                 |
      +-------------------------------------------------------------------+
      | Hold Time (2 octets)                                              |
      +-------------------------------------------------------------------+
      | Maximum PDU Size (2 octets)                                       |
      +-------------------------------------------------------------------+
      | Source RDI Length Indicator (1 octet)                             |
      +-------------------------------------------------------------------+
      | Source RDI (variable)                                             |
      +-------------------------------------------------------------------+
      | RIB-AttsSet (variable)                                            |
      +-------------------------------------------------------------------+
      | Confed-IDs (variable)                                             |
      +-------------------------------------------------------------------+
      | Authentication Code (1 octet)                                     |
      +-------------------------------------------------------------------+
      | Authentication Data (variable)                                    |
      +-------------------------------------------------------------------+

      The meaning and use of these fields are as follows:

      Version: This one octet field contains the version number of the
        protocol.  Its value is currently 1.

      Hold Time: This field contains a 2 octet unsigned integer that is the
        maximum number of seconds that this BIS will allow the FSM for a
        given BIS-BIS connection to remain in the ESTABLISHED state without
        receipt of a KEEPALIVE, UPDATE, or RIB REFRESH PDU from the peer
        BIS.  (See 7.6.1.4 and 7.20.5.)

      Maximum PDU Size: This field contains a 2 octet unsigned integer that
        is the maximum number of octets that this BIS will accept in an
        incoming UPDATE PDU, IDRP ERROR PDU, or RIB REFRESH PDU.

   Kunzinger                     ISO/IEC 10747                  [ Page 40 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        Independent of this value, every BIS shall accept KEEPALIVE PDUs or
        CEASE PDUs of length 30 octets; every BIS shall also accept any
        OPEN PDU with length less than or equal to 3000 octets.

        As a minimum, every BIS is required to support reception of all
        BISPDUs whose size is greater than or equal to MinBISPDULength
        octets and less than or equal to 1024 octets: that is, the minimum
        acceptable value for this field is 1024.

      Source RDI Length Indicator: This one octet field contains the length
        in octets of the Source RDI field.

      Source RDI: This variable length field contains the RDI of the
        routeing domain in which the BIS that is sending this BISPDU is
        located.

      RIB-AttsSet: This variable length field contains a list of all
        RIB-Atts that the local BIS is willing to support when
        communicating with the neighbor BIS (that is, the BIS to which this
        OPEN PDU is being sent).  It contains an encoding of all or part of
        the information contained in managed object RIBAttsSet (See 7.3 and
        7.10.1).

        A BIS is not required to list all of its supported RIB-Atts in an
        OPEN PDU that is sent to a neighbor BIS located in an adjacent
        routeing domain.  It must include only those RIB-Atts that
        correspond to Adj-RIBs-Out that the local BIS will use to
        communicate with the neighbor BIS, and those that correspond to the
        RIB-Atts of the Adj-RIBs-In that the local BIS supports for storing
        UPDATE PDUs received from that neighbor BIS.

        However, a BIS shall include all of the RIB-Atts listed in managed
        object RIBAttsSet in an OPEN PDU that is sent to another BIS
        located in its own routeing domain.  Failure to do so will result
        in an OPEN PDU error, as described in 7.20.2.

        The encoding of this field is as follows:




   Kunzinger                     ISO/IEC 10747                  [ Page 41 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        +-----------------------------------------------------------------+
        | Number of Non-empty RIB-Atts                                    |
        +-----------------------------------------------------------------+
        | Number of Distinguishing Attributes in First RIB-Att            |
        +-----------------------------------------------------------------+
        | First attribute, first RIB-Att                                  |
        +-----------------------------------------------------------------+
        | ....                                                            |
        +-----------------------------------------------------------------+
        | Last Attribute, first RIB-Att                                   |
        +-----------------------------------------------------------------+
        | Number of Distinguishing Attributes in Second RIB-Att           |
        +-----------------------------------------------------------------+
        | First attribute, second RIB-Att                                 |
        +-----------------------------------------------------------------+
        | ....                                                            |
        +-----------------------------------------------------------------+
        | Last Attribute, second RIB-Att                                  |
        +-----------------------------------------------------------------+
        | ...                                                             |
        +-----------------------------------------------------------------+
        | Number of Distinguishing Attributes in Nth RIB-Att              |
        +-----------------------------------------------------------------+
        | First attribute, Nth RIB-Att                                    |
        +-----------------------------------------------------------------+
        | ....                                                            |
        +-----------------------------------------------------------------+
        | Last Attribute, Nth RIB-Att                                     |
        +-----------------------------------------------------------------+
        | ...                                                             |
        +-----------------------------------------------------------------+
        | Number of Distinguishing Attributes in Last RIB-Att             |
        +-----------------------------------------------------------------+
        | First attribute, last RIB-Att                                   |
        +-----------------------------------------------------------------+
        | ....                                                            |
        +-----------------------------------------------------------------+
        | Last Attribute, last RIB-Att                                    |
        +-----------------------------------------------------------------+

        The field Number of RIB-Atts is one octet long.  It contains the
        total number of non-empty RIB-Atts supported by this BIS.  Since
        every BIS supports an empty RIB-Att (see 7.10.1), the empty RIB-Att
        shall not be listed in the OPEN PDU.

   Kunzinger                     ISO/IEC 10747                  [ Page 42 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        If a BIS supports no RIB-Atts other than the empty RIB-Att, then
        the field Number of Non-empty RIB-Atts shall contain 0.

        If the Number of Non-Empty RIB-Atts is non-zero, then the BIS
        supports all of the listed RIB-Atts plus the empty RIB-Att.

        Each field Number of Distinguishing Attributes in the Nth Set is
        one octet long, and it contains the number of distinguishing
        attributes that are contained in the Nth RIB-Att.  Since a RIB-Att
        consists of a set of distinguishing attributes, there is no
        significance to the order in which the distinguishing attributes of
        a given RIB-Att are listed.

        Each of the individual attributes in a set is encoded as follows:

        -   a type specific distinguishing attribute (see 7.11.2) is
            encoded as a single octet, using the type code specified in 6.3
            for the corresponding UPDATE PDU path attribute.

        -   a type-value-specific distinguishing attribute (see 7.11.2) is
            encoded as a triple <type, length, value>, using the type code
            for the attribute, the length in octets of the subsequent
            value, and the value itself.  The value is encoded as follows
            for the following distinguishing attributes:

            SECURITY: The value shall contain the Security Registration
              Identifier that identifies the Security Authority for which
              security related information is supported by this RIB-Att,
              encoded identically to the encoding of the SECURITY attribute
              specified in 6.3.1.14 including length fields, but with a
              zero length security information.

            LOCALLY DEFINED QOS: The value shall comprise the NSAP Address
              Prefix of the QoS Authority and the QoS value that identifies
              the QoS measurement, encoded identically to the encoding of
              the LOCALLY DEFINED QOS attribute specified in 6.3.1.11
              including length fields, but with a zero length metric.

      Confed-IDs: This is a variable length field which reports the RDIs of
        all RDCs that this BIS is a member of.  The encoding of this field
        is as follows:

        +-----------------------------------------------------------------+
        | Number of RDCs (1 octet)                                        |
        +-----------------------------------------------------------------+

   Kunzinger                     ISO/IEC 10747                  [ Page 43 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        +-----------------------------------------------------------------+
        | Length of First RDI (1 octet)                                   |
        +-----------------------------------------------------------------+
        | RDI of first RDC                                                |
        +-----------------------------------------------------------------+
        | ....                                                            |
        +-----------------------------------------------------------------+
        | Length of Last RDI (1 octet)                                    |
        +-----------------------------------------------------------------+
        | RDI of last confederation                                       |
        +-----------------------------------------------------------------+

        The 1 octet field Number of RDCs gives the number of RDCs of which
        this BIS is a member.  A value of zero indicates that this BIS
        participates in no RDCs.

        For each such confederation, the following fields give the length
        and RDI for each confederation, where each RDI is encoded according
        to the preferred binary encoding of ISO/IEC 8348.

      Authentication Code: This 1-octet unsigned integer indicates the
        authentication mechanism being used:

        a)  Code 1 indicates that the Validation Pattern field in the
            header of each BISPDU contains an unencrypted checksum that
            provides data integrity for the contents of that BISPDU.  Its
            use is described in 7.7.1 Its use is described in 7.7.1.

        b)  Code 2 indicates that the Validation Pattern field in the
            header of each BISPDU provides both peer-BIS authentication and
            data integrity for the contents of the BISPDU.  The specific
            mechanism used to generate the validation pattern is mutually
            agreed to by the pair of BISs, but is not specified by this
            International Standard.  Its use is described in 7.7.2.

        c)  Code 3 indicates that the Validation Pattern field in the
            header of each BISPDU contains an unencrypted checksum covering
            the concatenation of the contents of the BISPDU with
            untransmitted password string(s).  Its use is defined in 7.7.3.

      Authentication Data: The form and meaning of this field is a
        variable-length field that depends on the Authentication Code, as
        described in clause D.1.  The length of the authentication data
        field can be determined from the Length field of the BISPDU header.

   Kunzinger                     ISO/IEC 10747                  [ Page 44 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   6.3  UPDATE PDU

      An UPDATE PDU is used to advertise feasible routes to a neighbor BIS,
      or to withdraw multiple unfeasible routes from service (see 5.6).
      An UPDATE PDU may simultaneously advertise multiple feasible routes
      and withdraw multiple unfeasible routes from service.  The UPDATE PDU
      always includes the fixed header, Unfeasible Route Count field, and
      Total Path Length Attributes field; it can optionally contain the
      other fields shown in Figure 5:

      -   if routes are being explicitly withdrawn from service, then the
          UNFEASIBLE ROUTE COUNT field will be non-zero, and the WITHDRAWN
          ROUTES fields will be present

      -   if feasible routes are being advertised, then the TOTAL PATH
          ATTRIBUTES LENGTH field will be non-zero, and the PATH ATTRIBUTES
          and NLRI fields will be present.

      An UPDATE PDU can advertise multiple routes; a route is described by
      several path attributes, each of which is encoded as a 4-tuple.  All
      path attributes contained in a given UPDATE PDU apply to the
      destinations carried in the Network Layer Reachability Information
      field of the UPDATE PDU.

      An UPDATE PDU can list multiple routes to be withdrawn from service.
      Each such route is identified by its Route-ID, which unambiguously
      identifies the route in the context of the BIS-BIS connection in
      which it had been previously been advertised.

      An UPDATE PDU that is used only to withdraw routes from service (but
      not to advertise any feasible routes) will not include Path
      Attributes or NLRI.  Conversely, if an UPDATE PDU does not withdraw
      any routes from service, the UNFEASIBLE ROUTE COUNT field will
      contain the value 0, and WITHDRAWN ROUTES field will not be present.

      The components of the UPDATE PDU are described below:

      +-------------------------------------------------------------------+
      | Fixed Header                                                      |
      +-------------------------------------------------------------------+
      | Unfeasible Route Count (2 octets)                                 |
      +-------------------------------------------------------------------+
      | Withdrawn Routes (variable)                                       |
      +-------------------------------------------------------------------+

   Kunzinger                     ISO/IEC 10747                  [ Page 45 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   |                                update4                               |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 5. Structure of the UPDATE PDU

      +-------------------------------------------------------------------+
      | Total Path Attributes Length (2 octets)                           |
      +-------------------------------------------------------------------+
      | Path Attributes (variable)                                        |
      +-------------------------------------------------------------------+
      | Network Layer Reachability Information (variable)                 |
      +-------------------------------------------------------------------+

      The use of these fields is as follows:

      Unfeasible Route Count: This is a 2-octet long field that contains an
        integer whose value is equal to the number of ROUTE-IDs that are
        included in the subsequent WITHDRAWN ROUTES field.  A value of 0
        indicates that no routes are being withdrawn from service, and that
        the WITHDRAWN ROUTES field is not present in this UPDATE PDU.

      Withdrawn Routes: This is a variable length field that contains a
        list of Route-IDs for the routes that are being withdrawn from
        service.  Each Route-ID is 4 octets in length.

      Total Path Attribute Length: The length of this field is 2 octets.
        It is the total length of all Path Attributes in the UPDATE PDU in
        octets.

      Path Attributes: A variable length sequence of path attributes is
        present in every UPDATE PDU that is used to advertise a feasible
        route.

      Network Layer Reachability Information: A variable length field that
        lists the destinations for the feasible routes that are being
        advertised in this UPDATE PDU.



   Kunzinger                     ISO/IEC 10747                  [ Page 46 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   6.3.1  Path attribute encoding

      Each path attribute is a 4-tuple of variable length--<flag, type,
      length, value>.  The elements are used as follows:

      -   Flag:

          The first element of each attribute is a one octet field:

          -   The high-order bit (bit 8) of the attribute flags octet is
              the Optional bit. If it is set to 1, the attribute is
              optional; if set to 0, the attribute is well-known.

          -   The second high-order bit (bit 7) of the attribute flags
              octet is the Transitive bit.  It defines whether an optional
              attribute is transitive (if set to 1) or non-transitive (if
              set to 0).  For well-known attributes, the Transitive bit
              shall be set to 1.

          -   The third high-order bit (bit 6) of the attribute flags octet
              is the Partial bit.  It defines whether the optional
              transitive attribute is partial (if set to 1) or complete (if
              set to 0).  For well-known attributes and for optional
              non-transitive attributes the Partial bit shall be set to 0.

          -   The lower order five bits (1 through 5) of the attribute
              flags octet are reserved.  They shall be transmitted as 0 and
              shall be ignored when received.

      -   Type:

          The second element of each attribute is a one octet field which
          contains the type code for the attribute.  Currently defined
          attribute type codes are discussed in clause 7.11.

          Note 4:  It is not the intention of this International Standard
                   to define globally understood path attributes for type
                   codes greater than value 128.  Such codes are reserved
                   for local use.

      -   Length:

          The third field of each path attribute is 2 octets in length; it
          contains the length in octets of the immediately following Value
          field.

   Kunzinger                     ISO/IEC 10747                  [ Page 47 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      -   Value:

          The remaining octets of each path attribute field contain the
          value of the attribute, which is interpreted according to the
          attribute flags and the attribute type code.  The supported
          attribute values and their encodings are defined below.

   6.3.1.1  ROUTE_SEPARATOR (Type Code 1)

      ROUTE_SEPARATOR is a well-known mandatory attribute whose length is 5
      octets.  One ROUTE_SEPARATOR attribute shall be present for each
      feasible route that is advertised in an UPDATE PDU.  Multiple
      ROUTE_SEPARATORs may appear in a single UPDATE PDU.  Each one
      provides a 2-tuple <ROUTE_ID, LOCAL_PREF> for the route whose
      distinguishing attributes immediately follow.  It is encoded as shown
      below:

      +-------------------------------------------------------------------+
      | ROUTE-ID 1 (4 octets)                                             |
      +-------------------------------------------------------------------+
      | LOCAL-PREF 1 (1 octet)                                            |
      +-------------------------------------------------------------------+

      a)  ROUTE-ID:

          A four octet field that contains the route identifier for the
          route associated with the RIB-Att composed of the set of
          distinguishing path attributes that appear between itself and
          either the next ROUTE_SEPARATOR attribute or the end of the
          UPDATE PDU.

      b)  LOCAL_PREF:  A one octet field that contains the local preference
          value for route.

      The usage of this attribute is defined in 7.12.1.




   Kunzinger                     ISO/IEC 10747                  [ Page 48 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   6.3.1.2  EXT_INFO (Type Code 2)

      EXT_INFO is a well-known discretionary attribute that has a length of
      zero octets; its presence indicates that some (or all) of the path
      attributes or Network Layer Reachability Information contained in
      this UPDATE PDU have been obtained by methods not specified by IDRP.
      Conversely, its absence indicates that all path attributes and NLRI
      have been learned by methods defined within IDRP.  Its usage is
      defined in 7.12.2

   6.3.1.3  RD_PATH (Type Code 3)

      The RD_PATH attribute is a well-known mandatory attribute composed of
      a series of RD path segments.  Each path segment is represented by a
      triple <path segment type, path segment length, path segment value>.

      The path segment type is a 1-octet long field, with the following
      values defined:

      +------------------------------------------------------+------------+
      | Segment Type                                         | Value      |
      +------------------------------------------------------+------------+
      | RD_SET                                               | 1          |
      +------------------------------------------------------+------------+
      | RD_SEQ                                               | 2          |
      +------------------------------------------------------+------------+
      | ENTRY_SEQ                                            | 3          |
      +------------------------------------------------------+------------+
      | ENTRY_SET                                            | 4          |
      +------------------------------------------------------+------------+

      An RD_SEQ and a ENTRY_SEQ provide a list of RDIs, for routeing
      domains or for confederations respectively, in the order that the
      routeing information has travelled through them.  An RD_SET and an
      ENTRY_SET provide an unordered list of RDIs, for routeing domains or
      for confederations respectively; the routeing information has not
      necessarily travelled through all of the listed domains or
      confederations.

      The path segment length is a two octet field containing the length in
      octets of the path segment value field.

      The path segment value field contains one or more 2-tuples <length,
      RDI>. Length is a one octet long field that contains the length of

   Kunzinger                     ISO/IEC 10747                  [ Page 49 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      the RDI in octets; RDI itself is encoded according to the preferred
      binary encoding of ISO/IEC 8348.

      Usage of this attribute is defined in 7.12.3.

   6.3.1.4  NEXT_HOP (Type Code 4)

      This is a well-known discretionary attribute that can be used for two
      principal purposes:

      a)  to permit a BIS to advertise a different BIS's NET in the "NET of
          Next Hop" field

      b)  to allow a given BIS to report some or all of the SNPAs that
          exist within the local system

      It is encoded as shown below:

      +-------------------------------------------------------------------+
      | IDRP_Server_Allowed (1 octet)                                     |
      +-------------------------------------------------------------------+

      followed by one or more of the following:

      +-------------------------------------------------------------------+
      | Proto_type (1 octet)                                              |
      +-------------------------------------------------------------------+
      | Proto_length (1 octet)                                            |
      +-------------------------------------------------------------------+
      | Protocol (variable)                                               |
      +-------------------------------------------------------------------+
      | Length of NET (1 octet)                                           |
      +-------------------------------------------------------------------+
      | NET of Next Hop (variable)                                        |
      +-------------------------------------------------------------------+
      | Number of SNPAs (1 octet)                                         |
      +-------------------------------------------------------------------+
      | Length of first SNPA(1 octet)                                     |
      +-------------------------------------------------------------------+
      | First SNPA (variable)                                             |
      +-------------------------------------------------------------------+
      | Length of second SNPA (1 octet)                                   |
      +-------------------------------------------------------------------+

   Kunzinger                     ISO/IEC 10747                  [ Page 50 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      +-------------------------------------------------------------------+
      | Second SNPA (variable)                                            |
      +-------------------------------------------------------------------+
      | ...                                                               |
      +-------------------------------------------------------------------+
      | Length of Last SNPA (1 octet)                                     |
      +-------------------------------------------------------------------+
      | Last SNPA (variable)                                              |
      +-------------------------------------------------------------------+

      The use and meaning of these fields are as follows:

      IDRP_Server_Allowed: The value X'FF' indicates the recipient of this
        UPDATE PDU has the option of advertising (in its own outbound
        UPDATE PDUs) the NET and SNPA information learned from this UPDATE
        PDU.  If the value is not X'FF', then the recipient of this UPDATE
        PDU shall not advertise the NET and SNPA information learned from
        this UPDATE PDU.

      Proto_type: This field indicates the type of protocol identifier that
        follows:

         1  ISO/IEC TR 9577 IPI/SPI
         2  ISO 8802 LSAP

        For use with ISO 8473, this field shall contain the value 1.

      Proto_length: This field indicates the length in octets of the
        protocol identifier that follows.  For use with ISO 8473, this
        field shall contain the value 1.

      Protocol: This field carries the identity of the protocol associated
        with the address information that follows.  For use with ISO 8473,
        this field shall contain the value X'81'.

      Length of NET: A 1 octet field whose value expresses the length of
        the "NET of Next Hop" field as measured in octets

      NET of Next Hop: A variable length field that contains the NET of the
        next BIS on the path to the destination system

      Number of SNPAs: A 1 octet field which contains the number of
        distinct SNPAs to be listed in the following fields.  The value 0
        may be used to indicate that no SNPAs are listed in this attribute.

   Kunzinger                     ISO/IEC 10747                  [ Page 51 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Length of Nth SNPA: A 1 octet field whose value expresses the length
        of the "Nth SNPA of Next Hop" field as measured in semi-octets

      Nth SNPA of Next Hop: A variable length field that contains an SNPA
        of the BIS whose NET is contained in the "NET of Next Hop" field.
        The field length is an integral number of octets in length, namely
        the rounded-up integer value of one half the SNPA length expressed
        in semi-octets; if the SNPA has an contains an odd number of
        semi-octets, a value in this field will be padded with a trailing
        all-zero semi-octet.

      Its usage is defined in 7.12.4.  A conforming IDRP implementation may
      ignore next hop information for all protocols other than ISO 8473.
      The Decision and Forwarding processes of IDRP for use with protocols
      other than ISO 8473 are outside the scope of this international
      standard.

      Note 5:  The ISO 8802 LSAP format is intended for use with protocols
               that are identified directly by the use of a particular LSAP
               value;  in such cases, the value of the Proto_length field
               should be 1.

               The ISO/IEC TR 9577 IPI/SPI format may include additional
               information beyond the IPI/SPI value in the Protocol field;
               for example, if the IPI/SPI value is X'80', an IEEE 802.1a
               SNAP header might be included.

   6.3.1.5  DIST_LIST_INCL (Type Code 5)

      The DIST_LIST_INCL is a well-known discretionary attribute that
      contains a list of the RDIs of routeing domains and confederations to
      which the Network Layer Reachability Information contained in that
      UPDATE PDU may be distributed.  Its usage is described in 7.12.5.

      Each RDI in the list is encoded as a <length, value> pair, using the
      following fields:

      +-------------------------------------------------------------------+
      | Count (1 octet)                                                   |
      +-------------------------------------------------------------------+
      | Length (1 octet)                                                  |
      +-------------------------------------------------------------------+
      | Value  (variable)                                                 |
      +-------------------------------------------------------------------+

   Kunzinger                     ISO/IEC 10747                  [ Page 52 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      +-------------------------------------------------------------------+
      | ...                                                               |
      +-------------------------------------------------------------------+
      | Length (1 octet)                                                  |
      +-------------------------------------------------------------------+
      | Value  (variable)                                                 |
      +-------------------------------------------------------------------+

      The use and meaning of these fields are as follows:

      a)  Count:

          The count field is an integer that gives the number of RDIs in
          the list, where each RDI is represented by a <length, value> pair
          as described below.

      b)  Length:

          The length field indicates the length in octets of the following
          RDI.

      c)  Value:

          The value field contains the RDI, encoded according to the
          preferred binary encoding of ISO/IEC 8348.

      The DIST_LIST_INCL attribute shall not be present together with the
      DIST_LIST_EXCL attribute in the same UPDATE PDU.

   6.3.1.6  DIST_LIST_EXCL (Type Code 6)

      The DIST_LIST_EXCL is a well-known discretionary attribute that
      contains a list of the RDIs of routeing domains and confederations to
      which the Network Layer Reachability Information contained in that
      UPDATE PDU shall not be distributed.  Its usage is described in
      7.12.6.

      Each RDI in the list is encoded as a <length, value> pair, using the
      following fields:

      +-------------------------------------------------------------------+
      | Count (1 octet)                                                   |
      +-------------------------------------------------------------------+

   Kunzinger                     ISO/IEC 10747                  [ Page 53 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      +-------------------------------------------------------------------+
      | Length (1 octet)                                                  |
      +-------------------------------------------------------------------+
      | Value  (variable)                                                 |
      +-------------------------------------------------------------------+
      | ...                                                               |
      +-------------------------------------------------------------------+
      | Length (1 octet)                                                  |
      +-------------------------------------------------------------------+
      | Value  (variable)                                                 |
      +-------------------------------------------------------------------+

      The use and meaning of these fields are as follows:

      a)  Count:

          The count field is an integer that gives the number of RDIs in
          the list, where each RDI is represented by a <length, value> pair
          as described below.

      b)  Length:

          The length field indicates the length in octets of the following
          RDI.

      c)  Value:

          The value field contains the RDI, encoded according to the
          preferred binary encoding of ISO/IEC 8348.

      The DIST_LIST_EXCL attribute shall not be present together with the
      DIST_LIST_INCL attribute in the same UPDATE PDU.

   6.3.1.7  MULTI-EXIT_DISC (Type Code 7)

      MULTI-EXIT_DISC (Multi-exit Discriminator) is an optional
      non-transitive attribute that is a 1 octet non-negative integer.  The
      value of this attribute may be used by a BIS's decision process to
      discriminate between multiple exit points to an adjacent routeing
      domain.  Its usage is defined in 7.12.7.


   Kunzinger                     ISO/IEC 10747                  [ Page 54 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   6.3.1.8  TRANSIT DELAY (Type Code 8)

      The TRANSIT DELAY is a well-known discretionary attribute that has a
      length of 2 octets, and is used to notify a BIS that the path to
      destination has transit delay determined by the value of the
      attribute.  Its usage is defined in 7.12.8.

   6.3.1.9  RESIDUAL ERROR (Type Code 9)

      The RESIDUAL ERROR is a well-known discretionary attribute that has a
      length of 4 octets, and is used to notify a BIS that the path to
      destination has residual error probability determined by the value of
      the attribute.  Its usage is defined in 7.12.9.

   6.3.1.10  EXPENSE (Type Code 10)

      The EXPENSE is a well-known discretionary attribute that has a length
      of 2 octets, and is used to notify a BIS that the path to destination
      has expense determined by the value of the attribute.  Its usage is
      defined in 7.12.10.

   6.3.1.11  LOCALLY DEFINED QOS (Type Code 11)

      This is a well-known discretionary attribute whose variable length
      field contains the parameters associated with a QOS related path
      attribute defined by a QOS authority.

      The parameters of this attribute identify the QOS authority, the name
      of the QOS measurement, and, optionally, a metric associated with
      that measurement.  The syntax and semantics of the QOS measurement
      and its metric are outside the scope of this International Standard,
      and are specified by the responsible QOS Authority.

      It is encoded as follows:

      +-------------------------------------------------------------------+
      | NSAP prefix length (1 octet)                                      |
      +-------------------------------------------------------------------+
      | NSAP prefix (variable)                                            |
      +-------------------------------------------------------------------+
      | QOS length (1 octet)                                              |
      +-------------------------------------------------------------------+

   Kunzinger                     ISO/IEC 10747                  [ Page 55 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      +-------------------------------------------------------------------+
      | QOS value (variable)                                              |
      +-------------------------------------------------------------------+
      | Metric length (1 octet)                                           |
      +-------------------------------------------------------------------+
      | Metric value (variable)                                           |
      +-------------------------------------------------------------------+

      The use and meaning of the fields is as follows:

      a)  NSAP prefix length:

          The length field indicates the length in bits of the NSAP address
          prefix (see 7.1.2.1).  A length of zero indicates a prefix that
          matches all NSAPs.

      b)  NSAP prefix:

          If the Length field specifies an integral number of octets, then
          the Prefix field shall contain only the NSAP address prefix
          encoded according to 7.1.2.1.  If the Length field does not
          specify an integral number of octets, then the Prefix field shall
          contain the NSAP address prefix encoded according to 7.1.2.1,
          followed by enough trailing zeroes to make the end of the field
          fall on an octet boundary.

          This field identifies the QoS Authority and comprises an NSAP
          Address Prefix when the QoS Authority is also an NSAP Addressing
          Authority (see ISO 8473 clauses 7.5.6.1 and 7.5.6.2); the NSAP
          Address Prefix is that of the QoS Authority's Addressing
          Subdomain. When the QoS Authority is not also an NSAP Addressing
          Authority, then this field contains an NET that uniquely
          identifies the QoS Authority.

      c)  QOS length:

          Gives the length in octets of the QOS value field.

      d)  QOS value:

          Contains the value of the QOS parameter.

      e)  Metric length:


   Kunzinger                     ISO/IEC 10747                  [ Page 56 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          Gives the length in octets of the metric value field.  A length
          of zero is a permitted value.

      f)  Metric value:

          Contains a positive integer that is the value of the metric
          associated with the path being advertised (that is, its "cost")

      Its usage is defined in 7.12.11.

   6.3.1.12  HIERARCHICAL RECORDING (Type Code 12)

      This is a well-known discretionary attribute.  It contains a 1-octet
      field used by members of a routeing domain confederation to control
      the transitivity of NPDUs through the confederation.  It is encoded
      as follows:

      +-------------------------------------------------------------------+
      | Flag (1 octet)                                                    |
      +-------------------------------------------------------------------+

      Its usage is defined in 7.12.12.

   6.3.1.13  RD_HOP_COUNT (Type Code 13)

      The RD_HOP_COUNT is a well-known mandatory attribute that contains a
      1 octet long field.  It contains an unsigned integer that is the
      upper bound on the number of routeing domains through which this
      UPDATE PDU has travelled.  Its usage is defined in 7.12.13.

   6.3.1.14  SECURITY (Type Code 14)

      This is a well-known discretionary attribute whose variable length
      field contains the parameters associated with a security related path
      attribute defined by a Security Authority.

      The parameters of this attribute identify the Security Authority, and
      can also contain additional security related information, which may
      identify the protection provided by the route, a set of Security
      Labels associated with the route, or both.  The syntax and semantics
      of the security related information are outside the scope of this

   Kunzinger                     ISO/IEC 10747                  [ Page 57 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      International Standard, and are specified by the responsible Security
      Authority.

      The encoding of the attribute is as follows:

      +-------------------------------------------------------------------+
      | Security Registration ID Length (1 octet)                         |
      +-------------------------------------------------------------------+
      | Security Registration ID (variable)                               |
      +-------------------------------------------------------------------+
      | Security Information Length (1 octet)                             |
      +-------------------------------------------------------------------+
      | Security Information (variable)                                   |
      +-------------------------------------------------------------------+

      The use and meaning of the fields is as follows:

      a)  Security Registration ID Length:

          This field contains the length in octets of the Security
          Authority's Security Registration Identifier.

      b)  Security Registration ID:

          This variable length field contains the Security Registration
          Identifier of the Security Authority responsible for defining the
          following security information.

      c)  Security Information Length:

          This field contains the length in octets of the Security
          Information, as a non-zero unsigned integer. A value of zero is
          not permitted.

      d)  Security Information:

          This variable length field contains an integral number of octets
          comprising security related information specified by the Security
          Authority identified above. The syntax and semantics of this
          information are outside of the scope of this International
          Standard.


   Kunzinger                     ISO/IEC 10747                  [ Page 58 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   6.3.1.15  CAPACITY (Type code 15)

      CAPACITY is a well-known mandatory attribute that has a length of 1
      octet, and is used to denote the relative capacity of the RD_PATH for
      handling traffic. High values indicate a lower traffic handling
      capacity than do low values.  Its usage is defined in 7.12.15.

   6.3.1.16  PRIORITY (Type Code 16)

      PRIORITY is a well-known discretionary attribute that is 1 octet in
      length.  The content of the field is an integer in the range from 0
      to 14.  It enables paths to be distinguished on the basis of which
      values of the ISO  8473 priority parameter (see ISO 8473, subclause
      7.5.7).  As in ISO 8473, the value 0 indicates the normal (default)
      priority, and the values 1 through 14 indicate higher priorities.  A
      particular value of this parameter, m, means that the BIS will not
      forward any ISO 8473 PDUs whose priority parameter has a value less
      than m.  Detailed usage rules are presented in 7.12.16.

   6.3.2  Network layer reachability information

      This variable length field contains a list of reachable destinations
      encoded as zero or more 5-tuples of the form <Proto_type,
      Proto_length, Protocol, Addr_length, Addr_info>, whose fields are
      described below:

      +-------------------------------------------------------------------+
      | Proto_type (1 octet)                                              |
      +-------------------------------------------------------------------+
      | Proto_length (1 octet)                                            |
      +-------------------------------------------------------------------+
      | Protocol (variable)                                               |
      +-------------------------------------------------------------------+
      | Addr_length (2 octets)                                            |
      +-------------------------------------------------------------------+
      | Addr_info (variable)                                              |
      +-------------------------------------------------------------------+

      The use and meaning of these fields are as follows:

      Proto_type: This field indicates the type of protocol identifier that
        follows:

   Kunzinger                     ISO/IEC 10747                  [ Page 59 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         1  ISO/IEC TR 9577 IPI/SPI
         2  ISO 8802 LSAP

        For use with ISO 8473, this field shall contain the value 1.

      Proto_length: This field indicates the length in octets of the
        protocol identifier that follows.  For use with ISO 8473, this
        field shall contain the value 1.

      Protocol: This field carries the identity of the protocol associated
        with the address information that follows.  For use with ISO 8473,
        this field shall contain the value X'81'.

      Addr_length: This field specifies the total length in octets of the
        address information that follows.

      Addr_info: This field contains a list of reachable address prefixes.
        The encoding of this field is specific to each protocol supported.

        For use with ISO 8473, this field shall be encoded as one or more
        2-tuples of the form <length, prefix>, whose fields are described
        below:

        a)  The Length field is one octet long, and it indicates the length
            in bits of the address prefix.  A length of zero indicates a
            prefix that matches all addresses.

        b)  The Prefix field has a variable length, and it contains an
            address prefix.  If the Length field does not specify an
            integral number of octets, then the Prefix field shall be
            padded with trailing zero bits to the next octet boundary.  For
            purposes of use with ISO 8473, this field shall contain an NSAP
            address prefix encoded according to 7.1.2.1.

        A conforming IDRP implementation may ignore NLRI for all protocols
        other than ISO 8473.  The Decision and Forwarding processes of IDRP
        for use with protocols other than ISO 8473 are outside the scope of
        this international standard.

      Note 6:  The ISO 8802 LSAP format is intended for use with protocols
               that are identified directly by the use of a particular LSAP
               value;  in such cases, the value of the proto_length field
               should be 1.


   Kunzinger                     ISO/IEC 10747                  [ Page 60 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

               The ISO/IEC TR 9577 IPI/SPI format may include additional
               information beyond the IPI/SPI value in the Protocol field;
               for example, if the IPI/SPI value is X'80', an IEEE 802.1a
               SNAP header might be included.

   6.4  IDRP ERROR PDU

      IDRP ERROR PDUs report error conditions which have been detected by
      the local BIS.  In addition to its fixed header, the IDRP ERROR PDU
      contains the following fields:

      +-------------------------------------------------------------------+
      | Fixed Header                                                      |
      +-------------------------------------------------------------------+
      | Error Code (1 octet)                                              |
      +-------------------------------------------------------------------+
      | Error Subcode (1 octet)                                           |
      +-------------------------------------------------------------------+
      | Data (variable)                                                   |
      +-------------------------------------------------------------------+

      The use of these fields is as follows:

      Error code: The Error code field is 1 octet long, and shall be
        present in every IDRP ERROR PDU.  It describes the type of error.
        The following error codes are defined:

        +----------------------------------------------------+------------+
        | Error Code                                         | Value      |
        +----------------------------------------------------+------------+
        | OPEN_PDU_Error                                     | 1          |
        +----------------------------------------------------+------------+
        | UPDATE_PDU_Error                                   | 2          |
        +----------------------------------------------------+------------+
        | Hold_Timer_Expired                                 | 3          |
        +----------------------------------------------------+------------+
        | FSM_Error                                          | 4          |
        +----------------------------------------------------+------------+
        | RIB_REFRESH_PDU_Error                              | 5          |
        +----------------------------------------------------+------------+

        All errors are fatal to the BIS connection.


   Kunzinger                     ISO/IEC 10747                  [ Page 61 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Error subcode: The Error subcode is one octet long, and shall be
        present in every IDRP ERROR PDU.  The error subcode provides more
        specific information about the nature of the reported error.  A
        given IDRP ERROR PDU may report only one error subcode for the
        indicated error code.  The supported error subcodes are as follows:

        a)  OPEN PDU Error subcodes:

            +-------------------------------------------------+-----------+
            | Subcode                                         | Value     |
            +-------------------------------------------------+-----------+
            | Unsupported_Version_Number                      | 1         |
            +-------------------------------------------------+-----------+
            | Bad_Max_PDU_Size                                | 2         |
            +-------------------------------------------------+-----------+
            +-------------------------------------------------+-----------+
            | Bad_Peer_RD                                     | 3         |
            +-------------------------------------------------+-----------+
            | Unsupported_Authentication_code                 | 4         |
            +-------------------------------------------------+-----------+
            | Authentication_Failure                          | 5         |
            +-------------------------------------------------+-----------+
            | Bad_RIB-AttsSet                                 | 6         |
            +-------------------------------------------------+-----------+
            | RDC_Mismatch                                    | 7         |
            +-------------------------------------------------+-----------+

        b)  UPDATE PDU Error subcodes:

            +-------------------------------------------------+-----------+
            | Subcode                                         | Value     |
            +-------------------------------------------------+-----------+
            | Malformed_Attribute_List                        | 1         |
            +-------------------------------------------------+-----------+
            | Unrecognized_Well-known_Attribute               | 2         |
            +-------------------------------------------------+-----------+
            | Missing_Well-known_Attribute                    | 3         |
            +-------------------------------------------------+-----------+
            | Attribute_Flags_Error                           | 4         |
            +-------------------------------------------------+-----------+
            | Attribute_Length_Error                          | 5         |
            +-------------------------------------------------+-----------+
            | RD_Routeing_Loop                                | 6         |
            +-------------------------------------------------+-----------+

   Kunzinger                     ISO/IEC 10747                  [ Page 62 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

            +-------------------------------------------------+-----------+
            | Subcode                                         | Value     |
            +-------------------------------------------------+-----------+
            | Invalid_NEXT_HOP_Attribute                      | 7         |
            +-------------------------------------------------+-----------+
            | Optional_Attribute_error                        | 8         |
            +-------------------------------------------------+-----------+
            | Invalid_Reachability_Information                | 9         |
            +-------------------------------------------------+-----------+
            | Misconfigured_RDCs                              | 10        |
            +-------------------------------------------------+-----------+
            | Malformed_NLRI                                  | 11        |
            +-------------------------------------------------+-----------+
            | Duplicated_Attributes                           | 12        |
            +-------------------------------------------------+-----------+
            | Illegal_RD_Path_Segment                         | 13        |
            +-------------------------------------------------+-----------+

        c)  Hold_Timer_Expired Error Subcodes:

            +-------------------------------------------------+-----------+
            | Subcode                                         | Value     |
            +-------------------------------------------------+-----------+
            | NULL                                            | 0         |
            +-------------------------------------------------+-----------+

        d)  FSM_Error Error Subcodes:

            When an FSM Error (see 7.6.1) has occurred, the first
            semi-octet of the error subcode carries the type number of the
            BISPDU that should not have been received and the second
            semi-octet encodes the state that the FSM was in when the
            reception took place.  The BISPDU type numbers are defined in
            6.1; the FSM states are encoded as follows:

            +-------------------------------------------------+-----------+
            | FSM State                                       | Encoded   |
            |                                                 | Value     |
            +-------------------------------------------------+-----------+
            | CLOSED                                          | 1         |
            +-------------------------------------------------+-----------+
            | OPEN-RCVD                                       | 2         |
            +-------------------------------------------------+-----------+
            | OPEN-SENT                                       | 3         |
            +-------------------------------------------------+-----------+

   Kunzinger                     ISO/IEC 10747                  [ Page 63 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

            +-------------------------------------------------+-----------+
            | FSM State                                       | Encoded   |
            |                                                 | Value     |
            +-------------------------------------------------+-----------+
            | CLOSE-WAIT                                      | 4         |
            +-------------------------------------------------+-----------+
            | ESTABLISHED                                     | 5         |
            +-------------------------------------------------+-----------+

        e)  RIB_REFRESH_PDU_Error Subcodes:

            +-------------------------------------------------+-----------+
            | Subcode                                         | Value     |
            +-------------------------------------------------+-----------+
            | Invalid_OpCode                                  | 1         |
            +-------------------------------------------------+-----------+
            | Unsupported_RIB-Atts                            | 2         |
            +-------------------------------------------------+-----------+

      Data: This variable length field contains zero or more octets of data
        to be used in diagnosing the reason for the IDRP ERROR PDU.  The
        contents of the Data field depends upon the error code and error
        subcode.

        Note that the length of the Data field can be determined from the
        Length field of the BISPDU header.  The minimum length of the IDRP
        ERROR PDU is 32 octets, including BISPDU header.

   6.5  KEEPALIVE PDU

      A KEEPALIVE PDU consists of only a PDU header and has a length of 30
      octets.

      A BIS can use the periodic exchange of KEEPALIVE PDUs with an
      adjacent BIS to verify that the peer BIS is reachable and active.
      KEEPALIVE PDUs are exchanged often enough as not to cause the hold
      time advertised in the OPEN PDU to expire.  The maximum time between
      KEEPALIVE PDUs shall be one third of the Hold Time interval as
      advertised in the Hold Time field of the OPEN PDU.

      A KEEPALIVE PDU may be sent asynchronously to acknowledge the receipt
      of other BISPDUs.  Sending a KEEPALIVE PDU does not cause the
      sender's sequence number to be incremented.

   Kunzinger                     ISO/IEC 10747                  [ Page 64 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   6.6  CEASE PDU

      A CEASE PDU consists of only a PDU header and has length of 30
      octets.

      A CEASE PDU is used by the originating BIS to instruct the peer BIS
      to close the BIS-BIS connection.

      Receipt of a CEASE PDU will cause the BIS to close down the
      connection with the BIS that issued it, as described in 7.6.2.

   6.7  RIB REFRESH PDU

      The RIB REFRESH PDU is used to allow a BIS to send a refresh of the
      routeing information in an Adj-RIB-Out to a neighbor BIS, or to
      solicit a neighbor BIS to send a refresh of its Adj-RIB-Out to the
      local BIS.  The RIB REFRESH PDU contains a fixed header and also the
      additional fields shown below:

      +-------------------------------------------------------------------+
      | Fixed Header                                                      |
      +-------------------------------------------------------------------+
      | OpCode (1 octet)                                                  |
      +-------------------------------------------------------------------+
      | RIB-Atts (variable)                                               |
      +-------------------------------------------------------------------+

      The use and meaning of these fields is as follows:

      There are three OpCode values defined:

      +------------+------------------------------------------------------+
      | Code       | Operation                                            |
      +------------+------------------------------------------------------+
      | 1          | RIB Refresh Request                                  |
      +------------+------------------------------------------------------+
      | 2          | RIB Refresh Start                                    |
      +------------+------------------------------------------------------+
      | 3          | RIB Refresh End                                      |
      +------------+------------------------------------------------------+

      The RIB-Atts field contains the RIB-Atts of the Adj-RIB-In for which
      a refresh is being requested.  This field is encoded in the same way
      that the RIB-AttsSet field of the OPEN PDU is encoded.

   Kunzinger                     ISO/IEC 10747                  [ Page 65 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Its usage is defined in 7.10.3.


   7.  Elements of procedure


      This clause explains the elements of procedure used by the protocol
      specified in this International Standard; it also describes the
      naming conventions and system deployment practices assumed by this
      protocol.

   7.1  Naming and addressing conventions

      Correct operation of this protocol requires that all NSAP-addresses,
      NETs, and RDIs shall be encoded according to the preferred binary
      encoding method of ISO/IEC 8348.

   7.1.1  Interpretation of address information

      IDRP does not assume or require any particular internal structure for
      the address.  That is, as long as the routeing domain administrator
      assigns values within this field that are consistent with the
      deployment constraints of 7.2.2, the protocol specified in this
      International Standard will operate correctly.

   7.1.2  NSAP address prefixes

      NSAP address prefixes provide a compact method for identifying groups
      of systems that reside in a given routeing domain or confederation.
      A prefix may have a length that is either smaller than, or the same
      size as, the base NSAP address.

      Note 7:  At one extreme, for example, the largest NSAP address prefix
               will be identical with the full NSAP address--in this case,
               it would identify a single system rather than a group of
               systems.  At another extreme, the NSAP prefix may be based

   Kunzinger                     ISO/IEC 10747                  [ Page 66 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

               on only a portion of NSAP address's IDP--in this case, it
               will identify a large group of systems.

   7.1.2.1  Encoding of prefixes

      The encoded form of an NSAP address prefix is obtained by encoding
      the prefix (expressed in its abstract syntax) according to the
      preferred binary encoding of ISO 8348, unless the end of the prefix
      falls within the IDP.  In this case, each decimal digit in the prefix
      shall be encoded as the corresponding semi-octet in the range
      0000-1001 and no padding characters shall be inserted.

      The length of an encoded prefix is denominated in bits.  The prefix
      shall end on a boundary that is legal in the abstract syntax of the
      address family from which it is derived.  For example, the encoding
      of a prefix whose DSP is expressed in decimal syntax must end on a
      semi-octet boundary, while the encoding of a prefix whose DSP is
      expressed in binary syntax can end on an arbitrary bit boundary.

   7.1.2.2  Prefix matching

      As part of the forwarding process, a BIS must match the destination
      NSAP address from an ISO 8473 NPDU against the NSAP address prefixes
      that are used to identify the Forwarding Information Bases.  An NSAP
      address prefix that extends into the DSP shall be compared directly
      against the encoded NSAP address, including any padding characters
      that may be present.  An NSAP address prefix which does not extend
      into the DSP shall be compared against the derived quantity NSAP',
      which is obtained from the encoded NSAP address by removing all
      padding characters that were inserted by the binary encoding process
      of ISO 8348.

      The existence of a match shall be determined as follows:

      a)  If the encoded NSAP address (or NSAP') contains fewer bits than
          the NSAP address prefix, then there is no match.

      b)  If the encoded NSAP address (or NSAP') contains at least as many
          bits as the NSAP address prefix, and all bits of the NSAP address
          prefix are identical to the corresponding leading bits of the
          encoded NSAP address (or NSAP'), there is a match.  Otherwise,
          there is no match.

   Kunzinger                     ISO/IEC 10747                  [ Page 67 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      In cases where a given NSAP address matches several address prefixes,
      the match with the longest prefix shall take precedence.  For
      purposes of prefix matching, the length of a prefix is defined to be
      the number of bits that it contains.

      Note 8:  Any implementation of a matching process that satisfies the
               requirements listed above may be used.  The key point is
               that matching process must be aware of whether or not the
               NSAP address prefix extends into the DSP, and must then
               either include or exclude padding characters from the
               encoded NSAP address, as defined above.

   7.2  Deployment guidelines

   7.2.1  Minimum  configuration of an RD

      To participate in this inter-domain routeing protocol, a routeing
      domain must, as a minimum:

      -   contain at least one Boundary Intermediate system

      -   contain at least one BIS capable of delivering NPDUs to the
          intra-domain routeing function, if the RD contains End systems.

   7.2.2  Deployment of ISs and ESs

      End systems and intermediate systems may use any NSAP address or NET
      that has been assigned under ISO/IEC 8348 guidelines.  However,
      correct and efficient operation of this protocol can only be
      guaranteed if the following additional guidelines are met:

      a)  An NSAP prefix carried in the NLRI field of route originated by a
          BIS in a given routeing domain should be associated with only
          that routeing domain: that is, no system identified by the prefix
          should reside in a different routeing domain.  Ambiguous routeing
          may result if several routeing domains originate routes whose
          NLRI fields contain identical NSAP address prefixes, since this
          would imply that the same system(s) are simultaneously located in
          several routeing domains.  (As noted in 7.1.2.2, prefixes may be
          discriminated by both content and length.)

   Kunzinger                     ISO/IEC 10747                  [ Page 68 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      b)  Several different NSAP prefixes may be associated with a single
          routeing domain identifier (RDI).  Thus, it is possible to
          construct a single routeing domain which contains a mix of
          systems which use NSAP addresses assigned by several different
          naming authorities.

      The protocol defined in this International Standard assumes that the
      guidelines listed above have been satisfied, but it contains no means
      to verify that this is so.  Therefore, such verification will be the
      responsibility of the administrators of routeing domains.

   7.3  Domain configuration information

      Correct operation of the protocol described in this international
      standard assumes that a minimum amount of information is available to
      both the inter-domain and the intra-domain routeing protocols.  The
      information is static in nature, and is not expected to change
      frequently.  This protocol specifies the content of the information
      in terms of managed objects.

      The information required by a BIS that implements the protocol
      described in this International Standard is:

      a)  Location and identity of adjacent intra-domain ISs:

          The managed object intraIS lists the NETs of systems to which the
          local BIS may deliver an inbound NPDU whose destination lies
          within the BIS's routeing domain.  The managed object contains
          the NETs of ISs that support the intra-domain routeing protocol
          and are located on the same common subnetwork as the local BIS.
          In particular, if the BIS participates in the intra-domain
          routeing protocol (that is, the protocol machines for both intra-
          and inter-domain routeing are located in the same real system),
          then the NET of the local BIS will be listed in the managed
          object intraIS.

      b)  Location and identity of BISs in the domain:

          This information permits a BIS to identify all other BISs located
          within its routeing domain.  This information is contained in the
          managed object internalBIS, which contains a set of NETs which
          identify the BISs in the domain.

      c)  Location and identity of BISs in adjacent domain:

   Kunzinger                     ISO/IEC 10747                  [ Page 69 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          Each BIS needs information to identify the NETs of each BIS
          located in an adjacent RD and reachable via a single subnetwork
          hop.  This information is contained in managed object
          externalBISNeighbor, which consists of a list of NETs.

      d)  NETs and NSAP addresses of all systems in the routeing domain:

          This information is used by the BIS to construct its network
          layer reachability information.  This information is contained
          within the managed object internalSystems, which lists the
          address prefixes of the systems contained within the routeing
          domain.

      e)  Local RDI:

          This information is contained in managed object localRDI; it is
          the RDI of the routeing domain in which the BIS is located.

      f)  RIBAttsSet:

          This managed object lists all of the RIB-Atts (RIB attributes)
          which are supported by BISs located in this routeing domain.  As
          noted in 7.10.1, a RIB-Att is a set of Distinguishing Attributes.

      g)  Routeing Domain Configuration:

          Managed object rdcConfig identifies all the routeing domain
          confederations (RDCs) to which the RD of the local BIS belongs,
          and it describes the nesting relationships that are in force
          between them.  It is contained in managed object rdcConfig.

      h)  Local SNPAs:

          Managed object localSNPA contains a list of the SNPAs of the BIS.

   7.4  Advertising NLRI

      The NLRI field in an UPDATE PDU contains information about the NSAP
      addresses of systems that reside within a given routeing domain or
      whose NSAP addresses are under control of the administrator of that
      routeing domain; it should not be used to convey information about
      the operational status of these systems.  The information in the NLRI
      field is intended to convey static administrative information rather
      than dynamic transient information: for example, it is not necessary

   Kunzinger                     ISO/IEC 10747                  [ Page 70 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      to report that a given system has changed its status from online to
      offline.

      The following guidelines for inclusion of NSAP address prefixes in
      the NLRI field of UPDATE PDUs originated within a given routeing
      domain will provide efficient operation of this protocol:

      a)  NSAP addresses that are within the control of the administrator
          of a given routeing domain may be reported in the NLRI field for
          that routeing domain.  The NSAP prefixes can provide information
          about systems that are online, systems that are offline, or
          unallocated NSAP addresses.  The ability to include unallocated
          NSAP addresses and NSAP addresses of offline systems in the NLRI
          allows a routeing domain administrator to advertise compact
          prefixes, thus minimizing the amount of data carried in the
          BISPDUs.

      b)  NSAP addresses that are known to correspond to systems that are
          not under control of the routeing domain administrator should not
          be included in the NLRI field for that routeing domain.  By not
          listing NSAP address prefixes that identify systems that are not
          under his control, a routeing domain administrator will comply
          with the deployment guidelines for ISs and ESs as described in
          7.2.2, thus assuring correct operation of this protocol.

      c)  For efficient operation of this protocol, the WITHDRAWN ROUTES
          field should not be used to report the NLRI of systems in the
          local routeing domain that are offline.  This field should be
          used only to advertise NSAP prefixes that are no longer under
          control of the administrator of the local routeing domain,
          regardless of whether such systems are online or offline.

      Note 9:  Although the protocol in this International Standard will
               operate correctly if each system is reported individually as
               a maximum-length NSAP address prefix, this will result in a
               large amount of routeing information, and hence can result
               in inefficient operation of this protocol.

               This protocol provides no means to verify that the preceding
               guidelines are followed.  However, it is within the
               prerogative of the administrator of any routeing domain to
               implement policies that ignore UPDATE PDUs that contain an
               excessive amount of NLRI information or that can cause
               inefficient operation of this protocol.

   Kunzinger                     ISO/IEC 10747                  [ Page 71 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.5  Receive process

      Within the Network layer, the IDRP protocol is located above the
      ISO 8473 protocol.  Therefore, IDRP relies upon ISO 8473 to perform
      the initial processing of incoming PDUs.  After processing the input
      NPDU, the ISO 8473 protocol machine that resides within the receiving
      BIS will deliver:

      a)  BISPDUs to the IDRP Receive Process, or
      b)  ISO 8473 NPDUs to the IDRP CLNS Forwarding Process.

      The ISO 8473 protocol machine shall process inbound NPDUs according
      to the appropriate ISO 8473 functions.

      If the NPDU contains an SPI that identifies IDRP, and the NPDU's
      source address identifies any system listed in managed objects
      internalBIS or externalBISNeighbor, then the data part of the NPDU
      contains a BISPDU.  This BISPDU shall be passed to the IDRP finite
      state machine defined in 7.6.1.

      However, if the source address of the NPDU is not an NET listed in
      the internalBIS or the externalBISNeighbor attributes of the
      idrpConfig Managed Object, then:

      a)  If the NPDU is an OPEN BISPDU without errors, then the BIS shall
          send a notification ("connectRequestBISUnknown") to Systems
          Management,
      b)  If the NPDU is any other BISPDU with or without errors, then the
          BIS shall send a notification ("PacketBomb") to Systems
          Management.

      The NPDU shall then be discarded.

      If the SPI identifies ISO 8473, decapsulate the inner PDU and pass it
      back to the ISO 8473 protocol machine.  (This step permits iterations
      on multiply encapsulated NPDUs, which may occur, for example, as
      described in 8.4, item b1.)




   Kunzinger                     ISO/IEC 10747                  [ Page 72 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.6  BIS-BIS connection management

      The protocol described in this International Standard relies on the
      underlying Network layer service to establish a full-duplex
      communications channel between each pair of BISs.

   7.6.1  BIS finite state machines

      A BIS shall maintain one finite state machine (FSM) for each BIS-BIS
      connection that it supports, and each FSM in a given BIS shall run
      independently of one another.  A BIS-BIS connection will progress
      through a series of states during its lifetime, which are summarized
      in the state table shown in Table 2.

      +---                  ----------------------------------------------+
      |    Notation Warning                                               |
      | To create a readable table within the bounds of a flat ASCII file |
      | using a monospaced font at 10 characters/inch, the following      |
      | abbreviated notation is used within the table:                    |
      |                                                                   |
      | start     activate                                                |
      |                                                                   |
      | stop      deactivate                                              |
      |                                                                   |
      | CLSD      CLOSED                                                  |
      |                                                                   |
      | OPRC      OPEN-RCVD                                               |
      |                                                                   |
      | OPSN      OPEN-SENT                                               |
      |                                                                   |
      | CLWT      CLOSED-WAIT                                             |
      |                                                                   |
      | ESTB      ESTABLISHED                                             |
      |                                                                   |
      | KPALV     KEEPALIVE                                               |
      |                                                                   |
      | ClWtD     CloseWaitDelay                                          |
      |                                                                   |
      | LFO       ListenForOPEN                                           |
      |                                                                   |
      +-------------------------------------------------------------------+

      BISPDUs passed to this finite state machine are subject the flow
      control procedures of 7.7.5 if the FSM is in the ESTABLISHED state.

   Kunzinger                     ISO/IEC 10747                  [ Page 73 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      When the FSM is in the ESTABLISHED state, only BISPDUs that are not
      discarded by the flow control process are processed by the FSM.  In
      all other states, all BISPDUs are processed directly by the finite
      state machine without being subject to flow control procedures.

      In describing the FSM transitions in response to receipt of BISPDUs,
      the following shorthand notation is used:

      a)  Receive with no errors means that the none of the error
          conditions defined in the appropriate subclause of 7.20 have been
          detected.

      b)  Receive with errors means that an error condition defined in the
          appropriate subclause of 7.20 has been detected.

      It is possible to receive a BISPDU which is properly formed, but
      which normally should not be received while the FSM is in the given
      state.  Such an event constitutes an FSM Error.  If an FSM Error can
      occur for a given state, it is shown in the description of that
      state.

   7.6.1.1  CLOSED State

      Initially the BIS Finite State Machine is in the CLOSED state.  The
      CLOSED state exists when no BIS-BIS connection exists and there is no
      connection record allocated.

      While in the CLOSED state, the BIS shall take the following actions:

      a)  If the BIS receives a deactivate, no action shall be taken and
          the FSM shall remain in the CLOSED state.

      b)  If the FSM receives an activate, the local BIS shall shall
          generate an initial sequence number (see 7.7.4), and shall send
          an OPEN PDU to the remote BIS.  The sequence field of the OPEN
          PDU shall contain the Initial Sequence Number (ISN); the
          Acknowledgement and Credit Available fields shall contain the
          value 0; and the Credit Offered field shall contain the initial
          flow control credit.  The FSM shall enter the OPEN-SENT state.

      c)  If the managed object ListenForOPEN is TRUE, and the BIS receives
          an OPEN PDU with no errors, then the local BIS shall generate an
          initial sequence number (see 7.7.4) and shall send an OPEN PDU to
          the remote BIS.  The sequence field of the OPEN PDU shall contain

   Kunzinger                     ISO/IEC 10747                  [ Page 74 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          the Initial Sequence Number (ISN), the Acknowledgement field
          shall acknowledge the received OPEN PDU, the Credit Available
          field shall be set according to the procedures of 7.7.5b, and the
          Credit Offered field shall contain the initial flow control
          credit.  The FSM shall then change its state to OPEN_RCVD.

      d)  If the managed object ListenForOPEN is TRUE and the BIS receives
          any BISPDU other than an OPEN PDU with no errors, or if the
          managed object ListenForOPEN is FALSE and the BIS receives any
          BISPDU, with or without errors, the BIS shall ignore the BISPDU
          and the FSM shall remain in the CLOSED state.

   7.6.1.2  OPEN-SENT State

      While in the OPEN-SENT state, the BIS shall take the following
      actions:

      a)  If the FSM receives an activate, the BIS shall ignore it, and the
          FSM shall remain in the OPEN-SENT state.

      b)  If the FSM receives a deactivate, the BIS shall send a CEASE PDU
          to its peer, and the FSM shall enter the CLOSE-WAIT state.

      c)  If the BIS receives a BISPDU with header errors (see 7.20.1), it
          shall log the error event, and the FSM shall remain in the
          OPEN-SENT state.

      d)  If the BIS receives an OPEN PDU with errors (see 7.20.2), it
          shall send an IDRP ERROR PDU to the adjacent BIS, acknowledging
          the remote BIS's OPEN PDU.  The FSM shall then enter the
          CLOSE-WAIT state.

      e)  If the BIS receives an OPEN PDU with no errors that does not
          acknowledge its own previously sent OPEN PDU, then the local BIS
          shall resend its own OPEN PDU with the same sequence number and
          with an acknowledgement of the remote BIS's OPEN PDU.  The value
          of the Credit Available field shall be set according to the
          procedures of 7.7.5b.  The FSM shall then change its state to
          OPEN-RCVD.

      f)  If the BIS receives an OPEN PDU with no errors that acknowledges
          its own previously sent OPEN PDU, the local BIS shall send a
          KEEPALIVE, RIB REFRESH, or UPDATE PDU that acknowledges the OPEN

   Kunzinger                     ISO/IEC 10747                  [ Page 75 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          PDU received from the remote BIS.  The FSM shall then enter the
          ESTABLISHED state.

      g)  If the BIS receives an IDRP ERROR PDU, either with or without
          error, it shall send a CEASE PDU, and the FSM shall change its
          state to CLOSED.

      h)  If the BIS receives a RIB REFRESH PDU or UPDATE PDU, either with
          or without errors, it shall issue an IDRP ERROR PDU, indicating
          "FSM Error".  The FSM shall then enter the CLOSE-WAIT state.

      i)  If the BIS receives a KEEPALIVE PDU, it shall issue an IDRP ERROR
          PDU, indicating "FSM Error".  The FSM shall then enter the
          CLOSE-WAIT state.

      j)  If the BIS receives a CEASE PDU, it shall issue a CEASE PDU in
          return, and then the FSM shall enter the CLOSED state.

      k)  If the BIS does not receive an OPEN PDU within a period t[ R]
          after sending an OPEN PDU, the BIS shall resend the OPEN PDU.  If
          the OPEN PDU is retransmitted n times, the local BIS shall issue
          a deactivate to close the BIS-BIS connection.

          Note 10:  The value t[R] should be chosen to be large enough so
                    that attempting to establish a connection to an
                    unresponsive peer BIS does not consume significant
                    network resources.  The values of t[R] and n must be
                    chosen so that <t[ R]> * n is greater than the
                    architectural constant CloseWaitDelay.

   +----------------------------------------------------------------------+
   | Table 2 (Page 1 of 7). BIS Finite State Machine                      |
   +--------+-----------+-------------+-------------+----------+----------+
   | STATE  | CLSD      | OPRC        | OPSN        | CLWT     | ESTB     |
   | >      |           |             |             |          |          |
   +--------+           |             |             |          |          |
   | INPUT  |           |             |             |          |          |
   | V      |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | start  | S=OPSN    | S=OPRC      | S=OPSN      | S=CLWT   | S=ESTB   |
   |        | A=send    | A=none      | A=none      | A=none   | A=none   |
   |        | OPEN PDU  |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+


   Kunzinger                     ISO/IEC 10747                  [ Page 76 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   | Table 2 (Page 2 of 7). BIS Finite State Machine                      |
   +--------+-----------+-------------+-------------+----------+----------+
   | STATE  | CLSD      | OPRC        | OPSN        | CLWT     | ESTB     |
   | >      |           |             |             |          |          |
   +--------+           |             |             |          |          |
   | INPUT  |           |             |             |          |          |
   | V      |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | stop   | S=CLSD    | S=CLWT      | S=CLWT      | S=CLWT   | S=CLWT   |
   |        | A=none    | A=send      | A=send      | A=none   | A=send   |
   |        |           | CEASE PDU   | CEASE PDU   |          | CEASE    |
   |        |           |             |             |          | PDU      |
   +--------+-----------+-------------+-------------+----------+----------+
   | Expiry | S=CLSD    | S=OPRC      | S=OPSN      | S=CLSD   | S=ESTB   |
   | of     | A=none    | A=none      | A=none      | A=7.6.2  | A=none   |
   | ClWtD  |           |             |             |          |          |
   | Timer  |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | Expiry | S=CLSD    | S=OPRC      | S=OPSN      | S=CLWT   | S=CLWT   |
   | of     | A=none    | A=none      | A=none      | A=none   | A=Send   |
   | Hold   |           |             |             |          | IDRP     |
   | Timer  |           |             |             |          | ERROR    |
   |        |           |             |             |          | PDU to   |
   |        |           |             |             |          | report   |
   |        |           |             |             |          | error    |
   +--------+-----------+-------------+-------------+----------+----------+
   | Receive| S=CLSD    | S=OPRC      | S=OPSN      | S=CLWT   | S=ESTB   |
   | BISPDU | A=none    | A=log error | A=log error | A=none   | A=log    |
   | with   |           | event       | event       |          | error    |
   | Header |           |             |             |          | event    |
   | Error  |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+





   Kunzinger                     ISO/IEC 10747                  [ Page 77 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   | Table 2 (Page 3 of 7). BIS Finite State Machine                      |
   +--------+-----------+-------------+-------------+----------+----------+
   | STATE  | CLSD      | OPRC        | OPSN        | CLWT     | ESTB     |
   | >      |           |             |             |          |          |
   +--------+           |             |             |          |          |
   | INPUT  |           |             |             |          |          |
   | V      |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | Receive| S=CLSD    | If ACK is   | S=CLWT      | S=CLWT   | S=ESTB   |
   | KPALV  | A=none    | correct,    | A=Send IDRP | A=send   | A=Restart|
   | PDU    |           |             | ERROR PDU   | CEASE,   | Hold     |
   | with   |           |  S=ESTB     | to report   | restart  | Timer    |
   | no     |           |  A=Restart  | FSM Error   | ClWtD    |          |
   | errors |           |  Hold Timer |             | timer    |          |
   |        |           |             |             |          |          |
   |        |           | If ACK is   |             |          |          |
   |        |           | incorrect,  |             |          |          |
   |        |           |             |             |          |          |
   |        |           |  S=CLWT     |             |          |          |
   |        |           |  A=Send     |             |          |          |
   |        |           |  IDRP ERROR |             |          |          |
   |        |           |  PDU to     |             |          |          |
   |        |           |  peer BIS   |             |          |          |
   |        |           |  to report  |             |          |          |
   |        |           |  FSM Error  |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | Receive| S=CLSD    | S=CLSD      | S=CLSD      | S=CLSD   | S=CLSD   |
   | CEASE  | A=none    | A=send      | A=send      | A=7.6.2  | A=send   |
   | PDU    |           | CEASE,      | CEASE,      |          | CEASE,   |
   | with   |           | 7.6.2       | 7.6.2       |          | 7.6.2    |
   | no     |           |             |             |          |          |
   | errors |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | Receive| S=CLOSE   | S=CLWT      | S=CLWT      | S=CLWT   | S=CLWT   |
   | OPEN   | A=none    | A=Send IDRP | A=Send IDRP | A=none   | A=Send   |
   | PDU    |           | ERROR PDU   | ERROR PDU   |          | IDRP     |
   | with   |           | to peer BIS | to peer BIS |          | ERROR    |
   | errors |           | to report   | to report   |          | PDU to   |
   |        |           | OPEN PDU    | OPEN PDU    |          | peer BIS |
   |        |           | error       | error       |          | to       |
   |        |           |             |             |          | report   |
   |        |           |             |             |          | OPEN PDU |
   |        |           |             |             |          | error    |
   +--------+-----------+-------------+-------------+----------+----------+

   Kunzinger                     ISO/IEC 10747                  [ Page 78 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   | Table 2 (Page 4 of 7). BIS Finite State Machine                      |
   +--------+-----------+-------------+-------------+----------+----------+
   | STATE  | CLSD      | OPRC        | OPSN        | CLWT     | ESTB     |
   | >      |           |             |             |          |          |
   +--------+           |             |             |          |          |
   | INPUT  |           |             |             |          |          |
   | V      |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | Receive| If LFO is | If ACK is   | If ACK is   | S=CLWT   | S=CLWT   |
   | OPEN   | TRUE,     | correct,    | correct,    | A=send   | A=Send   |
   | PDU    |           |             |             | CEASE,   | IDRP     |
   | with   |  S=OPRC   |  S=ESTB     |  S=ESTB     | restart  | ERROR    |
   | no     |  A=send   |  A=send     |  A=send     | ClWtD    | PDU to   |
   | errors |  OPEN PDU |  KPALV,     |  KPALV,     | timer    | peer BIS |
   |        |           |  UPDATE, or |  UPDATE, or |          | to       |
   |        | If LFO is |  RIB        |  RIB        |          | report   |
   |        | FALSE,    |  REFRESH    |  REFRESH    |          | FSM      |
   |        |           |  PDU        |  PDU        |          | error    |
   |        |  S=CLSD   |             |             |          |          |
   |        |  A=none   | If ACK is   | If ACK is   |          |          |
   |        |           | incorrect,  | incorrect,  |          |          |
   |        |           |             |             |          |          |
   |        |           |  S=OPRC,    |  S=OPRC     |          |          |
   |        |           |  A=send     |  A=send     |          |          |
   |        |           |  OPEN PDU   |  OPEN PDU   |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | Receive| S=CLSD    | S=CLWT      | S=CLWT      | S=CLWT   | S=CLWT   |
   | UPDATE | A=none    | A=Send IDRP | A=Send IDRP | A=none   | A=Send   |
   | PDU    |           | ERROR PDU   | ERROR PDU   |          | IDRP     |
   | with   |           | to peer BIS | to peer BIS |          | ERROR    |
   | errors |           | to report   | to report   |          | PDU to   |
   |        |           | UPDATE PDU  | FSM error   |          | peer BIS |
   |        |           | error       |             |          | to       |
   |        |           |             |             |          | report   |
   |        |           |             |             |          | UPDATE   |
   |        |           |             |             |          | PDU      |
   |        |           |             |             |          | error    |
   +--------+-----------+-------------+-------------+----------+----------+



   Kunzinger                     ISO/IEC 10747                  [ Page 79 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   | Table 2 (Page 5 of 7). BIS Finite State Machine                      |
   +--------+-----------+-------------+-------------+----------+----------+
   | STATE  | CLSD      | OPRC        | OPSN        | CLWT     | ESTB     |
   | >      |           |             |             |          |          |
   +--------+           |             |             |          |          |
   | INPUT  |           |             |             |          |          |
   | V      |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | Receive| S=CLSD    | If ACK is   | S=CLWT      | S=CLWT   | S=ESTB   |
   | UPDATE | A=none    | correct,    | A=Send IDRP | A=send   | A=7.14,  |
   | PDU    |           |             | ERROR PDU   | CEASE,   | restart  |
   | with   |           |  S=ESTB     | to peer BIS | restart  | Hold     |
   | no     |           |  A=7.14,    | to report   | ClWtD    | Timer    |
   | errors |           |  restart    | FSM error   | timer    |          |
   |        |           |  Hold Timer |             |          |          |
   |        |           |             |             |          |          |
   |        |           | If ACK is   |             |          |          |
   |        |           | incorrect,  |             |          |          |
   |        |           |             |             |          |          |
   |        |           |  S=CLWT     |             |          |          |
   |        |           |  A=Send     |             |          |          |
   |        |           |  IDRP ERROR |             |          |          |
   |        |           |  PDU to     |             |          |          |
   |        |           |  peer BIS   |             |          |          |
   |        |           |  to report  |             |          |          |
   |        |           |  FSM Error  |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | Receive| S=CLSD    | S=CLSD      | S=CLSD      | S=CLSD   | S=CLSD   |
   | IDRP   | A=none    | A=Send      | A=Send      | A=Send   | A=Send   |
   | ERROR  |           | CEASE PDU,  | CEASE PDU,  | CEASE    | CEASE    |
   | PDU    |           | 7.6.2       | 7.6.2       | PDU,     | PDU,     |
   | with   |           |             |             | 7.6.2    | 7.6.2    |
   | errors |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | Receive| S=CLSD    | S=CLSD      | S=CLSD      | S=CLSD   | S=CLSD   |
   | IDRP   | A=none    | A=Send      | A=Send      | A=Send   | A=Send   |
   | ERROR  |           | CEASE PDU,  | CEASE PDU,  | CEASE    | CEASE    |
   | PDU    |           | 7.6.2       | 7.6.2       | PDU,     | PDU,     |
   | with   |           |             |             | 7.6.2    | 7.6.2    |
   | no     |           |             |             |          |          |
   | errors |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+


   Kunzinger                     ISO/IEC 10747                  [ Page 80 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   | Table 2 (Page 6 of 7). BIS Finite State Machine                      |
   +--------+-----------+-------------+-------------+----------+----------+
   | STATE  | CLSD      | OPRC        | OPSN        | CLWT     | ESTB     |
   | >      |           |             |             |          |          |
   +--------+           |             |             |          |          |
   | INPUT  |           |             |             |          |          |
   | V      |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | Receive| S=CLSD    | S=CLWT      | S=CLWT      | S=CLWT   | S=CLWT   |
   | RIB    | A=none    | A=Send IDRP | A=Send IDRP | A=none   | A=Send   |
   | REFRESH|           | ERROR PDU   | ERROR PDU   |          | IDRP     |
   | PDU    |           | to peer BIS | to peer BIS |          | ERROR    |
   | with   |           | to report   | to report   |          | PDU to   |
   | errors |           | RIB REFRESH | FSM error   |          | peer BIS |
   |        |           | PDU error   |             |          | to       |
   |        |           |             |             |          | report   |
   |        |           |             |             |          | RIB      |
   |        |           |             |             |          | REFRESH  |
   |        |           |             |             |          | PDU      |
   |        |           |             |             |          | error    |
   +--------+-----------+-------------+-------------+----------+----------+









   Kunzinger                     ISO/IEC 10747                  [ Page 81 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   | Table 2 (Page 7 of 7). BIS Finite State Machine                      |
   +--------+-----------+-------------+-------------+----------+----------+
   | STATE  | CLSD      | OPRC        | OPSN        | CLWT     | ESTB     |
   | >      |           |             |             |          |          |
   +--------+           |             |             |          |          |
   | INPUT  |           |             |             |          |          |
   | V      |           |             |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+
   | Receive| S=CLSD    | If ACK is   | S=CLWT      | S=CLWT   | S=ESTB   |
   | RIB    | A=none    | correct,    | A=Send IDRP | A=send   | A=7.10.3,|
   | REFRESH|           |             | ERROR PDU   | CEASE,   | restart  |
   | PDU    |           |  S=ESTB     | to report   | restart  | Hold     |
   | with   |           |  A=7.10.3,  | FSM Error   | ClWtD    | Timer    |
   | no     |           |  restart    |             | timer    |          |
   | errors |           |  Hold Timer |             |          |          |
   |        |           |             |             |          |          |
   |        |           | If ACK is   |             |          |          |
   |        |           | incorrect,  |             |          |          |
   |        |           |             |             |          |          |
   |        |           |  S=CLWT     |             |          |          |
   |        |           |  A=Send     |             |          |          |
   |        |           |  IDRP ERROR |             |          |          |
   |        |           |  PDU to     |             |          |          |
   |        |           |  peer BIS   |             |          |          |
   |        |           |  to report  |             |          |          |
   |        |           |  FSM Error  |             |          |          |
   +--------+-----------+-------------+-------------+----------+----------+







   Kunzinger                     ISO/IEC 10747                  [ Page 82 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   | Notes:                                                               |
   |                                                                      |
   | a)  "S" indicates the state into which the FSM will make a           |
   |     transition after performing the indicated action.                |
   |                                                                      |
   | b)  "A" indicates the action to be taken.                            |
   |                                                                      |
   | c)  "X.Y.Z" is shorthand notation for "do as specified in clause     |
   |     X.Y.Z".                                                          |
   |                                                                      |
   | d)  The phrase "no errors" for a given BISPDU type means that no     |
   |     condition described in the appropriate subclause of 7.20 has     |
   |     been detected.                                                   |
   |                                                                      |
   | e)  The phrase "with errors" for a given BISPDU type means that a    |
   |     condition described in the appropriate subclause of 7.20 has     |
   |     been detected.                                                   |
   |                                                                      |
   | f)  Since the KPALV PDU and the CEASE PDU consist of only a fixed    |
   |     BISPDU header, errors in these BISPDUs are handled as Header     |
   |     Errors.  Hence, there are no explicit entries in the table for   |
   |     "KPALV with errors" or "CEASE with errors".                      |
   +----------------------------------------------------------------------+

   7.6.1.3  OPEN-RCVD State

      While in the OPEN-RCVD state, the BIS shall take the following
      actions:

      a)  If the BIS receives an activate, it shall ignore it and the FSM
          shall remain in the OPEN-RCVD state.

      b)  If the BIS receives a deactivate, it shall send a CEASE PDU to
          the remote BIS, and the FSM shall enter the CLOSE-WAIT state.

      c)  If the BIS receives a BISPDU with a header error, it shall log
          the error event, and the FSM shall remain in the OPEN-RCVD state.

      d)  If the BIS receives a KEEPALIVE PDU that acknowledges its
          previously sent OPEN PDU, then the FSM shall enter the
          ESTABLISHED state.

   Kunzinger                     ISO/IEC 10747                  [ Page 83 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      e)  If the BIS receives a KEEPALIVE PDU that does not acknowledge its
          previously sent OPEN PDU, the BIS shall issue an IDRP ERROR PDU
          indicating "FSM Error", and the FSM shall change its state to
          CLOSE-WAIT.

      f)  If the BIS receives a CEASE PDU, it shall issue a CEASE PDU in
          return, and then the FSM shall enter the CLOSED state.

      g)  If the BIS receives an OPEN PDU with no errors from the remote
          BIS that acknowledges the local BIS's previously sent OPEN PDU,
          the BIS shall send a KEEPALIVE, RIB REFRESH, or UPDATE PDU that
          acknowledges the OPEN PDU received from the remote BIS.  The FSM
          shall then enter the ESTABLISHED state.

      h)  If the BIS receives an OPEN PDU with no errors that does not
          acknowledge the local BIS's previously sent OPEN PDU, then the
          local BIS shall resend its own OPEN PDU with the same sequence
          number, and shall also include an acknowledgement of the remote
          BIS's OPEN PDU.  The FSM shall remain in the OPEN-RCVD state.

      i)  If the BIS receives an UPDATE PDU or RIB REFRESH PDU with errors,
          theBIS shall send an IDRP ERROR PDU to the remote BIS, and the
          FSM shall enter the CLOSE-WAIT state.

      j)  If the BIS receives an UPDATE PDU or RIB REFRESH PDU with no
          errors that acknowledges the OPEN PDU previously sent by the
          local BIS, the FSM shall enter the ESTABLISHED state.

      k)  If the BIS receives an UPDATE PDU or RIB REFRESH PDU with no
          errors that does not acknowledge the OPEN PDU previously sent by
          the local BIS, the BIS shall issue an IDRP ERROR PDU indicating
          "FSM Error", and the FSM shall change its state to CLOSE-WAIT.

      l)  If the BIS receives an IDRP ERROR PDU, either with or without
          errors, it shall send a CEASE PDU to the remote BIS, and the FSM
          shall enter the CLOSED state.

      m)  If the BIS does not exit the OPEN-RCVD state within a period t[R]
          after sending an OPEN PDU, the BIS shall resend the OPEN PDU.  If
          the OPEN PDU is transmitted n times, the local BIS shall issue a
          deactivate.

          Note 11:  The value t[R] should be chosen to be large enough so
                    that attempting to establish a connection to an
                    unresponsive peer BIS does not consume significant

   Kunzinger                     ISO/IEC 10747                  [ Page 84 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

                    network resources.  The values of t[R] and n must be
                    chosen so that <t[R]> * n is greater than the
                    architectural constant CloseWaitDelay.

   7.6.1.4  ESTABLISHED State

      The ESTABLISHED state is entered from either the OPEN-SENT or the
      OPEN-RCVD states.  It is entered when a connection has been
      established by the successful exchange of state information between
      two sides of the connection. Each side has exchanged and received
      such data as initial sequence number, maximum PDU size, credit
      offered, protocol version number, hold time, and RDI of the other
      side. In addition, the remote BIS may also have been authenticated.

      In ESTABLISHED state, both BISs that are involved in the connection
      may exchange UPDATE PDUs, KEEPALIVE PDUs, IDRP ERROR PDUs, RIB
      REFRESH PDUs, and CEASE PDUs.

      While in the ESTABLISHED state, the local BIS shall take the
      following actions:

      a)  If the FSM receives an activate, the FSM shall ignore it, and the
          FSM shall remain in the ESTABLISHED state.

      b)  If the FSM receives a deactivate, the BIS  shall send a CEASE PDU
          to the peer BIS.  The FSM shall enter the CLOSE-WAIT state.

      c)  If the Hold Timer expires, the BIS shall issue an IDRP ERROR PDU
          to the remote BIS, reporting a Hold_Timer error.  The FSM shall
          enter the CLOSE-WAIT state.

      d)  If the BIS receives a BISPDU with a header error, it shall log
          the error event, and the FSM shall remain in the ESTABLISHED
          state.

      e)  If the BIS receives a KEEPALIVE PDU, it shall restart its Hold
          Timer, and the FSM shall remain in the ESTABLISHED state.

      f)  If the BIS receives a CEASE PDU, it shall issue a CEASE PDU in
          return, and then the FSM shall enter the CLOSED state.

      g)  If an OPEN PDU with no errors is received from the peer BIS, it
          shall issue an IDRP ERROR PDU, indicating FSM error.  The FSM
          shall enter the CLOSE-WAIT state.

   Kunzinger                     ISO/IEC 10747                  [ Page 85 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      h)  If the BIS receives an UPDATE PDU with no errors, the BIS shall
          perform the actions provided in 7.14, and shall restart its Hold
          Timer.  The FSM shall remain in the ESTABLISHED state.

      i)  If the BIS receives a RIB REFRESH PDU with no errors, the BIS
          shall perform the actions provided in 7.10.3, and shall restart
          its Hold Timer.  The FSM shall remain in the ESTABLISHED state.

      j)  If the BIS receives an UPDATE PDU with errors, an OPEN PDU with
          errors, or a RIB REFRESH PDU with errors, it shall send an IDRP
          ERROR PDU to the remote BIS to report the error, and the FSM
          shall enter the CLOSE-WAIT state.

      k)  If the BIS receives an IDRP ERROR PDU, either with or without
          errors, it shall send a CEASE PDU to the remote BIS.  The FSM
          shall enter the CLOSED state.

   7.6.1.5  CLOSE-WAIT State

      When an FSM enters the CLOSE-WAIT state, the local BIS is preparing
      to close the connection with the remote BIS.  Upon entering this
      state, the local BIS shall mark all entries in the Adj-RIB-In
      associated with the adjacent BIS as unreachable, and shall then
      re-run its Decision Process.  The CloseWaitDelay timer shall be
      started.

      While in the CLOSE-WAIT state, the BIS shall take the following
      actions:

      a)  If the CloseWaitDelay timer expires, the connection ceases to
          exist.  The FSM shall enter the CLOSED state.

      b)  If the BIS receives a CEASE PDU, the FSM shall enter the CLOSED
          state.

      c)  If the BIS receives an IDRP ERROR PDU, it shall send a CEASE PDU
          to the peer BIS.   The FSM shall then enter the CLOSED state.

      d)  If the BIS receives any other type of BISPDU, with or without
          errors, it shall issue a CEASE PDU.  The FSM shall remain in the
          CLOSE-WAIT state, and the CloseWaitDelay timer shall be
          restarted.


   Kunzinger                     ISO/IEC 10747                  [ Page 86 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      e)  The BIS shall take no action for any of the following inputs, and
          the FSM shall remain in the CLOSE-WAIT state:

          -   activate
          -   deactivate
          -   Expiration of Hold Timer

   7.6.2  Closing a connection

      The closing of a connection can be initiated by a deactivate
      generated by the local system, by receipt of an incorrect PDU, by
      receipt of a IDRP ERROR PDU, by expiration of the Hold Timer, or by
      receipt of a CEASE PDU.  The actions taken in response to each of
      these stimuli are shown in Table 2

      When the connection enters the CLOSED state, the sequence number last
      used by the local BIS is recorded in managed object lastPriorSeqNo,
      and all routes that had been exchanged between the pair of BISs are
      implicitly withdrawn from service; hence, the local BIS should rerun
      its Decision Process.

   7.7  Validation of BISPDUs

      The protocol described in this International Standard is a connection
      oriented protocol in which the underlying Network Layer service is
      used to establish full-duplex communication channels between pairs of
      BISs, as described in 7.6.  This International Standard supports the
      use of any of the following three mechanisms for validating BISPDUs.
      Types 1,2, and 3 provide data integrity for the contents of BISPDUs;
      in addition, types 2 and 3 provide peer BIS authentication.  Each
      mechanism is described below.  Figure 6 illustrates the data
      integrity mechanisms used for authentication types 1 and 3;
      informative Annex D describes an example approach that might be used
      to provide both data integrity and peer BIS authentication for
      authentication type 2.




   Kunzinger                     ISO/IEC 10747                  [ Page 87 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   |                                 auth13                               |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 6. Illustration of Authentication Types 1 and 3

   7.7.1  Authentication type 1

      For all BISPDUs that flow on a connection that was established in
      response to an OPEN PDU whose authentication code field was equal to
      1, the validation field shall contain a 16-octet unencrypted
      checksum:

      a)  Generating a Validation Pattern:

          The contents of the Validation Pattern field that is included in
          an outbound BISPDU shall be generated by applying the algorithm
          of Annex B to the input data stream that consists of the contents
          of the entire BISPDU with all bits of the Validation Pattern
          field initially set to 0.  The output of this step is an
          unencrypted 16-octet long checksum, which shall be placed in the
          Validation Pattern field of the BISPDU.

      b)  Checking the Validation Pattern of an Inbound BISPDU:

          The contents of the Validation Pattern field of an inbound BISPDU
          shall be checked by applying the algorithm of Annex B to the
          contents of the inbound BISPDU with its Validation Pattern set to
          all zeros.  Call this quantity the "reference pattern".

          If the "reference pattern" matches the contents of the Validation
          Pattern field of the inbound BISPDU, then the BISPDU's checksum
          is correct; otherwise, it is incorrect.

   7.7.2  Authentication type 2

      When the authentication type code of the OPEN PDU is 2, the pattern
      carried in the 16-octet Validation Pattern field of the fixed header
      shall provide both peer-BIS authentication and data integrity for the
      contents of the BISPDU.  The specific mechanisms used to provide
      these functions are not specified by this International Standard.
      However, they must be agreed to by the pair of communicating BISs as
      part of their security association.

   Kunzinger                     ISO/IEC 10747                  [ Page 88 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      An example of type 2 authentication that uses an encrypted version of
      MD4 checksum is described in Annex D.

      Note 12:  This International Standard includes as an optional
                function a mechanism that can be used for authentication of
                the source of a BISPDU.  Other security-related facilities
                (for example, protection against replay of BISPDUs or the
                ability to re-key during a BIS_BIS connection) are not
                intended to be provided by this protocol, and therefore are
                not specified in this International Standard.

                All of the relevant security services identified in ISO
                7498-2, including authentication, could be achieved by the
                use of ISO/IEC 11577, a security protocol specified for the
                provision of secure ISO 8473 communications (for example,
                see 9.1).

   7.7.3  Authentication type 3

      When the authentication type code of the OPEN PDU is 3, the
      Validation Pattern field shall contain a 16-octet checksum covering
      both the contents of the BISPDU and some additional Password Text,
      which is not transmitted to the peer BIS.  The checksum provides data
      integrity and the untransmitted Password Text provides peer BIS
      authentication.

      The mechanisms are as follows:

      a)  Generating a Validation Pattern:

          The contents of the Validation Pattern field that is carried in
          the outbound BISPDU shall be generated by the following process,
          which is illustrated in Figure 6.

          1)  Password text shall be appended to the BISPDU immediately
              after the final octet of the BISPDU (as defined by the BISPDU
              length field of the BISPDU header).  Additional password text
              may also be prepended to the BISPDU immediately prior to the
              first octet of its header.
          2)  A checksum that covers the concatenated contents of the
              BISPDU and the password text shall be generated using the
              methods of Annex B with all bits of the Validation Pattern
              initially set to zero.  The resultant checksum shall then be
              placed in the Validation Pattern field of the BISPDU.

   Kunzinger                     ISO/IEC 10747                  [ Page 89 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          3)  The password text shall not be transmitted along with the
              BISPDU.

      b)  Checking the Validation Pattern of an Inbound BISPDU:

          The contents of the Validation Pattern field of an inbound BISPDU
          shall be checked by the following procedure:

          1)  Append the Password Text to the BISPDU immediately after the
              final octet of the BISPDU (as defined by the BISPDU Length
              field of the BISPDU header.  If additional Password text was
              also prepended to the BISPDU by the sender, then prepend this
              text immediately prior to the first octet of the BISPDU.
          2)  Apply the IDRP Checksum Algorithm to the data stream that
              consists of the concatenated contents of the BISPDU and the
              password text, with all bits of the BISPDU Validation Pattern
              set to zero.  Call this value the "reference pattern".
          3)  If the "reference pattern" is identical to the data carried
              in the Validation Pattern of the incoming BISPDU, then the
              peer BIS has been authenticated.  If the "reference pattern"
              does not match the Validation Pattern, the receiving BIS
              shall inform system management that an authentication failure
              has occurred.  The incoming BISPDU shall be ignored.  The
              receiving BIS shall not send an IDRP ERROR PDU to the peer
              BIS because the identity of the peer has not been
              authenticated.

   7.7.4  Sequence numbers

      A sequence number is a 4-octet unsigned value.  Sequence numbers
      shall increase linearly from 1 up to a maximum value of <2^32>-1.
      The value 0 is not a valid sequence number.

      The rules for manipulating sequence numbers are:

      a)  When a BIS initially establishes a connection with an adjacent
          BIS, the first sequence number shall be set to 1 and shall
          increase linearly to a value of <2^32>-1.  Before attempting to
          establish an initial BIS-BIS connection with an adjacent BIS, the
          local BIS must ensure that it has not sent a BISPDU to the
          adjacent BIS for at least CloseWaitDelay seconds.

      b)  The sequence number shall not be incremented for the KEEPALIVE
          PDU, CEASE PDU, and the IDRP ERROR PDU.

   Kunzinger                     ISO/IEC 10747                  [ Page 90 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      c)  If the connection is subsequently closed under the conditions
          described in Table 2 and a subsequent connection is to be made to
          the same adjacent BIS, the local BIS shall, as a local matter,
          choose one of the following options:

          1)  Maintain status of the sequence number space, and use any
              value greater than the value last used in the prior BIS-BIS
              connection (lastPriorSeqNo), or
          2)  Ensure that at least CloseWaitDelay seconds have passed since
              the last BISPDU was sent to the adjacent BIS, and start with
              any sequence number.  The choice of the initial value of the
              sequence number is a local matter.

      d)  After a BIS sends a BISPDU with the maximum permissible sequence
          number (<2^32>-1) the BIS shall not send any further BISPDUs
          until the BISPDU with maximum sequence number and all outstanding
          BISPDUs have been acknowledged using the procedure of 7.7.5.  The
          BIS then shall set its lower window edge (see 7.7.5) to one.
          When a BIS receives a BISPDU with a sequence number of one, after
          having acknowledged a BISPDU with the maximum permissible
          sequence number, it shall set the value of its next expected
          sequence number to one, prior to processing that BISPDU.

          Note 13:  The maximum lifetime of an ISO 8473 NPDU is 128 s.
                    Since the architectural constant CloseWaitDelay is 150
                    s, it can be guaranteed that all outstanding BISPDUs
                    (which are carried as user data within an encapsulating
                    8473 NPDU) will have expired before the new BIS-BIS
                    connection is established.

   7.7.5  Flow control

      After an IDRP connection is established, the BIS Finite State Machine
      is in state ESTABLISHED (see section 7.6.1), and flow control and
      packet sequencing is in effect.  The IDRP flow control process shall
      obey the following rules:

      a)  A separate series of sequence numbers shall be maintained for
          each direction of a BIS-BIS connection, with the initial sequence
          number value chosen by the sender of a BISPDU and declared in the
          Sequence field of its OPEN PDU.  The local BIS will maintain a
          window to manage transmission of BISPDUs to the remote BIS.  The
          sender's lower window edge shall be set to the initial sequence
          number plus one; the sender's upper window edge shall be set to

   Kunzinger                     ISO/IEC 10747                  [ Page 91 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          the lower window edge plus the value of credit offered contained
          in the peer BIS's OPEN PDU.  Record is also kept of the next
          expected sequence number for an inbound UPDATE, RIB REFRESH,
          KEEPALIVE, or OPEN PDU to be received from the peer BIS; this is
          initially set to the value of one plus Sequence that is carried
          in the peer BIS's OPEN PDU.

      b)  An UPDATE PDU or RIB REFRESH PDU shall not be sent if the upper
          window edge is less than or equal to the lower window edge.  When
          a BISPDU is sent, the value of Sequence in the fixed header shall
          be set to the current value of the lower window edge.  When an
          UPDATE or RIB REFRESH PDU is to be sent, the local BIS shall
          generate the contents of the BISPDU based on the current value of
          the lower window edge.  The local BIS shall increment the local
          window edge by one before it transmits the BISPDU to the peer BIS
          and before it generates any other BISPDUs or processes any
          received BISPDUs; when a BISPDU other than an UPDATE or RIB
          REFRESH PDU is to be sent, the lower window edge shall not be
          incremented.  The value of Acknowledgement shall be set to the
          value of the next expected sequence number less one.  The value
          of credit offered shall be set to the number of additional
          BISPDUs that the local BIS is currently able to accept from the
          peer BIS.  Credit, once offered, can not be revoked (that is, the
          remote BIS's upper window edge can not be reduced).  Therefore,
          the sum of Acknowledgement and credit offered must never decrease
          in successive BISPDUs.  The value of credit available shall be
          set to the upper window edge less the lower window edge (after
          incrementing the lower window edge, if appropriate).

          The local BIS shall retain a copy of transmitted UPDATE and RIB
          REFRESH BISPDUs for possible retransmission.

      c)  An incoming UPDATE PDU or RIB REFRESH PDU whose Sequence value
          corresponds to the next expected sequence number shall be
          accepted and passed to the Finite State Machine described in
          7.6.1; the next expected sequence number shall be incremented by
          one.

          An incoming UPDATE PDU or RIB REFRESH PDU whose Sequence is less
          than the next expected sequence number shall be discarded.  An
          incoming UPDATE PDU or RIB REFRESH PDU whose Sequence is greater
          than the next expected sequence number shall be discarded, unless
          re-ordering is supported as a local implementation option, and
          the sequence number is not greater than the peer's upper window
          edge.

   Kunzinger                     ISO/IEC 10747                  [ Page 92 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          An incoming KEEPALIVE PDU or OPEN PDU whose Sequence value
          corresponds to the next expected sequence number shall be
          accepted and passed to the Finite State Machine described in
          7.6.1.  An incoming KEEPALIVE PDU or OPEN PDU whose Sequence does
          not correspond to the next expected sequence number shall be
          discarded.

          An Incoming CEASE PDU or IDRP ERROR PDU shall be accepted and
          passed to the Finite State Machine described in 7.6.1regardless
          of its Sequence value.

          Whenever a BIS receives an UPDATE PDU, RIB REFRESH PDU, or
          KEEPALIVE PDU, it shall inspect its Acknowledgement and credit
          offered fields.  Any BISPDUs retained for retransmission whose
          sequence number is less than or equal to the value of the
          Acknowledgement field shall be discarded.  If the sum of one plus
          the value of Acknowledgement plus the value of credit offered in
          the received BISPDU is greater than the local BIS's current upper
          window edge, then the BIS shall set its upper window edge to this
          sum.

      d)  A BIS shall acknowledge receipt of incoming UPDATE PDUs and RIB
          REFRESH PDUs within a period t[A] of their receipt.  The
          acknowledgement may be accomplished by means of an UPDATE PDU or
          a RIB REFRESH PDU sent as outlined in item b above.  However, if
          no UPDATE PDU or RIB REFRESH PDU is available to be sent, then a
          KEEPALIVE PDU may be sent instead, with its Sequence set to the
          lower window edge and its Acknowledgement, credit offered, and
          credit available set as in step b above.

      e)  If a retained BISPDU remains unacknowledged after a period t[R],
          then it shall again be transmitted and again retained for
          possible retransmission.  If, for a retained BISPDU, t[R] expires
          after n retransmissions, the local BIS shall issue a deactivate
          to close the BIS-BIS connection.

          Note 14:  The value t[R] should be chosen to be greater than the
                    value <t[A]> + 2*L, where L is the transmission delay
                    over the subnetwork or virtual link between the pair of
                    communicating BISs.

      f)  The local BIS shall provide its peer BIS with sufficient credit
          to send further BISPDUs as long as the local BIS has resources to
          receive them.  Therefore, if the local BIS receives a BISPDU
          whose credit available is equal to zero (that is, the peer BIS

   Kunzinger                     ISO/IEC 10747                  [ Page 93 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          believes itself unable to send additional BISPDUs), then as soon
          as resources are available locally, the local BIS shall send an
          UPDATE PDU or a RIB REFRESH PDU, if appropriate.  If not, then a
          KEEPALIVE PDU shall be sent.

          Note 15:  An UPDATE PDU of minimal size will contain the
                    Unfeasible Route Count field with a value of zero, but
                    will not contain any path attributes or NLRI.  Thus,
                    its size will be only 33 octets.

          A KEEPALIVE PDU that advertises a non-zero value of credit
          offered in response to a received BISPDU with a credit available
          of zero shall be retransmitted within a period t[R] until the
          local BIS receives any in-sequence BISPDU that reports a non-zero
          value of credit available.  If t[R] expires after n
          retransmissions, then the local BIS shall issue a deactivate to
          close the connection.

      g)  A BIS that has sent a BISPDU with zero credit available to its
          neighbor shall respond within a period t[A] to a BISPDU from that
          neighbor that causes its upper window edge to be increased.  The
          response shall consist of an UPDATE PDU or a RIB REFRESH PDU, if
          available, or a KEEPALIVE PDU, if not.

      h)  A BIS that has not sent any BISPDU for a period t[I] shall send a
          KEEPALIVE PDU, with Sequence equal to the lower window edge, and
          Acknowledgement, credit offered, and credit available set as in
          step b above.

          Note 16:  The condition (t[I]) >> (t[R]) should be satisfied,
                    where t[I] is one third of the Hold Timer value.

      i)  A BIS that has sent a BISPDU containing a credit offered of zero
          shall, as soon as its local resources become available to process
          additional BISPDUs from its peer, send an UPDATE PDU or RIB
          REFRESH PDU, if appropriate, containing a non-zero value of
          credit offered.  If neither of these BISPDU types is appropriate,
          then a KEEPALIVE PDU shall be sent.

      j)  The BIS shall issue a deactivate to close the BIS-BIS connection
          if no BISPDUs are received for a period equal to the value of
          Hold Time that is carried in the OPEN PDU.


   Kunzinger                     ISO/IEC 10747                  [ Page 94 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.8  Version negotiation

      BIS peers may negotiate the version number of IDRP by making
      successive attempts to open a BIS-BIS connection, starting with the
      highest supported version number (contained in managed object
      version) and decrementing the number each time a connection attempt
      fails.  The lack of support for a particular IDRP version is
      indicated by an IDRP ERROR PDU with error code "OPEN_PDU_Error" and
      an error subcode of "Unsupported_Version_Number".  One BIS may
      determine the highest version number supported by the other BIS (as
      advertised in its OPEN PDU) by examining the "Data" field of the
      received IDRP ERROR PDU.  No further retries should be attempted if
      the version number reaches zero.

   7.9  Checksum algorithm

      The checksums used in this International Standard for authentication
      types 1 and 3 shall be generated in accordance with the procedures
      described in normative Annex B.  For an input data stream of any
      length, this algorithm will generate a checksum that is 16 octets
      long.  This algorithm shall be used to generate the checksums for
      both the BISPDUs and the RIBs.

   7.10  Routeing information bases

      The Routeing Information Base (RIB) within a BIS consists of three
      distinct parts, as shown in Figure 7:

      a)  Adj-RIBs-In: The Adj-RIBs-In store routeing information that has
          been learned from inbound UPDATE PDUs.  Their contents represent
          routes that are available as input to the Decision Process.  A
          BIS must support at least one Adj-RIB-In for each of its neighbor
          BISs; it may optionally support several Adj-RIBs-In for a given
          neighbor BIS.  Within the set of Adj-RIBs-In associated with a
          given neighbor BIS, no two shall have the same RIB-Att (see
          7.10.1).

      b)  Loc-RIBs: The Loc-RIBs contain the local routeing information
          that the BIS has selected by applying its local policies to the
          routeing information contained in its Adj-RIBs-In.  A BIS may
          support multiple Loc-RIBs.  No two Loc-RIBs within a given BIS
          shall have the same RIB-Att (see clause 7.10.1).  Information in
          the Loc-RIB is used to build the Adj-RIBs-Out.

   Kunzinger                     ISO/IEC 10747                  [ Page 95 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   |                                  yr2                                 |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 7. Routeing Information Base.  An RIB is comprised of
             Adj-RIBs-In, Adj-RIBs-Out, and Loc-RIBs

      c)  Adj-RIBs-Out: The Adj-RIBs-Out store the information that the
          local BIS has selected for advertisement to its neighbors.  A BIS
          must support at least one Adj-RIB-Out for each of its neighbor
          BISs; it may optionally support several Adj-RIBs-Out for a given
          neighbor BIS.  Within the set of Adj-RIBs-Out associated with a
          given neighbor BIS, no two shall have the same RIB-Att (see
          7.10.1).  The routeing information stored in the Adj-RIBs-Out
          will be carried in the local BIS's UPDATE PDUs and advertised to
          its neighbor BISs.

      In summary, the Adj-RIBs-In contain unprocessed routeing information
      that has been advertised to the local BIS by its neighbors; the
      Loc-RIBs contain the routes that have been selected by the local
      BIS's Decision Process; and the Adj-RIBs-Out organize the selected
      routes for advertisement to specific neighbor BISs by means of the
      local BIS's UPDATE PDUs.

      Note 17:  Although the conceptual model distinguishes between
                Adj-RIBs-In, Adj-RIBs-Out, and Loc-RIBs, this does neither
                implies nor requires that an implementation must maintain
                three separate copies of the routeing information.  The
                choice of implementation (for example, 3 copies of the
                information vs. 1 copy with pointers) is not constrained by
                this standard.

   7.10.1  Identifying an information base

      Each information base (a single Adj-RIB-In, a single Loc-RIB, or a
      single Adj-RIB-Out) has one and only one RIB-Att associated with it.
      A RIB-Att is composed of a set of Distinguishing Attributes that the
      local BIS supports: in particular, a RIB-Att may consist of one or
      more Distinguishing Attributes that form a permissible combination,
      as defined in 7.11.2.

      The managed object RIBAttsSet explicitly enumerates all the RIB-Atts
      that a BIS supports.  Managed object RIB-AttsSet shall not contain

   Kunzinger                     ISO/IEC 10747                  [ Page 96 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      any pairs of RIB-Atts that are identical, thus assuring that each
      RIB-Att is unambiguous within the BIS.

      All BISs located within a given routeing domain shall support the
      same RIB-Atts: that is, the managed object RIB-AttsSet of every BIS
      within an RD shall list the same RIB-Atts.  When a BIS receives an
      OPEN PDU from another BIS located in its own routeing domain, it
      shall compare the information in the field RIB-AttsSet with the
      information in its local managed object RIBAttsSet. If they do not
      match, then the appropriate error handling procedure in 7.20.2 shall
      be followed.

      Each BIS shall support default information bases (Adj-RIBs-In,
      Adj-RIBs-Out, Loc-RIB, and FIB) that correspond to the RIB-Att that
      is composed of an empty set of Distinguishing Attributes.

      Note 18:  Because policy is a local matter, IDRP does not specify the
                criterion used to select the information to be placed in
                the default Loc-RIB.  However, since the following
                mandatory path attributes are present in every route, it is
                suggested that RD_PATH and RD_HOP_COUNT should be used for
                this purpose.

   7.10.2  Validation of RIBs

      A BIS shall not continue to operate for an extended period with
      corrupted routeing information.  Therefore, the BIS shall operate in
      a "fail-stop" manner: when corruption of a RIB is detected, the BIS
      shall immediately take action to cease using the routes contained in
      the corrupted information base.

      In the absence of an implementation-specific method for insuring
      this, the BIS shall perform the following checks at least every
      maxRIBIntegrityCheck seconds:

      a)  Upon expiration of its maxRIBIntegrityCheck timer, the BIS shall
          recheck the checksum of the routeing information contained in
          each of its Adj-RIBs-In in order to detect corruption of routeing
          information while in memory.

          If corruption is detected, the BIS shall purge the Adj-RIB-In,
          and shall notify System Management of a "Corrupted AdjRIBIn"
          event.

   Kunzinger                     ISO/IEC 10747                  [ Page 97 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          Note 19:  This International Standard does not prescribe a
                    specific checksum algorithm but notes that the
                    procedures described in Annex F satisfy the
                    requirements given above.  Other approaches can also be
                    used: for example, it may be possible to use an
                    incremental algorithm to compute the checksum for a
                    given Adj-RIB-In when new information is received.

                    After detection of a corrupted Adj-RIB-In, a BIS may
                    choose to issue a RIB REFRESH PDU, asking for a
                    solicited refresh of the routeing information from its
                    peer BIS.

      b)  On completion of its check of the Adj-RIBs-In, the BIS shall
          rerun its Decision Process, regardless of whether or not
          corruption of the Adj-RIBs-In has been detected.  As a byproduct
          of running the Decision Process, the BIS will construct new
          information for its Loc-RIBs, and will then regenerate its
          Adj-RIBs-Out and its FIBs.  Thus, any corrupted information that
          may have been present in the Adj-RIBs-Out or the FIBs will be
          replaced as a result.

      c)  Upon completion of these checks, the BIS shall reset the timer to
          the value MaxRIBIntegrityCheck with jitter applied in accordance
          with 7.17.3.3.

      Since a given Adj-RIB-In that had been corrupted will have been
      purged before the Decision Process is re-executed, the defective
      information will not be used in the recalculation.

      An explicit integrity check on the contents of the Loc-RIBs,
      Adj-RIBs-Out, and the FIBs is not required, since corrupted
      information will be replaced periodically when the Decision Process
      is re-run.

      As a local option, a BIS may also choose to perform an explicit
      integrity check on the routeing information in its Loc-RIBs,
      Adj-RIBs-Out, and FIBs.  If such an integrity check detects that the
      information base has become corrupted, then the BIS shall immediately
      rerun its Decision Process, and should notify System Management of
      "Corrupt Loc-RIB", "CorruptAdjRIBOut", or "CorruptFIB", as
      appropriate.


   Kunzinger                     ISO/IEC 10747                  [ Page 98 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.10.3  Use of the RIB REFRESH PDU

      The RIB REFRESH PDU can be used by a BIS to solicit a refresh of its
      Adj-RIBs-In by a neighbor BIS, or to send an unsolicited refresh to a
      neighbor BIS:

      a)  Solicited Refresh

          A BIS may request a neighbor BIS to refresh one or more of the
          local BIS's Adj-RIBs-In by sending a RIB-REFRESH PDU that
          contains the OpCode for RIB-Refresh-Request and the RIB-Atts of
          the Adj-RIBs-In that it wants to be refreshed.

          When the neighbor BIS receives a RIB-REFRESH PDU with OpCode
          RIB-Refresh-Request, it shall send back a RIB-REFRESH PDU with
          OpCode RIB-Refresh-Start, followed by a sequence of UPDATE PDUs
          that contain the information in its Adj-RIBs-Out associated with
          the requesting BIS.  The neighbor BIS shall indicate the
          completion of the refresh by sending a RIB-REFRESH PDU with
          OpCode RIB-Refresh-End.

      b)  Unsolicited Refresh

          A BIS may initiate an unsolicited refresh by sending a
          RIB-REFRESH PDU with OpCode RIB-Request-Start, followed by a
          sequence of UPDATE PDUs that contain the information in its
          Adj-RIBs-Out that been advertised to a given BIS.  The completion
          of the refresh shall be indicated by sending the RIB-REFRESH PDU
          with OpCode RIB-Refresh-End.

      When a BIS receives a RIB REFRESH PDU with OpCode 2 (RIB Refresh
      Start), it shall not change any of the routeing information currently
      stored in the Adj-RIB-In which is identified by the distinguishing
      attributes of the RIB REFRESH PDU until the refresh cycle has been
      completed or has been aborted.

      The BIS shall accumulate the routeing information contained in all
      the UPDATE PDUs that are received in a completed refresh cycle.
      Completion of a refresh cycle is indicated by receipt of a RIB
      REFRESH PDU with OpCode 3 (RIB Refresh End).  Then the BIS shall
      replace the previous routeing information in the associated
      Adj-RIB-In with the routeing information that was learned during the
      refresh cycle.


   Kunzinger                     ISO/IEC 10747                  [ Page 99 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Abortion of a refresh cycle is indicated by receipt of another RIB
      REFRESH PDU with OpCode 2 (RIB Refresh Start) before receipt of a RIB
      REFRESH PDU with OpCode 3 (RIB Refresh End).  In this case, any
      routeing information learned in the time between receipt of the two
      successive RIB Refresh Starts shall be discarded, and a new refresh
      cycle (triggered by receipt of the second RIB Refresh Start) shall
      begin.

      If the refreshing BIS receives a new RIB-Refresh-Request while it is
      in the middle of refresh (after sending RIB-REFRESH PDU with OpCode
      RIB-Refresh-Start, but before sending RIB-REFRESH PDU with OpCode
      RIB-Refresh-End), then the current refresh shall be aborted and the
      new refresh is initiated.

   7.11  Path attributes

      An UPDATE PDU that carries an NLRI field also carries a set of path
      attributes.  An UPDATE PDU that does not carry any NLRI field shall
      not carry any path attributes.  Path attributes are summarized in
      Table 3; their encoding is described in 6.3.

      +-------------------------------------------------------------------+
      | Table 3 (Page 1 of 2). Path Attribute Characteristics             |
      +----------------+--------------+------+----------+-----------------+
      | Attribute      | Category     | Type |  Length  |  Distinguishing |
      |                |              | Code | (octets) |                 |
      +----------------+--------------+------+----------+-----------------+
      |                |              |      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | ROUTE_SEPARATOR| well-known   |   1  |     5    |        No       |
      |                | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | EXT_INFO       | well-known   |   2  |     0    |        No       |
      |                | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | RD_PATH        | well-known   |   3  | variable |        No       |
      |                | mandatory    |      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | NEXT_HOP       | well-known   |   4  | variable |        No       |
      |                | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | DIST_LIST_INCL | well-known   |   5  | variable |        No       |
      |                | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+

   Kunzinger                     ISO/IEC 10747                 [ Page 100 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      +-------------------------------------------------------------------+
      | Table 3 (Page 2 of 2). Path Attribute Characteristics             |
      +----------------+--------------+------+----------+-----------------+
      | Attribute      | Category     | Type |  Length  |  Distinguishing |
      |                |              | Code | (octets) |                 |
      +----------------+--------------+------+----------+-----------------+
      | DIST_LIST_EXCL | well-known   |   6  | variable |        No       |
      |                | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | MULTI-EXIT     | optional     |   7  |     1    |        No       |
      | DISC           | non-transitiv|      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | TRANSIT DELAY  | well-known   |   8  |     2    |       Yes       |
      |                | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | RESIDUAL ERROR | well-known   |   9  |     4    |       Yes       |
      |                | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | EXPENSE        | well-known   |  10  |     2    |       Yes       |
      |                | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | LOCALLY        | well-known   |  11  | variable |       Yes       |
      | DEFINED QOS    | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | HIERARCHICAL   | well-known   |  12  |     1    |        No       |
      | RECORDING      | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | RD_HOP_COUNT   | well-known   |  13  |     1    |        No       |
      |                | mandatory    |      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | SECURITY       | well-known   |  14  | variable |       Yes       |
      |                | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | CAPACITY       | well-known   |  15  |     1    |        No       |
      |                | mandatory    |      |          |                 |
      +----------------+--------------+------+----------+-----------------+
      | PRIORITY       | well-known   |  16  |     1    |       Yes       |
      |                | discretionary|      |          |                 |
      +----------------+--------------+------+----------+-----------------+



   Kunzinger                     ISO/IEC 10747                 [ Page 101 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.11.1  Categories of path attributes

      Path attributes fall into four categories:

      a)  Well-known mandatory: these attributes must be recognized upon
          receipt by all BISs, and must be present in every UPDATE PDU
      b)  Well-known discretionary: these attributes must be recognized
          upon receipt by all BISs, but are not necessarily present in an
          UPDATE PDU
      c)  Optional transitive: these attributes need not be recognized upon
          receipt by all BISs, and are not necessarily present in an UPDATE
          PDU.  If a given BIS does not recognize an optional transitive
          attribute, it must pass it on to other BISs
      d)  Optional non-transitive: these attributes need not be recognized
          upon receipt by all BISs, and are not necessarily present in an
          UPDATE PDU.  If it does not recognize an optional non-transitive
          attribute, a BIS shall ignore it and shall not include it in any
          of its own UPDATE PDUs.

      A BIS shall handle optional attributes in the following manner:

      a)  If a route with an unrecognized optional transitive attribute is
          received and the route is to be propagated to other BISs, the
          optional transitive attribute must be propagated with the route,
          and the Partial bit in the Flag field of the attribute shall be
          set to 1.

      b)  If a route with a recognized optional transitive attribute is
          received and the route is to be propagated to other BISs, the
          optional transitive attribute may or may not be propagated with
          the route, according to the definition of the attribute.  If the
          attribute is propagated, then the local BIS shall not modify the
          value of the PARTIAL bit in the Flag field of the attribute.

      c)  If a route with an unrecognized optional non-transitive attribute
          is received, the receiving BIS shall ignore the attribute and
          shall not propagate that attribute to any other BIS.  However, it
          may propagate the remainder of the route: that is, the route
          without the unrecognized optional non-transitive attribute.

      d)  If a route with a recognized optional non-transitive attribute is
          received and the route is to be propagated to other BISs, the
          optional transitive attribute may or may not be propagated with
          the route, according to the definition of the attribute.  If the

   Kunzinger                     ISO/IEC 10747                 [ Page 102 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          attribute is propagated, then the local BIS shall not modify the
          value of the PARTIAL bit in the Flag field of the attribute.

      BISs shall observe the following rules for attaching and updating the
      values of optional attributes:

      -   New optional transitive attributes may be attached to the path
          information by any BIS in the path, and that BIS shall then set
          the PARTIAL bit in the attributes flag of its UPDATE PDU to 1.

      -   The rules for attaching new non-transitive optional attributes
          depend on the nature of each specific attribute.  The definition
          of each non-transitive optional attribute specifies such rules.

      -   Any optional attribute may be updated by any BIS in its path.

   7.11.2  Handling of distinguishing attributes

      Certain well-known discretionary path attributes are classified as
      Distinguishing Attributes (see 5.7), which can be used to
      discriminate among multiple routes to a destination, based on
      differences in quality between the routes.

      Distinguishing path attributes shall only be created by the BIS that
      originates the routeing information; they can be updated by any BIS
      that receives an UPDATE PDU that contains them.  The rules for
      updating each of IDRP's distinguishing attributes are defined in the
      appropriate subclause of 7.12.

      A permissible set of distinguishing attributes is defined to be a set
      that can be derived from information that can be validly encoded in
      the header of an ISO 8473 NPDU, using the mappings described in 9.2.
      In turn, a valid RIB-Att (see 5.7) is also a permissible set of
      distinguishing attributes, which is used to identify the RIB that
      holds a route characterized by those distinguishing attributes.
      Therefore, a permissible set of distinguishing attributes and a
      corresponding valid RIB-Att:

      a)  Can consist of an empty set (that is, the Empty Distinguishing
          Attribute)

      b)  Can contain the SECURITY path attribute


   Kunzinger                     ISO/IEC 10747                 [ Page 103 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          Note 20:  This distinguishing attributes is derived from the ISO
                    8473 Security parameter, as described in 8.2.

      c)  Can contain at most one of the following attributes:  RESIDUAL
          ERROR, TRANSIT DELAY, EXPENSE, and LOCALLY DEFINED QOS.

          Note 21:  These distinguishing attributes are derived from the
                    ISO 8473 Quality of Service Maintenance parameter,
                    which can request only one of them (see 8.2).

      d)  Can include the Priority Distinguishing Attribute.

          Note 22:  This distinguished attribute is derived from the ISO
                    8473 Priority parameter, as described in 8.2.

      e)  Can not include any instance of equivalent distinguishing
          attributes, as defined in 7.11.3.

      Therefore, the number of distinguishing attributes that can comprise
      either a valid RIB-Att or a permissible set of distinguishing
      attributes is not unbounded: it is limited to at most three.

   7.11.3  Equivalent distinguishing attributes

      IDRP recognizes two categories of distinguishing attribute:  type
      specific, and type-value specific.  Certain Distinguishing Attributes
      are unambiguous by their type --namely, Capacity, Priority, Transit
      Delay, Expense, and Residual Error. These are called type specific.

      Others can not be disambiguated based solely on their type, but
      require knowledge of both type and a subset of the fields that
      comprise their value--namely, SECURITY and LOCALLY DEFINED QOS.
      These are called type-value specific.

      Within IDRP, two instances of Distinguishing Attributes are
      equivalent each other if either:

      a)  they are both type specific and they both have the same type, or

      b)  they are both type-value specific, and they both have the same
          type and the same value.

      In all other cases two instances of Distinguishing Attribute are not
      equivalent.

   Kunzinger                     ISO/IEC 10747                 [ Page 104 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.12  Path attribute usage

      The usage of each of IDRP's path attributes is described in the
      following clauses.

   7.12.1  ROUTE_SEPARATOR

      ROUTE-SEPARATOR is a well-known mandatory attribute.  Multiple
      instances of this attribute may appear in a single UPDATE PDU.  The
      ROUTE_SEPARATOR serves as a delimiter between sets of distinguishing
      attributes.  Each set of distinguishing attributes determines the
      routeing information base associated with the route.  The ROUTE_ID
      and LOCAL_PREF values for a given route are contained in the
      ROUTE_SEPARATOR that immediately precedes the set of distinguishing
      attributes for that route.  A BIS shall include a ROUTE_SEPARATOR for
      each feasible route carried in the UPDATE PDU:

      -   The ROUTE-ID must be unambiguous within the context of the
          BIS-BIS connection over which the UPDATE PDU is transmitted.
      -   The LOCAL-PREF field is used to detect inconsistent routeing
          decisions among a set of BISs that are all located in the same
          routeing domain.  Its value shall be set as follows:

          a)  For UPDATE PDUs sent to adjacent routeing domains, LOCAL-PREF
              shall contain the value 0; the receiving BIS (in the adjacent
              RD) shall ignore this field upon receipt.

          b)  For UPDATE PDUS sent to BISs in the same routeing domain as
              the local BIS, its value shall be set in accordance with
              7.15.1; the receiving BIS (in the same RD) shall use this
              value to check for internal inconsistencies, in accordance
              with 7.15.1.

      All distinguishing attributes that appear after a given
      ROUTE_SEPARATOR and before the next ROUTE_SEPARATOR or the end of the
      BISPDU (whichever occurs first) form a set that determines the
      RIB-Att associated with the route.

      All non-distinguishing path attributes and the NLRI field apply to
      every route advertised in the UPDATE PDU, regardless of where they
      appear with respect to the ROUTE_SEPARATOR(s).


   Kunzinger                     ISO/IEC 10747                 [ Page 105 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      The ROUTE_ID associated with a route received from an adjacent BIS
      bear no functional relationship to the ROUTE_ID that the local BIS
      will generate if it decides to propagate that route.  Similarly, the
      ROUTE-ID for an aggregated route bears no functional relationship the
      individual ROUTE-IDs of the routes from which it was constructed.

      Note 23:  The requirements on unambiguity within the context of a
                given BIS-BIS connection lead to the following
                observations:

                a)  Since the ROUTE-ID must be unambiguous within each
                    instance of BIS-BIS communication, a BIS can advertise
                    the same route to different neighbor BISs, using
                    different ROUTE-IDs in each instance of BIS-BIS
                    communications.

                b)  The ROUTE-IDs associated with routes to be advertised
                    by a BIS (that is, the routes in its Adj-RIBs-Out)
                    bears no relationship to the ROUTE-IDs associated with
                    routes received from other BISs (that is, the routes in
                    the local BIS's Adj-RIBs-In).

   7.12.2  EXT_INFO

      EXT_INFO is a well-known discretionary attribute.  It shall be
      recognized upon receipt by all BISs.  It shall be included in each
      UPDATE PDU that reports either an RD_PATH attribute or Network Layer
      Reachability Information that has been learned by methods not
      described in this International Standard.

      The EXT_INFO attribute shall be generated by the RD that originates
      the associated routeing information.  If the EXT_INFO attribute was
      present in a received UPDATE PDU, then it shall also be included in
      the UPDATE PDUs of all BISs that choose to propagate this information
      to other BISs.

      Note 24:  Information obtained from the managed object
                internalSystems or obtained from UPDATE PDUs which do not
                contain the EXT_INFO attribute has been learned by methods
                within IDRP's scope; however, manually configured
                reachability information for an RD which does not run IDRP
                is an example of information which is learned by means
                outside IDRP's scope.

   Kunzinger                     ISO/IEC 10747                 [ Page 106 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

                If a BIS selects a route which has been advertised with the
                EXT_INFO attribute, it is possible that there may be
                undetected looping of routeing information.  Therefore, it
                is recommended that distribution of information not learned
                by the methods of IDRP be tightly controlled.  The path
                attributes DIST_LIST_INCL and DIST_LIST_EXCL afford a
                convenient method for providing this control.  Furthermore,
                a given RD may also enforce policies which prohibit any of
                its BISs from selecting routes which have the EXT_INFO
                attribute associated with them.

   7.12.3  RD_PATH

      RD_PATH is a well-known mandatory attribute.  It shall be present in
      every UPDATE PDU, and shall be recognized on receipt by all BISs.
      This attribute consists of a concatenation of path segments that
      identifies the routeing domains and routeing domain confederations
      through which this route has passed.  The path segments can be
      RD_SETs, RD_SEQs, ENTRY_SEQs, or ENTRY_SETs.

   7.12.3.1  Generating an RD_PATH attribute

      When a BIS originates a route to destinations contained within its
      own routeing domain or to destinations learned by means outside the
      protocol (see 7.12.2), it shall examine the information contained in
      its managed object rdcConfig to determine the ordering relationships
      among all the confederations of which the local routeing domain is a
      member.  The local BIS shall then construct an RD_PATH attribute as
      follows:

      a)  If the local routeing domain is a member of one or more
          confederations, the RD_PATH shall consist of an ENTRY_SEQ segment
          followed immediately by an RD_SEQ segment.  The ENTRY_SEQ shall
          list the confederations, ordered as follows:

          1)  If a confederation, RDC-B, is nested within another
              confederation, RDC-A, then the RDI of RDC-A shall precede
              that of RDC-B.

          2)  The RDIs of overlapping confederations shall be listed in
              increasing order of the RDIs, as long as the order implied by
              any nesting relationships is maintained.  For purposes of
              ordering, two RDIs are compared octet-by-octet from the left

   Kunzinger                     ISO/IEC 10747                 [ Page 107 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

              until differing octet values are found.  The RDI with the
              lesser octet value (when treated as an unsigned integer) is
              considered to have the lesser RDI value.  If there are two
              RDIs of different lengths, and the leading octets of the
              longer RDI are exactly the same as the octets of the
              (complete) shorter RDI, then the shorter RDI is considered to
              have the lesser value.

          The RD_SEQ shall list the RDI of the BIS's routeing domain.

      b)  If the local routeing domain is not a member of any
          confederation, then the RD_PATH contains a single RD_SEQ segment
          that lists the RDI of the BIS's routeing domain.

   7.12.3.2  Updating a received RD_PATH attribute

      The local BIS shall update the RD_PATH attribute of a route received
      from another BIS according to the following rules:

      a)  If the route was received from a BIS located in the same routeing
          domain as the local BIS, then the RD_PATH attribute shall not be
          updated.

      b)  If the route was received from a BIS located in an adjacent
          routeing domain, the local BIS shall determine if the route has
          entered any confederations (see 7.13.3), and it shall examine the
          information contained in its managed object rdcConfig to
          determine the ordering relationships among all such
          confederations.  The local BIS shall then amend the RD_PATH
          attribute as follows:

          1)  If the route has entered any confederations, the BIS shall
              append a path segment of type ENTRY_SEQ that lists all the
              newly entered confederations, ordered as follows:

              i)  If a confederation, RDC-B, is nested within another
                  confederation, RDC-A, then the RDI of RDC-A shall precede
                  that of RDC-B.

              ii) The RDIs of overlapping confederations shall be listed in
                  increasing order of the RDIs, as long as the order
                  implied by any nesting relationships is maintained.  For
                  purposes of ordering, two RDIs are compared
                  octet-by-octet from the left until differing octet values

   Kunzinger                     ISO/IEC 10747                 [ Page 108 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

                  are found.  The RDI with the lesser octet value (when
                  treated as an unsigned integer) is considered to have the
                  lesser RDI value.  If there are two RDIs of different
                  lengths, and the leading octets of the longer RDI are
                  exactly the same as the octets of the (complete) shorter
                  RDI, then the shorter RDI is considered to have the
                  lesser value.

              The ENTRY_SEQ segment shall be followed immediately by an
              RD_SEQ segment that lists the RDI of the BIS's routeing
              domain.

          2)  If the route has not entered any confederations, the local
              BIS shall append a path segment of type RD_SEQ that lists the
              RDI of the BIS's routeing domain.

   7.12.3.3  Advertising a route received from another BIS

      After receiving a route, a BIS will have modified its RD_PATH
      attribute in accordance with 7.12.3.2; and when a route is generated
      locally, the BIS will have created an RD_PATH attribute in accordance
      with 7.12.3.1.  If the local BIS selects a route for subsequent
      advertisement, the RD_PATH attribute of that route shall be amended
      as follows, based on the confederations which have been exited and on
      the nesting relationships among confederations of which the local BIS
      is a member (see managed object rdcConfig):

      a)  If the adjacent BIS to which the route will be advertised can be
          reached without exiting any confederations, then no modification
          to the RD_PATH attribute shall be made.

      b)  If the adjacent BIS to which the route will be advertised can
          only be reached by exiting one or more confederations, then the
          local BIS shall check the RD_PATH attribute for the presence of
          ENTRY_SEQ or ENTRY_SET path segments that contain the RDIs of the
          exited confederations.

          If there is any RDI of an exited confederation which is absent
          from all ENTRY_SEQ and ENTRY_SET segments, then the route is in
          error.  The local BIS shall send an IDRP ERROR PDU to the BIS
          that advertised the route, reporting a Misconfigured_RDCs error.

          If two confederation, RDC-A and RDC-B, are listed in the same
          ENTRY_SEQ, and managed object rdcConfig indicates that RDC-B is

   Kunzinger                     ISO/IEC 10747                 [ Page 109 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          nested within RDC-A, then the RDI of RDC-A shall precede that of
          RDC-B in the ENTRY_SEQ.  If it does not, the local BIS shall send
          an IDRP ERROR to the BIS that advertised the route, reporting a
          Misconfigured_RDCs error.

          Otherwise, the local BIS shall scan the RD_PATH attribute from
          the back (right to left, starting at the highest numbered octet)
          looking for an ENTRY_SEQ or ENTRY_SET path segment that lists an
          exited confederation.  Within a given ENTRY_SET or ENTRY_SEQ
          segment, the RDI for a given confederation can not be processed
          until the RDIs for all confederations nested within it have been
          processed.

          For each exited confederation (for example, the confederation
          whose RDI is "X"), the advertising BIS shall then update the
          RD_PATH of the route as follows:

          1)  The entry for "X" shall be removed from the ENTRY_SEQ or
              ENTRY_SET segment

          2)  If "X" is the only RDI contained in an ENTRY_SEQ or ENTRY_SET
              segment of the RD_PATH, then create a path segment of type
              RD_SEQ that lists "X" and insert it in front of the previous
              entry for "X".

          3)  If the local BIS's routeing domain is a member of other
              confederations besides "X" that are listed in the ENTRY_SEQ
              or ENTRY_SET segments of the RD_PATH, then:

              i)  If "X" occurs in an ENTRY_SEQ or ENTRY_SET segment, and
                  "X" is nested within none of the other confederations,
                  then create an RD_SET that lists "X" and insert it in
                  front of the first ENTRY_SEQ or ENTRY_SET segment that
                  occurs in the RD_PATH.

              ii) If "X" occurs in an ENTRY_SEQ and "X" is nested within
                  all the other confederations, then create a path segment
                  of type RD_SEQ that lists "X" and insert it immediately
                  in front of the previous entry for "X"

              iii) If "X" occurs in an ENTRY_SEQ and "X" is nested within
                  some but not all of the other confederations, then create
                  a path segment of type RD_SET that lists "X", and insert
                  it immediately after the closest prior entry for any
                  confederation in which "X" is nested.

   Kunzinger                     ISO/IEC 10747                 [ Page 110 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

              iv) If "X" occurs in an ENTRY_SET and "X" is nested within
                  all the other confederations, then create a path segment
                  of type RD_SET that lists "X" and insert it immediately
                  in front of the previous entry for "X"

              v)  If "X" occurs in an ENTRY_SET and "X" is nested within
                  some but not all of the other confederations, then create
                  a path segment of type RD_SET that lists "X", and insert
                  it immediately after the the closest prior entry for any
                  confederation in which "X" is nested.

              If the procedures call for the insertion of an RD_SET or an
              RD_SEQ between entries that are contained in a single
              ENTRY_SET or ENTRY_SEQ, then break the ENTRY_SET or ENTRY_SEQ
              into two segments of identical type and perform the
              insertion.  For example, if it is necessary to insert
              RD_SET(X) between entries for "A" and "B", where "A" and "B"
              are contained in ENTRY_SEQ(H,J,A,B,C), the result would be:
              ENTRY_SEQ(H,J,A) RD_SET(X) ENTRY_SEQ(B,C).

          If, after applying these procedures, the ENTRY_SEQ or ENTRY_SET
          segment in which "X" originally occurred is empty, then that path
          segment shall be deleted, together with any subsequent path
          segments between itself and the next occurring ENTRY_SEQ or
          ENTRY_SET segment, or between itself and the end of the RD_PATH
          attribute if there is no subsequent ENTRY_SEQ or ENTRY_SET
          segment.

   7.12.4  NEXT_HOP

      NEXT_HOP is a well-known discretionary attribute.  It shall be
      recognized upon receipt by all BISs.

      For purposes of defining the usage rules for this attribute, a
      subnetwork is transitive with respect to system reachability if all
      of the following conditions are true:

      a)  Systems A, B, and C are all attached to the same subnetwork,

      b)  When A can reach B directly,  and B can reach C directly, it
          follows that A can reach C directly.

      Verification of the above conditions should be accomplished by means
      outside of IDRP.  For example, systems located on a common subnetwork

   Kunzinger                     ISO/IEC 10747                 [ Page 111 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   |                    +-----+                                           |
   |                    |  B  |                                           |
   |                    +-----+                                           |
   |                   =   |   =                                          |
   |      BIS-BIS     =    |    =  BIS-BIS                                |
   |      Connection =     |     = Connection                             |
   |                =      |      =                                       |
   |               =       |       =                                      |
   |              =        |        =                                     |
   |             =         |         =                                    |
   |          +---+        |        +---+                                 |
   |          | A |--------+--------| C |                                 |
   |          +---+                 +---+                                 |
   |                                                                      |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 8. A Transitive Fully Connected Subnetwork

      could use an ES-IS protocol (such as ISO 9542) to ascertain if there
      is direct reachability between them.  Examples of such media are IEEE
      802.2 and SMDS.

      Consider three BISs attached to a fully connected transitive
      subnetwork, as shown in Figure 8: A and B share a BIS-BIS connection,
      B and C share a BIS-BIS connection, but A and C have no BIS-BIS
      connection between themselves.  If C propagates an UPDATE PDU to B,
      then with respect to the UPDATE PDU advertised by B:

      -   C is defined to be the source BIS
      -   B is defined to be the first recipient BIS
      -   A is defined to be the subsequent recipient BIS.

      In terms of these definitions, the following rules apply to the usage
      of the NEXT_HOP attribute:

      a)  Generating the Attribute

          When a given BIS generates an UPDATE PDU:

          1)  It may list its own NET and the SNPAs of subnetworks that
              connect itself to the remote BIS in the NEXT_HOP attribute of
              that UPDATE PDU.

   Kunzinger                     ISO/IEC 10747                 [ Page 112 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          2)  It may choose not to include a NEXT_HOP attribute in its
              UPDATE PDU.  When the NEXT_HOP field is not present, it
              implies that the NET of the BIS that advertises the UPDATE
              PDU should be considered to be the NET of the next-hop BIS.

          3)  It may set the value of the "IDRP_Server_Allowed" field in
              accordance with its local policies:

              -   If the source BIS wants to allow the first recipient BIS
                  to advertise the source BIS's NET and SNPA to a
                  subsequent recipient BIS, then it shall set this field to
                  X'FF'

              -   If the source BIS does not want the first recipient BIS
                  to advertise the source BIS's NET and SNPA, then it shall
                  set this field to any value other than X'FF'.

      b)  Advertising Routeing Information

          When a BIS chooses to advertise routeing information learned from
          an UPDATE PDU:

          1)  The BIS may choose to list its own NET and the SNPAs of
              subnetworks that connect itself to the remote BIS in the
              NEXT_HOP attribute of an UPDATE PDU that propagates the
              routeing information

          2)  The BIS may choose not to include a NEXT_HOP attribute in its
              UPDATE PDU.  When the NEXT_HOP field is not present, it
              implies that the BIS that advertises the UPDATE PDU is also
              the next-hop BIS.

          3)  If any condition listed below is not satisfied, then the
              recipient BIS shall not list the NET and SNPAs of the source
              BIS in its own UPDATE PDUs.  If they are all satisfied, then
              instead of listing its own NET and SNPAs, the BIS may
              optionally list the NET and SNPAs of the source BIS (as
              contained in the UPDATE PDU received from the source BIS)
              when it propagates the information to a subsequent recipient
              BIS.  The conditions are the following:

              i)  The "IDRP_Server_Allowed" field of the UPDATE PDU of the
                  source BIS was equal to X'FF'.


   Kunzinger                     ISO/IEC 10747                 [ Page 113 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

              ii) All three BISs (source, first recipient, and subsequent
                  recipient) are located on a common subnetwork which is
                  full-duplex and is transitive with respect to
                  reachability of all three BISs.

              iii) The managed object routeServer is "true".

              iv) The first recipient and subsequent recipient are located
                  in different routeing domains.

              v)  Advertisement of this route to the subsequent recipient
                  BIS does not conflict with any of the path attributes
                  that were contained in the UPDATE PDU from the source
                  BIS.  (For example, it may not propagate the UPDATE PDU
                  to a recipient that is listed in the DIST_LIST_EXCL
                  attribute.)

      Note 25:  The following observations should be noted with regard to
                the rules stated above:

                a)  The rules do not remove the requirement that there must
                    be a BIS-BIS connections between each pair of BISs
                    located in the same routeing domain.

                b)  The contents of the NEXT_HOP attribute have no effect
                    upon the contents of the RD_PATH attribute: that is,
                    the RD_PATH attribute will always be used in accordance
                    with 7.12.3.

                c)  If the NET and SNPAs are not available in an UPDATE
                    PDU, then a BIS that receives it must learn them by
                    means outside of this International Standard.  For
                    example, the value of the NET can be learned from the
                    NUNITDATA.INDICATION, and IS 9542 can be used to
                    associate an SNPA with that NET.




   Kunzinger                     ISO/IEC 10747                 [ Page 114 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.12.5  DIST_LIST_INCL

      DIST_LIST_INCL is a well-known discretionary attribute.  It shall be
      recognized upon receipt by all BISs.  When present, this attribute
      lists the RDIs of the routeing domains and confederations to which
      the routeing information may be distributed.  Since NPDUs usually
      flow in a direction opposite to the flow of UPDATE PDUs,
      DIST_LIST_INCL provides a means for a given RD or confederation to
      control use of its resources by other RDs.

      When a BIS receives an UPDATE PDU that contains the DIST_LIST_INCL
      attribute, then the receiving BIS shall not redistribute the
      associated routeing information to any BIS which is not a member of
      at least one RD or RDC whose RDI is contained in this attribute.

      A BIS shall redistribute only that information which has been locally
      selected as a route, and shall redistribute it only to RDs or RDCs
      which are both adjacent to it and are included in the distribution
      list.  A BIS may distribute the information to any adjacent BIS that
      is a member of any routeing domain or confederation whose RDI is
      contained in DIST_LIST_INCL.  A BIS is not required to distribute the
      routeing information to every RD or RDC whose RDI is listed: for
      example, it is possible for local policy considerations or the
      contents of the HIERARCHICAL_RECORDING path attribute to further
      restrict the set of RDIs to whom the routeing information will
      actually be redistributed.

      If a BIS receives an UPDATE PDU that contains neither the
      DIST_LIST_INCL nor DIST_LIST_EXCL attributes, then it may distribute
      the routeing information to all adjacent BISs.  Alternatively, the
      local BIS may also add a DIST_LIST_INCL or DIST_LIST_EXCL attribute,
      but not both, to the route information.

      If the DIST_LIST_INCL attribute is present and has a length of zero
      octets, then the routeing information may be used locally, but shall
      not be advertised to any other BIS.

      When it originates an UPDATE PDU which describes a route to
      destinations located in its own routeing domain, a BIS may append the
      DIST_LIST_INCL attribute, in accordance with its local policies.

      If a BIS chooses to advertise a route which was learned from an
      UPDATE PDU which already contained the DIST_LIST_INCL attribute, the
      advertising BIS may modify this attribute by pruning the set of RDIs
      included in the list.  If a BIS chooses to prune the set, it shall

   Kunzinger                     ISO/IEC 10747                 [ Page 115 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      not delete the RDI of its own RD, nor shall it delete the RDI of any
      RDC to which it belongs.  However, if the reduced list is empty (that
      is, has a length of zero), then the BIS shall not advertise the
      routeing information to any BIS located in a different routeing
      domain.

   7.12.5.1  Interaction with HIERARCHICAL_RECORDING

      When a given UPDATE PDU contains both the HIERARCHICAL_RECORDING
      attribute and the DIST_LIST_INCL attribute, the constraints imposed
      by the HIERARCHICAL_RECORDING, as specified in 7.12.12, shall take
      precedence over those imposed by DIST_LIST_INCL.

   7.12.6  DIST_LIST_EXCL

      DIST_LIST_EXCL is a well-known discretionary attribute.  It shall be
      recognized upon receipt by all BISs.  When present, this attribute
      lists the RDIs of routeing domains and confederations to which the
      routeing information may not be distributed.  Since NPDUs usually
      flow in a direction opposite to the flow of UPDATE PDUs,
      DIST_LIST_EXCL provides a means for a given RD or confederation to
      control use of its resources by other RDs and RDCs.

      When a BIS receives an UPDATE PDU that contains the DIST_LIST_EXCL
      attribute, then the receiving BIS shall not redistribute the
      associated routeing information to any BIS located in an RD or RDC
      whose RDI is included in the list.  A BIS shall not distribute the
      information to any adjacent BIS that is a member of any routeing
      domain or confederation whose RDI is contained in DIST_LIST_EXCL.
      Local policy considerations shall not override redistribution of the
      routeing information as dictated by the DIST_LIST_EXCL attribute.

      If a BIS receives an UPDATE PDU that contains neither the
      DIST_LIST_INCL nor the DIST_LIST_EXCL attributes associated with it,
      then it may distribute the routeing information to all adjacent BISs.
      Alternatively, the local BIS may also add a DIST_LIST_INCL or
      DIST_LIST_EXCL attribute, but not both, to the route information.

      If the DIST_LIST_EXCL attribute is absent and the DIST_LIST_INCL
      attribute is present, then the distribution of the routeing
      information is controlled by the DIST_LIST_INCL attribute.  If the
      DIST_LIST_EXCL attribute is present and has a length of zero octets,

   Kunzinger                     ISO/IEC 10747                 [ Page 116 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      then the routeing information may, in accordance with local policy,
      be advertised to any other BIS.

      When it originates an UPDATE PDU which describes a route to
      destinations located in its own routeing domain, a BIS may append the
      DIST_LIST_EXCL attribute, in accordance with its local policies.

      If a BIS chooses to advertise a route which was learned from an
      UPDATE PDU which already contained the DIST_LIST_EXCL attribute, the
      advertising BIS may modify this attribute by augmenting the set of
      RDIs included in the list.  If a BIS chooses to augment the set, it
      shall not add the RDI of its own RD, nor shall it add the RDI of any
      RDC to which it belongs.

   7.12.6.1  Interaction with HIERARCHICAL RECORDING

      When a given UPDATE PDU contains both the HIERARCHICAL_RECORDING
      attribute and the DIST_LIST_EXCL attribute, the constraints imposed
      by DIST_LIST_EXCL, as specified in 7.12.6, shall take precedence over
      those imposed by the HIERARCHICAL_RECORDING attribute.

   7.12.7  MULTI-EXIT_DISC

      MULTI-EXIT_DISC is an optional non-transitive attribute.  If the
      local BIS's managed object multiExit is "true", the BIS may use the
      attribute in its path selection algorithm.  For example, a routeing
      domain may choose to implement a policy which mandates that if all
      other path attributes are equal, the exit point with the lowest value
      of MULTI-EXIT_DISC should be preferred.

      Each BIS that is connected to an adjacent RD by one or more common
      subnetworks may generate a MULTI-EXIT_DISC attribute for each link
      connecting itself to an adjacent RD.  The value of this attribute is
      a local matter, which will be determined by the policies of the RD in
      which the originating BIS is located.

      A BIS that generates a value for this attribute may distribute it to
      all neighboring BISs which are located in adjacent RDs.

      If a MULTI-EXIT_DISC attribute is received from a BIS located in an
      adjacent RD, then the receiving BIS may distribute this attribute to
      all other BISs located in its own RD.  However, the receiving BIS

   Kunzinger                     ISO/IEC 10747                 [ Page 117 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      shall not re-distribute the attribute to any BISs which are not
      located within its own RD.

   7.12.8  TRANSIT DELAY

      TRANSIT DELAY is a well-known discretionary attribute.  A BIS shall
      include this attribute in its UPDATE PDU to indicate that it supports
      routeing based on the Transit Delay attribute, and that it maintains
      Adj-RIBs and a Loc-RIB distinguished by this attribute.

      The average transit delay associated with the local RD is obtained
      from the managed object rdTransitDelay and represents an average
      transit delay that would be experienced by SNSDU size of 512 octets
      while traversing the RD. rdTransitDelay is specified in units of 2
      ms.

      If A BIS advertises a route whose destinations are located in its own
      RD, then the originating BIS may append the Transit Delay attribute
      to the route, using the value contained in managed object
      rdTransitDelay.

      When a BIS re-distributes a route which has been learned in an UPDATE
      PDU that contains the Transit Delay attribute, it shall update the
      value of this attribute before advertising the route to a BIS located
      in another routeing domain.  The updated value shall be computed by
      adding the value in rdTransitDelay to the value of the parameter that
      was received in the UPDATE PDU's Transit Delay attribute.

      If the route is re-distributed to another BIS located in the same RD
      as the advertising BIS, then the Transit Delay attribute shall not be
      modified, but shall be distributed with the same value that was
      present in the received UPDATE PDU.

   7.12.9  RESIDUAL ERROR

      RESIDUAL ERROR is a well-known discretionary attribute.  A BIS shall
      include this attribute in its UPDATE PDU to indicate that it supports
      routeing based on the Residual Error attribute, and that it maintains
      Adj-RIBs and a Loc-RIB distinguished by this attribute.

      The value contained in the RESIDUAL ERROR attribute, in RRE, and in
      managed object rdLRE is a positive integer in the range from 0 to

   Kunzinger                     ISO/IEC 10747                 [ Page 118 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      <2^32> -1; the actual probability of error can be obtained by
      dividing the value by <2^32> -1.

      If A BIS advertises a route whose destinations are located in its own
      RD, then the originating BIS may append the RESIDUAL ERROR attribute
      to the route, using the value contained in managed object rdLRE.  The
      value of the rdLRE is an integer value derived from the average ratio
      of lost, duplicated, or incorrectly delivered SNSDU's to total SNSDUs
      transmitted by the SNDCF during a measurement period: this ratio is
      multiplied by <2^32> -1, and then rounded up to the next higher
      integer.

      When a BIS re-distributes a route which has been learned in an UPDATE
      PDU that contains the RESIDUAL ERROR attribute, it shall update the
      value of this attribute before advertising the route to a BIS located
      in another routeing domain.  The updated value is computed by the
      following formula:

                        K * (1 - ((1-(RRE/K))*(1-(RDLRE/K))))

      where RRE is the value of the RESIDUAL ERROR attribute of the
      received route, RDLRE is the value of the average residual error
      probability associated with the local RD, K is the constant <2^32>
      -1, and the whole expression is rounded up to the nearest integer.

      If the route is re-distributed to another BIS located in the same RD
      as the advertising BIS, then the RESIDUAL ERROR attribute shall not
      be modified, but shall be distributed with the same value that was
      present in the received UPDATE PDU.

   7.12.10  EXPENSE

      EXPENSE is a well-known discretionary attribute.  A BIS shall include
      this attribute in its UPDATE PDU to indicate that it supports
      routeing based on the Expense attribute, and that it maintains
      Adj-RIBs and a Loc-RIB distinguished by this attribute.  The value of
      Expense associated with a given routeing domain is contained in
      managed object locExpense.  It is related to monetary cost.
      Different routeing domains may use different values for this
      attribute:  thus, the attribute must deal in relative monetary costs.


   Kunzinger                     ISO/IEC 10747                 [ Page 119 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      If A BIS advertises a route whose destinations are located in its own
      RD, then the originating BIS may append the Expense attribute to the
      route, using the value contained in managed object locExpense.

      When a BIS re-distributes a route which has been learned in an UPDATE
      PDU that contains the Expense attribute, it shall update the value of
      this attribute before advertising the route to a BIS located in
      another routeing domain.  The updated value is computed by adding the
      value of the expense contained in managed object locExpense to the
      value of the EXPENSE attribute of the received route.

      If the route is re-distributed to another BIS located in the same RD
      as the advertising BIS, then the Expense attribute shall not be
      modified, but shall be distributed with the same value that was
      present in the received UPDATE PDU.

   7.12.11  LOCALLY DEFINED QOS

      LOCALLY DEFINED QOS is a well known discretionary attribute that
      enables a QoS Authority to specify a QoS measurement that is not
      included in the set of QoS measurements specified in this
      International Standard. The QoS Measurement is identified within the
      context of the QoS Authority, which is also responsible for
      specifying its name (QoS Value) and its semantics. A QoS Authority
      may specify as many QoS measurements as necessary, each distinguished
      by the QoS Value field.

      When a BIS supports a LOCALLY DEFINED QOS measurement, this may be
      signalled to adjacent BISs in a RIB-Att as specified in 6.2.  When
      support of a LOCALLY DEFINED QOS measurement is indicated in a
      RIB-Att, then the BIS shall support the Adj-RIBs-In, Adj-RIBs-Out,
      and a Loc-RIB and a FIB corresponding to this RIB-Att. A BIS may only
      include a LOCALLY DEFINED QOS measurement in a RIB-Att when its PIB
      contains the rules necessary to support this measurement.

      When a BIS re-distributes a route which has been learned in an UPDATE
      PDU that contains a LOCALLY DEFINED QOS path attributes, then the new
      UPDATE PDU shall contain the same QoS Value and NSAP Address Prefix
      fields in the LOCALLY DEFINED QOS path attribute, and the metric
      fields (if present) shall be modified in the following way:

      a)  when the route is advertised to a BIS located in the same RD as
          the advertising BIS, the metric value shall not be modified

   Kunzinger                     ISO/IEC 10747                 [ Page 120 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      b)  when the route is advertised to a BIS located in a different RD
          from the advertising BIS, the metric value shall be modified
          according to the rules for that metric.  Rules for modifying a
          given metric value field are defined by the authority responsible
          for assigning the addresses contained in the "address" field of
          this attribute; such rules shall be specified in the PIB.

   7.12.12  HIERARCHICAL RECORDING

      The HIERARCHICAL_RECORDING attribute provides an optional means for
      members of a routeing domain confederation to control transitivity.
      The transitivity constraints are based upon two factors:

      a)  the value of the HIERARCHICAL ATTRIBUTE that was contained in a
          received UPDATE PDU

      b)  knowledge of whether it is necessary to enter or exit a
          confederation in order to reach an adjacent RD.

      If an RD wishes to support this attribute, then it shall obey the
      following usage rules:

      a)  Destination BIS in a Disjoint RDC:

          The HIERARCHICAL_RECORDING attribute shall not be included in an
          UPDATE PDU that is transmitted to a BIS that can be reached only
          by exiting all of the confederations in which the advertising BIS
          resides.

      b)  Destination BIS in Same, Nested, or Overlapping RDC:

          1)  If a given BIS chooses to advertise routeing information that
              it learned from an inbound UPDATE PDU whose
              HIERARCHICAL_RECORDING attribute was equal to 1, or if it is
              the originator of the routeing information, it may advertise
              this information to BISs located in any adjacent routeing
              domain, as follows:

              i)  If it is necessary to enter a confederation in order to
                  reach the destination BIS, then the advertising BIS shall
                  include the HIERARCHICAL RECORDING attribute in its
                  outbound UPDATE PDU, and shall set its value to 0.


   Kunzinger                     ISO/IEC 10747                 [ Page 121 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

              ii) If the destination BIS can be reached without entering
                  any confederation, then the advertising BIS shall include
                  the HIERARCHICAL RECORDING attribute in its outbound
                  UPDATE PDU, and shall set its value to 1.

          2)  If a given BIS chooses to advertise routeing information that
              it learned from an inbound UPDATE PDU whose
              HIERARCHICAL_RECORDING attribute was equal to 0, it may
              advertise that information only to BISs that can be reached
              without exiting any confederation to which the advertising
              BIS belongs.  The HIERARCHICAL_RECORDING attribute shall be
              included in the outbound UPDATE PDU, and its value shall be
              set to 0.

   7.12.12.1  Interaction with DIST_LIST_INCL and DIST_LIST_EXCL

      When a given UPDATE PDU contains both the HIERARCHICAL_RECORDING
      attribute and the DIST_LIST_EXCL attribute, the constraints imposed
      by DIST_LIST_EXCL, as specified in 7.12.6, shall take precedence over
      those imposed by the HIERARCHICAL_RECORDING attribute.

      When a given UPDATE PDU contains both the HIERARCHICAL_RECORDING
      attribute and the DIST_LIST_INCL attribute, the constraints imposed
      by the HIERARCHICAL_RECORDING, as specified in 7.12.12, shall take
      precedence over those imposed by DIST_LIST_INCL.

   7.12.13  RD_HOP_COUNT

      This is a well-known mandatory attribute whose usage is as follows:

      a)  The initial value of this attribute is 0.

      b)  Before sending an UPDATE PDU to a BIS located in an adjacent
          routeing domain, a BIS shall increment the value of this
          attribute by 1, and shall place the result in the RD_HOP_COUNT
          field of the outbound UPDATE PDU.

      c)  A BIS shall not increment the value of this attribute when it
          sends an UPDATE PDU to another BIS located in its own routeing
          domain.

      Note 26:  ISO 8473 limits the maximum lifetime of an NPDU to 256
                counts, and requires each Network entity processing a given

   Kunzinger                     ISO/IEC 10747                 [ Page 122 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

                NPDU to decrement that NPDU's lifetime by at least 1 count.
                In the limiting case of one BIS per routeing domain, this
                implies that a NPDU's lifetime will expire before it can
                reach the 257th RD.  Hence, there is no need to provide an
                RD_HOP_COUNT greater than 256.

   7.12.14  SECURITY

      SECURITY is a well known discretionary attribute that enables a
      Security Authority to specify security related information concerning
      a route.  The security related information is identified within the
      context of the Security Authority, which is also responsible for
      specifying its semantics. Only one security attribute may be included
      in each route.

      When a BIS is able to interpret and act on security related
      information specified by a given Security Authority, this may be
      signalled to adjacent BISs in a RIB-Att as specified in 6.2.  When
      support of the SECURITY attribute is indicated in a RIB-Att, then the
      BIS shall support the Adj-RIBs-In, Adj-RIBs-out, a Loc-RIB and a FIB
      corresponding to this RIB-Att.  A BIS may only include a SECURITY
      distinguishing attribute in a RIB-Att when its PIB contains the rules
      necessary to interpret and act on the security related information
      for the identified Security Authority.

      When a BIS re-distributes a route which has been learned in an UPDATE
      PDU that contains a SECURITY distinguishing attribute, then the new
      UPDATE PDU shall contain the same Security Authority identification
      fields, and the security related information shall be modified
      according to the rules specified in the PIB. Any such modification
      may only reduce the protection level indicated, or add additional
      restrictions on access to the route.

   7.12.15  CAPACITY

      This is a well-known mandatory attribute that is used to denote the
      traffic handling capacity of the RD_PATH listed in the same UPDATE
      PDU.  Different routeing domains may use different values for this
      attribute: thus, the attribute shall deal in relative capacities.

      Note 27:  The semantics of this attribute must be agreed on a
                bilateral basis using mechnaisms outsdide the scope of this

   Kunzinger                     ISO/IEC 10747                 [ Page 123 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

                International Standard before a BIS-BIS connection is
                established.

      The value of capacity that is associated with a given routeing domain
      is contained in managed object capacity.

      If a BIS advertises a route whose destinations are located in its own
      routeing domain, then the originating BIS shall include this
      attribute in its outbound UPDATE PDUs, and its value shall be equal
      to that of managed object capacity.

      If a BIS redistributes a route, it shall include the CAPACITY
      attribute in its outbound UPDATE PDU, and shall reflect the higher of
      the following two quantities: the value of the CAPACITY attribute
      contained in the UPDATE PDU that advertised the route, or the value
      of local managed object capacity.

   7.12.16  PRIORITY

      This well-known discretionary attribute is a distinguishing
      attribute, used to indicate the minimum priority value that the BIS
      will support.  It is an unsigned integer in the range from 0 to 14,
      with higher priority indicated by higher values.

      The value of this parameter is the same for all BISs in a given
      routeing domain, and is equal to the value contained in managed
      object priority.

      If a BIS originates a route to destinations located in its own
      routeing domain, then the originating BIS may include this attribute
      in its outbound UPDATE PDUs; if present, its value shall be equal to
      that of managed object priority.

      If a BIS redistributes a route that was advertised with the PRIORITY
      attribute present, it shall include the PRIORITY attribute in its
      outbound UPDATE PDU, and shall set its value equal to the higher of
      the following two quantities: the value of the PRIORITY attribute
      contained in the UPDATE PDU that advertised the route, or the value
      of local managed object priority.



   Kunzinger                     ISO/IEC 10747                 [ Page 124 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.13  Routeing domain confederations

      Formation of an RDC is done via a private arrangement between its
      members without any need for global coordination; the methods for
      doing so are not within the scope of this International Standard.

      From the outside, an RDC looks similar to a single routeing domain:
      for example, it has an identifier which is an RDI.  Other RDs can
      develop policies with respect to the confederation as a whole, as
      opposed to the individual RDs that are members of the confederation.
      Confederations can be disjoint, nested, or overlapping (see 3.6).

   7.13.1  RDC policies

      Each RD within a confederation may have its own set of policies; that
      is, different RDs in the same confederation can have different
      policies.  For BISs located within the same RD, the methods of 7.15.1
      will detect both internal and external routeing inconsistencies.

      Since a confederation appears to the external world as if it were an
      individual RD, IDRP's loop detection methods will detect routeing
      information loops through a given confederation.  In particular, a
      route which leaves the confederation and then later re-enters it will
      be detected as a loop: thus, a route between two RDs that are members
      of the same confederation will be constrained to remain within that
      confederation.

   7.13.2  RDC configuration information

      Each BIS that participates in one or more RDCs must be aware of the
      RDIs of all confederations of which it is a member, and it must know
      the partial order which prevails between these confederations: that
      is, it must know the nesting and overlap relationships between all
      confederations to which it belongs.  This information shall be
      contained in managed object rdcConfig, which consists of a list of
      confederation RDIs and the partial order that prevails among those
      confederations.

      Since RDCs are formed via private arrangement between their members,
      the partial order of a given confederation is a local matter for that
      confederation, and bears no relationship to the partial orders that
      may prevail in different confederations.  The RDI of its own routeing
      domain is contained in managed object localRDI, as defined in 7.3.

   Kunzinger                     ISO/IEC 10747                 [ Page 125 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.13.3  Detecting confederation boundaries

      A given BIS can tell which confederations are common to itself and an
      adjacent BIS by comparing information obtained from the Confed-IDs
      field of the adjacent BIS's OPEN PDU with the local BIS's rdcConfig
      managed object.  This knowledge determines when an outbound UPDATE
      PDU exits a given confederation and when an inbound UPDATE PDU enters
      a given confederation:

      Exiting a Confederation: An UPDATE PDU sent by a given BIS to an
        adjacent BIS is defined to have exited all those confederations
        whose RDIs are present in the advertising BIS's rdcConfig managed
        object but were not reported in the Confed-IDs field of the
        adjacent BIS's OPEN PDU.

      Entering a Confederation: An UPDATE PDU received from an adjacent BIS
        is defined to have entered all those confederations whose RDIs are
        present in the receiving BIS's rdcConfig managed object but were
        not reported in the Confed-IDs field of the sending BIS's OPEN PDU.

   7.14  Update-Receive process

      The Update-Receive process is initiated when an UPDATE PDU with no
      errors is received while the FSM is in the ESTABLISHED state.  When
      this occurs, the BIS shall update the appropriate Adj-RIB-In.

      For each feasible route, the Adj-RIB-In is identified by the set of
      distinguishing path attributes contained between consecutive
      instances of ROUTE_SEPARATORs or between the last ROUTE_SEPARATOR and
      the end of the UPDATE PDU.  For an unfeasible route, the Adj-RIB-In
      is identified by the ROUTE-ID carried in the WITHDRAWN ROUTES field
      of the UPDATE PDU.  The actions to be taken for each route are:

      a)  If the UPDATE PDU contains a non-empty WITHDRAWN ROUTES field,
          the previously advertised feasible routes associated with the
          ROUTE-IDs contained in this field shall be removed from the
          Adj-RIB-In.  The BIS shall run its Decision Process since the
          previously advertised route is no longer available for use.

      b)   If the UPDATE PDU contains feasible routes, they shall each be
          placed in the appropriate Adj-RIB-In, and the following
          additional actions shall be taken for each route:


   Kunzinger                     ISO/IEC 10747                 [ Page 126 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          1)  If its NLRI and distinguishing attributes are identical to
              those of a route currently stored in the Adj-RIB-In, then the
              new route shall replace the older route in the Adj-RIB-In,
              thus implicitly withdrawing the older route from service.
              The BIS shall run its Decision Process since the older route
              is no longer available for use.

          2)  If the new route is an overlapping route that is more
              specific (see 7.16.3.1) than an earlier route contained in
              the Adj-RIB-In, and the non-distinguishing path attributes of
              the new route differ from those of the earlier route, the BIS
              shall run its Decision Process since the more specific route
              has implicitly made a portion of the less specific route
              unavailable for use.

          3)  If the new route has identical path attributes (both
              distinguishing and non-distinguishing) to an earlier route
              contained in the Adj-RIB-In, and is more specific (see
              7.16.3.1) than the earlier route, no further actions are
              necessary.

          4)  If a new route has different NLRI from any of the routes
              currently in the Adj-RIB-In, it shall be placed in the
              Adj-RIB-In.

          5)  If a new route is an overlapping route that is less specific
              (see 7.16.3.1) than an earlier route in an Adj-RIB-In, the
              BIS shall place the new route in the appropriate Adj-RIB-In.
              The earlier, more specific route remains unaffected.

   7.15  Information consistency

      Correct operation of this protocol requires that all BISs within a
      routeing domain apply a consistent set of policies for calculating
      the degree of preference for an RD-path.  An internal inconsistency
      can occur when there is more than a single path to a particular
      destination.  The hop-by-hop routeing methodology then requires a BIS
      to select only one of these paths for each distinguishable QOS
      category.  Internal inconsistency arises if different BISs within the
      same routeing domain make different selections when presented with
      exactly the same set of routeing information.


   Kunzinger                     ISO/IEC 10747                 [ Page 127 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.15.1  Detecting inconsistencies

      The Update-Receive and Update-Send processes of each BIS shall
      support the LOCAL_PREF field of the ROUTE_SEPARATOR attribute, which
      is a well-known discretionary attribute.  Its value shall be set to
      zero in UPDATE PDUs transmitted to BISs that are located in adjacent
      routeing domains.  In UPDATE PDUs transmitted to BISs that are
      located in the same routeing domain as the local BIS, its value shall
      be set to the degree of preference for the route as computed by the
      advertising (local) BIS.

      A BIS shall detect inconsistent routeing decisions (and, therefore,
      internal inconsistencies) by calculating a degree of preference for
      each route carried in an UPDATE PDU that it receives as part of the
      internal update process (see 7.17.1).  If the degree of preference
      calculated by the local BIS is different from the value carried in
      the LOCAL_PREF field of the UPDATE PDU's ROUTE_SEPARATOR attribute,
      the routeing policies of the two BISs have internal inconsistencies.
      The BIS that detects the inconsistency shall report it to system
      management.

   7.16  Decision process

      The Decision Process selects routes for subsequent advertisement by
      applying the policies in its Policy Information Base to the routes
      stored in its Adj-RIBs-In.  The output of the Decision Process is the
      set of routes that will be advertised to adjacent BISs; the selected
      routes will be stored in the local BIS's Loc-RIBs and Adj-RIBs-Out.

      The selection process is formalized by defining a function that takes
      the attributes of a given route as an argument and returns a
      non-negative integer denoting the degree of preference for the route.
      The function that calculates the degree of preference for a given
      route shall not use as its inputs any of the following: the existence
      of other routes, the non-existence of other routes, or the path
      attributes of other routes.  Route selection then consists of
      individual application of the degree of preference function to each
      feasible route, followed by the choice of the one with the highest
      degree of preference.

      Routes that could form routeing loops must be ignored by the Decision
      Process. Therefore, any route that was a) received from a BIS located
      in an adjacent routeing domain and b) contains in its RD_PATH
      attribute a path segment of type RD_SEQ or RD_SET that contains the

   Kunzinger                     ISO/IEC 10747                 [ Page 128 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      RDI of the local routeing domain or any RDC of which the local RD is
      a member is unfeasible, and shall be discarded by the Decision
      Process.

      IDRP does not require a universally agreed-upon metric to exist
      between multiple RDs.  Instead, IDRP allows each RD to apply its own
      set of criteria for route selection, as determined by its local PIB.
      An example of the syntax and semantics of a routeing policy that
      could be used to calculate a degree of preference is described in
      informative Annex L.

      The Decision process operates on routes contained in each Adj-RIB-In,
      and is responsible for:

      -   selection of routes to be advertised to BISs located in local
          BIS's routeing domain
      -   selection of routes to be advertised to BISs located in adjacent
          routeing domains
      -   route aggregation and route information reduction

      The Decision process takes place in three distinct phases, each
      triggered by a different event:

      a)  Phase 1 is responsible for calculating the degree of preference
          for each route received from a BIS located in an adjacent
          routeing domain, and for advertising to the other BISs in the
          local Routing Domain the routes that have the highest degree of
          preference for each distinct destination.

      b)  Phase 2 is invoked on completion of Phase 1. It is responsible
          for choosing the best route out of all those available for each
          distinct destination, and for installing each chosen route into
          the appropriate Loc-RIB.

      c)  Phase 3 is invoked after the Loc-RIB has been modified.  It is
          responsible for disseminating routes in the Loc-RIB to each
          adjacent BIS located in an adjacent routeing domain, according to
          the policies contained in the PIB. Route aggregation, information
          reduction and the modification of QOS path attributes can
          optionally be performed within this phase.



   Kunzinger                     ISO/IEC 10747                 [ Page 129 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.16.1  Phase 1: calculation of degree of preference

      The Phase 1 decision function shall be invoked whenever the local BIS
      receives an UPDATE PDU from a neighbor BIS that advertises a new
      route, a replacement route, or a withdrawn route.

      The Phase 1 decision function is a separate process which completes
      when it has no further work to do.

      The Phase 1 decision function shall be blocked from running while the
      Phase 2 decision function for the same RIB-Att is in process.

      The Phase 1 decision function shall lock an Adj-RIB-In prior to
      operating on any route contained within it, and shall unlock it after
      operating on all new or unfeasible routes contained within it.

      For each newly received or replacement feasible route, the local BIS
      shall compute a degree of preference.  Then, the local BIS shall run
      the internal update process of 7.17.1 to select and advertise the
      most preferable routes.

      A route received from another BIS in the local routeing domain always
      carries the degree of preference calculated by that BIS in the
      LOCAL_PREF field of the ROUTE_SEPARATOR attribute.  If the value in
      the LOCAL_PREF field differs from the degree of preference computed
      above, then an internal inconsistency has occurred, and the local BIS
      shall report it to system management.

   7.16.2  Phase 2: route selection

      The Phase 2 decision function shall be invoked on completion of Phase
      1.  The Phase 2 function is a separate process which completes when
      it has no further work to do.  The Phase 2 process shall consider all
      routes that are present in the Adj-RIBs-In, including those received
      from BISs located in its own routeing domain and those received from
      BISs located in adjacent routeing domains.

      The Phase 2 decision function shall be blocked from running while the
      Phase 3 decision function is in process.  The Phase 2 function shall
      lock all Adj-RIBs-In with the RIB- Att associated with this instance
      of the process prior to commencing its function, and shall unlock
      them on completion.


   Kunzinger                     ISO/IEC 10747                 [ Page 130 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      For each set of destinations for which a feasible route exists in the
      Adj-RIBs-In identified by the RIB-Att on which this instance of the
      function operates, the local BIS shall identify the route that has:

      a)  the highest degree of preference of any route to the same set of
          destinations, or

      b)  is the only route to that destination, or

      c)  is selected as a result of the Phase 2 tie breaking rules
          specified in 7.16.2.1.

      The local BIS shall then install that route in the Loc-RIB, replacing
      any route to the same destination that is currently held in the
      Loc-RIB.

      When the RIB-Att includes the priority attribute then all routes with
      the same NLRI shall be copied to the Loc-RIB unless their computed
      preference is less than another such route with the same or lower
      priority.

      When the RIB-Att includes the SECURITY attribute then all routes with
      the same NLRI shall be copied to the Loc-RIB unless their computed
      preference is less than another such route which the applicable PIB
      Security Policy rules identify as providing equivalent or poorer
      protection and are usable by the same or more NPDUs.

      If a route copied to a Loc-RIB does not have a NEXT_HOP path
      attribute, then the local BIS shall add that attribute to the entry
      in the Loc-RIB. The value of the attribute shall be the NET of the
      adjacent BIS from which the route was received.

      Unfeasible routes shall be removed from the Loc-RIB, and
      corresponding unfeasible routes shall then be removed from the
      Adj-RIBs-In.

      Note 28:  The decision process should not select a route to
                destinations located within the local routeing domain if
                that route would exit the local routeing domain and later
                re-enter it.  Such routes would be rejected by other RDs
                due to the existence of an RD-loop.  Furthermore, the IDRP
                CLNS Forwarding Process will not forward NPDUs (destined to
                internal destinations) outside of the local RD, but will
                instead hand them over to the intra-domain routeing
                protocol.

   Kunzinger                     ISO/IEC 10747                 [ Page 131 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.16.2.1  Breaking ties (phase 2)

      In its Adj-RIBs-In, a BIS may have several routes to the same
      destination that have the same degree of preference and also have an
      equivalent set of distinguishing attributes.  The local BIS can
      select only one of these routes for inclusion in the associated
      Loc-RIB.  The local BIS considers all equally preferable routes, both
      those received from BISs located in adjacent RDs and those received
      from other BISs located in the local BIS's own RD.

      Ties shall be broken according to the following rules:

      a)  If the candidate routes have identical path attributes or differ
          only in the NEXT_HOP attribute, select the route that was
          advertised by the BIS in an adjacent routeing domain whose NET
          has the lowest value.  If none of the candidate routes were
          received from a BIS located in an adjacent routeing domain,
          select the route that was advertised by the BIS in the local
          routeing domain whose NET has the lowest value.

      b)  If all candidate routes contain the MULTI-EXIT_DISC attribute,
          the candidate routes differ only in their NEXT_HOP and
          MULTI-EXIT_DISC attributes, and the local BIS's managed object
          multiExit is TRUE, select the route that has the lowest value of
          the MULTI-EXIT_DISC attribute.  If multiple candidate routes
          remain, select the route that was advertised by the BIS whose NET
          has the lowest value.

          If the managed object multiExit is false, select the route
          advertised by the BIS in an adjacent RD whose NET has the lowest
          value.  If none of the candidate routes were received from a BIS
          located in an adjacent routeing domain, select the route that was
          advertised by the BIS in the local routeing domain whose NET has
          the lowest value.

      c)  If the candidate routes differ in any path attributes other than
          NEXT_HOP and MULTI-EXIT_DISC, select the route that was
          advertised by the BIS whose NET has the lowest value.  When
          comparing NETs, if one of the candidate routes was received from
          a BIS in an adjacent routeing domain, use the NET of the local
          BIS for the comparison.

      For purposes of determining the lowest-valued NET, each
      binary-encoded NET shall be padded with trailing 0's in order to

   Kunzinger                     ISO/IEC 10747                 [ Page 132 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      bring its length up to 20 octets.  The encoded (and possibly padded)
      NETs shall then be treated as unsigned binary integers.

   7.16.3  Phase 3: route dissemination

      The Phase 3 decision function shall be invoked on completion of Phase
      2, or when any of the following events occur:

      a)  when routes in a Loc-RIB to local destinations have changed

      b)  when locally generated routes with the EXT_INFO attribute (that
          is, routes learned by means outside of IDRP) have changed

      c)  when a new BIS-BIS connection has been established

      d)  when directed to do so by system management.

      The Phase 3 function is a separate process which completes when it
      has no further work to do.

      The Phase 3 Routing Decision function shall be blocked from running
      while the Phase 2 decision function is in process.

      All routes in the Loc-RIB shall be processed into a corresponding
      entry in the associated Adj-RIBs-Out and FIBs (which are identified
      by the same RIB-Att), replacing the current entries., The path
      attributes are updated in accordance with the appropriate subclause
      of 7.12.  Route aggregation and information reduction techniques (see
      7.18) may optionally be applied.  Routes with identical NLRI
      extracted from the same Loc-RIB shall always be aggregated before
      being copied to an Adj-RIB-Out, and may be aggregated with other
      routes according to the local Routing Policy.  Every FIB shall have
      an entry for every destination for which a route exists in a Loc-RIB.

      A locking scheme should be implemented to prevent simultaneous access
      to an FIB by both the phase 3 function and forwarding engine.  The
      phase 3 function should first lock an FIB before entering, replacing
      or deleting an entry, and then unlock that FIB once the operation is
      complete.

      When the updating of the Adj-RIBs-Out and the FIBs is complete, the
      local BIS shall run the external update process of 7.17.2.


   Kunzinger                     ISO/IEC 10747                 [ Page 133 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.16.3.1  Overlapping routes

      A BIS may transmit routes with overlapping NLRI to another BIS.  NLRI
      overlap occurs when a set of destinations are identified in
      non-matching multiple routes, all of which have the same set of
      distinguishing attributes.  Since IDRP encodes NLRI using prefixes,
      overlaps will always exhibit subset relationships.  A route
      describing a smaller set of destinations (a longer prefix) is said to
      be more specific than a route describing a larger set of destinations
      (a shorter prefix); similarly, a route describing a larger set of
      destinations (a shorter prefix) is said to be less specific than a
      route describing a smaller set of destinations (a longer prefix).

      When overlapping routes are present in the same Adj-RIB-In, the more
      specific routes shall take precedence, in order from most specific to
      least specific.

      This precedence relationship effectively decomposes less specific
      routes into two parts:

      -   a set of destinations described only by the less specific route,
          and
      -   a set of destinations described by the overlap of the less
          specific and the more specific routes

      The set of destinations described by the overlap represent a portion
      of the less specific route that is feasible, but is not currently in
      use.  If a more specific route is later withdrawn, the set of
      destinations described by the overlap will still be reachable using
      the less specific route.

      If a BIS receives overlapping routes from a given neighbor, the
      Decision Process shall not simultaneously reject the more specific
      route from neighbor BIS (A) and install A's less specific route
      unless the contents of the local BIS's Adj-RIBs-Out and FIBs insure
      that NPDUs with destinations listed in the NLRI of A's more specific
      route can not be forwarded to the neighbor BIS (A).

      Therefore, when presented with overlapping routes from a given
      neighbor BIS (A), the local BIS could select any of the following
      options, all of which satisfy the criterion stated above:

      a)  Install both the less specific and more specific routes received
          from the given neighbor (A)

   Kunzinger                     ISO/IEC 10747                 [ Page 134 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      b)  Install the more specific route received from the given neighbor
          (A) and reject A's less specific route
      c)  Install the non-overlapping part of the less specific and more
          specific routes received from the given neighbor (A)
      d)  Install a route formed by the aggregation of the less specific
          and the more specific route received from the given neighbor (A)
      e)  Install the less specific route received from the given neighbor
          (A), and also install another route received from a different
          neighbor (B) that is simultaneously:
          1)  more specific than A's less specific route, and
          2)  less specific than A's more specific route.
      f)  Install neither of the routes received from A.

   7.16.4  Interaction with update process

      Since the Adj-RIBs-In are used both to receive inbound UPDATE PDUs
      and to provide input to the Decision Process, care must be taken that
      their contents are not modified while the Decision Process is
      running.  That is, the input to the Decision Process shall remain
      stable while a computation is in progress.

      Two examples of approaches that could be taken to accomplish this:

      a)  The Decision Process can signal when it is running.  During this
          time, any incoming UPDATE PDUs will be queued and will not be
          written into the Adj-RIBs-In.  If more UPDATE PDUs arrive than
          can be fit into the allotted queue, they will be dropped and will
          not be acknowledged.

      b)  A BIS can maintain two copies of the Adj-RIBs-In--one used by the
          Decision Process for its computation (call this the Comp-Adj-RIB)
          and the other to receive inbound UPDATE PDUs (call this the
          Holding-Adj-RIB).  Each time the Decision begins a new
          computation, the contents of the Holding-Adj-RIB will be copied
          to the Comp-Adj-RIB: that is, the a snapshot of the Comp-Adj-RIB
          is used as the input for the Decision Process.  The contents of
          the Comp-Adj-RIB remain stable until a new computation is begun.

      The advantage of the first approach is that it takes less memory; the
      advantage of the second  is that inbound UPDATE PDUs will not be
      dropped.  This international standard does not mandate the use of
      either of these methods.  Any method that guarantees that the input
      data to the Decision Process will remain stable while a computation

   Kunzinger                     ISO/IEC 10747                 [ Page 135 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      is in progress and that is consistent with the conformance
      requirements of this International Standard may be used.

   7.17  Update-Send process

      The Update-Send process is responsible for advertising BISPDUs to
      adjacent BISs.  For example, it distributes the routes chosen by the
      Decision Process to other BISs which may be located in either the
      same RD or an adjacent RD.  Rules for information exchange between
      BIS located in different routeing domains are given in 7.17.2; rules
      for information exchange between BIS located in the same domain are
      given in 7.17.1.

      Distribution of reachability information between a set of BISs, all
      of which are located in the same routeing domain, is referred to as
      internal distribution.  All BISs located in a single RD must present
      consistent reachability information to adjacent RDs, thus requiring
      that they have consistent routeing and policy information among them.

      Note 29:  This requirement on consistency does not preclude an RD
                from distributing different reachability information to
                each of its adjacent routeing domains.  It does mean that
                all of a domain's BISs which are attached to a given
                adjacent domain must provide identical reachability to that
                domain.

      When this protocol is run between BISs located in different routeing
      domains, the communicating BISs must be located in adjacent routeing
      domains--that is, they must be attached to a common subnetwork.

   7.17.1  Internal updates

      The internal update process is concerned with the distribution of
      routeing information to BISs located in the local BIS's own routeing
      domain.  Each BIS selects the most preferable route, if any, that it
      has received from a BIS in an adjacent routeing domain, and
      distributes that route to every other BIS in its own routeing domain.
      This process ensures that all BISs in a routeing domain will select
      the same set of routes.

      The following procedures shall be applied separately for each set of
      Distinguishing Attributes supported by the BIS:

   Kunzinger                     ISO/IEC 10747                 [ Page 136 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      a)  When a BIS receives an UPDATE PDU from another BIS located in its
          own routeing domain, the receiving BIS shall not re-distribute
          the routeing information contained in that UPDATE PDU to other
          BISs located in its own routeing domain.

      b)  When a BIS receives a new feasible route from a BIS in an
          adjacent routeing domain, it shall advertise that route to all
          other BISs in its routeing domain by means of an UPDATE PDU if
          any of the following conditions occur:

          1)  the degree of preference assigned to the newly received route
              by the  local BIS is higher than the degrees of preference
              that the local BIS has assigned to other routes--with the
              same destinations and the same Distinguishing
              Attributes--that have been received from BISs in adjacent
              routeing domains.

          2)  there are no other routes--with the same destinations and the
              same Distinguishing Attributes--that have been received from
              BISs in adjacent routeing domains.

          3)  the newly received route is selected as a result of breaking
              a tie between several routes that were received from BISs in
              adjacent routeing domains and that have the highest degree of
              preference, the same destinations, and the same
              distinguishing attributes (see 7.17.1.1).

      c)  When a BIS receives an UPDATE PDU with a non-empty WITHDRAWN
          ROUTES field, it shall remove from its Adj-RIBs-In all routes
          whose ROUTE-ID was carried in this field.  The BIS shall take the
          following additional steps:

          1)  if the corresponding feasible route had not been previously
              advertised, then no further action is necessary

          2)  if the corresponding feasible route had been previously
              advertised, then:

              i)  if a new route is selected for advertisement that has the
                  same distinguishing attributes and NLRI as the unfeasible
                  route, then the local BIS shall advertise the replacement
                  route

              ii) if a replacement route is not available for
                  advertisement, then the BIS shall include the ROUTE-ID of

   Kunzinger                     ISO/IEC 10747                 [ Page 137 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

                  the unfeasible route in the WITHDRAWN ROUTES field of an
                  UPDATE PDU, and shall send this PDU to each neighbor BIS
                  to whom it had previously advertised the corresponding
                  feasible route.

      All feasible routes which are advertised shall be placed in the
      appropriate Adj-RIB-Out, and all unfeasible routes which are
      advertised shall be removed from the Adj-RIBs-Out.

   7.17.1.1  Breaking ties (internal updates)

      If a local BIS has connections to several BISs in adjacent domains,
      there will be multiple Adj-RIBs-In associated with these neighbors.
      These Adj-RIBs-In might contain several equally preferable routes to
      the same destination, all of which have the same set of
      distinguishing attributes and all of which were advertised by BISs
      located in adjacent routeing domains.  The local BIS shall select one
      of these routes, according to the following rules:

      a)  If all candidate routes contain the MULTI-EXIT_DISC attribute,
          the candidate routes differ only in their NEXT_HOP and
          MULTI-EXIT_DISC attributes, and the local BIS's managed object
          Multiexit is TRUE, select the route that has the lowest value of
          the MULTI-EXIT_DISC attribute.  If multiple candidate routes
          remain, select the route that was advertised by the BIS whose NET
          has the lowest value.
      b)  In all other cases, select the route that was advertised by the
          BIS whose NET has the lowest value.

      For purposes of determining the lowest-valued NET, each
      binary-encoded NET shall be padded with trailing 0's in order to
      bring its length up to 20 octets.  The encoded (and possibly padded)
      NETs shall then be treated as unsigned binary integers.

   7.17.2  External updates

      The external update process is concerned with the distribution of
      routeing information to BISs located in adjacent routeing domains.
      As part of the Phase 3 route selection process, the BIS has updated
      its Adj-RIBs-Out and its FIBs.  All newly installed routes and all
      newly unfeasible routes for which there is no replacement route shall
      be advertised to BISs located in adjacent routeing domains by means
      of UPDATE PDUs.

   Kunzinger                     ISO/IEC 10747                 [ Page 138 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Any routes in the Loc-RIB marked as infeasible shall be removed.
      Changes to the reachable destinations within its own RD shall also be
      advertised in an UPDATE PDU.

      However, advertisement of a given UPDATE PDU shall not violate any
      distribution constraint imposed by the path attributes of the route
      contained therein.  (For example, DIST_LIST_INCL, DIST_LIST_EXCL, and
      HIERARCHICAL _RECORDING are attributes that impose distribution
      constraints on the UPDATE PDU that contains them.)

      A BIS shall not propagate an UPDATE PDU that contains a set of
      distinguishing path attributes that were not listed in the
      RIB-AttsSet field of the neighbor BIS's OPEN PDU.  If such
      distinguishing attributes are advertised, it will cause the BIS-BIS
      connection to be closed, as described in 7.20.3.

   7.17.3  Controlling routeing traffic overhead

      The inter-domain routeing protocol constrains the amount of routeing
      traffic (that is, BISPDUs) in order to limit both the link bandwidth
      needed to advertise BISPDUs and the processing power needed by the
      Decision Process to digest the information contained in the BISPDUs.

   7.17.3.1  Frequency of route advertisement

      The managed object minRouteAdvertisementInterval determines the
      minimum amount of time that must elapse between advertisements of
      routes to a particular destination from a single BIS.  This rate
      limiting procedure applies on a per-destination basis, although the
      value of minRouteAdvertisementInterval is set on a per-BIS basis.

      Two UPDATE PDUs sent from a single BIS that advertise feasible routes
      to some common set of destinations received from BISs in other
      routeing domains must be separated in time by at least
      minRouteAdvertisementInterval.  For example, any technique that
      ensures that the separation will be between one and two times the
      value minRouteAdvertisementInterval is acceptable.

      Since fast convergence is needed within an RD, this procedure does
      not apply for routes received from other BISs in the same routeing
      domain.  To avoid long-lived black holes, the procedure does not
      apply to the explicit withdrawal of unfeasible routes (that is,

   Kunzinger                     ISO/IEC 10747                 [ Page 139 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      routes whose ROUTE_ID is listed in the Withdrawn Routes field of an
      UPDATE PDU).

      This procedure does not limit the rate of route selection, but only
      the rate of route advertisement.  If new routes are selected multiple
      times while awaiting the expiration of minRouteAdvertisementInterval,
      the last route selected shall be advertised at the end of
      minRouteAdvertisementInterval.

   7.17.3.2  Frequency of route origination

      The architectural constant MinRDOriginationInterval determines the
      minimum amount of time that must elapse between successive
      advertisements of UPDATE PDUs that report changes within the
      advertising BIS's own routeing domain.

   7.17.3.3  Jitter

      To minimize the likelihood that the distribution of BISPDUs by a
      given BIS will contain peaks, jitter should be applied to the timers
      associated with minRouteAdvertisementInterval and
      MinRDOriginationInterval.  A given BIS shall apply the same jitter to
      each of these quantities regardless of the destinations to which the
      updates are being sent: that is, jitter will not be applied on a "per
      peer" basis.

      The amount of jitter to be introduced shall be determined by
      multiplying the base value in the appropriate managed object by a
      random factor which is uniformly distributed in the range from 1-J to
      1, where J is the value of the architectural constant Jitter.  The
      result shall be rounded up to the nearest 100 millisecond increment.

      An example of a suitable algorithm is shown in informative Annex E,
      using the architectural constant jitter.




   Kunzinger                     ISO/IEC 10747                 [ Page 140 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.18  Efficient organization of routeing information

      Having selected the routeing information which it will advertise, a
      BIS may avail itself of several methods to organize this information
      in an efficient manner.

   7.18.1  Information reduction

      Information reduction may imply a reduction in granularity of policy
      control--after information is collapsed, the same policies will apply
      to all destinations and paths in the equivalence class.

      The Decision Process may optionally reduce the amount of information
      that it will place in the Adj-RIBs-Out by any of the following
      methods:

      a)  Network Layer Reachability Information:

          Destination NSAP addresses can be represented as NSAP address
          prefixes.  In cases where there is a correspondence between the
          address structure and the systems under control of a routeing
          domain administrator, it will be possible to reduce the size of
          the network layer reachability information that is carried in the
          UPDATE PDUs.

      b)  RD_PATHS:

          RD path information can be represented as ordered RD-SEQUENCES or
          unordered RD_SETs.  RD_SETs are used in the route aggregation
          algorithm described in 7.18.2.  They reduce the size of the
          RD_PATH information by listing each RDI only once, regardless of
          how many times it may have appeared in the multiple RD_PATHS that
          were aggregated.

          An RD_SET implies that the destinations listed in the NLRI can be
          reached through paths that traverse at least some of its
          constituent RDs.  RD_SETs provide sufficient information to avoid
          routeing loops; however, their use may prune potentially useful
          paths, since such paths are no longer listed individually as in
          the form of RD_SEQUENCES.  In practice this is not likely to be a
          problem, since once an NPDU arrives at the edge of a group of
          RDs, the BIS at that point is likely to have more detailed path
          information and can distinguish individual paths to destinations.

   Kunzinger                     ISO/IEC 10747                 [ Page 141 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.18.2  Aggregating routeing information

      Aggregation is the process of combining the characteristics of
      several different routes (or components of a route such as an
      individual path attribute) in such a way that a single route can be
      advertised.  Aggregation can occur as part of the decision process to
      reduce the amount of information that will be placed in the
      Adj-RIBs-Out.  For example, at the boundary of a routeing domain
      confederation an exit BIS can aggregate several intra-confederation
      routes into a single route that will be advertised externally.

      Aggregation reduces the amount of information that BISs must store
      and exchange with each other. Routes can be aggregated by applying
      the following procedures separately to path attributes of like type
      and to the NLRI information.

   7.18.2.1  Route aggregation

      Several routes shall not be aggregated into a single route unless the
      Distinguishing Attributes of each of these route are equivalent, as
      defined in 7.11.3.

      Routes that contain the DIST_LIST_INCL attribute may not be
      aggregated with routes that contain the DIST_LIST_EXCL attribute.

      Routes that have the following attributes shall not be aggregated
      unless the corresponding attributes of each route are identical:
      MULTI-EXIT_DISC and NEXT_HOP.

      An aggregated route is constructed from one or more component routes.
      If a component of an aggregated route that has been advertised in an
      UPDATE PDU becomes unfeasible, then all component routes that
      comprise the aggregated route, except for the unfeasible component,
      shall be advertised again, either as separate routes or as a new
      aggregated route.  If the new aggregated route has the same NLRI as
      the previous aggregated route, then no further actions are necessary,
      since advertisement of the new aggregated route implicitly marks the
      old aggregated route as having been withdrawn from use.  In all other
      cases, the original aggregated route must be withdrawn explicitly by
      means of the Withdrawn Routes field of an UPDATE PDU.


   Kunzinger                     ISO/IEC 10747                 [ Page 142 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.18.2.2  NLRI aggregation

      The aggregation of the NLRI fields from several routes is
      straightforward:

      -   If a shorter NSAP address prefix can be used to represent the
          NSAPs (and only those NSAPs) listed in several individual NSAP
          address prefixes, this may be done.  However, a shorter NSAP
          prefix which would be associated with more NSAPs than were
          associated with the individual prefixes being aggregated shall
          not be used.

      -   Individual NSAP address prefixes from the routes whose NLRI is to
          be aggregated can be listed individually in a single NLRI field.

   7.18.2.3  Path attribute aggregation

      Path attributes that have different type codes can not be aggregated
      together.  Path attributes of the same type code may be aggregated,
      according to the following rules:

      ROUTE_SEPARATOR attributes: When several routes are aggregated, the
         ROUTE_SEPARATOR attribute of the aggregated route shall contain an
         unambiguous ROUTE-ID for the aggregated route, in accordance with
         7.12.1; the advertising BIS shall also compute a degree of
         preference for the aggregated route, and shall carry this value in
         the LOCAL_PREF field, in accordance with 7.12.1.

      EXT_INFO attributes: If at least one route among routes that are
         aggregated has the EXT_INFO attribute, then the aggregated route
         must have the EXT_INFO attribute as well.

      RD_PATH attributes: The individual RD_PATH attributes from which the
         aggregated RD_PATH attribute will be constructed are called the
         component attributes, and the ENTRY_SEQ and ENTRY_SET path
         segments contain the RDIs of confederations that have been entered
         but not yet exited.  If the RDIs of all such confederations appear
         in the same relative order of entry in every component route, then
         aggregation may be performed without pre-processing the component
         routes.  If they appear in different orders of entry in the
         component routes, then the pre-processing step outlined below must
         be performed in order to create the same order of entry in every
         component route before applying the aggregation procedures.

   Kunzinger                     ISO/IEC 10747                 [ Page 143 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         If routes to be aggregated have identical RD_PATH attributes, then
         the aggregated route has the same RD_PATH attribute as each
         individual route, and no further processing is necessary.

         Pre-processing to Attain Identical Order of Entry: Apply the
         following procedure to each component route individually.  Replace
         all path segments, from the first ENTRY_SET or ENTRY_SEQ segment
         to the last path segment, inclusive, with a path segment of type
         ENTRY_SET followed by a path segment of type RD_SET:

         -   The path segment of type ENTRY_SET shall contain the union of
             the all the RDIs listed in the individual ENTRY_SET and
             ENTRY_SEQ segments. The RDIs must be listed in the same order
             in each component route.  The specific ordering algorithm is
             left as a local matter, but it shall guarantee that the RDI of
             a given confederation does not precede the RDI of any
             confederation within which it it is nested.

         -   The path segment of type RD_SET shall contain the union of the
             RDIs contained in all RD_SETs and RD_SEQs that appear after
             the first ENTRY_SET or ENTRY_SEQ of the component route.

         Aggregation Procedures:  For purposes of this procedure, a path
         segment that lists multiple RDIs shall be treated as if it were
         multiple consecutive path segments, where each path segment lists
         a single RDI and the order of appearance of RDIs is maintained.
         For example, a path segment that listed RDIs X, Y, and Z (in that
         order) is treated as if it were a path segment listing X, followed
         by a path segment listing Y, followed by a path segment listing Z.
         If all the RD_PATH attributes of all component routes are
         identical, the aggregated path attribute is equal to the original
         RD_PATH attribute.

         The main procedure of 7.18.2.3.1 calls the subroutine of
         7.18.2.3.2 for aggregating RD_PATH attributes that contain no
         ENTRY_SEQs or ENTRY_SETs (generically called an "Entry Marker").
         In effect, the main procedure applies the subroutine to all
         segments that are located between Entry Markers, between an Entry
         Marker and the end of a component attribute, or between the start
         of a component attribute and its first Entry Marker.

         The main procedure is described in 7.18.2.3.1, and the subroutine
         is described in 7.18.2.3.2.


   Kunzinger                     ISO/IEC 10747                 [ Page 144 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      DIST_LIST_INCL attributes: The DIST_LIST_INCL attribute of the
         aggregated route is formed by the set intersection of the RDIs
         listed in the DIST_LIST_INCL attributes of the individual routes.
         If the set intersection consists of an empty set, then the routes
         shall not be aggregated.

      DIST_LIST_EXCL attributes: The DIST_LIST_EXCL attribute of the
         aggregated route is formed by the set union of the RDIs listed in
         the DIST_LIST_EXCL attribute of the individual routes.  A route
         that contains no DIST_LIST_EXCL attribute is treated as if it
         contained a DIST_LIST_EXCL attribute that lists no RDIs.

      TRANSIT DELAY attributes: The value of the Transit Delay attribute of
         the aggregated route is set to the maximum value of the Transit
         Delay attribute of the individual routes that are aggregated.

      RESIDUAL ERROR attributes: The value of the Residual Error attribute
         of the aggregated route is set to the maximum value of the
         Residual Error attribute of the individual routes that are
         aggregated.

      EXPENSE  attributes: The value of the Expense attribute of the
         aggregated route is set to the maximum value of the Expense
         attribute of the individual routes that are aggregated.

      LOCALLY DEFINED QOS attributes: Routes that contain the LOCALLY
         SPECIFIED QOS attribute shall only be aggregated if their LOCALLY
         SPECIFIED QOS attributes have an identical NSAP Address Prefix
         field and an identical QoS Value field.

         The rules for determining the value of the metric field of each
         such LOCALLY SPECIFIED QOS attribute of the aggregated route are
         specific for each QoS Value and are specified by the responsible
         QoS Authority. They shall be held in the PIB. If no suitable rule
         exists in the PIB then the routes shall not be aggregated.

      HIERARCHICAL RECORDING attributes: If any of the routes to be
         aggregated contains the HIERARCHICAL_RECORDING attribute, the
         aggregated route shall also contain a HIERARCHICAL_RECORDING
         attribute:

         -   If the routes to be aggregated contain different values for
             this attribute, then it shall be set to a value of 0 in the
             aggregated route

   Kunzinger                     ISO/IEC 10747                 [ Page 145 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         -   If all routes to be aggregated contain the same value for this
             attribute, then it shall be set to that value in the
             aggregated route.

      RD_HOP COUNT attribute: The value of the RD_HOP_COUNT of the
         aggregated route shall be set equal to the largest RD_HOP_COUNT
         that was contained in the routes being aggregated.

      SECURITY attribute: Routes that contain the SECURITY attribute shall
         only be aggregated if their SECURITY attributes identify the same
         Security Authority.

         The rules for determining the value of the SECURITY attribute of
         the aggregated route are specified by the responsible Security
         Authority. They shall be held in the PIB. If no suitable rule
         exists in the PIB then the routes shall not be aggregated.

      PRIORITY attributes: The value of the PRIORITY attribute of the
         aggregated route shall be equal to the maximum value of the values
         of the PRIORITY attributes of the routes being aggregated, unless
         the NLRI of component routes are identical.  In this case, the
         value of the PRIORITY attribute of the aggregated route shall be
         the minimum value of the values of the PRIORITY attributes of the
         routes being aggregated.

      CAPACITY Attributes: The value of the CAPACITY attribute of the
         aggregated route shall be equal to the smallest integer value
         contained in the CAPACITY fields of the routes being aggregated.

      7.18.2.3.1  Main procedure for RD_PATH aggregation:  This procedure
      is used to aggregate the RD_PATH attributes of component routes:

      a)  Set the aggregated RD_PATH to "empty".

      b)  Scanning from the back of each non-empty component attribute,
          locate the first Entry Marker.  If the type of marker in any
          component route is ENTRY_SET, then change the type of the
          corresponding Entry Marker in all component attributes to
          ENTRY_SET.

      c)  If no Entry Marker is found, apply the subroutine for aggregating
          RD_PATHs with no Entry Markers (see 7.18.2.3.2), and prepend the
          result to the aggregated RD_PATH attribute.


   Kunzinger                     ISO/IEC 10747                 [ Page 146 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      d)  If a Entry Marker is found, prepend the following to the
          aggregated RD_PATH attribute, in the order indicated: the located
          Entry Marker, followed immediately by the path segments obtained
          by applying the subroutine for aggregation of RD_PATHs with no
          Entry Markers (see 7.18.2.3.2) to the path segments that follow
          the located Entry Marker in each component attribute.  If a
          component attribute has no path segments following the located
          Entry Marker, pass it to the subroutine as an empty set.

      e)  Delete from each component attribute all the path segments that
          were appended to the aggregated attribute in steps c or d.

      f)  Repeat steps b through e until every component attribute is
          empty.

      If there are consecutive path segments of the same type, they shall
      be combined into a single path segment of the same type.

      7.18.2.3.2  Aggregating routes with no entry markers:  The subroutine
      for aggregating RD_PATH attributes with no entry markers is as
      follows:

      a)  Set the aggregated RD_PATH to "empty".

      b)  Scanning from the back of each component attribute, locate the
          first identical longest sequence of path segments that occurs in
          every component attribute, including any that are empty.

          Note 30:  It will not be possible to find an identical sequence
                    in every component attribute if one or more of them are
                    empty.

      c)  If there is no identical sequence, form a path segment of type
          RD_SET that contains every RDI in every non-empty component
          attribute.  Prepend this list to the aggregated RD_PATH
          attribute.

      d)  If the identical sequence is the final sequence of every
          component attribute,  prepend it to the aggregated route.

      e)  If the identical sequence is not the final sequence of every
          component attribute, form a path segment of type RD_SET that
          lists every RDI that occurs between the end of the identical
          sequence and the end of each non-empty component attribute.
          Prepend this list to the aggregated RD_PATH attribute.

   Kunzinger                     ISO/IEC 10747                 [ Page 147 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      f)  Delete from each component attribute all path segments that were
          added to the aggregated RD_PATH attribute in step c, d, or e.

      g)  If, after the deletions in step f have been made, an RDI is
          present in both the aggregated RD_PATH attribute and in any of
          the component attributes, then the accumulated RD_PATH attribute
          shall be replaced by a single path segment of type RD_SET that
          lists every RDI that was present in the component routes that
          were the input to this subroutine  (before any deletions were
          made), and the subroutine terminates.  Otherwise, repeat steps b
          through f until every component attribute is empty.

   7.19  Maintenance of the forwarding information bases

      As summarized in Table 1, the Forwarding Information Bases contain
      the following information for a given RIB-Att (set of distinguishing
      attributes) and set of destinations (NLRI):

      a)  the NET of the next-hop BIS,

      b)  the local SNPA used by the local BIS to forward traffic to the
          next-hop BIS,

      c)  the minimum priority supported by this subnetwork hop, if the
          FIB's RIB-Att contains the PRIORITY attribute

      d)  security related information associated with this subnetwork hop,
          if the FIB's RIB-Att contains the SECURITY attribute

      e)  if available, the SNPA in the next-hop BIS to which NPDUs will be
          forwarded.

      f)  the QoS metric value if the FIB's RIB-Att contains the RESIDUAL
          ERROR, TRANSIT DELAY, EXPENSE, or LOCALLY DEFINED QOS attribute.

      The RIB-Att of the Loc-RIB which contains a route is also the RIB-Att
      of the corresponding FIB; the NLRI for the associated FIB is the same
      as the NLRI of the corresponding route that is stored in the Loc-RIB.
      Therefore, the destination address of an incoming NPDU and its
      NPDU-derived distinguishing attributes (see 8.3) allow a BIS to
      determine the FIB which contains the forwarding information to be
      used for this NPDU.

      The forwarding information consists of three parts.

   Kunzinger                     ISO/IEC 10747                 [ Page 148 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      a)  Net of Next-hop BIS: For each route in the Loc-RIB, the next-hop
          BIS has been determined, and is carried as a tag, as described in
          7.16.2.  The same tag is then carried over into the corresponding
          entry in the FIB.  This information is always present.

      b)  Output SNPA: The SNPA that will be used by the local BIS for
          forwarding traffic to the destinations identified in the NLRI
          field of the FIB is established locally, and is one of the SNPAs
          identified in managed object localSNPA.

      c)  Input SNPA: The SNPA that will be used by the remote BIS to
          receive traffic that is the NEXT_HOP attribute of the
          corresponding route stored in the Loc-RIB.  If the NEXT-HOP
          attribute contains an empty SNPA list, or if the NEXT_HOP
          attribute itself is not included in the route, then the Input
          SNPA field in the FIB will be empty.

      d)  priority: The minimum priority that an NPDU shall have for it to
          be forwarded over this subnetwork hop. If omitted, then the NPDU
          may have any priority.

      e)  security related information:  identifies the protection
          available over the subnetwork hop and the NPDUs that may use it
          with reference to a known Security Policy.

      f)  QoS Metric:  provides the value of the route's QoS metric for the
          corresponding QoS distinguishing path attribute, for use in
          additional matching rules during the NPDU forwarding process.

   7.20  Error handling for BISPDUs

      This section describes actions to be taken when errors are detected
      while processing BISPDUs.  Error handling procedures apply
      individually to each FSM in the BIS.




   Kunzinger                     ISO/IEC 10747                 [ Page 149 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.20.1  BISPDU header error handling

      If BIS-BIS connection was established using authentication code 2
      (checksum plus authentication) and the validation pattern in the
      BISPDU header does not match the locally computed pattern, then the
      BISPDU shall be discarded without any further actions.

      If any of the following error conditions are detected, the BISPDU
      shall be discarded, and the appropriate error event shall be logged
      by the receiving BIS:

      a)  Length field of a PDU header less than 30 octets or greater than
          the Segment Size specified by the remote system's OPEN PDU,

      b)  Length field of an OPEN PDU less than minimum length of an OPEN_
          PDU

      c)  Length field of an UPDATE PDU less than minimum length of an
          UPDATE PDU

      d)  Length field of KEEPALIVE PDU not equal to 30

      e)  Length of an IDRP ERROR PDU less than the minimum length of 32

      f)  Length of a CEASE PDU less than the minimum length of 30

      g)  The BIS-BIS connection was established using authentication code
          1 (checksum without authentication) and the validation pattern in
          the BISPDU header does not match the locally computed pattern

      h)  Type field in the BISPDU is not recognized

   7.20.2  OPEN PDU error handling

      The following errors detected while processing the OPEN PDU shall be
      indicated by sending an IDRP ERROR PDU with error code
      OPEN_PDU_Error.  The error subcode of the IDRP ERROR PDU shall
      elaborate on the specific nature of the error.

      a)  If the version number of the received OPEN PDU is not supported,
          then the error subcode of the IDRP ERROR PDU shall be set to
          Unsupported_Version_Number.  The Data field of the IDRP ERROR PDU
          is a 2-octet unsigned integer, which indicates the highest

   Kunzinger                     ISO/IEC 10747                 [ Page 150 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          supported version number less than the version of the remote BIS
          peer's bid (as indicated in the received OPEN PDU).

      b)  If the Maximum PDU Size field of the OPEN PDU is less than
          MinBISPDULength octets, the error subcode of the IDRP ERROR PDU
          is set to Bad_Maximum PDU_Size.  The Data field of the IDRP ERROR
          PDU is a 2 octet unsigned integer which contains the erroneous
          Maximum PDU Size field.

      c)  If the Routeing Domain Identifier field of the OPEN PDU is not
          the expected one, the error subcode of the IDRP ERROR PDU is set
          to Bad_Peer_RD.  The expected values of the Routeing Domain
          Identifier may be obtained by means outside the scope of this
          protocol (usually it is a configuration parameter).  The value of
          the erroneous RDI is returned in the Data field of the IDRP ERROR
          PDU, encoded as a <length, RDI> pair.  "Length" is a one octet
          field containing a positive integer that gives the number of
          octets used for the following "RDI" field.

      d)  If a BIS receives an OPEN PDU from a BIS located in the same RD,
          and the RIB-AttsSet field contained in that PDU is different from
          the receiving BIS's managed object RIBAttsSet, then the error
          subcode of the IDRP ERROR PDU shall be set to Bad-RIB-AttsSet.

      e)  If the value of the Authentication Code field of the OPEN PDU is
          any value other than 1 or 2, the error subcode of the IDRP ERROR
          PDU is set to Unsupported_Authentication_Code.

      f)  If a given BIS receives an OPEN PDU from another BIS located in
          the same routeing domain, then the RDIs reported in the
          Confed-IDs field of the OPEN PDU (received from the remote BIS)
          should match the Confed-IDs of the local BIS.  If they do not
          match exactly, then an IDRP ERROR PDU shall be issued, indicating
          an OPEN PDU error with an error subcode of RDC_Mismatch.  The
          data field of the IDRP ERROR PDU shall report the offending
          Confed-IDs field from the rejected OPEN PDU.




   Kunzinger                     ISO/IEC 10747                 [ Page 151 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.20.3  UPDATE PDU error handling

      All errors detected while processing the UPDATE PDU are indicated by
      sending an IDRP ERROR PDU with error code UPDATE_PDU_Error.  The
      error subcode of the IDRP ERROR PDU elaborates on the specific nature
      of the error.

      a)  If the Total Attribute Length is inconsistent with the Length
          field of the PDU header, then the error subcode of the IDRP ERROR
          PDU shall be set to Malformed_Attribute_List.  No further
          processing shall be done and all information in the UPDATE PDU
          shall be discarded.

      b)  If any recognized attribute has attribute flags that conflict
          with the attribute type code, then the error subcode of the IDRP
          ERROR PDU shall be set to Attribute_Flags_Error.  The Data field
          of the IDRP ERROR PDU shall contain the incorrect attribute
          (type, length and value).  No further processing shall be done,
          and all information in the UPDATE PDU shall be discarded.

      c)  If any recognized attribute has a length that conflicts with the
          expected length (based on the attribute type code), then the
          error subcode of the IDRP ERROR PDU shall be set to
          Attribute_Length_Error.  The Data field of the IDRP ERROR PDU
          contains the incorrect attribute (type, length and value).  No
          further processing shall be done, and all information in the
          UPDATE PDU shall be discarded.

      d)  If any of the mandatory well-known attributes are not present,
          then the error subcode of the IDRP ERROR PDU shall be set to
          Missing_Well-known_Attribute.  The Data field of the IDRP ERROR
          PDU contains the attribute type code of the missing well-known
          attribute.

      e)  If any well-known attribute (so designated by the attribute
          flags) is not recognized, then the error subcode of the IDRP
          ERROR PDU shall be set to Unrecognized_Well-known_Attribute.  The
          Data field of the IDRP ERROR PDU shall report the unrecognized
          attribute (type, length and value).  In both cases no further
          processing shall be done, and all information in the UPDATE PDU
          shall be discarded.

      f)  If the NEXT_HOP attribute field is invalid, then the error
          subcode of the IDRP ERROR PDU shall be set to
          Invalid_NEXT_HOP_Attribute.  The Data field of the IDRP ERROR PDU

   Kunzinger                     ISO/IEC 10747                 [ Page 152 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          contains the incorrect attribute (type, length and value).  No
          further processing shall be done and all information in the
          UPDATE PDU shall be discarded.

      g)  The sequence of RD path segments shall be checked for RD loops.
          RD loop detection shall be done by scanning the complete list of
          RD path segments (as specified in the RD_PATH attribute) and
          checking that each RDI in this list occurs only once.  If an RD
          loop is detected, then the error subcode of the IDRP ERROR PDU
          shall be set to RD_Routeing_Loop.

          The data field of the IDRP ERROR PDU shall report the first RDI
          that indicated a loop.  This RDI shall be followed immediately by
          the complete RD_PATH attribute.  The encoding shall be:  length,
          RDI, Offending RD_PATH attribute>, where:

          -   "length" is a one octet field that gives the length of the in
              octets of the immediately following RDI field
          -   "RDI" is the RDI that was detected as creating the loop
          -   RD_PATH is the octet string that encoded the value field of
              the offending RD_PATH attribute in the received UPDATE PDU
              (see 6.3.

          No further processing shall be done, and all information in the
          UPDATE PDU shall be discarded.

      h)   If any non-empty set of distinguishing attributes for any route
          advertised in an UPDATE PDU received from a BIS located in a
          different routeing domain does not match any of the RIB-Atts that
          the local (receiving) BIS had advertised to that neighbor in the
          RIB-AttsSet field of its OPEN PDU, then the receiving BIS shall
          send an IDRP Error PDU that reports an error subcode of
          Malformed_Attribute_List.  All information in the UPDATE PDU
          shall be discarded, and no further processing shall be done.

      i)  If the UPDATE PDU contains both the DIST_LIST_INCL and the
          DIST_LIST_EXCL attributes, then the error subcode of the IDRP
          ERROR PDU shall be set to Malformed_Attribute_List.  No further
          processing shall be done, and all information in the UPDATE PDU
          shall be discarded.

      j)  If a BIS receives an UPDATE PDU that has a DIST_LIST_EXCL
          attribute with the RDI of the receiving BIS or the RDI of any RDC
          to which the BIS belongs, the subcode of the IDRP ERROR PDU shall
          be set to Malformed_Attribute_List.  The Data field of the IDRP

   Kunzinger                     ISO/IEC 10747                 [ Page 153 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          ERROR PDU shall report the incorrect attribute (type, length and
          value).  No further processing shall be done, and all information
          in the UPDATE PDU shall be discarded.

      k)  If a BIS receives an UPDATE PDU that has a DIST_LIST_INCL
          attribute without the RDI of the receiving BIS or the RDI of any
          RDC to which the BIS belongs, the subcode of the IDRP ERROR PDU
          shall be set to Malformed_Attribute_List.  The Data field of the
          IDRP ERROR PDU shall report the incorrect attribute (type, length
          and value).  No further processing shall be done, and all
          information in the UPDATE PDU shall be discarded.

          Note 31:  It is permissible for an UPDATE PDU to contain neither
                    the DIST_LIST_INCL nor the DIST_LIST_EXCL attributes.
                    According to 7.12.5, the absence of both the
                    DIST_LIST_INCL and DIST_LIST_EXCL attributes implies
                    that all RDs and all RDCs may receive the routeing
                    information.

      l)  If the length of the NLRI is inconsistent with the Length field
          of the PDU header, then the error subcode of the IDRP ERROR PDU
          shall be set to Malformed_NLRI.  No further processing shall be
          done, and all information in the UPDATE PDU shall be discarded.

      m)  If an optional attribute is recognized, then the value of this
          attribute shall be checked.  If an error is detected, the
          attribute shall be discarded, and the error subcode of the IDRP
          ERROR PDU shall be set to Optional_Attribute_Error.  The Data
          field of the IDRP ERROR PDU shall report the attribute (type,
          length and value).  No further processing shall be done, and all
          information in the UPDATE PDU shall be discarded.

      n)  If RDCs are supported and any of the error conditions noted in
          7.12.3.3 occur, no further processing of the UPDATE PDU shall be
          done, all information in the UPDATE PDU shall be discarded, and
          the error code of the NOTIFICATION PDU shall be set to
          Misconfigured_RDCs.

      o)  If a route carried in an UPDATE PDU contains more than a single
          instance of a distinguishing path attribute, then the error
          subcode shall be set to Malformed_Attribute_List.  No further
          processing shall be done, and all information in the UPDATE PDU
          shall be discarded.


   Kunzinger                     ISO/IEC 10747                 [ Page 154 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          Note 32:  This error condition refers to duplicated attributes
                    within a single route.  It is not an error if a
                    distinguishing attribute of the same type appears in
                    several of the routes carried in an UPDATE PDU that
                    advertises multiple routes.

      p)  If an UPDATE PDU contains more than one instance of a
          non-distinguishing path attribute of the same type, except for
          ROUTE_SEPARATOR, the BIS shall send an IDRP ERROR PDU with error
          subcode Duplicated_Attributes.  The data field of the IDRP ERROR
          PDU shall list the type codes of all such duplicated attributes.

      q)  If the RD_PATH attribute contains an illegal segment type, the
          BIS shall send an IDRP ERROR PDU, with error subcode
          Illegal_RD_Path_Segment.  The data field of the IDRP ERROR PDU
          shall reproduce the encoding of the offending segment of the
          RD_PATH attribute, as it appeared in the received UPDATE PDU.

   7.20.4  IDRP ERROR PDU error handling

      If a BIS receives an IDRP ERROR PDU with a correct validation pattern
      but which contains an unrecognized error code or error subcode, the
      local BIS shall close the connection as described in 7.6.2.

      Note 33:  Any error (such as unrecognized Error Code or Error
                Subcode, or an incorrect Length field in the PDU header)
                should be logged locally and brought to the attention of
                the administration of the peer.  The means to do this are,
                however, outside the scope of this protocol.

   7.20.5  Hold timer expired error handling

      If the FSM for a given BIS-BIS connection is in the ESTABLISHED state
      and the local BIS does not receive successive PDUs of types
      KEEPALIVE, UPDATE, or RIB REFRESH, within the period specified in the
      Hold Time field of the OPEN PDU previously sent to the remote BIS,
      then an IDRP ERROR PDU with error code Hold_Timer_Expired shall be
      sent to the remote BIS and the FSM for the associated BIS-BIS
      connection shall enter the CLOSE-WAIT state.


   Kunzinger                     ISO/IEC 10747                 [ Page 155 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   7.20.6  KEEPALIVE PDU error handling

      The KEEPALIVE PDU consists of only the BISPDU Header. Error
      conditions are handled according to 7.20.1.

   7.20.7  CEASE PDU error handling

      The CEASE PDU consists of only the BISPDU Header. Error conditions
      are handled according to 7.20.1

   7.20.8  RIB REFRESH PDU error handling

      If any of the following error conditions are detected, the BIS shall
      issue an IDRP ERROR PDU with the following error indications:

      a)  Invalid OpCode not in Range 1 to 3: indicate RIB REFRESH error
          with error subcode "Invalid OpCode"

      b)  Receipt of an OpCode 3 (RIB Refresh End) without prior receipt of
          OpCode 2 (Rib Refresh Start): indicate FSM Error

      c)  Receipt of an unsupported RIB-Att in the Rib-Atts variable length
          field in the RIB REFRESH PDU for a RIB Refresh Start OpCode:
          indicate RIB REFRESH error with error subcode "Unsupported
          RIB-Atts"


   8.  Forwarding process for CLNS


      The forwarding process for CLNS operation is driven by the header
      information carried in an ISO 8473 NPDU:

      a)  If the NPDU contains an ISO 8473 complete source route parameter,
          then further forwarding of this NPDU shall be handled by the
          ISO 8473 protocol, not by the mechanisms defined in this
          International Standard.

   Kunzinger                     ISO/IEC 10747                 [ Page 156 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      b)  If the NPDU contains an ISO 8473 partial source route parameter,
          the NPDU shall be forwarded on a path to the next system listed
          in the partial source route parameter.

      c)  If the NPDU does not contain an ISO 8473 source route parameter,
          the NPDU shall be forwarded on a path to the system listed in the
          destination address field of the NPDU.

      Having determined the system to which a path is needed, the BIS shall
      proceed as follows:

      a)  If the destination system is located in its own RD, the local BIS
          shall proceed as defined in 8.1.

      b)  If the destination system is located in a different RD, the local
          BIS shall perform the following actions:

          1)  It shall determine the NPDU-Derived Distinguishing Attributes
              of the NPDU, according to 8.2.

          2)  It shall next apply the procedures of 8.3 to determine if the
              NPDU-derived Distinguishing Attributes match any of the
              FIB-Atts of the Forwarding Information Bases of the local
              BIS:

              i)  If the NPDU-derived Distinguishing Attributes match the
                  FIB-Att of a local FIB, then the NPDU shall select that
                  FIB and shall forward the NPDU using the methods of 8.4.

              ii) Otherwise, perform the ISO 8473 "Discard PDU Function"
                  and generate an ER PDU with the parameter value set to
                  "Unsupported Option not Specified".

          If the underlying data protocol permits the modification or
          removal of the QOS or Priority parameters of the data PDU, then
          the BIS may modify such information appropriately and forward the
          data PDU.




   Kunzinger                     ISO/IEC 10747                 [ Page 157 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   8.1  Forwarding to internal destinations

      If the destination address of an incoming NPDU depicts a system
      located within the routeing domain of the receiving BIS, then it
      shall forward that NPDU to any of the ISs listed in managed object
      INTRA-IS.  That is, any further forwarding of the NPDU is the
      responsibility of the intra-domain routeing protocol.

   8.2  Determining the NPDU-derived distinguishing attributes

      As the first step in forwarding an NPDU to a destination located in
      another routeing domain, the receiving BIS shall determine the
      NPDU-derived Distinguishing Attributes of the incoming ISO 8473 NPDU.
      This determination shall be based on an examination of the priority
      parameter, security parameter, and QOS maintenance parameter in the
      NPDU's header:

      -   The 8473 priority parameter corresponds to the PRIORITY path
          attribute.

      -   The first two bits of the ISO 8473 security parameter are
          decoded:

          -   if they equal '11', then the parameter identifies a globally
              unique and unambiguous security level (see ISO 8473,
              subclause 7.5.3.3)
          -   if they equal '01' then the responsible Security Authority is
              identified by the NPDU's source NSAP Address
          -   if they equal '10' then the responsible Security Authority is
              identified by the NPDU's destination NSAP Address.

          The corresponding NPDU-Derived Distinguishing attribute is then a
          SECURITY attribute identifying the same Security Authority.

      -   The first two bits of the ISO 8473 QoS Maintenance parameter are
          decoded:

          a)  If they equal '01' then the responsible QoS Authority is
              indicated by the source NSAP Address, and the NPDU-Derived
              Distinguishing attribute is determined using the remaining
              octets of the QoS Maintenance parameter and by applying the
              rules specified by the QoS Authority and contained in the PIB
              for selection of the NPDU-Derived Distinguishing attribute.
              If no such rules exist then no NPDU-Derived Distinguishing

   Kunzinger                     ISO/IEC 10747                 [ Page 158 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   | +------------------------------------------------------------------+ |
   | | Table 4. NPDU-Derived Attribute Set.  Some NPDU-derived          | |
   | |          Distinguishing attributes are derived by examining the  | |
   | |          QOS Maintenance Parameter octet for 1 or 0 in the bit   | |
   | |          positions shown below.  The symbol "-" indicates that   | |
   | |          the corresponding bit does not enter into the           | |
   | |          determination.                                          | |
   | +------------------------------------------------+-----------------+ |
   | |            QOS Maintenance Parameter           | NPDU-Derived    | |
   | +-----+-----+-----+-----+-----+------+-----+-----+ Attributes      | |
   | | b[8]| b[7]| b[6]| b[5]| b[4]| b[3] | b[2]| b[1]|                 | |
   | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ |
   | |  1  |  1  |  -  |  -  |  -  |   1  |  0  |  0  | Transit Delay   | |
   | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ |
   | |  1  |  1  |  -  |  -  |  -  |   1  |  0  |  1  | Transit Delay   | |
   | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ |
   | |  1  |  1  |  -  |  -  |  -  |   0  |  0  |  0  | Expense         | |
   | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ |
   | |  1  |  1  |  -  |  -  |  -  |   0  |  1  |  0  | Expense         | |
   | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ |
   | |  1  |  1  |  -  |  -  |  -  |   0  |  1  |  1  | Residual Error  | |
   | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ |
   | |  1  |  1  |  -  |  -  |  -  |   1  |  1  |  1  | Residual Error  | |
   | +-----+-----+-----+-----+-----+------+-----+-----+-----------------+ |
   |                                                                      |
   +----------------------------------------------------------------------+

              attribute shall be associated with this QoS Maintenance
              parameter.

          b)  If they equal '10' then the responsible QoS Authority is
              indicated by the destination NSAP Address, and the
              NPDU-Derived Distinguishing attribute is determined using the
              remaining octets of the QoS Maintenance parameter and by
              applying the rules specified by the QoS Authority and
              contained in the PIB for selection of the NPDU-Derived
              Distinguishing attribute. If no such rules exist then no
              NPDU-Derived Distinguishing attribute shall be associated
              with this QoS Maintenance parameter.

          c)  If they equal '11' then the NPDU-Derived Distinguishing
              attribute is as shown in Table 4.

   Kunzinger                     ISO/IEC 10747                 [ Page 159 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      If examination of the 8473 header shows that no NPDU-Derived
      Distinguished Attributes are present, then the NPDU shall be
      associated with the Empty Distinguishing Attribute.

   8.3  Matching RIB-Att to NPDU-derived distinguishing attributes

      Within the BIS, each of its FIB(s) has an unambiguous RIB-Att (see
      7.10.1) which is constructed from the set of Distinguishing
      Attributes that the local BIS supports.  The set of NPDU-derived
      Distinguishing Attributes matches a given RIB-Att (which is itself a
      set of Distinguishing Attributes) when all of the following
      conditions are satisfied:

      a)  Both sets contain the same number of attributes.

      b)  Each instance of a type-specific attribute in the NPDU-derived
          Distinguishing Attributes must have an equivalent instance in the
          FIB-Att.  The type-specific path attributes supported by IDRP
          are:

          -   Transit delay
          -   Residual error
          -   Expense
          -   Priority

      c)  Each instance of a type-value specific attribute in the
          NPDU-Derived Distinguishing Attributes has a corresponding
          instance in an FIB's RIB-Att, and, depending on the type of the
          NPDU-Derived Distinguishing Attribute:

          LOCALLY DEFINED QOS: The NSAP Address prefixes and QoS Values are
            identical.

          SECURITY: The same Security Authority is identified in each case.

      Provided that such a RIB-Att can be found then the contents is
      inspected to find an entry such that:

      a)  the NLRI contains the NPDU's destination NSAP Address, or an NSAP
          Address prefix which is a prefix of the NPDU's destination NSAP
          Address;

      b)  the subnetwork hop's priority, if present, is less than or equal
          to the NPDU's priority

   Kunzinger                     ISO/IEC 10747                 [ Page 160 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      c)  with reference to the applicable Security Policy rules contained
          in the PIB, the subnetwork hop provides sufficient protection for
          the NPDU, and the NPDU is permitted to use the subnetwork hop.

      d)  when a type specific NPDU-Derived Distinguishing Attribute has
          been selected by a rule specified by a QoS Authority from a
          source or destination specific QoS Maintenance parameter, then an
          additional matching rule may also be specified that determines
          whether the value of the QoS metric is acceptable.

      If such a RIB-Att or entry cannot be found, then perform the
      following procedure in the order indicated, terminating when either a
      match is found or all three steps have been executed:

      a)  if the NPDU's security parameter does not express a requirement
          for protection, the SECURITY attribute may be removed from the
          NPDU- Derived Distinguishing attributes, and the above procedures
          repeated in order to find a match.

      b)  the PRIORITY attribute may be removed from the NPDU-Derived
          Distinguishing attributes, and the above procedures repeated in
          order to find a match.

      c)  LOCALLY DEFINED QOS, EXPENSE, TRANSIT DELAY, or RESIDUAL ERROR
          (only one of which can be present in a valid set of
          distinguishing attributes) may be removed from the NPDU-Derived
          Distinguishing attributes, and the above procedures repeated to
          find a match.

          Note 34:  If no match was found in the first two steps, the third
                    step will reduce the NPDU-Derived distinguishing
                    attributes to either an empty set or a single security
                    attribute.   In the first case, the empty set will
                    match the Empty RIB-Att; in the second case, there can
                    be either a match or a mismatch with the security
                    parameter.




   Kunzinger                     ISO/IEC 10747                 [ Page 161 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   8.4  Forwarding to external destinations

      If the destination address of the incoming NPDU depicts a system
      located in a different routeing domain from the receiving BIS, then
      the receiving BIS shall use the FIB identified by the FIB-Att that
      matches the NDPU-derived Distinguishing Attributes of the incoming
      NPDU.  The incoming NPDU shall be forwarded based on the longest
      address prefix that matches (as in 7.1.2.2) the destination NSAP
      address of the incoming NPDU, as follows:

      a)  If the entry in the inter-domain FIB that corresponds to the
          destination address of the incoming NPDU contains a NEXT_HOP
          entry that identifies a BIS which is located on at least one
          common subnetwork with the local BIS, then the NPDU shall be
          forwarded directly to the BIS indicated in the NEXT_HOP entry.

      b)  If the entry in the inter-domain FIB that corresponds to the
          destination address of the incoming NPDU contains a NEXT_HOP
          entry that identifies a BIS which is not located on at least one
          common subnetwork with the local BIS, then the local BIS has the
          following options:

          1)  Encapsulate the NPDU:  The local BIS may encapsulate the
              NPDU, using its own NET as the source address and the NET of
              the next-hop BIS as the destination address.  Copy the
              following, when present in the header of the encapsulated
              (inner) NPDU, to the header of the encapsulating (outer)
              NPDU:  QOS Maintenance parameter, Segmentation Permitted
              Flag, Error Report Flag, and PDU Lifetime field. When the
              inner NPDU is decapsulated, replace its PDU Lifetime field
              with PDU Lifetime field of the outer NPDU.  The encapsulated
              NPDU shall then be handed over to the intra-domain routeing
              protocol.

              Note 35:  It is a local responsibility to insure that the
                        NPDU is encapsulated appropriately for the RD's
                        intra-domain protocol.  Since this International
                        Standard does not mandate the use of a specific
                        intra-domain protocol, encapsulation details for
                        specific intra-domain protocols are outside its
                        scope.

          2)  Use Paths Provided by the Intra-domain Routeing Protocol:
              The local BIS may query the intra-domain FIB to ascertain if

   Kunzinger                     ISO/IEC 10747                 [ Page 162 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

              the intra-domain protocol is aware of a route to the
              destination system.

              Note 36:  For example, if ISO/IEC 10589 were used as the
                        intra-domain routeing protocol, it would be able to
                        calculate path segments through the RD for systems
                        contained in its "reachable address prefixes".

              If there is an intra-domain route that supports the QOS
              Maintenance parameter of the NPDU and will deliver the NPDU
              to the appropriate next-hop BIS, then the NPDU may be
              forwarded along this route.

              Note 37:  This case makes use of the intra-domain protocol's
                        knowledge of suitable paths through the local RD
                        which support the specified QOS parameter.  It does
                        not require encapsulation of the NPDU.

                        Details of the mapping between the QOS parameters
                        of used by a given intra-domain protocol and the
                        QOS Maintenance parameter of the NPDU must be
                        determined by the intra-domain routeing protocol;
                        this mapping is not within the scope of IDRP.


   9.  Interface to ISO 8473


      For the purposes of its interface to ISO 8473, a BIS shall be
      regarded as being comprised of a co-resident ES and IS.  The protocol
      described in this International Standard, although still within the
      Network layer, shall access the service provided by ISO 8473 through
      an NSAP in the ES part of the BIS.  Hence, a BIS's NET shall, for the
      purposes of communication using ISO 8473, be regarded as NSAP
      address.

      The protocol described in this International Standard interfaces at
      its lower boundary to ISO 8473 using the ISO 8473 primitives shown in
      Table 5.

   Kunzinger                     ISO/IEC 10747                 [ Page 163 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      +-------------------------------------------------------------------+
      | Table 5. IDRP-CL Primitives                                       |
      +-------------------------+-----------------------------------------+
      | Primitive               | Parameters                              |
      +-------------------------+-----------------------------------------+
      |                         |                                         |
      +-------------------------+-----------------------------------------+
      | N-UNITDATA Request      | Destination NSAP Address                |
      |                         | Source NSAP Address                     |
      |                         | QOS                                     |
      |                         | Userdata                                |
      +-------------------------+-----------------------------------------+
      |                         |                                         |
      +-------------------------+-----------------------------------------+
      | N-UNITDATA Indication   | Destination NSAP Address                |
      |                         | Source NSAP Address                     |
      |                         | QOS                                     |
      |                         | Userdata                                |
      +-------------------------+-----------------------------------------+
      |                         |                                         |
      +-------------------------+-----------------------------------------+

      The parameters associated with the N-UNITDATA request primitive are:

      -   Destination NSAP Address is the NET of the BIS to which this
          BISPDU is being sent (that is, the remote BIS)

      -   Source NSAP Address is the NET the BIS that is sending this
          BISPDU (that is, the local BIS)

      -   QOS is the quality of service parameter for this BIS-BIS
          connection

      -   Userdata is an ordered sequence of octets which comprise the
          BISPDU to be sent to the remote BIS

      The parameters associated with the N-UNITDATA indication primitive
      are:

      -   Destination NSAP Address is the NET of the BIS to which this
          BISPDU is being sent

      -   Source NSAP Address is the NET the BIS that is sending this
          BISPDU (that  is, the remote BIS)

   Kunzinger                     ISO/IEC 10747                 [ Page 164 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      -   QOS is the quality of service parameter for this BIS-BIS
          connection

      -   Userdata is an ordered sequence of octets which comprise the
          BISPDU being delivered to the local BIS

   9.1  Use of network layer security protocol over ISO 8473.

      The network layer security protocol described in ISO/IEC 11577 may be
      used over the ISO 8473 protocol to provide security protection of
      IDRP exchanges.  In this case, the NLSP-UNITDATA request and
      indication service primitives are used instead of the N-UNITDATA
      service primitives as described in clause 9.  The use of BN-UNITDATA
      notional service primitives by CD 11577 is then mapped onto the use
      by ISO 8473 of the equivalent N-UNITDATA primitives.

      IDRP may control the protection requirements through the use of the
      NLSP-UNITDATA request and indication primitives or the NLSP QOS
      Protection parameter; or protection may be imposed by NLSP through
      the use of security association management.


   10.  Constants


      This constants used by the protocol defined in this International
      Standard are enumerated in Table 6.





   Kunzinger                     ISO/IEC 10747                 [ Page 165 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   | Table 6. Architectural Constants of IDRP                             |
   +---------------------------+--------------+---------------------------+
   | Name of Constant          | Value        | Description               |
   +---------------------------+--------------+---------------------------+
   | Inter-domain Routeing     | X'85'        | The SPI for the protocol  |
   | Protocol Identifier       |              | described in this         |
   |                           |              | International Standard    |
   +---------------------------+--------------+---------------------------+
   | MinBISPDULength           | 30           | The size in octets of the |
   |                           |              | smallest allowable        |
   |                           |              | BISPDU.                   |
   +---------------------------+--------------+---------------------------+
   | MinRDOriginationInterval  | 15 min       | The minimum time between  |
   |                           |              | successive UPDATE PDUs    |
   |                           |              | advertising routeing      |
   |                           |              | information about the     |
   |                           |              | local RD                  |
   +---------------------------+--------------+---------------------------+
   | Jitter                    | 0,25         | The factor used to        |
   |                           |              | compute jitter according  |
   |                           |              | to 7.17.3.3.              |
   +---------------------------+--------------+---------------------------+
   | MaxCPUOverloadPeriod      | 1 hr         | Maximum time in which a   |
   |                           |              | BIS can remain            |
   |                           |              | CPU-overloaded before     |
   |                           |              | terminating its BIS-BIS   |
   |                           |              | connections.              |
   +---------------------------+--------------+---------------------------+
   | CloseWaitDelay            | 150 s        | The time that a FSM       |
   |                           |              | remains in CLOSE-WAIT     |
   |                           |              | state before entering the |
   |                           |              | CLOSED state.             |
   +---------------------------+--------------+---------------------------+




   Kunzinger                     ISO/IEC 10747                 [ Page 166 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   11.  System management and GDMO definitions


      The operation of the inter-domain routeing functions in a BIS may be
      monitored and controlled using System Management.  This clause
      contains management specification for IDRP, expressed in the GDMO
      notation defined in ISO/IEC 10165-4.  The naming and containment
      hierarchy is shown in Figure 9.

   11.1  Name binding

      idrpConfig-networkEntity NAME BINDING

       SUBORDINATE OBJECT CLASS idrpConfig AND SUBCLASSES;
       NAMED BY SUPERIOR OBJECT CLASS "ISO/IEC 10733 : 19xx":
       networkEntity;
       WITH ATTRIBUTE idrpConfigId;
       CREATE WITH-AUTOMATIC-INSTANCE-NAMING;
       DELETE ONLY-IF-NO-CONTAINED-OBJECTS;
       REGISTERED AS { IDRP.nboi idrpConfig-networkEntity(1) };

      adjacentBIS-idrpConfig NAME BINDING

       SUBORDINATE OBJECT CLASS adjacentBIS AND SUBCLASSES;
       NAMED BY SUPERIOR OBJECT CLASS idrpConfig AND SUBCLASSES;
       WITH ATTRIBUTE bisNet;
       BEHAVIOUR adjacentBIS-idrpConfig-B BEHAVIOUR

        DEFINED AS This name binding attribute identifies a BIS to BIS
        connection information block.  One of these blocks of data should
        exist per remote BIS that this local BIS exchanges BISPDUs with.;;

       REGISTERED AS { IDRP.nboi adjacentBIS-idrpConfig(2) };




   Kunzinger                     ISO/IEC 10747                 [ Page 167 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   |                                contain                               |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 9. IDRP Naming and Containment Hierarchy

   11.2  Managed objects for IDRP

      idrpConfig MANAGED OBJECT CLASS

       DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992": top;
       CHARACTERIZED BY idrpConfigPkg-P PACKAGE;
       REGISTERED AS { IDRP.moi idrpConfig (1)};

      adjacentBIS MANAGED OBJECT CLASS

       DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2: 1992": top;
       CHARACTERIZED BY adjacentBISPkg-P PACKAGE;
       REGISTERED AS { IDRP.moi adjacentBIS(2) };

   11.3  Packages for IDRP

      idrpConfigPkg-P PACKAGE

       BEHAVIOUR iDRPBasicImportedAlarmNotifications-B

        BEHAVIOUR DEFINED AS %Imports the communicationsAlarm notification
        from ISO/IEC 10165-2.  It is used to report the following protocol
        events:

         errorBISPDUsent:  Generated when a BISPDU is received with an
         error in its format.  The significance sub-parameter of each item
         of additionalInformation shall be set to the value `False' (i.e.,
         not significant) so that a managing system receiving the event
         report will be less likely to reject  it.  The probableCause shall
         be set to NLM.communicationsProtocolError.   The perceivedSeverity
         shall be set to 'Minor'.  A subsequent communicationsAlarm with a
         perceivedSeverity value of 'Cleared' shall not be generated.  No
         other fields or parameters shall be used, with the exception of
         further parameters in the AdditionalInformation field, as follows:

         a)  RemoteBISNET for BIS-BIS connection--using the
             notificationRemoteBISNET parameter

   Kunzinger                     ISO/IEC 10747                 [ Page 168 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         b)  BISPDU error code (see 6.4 and 7.20)--this reports the error
             code that will be sent in the ERROR PDU using the parameter
             "notificationBISPDUerrorcode".
         c)  BIS error subcode (see 6.4 and 7.20)--this reports the subcode
             that will be sent using the parameter
             "notificationBISerrorsubcode".
         d)  BISPDU error information (see 6.4 and 7.20)--this reports the
             data from the received BISPDU that will be used to diagnose
             the problem for the Notification.  The parameter
             "notificationBISPDUerrorinfo" will be used to report this
             information.

         OpenBISpduRDCError:  generated when an OPEN BISPDU is received
         from another BIS in the same routeing domain, and the remote BIS
         is not a member of identically the same confederations as the
         local BIS.  The significance sub-parameter of each item of
         additionalInformation shall be set to the value 'False' (i.e., not
         significant) so that a managing system receiving the event report
         will be less likely to reject  it.  The probableCause shall be set
         to NLM.communicationsProtocolError.   The perceivedSeverity shall
         be set to 'Minor'.  A subsequent communicationsAlarm with a
         perceivedSeverity value of 'Cleared' shall not be generated.  No
         other fields or parameters shall be used, with the exception of
         further parameters in the AdditionalInformation field, as follows:

         a)  Remote BIS NET for this BIS-BIS connection--using the
             "notificationRemoteBISNET" parameter.
         b)  Remote BIS Routeing Domain Confederation (RDC) information
             using the "notificationRemoteRDCConfig" parameter.
         c)  Local BIS Routeing Domain Confederation (RDC) information
             using the "notificationLocalRDCConfig" parameter.

         errorBISPDUconnectionclose:  generated when an ERROR PDU has been
         received from a remote BIS.  The significance sub-parameter of
         each item of additionalInformation shall be set to the value
         'False' (i.e., not significant) so that a managing system
         receiving the event report will be less likely to reject  it.  The
         probableCause shall be set to NLM.communicationsProtocolError.
         The perceivedSeverity shall be set to 'Minor'.  A subsequent
         communicationsAlarm with a perceivedSeverity value of 'Cleared'
         shall not be generated.  No other fields or parameters shall be
         used, with the exception of further parameters in the
         AdditionalInformation field, as follows:


   Kunzinger                     ISO/IEC 10747                 [ Page 169 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         a)  RemoteBISNET for BIS-BIS connection--using the
             "notificationRemoteBISNET" parameter
         b)  BISPDU error code (see 6.4 and 7.20)--this reports the error
             code that will be sent in the ERROR PDU using the parameter
             "notificationBISPDUerrorcode".
         c)  BIS error subcode (see 6.4 and 7.20)--this reports the subcode
             that will be sent using the parameter
             "notificationBISerrorsubcode".
         d)  BISPDU error information (see 6.4 and 7.20)--this reports the
             data from the received BISPDU that will be used to diagnose
             the problem for the Notification.  The parameter
             "notificationBISPDUerrorinfo" will be used to report this
             information.

         CorruptAdjRIBIn:  generated when the local method of checking the
         Adj-RIB-In has found an error.  All Adj-RIBs-In are being purged.
         The significance sub-parameter of each item of
         additionalInformation shall be set to the value 'False' (i.e., not
         significant) so that a managing system receiving the event report
         will be less likely to reject  it.  The probableCause shall be set
         to NLM.communicationsProtocolError.   The perceivedSeverity shall
         be set to 'Minor'.  A subsequent communicationsAlarm with a
         perceivedSeverity value of 'Cleared' shall not be generated.  No
         other fields or parameters shall be used, with the exception of
         further parameters in the AdditionalInformation field, as follows:

         a)  The number of integrity check failures detected in the
             parameter "notificationtRIBIntegrityFailure"
         b)  The remote BIS associated with this Adjacent RIB in the
             parameter "notificationRemoteBISNET".

         PacketBomb:  generated when the local BIS received a BISPDU other
         than an OPEN PDU, from an unknown BIS.  The Source-BIS-NET is
         reported in the AdditionalInformation field using the
         "notificationSourceBIS-NET parameter.  The significance
         sub-parameter of each item of additionalInformation shall be set
         to the value 'False' (i.e., not significant) so that a managing
         system receiving the event report will be less likely to reject
         it.  The probableCause shall be set to
         NLM.communicationsProtocolError.   The perceivedSeverity shall be
         set to 'Minor'.  A subsequent communicationsAlarm with a
         perceivedSeverity value of 'Cleared' shall not be generated.  No
         other fields or parameters shall be used, with the exception of
         further parameters in the AdditionalInformation field, as follows.
         These parameters are created from the OPEN PDU values:

   Kunzinger                     ISO/IEC 10747                 [ Page 170 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         a)  notificationSourceBISNET--NET of remote BIS sending packet
             bomb
         b)  notificationSourceBISrdi--RDI of remote BIS sending packet
             bomb
         c)  notificationSourceBISrdc--RDC information for remote BIS
             sending packet bomb

         connectRequestBISUnknown:  generated when the local BIS has
         received an OPEN BISPDU from an unknown BIS.  The significance
         sub-parameter of each item of additionalInformation shall be set
         to the value 'False' (i.e., not significant) so that a managing
         system receiving the event report will be less likely to reject
         it.  The probableCause shall be set to
         NLM.communicationsProtocolError.   The perceivedSeverity shall be
         set to 'Minor'.  A subsequent communicationsAlarm with a
         perceivedSeverity value of 'Cleared' shall not be generated.  No
         other fields or parameters shall be used, with the exception of
         further parameters in the AdditionalInformation field, as follows.
         These parameters are created from the OPEN PDU values:

         a)  notificationSourceBISNET--NET of remote BIS sending OPEN PDU
         b)  notificationSourceBISrdi--RDI of remote BIS sending OPEN PDU
         c)  notificationSourceBISrdc--RDC information for remote BIS
             sending OPEN PDU

         connectionRequested:  generated when the local BIS has received an
         OPEN BISPDU from an adjacent BIS, the FSM for the for the BIS-BIS
         connection is in the CLOSED state, and the managed object
         ListenForOpen has the value TRUE.  The significance sub-parameter
         of each item of additionalInformation shall be set to the value
         'False' (i.e., not significant) so that a managing system
         receiving the event report will be less likely to reject  it.  The
         probableCause shall be set to NLM.communicationsProtocolError.
         The perceivedSeverity shall be set to 'Minor'.  A subsequent
         communicationsAlarm with a perceivedSeverity value of 'Cleared'
         shall not be generated.  No other fields or parameters shall be
         used, with the exception of further parameters in the
         AdditionalInformation field, as follows.  These parameters are
         created from the OPEN PDU values:

         a)  notificationSourceBISNET--NET of remote BIS sending OPEN PDU
         b)  notificationSourceBISNET--NET of remote BIS sending OPEN PDU
         c)  notificationSourceBISrdi--RDI of remote BIS sending OPEN PDU
         d)  notificationSourceBISrdc--RDC information for remote BIS
             sending OPEN PDU

   Kunzinger                     ISO/IEC 10747                 [ Page 171 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         EnterFSMStateMachine:  generated when the IDRP FSM state machine
         used to communicate with another BIS is started.  The
         RemoteBis-NET is reported in the additionalInformation field using
         the "notificationRemoteBISNET" parameter.  The significance
         sub-parameter of each item of additionalInformation shall be set
         to the value 'False' (i.e., not significant) so that a managing
         system receiving the event report will be less likely to reject
         it.  The probableCause shall be set to
         NLM.communicationsProtocolError.   The perceivedSeverity shall be
         set to 'Minor'.  A subsequent communicationsAlarm with a
         perceivedSeverity value of 'Cleared' shall not be generated.  No
         other fields or parameters shall be used.%;,

       iDRPBasicImportedInfoNotifications-B
        BEHAVIOUR DEFINED AS %Imports the communicationsInformation
        notification from ISO/IEC 10165-5.  It is used to report the
        following protocol events:

         EnterFSMState:  generated when a BIS starts the IDRP FSM state
         machine to establish a connection with a remote BIS.  The
         RemoteBis-NET is reported in the AdditionalInformation field using
         the "notificationRemoteBISNET" parameter.  The significant
         subparameter of each item of AdditionalInformation shall be set to
         "false" (that is, not significant) so that a managing system
         receiving the event report will be less likely to reject it.

         FSMStateChange:  generated when the IDRP FSM used to communicate
         with another BIS transitions from one state to another.  The
         RemoteBis-NET is reported in the AdditionalInformation field using
         the "notificationRemoteBISNET" parameter.  The significant
         sub-parameter of each item ofAdditionalInformation shall be set to
         "false" (that is, not significant) so that a managing system
         receiving the event report will be less likely to reject it.%;;

       ATTRIBUTES
        authenticationTypeCode
         INITIAL VALUE DERIVATION RULE
         supplyOnCreate-B
         GET,
        capacity GET,
        externalBISNeighbor GET-REPLACE,
        holdTime GET,
        idrpConfigID
         INITIAL VALUE DERIVATION RULE
         supplyOnCreate-B

   Kunzinger                     ISO/IEC 10747                 [ Page 172 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         GET,
        internalBIS GET-REPLACE,
        internalSystems GET-REPLACE,
        intraIS GET-REPLACE,
        localRDI GET-REPLACE,
        localSNPA GET-REPLACE,
        locExpense GET,
        maxCPUOverloadTimer GET,
        maxPDULocal GET,
        maxRIBIntegrityCheck GET,
        maxRIBIntegrityTimer GET,
        minRDOriginationTimer GET,
        multiExit GET-REPLACE,
        priority GET,
        rdcConfig GET-REPLACE,
        rdLRE GET,
        rdTransitDelay GET,
        retransmissionTime GET,
        ribAttsSet GET,
        routeServer GET-REPLACE,
        version GET;
       ACTIONS
        "GMI":activate,
        "GMI":deactivate;
       NOTIFICATIONS "REC X.721 | ISO/IEC 10165-2:1992":
       communicationsAlarm
        notificationBISerrorssubcode
        notificationBISPDUerrorcode
        notificationBISPDUerrorinfo
        notificationLocalRDCconfig
        notificationRIBIntegrityFailure
        notificationRemoteBISNET
        notificationRemoteRDCconfig
        notificationSourceBISNET
        notificationSourceBISrdc
        notificationSourceBISrdi,
       "REC X.723 | ISO/IEC 10165-5: 1992": communicationsInformation
        notificationRemoteBISNET;
       REGISTERED AS {IDRP.poi idrpConfigPkg-P (1)};

      adjacentBISPkg-P PACKAGE

       ATTRIBUTES
        bisNegotiatedVersion GET,
        bisNet GET,

   Kunzinger                     ISO/IEC 10747                 [ Page 173 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        bisPeerSNPAs GET,
        bisRDC GET
          REPLACE-WITH-DEFAULT
          DEFAULT VALUE IDRP.nullRDC
          GET-REPLACE,
        bisRDI GET
          REPLACE-WITH-DEFAULT
          DEFAULT VALUE IDRP.nullRDI
          GET-REPLACE,
        closeWaitDelayTimer GET,
        holdTimer GET,
        keepAlivesSinceLastUpdate GET,
        keepAliveTimer GET,
        lastAckRecv GET
         INITIAL VALUE IDRP.zero,
        lastAckSent GET
         INITIAL VALUE IDRP.zero,
        lastSeqNoRecv GET
         INITIAL VALUE IDRP.zero,
        lastPriorSeqNo GET-REPLACE,
        lastSeqNoSent GET
         INITIAL VALUE IDRP.zero,
        listenForOPEN GET,
        maxPDUPeer GET,
        minRouteAdvertisementInterval GET,
        minRouteAdvertisementTimer GET,
        outstandingPDUs GET,
        state GET,
        totalBISPDUsIn GET,
        totalBISPDUsOut GET,
        updatesIn GET,
        updatesOut GET;
       ATTRIBUTE GROUPS
        "GMI":counters
         updatesIn
         updatesOut
         totalBISPDUsIn
         totalBISPDUsOut
         keepAlivesSinceLastUpdate,
        "DMI":state
         state;
       ACTIONS
        "GMI":activate,
        "GMI":deactivate;
       REGISTERED AS { IDRP.poi adjacentBISPkg-P (2) }

   Kunzinger                     ISO/IEC 10747                 [ Page 174 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   11.4  Attribute definitions

      authenticationTypeCode ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.AuthenticationCode;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR authenticationTypeCode-B
        BEHAVIOUR DEFINED AS Indication of which authentication mechanism
        will be used;;
       REGISTERED AS { IDRP.atoi authenticationTypeCode(1) };

      bisNegotiatedVersion ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.BisNegotiatedVersion;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR bisNegotiatedVersion-B
        BEHAVIOUR DEFINED AS The negotiated version of IDRP protocol  this
        BIS to BIS connection is using.;;
       REGISTERED AS { IDRP.atoi bisNegotiatedVersion(2) };

      bisNet ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.BisNet;
       MATCHES FOR EQUALITY;
       BEHAVIOUR bisNet-B
        BEHAVIOUR DEFINED AS The NET of the remote BIS of this BIS to BIS
        connection.;;
       REGISTERED AS { IDRP.atoi bisNet(3) };

      bisPeerSNPAs ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.BisPeersSNPAs;
       MATCHES FOR EQUALITY;
       BEHAVIOUR bisPeerSNPAs-B
        BEHAVIOUR DEFINED AS The SNPAs announced by the remote BIS of this
        BIS to BIS connection.;;
       REGISTERED AS { IDRP.atoi bisPeerSNPAs(4) };

      bisRDC ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Rdcgroup;
       MATCHES FOR EQUALITY;
       BEHAVIOUR bisRDC-B
        BEHAVIOUR DEFINED AS The RDCs the remote BIS belong to, as reported
        in the OPEN PDU received from the remote BIS;;

   Kunzinger                     ISO/IEC 10747                 [ Page 175 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       REGISTERED AS { IDRP.atoi bisRDC(5) };

      bisRDI ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Rdi;
       MATCHES FOR EQUALITY;
       BEHAVIOUR bisRDI-B
        BEHAVIOUR DEFINED AS The RDI of the remote BIS participating in
        this BIS-BIS connection.;;
       REGISTERED AS { IDRP.atoi bisRDI(6) };

      capacity ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Capacity;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR capacity-B
        BEHAVIOUR DEFINED AS The traffic carrying capacity of this Routeing
        Domain.;;
       REGISTERED AS { IDRP.atoi capacity(7) };

      closeWaitDelayTimer ATTRIBUTE

       DERIVED FROM "GMI":timer;
       BEHAVIOUR closeWaitDelayTimer-B
        BEHAVIOUR DEFINED AS The timer that measures in seconds the time
        that has elapsed since the BIS FSM entered the CLOSE-WAIT state.
        Upon timer expiration, the BIS FSM will enter the CLOSED state;;
       REGISTERED AS { IDRP.atoi closeWaitDelayTimer(8) };

      externalBISNeighbor ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.BISGroup;
       MATCHES FOR EQUALITY;
       BEHAVIOUR externalBISNeighbor-B
        BEHAVIOUR DEFINED AS The set of NETs which identify the BISs in
        adjacent routeing domain that are reachable via a single subnetwork
        hop.;;
       REGISTERED AS { IDRP.atoi externalBISNeighbor(9) };

      holdTime ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Holdtime;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR holdTime-B

   Kunzinger                     ISO/IEC 10747                 [ Page 176 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        BEHAVIOUR DEFINED AS The maximum number of seconds that may elapse
        between the receipt of two successive BISPDUs from the adjacent BIS
        of any of the following types:  KEEPALIVE, UPDATE, RIB CHECKSUM
        PDUs or RIB REFRESH PDUs;;

       REGISTERED AS { IDRP.atoi holdTime(10) };

      holdTimer ATTRIBUTE

       DERIVED FROM "GMI":timer;
       BEHAVIOUR holdTimer-B
        BEHAVIOUR DEFINED AS The timer that measures in seconds the time
        that has elapsed since the local BIS's most recent reception from
        the peer BIS of any of the following types of BISPDUs:  KEEPALIVE,
        UPDATE, RIB REFRESH;;
       REGISTERED AS { IDRP.atoi holdTimer(11) };

      idrpConfigID ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.NetworkEntityTitle;
       MATCHES FOR EQUALITY;
       BEHAVIOUR idrpConfigID-B
        BEHAVIOUR DEFINED AS The NET of the local BIS.;;
       REGISTERED AS { IDRP.atoi idrpConfigID(50) };

      internalBIS ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.BISGroup;
       MATCHES FOR EQUALITY;
       BEHAVIOUR internalBIS-B
        BEHAVIOUR DEFINED AS The set of NETs which identify the BISs in
        this routeing domain;;
       REGISTERED AS { IDRP.atoi internalBIS(12) };

      internalSystems ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.SystemIdGroup;
       MATCHES FOR EQUALITY;
       BEHAVIOUR internalSystems-B
        BEHAVIOUR DEFINED AS The set of NET and NSAP prefixes that identify
        the systems in this routeing domain for which the BIS constructs
        this routeing domain from which the BIS constructs network layer
        reachability information;;
       REGISTERED AS { IDRP.atoi internalSystems(13) };

   Kunzinger                     ISO/IEC 10747                 [ Page 177 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      intraIS ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.BISGroup;
       MATCHES FOR EQUALITY;
       BEHAVIOUR intraIS-B
        BEHAVIOUR DEFINED AS The set of NETs of the ISs to which the local
        BIS may deliver an inbound NPDU whose destination lies within the
        BIS's routeing domain.  These ISs must be located on the same
        common subnetwork as this local BIS, and must be capable of
        delivering NPDUs to destinations that are located within the local
        BIS's routeing domain.;;
       REGISTERED AS { IDRP.atoi intraIS(14) };

      keepAlivesSinceLastUpdate ATTRIBUTE

       DERIVED FROM "GMI":nonWrapping64BitCounter;
       BEHAVIOUR keepAlivesSinceLastUpdate-B
        BEHAVIOUR DEFINED AS The number of KEEPALIVE BISPDUS received by
        this BIS from the remote BIS since this last UPDATE BISPDU.;;
       REGISTERED AS { IDRP.atoi keepAlivesSinceLastUpdate(15) };

      keepAliveTimer ATTRIBUTE

       DERIVED FROM "GMI":timer;
       BEHAVIOUR keepAliveTimer-B
        BEHAVIOUR DEFINED AS The timer that measures in seconds the time
        that has elapsed since the previous KEEPALIVE PDU from the adjacent
        BIS was received by the local BIS.  Upon its expiration, the BIS
        will send a BISPDU to its peer BIS;;
       REGISTERED AS { IDRP.atoi keepAliveTimer(16) };

      lastAckRecv ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Integer;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR lastAckRecv-B
        BEHAVIOUR DEFINED AS The number of the last ack received from the
        remote BIS by this local BIS on this BIS to BIS connection.;;
       REGISTERED AS { IDRP.atoi lastAckRecv(17) };

      lastAckSent ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Integer;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR lastAckSent-B

   Kunzinger                     ISO/IEC 10747                 [ Page 178 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        BEHAVIOUR DEFINED AS The number of the last ack sent to the remote
        BIS from this local BIS on this BIS to BIS connection.;;
       REGISTERED AS { IDRP.atoi lastAckSent(18) };

      lastSeqNoRecv ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Integer;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR lastSeqNoRecv-B
        BEHAVIOUR DEFINED AS The last sequence number received from the
        remote BIS by this local BIS on this BIS to BIS connection.;;
       REGISTERED AS { IDRP.atoi lastSeqNoRecv(19) };

      lastPriorSeqNo ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Integer;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR lastPriorSeqNo-B
        BEHAVIOUR DEFINED AS The last sequence number sent to the remote
        BIS immediately before the local BIS enters the CLOSED state;;
       REGISTERED AS { IDRP.atoi lastPriorSeqNo(49) };

      lastSeqNoSent ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Integer;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR lastSeqNoSent-B
        BEHAVIOUR DEFINED AS The last sequence number sent to the remote
        BIS from this local BIS on this BIS to BIS connection.;;
       REGISTERED AS { IDRP.atoi lastSeqNoSent(20) };

      listenForOPEN ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Boolean;
       MATCHES FOR EQUALITY;
       BEHAVIOUR listenForOPEN-B
        BEHAVIOUR DEFINED AS The boolean value determines how the Finite
        State machnine will react to reception of an OPEN PDU while it is
        in the CLOSED state;;
       REGISTERED AS { IDRP.atoi listenForOPEN(21) };

      localRDI ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Rdi;
       MATCHES FOR EQUALITY;

   Kunzinger                     ISO/IEC 10747                 [ Page 179 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       BEHAVIOUR localRDI-B
        BEHAVIOUR DEFINED AS The Routing Domain Identifier for the routeing
        domain where this BIS is located;;
       REGISTERED AS { IDRP.atoi localRDI(22) };

      localSNPA ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.LocalSNPAs;
       MATCHES FOR EQUALITY;
       BEHAVIOUR localSNPA-B
        BEHAVIOUR DEFINED AS The list of SNPAs of this BIS;;
       REGISTERED AS { IDRP.atoi localSNPA(23) };

      locExpense ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.LocExpense;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR locExpense-B
        BEHAVIOUR DEFINED AS The monetary expense of transiting this
        Routeing Domain.  The attribute contains an indication of cost and
        the units in which it is calculated;;
       REGISTERED AS { IDRP.atoi locExpense(24) };

      maxCPUOverloadTimer ATTRIBUTE

       DERIVED FROM "GMI":timer;
       BEHAVIOUR maxCPUOverloadTimer-B
        BEHAVIOUR DEFINED AS The timer that measures in seconds the time
        that has elapsed since the local BIS has detected that its CPU has
        become overloaded.  See Annex H;;
       REGISTERED AS { IDRP.atoi maxCPUOverloadTimer(25) };

      maxPDULocal ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.MaxPDUSize;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR maxPDULocal-B

        BEHAVIOUR DEFINED AS The maximum number of octets that a peer BIS
        can include in a BISPDU that it sends to this BIS.  The local BIS
        informs its peer of this value via the OPEN PDU sent to the peer;;

       REGISTERED AS { IDRP.atoi maxPDULocal(26) };

      maxPDUPeer ATTRIBUTE

   Kunzinger                     ISO/IEC 10747                 [ Page 180 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       WITH ATTRIBUTE SYNTAX IDRP.MaxPDUSize;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR maxPDUPeer-B

        BEHAVIOUR DEFINED AS The maximum number of octets that this BIS
        will include in a BISPDU that it sends to its peer BIS.  This value
        is obtained from information in the header of the peer BIS's OPEN
        PDU;;

       REGISTERED AS { IDRP.atoi maxPDUPeer(27) };

      maxRIBIntegrityCheck ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.MaxRIBIntegrityCheck;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR maxRIBIntegrityCheck-B
        BEHAVIOUR DEFINED AS The maximum time in seconds between checking
        of the Adj-RIBs-In by a local mechanism.  If corrupt Adj-RIB-In is
        detected, the BIS shall purge the offending Adj-RIB-In;;
       REGISTERED AS { IDRP.atoi maxRIBIntegrityCheck(28) };

      maxRIBIntegrityTimer ATTRIBUTE

       DERIVED FROM "GMI":timer;
       BEHAVIOUR maxRIBIntegrityTimer-B
        BEHAVIOUR DEFINED AS The timer that measures in seconds the time
        remaining until the Adj-RIBs-In must be checked by a local
        mechanism.  If a corrupt Adj-RIB-In is detected, the BIS shall
        purge the offending Adj-RIB-In;;
       REGISTERED AS { IDRP.atoi maxRIBIntegrityTimer(29) };

      minRDOriginationTimer ATTRIBUTE

       DERIVED FROM "GMI":timer;
       BEHAVIOUR minRDOriginationTimer-B
        BEHAVIOUR DEFINED AS The timer that measures in seconds the time
        that has elapsed since the advertisement by the local BIS of an
        UPDATE PDU that reported changes within the local BIS's routeing
        domain.  See 7.17.3.2;;
       REGISTERED AS { IDRP.atoi minRDOriginationTimer(30) };

      minRouteAdvertisementInterval ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.MinRouteAdvertisementInterval;
       MATCHES FOR EQUALITY, ORDERING;

   Kunzinger                     ISO/IEC 10747                 [ Page 181 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       BEHAVIOUR minRouteAdvertisementInterval-B
        BEHAVIOUR DEFINED AS The minimum time in seconds that must elapse
        between successive advertisements by a single BIS to the adjacent
        BIS of routes to a particular destination;;
       REGISTERED AS { IDRP.atoi minRouteAdvertisementInterval(48) };

      minRouteAdvertisementTimer ATTRIBUTE

       DERIVED FROM "GMI":timer;
       BEHAVIOUR minRouteAdvertisementTimer-B
        BEHAVIOUR DEFINED AS The timer that measures in seconds the time
        that has elapsed since the advertisement by the local BIS to the
        adjacent BIS of a better route that was received from a BIS located
        in another routeing domain.  See 7.17.3.2.  The minimum value is 5
        seconds, and the maximum value is 1800 seconds;;
       REGISTERED AS { IDRP.atoi minRouteAdvertisementTimer(31) };

      multiExit ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Boolean;
       MATCHES FOR EQUALITY;
       BEHAVIOUR multiExit-B
        BEHAVIOUR DEFINED AS The indication whether this BIS will use the
        MULTI_EXIT_DISC attribute to decide between otherwise identical
        routes.  The multiExit parameter is used as the default value for
        the "multi_exit_disc" function in policy decisions.;;
       REGISTERED AS { IDRP.atoi multiExit(32) };

      outstandingPDUs ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.OutstandingPdus;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR outstandingPDUs-B
        BEHAVIOUR DEFINED AS The maximum number of BISPDUs that may be sent
        to this BIS without receiving an acknowledgement;;
       REGISTERED AS { IDRP.atoi outstandingPDUs(33) };

      priority ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Priority;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR priority-B
        BEHAVIOUR DEFINED AS The lowest value of ISO 8473 priority
        parameter that this RD will provide forwarding services for;;
       REGISTERED AS { IDRP.atoi priority(34) };

   Kunzinger                     ISO/IEC 10747                 [ Page 182 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      rdcConfig ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.RdcNest;
       MATCHES FOR EQUALITY;
       BEHAVIOUR rdcConfig-B
        BEHAVIOUR DEFINED AS A depiction of the nesting relationships that
        exist between the confederations to which the local BIS belongs.
        Each nesting relationship identifies a top level confederation to
        which the local routeing domain belongs; it also lists in order,
        from outermost to innernmost, a set of nested RDCs on a path
        between the local RDI and the top level confederation.  Since
        confederations can overlap one another, there may several paths
        between a given bottom level confederation and a given top level
        confederation.  Hence, same top level confederation and bottom
        level confederation could be contained in several of the elements
        that comprise this attribute.;;
       REGISTERED AS { IDRP.atoi rdcConfig(35) };

      rdLRE ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Rdlre;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR rdLRE-B
        BEHAVIOUR DEFINED AS A quantity that is proportional to the average
        error rate of a Routeing Domain and is expressed as an an integer
        in the range from 0 to <2^32> - 1.  The actual error rate is equal
        to the integer value divided by <2^32> -1.;;
       REGISTERED AS { IDRP.atoi rdLRE(36) };

      rdTransitDelay ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.RDTransitDelay;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR rdTransitDelay-B
        BEHAVIOUR DEFINED AS The estimated average delay across a Routeing
        Domain in units of 2 ms.;;
       REGISTERED AS { IDRP.atoi rdTransitDelay(37) };

      retransmissionTime ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.RetransmissionTime;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR retransmissionTime-B
        BEHAVIOUR DEFINED AS The Number of seconds between KEEPALIVE
        messages if no other traffic is sent;;

   Kunzinger                     ISO/IEC 10747                 [ Page 183 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       REGISTERED AS { IDRP.atoi retransmissionTime(38) };

      ribAttsSet ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.RibAttsSet;
       MATCHES FOR EQUALITY;
       BEHAVIOUR ribAttsSet-B
        BEHAVIOUR DEFINED AS The set of Rib Attributes supported by this
        BIS.;;
       REGISTERED AS { IDRP.atoi ribAttsSet(39) };

      routeServer ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Boolean;
       MATCHES FOR EQUALITY;
       BEHAVIOUR routeServer-B
        BEHAVIOUR DEFINED AS The indication whether this BIS may set the
        "IDRP_Server_Allowed" field in the NEXT_HOP attribute to X"FF" for
        BIS to BIS UPDATE BISPDUs.  If this variable is true then in
        accordance with local policy, the IDRP_Server_Allowed field may be
        set on some UPDATE BISPDUs that this BIS sends.  If this attribute
        is set to false, then no UPDATE BISPDUs will be sent by this BIS
        with NEXT_HOP attributes containing an "IDRP_Server flag" equal to
        X"FF".;;
       REGISTERED AS { IDRP.atoi routeServer(40) };

      state ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.State;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR state-B
        BEHAVIOUR DEFINED AS The current state of BIS to BIS communication
        in the local BIS.;;
       REGISTERED AS { IDRP.atoi state(41) };

      totalBISPDUsIn ATTRIBUTE

       DERIVED FROM "GMI":nonWrapping64BitCounter;
       BEHAVIOUR totalBISPDUsIn-B
        BEHAVIOUR DEFINED AS The number of BISPDUS received by this BIS
        from the remote BIS on this BIS to BIS connection.;;
       REGISTERED AS { IDRP.atoi totalBISPDUsIn(42) };

      totalBISPDUsOut ATTRIBUTE

   Kunzinger                     ISO/IEC 10747                 [ Page 184 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       DERIVED FROM "GMI":nonWrapping64BitCounter;
       BEHAVIOUR totalBISPDUsOut-B
        BEHAVIOUR DEFINED AS The number of BISPDUS received by this BIS
        from the remote BIS on this BIS to BIS connection.;;
       REGISTERED AS { IDRP.atoi totalBISPDUsOut(43) };

      updatesIn ATTRIBUTE

       DERIVED FROM "GMI":nonWrapping64BitCounter;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR updatesIn-B
        BEHAVIOUR DEFINED AS The number of UPDATE BISPDUs received by this
        BIS on this BIS to BIS connection.;;
       REGISTERED AS { IDRP.atoi updatesIn(44) };

      updatesOut ATTRIBUTE

       DERIVED FROM "GMI":nonWrapping64BitCounter;
       BEHAVIOUR updatesOut-B
        BEHAVIOUR DEFINED AS The number of UPDATE BISPDUs sent by this BIS
        on this BIS to BIS connection.;;
       REGISTERED AS { IDRP.atoi updatesOut(45) };

      version ATTRIBUTE

       WITH ATTRIBUTE SYNTAX IDRP.Version;
       MATCHES FOR EQUALITY, ORDERING;
       BEHAVIOUR version-B
        BEHAVIOUR DEFINED AS The version of IDRP protocol this machine
        defaults to using.;;
       REGISTERED AS { IDRP.atoi version(46) };

   11.5  Parameter definitions

      notificationRemoteBISNET PARAMETER

       CONTEXT EVENT-INFO;
       WITH SYNTAX IDRP.RemoteBISNetActionReply;
       BEHAVIOUR notificationRemoteBISNET-B
        BEHAVIOUR DEFINED AS The NET of the Remote BIS that this local BIS
        is starting IDRP protocol communication with.;;
       REGISTERED AS { IDRP.proi notificationRemoteBISNET(1) };

      notificationBISPDUerrorcode PARAMETER

   Kunzinger                     ISO/IEC 10747                 [ Page 185 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       CONTEXT EVENT-INFO;
       WITH SYNTAX  IDRP.BispduErrorCode;
       BEHAVIOUR notificationBISPDUerrorcode-B
        BEHAVIOUR DEFINED AS The error code indicating what type of error
        occurred in the BIS PDU.;;
       REGISTERED AS { IDRP.proi notificationBISPDUerrorcode(2) };

      notificationBISerrorsubcode PARAMETER

       CONTEXT EVENT-INFO;
       WITH SYNTAX  IDRP.BispduErrorSubcode;
       BEHAVIOUR notificationBISerrorsubcode-B
        BEHAVIOUR DEFINED AS The error code indicating what type of error
        within the major error type occurred in the BIS PDU.;;
       REGISTERED AS { IDRP.proi notificationBISerrorsubcode(3) };

      notificationBISPDUerrorinfo PARAMETER

       CONTEXT EVENT-INFO;
       WITH SYNTAX  IDRP.BispduErrorInfo;
       BEHAVIOUR notificationBISPDUerrorinfo-B
        BEHAVIOUR DEFINED AS The additional information from original PDU
        that indicated an error in the BIS PDU.;;
       REGISTERED AS { IDRP.proi notificationBISPDUerrorinfo(4) };

      notificationRemoteRDCConfig PARAMETER

       CONTEXT EVENT-INFO;
       WITH SYNTAX  IDRP.RemoteRDCConfig;
       BEHAVIOUR notificationRemoteRDCConfig-B
        BEHAVIOUR DEFINED AS The Routing Domain Confederation (RDC)
        information from the remote BIS on this BIS to BIS communication.;;
       REGISTERED AS { IDRP.proi notificationRemoteRDCConfig(5) };

      notificationLocalRDCConfig PARAMETER

       CONTEXT EVENT-INFO;
       WITH SYNTAX  IDRP.LocalRDCConfig;
       BEHAVIOUR notificationLocalRDCConfig-B
        BEHAVIOUR DEFINED AS The Routing Domain Confederation (RDC)
        information from this local BIS on this BIS to BIS communcation.;;
       REGISTERED AS { IDRP.proi notificationLocalRDCConfig(6) };

      notificationRIBIntegrityFailure PARAMETER

   Kunzinger                     ISO/IEC 10747                 [ Page 186 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       CONTEXT EVENT-INFO;
       WITH SYNTAX  IDRP.RIBIntegrityFailure;
       BEHAVIOUR notificationRIBIntegrityFailure-B
        BEHAVIOUR DEFINED AS The maximum number of integrity checks
        detected before reporting the event to systems management;;
       REGISTERED AS { IDRP.proi notificationRIBIntegrityFailure(7) };

      notificationSourceBISNET PARAMETER

       CONTEXT EVENT-INFO;
       WITH SYNTAX  IDRP.NetworkEntityTitle;
       BEHAVIOUR notificationSourceBISNET-B
        BEHAVIOUR DEFINED AS NET of the remote BIS that sent a packet bomb
        to the local BIS;;
       REGISTERED AS { IDRP.proi notificationSourceBISNET(8) };

      notificationSourceBISrdi PARAMETER

       CONTEXT EVENT-INFO;
       WITH SYNTAX  IDRP.Rdi;
       BEHAVIOUR notificationSourceBISRdi-B
        BEHAVIOUR DEFINED AS RDI of the remote BIS that sent a packet bomb
        to the local BIS;;
       REGISTERED AS { IDRP.proi notificationSourceBISrdi(9) };

      notificationSourceBISrdc PARAMETER

       CONTEXT EVENT-INFO;
       WITH SYNTAX  IDRP.Rdi;
       BEHAVIOUR notificationSourceBISrdc-B
        BEHAVIOUR DEFINED AS RDC of the remote BIS that sent a packet bomb
        to the local BIS;;
       REGISTERED AS { IDRP.proi notificationSourceBISrdc(10) };

   11.6  Behaviour

      supplyOnCreate-B BEHAVIOUR

       DEFINED AS Value is supplied by the protocol machine when the MO is
       created, or supplied via CREATE operation.  The value can not be
       changed thereafter;


   Kunzinger                     ISO/IEC 10747                 [ Page 187 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   11.7  ASN.1 modules

      IDRP{joint-iso-ccitt network-layer(13)
        management(0) iDRP(3) asn1Module(2) 0}

      DEFINITIONS::=BEGIN
        -- object identifier definitions

       idrpoi OBJECT IDENTIFIER ::= {NLM.nl iDRP(3)}
       sseoi OBJECT IDENTIFIER ::=
        {idrpoi standSpecificExtensions(0)}
       moi OBJECT IDENTIFIER ::=
        {idrpoi objectClass (3)}
       poi OBJECT IDENTIFIER ::=
        {idrpoi package (4)}
       proi OBJECT IDENTIFIER ::=
        {idrpoi parameter(5)}
       nboi OBJECT IDENTIFIER ::=
        {idrpoi nameBinding (6)}
       atoi OBJECT IDENTIFIER ::=
        {idrpoi attribute (7)}
       agoi OBJECT IDENTIFIER ::=
        {idrpoi attributeGroup (8)}
       acoi OBJECT IDENTIFIER ::=
        {idrpoi action (9)}
       noi OBJECT IDENTIFIER ::=
        {idrpoi notification (10)}

          --
          --object identifiers for notification parameters
          --

       se OBJECT IDENTIFIER ::=
        {sseoi specificProblems(3)}
       errorBISPDUsent OBJECT IDENTIFIER ::=
        {se errorBISPDU0(0)}
       openBISpduRDCerror OBJECT IDENTIFIER ::=
        {se errorBISPDU1(1)}
       errorBISPDUconnectionclose OBJECT IDENTIFIER ::= {se
       errorBISPDU2(2)}
       corruptAdjRIBIn OBJECT IDENTIFIER ::=
        {se errorBISPDU3(3)}
       packetBomb OBJECT IDENTIFIER ::=
        {se errorBISPDU4(4)}
       enterFSMstate OBJECT IDENTIFIER ::=

   Kunzinger                     ISO/IEC 10747                 [ Page 188 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        {se errorBISPDU5(5)}
       fSMStateChange OBJECT IDENTIFIER ::=
        {se errorBISPDU6(6)}

          --
          --ASN1 Types and Values
          --

       AuthenticationCode ::=ENUMERATED{
        integrityOnly(0),
        integrityPlusAuthentication(1)
        integrityPlusSecretText(2)}
       Authtype ::=AuthenticationCode
       BISGroup ::= SET OF NetworkEntityTitle
       BisNet ::= NetworkEntityTitle
       BisNegotiatedVersion ::=Version
       BispduErrorCode::= ENUMERATED {
        oPENPDUerror (1),
        uPDATEPDUError (2),
        holdtimerExpired (3)}
       BispduErrorSubcode ::= CHOICE {
        operr [] IMPLICIT Openerrorsubcode,
        uperr [1] IMPLICIT Updateerrorsubcode}
       BispduErrorInfo ::=OCTET STRING(SIZE(1..50))
            --50 bytes of original message are saved
       BisPeersSNPAs ::= SNPAaddresses
       Boolean ::= BOOLEAN
       Capacity ::=INTEGER(1..255)
       EndSystemNSAP ::= OCTET STRING(SIZE(1..20))
       ESPrefix ::= NSAPprefix
       Expensevalue ::=Locexpense
       GLOBAL ::= ENUMERATED {
        delay(0),
        expense(1),
        capacity(3),
        error(4) }
       Holdtime ::=INTEGER(1..65535)
       Integer ::=INTEGER
       KeepaliveSincelastupdupdate ::=
        INTEGER(1..4294967295)
       Lastseqnosent ::=INTEGER(1..4294967295)
       Lastseqnorecv ::=INTEGER(1..4294967295)
       Lastacksent ::=INTEGER(1..4294967295)
       Lastackrecv ::=INTEGER(1..4294967295)
       LocExpense ::= INTEGER(1..65535)

   Kunzinger                     ISO/IEC 10747                 [ Page 189 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       LocalRDCConfig ::=Rdcgroup
       LocalSNPAs ::= SNPAaddresses
       MaxPDUSize ::=INTEGER(1..65535)
       MaxRIBIntegrityCheck ::=INTEGER(1..65535)
       Metriclength ::=INTEGER(1..255)
       Metricvalue ::=OCTET STRING(SIZE(1..255))
       MinRouteAdvertisementInterval ::=INTEGER(1..65535)
       NSAPprefixLength ::=INTEGER(1..160)
       NSAPprefix ::= BIT STRING(SIZE(1..160))
       NetworkEntityTitle ::=OCTET STRING(SIZE(1..20))
       NETPrefix ::= NSAPprefix
       NotificationInfo ::=SET OF Parameter
       nullRDC Rdcgroup ::= {}--empty set
       nullRDI Rdi ::= OCTET STRING(SIZE(0))
       Openerrorsubcode ::=ENUMERATED {
        unsupportedVersionnumber (1),
        badMaxPDUsize (2),
        badOutstandingPDUs (3),
        badPeerRD (4),
        unsupportedAuthenticationcode (5),
        authenticationFailure (6),
        badRIB-AttrsSet (7),
        rDCmismatch (8)}
       OutstandingPdus ::=INTEGER(0..255)
       Parameter ::= SEQUENCE {
        paramID OBJECT IDENTIFIER,
        paramInfo ANY DEFINED BY paramID}
       Priority ::= INTEGER(0..14)
       QOS ::= CHOICE { global[0] EXPLICIT GLOBAL,
        ssQOS[1] EXPLICIT QOSTV,
        dsQOS[2] EXPLICIT QOSTV }
       QOSlength ::= INTEGER(1..255)
       QOSTV ::= SEQUENCE { preflgth NSAPrefixLength,
        prefix NSAPpreifx,
        qOSlgth QOSlength,
        qOSval QOSvalue }
       QOSvalue ::= OCTET STRING(SIZE(1..255))
       Rdi ::=OCTET STRING(SIZE(0..20))
        --assigned from the NSAP address space
       Rdcgroup::= SET OF Rdi
       RdcNest ::=SET OF RdcHierarchy
        --each nested path from top to bottom is
        --identified by the confederation at the top.
        --Because of overlapping confederations, a
        --given top level confederation may appear

   Kunzinger                     ISO/IEC 10747                 [ Page 190 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        --in several 'RdcHierarchy' elements
       RdcHierarchy ::= SEQUENCE {
        confed Rdcsetid,
        ConfedID Rdi, --RDI of top level RDC
        SubordinateRDCs SEQUENCE OF Rdi}
        --order of RDIs specifies a single
        --nesting relationships between the top
        --level RDC and a bottom level RDC
        --RDC in which the local routeing
        --domain is situated.
       Rdcsetid ::=INTEGER(1..255)
       RDTransitDelay ::=INTEGER(0..65535)
       Rdlre ::=INTEGER(0..4294967295)
       RetransmissionTime ::= INTEGER(0..65535)
       RemoteBISNET ::=NetworkEntityTitle
       RemoteRDCConfig ::=Rdcgroup
       RemoteBISNetActionReply ::=SEQUENCE{
        responseCode OBJECT IDENTIFIER,
        responseArgs SET OF Parameter OPTIONAL}
       RibAttsSet ::= SEQUENCE  { confed Ribsetid,
        count Ribsetcount,
        attribs SET OF Ribattributes}
       RIBIntegrityFailure ::=INTEGER(1..65535)
       Ribsetid ::=INTEGER(1..255)
       Ribsetcount ::=INTEGER(0..255)
       Ribattributes ::= SEQUENCE {
        priority [0] EXPLICIT Priority OPTIONAL,
        security [1] EXPLICIT SEC OPTIONAL,
        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 {
        transitdelayvalue [0] IMPLICIT INTEGER,
        residualerrorvalue [1] IMPLICIT INTEGER,
        expensevalue [2] IMPLICIT INTEGER,
        locDefQOS [3]IMPLICIT INTEGER,
        security [6] IMPLICIT INTEGER,

   Kunzinger                     ISO/IEC 10747                 [ Page 191 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        priorityvalue [8] IMPLICIT INTEGER}
       Ribattqos ::= SEQUENCE {
        preflgth NSAPprefixLength,
        prefix NSAPprefix,
        qOSlgth QOSlength,
        qOSval QOSvalue,
        metriclgth Metriclength,
        metricval Metricvalue}
       Ribattsec ::= SEQUENCE {
        preflgth NSAPprefixLength,
        prefix NSAPprefix,
        seclgth Securitylength,
        secval Securitylevel}
       RouteAdvertisementInterval ::=INTEGER(30..900)
        --IS 10589 imposes minimum value of 30 seconds
        --and maximum value of 900 seconds in clause
        --12.2.4.3, part e)
       SEC ::= SEQUENCE { secIDLgth SecurityLength,
        secID Securitylevel,
        secInfoLgth SecurityLength,
        secInfo SecurityInfo }
       SecurityInfo ::= OCTET STRING(SIZE(1..255))
       Securitylength ::= INTEGER(0..255)
       Securitylevel ::= OCTET STRING(SIZE(1..255))
       SNPAaddress ::= OCTET STRING (FROM
        ('1'H|'2'H|'3'H|'4'H|'5'H|'6'H|'7'H|'8'H|'9'H|
        'A'H|'B'H|'C'H|'D'H|'E'H|'F'H))
             --integral number of hexadecimal digits
       SNPAaddresses ::= SET OF SNPAaddress
       State ::= ENUMERATED {
        closed (0),
        open-recv(1),
        established(2),
        open-sent(3),
        close-wait(4)}
       StopEventreply ::= Parameter
       StartEventreply::=Parameter
       SystemIdGroup ::= SEQUENCE  { nETS SET OF NETprefix, nSAPs SET OF
       ESprefix }
       Updateerrorsubcode ::=ENUMERATED {
        malformedAttributelist (1),
        unrecognizedWell-knownAttribute (2),
        missingWell-knownAttribute (3),
        attributeFlagsError (4),
        attributeLengthError (5),

   Kunzinger                     ISO/IEC 10747                 [ Page 192 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        rDRouteingLoop (6),
        invalidNEXTHOPAttribute (7),
        optionalAttributeerror (8),
        invalidReachabilityInformation (9),
        misconfiguredRDCs (10)}
       Version ::=INTEGER (1..255)
       zero INTEGER ::= 0

      END


   12.  Conformance


      A Protocol Implementation Conformance Statement (PICS) shall be
      completed with respect to any claim for conformance of an
      implementation to this International Standard.  The PICS shall be
      produced in accordance with the relevant PICS-proforma in Annex A.

      Note 38:  Since it is only Boundary ISs that implement the elements
                of procedure of this International Standard, this clause
                does not address deployment guidelines or addressing
                guidelines for systems in general.  Since distribution of
                policies is outside the scope of this International
                Standard, this topic also is not addressed in the following
                conformance clauses.

   12.1  Static conformance for all BISs

      Each IS claiming conformance to this International Standard shall be
      capable of each of the following:

      a)  generating and parsing BISPDUs with the following structure and
          formats described in: 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, and 6.7

      b)  transmitting  and receiving NSAP prefixes that have been encoded
          as single values according to 7.1.2.1


   Kunzinger                     ISO/IEC 10747                 [ Page 193 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      c)  generating, recognizing upon receipt, and updating each of the
          following path attributes as described in the indicated
          subclauses:

          -   ROUTE_SEPARATOR in 6.3.1.1, 7.12.1
          -   RD_PATH in 6.3.1.3, 7.12.3
          -   RD_HOP_COUNT in 6.3.1.13, 7.12.4
          -   CAPACITY in 6.3.1.15, 7.12.15

      d)  recognizing upon receipt each of the following well-known
          discretionary path attributes that are contained in any incoming
          UPDATE PDU, as described in the indicated subclauses:

          -   EXT_INFO in 6.3.1.2, 7.12.2
          -   NEXT_HOP in 6.3.1.4, 7.12.4
          -   DIST_LIST_INCL in 6.3.1.5, 7.12.5
          -   DIST_LIST_EXCL in 6.3.1.6, 7.12.6
          -   TRANSIT DELAY in 6.3.1.8, 7.12.8
          -   RESIDUAL ERROR in 6.3.1.9, 7.12.9
          -   EXPENSE in 6.3.1.10, 7.12.10
          -   LOCALLY DEFINED QOS in 6.3.1.11, 7.12.11
          -   HIERARCHICAL RECORDING in 6.3.1.12, 7.12.12
          -   SECURITY in 6.3.1.14, 7.12.14
          -   CAPACITY in 6.3.1.15, 7.12.15
          -   PRIORITY in 6.3.1.16, 7.12.16

      e)  utilizing domain configuration information in the format
          described in 7.3

      f)  providing reliable delivery of BISPDUs using sequence numbering
          and flow control as described in 7.7.4 and 7.7.5.

      g)  establishing, closing, and maintaining BIS-BIS connections in
          accordance with the procedures of 7.6

      h)  responding to error conditions in BISPDUs according to 7.20

      i)  negotiating the protocol version number according to 7.8

      j)  operating in a "fail-stop" manner in regard to corrupted routeing
          information, according to 7.10.2

      k)  maintaining RIBs as described in 7.10.

      l)  handling incoming BISPDUs as described in 7.14.

   Kunzinger                     ISO/IEC 10747                 [ Page 194 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      m)  detecting inconsistent routeing information in accordance with
          7.15.1.

      n)  receiving and recognizing information which has been reduced in
          size according to the methods of 7.18.1.

      o)  distributing network reachability information within a routeing
          domain according to 7.17.1.

      p)  distributing network reachability information outside a routeing
          domain according to 7.17.2.

      q)  selecting routes according to 7.16

      r)  forwarding ISO 8473 NPDUs according to clause 8.

      s)  supporting the interface to ISO 8473 using the service primitives
          according to clause 9.

      t)  providing the managed objects described in 11.

   12.2  Conformance to optional functions

   12.2.1  Generation of information in reduced form

      A BIS that claims to support generation of information in a reduced
      form shall be capable of producing information in accordance with the
      reduction techniques of 7.18.1 and 7.18.2.

   12.2.2  Generation of well-known discretionary attributes

      A BIS that claims to support generation of any of the following
      well-known discretionary attributes shall do so in accordance with
      the indicated subclauses:

      -   ROUTE_SEPARATOR in 6.3.1.1, 7.12.1
      -   EXT_INFO in 6.3.1.2, 7.12.2
      -   NEXT_HOP in 6.3.1.4, 7.12.4
      -   DIST_LIST_INCL in 6.3.1.5, 7.12.5
      -   DIST_LIST_EXCL in 6.3.1.6, 7.12.6
      -   TRANSIT DELAY in 6.3.1.8, 7.12.8

   Kunzinger                     ISO/IEC 10747                 [ Page 195 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      -   RESIDUAL ERROR in 6.3.1.9, 7.12.9
      -   EXPENSE in 6.3.1.10, 7.12.10
      -   LOCALLY DEFINED QOS in 6.3.1.11, 7.12.11
      -   HIERARCHICAL RECORDING in 6.3.1.12, 7.12.12
      -   SECURITY in 6.3.1.14, 7.12.14
      -   CAPACITY in 6.3.1.15, 7.12.15
      -   PRIORITY in 6.3.1.16, 7.12.16

   12.2.3  Propagation of well-known discretionary attributes

      A BIS that claims to support updating and propagation of any of the
      following well-known discretionary attributes after having received
      them in an UPDATE PDU shall do so in accordance with the indicated
      subclauses:

      -   ROUTE_SEPARATOR in 6.3.1.1, 7.12.1
      -   EXT_INFO in 6.3.1.2, 7.12.2
      -   NEXT_HOP in 6.3.1.4, 7.12.4
      -   DIST_LIST_INCL in 6.3.1.5, 7.12.5
      -   DIST_LIST_EXCL in 6.3.1.6, 7.12.6
      -   TRANSIT DELAY in 6.3.1.8, 7.12.8
      -   RESIDUAL ERROR in 6.3.1.9, 7.12.9
      -   EXPENSE in 6.3.1.10, 7.12.10
      -   LOCALLY DEFINED QOS in 6.3.1.11, 7.12.11
      -   HIERARCHICAL RECORDING in 6.3.1.12, 7.12.12
      -   SECURITY in 6.3.1.14, 7.12.14
      -   CAPACITY in 6.3.1.15, 7.12.15
      -   PRIORITY in 6.3.1.16, 7.12.16

   12.2.4  Peer entity authentication

      A BIS that claims to support peer entity authentication shall do so
      in accordance with 7.7.2.




   Kunzinger                     ISO/IEC 10747                 [ Page 196 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Annex A.  PICS proforma


                                 (normative)

   A.1  Introduction

      The supplier of a protocol implementation which is claimed to conform
      to International Standard XXX shall complete the applicable Protocol
      Implementation Conformance Statement (PICS) proforma.

      A completed PICS proforma is the PICS for the implementation in
      question.  The PICS is a statement of which capabilities and options
      of the protocol have been implemented.  The PICS can have a number of
      uses, including use:

      -   by the protocol implementer, as a check list to reduce the risk
          of failure to conform to the standard through oversight;

      -   by the supplier and acquirer--or potential acquirer-- of the
          implementation, as a detailed indication of the capabilities of
          the implementation, stated relative to the common basis of
          understanding provided by the standard PICS proforma;

      -   by the user--or potential user-- the implementation, as a basis
          for initially checking the possibility of interworking unit
          another implementation (note that, while interworking can never
          be guaranteed, failure to interwork can often be predicted from
          incompatible PICSs);

      -   by a protocol tester, as the basis for selecting appropriate
          tests against which to assess the claim for conformance of the
          implementation.



   Kunzinger                     ISO/IEC 10747                 [ Page 197 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   A.2  Abbreviations and special symbols

   A.2.1  Status symbols

      The following status symbols are used in the PICS:

      Symbol    Meaning

      M         mandatory

      O         optional

      O.<n>     optional, but support of at least one of the group of
                options labelled by the same numeral <n> is required

      X         prohibited

      c.<cid>   conditional requirement, according to the condition
                identified by <cid>

      <item>    simple-predicate condition, dependent on the support marked
                for       <item

      --        not applicable (N/A)

   A.3  Instructions for completing the PICS proforma

   A.3.1  General structure of the PICS proforma

      The first part of the PICS proforma--Implementation Identification
      and Protocol Summary--is to be completed as indicated with the
      information necessary to identify fully both the supplier and the
      implementation.

      The main part of the PICS proforma is a fixed-format questionnaire
      divided into subclauses, each containing a group of individual items.
      Answers to the questionnaire items are to be provided in the
      rightmost column, either by simply marking an answer to indicate a
      restricted choice (usually Yes or No), or by entering a value or a
      set or range of values.  (Note that there are some items where two or

   Kunzinger                     ISO/IEC 10747                 [ Page 198 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      more choices from a set of possible answers can apply: all relevant
      choices are to be marked.)

      Each item is identified by an item reference in the first column; the
      second column contains the question to be answered; the third column
      contains the reference or references to the material that specifies
      the item in the main body of the standard; the remaining columns
      record the status of the item--whether support is mandatory,
      optional, or conditional--and provide space for the answers: see also
      A.3.4 below.

      A supplier may also provide--or be required to provide--further
      information, categorized as either Additional Information or
      Exception Information.  When present, each kind of further
      information is to be provided in a further subclause of items
      labelled A<i> or X<i>, respectively, for cross-referencing purposes,
      where <i> is any unambiguous identification for the item (e.g.,
      simply a numeral): there are no other restrictions on its format and
      presentation.

      A completed PICS proforma, including any Additional Information and
      Exception Information, is the Protocol Implementation Conformance
      Statement for the implementation in question.

      Note 39:  Where an implementation is capable of being configured in
                more than one way, a single PICS may be able to describe
                all such configurations.  However, the supplier has the
                choice of providing more than one PICS, each covering some
                subset of the implementation's configuration capabilities,
                in case that makes for easier and clearer presentation of
                the information.

   A.3.2  Additional information

      Items of Additional Information allow a supplier to provide further
      information intended to assist the interpretation of the PICS.  It is
      not intended or expected that a large quantity will be supplied, and
      a PICS can be considered complete without any such information.
      Examples might be an outline of the ways in which a (single)
      implementation can be set up to operate in a variety of environments
      and configurations, or a brief rationale--based perhaps upon specific
      application needs--for the exclusion of features which, although
      optional, are nonetheless commonly present in implementations of the
      protocol.

   Kunzinger                     ISO/IEC 10747                 [ Page 199 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      References to items of Additional Information may be entered next to
      any answer in the questionnaire, and may be included in items of
      Exception Information.

   A.3.3  Exception information

      It may occasionally happen that a supplier will wish to answer an
      item with mandatory or prohibited status (after any conditions have
      been applied) in a way that conflicts with the indicated requirement.
      No pre-printed answer will be found in the Support column for this:
      instead, the supplier is required to write into the Support column an
      X<i> reference to an item of Exception Information, and to provide
      the appropriate rationale in the Exception item itself.

      An implementation for which an Exception item is required in this way
      does not conform to ISO/IEC XXX.

      Note 40:  A possible reason for the situation described above is that
                a defect in the standard has been reported, a correction
                for which is expected to change the requirement not met by
                the implementation.

   A.3.4  Conditional status

   A.3.4.1  Conditional items

      The PICS proforma contains a number of conditional items.  These are
      items for which the status that applies--mandatory, optional, or
      prohibited--is dependent upon whether or not certain other items are
      supported, or upon the values supported for other items.

      In many cases, whether or not the item applies at all is conditional
      in this way, as well as the status when the item does apply.

      Individual conditional items are indicated by a conditional symbol in
      the Status column as described in A.3.4.2 and A.3.4.3 below.  Where a
      group of items is subject to the same condition for applicability, a
      separate preliminary question about the condition appears at the head
      of the group, with an instruction to skip to a later point in the
      questionnaire if the "Not Applicable" answer is selected.

   Kunzinger                     ISO/IEC 10747                 [ Page 200 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   A.3.4.2  Conditional symbols and conditions

      A conditional symbol is either of the form C.<n> or C.G<n>, where <n>
      is a numeral or is an abbreviated condition of the form described in
      A.3.4.3 below.  For the C.<n> form, the numeral identifies a
      condition appearing in a list as the end of the subclause containing
      the item.  For the C.G<n> form, the numeral identifies a condition
      appearing in a list of global conditions.

      A simple condition is of the form

        if <p1> then <s1> else <s2>

      where <p1> is a predicate (see A.3.4.4 below) and <s1> and <s2> are
      either basic status symbols (M, O, O.<n>, or X) or the symbol "--".

      An extended condition is of the form

        if <p1> then <s1>
        else if <p2> then <s2>
        [else if ...]
        else <sn>

      where the quantities <px> are predicates, and the quantities <sx> are
      either basic status symbols or "--".

      The symbol (either a basic status symbol or "--") applicable to an
      item governed by a simple condition is <s1> if the predicate of the
      condition is true, and is <s2> otherwise.  The symbol applicable to
      an item governed by an extended condition is <si> where <pi> is the
      first true predicate, if any, in the sequence <p1>, <p2>,...; and it
      is <sn> if no predicate is true.

   A.3.4.3  Abbreviated conditions

      The abbreviated condition <item>:<s> in the status column is
      equivalent to a conditional symbol with corresponding condition if
      <item> then <s> else "--".



   Kunzinger                     ISO/IEC 10747                 [ Page 201 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   A.3.4.4  Predicates

      A simple predicate in a condition is either:

      a)  a single item reference; or

      b)  a relation containing a comparison operator (=,<,etc.) with one
          (or both) of its operands being an item reference for an item
          taking numerical values as its answer.  In case (a), the
          predicate is true if the item referred to is marked as supported,
          and false otherwise.  In case (b), the predicate is true if the
          relation holds when each item reference is replaced by the value
          entered in the Support column as the answer to the item referred
          to.

      Compound predicates are boolean expressions constructed by combining
      simple predicates using the boolean operators AND, OR, and NOT, and
      parentheses, in the usual way.  A compound predicate is true if and
      only if the boolean expression evaluates to "true" when the simple
      predicates are interpreted as described above.

      Items whose references are used in predicates are indicated by an
      asterisk in the Item column.

   A.3.4.5  Answering conditional items

      To answer a conditional item, the predicate(s) of the condition is
      (are) evaluated as described in A.3.4.4 above, and the applicable
      symbol is determined as described in A.3.4.2.  If the result is
      "N/A", the Not Applicable answer column is to be marked; otherwise,
      the Support column is to be completed in the usual way.

      When two or more status symbols appear in the condition for an item,
      the Support column for the item contains one line for each such
      symbol, labelled by the relevant method.  The answer for the item is
      to be marked in the line labelled by the symbol selected according to
      the condition (unselected lines may be crossed out for added
      clarity).

      For example, in the illustration below, the N/A column would be
      marked if neither predicate of C.2 was true; the answer line labelled
      "M:" would be marked if item A4 was marked as supported; and the
      answer line labelled "O:" would be marked if item A4 was not marked
      as supported but item D1 was supported.

   Kunzinger                     ISO/IEC 10747                 [ Page 202 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   | +---------+---------------+---------+----------+----+--------------+ |
   | | Item    | Questions/Feat|rReferenc|sStatus   | N/A| Support      | |
   | +---------+---------------+---------+----------+----+--------------+ |
   | | H3      | Is ...        | 42.3(d) | C.2      | __ | M: Yes__     | |
   | |         | supported?    |         |          |    | O: Yes__     | |
   | |         |               |         |          |    | No__         | |
   | +---------+---------------+---------+----------+----+--------------+ |
   |                                                                      |
   |                                                                      |
   |   C.2: If A4 then M else if D1 or (B52>2) then O else N/A            |
   |                                                                      |
   +----------------------------------------------------------------------+

   A.4  Identification

   A.4.1  PICS proforma: IDRP implementation identification

   +-----------------------------------------------+----------------------+
   | Supplier                                      |                      |
   +-----------------------------------------------+----------------------+
   | Contact point for queries about this PICS     |                      |
   +-----------------------------------------------+----------------------+
   | Implementation Name(s) and Version(s)         |                      |
   +-----------------------------------------------+----------------------+
   | Other information necessary for full          |                      |
   | identification  (e.g., Name's and Version(s)  |                      |
   | for machines and operating systems, System    |                      |
   | Name(s))                                      |                      |
   +-----------------------------------------------+----------------------+

   Note 41:  Only the first three items are required for all
             implementations; other information may be completed as
             appropriate in meeting the requirement for full
             identification.  The terms Name and Version should be
             interpreted appropriately to correspond with a supplier's
             terminology (using, e.g., Type,Series, MODEL).


   Kunzinger                     ISO/IEC 10747                 [ Page 203 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   A.4.2  PICS proforma: IDRP protocol summary

   +-----------------------------------------------+----------------------+
   | Protocol Version                              |                      |
   +-----------------------------------------------+----------------------+
   | Addenda Implemented (if applicable)           |                      |
   +-----------------------------------------------+----------------------+
   | Amendments Implemented                        |                      |
   +-----------------------------------------------+----------------------+
   | Have any Exception items been required? (See  | Yes__ No__           |
   | A.3.3.)                                       |                      |
   |                                               | Note:  The answer    |
   |                                               |        Yes means     |
   |                                               |        that the      |
   |                                               |        implementation|
   |                                               |        does not      |
   |                                               |        conform to    |
   |                                               |        this          |
   |                                               |        International |
   |                                               |        Standard.)    |
   +-----------------------------------------------+----------------------+

   A.4.3  PICS proforma: IDRP general

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | BASIC   | Are all basic BIS     | 12.1        | M       | Yes__      |
   |         | functions             |             |         |            |
   |         | implemented?          |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | MGT     | Is this system        | 11          | M       | Yes__      |
   |         | capable of being      |             |         |            |
   |         | managed by the        |             |         |            |
   |         | specified management  |             |         |            |
   |         | information?          |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | VER     | Does this BIS support | 7.8         | M       | Yes__      |
   |         | version negotiation?  |             |         |            |
   +---------+-----------------------+-------------+---------+------------+


   Kunzinger                     ISO/IEC 10747                 [ Page 204 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | RTSEP   | Does this BIS support | 6.3.1.1,    | M       | Yes__      |
   |         | the ROUTE_SEPARATOR   | 7.12.1      |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | HOPS    | Does this BIS support | 6.3.1.13,   | M       | Yes__      |
   |         | the RD_HOP_COUNT      | 7.12.13     |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | PATH    | Does this BIS support | 6.3.1.3,    | M       | Yes__      |
   |         | the RD_PATH           | 7.12.3      |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | CAPY    | Does this BIS support | 6.3.1.15,   | M       | Yes__      |
   |         | the CAPACITY          | 7.12.15     |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | FSM     | Does this BIS manage  | 7.6.1       | M       | Yes__      |
   |         | BIS-BIS connections   |             |         |            |
   |         | according to the BIS  |             |         |            |
   |         | FSM description?      |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | FCTL    | Does this BIS provide | 7.7.5       | M       | Yes__      |
   |         | flow control?         |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | SEQNO   | Does this BIS provide | 7.7.4       | M       | Yes__      |
   |         | sequence number       |             |         |            |
   |         | support?              |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | INTG1   | Does this BIS provide | 7.7.1       | O.1     | Yes__ No__ |
   |         | data integrity using  |             |         |            |
   |         | authentication type   |             |         |            |
   |         | 1?                    |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | INTG2   | Does this BIS provide | 7.7.2       | O.1     | Yes__ No__ |
   |         | data integrity using  |             |         |            |
   |         | authentication type   |             |         |            |
   |         | 2?                    |             |         |            |
   +---------+-----------------------+-------------+---------+------------+


   Kunzinger                     ISO/IEC 10747                 [ Page 205 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | INTG3   | Does this BIS provide | 7.7.3       | O.1     | Yes__ No__ |
   |         | data integrity using  |             |         |            |
   |         | authentication type   |             |         |            |
   |         | 3?                    |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | ERROR   | Does this BIS handle  | 7.20        | M       | Yes__      |
   |         | error handling for    |             |         |            |
   |         | IDRP?                 |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | RIBCHK  | Does this BIS operate | 7.10.2      | M       | Yes__      |
   |         | in a "fail-stop"      |             |         |            |
   |         | manner with respect   |             |         |            |
   |         | to corrupted routeing |             |         |            |
   |         | information?          |             |         |            |
   +---------+-----------------------+-------------+---------+------------+










   Kunzinger                     ISO/IEC 10747                 [ Page 206 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   A.4.4  PICS proforma: IDRP update send process

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | INT     | Does this BIS provide | 7.17.1      | M       | Yes__      |
   |         | the internal update   |             |         |            |
   |         | procedures?           |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | RTSEL   | Does this BIS support | 7.17.3.1    | M       | Yes__      |
   |         | the                   |             |         |            |
   |         | MinRouteSelectionInter|al           |         |            |
   |         | timer?                |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | RTORG   | Does this BIS support | 7.17.3.2    | M       | Yes__      |
   |         | the                   |             |         |            |
   |         | MinRDOriginationInterv|l            |         |            |
   |         | timer?                |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | JITTER  | Does this BIS provide | 7.17.3.3    | M       | Yes__      |
   |         | jitter on its timers? |             |         |            |
   +---------+-----------------------+-------------+---------+------------+

   A.4.5  PICS proforma: IDRP update receive process

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | INPDU   | Does the BIS handle   | 7.14        | M       | Yes__      |
   |         | inbound BISPDUs       |             |         |            |
   |         | correctly?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | INCONS  | Does this BIS detect  | 7.15.1      | M       | Yes__      |
   |         | inconsistent routeing |             |         |            |
   |         | information?          |             |         |            |
   +---------+-----------------------+-------------+---------+------------+

   A.4.6  PICS proforma: IDRP decision process



   Kunzinger                     ISO/IEC 10747                 [ Page 207 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | TIES    | Does the BIS break    | 7.16.2.1    | M       | Yes__      |
   |         | ties between          |             |         |            |
   |         | candidate routes      |             |         |            |
   |         | correctly?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | RIBUPD  | Does this BIS update  | 7.16.2      | M       | Yes__      |
   |         | the correct Loc-RIBs? |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | AGGRT   | Does this BIS support | 7.18.2.1,   | O       | Yes__ No__ |
   |         | route aggregation?    | 7.18.2.2,   |         |            |
   |         |                       | 7.18.2.3    |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | LOCK    | Does this BIS provide | 7.16.4      | M       | Yes__      |
   |         | interlocks between    |             |         |            |
   |         | its decision process  |             |         |            |
   |         | and the updating of   |             |         |            |
   |         | the information in    |             |         |            |
   |         | its Adj-RIBs-In?      |             |         |            |
   +---------+-----------------------+-------------+---------+------------+

   A.4.7  PICS proforma: IDRP receive process

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | RCV     | Does the BIS process  | 7.14, 7.20  | M       | Yes__      |
   |         | incoming BISPDUs and  |             |         |            |
   |         | respond correctly to  |             |         |            |
   |         | error conditions?     |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | OSIZE   | Does the BIS accept   | 6.2, 7.20   | M       | Yes__      |
   |         | incoming OPEN PDUs    |             |         |            |
   |         | whose size in octets  |             |         |            |
   |         | is between            |             |         |            |
   |         | minBISPDULength and   |             |         |            |
   |         | 3000?                 |             |         |            |
   +---------+-----------------------+-------------+---------+------------+


   Kunzinger                     ISO/IEC 10747                 [ Page 208 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | MXPDU   | Does the BIS accept   | 6.2, 7.20   | M       | Yes__      |
   |         | incoming UPDATE, IDRP |             |         |            |
   |         | ERROR and RIB REFRESH |             |         |            |
   |         | PDUs whose size in    |             |         |            |
   |         | octets is between     |             |         |            |
   |         | minBISPDULength and   |             |         |            |
   |         | maxBISPDULength?      |             |         |            |
   +---------+-----------------------+-------------+---------+------------+












   Kunzinger                     ISO/IEC 10747                 [ Page 209 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   A.4.8  PICS proforma: IDRP CLNS forwarding

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | PSRCRT  | Does the BIS          | 8           | M       | Yes__      |
   |         | correctly handle 8473 |             |         |            |
   |         | NPDUs that contain a  |             |         |            |
   |         | partial source route? |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | DATTS   | Does the BIS          | 8.2         | M       | Yes__      |
   |         | correctly extract the |             |         |            |
   |         | NPDU-derived          |             |         |            |
   |         | Distinguishing        |             |         |            |
   |         | Attributes from an    |             |         |            |
   |         | 8473 NPDU?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | MATCH   | Does the BIS          | 8.3         | M       | Yes__      |
   |         | correctly match the   |             |         |            |
   |         | NPDU-derived          |             |         |            |
   |         | Distinguishing        |             |         |            |
   |         | Attributes with the   |             |         |            |
   |         | corresponding         |             |         |            |
   |         | FIB-Atts?             |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | EXTF    | Does the BIS          | 8.4         | M       | Yes__      |
   |         | correctly forward     |             |         |            |
   |         | NPDUs with            |             |         |            |
   |         | destinations outside  |             |         |            |
   |         | its own routeing      |             |         |            |
   |         | domain?               |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | INTF    | Does the BIS          | 8.1         | M       | Yes__      |
   |         | correctly forward     |             |         |            |
   |         | NPDUs with            |             |         |            |
   |         | destinations inside   |             |         |            |
   |         | its own routeing      |             |         |            |
   |         | domain?               |             |         |            |
   +---------+-----------------------+-------------+---------+------------+

   A.4.9  PICS proforma: IDRP authentication


   Kunzinger                     ISO/IEC 10747                 [ Page 210 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | AUTH    | Does the BIS          | 7.7.2       | O       | Yes__ No__ |
   |         | correctly             |             |         |            |
   |         | authenticate the      |             |         |            |
   |         | source of a BISPDU?   |             |         |            |
   +---------+-----------------------+-------------+---------+------------+

   A.4.10  PICS proforma: IDRP optional transitive attributes

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | MEXIT   | Does the BIS support  | 6.3.1.7,    | O       | Yes__ No__ |
   |         | use of the MULTI-EXIT | 7.12.7      |         |            |
   |         | DISC attribute?       |             |         |            |
   +---------+-----------------------+-------------+---------+------------+










   Kunzinger                     ISO/IEC 10747                 [ Page 211 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   A.4.11  PICS proforma: Generating IDRP well-known discretionary
   attributes

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | EXTG    | Does the BIS support  | 6.3.1.2,    | O       | Yes__ No__ |
   |         | generation of the     | 7.12.2      |         |            |
   |         | EXT_INFO attribute?   |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | NHRS    | Does the BIS support  | 6.3.1.4,    | O       | Yes__ No__ |
   |         | generation of the     | 7.12.4      |         |            |
   |         | NEXT_HOP attribute in |             |         |            |
   |         | support of route      |             |         |            |
   |         | servers?              |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | NHSN    | Does the BIS support  | 6.3.1.4,    | O       | Yes__ No__ |
   |         | generation of the     | 7.12.4      |         |            |
   |         | NEXT_HOP attribute to |             |         |            |
   |         | advertise SNPAs?      |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | DLI     | Does the BIS support  | 6.3.1.5,    | O       | Yes__ No__ |
   |         | generation of the     | 7.12.5      |         |            |
   |         | DIST_LIST_INCL        |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | DLE     | Does the BIS support  | 6.3.1.6,    | O       | Yes__ No__ |
   |         | generation of the     | 7.12.6      |         |            |
   |         | DIST_LIST_EXCL        |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | TDLY    | Does the BIS support  | 6.3.1.8,    | O       | Yes__ No__ |
   |         | generation of the     | 7.12.8      |         |            |
   |         | TRANSIT DELAY         |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | RERR    | Does the BIS support  | 6.3.1.9,    | O       | Yes__ No__ |
   |         | generation of the     | 7.12.9      |         |            |
   |         | RESIDUAL ERROR        |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+


   Kunzinger                     ISO/IEC 10747                 [ Page 212 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | EXP     | Does the BIS support  | 6.3.1.10,   | O       | Yes__ No__ |
   |         | generation of the     | 7.12.10     |         |            |
   |         | EXPENSE attribute?    |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | LQOSG   | Does the BIS support  | 6.3.1.11,   | O       | Yes__ No__ |
   |         | generation of the     | 7.12.11     |         |            |
   |         | LOCALLY DEFINED QOS   |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | HREC    | Does the BIS support  | 6.3.1.12,   | O       | Yes__ No__ |
   |         | generation of the     | 7.12.12     |         |            |
   |         | HIERARCHICAL          |             |         |            |
   |         | RECORDING attribute?  |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | SECG    | Does the BIS support  | 6.3.1.14,   | O       | Yes__ No__ |
   |         | generation of the     | 7.12.14     |         |            |
   |         | SECURITY attribute?   |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | PRTY    | Does the BIS support  | 6.3.1.16,   | O       | Yes__ No__ |
   |         | generation of the     | 7.12.16     |         |            |
   |         | PRIORITY attribute?   |             |         |            |
   +---------+-----------------------+-------------+---------+------------+








   Kunzinger                     ISO/IEC 10747                 [ Page 213 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   A.4.12  PICS proforma: Propagating IDRP well-known discretionary
   attributes

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | EXTGP   | Does the BIS support  | 6.3.1.2,    | M       | Yes__ No__ |
   |         | propagation of the    | 7.12.2      |         |            |
   |         | EXT_INFO attribute?   |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | NHRSP   | Does the BIS support  | 6.3.1.4,    | O       | Yes__ No__ |
   |         | propagation of the    | 7.12.4      |         |            |
   |         | NEXT_HOP attribute in |             |         |            |
   |         | support of route      |             |         |            |
   |         | servers?              |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | NHSNP   | Does the BIS support  | 6.3.1.4,    | O       | Yes__ No__ |
   |         | propagation of the    | 7.12.4      |         |            |
   |         | NEXT_HOP attribute to |             |         |            |
   |         | advertise SNPAs?      |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | DLIP    | Does the BIS support  | 6.3.1.5,    | O       | Yes__ No__ |
   |         | propagation of the    | 7.12.5      |         |            |
   |         | DIST_LIST_INCL        |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | DLEP    | Does the BIS support  | 6.3.1.6,    | O       | Yes__ No__ |
   |         | propagation of the    | 7.12.6      |         |            |
   |         | DIST_LIST_EXCL        |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | TDLYP   | Does the BIS support  | 6.3.1.8,    | O       | Yes__ No__ |
   |         | propagation of the    | 7.12.8      |         |            |
   |         | TRANSIT DELAY         |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | RERRP   | Does the BIS support  | 6.3.1.9,    | O       | Yes__ No__ |
   |         | propagation of the    | 7.12.9      |         |            |
   |         | RESIDUAL ERROR        |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+


   Kunzinger                     ISO/IEC 10747                 [ Page 214 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | EXPP    | Does the BIS support  | 6.3.1.10,   | O       | Yes__ No__ |
   |         | propagation of the    | 7.12.10     |         |            |
   |         | EXPENSE attribute?    |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | LQOSP   | Does the BIS support  | 6.3.1.11,   | O       | Yes__ No__ |
   |         | propagation of the    | 7.12.11     |         |            |
   |         | LOCALLY DEFINED QOS   |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | HRECP   | Does the BIS support  | 6.3.1.12,   | O       | Yes__ No__ |
   |         | propagation of the    | 7.12.12     |         |            |
   |         | HIERARCHICAL          |             |         |            |
   |         | RECORDING attribute?  |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | SECP    | Does the BIS support  | 6.3.1.14,   | O       | Yes__ No__ |
   |         | propagation of the    | 7.12.14     |         |            |
   |         | SECURITY attribute?   |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | PRTYP   | Does the BIS support  | 6.3.1.16,   | O       | Yes__ No__ |
   |         | propagation of the    | 7.12.16     |         |            |
   |         | PRIORITY attribute?   |             |         |            |
   +---------+-----------------------+-------------+---------+------------+








   Kunzinger                     ISO/IEC 10747                 [ Page 215 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   A.4.13  PICS proforma: Receiving IDRP well-known discretionary
   attributes

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | EXTR    | Does the BIS          | 6.3.1.2,    | M       | Yes__ No__ |
   |         | recognize upon        | 7.12.2      |         | X:         |
   |         | receipt the EXT_INFO  |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | NHRSR   | Does the BIS          | 6.3.1.4,    | M       | Yes__ No__ |
   |         | recognize upon        | 7.12.4      |         | X:         |
   |         | receipt the NEXT_HOP  |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | DLIR    | Does the BIS          | 6.3.1.5,    | M       | Yes__ No__ |
   |         | recognize upon        | 7.12.5      |         | X:         |
   |         | receipt the           |             |         |            |
   |         | DIST_LIST_INCL        |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | DLER    | Does the BIS          | 6.3.1.6,    | M       | Yes__ No__ |
   |         | recognize upon        | 7.12.6      |         | X:         |
   |         | receipt the           |             |         |            |
   |         | DIST_LIST_EXCL        |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | TDLYR   | Does the BIS          | 6.3.1.8,    | M       | Yes__ No__ |
   |         | recognize upon        | 7.12.8      |         | X:         |
   |         | receipt the TRANSIT   |             |         |            |
   |         | DELAY attribute?      |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | RERRR   | Does the BIS          | 6.3.1.9,    | M       | Yes__ No__ |
   |         | recognize upon        | 7.12.9      |         | X:         |
   |         | receipt the RESIDUAL  |             |         |            |
   |         | ERROR attribute?      |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | EXPR    | Does the BIS          | 6.3.1.10,   | M       | Yes__ No__ |
   |         | recognize upon        | 7.12.10     |         | X:         |
   |         | receipt the EXPENSE   |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+

   Kunzinger                     ISO/IEC 10747                 [ Page 216 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +---------+-----------------------+-------------+---------+------------+
   | Item    | Questions/Features    | References  | Status  | Support    |
   +---------+-----------------------+-------------+---------+------------+
   | LQOSR   | Does the BIS          | 6.3.1.11,   | M       | Yes__ No__ |
   |         | recognize upon        | 7.12.11     |         | X:         |
   |         | receipt the LOCALLY   |             |         |            |
   |         | DEFINED QOS           |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | HRECR   | Does the BIS          | 6.3.1.12,   | M       | Yes__ No__ |
   |         | recognize upon        | 7.12.12     |         | X:         |
   |         | receipt the           |             |         |            |
   |         | HIERARCHICAL          |             |         |            |
   |         | RECORDING attribute?  |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | SECR    | Does the BIS          | 6.3.1.14,   | M       | Yes__ No__ |
   |         | recognize upon        | 7.12.14     |         | X:         |
   |         | receipt the SECURITY  |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+
   | PRTYR   | Does the BIS          | 6.3.1.16,   | M       | Yes__ No__ |
   |         | recognize upon        | 7.12.16     |         | X:         |
   |         | receipt the PRIORITY  |             |         |            |
   |         | attribute?            |             |         |            |
   +---------+-----------------------+-------------+---------+------------+








   Kunzinger                     ISO/IEC 10747                 [ Page 217 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Annex B.  IDRP checksum generation algorithm


                                 (normative)

      This annex describes the IDRP checksum algorithm, which accepts an a
      message of arbitrary length as its input and produces a 128-bit
      digital signature as its output.  It is based upon the message digest
      algorithm described in RFC 1186.

   B.1  Mathematical notation

      In this annex, the following notation is used:

      Symbol  Meaning

      X+Y     Addition of two quantities, modulo 2^32

      X<<s    Left rotation (circular shifting) of the binary pattern X by
              "s" bit positions.

      ^X      Bitwise complement of the binary pattern X

      X xor Y Bitwise EXCLUSIVE-OR function of X and Y

      X & Y   Bitwise AND-function of X and Y

      X | Y   Bitwise OR-function of X and Y

   B.2  Algorithm description

      The input data stream, M, operated upon by this algorithm is assumed
      to be b binary digits in length.  The first (leftmost) bit of M is
      labelled m[1], the second is labelled m[2], ..., and the last
      (rightmost) bit is labelled m[b].

      The following steps shall be performed to compute the message digest
      of the message:

      a)  Append padding bits

   Kunzinger                     ISO/IEC 10747                 [ Page 218 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          From 1 to 512 padding bits shall be appended to the back of the
          original message M so that its length in bits is congruent to
          448, modulo 512.  If the original message length, b is already
          congruent to 448 modulo 512, then 512 bits of padding shall be
          added.  The first padding bit shall be 1, and all others shall be
          0.

      b)  Append the length field

          When the value of b is less than or equal to 2^64 it shall be
          expressed as a 64-bit binary integer.  If the quantity b is
          greater than 2^64, then only the low-order 64 bits of its binary
          representation shall be used.  The 64-bit long binary encoded
          quantity shall then be appended to the back of the result
          obtained in the first step.  Call this quantity Q.

      After completing these two steps, the quantity Q will have a length
      which is an exact multiple of 512 bits.  That is, Q consists of N
      32-bit words, where N is a multiple of 16.  Let Q[1] represent the
      first (leftmost) 32-bit word of Q,..., and Q [N] represent the last
      (rightmost) 32-bit word of Q.

      c)  Initialize the Checksum Buffer

          The checksum is accumulated in 4 32-bit buffers (A, B, C, and D).
          Each shall be initialized to the following values, expressed in
          hexadecimal notation:

           Word A initial value:    01 23 45 67

           Word B initial value:    89 AB CD EF

           Word C initial value:    FE DC BA 98

           Word D initial value:    76 54 32 10

      d)  Process Q in Blocks of 16 32-bit words

          Three auxiliary functions are defined that each take three 32-bit
          words as input and produce one 32-bit word as output;

           f(X,Y,Z)  =  (X & Y) | ((~X) & Z)


   Kunzinger                     ISO/IEC 10747                 [ Page 219 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

           g(X,Y,Z)  =  (X & Y) | (X & Z) | (Y & Z)

           h(X,Y,Z)  =  X xor Y xor Z

          Do the following:

           For i = 0 to N/16 do  /* process each 16-word block */
             For j = 1 to 16 do: /* copy block i into X */
                 set X[j] to M[i*16+j].
             end /* of loop on j */
             Save A as AA, B as BB, C as CC, and D as DD.

          [Round 1]:

          Let [K L M P t s] denote the operation
                 K =  (K+ f(L,M,P) + X[t]) << s  .

          Do the following 16 operations in the order indicated:
                   [A B C D 0 3]
                   [D A B C 1 7]
                   [C D A B 2 11]
                   [B C D A 3 19]
                   [A B C D 4 3]
                   [D A B C 5 7]
                   [C D A B 6 11]
                   [B C D A 7 19]
                   [A B C D 8 3]
                   [D A B C 9 7]
                   [C D A B 10 11]
                   [B C D A 11 19]
                   [A B C D 12 3]
                   [D A B C 13 7]
                   [C D A B 14 11]
                   [B C D A 15 19]

          [Round 2]:

          Now let [K L M P t s] denote the operation
                K = (K + g(L,M,P) + X[t] + 5A827999) <<s .

          (The value 5A827999 is a hexadecimal 32-bit constant.)


   Kunzinger                     ISO/IEC 10747                 [ Page 220 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          Do the following 16 operations in the order indicated:
                          [A B C D 0  3]
                          [D A B C 4  5]
                          [C D A B 8  9]
                          [B C D A 12 13]
                          [A B C D 1  3]
                          [D A B C 5  5]
                          [C D A B 9  9]
                          [B C D A 13 13]
                          [A B C D 2  3]
                          [D A B C 6  5]
                          [C D A B 10 9]
                          [B C D A 14 13]
                          [A B C D 3  3]
                          [D A B C 7  5]
                          [C D A B 11 9]
                          [B C D A 15 13]

          [Round 3]:

          Now let [K L M P t s] denote the operation
                K = (K + h(L,M,P) + X[t] + 6ED9EBA1)<<s.

          (The value 6ED9EBA1 is a hexadecimal 32-bit constant.)

          Do the following 16 operations in the order indicated:

                   [A B C D 0  3]
                   [D A B C 8  9]
                   [C D A B 4  11]
                   [B C D A 12 15]
                   [A B C D 2  3]
                   [D A B C 10 9]
                   [C D A B 6  11]
                   [B C D A 14 15]
                   [A B C D 1  3]
                   [D A B C 9  9]
                   [C D A B 5  11]
                   [B C D A 13 15]
                   [A B C D 3  3]
                   [D A B C 11 9]
                   [C D A B 7  11]
                   [B C D A 15 15]

   Kunzinger                     ISO/IEC 10747                 [ Page 221 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          Then perform the following additions:
                          A = A + AA
                          B = B + BB
                          C = C + CC
                          D = D + DD

          (That is, each register is incremented by the value it had when
          processing on this block was started.)

                    end /* of loop on i */

      e)  Output

          After completing the last loop on i, the checksum is the
          concatenation of the final values of A, B, C, and D.










   Kunzinger                     ISO/IEC 10747                 [ Page 222 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Annex C.  Bibliography


                                (informative)

      The following references contain information which is helpful in
      understanding the protocol described in this International Standard,
      and for setting the context in which it might be deployed.

      ISO/IEC 11577, Information technology - Telecommunications and
        Information Exchange between Systems - Network Layer Security
        Protocol

      RFC 1186,  The MD4 Message Digest Algorithm, R. Rivest, October 1990










   Kunzinger                     ISO/IEC 10747                 [ Page 223 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Annex D.  Example of authentication type 2


                                (informative)

   D.1  Authentication mechanism

      The procedure outlined below provides data integrity and peer BIS
      authentication in a way that satisfies the requirements of
      authentication type 2.  This is an illustrative example only.  Any
      other method that is consistent with type 2 authentication could also
      be used.

      For an OPEN PDU with an authentication code field of 2, and for all
      BISPDUs that flow on a BIS-BIS connection established by this OPEN
      PDU, the validation field will contain a 16-octet encrypted checksum:

      a)  Generating a Validation Pattern:

          The contents of the Validation Pattern field that is included in
          an outbound BISPDU can be generated by the following two step
          process, which is illustrated in Figure 10:

          1)  An unencrypted checksum that covers the contents of the
              BISPDU can be generated by applying the procedures of Annex B
              to the input data stream that consists of the contents of the
              entire BISPDU with all bits of the Validation Pattern field
              initially set to 0.  The output of this step is an
              unencrypted 16-octet long checksum, which is called chksum.

          2)  The 16-octet quantity chksum is then encrypted, and the
              encrypted pattern is placed in the Validation Pattern field
              of the BISPDU.

          Note 42:  The following observations can be made:

                    1)  The encryption algorithm must be agreed upon in the
                        cryptographic association set up by the two BISs
                        involved in the authentication process.  This
                        International Standard does not mandate use of a

   Kunzinger                     ISO/IEC 10747                 [ Page 224 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

                        specific encryption algorithm.  Explicit indication
                        of the specific algorithm to be used is outside the
                        scope of IDRP.   However, the "Authentication Data"
                        field of IDRP's OPEN PDU can be used to specify an
                        algorithm indirectly in accordance with the local
                        agreements of the two communicating BISs.

                    2)  There is no requirement that a given BIS must use
                        the same encryption algorithm on every BIS-BIS
                        connection which it has established.  The IDRP
                        authentication code carried in the OPEN PDU applies
                        only to a particular BIS-BIS connection; Thus,
                        different BIS-BIS connections may choose to use
                        different encryption algorithms.

                    3)  The presence or absence of the authentication
                        function is specified on a "per BIS-BIS connection"
                        basis.  Thus, a given BIS may support some BIS-BIS
                        connections that use authentication, and others
                        that do not.

      b)  Checking the Validation Pattern of an Inbound BISPDU:

          The contents of the Validation Pattern field of an inbound BISPDU
          will be checked by the following procedures:

          1)  Apply the IDRP checksum algorithm to the data stream that
              consists of the contents of the inbound BISPDU with its
              Validation Pattern set to all zeros.  Call this quantity the
              "reference pattern".

          2)  Decrypt the Validation Pattern field of the inbound BISPDU,
              calling the result the "received pattern".

          If the "reference pattern" and the "received pattern" are
          identical, then the peer BIS has been authenticated, and the
          inbound BISPDU will be accepted.  If the "reference pattern" and
          the "received pattern" are not identical, the receiving BIS will
          inform system management that an authentication failure has
          occurred.  The incoming BISPDU will be ignored.  The receiving
          BIS will not send an IDRP ERROR PDU to the peer-BIS because the
          identity of the peer has not been authenticated.


   Kunzinger                     ISO/IEC 10747                 [ Page 225 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Note 43:  If a BISPDU has a malformed header, it will be discarded.
                As a result, the Validation Pattern of such BISPDUs will
                not be checked.















   Kunzinger                     ISO/IEC 10747                 [ Page 226 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   |                                  md41                                |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 10. An Example of the Authentication Type 2














   Kunzinger                     ISO/IEC 10747                 [ Page 227 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Annex E.  Jitter algorithm


                                (informative)

      When BISPDUs are transmitted as a result of timer expiration, there
      is danger that the timers of individual systems could become
      synchronized.  To minimize the likelihood of this occurring, all
      periodic timers whose expiration can cause the transmission of a
      BISPDU shall have jitter introduced.  An example algorithm that
      satisfies the requirements of 7.17.3.3 is shown below.











   Kunzinger                     ISO/IEC 10747                 [ Page 228 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   | CONSTANT                                                             |
   |   Jitter=0.25 (* defined by architectural constant Jitter *)         |
   |   Resolution=100                                                     |
   |                                                                      |
   | PROCEDURE Random (max: Integer): Integer                             |
   |   (* This procedure delivers a uniformly distributed random integer R|
   |    such that 0 < R < max *)                                          |
   |                                                                      |
   | PROCEDURE                                                            |
   |   DefineJitteredTimer (baseTimeValueinSeconds: Integer;              |
   |   expirationAction: Procedure);                                      |
   |                                                                      |
   | VAR                                                                  |
   |   baseTimeValue, maximumTimeModifier, waitTime: Integer;             |
   |   nextexpirtation: Time;                                             |
   |                                                                      |
   | BEGIN                                                                |
   |   baseTimeValue:=baseTimeValueInSeconds*1000/Resolution;             |
   |   maximumTimeModifier:=baseTimeValue*Jitter;                         |
   |   WHILE running DO                                                   |
   |     BEGIN                                                            |
   |     (* First compute next expiration timer *)                        |
   |     randomTimeModifier:=Random(maximumTimeModifier);                 |
   |     waitTime:=baseTimeValue - randomTimeModifier;                    |
   |     waitTime:=waitTime*Resolution/1000;                              |
   |     nextexpiration:=CurrentTime + waitTime;                          |
   |     (* Then perform expiration action *)                             |
   |     expirationAction: WaitUntil(nextexpiration)                      |
   |     END (* of loop *)                                                |
   |  END (* of DefinedJitterTimer *)                                     |
   |                                                                      |
   |                                                                      |
   +----------------------------------------------------------------------+




   Kunzinger                     ISO/IEC 10747                 [ Page 229 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Annex F.  Computing a checksum for an Adj-RIB


                                (informative)

      To compute the checksum for a given Adj-RIB-Out or Adj-RIB-In, the
      following procedure can be used:

      a)  Unfeasible routes will not enter into the computation.

      b)  A sequence number will be associated with each feasible route in
          the information base.  For an Adj-RIB-Out, it will be the locally
          generated sequence number of the UPDATE PDU that was used to
          advertise the route; for an Adj-RIB-In, it will be the sequence
          number of the neighbor BIS's UPDATE PDU that advertised the
          route.

      c)  The feasible routes within the information base will be sorted in
          a non-decreasing order of their sequence numbers.

      d)  Within each route, path attributes will be sorted in a
          non-decreasing order based on their type codes, followed by the
          Network Layer Reachability Information sorted in lexicographical
          order, based on the binary value of its NSAP address prefixes.

      e)  The checksum will be generated by applying the procedures of
          Annex B to the octet stream which is composed from the
          concatenation of the sorted feasible routes.






   Kunzinger                     ISO/IEC 10747                 [ Page 230 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Annex G.  RIB overload


                                (informative)

      A BIS is said to experience a RIB-overload condition when it does not
      have enough memory available to store the routeing information needed
      for its Adj-RIBs-In, Loc-RIBs, and Adj-RIBs-Out.  Since the routeing
      information that a BIS chooses to maintain is in fact a local policy,
      this International Standard does not prescribe methods for handling
      overload conditions.

      Methods for handling RIB overload can be considered as specific
      instances of local policies, and therefore are not specified by this
      International Standard.  However, some examples of approaches that
      may be used to control RIB overload are suggested below.

      Since the Loc-RIBs contain only a subset of the routeing information
      held in the Adj-RIBs-In, the size of a BIS's Adj-RIBs-In will be
      greater than or equal to the size of its Loc-RIBs.  Therefore, the
      first step to alleviate the memory overload condition would be to
      reduce the amount of information that is stored in Adj-RIBs-In.  To
      insure routeing consistency within a routeing domain, the following
      steps can be applied to an Adj-RIB-In that is associated with a peer
      BIS located in an adjacent routeing domain:

      a)  Remove routes that are not currently in any of the Loc-RIBs (that
          is, those routes that have not been selected by the Decision
          Process):

          -   Any routes to destinations that are not contained in the
              routes stored in the Loc-RIB may be removed with no negative
              impact.

          -   Any routes to destinations that are contained in the routes
              stored in the Loc-RIBs can also be removed.  However, since
              they could later have been used as fallback routes (if the
              current route that is in the Loc-RIB becomes unfeasible),
              removing them may cause suboptimal connectivity in the
              future.


   Kunzinger                     ISO/IEC 10747                 [ Page 231 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      b)  If several Adj-RIBs-In (that have the same RIB attribute but are
          associated with different neighbor BISs) have routes to the same
          destination, then routes with higher degree of preference (as
          computed by the local BIS) should be retained, while routes with
          lower degree of preference may be deleted.

      c)  If a BIS unilaterally deletes a route, then any solicited
          RIB-refresh will reinstate the deleted route.  Hence, if the
          condition persists, the memory-overloaded BIS should close the
          IDRP connection, and then take corrective action, such as
          re-opening it with an OPEN PDU that indicates support for a
          smaller RIB-ATTsSet, for example.

      d)  Terminate one or more of the IDRP sessions with other BISs. That
          would result in releasing the memory that was previously used to
          store the Adj-RIB-Ins and the Adj-RIBs-Out associated with that
          BIS. To ensure routeing consistency within an RD this measure may
          be applied only to the IDRP sessions with BISs in adjacent RDs.

      e)  If all else fails to alleviate  the memory overload condition,
          the local BIS can terminate all of its IDRP sessions.









   Kunzinger                     ISO/IEC 10747                 [ Page 232 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Annex H.  Processor overload


                                (informative)

      A BIS is said to be CPU overloaded when there is not enough
      processing power to process incoming BISPDUs received from other
      BISs. In this situation BIS must continue to update the Adj-RIBs-In
      with information contained in BISPDUs received from other BISs, but
      may not run the Decision Process using this information except for
      routes identified in the WITHDRAWN ROUTES field of an UPDATE PDU.

      For a route identified in the WITHDRAWN ROUTES field of the UPDATE
      PDU, the local BIS checks whether this route is currently installed
      in one of its Loc-RIBs; if so, it removes it from the appropriate
      Loc-RIB, updates the appropriate Adj-RIBs-Out and FIB, and generates
      (if necessary) an UPDATE-PDU to inform other BIS's of the change in
      its Loc-RIBs and its Adj-RIBs-Out.  The Decision Process on the local
      BIS does not select another to replace the one that becomes
      unfeasible.

      Since this procedure decreases the size of the Loc-RIB, a
      long-lasting CPU overload condition can eventually deplete the entire
      Loc-RIB, thus making the BIS unavailable as an intermediate system.
      If the CPU overload condition disappears, then the Decision Process
      and Update Process should be run over all the new routes that were
      installed into the Adj-RIBs but have not yet been processed by the
      Decision Process. If the CPU overload condition persists for more
      than the predefined architectural constant MaxCPUOverloadPeriod, the
      local BIS terminates its IDRP sessions.

      The order of termination of the IDRP sessions is significant. First
      the BIS should terminate one or more of the IDRP sessions with BISs
      in adjacent RDs. If after terminating IDRP sessions with all of the
      BISs in adjacent RDs the CPU overload still persists, the BIS
      terminates the rest of its IDRP sessions (with all the BISs within
      its own RD).



   Kunzinger                     ISO/IEC 10747                 [ Page 233 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Annex J.  Formation of RDCs


                                (informative)

      Confederations exist in the knowledge configured into a given BIS.
      Since this knowledge must be added one BIS at a time, it is necessary
      to examine how a confederation can grow, and what happens in the
      interim when only some of the BISs are aware of the information
      regarding the confederation.

      There are some potential problems that one should be aware of:

      -   Routes through a confederation might not work properly if BISs in
          the middle of the confederation do not know about the
          confederation.

      -   Routes may not work properly while a planned very large
          confederation with confederations nested inside is growing, but
          is not yet large enough to include all the confederations that
          eventually will be nested inside.

      -   Policies in distant BIS's must change when confederations are
          formed or dissolve.

      If confederations are formed and dissolved carefully, then these
      problems can be avoided.  The next sections describe the steps that
      should be taken for several common scenarios.

   J.1  Forming a new lower level confederation

      Let's start with the simplest case--a newly formed confederation
      consisting of several RDs.  The steps involved are:

      a)  First warn all managers of all BISs whose RDs are contained in
          the new RDC that a new confederation will be formed consisting of
          the RDs in a particular set.  If the new confederation is to be
          nested within an existing confederation, the existence of the new
          confederation will not be noticeable to any BISs outside the
          nesting confederation.  Thus the affected BISs are those within
          the lowest level confederation in which this new confederation

   Kunzinger                     ISO/IEC 10747                 [ Page 234 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          will be nested.  If there are multiple overlapping confederations
          in which the confederation will be nested, with no smaller
          confederation nested within one of the overlapping confederations
          and in which the new confederation will be nested, BISs in all
          those confederations will be affected.

      b)  A manager of a BIS that has policies regarding any of the RDs to
          be included in the new confederation must modify those policies
          since the RDs in the new RDC can no longer be differentiated. For
          example, if the previous policy was that some of those were all
          right to route through and others not, a new single policy for
          the new confederation would need to be formulated.

      c)  The policy regarding the new confederation must be added to the
          existing set of policies (the confederation will not appear
          immediately).

      d)  When ample time has elapsed so that managers will can modify the
          policies at their BISs, the managers of the BISs in the new
          confederation can start informing them about the new
          confederation.

      e)  One by one, each BIS is informed that it is in the confederation.
          The order in which the BISs are modified is critical.  At all
          times the set of BISs that have been informed about the
          confederation must be a connected set.  Thus the confederation
          must be built gradually outwards until all the BISs have been
          modified.

      f)  When all the BISs in the confederation have been modified, the
          managers of remote BISs can be informed that the confederation
          has been fully formed, and any old policies regarding the RDs in
          the confederation can now be safely deleted.

      Note that the above rules apply as well if the new confederation is
      one that is nested within another confederation.  The only difference
      that occurs when the new confederation to be formed is nested within
      a confederation X is that managers of BISs that are not contained
      within X do not need to be informed about the formation of X.

      Also note that the BISs internal to X still need to retain their
      policies regarding the RDs and confederations within X.


   Kunzinger                     ISO/IEC 10747                 [ Page 235 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   J.2  Forming a higher level confederation

      Now assume it is desired to form a new confederation X that will have
      some number of already formed confederations nested within it, say Y
      and Z.  The steps are:

      a)  As above, warn all managers of all affected BISs (i.e.  in the
          lowest level confederation(s) that X will be nested within (or
          all BISs, if X is a top level confederation)) that a new
          confederation X will be formed, and list all the RDs and
          confederations to be included (the ones that are currently
          visible externally, i.e., don't list the RDs in confederations to
          be included in X -- just list the top level confederations to be
          included)..

      b)  As above, managers of BISs must figure out a reasonable policy
          for the new confederation.

      c)  As above, the policy regarding the new confederation must be
          ADDED to the existing set of policies (the confederation will not
          appear immediately).

      d)  As above, when ample time has elapsed so that managers will have
          been given an appropriate opportunity to modify the policies at
          their BISs, the managers of the BISs in the new confederation can
          start informing the BISs in the confederation about the
          confederation.

      e)  As above, one by one, each BIS is informed that it is in the
          confederation, where the order in which the BISs are configured
          with the confederation information is critical--at all times the
          confederation must be connected.

          The difference, though is in how the BISs are configured.
          Initially, the BISs are informed, one by one, that they are in X,
          but they are NOT informed that Y and Z are nested within X.
          Instead, they will be configured as though X is a lowest level
          confederation.

      f)  After all BISs in the confederation have been configured to know
          they belong to X, they can one by one be modified to believe Y
          and Z are nested within X.  In contrast to the knowledge that
          they belong to X, which must be configured in a careful order,
          the knowledge that Y and Z are nested within X can be configured
          within the BISs in X in any order.

   Kunzinger                     ISO/IEC 10747                 [ Page 236 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      g)  When all the BISs in the confederation have been twice modified
          (once to know about X, and once to know about the nesting rules),
          managers of remote BISs can be informed that the confederation
          has been fully formed, and the policies regarding RDs and
          confederations in the new confederation can now be safely
          deleted.

   J.3  Deleting a lowest level confederation

      Now suppose there is a confederation X, with no confederations nested
      within it, that is being dissolved.  The steps involved are:

      a)  First warn all managers of all affected BISs (see point 1 in the
          previous 2 sections for a rigorous description of which BISs are
          affected), that X will be dissolved, and list all the RDs in X.

      b)  A manager of a BIS that has policies regarding X needs to add the
          same policy many times, one for each RD in X.  It is also
          possible at this time to make policies that are different for the
          RDs in X.

      c)  When ample time has elapsed so that managers will have been given
          an appropriate opportunity to modify the policies at their BISs,
          the managers of the BISs in X can start informing the BISs in X
          to forget about X.

      d)  One by one, each BIS in X is informed that it is not in X.  The
          order in which the BISs are modified is critical.  At all times
          the set of BISs that believe they are in X must be a connected
          set.  Thus X must be shrunk gradually towards one point.

      e)  When all the BISs in X have been modified, the managers of remote
          BISs (those in the confederation within which X had been nested,
          or all BISs if X was a top level confederation) can be informed
          that X no longer exists, and the policies regarding X can now be
          safely deleted.




   Kunzinger                     ISO/IEC 10747                 [ Page 237 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   J.4  Deleting a higher level confederation

       The steps involved are:

      a)  As above, warn all managers of all affected BISs (see point 1 in
          the previous 3 sections) that confederation X will be dissolved,
          and list all the RDs and confederations included in X (i.e., the
          ones that will become visible when X is deleted.)

      b)  As above, policies need to be ADDED regarding all the RDs and
          confederations that were included in X.

      c)  As above, when ample time has elapsed so that managers will have
          been given an appropriate opportunity to modify the policies at
          their BISs, the managers of the BISs in the new confederation can
          start informing the BISs in X about X's impending dissolution.

      d)  Now different from above, one by one (in any order) the BISs in X
          are informed that nothing is nested within X any more, though
          they retain knowledge of X.

      e)  After all BISs in X have been configured to believe X is a bottom
          level confederation, knowledge of X can be carefully deleted from
          the BISs (careful because the order is critical, as above, i.e. X
          must at all times be connected.)

      f)  After all BISs previously in X have been twice modified (once to
          delete the nesting rules for X, and one to delete X), managers of
          remote BISs can be informed that X has been fully dissolved, and
          policies regarding the confederation can now be safely deleted.






   Kunzinger                     ISO/IEC 10747                 [ Page 238 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Annex K.  Example usage of MULTI-EXIT_DISC attribute


                                (informative)

      The MULTI-EXIT DISC attribute can be used to provide a limited form
      of multi-path (load-splitting), as is shown in the following
      examples.

      -   Example 1 (see Figure 11):
      Figure 12. Example 2 Configuration

      Consider the case when a BIS A located in routeing domain RD-A has
          two adjacent BISs (B1 and B2) that belong to the routeing domain
          RD-B.  Assume that RD-B has Network Layer Reachability
          information about NSAPs N1, N2, ... Nk, and it wants to advertise
          this information to RD-A.  By using the MULTI-EXIT_DISC attribute
          RD-B may do selective load splitting (based on NSAP addresses)
          between B1 and B2.

          For example, BIS B1 advertises to BIS A Network Layer
          Reachability information N1, N2, ... Nm with the MULTI_EXIT_DISC
          set to X, and advertises N(m+1), ... Nk with the MULTI_EXIT_DISC
          set to X + 1.

          Similarly, BIS B2 advertises to BIS A Network Layer Reachability
          information N1, N2, ... Nm with the MULTI_EXIT_DISC set to X + 1,
          and advertises N(m+1), ... Nk with the MULTI_EXIT_DISC set to X.

          As a result, traffic from BIS A that is destined to N1, N2, ...
          Nm will flow through BIS B1, while traffic from BIS A that is
          destined to N(m+1), ... Nk will flow through BIS B2.  This
          scenario illustrates the simplest way of doing limited multipath
          with IDRP.

      -   Example 2 (see Figure 12):

          Next consider more complex case where there is a multihomed
          routeing domain RD-A that has only slow speed links. RD-A is
          connected at several points to a transit routeing domain RD-B
          that has only high speed links; BIS A1 is adjacent to BIS B1, and
          BIS A2 is adjacent to BIS B2. RD-A wants to minimize the distance

   Kunzinger                     ISO/IEC 10747                 [ Page 239 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   |                                 RD-A                                 |
   |                                                                      |
   |                       +-----------------------+                      |
   |                       |                       |                      |
   |                       |                       |                      |
   |                       |       +-------+       |                      |
   |                       |       |  A1   |       |                      |
   |                       +-----------------------+                      |
   |                                /     \                               |
   |   Update PDU 1:               /       \      Update PDU 1:           |
   |    MULTI_EXIT_DISC = x,      /         \      MULTI_EXIT_DISC = x+1  |
   |    NLRI = N(1)...N(M)       /           \     NLRI=N(1)...N(M)       |
   |   Update PDU 2:            /             \   Update PDU 2:           |
   |    MULTI_EXIT_DISC = x+1, /               \   MULTI_EXIT_DISC = x    |
   |    NLRI = N(1)...N(K)    /                 \  NLRI=N(1)...N(K)       |
   |                         /                   \                        |
   |                +-------------------------------------+               |
   |                |    | B1 |                   | B2 |  |               |
   |                |    +----+                   +----+  |               |
   |                |                                     |               |
   |                |                                     |               |
   |                |                                     |               |
   |                +-------------------------------------+               |
   |                                                                      |
   |                                 RD-B                                 |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 11. Example 1 Configuration

          that incoming NPDUs addressed to certain ESs--say ES(1) through
          ES(k)--will have to travel within RD-A.

          One way of doing this is by making BIS A1 to announce to BIS B1
          destinations ES(1)-ES(k) with a lower MULTI_EXIT_DISC, as
          compared to the MULTI_EXIT_DISC that BIS A2 will use when
          announcing the same destinations to the BIS B2.  Similarly, BIS
          A2 would announce to BIS B2 destinations ES(k+1)-ES(n) within the
          RD-A that are closer to the BIS A2 (than to the BIS A1) with the
          lower MULTI_EXIT_DISC, as compared to the MULTI_EXIT_DISC that
          the BIS A1 will use when announcing the same destinations to the
          BIS B1.


   Kunzinger                     ISO/IEC 10747                 [ Page 240 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   |                            RD-B                                      |
   |                                                                      |
   |                                                                      |
   |            +---------------------------------------+                 |
   |            |               | X |                   |                 |
   |            |               +---+                   |                 |
   |            |                                       |                 |
   |            |          +----+     +----+            |                 |
   |            |          | B1 |     | B2 |            |                 |
   |            +---------------------------------------+                 |
   |                         |          |                                 |
   |  Update PDU:            |          |  Update PDU:                    |
   |   MULTI_EXIT_DISC=x     |          |   MULTI_EXIT_DISC=x+1           |
   |   NLRI=ES(1) to ES(k)   |          |   NLRI=ES(1) to ES(k)           |
   |                         |          |                                 |
   |                         |          |                                 |
   |  Update PDU:            |          |  Update PDU:                    |
   |   MULTI_EXIT_DISC=x+1   |          |   MULTI_EXIT_DISC=x             |
   |   NLRI=ES(k+1) to ES(n) |          |   NLRI=ES(k+1) to ES(n)         |
   |                         |          |                                 |
   |            +---------------------------------------+                 |
   |            |          | A1 |     | A2 |            |                 |
   |            |          +----+     +----+            |                 |
   |            |            |  \      /  |             |                 |
   |            |            |   \    /   |             |                 |
   |            |            |    \  /    |             |                 |
   |            |            |     \/     |             |                 |
   |            |            |     /\     |             |                 |
   |            |            |    /  \    |             |                 |
   |            |            |   /    \   |             |                 |
   |            |            |  /      \  |             |                 |
   |            |         +-------+   +---------+       |                 |
   |            |         | ES(1) |   | ES(k+1) |       |                 |
   |            |         |  to   |   |   to    |       |                 |
   |            |         | ES(k) |   | ES(n)   |       |                 |
   |            |         +-------+   +---------+       |                 |
   |            |                                       |                 |
   |            +---------------------------------------+                 |
   |                                                                      |
   |                                                                      |
   |                           RD-A                                       |
   |                                                                      |
   +----------------------------------------------------------------------+

   Kunzinger                     ISO/IEC 10747                 [ Page 241 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

          When traffic that is destined to some ES within RD-A enters  RD-B
          on its way to RD-A via BIS X, X picks up the exit BIS that has
          the lowest MULTI_EXIT_DISC value for that destination.  For
          example, X may pick up BIS A2 as an exit, even if the distance
          between A2 and X is greater than the distance between A1 and X.














   Kunzinger                     ISO/IEC 10747                 [ Page 242 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx
















   Kunzinger                     ISO/IEC 10747                 [ Page 243 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   Annex L.  Syntax and semantics for policy


                                (informative)

      This annex describes an example of a policy syntax and its associated
      semantics for the protocol defined in this International Standard.
      The example is intended to be informative: that is, alternative
      syntaxes with equivalent richness of functionality are not precluded,
      and other mechanisms may be needed to provide a fully functional
      configuration language.

   L.1  Overview

      The policy information base allows routing domain administrators to
      control routing information usage and flow according to the policies
      of the domain.  The policy information base is made up of three
      component sections, corresponding to three primary types of policy
      concerns that have been identified:

      a)  Route preference assigns a preference value to incoming routes;
          this is the "local selection policy" regarding routes.  These
          policies determine which routes in the Adj-RIBs-In are selected
          for the LOC-RIB.

      b)  Route aggregation chooses routes for aggregation and expresses
          some control over how aggregation is performed.  These policies
          select routes in the LOC-RIB that are to be advertised as an
          aggregate.  These policies can affect routes sent to BISs
          internal and external to the domain.

      c)  Route distribution modifies and selects routes for
          redistribution; this expresses the domain's "transit policy".
          These policies control traffic through the domain by restricting
          which routes from the Loc-RIB are placed in the Adj-RIBs-Out.
          Modifications may affect routes sent to internal or external
          BISs, however, selection policy only affects the distribution of
          routes to BISs external to the domain; internal BIS neighbors
          receive route information from the local BIS regardless of
          policy.

   Kunzinger                     ISO/IEC 10747                 [ Page 244 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Each policy subsection is comprised of a list of policy statements
      that express the domain's policy.  Although the policy statements of
      each section are different, all include a route pattern (which is a
      template for matching route attributes) and the associated actions.
      A domain administrator can use these "match + action" pairs to
      express the administrative policy of the routing domain.

   L.1.1  Preference statement

      The preference statement is identified by the "PREF" keyword, and has
      the following format:

       PREF <route pattern template> [<local_cond>] [<bis>]
         = <preference value expression>

      A PREF statement assigns a value to any route (from a BIS neighbor in
      an external domain) that matches the specified pattern.  The assigned
      value determines the degree of preference that will be used in the
      Decision Process.  This value is also used to generate the LOC_PREF
      attribute.  Note that it is possible for the assigned value to be
      less than zero or greater than 255.  Conversion from the assigned
      value to an eight-bit LOC_PREF field is a local matter.  Routes
      received from internal BIS neighbors will already have a LOC_PREF
      field.  The use of the LOC_PREF field as a basis for selecting the
      most preferred route is described in 7.12.1.

      The components of a <route pattern template> are:

      -   <nlri>
      -   [<info_src>]
      -   [<path>]
      -   [<dist_att>]
      -   [<att_cond>], where:.

      <nlri> : Reachable destinations; matches if the actual route's NLRI
            is a subset of the destinations specified by this template.
            The <nlri> must be present in the route pattern of every policy
            statement.

      <info_src> : Can be "idrp"|"ext"|"info_any", which is matched base d
            on the presence/absence of the EXT_INFO attribute in a route.
            These tokens are optional; if not present, the default match is
            "idrp".

   Kunzinger                     ISO/IEC 10747                 [ Page 245 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       <path> : Regular expression over RDIs to match against the content
            of the RD_PATH attribute.  A <path> is optional; if not
            present, the default matches any RD_PATH attribute.

      <dist_att> : Specifies a set of distinguished attributes for a route
            match.  The <dist_att> is optional; if not present, the pattern
            matches routes with any set of distinguished attributes.

      <att_cond> : Provides matching/control for all other attributes, i.e.
            other than what is carried in RD_PATH, EXT_INFO path attribute,
            and the presence of distinguished attributes.  This specifies
            conditions of route attributes that must be met for a route to
            match, e.g. (EXPENSE() < 10) && (! present(DIST_INCL)) might be
            the condition if the intent is to match a low-cost route which
            does not have certain re-distribution restrictions.  No
            <att_cond> need be specified; if not present, the route pattern
            matches routes with any attributes.

      Note that the route pattern template is found in all three types of
      policy statement (preference, aggregation, and distribution).  A
      slightly different form is used in the aggregation policy statement,
      which is discussed below.

      The PREF statement (actually, all policy statements) may also include
      "local condition tests", which allow policy to be sensitive to
      criteria not related to a route's attributes (e.g. time of day).  A
      <local_cond> is optional; if not present, routes are matched under
      any local conditions.

      The specification of <bis> allows routes from different BIS neighbors
      to be assigned preferences differently.  Any number of external BIS
      neighbors may be specified, and only routes received from these
      neighbors will be assigned a preference value by the statement.

      The <preference value expression> is an integer arithmetic expression
      with operators '+', '-', '*', '/', and (similar to the C language) a
      conditional operator '?'.  The basic operands are constants, or
      pre-defined functions which return values based on the attributes of
      a route, e.g. hopcount(), capacity(), weighted_list(EXCL,<table>).
      The condition expression for the condition operator includes the
      logic operators "&&" and "||", and may include (1) tests for the
      presence of an attribute, (2) comparisons of integer expressions
      including attribute values, and (3) local condition tests.  A <pref
      value> is required in all preference statements.

   Kunzinger                     ISO/IEC 10747                 [ Page 246 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      The order of PREF statements in a configuration file is significant;
      the first <route pattern> that matches an incoming route will assign
      the preference value.  The list of PREF statements can be thought of
      as filters, each acting on particular routes; a routing domain
      administrator can make effective use of this first-match
      functionality by listing more specific route patterns early and more
      general patterns later.  Hence, the "filters" start at a fine degree
      of granularity to assign preference to routes of particular
      importance, while other routes are handled by increasingly general
      "filters".

      If a route does not match any <route pattern>, it is dropped and not
      considered by the IDRP Decision Process.  Note that there may be
      over-riding operational criteria that dictate that the non-matched
      routes can not be handled in this manner.

      The concept of decreasingly specific filters is useful for all of the
      policy sections: preference, aggregation, and distribution.  As
      described below, more flexible control of the processing sequence for
      aggregation and distribution statements is possible, and necessary to
      concisely express policy.

   L.1.2  Aggregation statement

      The aggregation statement is identified by the "AGGR" keyword, and
      has the following format:

       AGGR <route pattern> <local_cond> =
        [<recipient BIS>] <aggr_nlri> ["DONE"|"CONT"]

      The <route pattern> specification of the aggregation statement is
      slightly different than the PREF statement <route pattern>.  The only
      difference is that the <nlri> template will consist of two NLRI
      specifications separated by the "MUST" token, i.e.  <nlri> "MUST"
      <nlri>.  The first <nlri> is used to match routes that can be
      aggregated, while the second <nlri> specifies NLRI which must be
      present for the aggregate route to be instantiated.  Either of the
      <nlri> specifications may omitted, but not both.  If the second
      <nlri> is omitted, the "MUST" token is not required.

      The AGGR statement's <local conditions> template has the same syntax
      and semantics as the PREF statement.


   Kunzinger                     ISO/IEC 10747                 [ Page 247 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      The <recipient BIS> of the aggregation statement indicates which
      external BIS's Adj-RIBs-Out are to receive the results of the
      statement's route aggregation.  One, several, or all external BISs
      may be specified to receive the aggregate route "manufactured" by an
      AGGR statement.  In addition, an administrator can specify
      "internal_bis" to affect aggregation to all other BISs internal to
      the routing domain.

      If a BIS is included in the recipient list, it will receive the
      aggregated route but not the component routes; if an aggregate is not
      instantiated to a particular BIS, it will receive all of the
      component routes.  Note that by using additional AGGR statements
      (with more specific route matching templates), particular component
      routes may be advertised separately from the aggregate route.  If the
      <recipient BIS> list is not specified, the default action is to
      announce the aggregate route to all external neighbor BISs; the
      default action will announce component routes to internal BISs.

      The <aggr_nlri> specifies how the BIS determines which NLRI to
      advertise for the aggregate route.  The two primary specifications
      are manual ("man") or automatic ("auto"), with two additional tokens
      ("auto_short" and "auto_subset") to specify variations of "auto";
      "auto" includes both of these variations.  Automatically aggregated
      NLRI will only reduce routes if there is no loss of reachability
      information, i.e. it will only advertise a more general NLRI if it
      can algorithmically determine that the aggregate is not advertising
      NLRI other than those of the component routes.  Domain administrators
      can also "manually" override the automatic aggregation and specify
      that aggregated route NLRI may include destinations not included in
      any component of the aggregate route.  The "manual" option is
      primarily intended for use when additional (complete) information is
      known about the NLRI (e.g. when it is part of the address space under
      control of the routing domain).  It is assumed such information is
      obtained by means outside of IDRP.  For instance, using "manual" NLRI
      configuration, a domain that acts as an address assignment authority
      may announce a single prefix for all routes containing longer
      extensions of this prefix, even though portions of the address space
      may be unassigned, with no route available to some destinations
      advertised by the NLRI.  Manually aggregated NLRI is determined by
      taking the longest common prefix of the set of NLRI specified by the
      route pattern <nlri>.  Using automatic aggregation, the aggregate
      NLRI is computed to be the shortest NLRI prefix necessary to announce
      the component route's NLRI (the aggregate NLRI is also the longest
      common prefix of the component routes).  The two variations of "auto"
      are as follows: (1) "auto_short" will collapse several longer NLRI

   Kunzinger                     ISO/IEC 10747                 [ Page 248 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      prefixes into a single common prefix based on the binary
      representation, e.g.  XX:YY:0xF601:* - XX:YY:0xF60F:* will be
      advertised as XX:YY:0xF60:*, and (2) "auto_subset" will permit longer
      prefixes to be aggregated with shorter ones, e.g. XX:YY:ZZ:* would be
      aggregated with XX:YY:* into XX:YY:*.

      Like PREF statements, the AGGR statements are applied in sequence
      (they are applied to the set of routes in the LOC-RIB).  "DONE" and
      "CONT" provide control over additional processing of routes by
      subsequent AGGR statements.  "CONT" is used to indicate that the
      aggregate route may be treated as a component route by later AGGR
      statements, and thus may be matched and further aggregated.  "DONE"
      indicates that the aggregate is to be advertised as-is, and will not
      be considered as a component route for further aggregation.
      Specification of "DONE" or "CONT" is optional; the default case is
      "DONE".

      [Note: Aggregated routes will have a preference value assigned by the
      policy PREF statements; just as incoming routes from other BISs,
      aggregated routes are processed by the route preference statements.
      If an aggregate route does not match a PREF statement template, no
      value is assigned and the aggregate is not instantiated.]

   L.1.3  Distribution statement

      The distribution statement is identified by the "DIST" keyword, and
      has the following format:

        DIST <route pattern> [<local_cond>] = [<recipient BIS>]
          <select_action> [<modifications>] ["DONE"|"CONT]"]

      The <route pattern> for the DIST statement is the same as the PREF
      statement <route pattern>, and <local_cond> serves the same function
      for the DIST statement as it does for the AGGR and PREF statements.

      Similar to the AGGR statement, the <recipient BIS> specifies which
      Adj-RIBs-Out are effected by the statement.  The Adj-RIBs-Out
      associated with the neighbors specified in <recipient BIS> may be
      affected in three ways by a DIST statement: (1) the route may be
      modified in these Adj-RIBs-Out, (2) the route may be placed in, or
      removed from, the Adj-RIBs-Out, and (3) the route may be marked as
      "DONE", so that it remains unaffected by further DIST statements.


   Kunzinger                     ISO/IEC 10747                 [ Page 249 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      The <select_action> can be "select_on", "select_off", "select_only",
      or "modify"; these control whether a route is distributed to an
      adjacent BIS.  If a route is selected for advertisement to a
      particular BIS neighbor, it will be placed in the associated RIB-OUT.
      By default, routes are not selected for advertisement until selected
      by a DIST statement.  The semantics of the <select_action> effect
      this distribution as follows:

      "select_on" The route should be placed in Adj-RIBs-Out associated
                with all specified neighbors, unless "selected off" by
                later DIST statement.

      "select_off" The route should not be placed in Adj-RIBs-Out
                associated with the specified neighbors, unless "selected
                on" by a later DIST statement.

       "select_only" The route should be placed in Adj-RIBs-Out associated
                with all specified neighbors, unless "selected off" by
                later DIST stmt; in addition, the route should not be
                placed in Adj-RIBs-Out associated with BISs not in
                <recipient BIS>, unless "selected on" by a later DIST
                statement.

      "modify"  Modify only; the selection status of routes are not
                effected by this DIST statement.  Presumably, some routes
                matching this statement will also match, and be selected
                for distribution by, other DIST statements.

      The effects of a <select_action> is applied only when <recipient BIS>
      indicates a BIS in an adjacent domain.  It has no effect on
      distribution to BISs within the same domain as the local system.

      Note that in most cases, only the routes in Adj-RIBs-Out specified by
      <recipient BIS> will be affected by a DIST statement, however, there
      is one exception.  The "select_only" action also indicates routes are
      not to appear in the Adj-RIBs-Out associated with BISs not in
      <recipient BIS> list, and that these routes may or may not be
      considered for further DIST statement processing (in the excluded
      BISs) based on the DIST statement's DONE/CONT token.  Using
      "select_only" along with "DONE" allows one to concisely specify that
      only certain BISs are to receive particular routes, and as an
      additional effect, make certain these routes are not inadvertently
      selected for other BISs by a subsequent DIST statement that matches a
      more general route pattern.

   Kunzinger                     ISO/IEC 10747                 [ Page 250 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      A list of <modifications> statements indicates policy-driven changes
      to route attributes (e.g. DIST_LISTs, HIERARCHICAL RECORDING changes,
      etc).  No <modifications> need be present; the default leaves routes
      unchanged.

      "CONT" and "DONE" have similar function as in the aggregation
      statement; they control whether routes matching a particular DIST
      statement may be affected by later DIST statements.  "CONT" indicates
      that a matched route in a specified RIB-OUT is eligible for further
      modifications, "DONE" indicates no further DIST statement processing.
      Specification of "DONE" or "CONT" is optional; the default case is
      "DONE".

   L.2  Policy configuration language BNF

      This section specifies the basic syntax for this example IDRP
      configuration language.  This BNF tree does not include all
      terminal-symbol leaves; it is sufficient as an illustration of some
      minimal useful functionality, however, it is not complete.

      The policy configuration language uses a '#' to denote a comment to
      the end of line.  This convention is also used to provide comments
      throughout the BNF specification.  This BNF uses square brackets, '['
      and ']', as a notational convenience to indicate optional (zero or
      one occurrence) syntactic symbols.  This BNF also uses curly braces,
      '{' and '}' and a '|' to indicate a choice of symbols.

      A discussion of the semantics of this language can be found in L.1.1
      above..

   L.2.1  PREF statement BNF

       <preference_section> ::= <p_stmt_list>
        <p_stmt_list> ::= <p_stmt> ';' <p_stmt_list> | <empty>
        <p_stmt> ::= "PREF" <nlri> <route_pattern> <local_cond> [<bis>]
                 '=' <preference_value_expression>

      All of the symbols used by the <p_stmt> are also used in other
      places, and are defined in L.2.4.


   Kunzinger                     ISO/IEC 10747                 [ Page 251 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   L.2.2  AGGR statement BNF

       <aggregation_section> ::= <a_stmt_list>
        <a_stmt_list> ::= <a_stmt> ';' <a_stmt_list> | <empty>
        <a_stmt> ::= "AGGR" <nlri_2> <route_pattern> <local_cond>
       '=' [<bis>] <aggr_nlri> <done_cont>

       <nlri_2>::= '{' <dest_list> [ "MUST" <dest_list> '}']
       <aggr_nlri>::= "auto" | "auto_subset" | "auto_short" | "man"

   L.2.3  DIST statement BNF

       <distribution_section> ::= <d_stmt_list>
        <d_stmt_list> ::= <d_stmt> ';' <d_stmt_list> | <empty>
        <d_stmt> ::= "DIST" <nlri> <route_pattern> <local_cond>
                  '=' [<bis>] <select_action> <mods> <done_cont>
       <select_action> ::= "select_on" | "select_off"  |
        "select_only" | "modify"

      Policy- defined changes to route attributes are distinct from
      attribute updates that occur due to basic "operational" processing
      (e.g. HOP_COUNT is updated without regard to policy).

       <mods> ::= '{' <mod_list> '}' | <empty>
        <mod_list> ::= <mod_statement> ';' <mod_list> | <empty>
        <mod_statement> ::= <multi_exit_statement> |
             <dist_list_statement>  |
             <hrecord_statement>    |
             <next_hop_statement>

       <multi_exit_statement> ::= "set_multi_exit" '(' <value> ')'

      init_hr() - If HIERARCHICAL_RECORDING attribute is not already
      present in route, add attribute to route and initialize to one (1) to
      limit distribution within RDC.

       <hrecord_statement>  ::=  "init_hr" '(' ')'

      Add RDIs to INCL or EXCL list.

       <dist_list_statement> ::=
        "allow_dist" '(' <rdis> ')' |
        "prohibit_dist" '(' <rdis> ')'

   Kunzinger                     ISO/IEC 10747                 [ Page 252 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       <next_hop_statement> ::=
        "set_next_hop" '(' <net> <snpa> ')'

   L.2.4  Common BNF symbols

      This section describes common syntax components used by all three
      types of policy statements.

   L.2.4.1  Route attribute matching template

      Reachability:

       <nlri> ::= '{' <dest_list> '}'
        <dest_list> ::= <dest> ',' <dest_list> | <dest>
        <dest> ::=      "nlri_any"              |
          ["not"] <nsap> ':' '*'  |      ## prefix match
          ["not"] <nsap>          |      ## exact <nsap> match
          <empty>

      Route matching template

       <route_pattern> ::= <info_src> <path> <dist_att> <attrib_cond>
       <info_src> ::= "idrp" | "ext" | "info_any"
       <path> ::= '/' <<regular-expression over RDIs>> '/'

      Distinguished attributes

       <dist_att> ::=  <empty> |
        "dist_att_none" |
        "dist_att_any" |
        '(' <qos> <security> <priority> ')'
       (If <empty>, default is "dist_att_any".)

       <qos> ::= "qos_any" | <qos_list>
       <qos_list> ::= <one_qos> <qos_list> | <empty>
       (If <empty>, default is "qos_any".)

       <one_qos> ::= "qos_none" | "error" | "expense" | "delay" |
        "capacity" | <src_qos> | <dst_qos>
       <src_qos>     ::= "srcqos"  <nsap>  <qos_value>
       <dst_qos>     ::= "dstqos"  <nsap>  <qos_value>
       <qos_value> ::=  ## TO BE DEFINED ##

   Kunzinger                     ISO/IEC 10747                 [ Page 253 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      <security> ::= "security_any" | <sec_list> <sec_list> ::= <sec_list>
      <one_sec> | <empty>
       (If <empty>, default is "security_any".)

       <one_sec> :: = "security_none" | <srcsec> | <dstsec>
       <srcsec> ::= "srcsec" <nsap>
       <dstsec> ::= "dstsec" <nsap>

      Security-related BNF is subject to change as the protocol continues
      to develop.

       <priority> ::= "priority_any" | "priority" | "priority_none"|
      <empty>

      The "priority_any" token matches routes in either case, whether; thef
      priority attribute is present, or if it is not.  If <empty>, default
      is "priority_any".

   L.2.4.2  BNF: numerical expressions

       <value> ::=
        <integer>       |
        <att_value>     |
        '('<value> ')' |
        <value> <integer_op> <value> |
        <case_statement>
       <case_statement> ::=   '(' <case_cond> '?' <value> ':'<value> ')'
       <att_value> ::=
        "hopcount"    "()"                 |  ## rd_hopcount
        "pathweight"  '(' <table> ')'      |  ## weighted path
        "listlen"    '(' {"INCL"|"EXCL"} ')'                 |
        "listweight" '(' {"INCL|"EXCL"} ',' <table> ')'      |
        <att_value_name> "()"

      Returns the value carried by the attribute specified by the
      <att_value_name>.

       <att_value_name> ::= "multi_exit" | "loc_pref" | "priority"
        | "delay" | "expense"  | "error" | "capacity"
        | "hier_rec"

      This example of the PIB BNF does not deal with the following
      attributes: SRC_QOS, DST_QOS, SRC_SECURITY, and DST_SECURITY.

   Kunzinger                     ISO/IEC 10747                 [ Page 254 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   L.2.4.3  BNF: conditional specification

      There are three related types of conditions:

      a)  <attrib_cond> used when doing a route match; only tests/examines
          attributes of a route
      b)  <local_cond> used in policy actions; tests "other" (TBD) criteria
          (e.g. time of day)
      c)  <case_cond> used in case statement; may test attribute or local
          criteria

       <local_cond> ::=
        <A_cond_LOCAL>                   |
        '!' <local_cond>                     |
        '(' <local_cond> ')'                 |
        <local_cond> "&&" <local_cond>   |
        <local_cond> "||" <local_cond>

        <A_cond_LOCAL>  ::=   ## TO BE DEFINED

      This is currently a place holder reserved for future use; one
      potential example is time of day.

       <attrib_cond> ::=
        <A_cond_ATTRIB>                  |
        '!' <attrib_cond>                    |
        '(' <attrib_cond> ')'                |
        <attrib_cond> "&&" <attrib_cond> |
        <attrib_cond> "||" <attrib_cond>

       <A_cond_ATTRIB> ::= <att_value> <compare_op> <value>     |
        "present" '(' <attribute_name> ')'   |
        <other_att_test>

       <case_cond> ::=    <A_cond_CASE>                  |
        '!' <case_cond>                    |
        '(' <case_cond> ')'                |
        <case_cond> "&&" <case_cond>   |
        <case_cond> "||" <case_cond>

       <A_cond_CASE>   ::= <A_cond_ATTRIB> | <A_cond_LOCAL>

       <attribute_name> ::= "src_qos" | "dst_qos" |
        "dst_sec" | "src_sec" |
        "dist_incl" | "dist_excl" |

   Kunzinger                     ISO/IEC 10747                 [ Page 255 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        "ext_info"  | "next_hop"  |
        <att_value_name>

       <other_att_test> ::=  <next_hop_test>

      This PIB BNF only defines the next_hop_test; others may be defined.

       <next_hop_test> ::= "next_hop" '(' <next_hop_list> ')'
       <next_hop_list> ::= <next_hop_match> ',' <next_hop_list>    |
        <next_hop_match>
       <next_hop_match> ::= "next_hop_any"             |
        ["not"] <net> ':' '*'      |
        ["not"] <net> [<snpa>]     |
        ["not"] <net> <one_snpa>   |

      One can attempt to match NEXT_HOP attribute against "any", a set of
      BISs (NET prefix), a particular BIS and optionally specific
      interfaces.  Also one can match routes against local interface over
      which route was received.

   L.2.4.4  Other common BNF symbols

      <bis> ::= "bis_all" | '{' <bis_list> '}' <bis_list> ::= <bis_item>
      ',' <bis_list> | <bis_item> <bis_item> ::= "rdi" <one_rdi> | "bis"
      <net> |
       "internal_bis"  | "external_bis"

      One can specify all BIS neighbors in an adjacent RDIrdi, single out a
      particular bis by NET, specify all internal BIS neighbors, or all
      external BIS neighbors.

       <done_cont> ::= "DONE" | "CONT" | <empty>
       (Default <empty> is DONE)

       <table> ::= '{' <table_list> <table_default> '}'
       <table_list> ::= <table_pair> <table_list> | <empty>
       <table_pair> ::= '(' <one_rdi> ',' <integer> ')'
       <table_default> ::= '(' "default" ',' <integer> ')' | <empty> p.List
      of interfaces of this BIS;

       <snpa> ::= '{' <snpa_list> '}'
       <snpa_list> ::= <one_snpa> ',' <snpa_list> | <one_snpa>

      Routing Domain Identifiers;

   Kunzinger                     ISO/IEC 10747                 [ Page 256 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

       <rdis> ::= '{' <rdi_list> '}'
       <rdi_list> ::= <rdi_list> ',' <one_rdi> | <one_rdi>

   L.3  Simple example

      This example is provided to make the intended use of the policy
      configuration language more clear.  Note that this example is
      incomplete, and at best only marginally realistic; it is intended to
      illustrate the basics of the policy configuration statements for
      purposes of this overview.

      Throughout this text we refer to the set of distinguished attributes
      which has no QOS attribute, no priority attribute, and no security
      attribute as the default set of distinguished attributes.  This is
      the distinguished attribute set specified by "dist_att_none".

      Consider the portion of an internet shown in Figure 13.  Assume that
      each routing domain has exactly one BIS that communicates with all
      adjacent domains' BISs.

   L.3.1  Transit domain 3

      Example policies of transit domain RD #3 might be as follows:

      a)  RD #3 only accepts IDRP originated routes.  It supports two sets
          of distinguished RIB_ATTs: the default set (no distinguished
          attributes) and the set having only the CAPACITY QOS attribute.

      b)  Routes with CAPACITY QOS must travel via RD#6; CAPACITY must be
          greater than 15.

      c)  For routes with no distinguished attributes, prefer routes
          through transit domain 1, however preference should be given to
          routes with short paths; large hop counts on a route via RD#1 may
          cause a shift to another transit domain.

      d)  CAPACITY QOS routes are only offered to some domains (RDs #5,
          #8), and are restricted from being propagated further (i.e. via
          the DIST_LIST_INCL attribute).

      e)  All routes with no distinguished attributes are re-distributed to
          every neighbor RD; hierarchical recording is desired to limit

   Kunzinger                     ISO/IEC 10747                 [ Page 257 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   +----------------------------------------------------------------------+
   |                                                                      |
   |                            \   /                                     |
   |   Transit Domains:          \ /                                      |
   |      1, 2, 3, 5, 6, 7      +---+      +---+     +---+                |
   |                            | 1 |------| 2 |-----| 4 |                |
   |                            +---+      +---+     +---+                |
   |   Stub Domains:              |          |                            |
   |      4, 8                    |          |                            |
   |                              |          |                            |
   |                            +---+      +---+     +---+                |
   |                            | 3 |------| 5 |-----| 8 |                |
   |                            +---+      +---+     +---+                |
   |                             / |                                      |
   |                            /  |                                      |
   |                           /   |                                      |
   |                          /    |                                      |
   |                         /     |                                      |
   |                      +---+  +---+                                    |
   |                      | 6 |  | 7 |                                    |
   |                      +---+  +---+                                    |
   |                       /        \                                     |
   |                      /          \                                    |
   |                     /            \                                   |
   |                                                                      |
   |                                                                      |
   +----------------------------------------------------------------------+
   Figure 13. A Portion of an Internet

          distribution of all of these routes (the specific RDC membership
          information is irrelevant for this example).

      f)  Any route (default or CAPACITY) which pass through transit RD#9
          (not pictured) can only be redistributed to some domains (RD#2,
          RD#5, RD#8).

      g)  All routes carrying NLRI of the address space controlled by
          domain #3 (XX:YY:3:*) will be aggregated (regardles    s whether
          or not aggregated routes include NLRI for all of this space).  In
          addition, routes carrying NLRI for RD#5 NSAPs (XX:YY:3    :5:*)
          will be announced separately.  All routes for default dist_atts
          will be aggregated algorithmically.  A "default route" (zero
          length NSAP) will be advertised for CAPACITY QOS routes (although
          distribution of this route will be limited to particular domains,
          i.e. RD#5, by the select/modify policy section).

   Kunzinger                     ISO/IEC 10747                 [ Page 258 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   L.3.2  Policy configuration example

      The following is one example of an expression of the above policies
      using this configuration language.  The next subclause examines and
      discusses each line of this configuration example in detail.

      This example assumes that the policy language is case insensitive.

       PREF {nlri_any} / .* 6 / (CAPACITY security_none priority_none)

       (CAPACITY() > 15) = 50;

       PREF {nlri_any} / .* 1 / dist_att_none = 255 - hopcount();

       PREF {nlri_any} /.*/     dist_att_none = 245 - hopcount();

       AGGR {XX:YY:3:5:*} /.*/ dist_att_none  = man;

       AGGR {XX:YY:3:*}   /.*/ dist_att_none  = man;

       AGGR {nlri_any}    /.*/ dist_att_none  = auto;

       AGGR {nlri_any}  /.*/ (CAPACITY security_none priority_none) = man;

       DIST {nlri_any}   /.* 9 .*/ =

       modify {allow_dist({RD#2, RD#5, RD#8});} CONT;

       DIST {nlri_any}  /.* 6/ (CAPACITY security_none priority_none)

       CAPACITY() > 15) = {BIS#5} select_only {allow_dist(RD#5, RD#8);};

       DIST {nlri_any} /.*/  = select_on {init_hr();};

   L.3.3  Discussion

      Each policy statement given in subclause L.3.2 is discussed.  In most
      cases, the optional parts of the BNF have been omitted if the default
      action is appropriate to represent the example policy.  For brevity,
      these defaults will be mentioned in the discussion only once, at the
      statement where they are first encountered.


   Kunzinger                     ISO/IEC 10747                 [ Page 259 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

   L.3.3.1  Preference statement discussion

      Recall that the sequence of statements is significant for determining
      the application and processing of all types of policy statements.
      Preference statements are the least complex of the three; routes are
      simply assigned the preference associated with the first <route
      pattern> that is matched (the other statements' processing and
      application sequence are discussed later in this text).

      The first PREF statement matches routes to any destination, indicated
      by {nlri_any}.  No token for information source is present, so by
      default only routes where the information source was IDRP are matched
      (i.e. routes where no EXT_INFO attribute is present).  The third
      expression "/ .* 6 /" matches any RD_PATH attribute where the last
      "hop" was from RD#6.

        PREF {nlri_any} / .* 6 / (CAPACITY security_none priority_none)
         (CAPACITY() > 15) = 50;

      The 3-tuple (CAPACITY security_none priority_none) indicates a route
      is to match if it corresponds to the RIB_ATT which has CAPACITY QOS,
      no security, and no priority.  Finally, the attribute conditions only
      allow routes with CAPACITY attribute greater than 15 to be matched.
      There are no local conditions to be considered, so nothing is
      specified and by default routes are matched under any local
      conditions.  Note that none of the actions in this example are
      dependent on local conditions, so this will be ignored for the rest
      of the example.  Routes matched by this pattern are simply assigned a
      preference of 50.

      The second PREF statement also matches routes to any destination, if
      the routing information source was IDRP.  The statement matches
      routes received directly from RD#1, by examining the route's RD_PATH
      attribute.  The "dist_att_none" is specified, so only routes which
      have no QOS attribute, no priority attribute, and no security
      attribute will be matched.  There are no other attribute or local
      conditions to meet, which is the default if nothing is specified.

       PREF {nlri_any} / .* 1 / dist_att_none = 255 - hopcount();

      This statement assigns a route preference based on the HOP_COUNT
      value plus a constant.  The constant (255) is relatively "good"
      (relative to 245 in the next statement) so that routes through RD#1
      are preferred (per policy C above).  Since routes will be assigned
      preference by the the first <route pattern> matched, a path through

   Kunzinger                     ISO/IEC 10747                 [ Page 260 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      RD#1 matching this pattern will not have a value assigned by the next
      statement, even though it has a more general <route pattern> and also
      would be a correct match.

      The next PREF statement matches any route with no distinguished
      attributes, again, only if the information source was IDRP.

        PREF {nlri_any} /.*/     dist_att_none = 245 - hopcount();

      Routes matching this pattern are assigned a preference based on the
      hop count and a relatively "bad" constant (245), so that these routes
      are preferred less than routes through RD#1 (which match a previous
      PREF statement).

      Examining the last two preference statements, per policy C routes
      through RD#1 are preferred unless the path length (hop count) is
      worse (by ten hops or more).

   L.3.3.2  Aggregation statement discussion

      Aggregation statements are also processed in the order that they
      appear, however, their processing and application is not simply based
      on first match.  An AGGR statement may be marked with "CONT" to
      indicate that the aggregate route may act as a component for
      subsequent AGGR statements.  Alternatively, "DONE" indicates that an
      aggregate should be installed/advertised, and not considered in
      further aggregation processing.

      The first aggregation statement matches routes with a specific set of
      destinations, {XX:YY:3:5:*}, and announces the aggregate route with
      manually configured NLRI.  The longest common NLRI prefix specified
      is XX:YY:3:5, so this will serve as the NLRI for the aggregate route.
      Using "manual" aggregation, this aggregate is instantiated whether or
      not the NLRI of the matched component routes include all destinations
      implied by the prefix XX:YY:3:5.

        AGGR {XX:YY:3:5:*} /.*/ dist_att_none = man;

      Any number of routes may match this pattern, and are replaced by a
      single aggregate route.  No recipient <bis> are specified, so by
      default the aggregate route (rather than the components) is announced
      to all external BIS neighbors.  The default action, "DONE", requires
      that the aggregate route be distributed without undergoing further
      aggregation.  Hence, routes to these destination NSAPs are announced

   Kunzinger                     ISO/IEC 10747                 [ Page 261 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      separately from the rest of the XX:YY:3:* NSAPs (which are aggregated
      below).

      The second AGGR statement is almost identical to the first.

        AGGR {XX:YY:3:*} /.*/ dist_att_none  = man;

      Routes to a specific set of NSAPs are matched and aggregated; these
      destinations are a superset of those matched by the previous AGGR
      statement.  This construct (two AGGR statements with overlapping
      NLRI) can be used to make certain that particular longer prefixes are
      announced separately from a more general aggregate prefix.

      The third aggregation statement matches routes to any destination,
      with any RD_PATH, with no distinguished attributes, and no additional
      attribute or local conditions.

        AGGR {nlri_any} /.*/ dist_att_none = auto;

      These routes are to be aggregated automatically; that is safely and
      algorithmically such that the aggregated NLRI does not include more
      NSAPs than the component routes did.  By default, this statement
      affects the routes that are announced to all external BIS neighbors.

      The fourth AGGR statement matches routes to any destination, with any
      RD_PATH, if they have distinguished attributes that include only
      CAPACITY QOS.

        AGGR {nlri_any}  /.*/ (CAPACITY security_none priority_none) = man;

      Manual aggregation will use the longest common prefix of the
      specified NLRI as the aggregate route's NLRI.  This statement matches
      routes to any destination, so the aggregate NLRI is a "default" route
      (route with zero length NLRI).

   L.3.3.3  Distribution statement discussion

      Distribution statements are the most complex of the policy
      statements; they control both the selection and modification of
      routes for re-distribution.  DIST statement processing is sequential,
      and like the AGGR statement, "CONT" and "DONE" affect the processing
      of a route by policy statements.  If a DIST statement specifies
      "DONE", routes will not be affected by any subsequent DIST
      statements.  A "CONT" token indicates that routes should be affected

   Kunzinger                     ISO/IEC 10747                 [ Page 262 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      by the next DIST statement that is matched.  Using the idea of
      increasingly or decreasingly specific <route pattern> templates in
      combination with "DONE" and "CONT" to selectively prohibit further
      processing of some routes, a wide range of policy requirements can be
      concisely expressed.

      The first DIST statement from the example matches routes to any
      destination, originated by IDRP (the default match), where RD#9 is in
      the RD_PATH.  These routes can have any distinguished attribute set
      (any distinguished attribute is the default match), and no additional
      attribute or local conditions need to be satisfied.

        DIST {nlri_any}   /.* 9 .*/ =
         modify {allow_dist({RD#2, RD#5, RD#8});} CONT;

      This statement does not indicate a <bis> list, so by default all
      external BIS neighbors' Adj-RIBs-Out are affected by this statement.
      The "modify" indicates that route attributes are to be modified, but
      the route's "selected status" will remain unchanged by this DIST
      statement.  One modification is performed which restricts the
      distribution of these routes (per policy F above) by altering the
      DIST_LISTs to only allow certain domains to receive this route.  The
      statement indicates "CONT", so these routes may be further modified,
      and/or selected for distribution to adjacent BIS, by subsequent DIST
      statements.

      The second DIST statement matches routes to any destination with
      distinguished attributes (CAPACITY security_none priority_none).

        DIST {nlri_any}  /.* 6/ (CAPACITY security_none priority_none)
         (CAPACITY() > 15) = {BIS#5} select_only {allow_dist(RD#5, RD#8);};

      The {BIS#5} indication along with "select_only" specifies that the
      matched routes are to be selected for distribution only to BIS#5; an
      additional effect of "select_only" is to explicitly mark these routes
      as NOT distributable to  all other BISs (all but BIS#5).  The default
      action, "DONE", will keep these routes from being affected by other
      DIST statements.  The "DONE" combined with the "select_only" will
      also prevent these routes from being matched and possibly placed in
      the RIB-OUT for distribution to other BISs (i.e. other than BIS#5).
      Using the "allow_dist()" function, this statement modifies the
      DIST_LISTs of matched routes to restrict further redistribution to
      domains RD#5 and RD#8.


   Kunzinger                     ISO/IEC 10747                 [ Page 263 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      The third DIST statement matches routes to any destination, with any
      RD_PATH; these routes can have any distinguished attributes, and no
      additional attribute or local conditions need to be satisfied.

        DIST {nlri_any} /.*/  = select_on {init_hr();};

      The Adj-RIBs-Out for all neighboring BISs are affected by this
      statement, which selects the matched routes for distribution
      ("select_on") and modifies the hierarchical recording attribute so it
      is initialized to "1" (only if the attribute is not already present
      and thus can be initialized according to operational procedures).

   L.3.3.4  Operational example

      Consider a route with the following attributes that arrives at our
      BIS configured with the above Policy Information Base (PIB):

        nlri(10:66:*) rd_path(6 22 10) hopcount(15)

      It is a route with no distinguished attributes, which matches only
      one of the PREF statement route patterns:

        PREF {nlri_any} /.*/  dist_att_none

      and is assigned a preference of 230 (245-hopcount()) by the this PREF
      statement.  Consider a second route to the same destination NLRI with
      attributes:

        nlri(10:66:*) rd_path(1 44 9 16 10) hopcount(20)

      It also has no distinguished attributes.  It matches two PREF route
      patterns, however, only the first match is considered (first match).

        PREF {nlri_any} idrp /.* 1/  dist_att_none

      Because the route is through RD#1 it is a preferred route, and is
      assigned a preference of 235 (255-hopcount()).  Both of these two
      routes are for the same set of destination NLRI; the second route,
      with preference value of 235 would be chosen over the route with
      preference value 230.  If these were the only two routes to these
      destinations, the preferred route would be installed in our LOC_RIB
      and FIB.


   Kunzinger                     ISO/IEC 10747                 [ Page 264 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Now aggregation policy must be considered to see how the route is to
      be announced.  The preferred route that was placed in the LOC_RIB:

        nlri(10:66:*) rd_path(1 44 9 16 10) hopcount(20)

      matches one AGGR statement route pattern, which specifies automatic
      aggregation for those routes where it is possible:

        AGGR {nlri_any} /.*/ dist_att_none = auto;

      Depending on what other routes and aggregates are installed, this
      route may be announced individually, may result in a new aggregation,
      or it may be part of an already instantiated aggregate.  For
      instance, if there is already an (aggregate) route to nlri(10:*), the
      example route could be included in the nlri(10:*) aggregate; the
      example route would be installed in the LOC-RIB and FIB (so packets
      are forwarded correctly), and then a new aggregate (made up of this
      route and the old aggregate) would be composed.  If a new aggregate
      were to be generated, a new preference value would be assigned by the
      PREF policy statement processing.  Whether this route is aggregated
      with other routes, or maintained individually, it must be selected by
      a DIST statement before it will be announced.

      Assuming that there is no aggregate for this route, it is installed
      in the LOC-RIB and FIB as-is, and must be considered for
      redistribution.  Again, the route:

        nlri(10:66:*) rd_path(1 44 9 16 10) hopcount(20)

      is matched against route patterns.  It matches the first DIST
      statement:

        DIST {nlri_any} /.* 9 .*/ =
         modify {allow_dist({RD#2, RD#5, RD#8});} CONT;

      which requires the route be modified before it is re-distributed.
      Applying the modifications the route becomes:

       nlri(10:*) rd_path(1 44 9 16 10) dist_list_incl(2,5,8) hopcount(20)

      Since this DIST statement does not terminate distribution processing,
      ("CONT"), other DIST statements may be matched.  At this point the
      route has been modified, but has not been selected for distribution
      ("modify" rather than "select_on" or "select_only" was specified).
      The route also matches the following DIST statement:

   Kunzinger                     ISO/IEC 10747                 [ Page 265 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

        DIST {nlri_any} /.*/ = select_on {init_hr();};

      which modifies the route (initializing the HIERARCHICAL_RECORDING
      attribute since it's not already set), and selects the route for
      distribution (to all external BIS neighbors).  This DIST statement
      (by default) specifies "DONE", so no further distribution processing
      is applied to this route.  Note that other changes to the route
      attributes (i.e. update of RD_PATH) will be performed as part of
      "operational processing".  h4 id=defxmp.Simple Default Policy

      Among the concerns about configuring administrative policy is ease of
      configuration for the majority of domains which may have very simple
      policy.  A simple policy configuration must include a preference
      statement:

      (Assign a preference to all routes based on the number of hops.)

        PREF {nlri_any} / .*/ = 255 - hopcount();

      If the routing domain will carry transit traffic, then the following
      minimal aggregation and distribution statements are also needed:

      (Automatic aggregation to reduce the amount of information.)

        AGGR {nlri_any} / .*/ = auto;

      (Select all routes for distribution; no modifications.)

        DIST {nlri_any} / .*/ = select_on;

      This illustrates that the configuration of the policy information
      base does not necessarily have to be extensive or complex.  A complex
      configuration will be the case only to the extent that the domain's
      administrative policy has extensive requirements and specifications.





   Kunzinger                     ISO/IEC 10747                 [ Page 266 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      Index


         +---+                            authentication  39, 44, 87, 88,
         | A |                             89, 150, 151, 224
         +---+                            authenticationTypeCode  175

      Adj-RIB-In  24, 27, 28, 41, 65,
       95, 96, 100                           +---+
         and withdrawn routes  137           | B |
         as used by Decision                 +---+
          Process  128--136
         default identified by Empty      bisNegotiatedVersion  175
          RIB-Att  97                     bisNet  175
         solicited refresh of  99         BISPDU  37--65
         unsolicited refresh of  99       BISPDU fixed header  37
         updating by Update-Receive       bisPeerSNPAs  175
          process  126                    bisRDC  175
         validation of  97                bisRDI  176
      Adj-RIB-Out  24, 27, 28, 41, 65,    boundary IS
       95, 96, 100, 138                      definition  19
         and information reduction  141   breaking ties  138
         and route aggregation  142
         and withdrawn routes  137
         as used by Decision                 +---+
          Process  128--136                  | C |
         default identified by Empty         +---+
          RIB-Att  97
         validation of  97                CAPACITY  59, 123, 146, 176
      adjacentBIS  168                    CEASE PDU  65, 76, 84, 85, 87,
      adjacentBISPkg  173                  149, 156
      administrative domain  14           checksum
      advertisement intervals for            algorithm for generation  218
       routes  139, 140                      encrypted, in BISPDU
      aggregating routes                      header  88, 224
         See route aggregation               field in BISPDU header  39
      architectural constants  165           for RIB validation  97
                                             in BISPDU header  150


   Kunzinger                     ISO/IEC 10747                 [ Page 267 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      checksum (continued)                distinguishing attributes
         unencrypted, in BISPDU              derived from NPDU  158
          header  88                            matching with RIB-Att  160
      CLOSE-WAIT State  86--87               distinguishing path attributes
      CLOSED State  74--75                    in UPDATE PDU  28
      CloseWaitDelay  76, 84, 86, 90,           as identifier of RIBs and
       91                                        FIBs  96
      closeWaitDelayTimer  176                  type specific  104
      closing a BIS-BIS connection  87          type-value specific  104
      confederations                         equivalence of  104
         See RDC (Routeing Domain            origination and update  103
          Confederation)                     permissible sets of  103
      configuration information  69
      conformance
       requirements  193--196                +---+
      connection management between          | E |
       BISs  73--87                          +---+
      connectionRequested  171
      connectRequestBISUnknown  171       empty RIB-Att  41
      CorruptAdjRIBIn  170                encryption  224
                                          EnterFSMState  172
                                          EnterFSMStateMachine  171
         +---+                            ENTRY_SEQ  49, 107, 108, 109, 143
         | D |                            ENTRY_SET  49, 107, 108, 109,
         +---+                             143, 146
                                          error codes and subcodes  61
      decision process                    error handling  149
         overview of three phases  129    errorBISPDUconnectionclose  169
         phase 1  130                     errorBISPDUsent  168
         phase 2  130                     ESTABLISHED State  85--86
         phase 3  133                     EXPENSE  55, 119, 145, 160
      degree of preference  25, 128,      EXT_INFO  49, 106, 143
       130, 132                           external updates  138
      deployment guidelines               externalBISNeighbor  69, 72, 176
         for ESs and ISs  68
         for RDs  68
      DIST_LIST_EXCL  53, 115, 116,
       142, 145
      DIST_LIST_INCL  52, 115, 116,
       142, 145



   Kunzinger                     ISO/IEC 10747                 [ Page 268 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         +---+                               +---+
         | F |                               | I |
         +---+                               +---+

      finite state machines  73--87       IDRP ERROR PDU  61
      flow control of BISPDUs  91         idrpConfig  168
      Forwarding Information Base         idrpConfigID  177
       (FIB)  24, 27, 28, 29, 138         idrpConfigPkg-P  168
         default identified by Empty      inter-domain link
          RIB-Att  97                        definition  18
         maintenance of  148                 real links and inter-domain
         validation of  97                    traffic  18
      forwarding of NPDUs                    virtual links and inter-domain
         and NPDU-derived                     traffic  18
          Distinguishing                     virtual links and intra-domain
          Attributes  157                     traffic  18
         to external destinations  162    internal updates  136
         to internal destinations  158    internalBIS  69, 72, 177
      FSM error  74                       internalSystems  70, 106, 177
      FSMStateChange  172                 intra-domain routeing
                                           protocol  11, 18, 35, 69
                                          intraIS  69, 178
         +---+                            ISO/IEC 10589  26
         | G |                            ISO/IEC TR 9577  60
         +---+

      GDMO descriptions  167--193            +---+
                                             | J |
                                             +---+
         +---+
         | H |                            jitter  140, 228
         +---+

      header of BISPDU  37
      HIERARCHICAL_RECORDING  57, 121
      hold time
         of OPEN PDU  40
      holdTime  176
      holdTimer  177



   Kunzinger                     ISO/IEC 10747                 [ Page 269 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         +---+                               +---+
         | K |                               | M |
         +---+                               +---+

      KEEPALIVE PDU  64, 156              maxCPUOverloadTimer  180
      keepAlivesSinceLastUpdate  178      maxPDULocal  180
      keepAliveTimer  178                 maxPDUPeer  180
                                          maxRIBIntegrityCheck  97, 98, 181
                                          maxRIBntegrityTimer  181
         +---+                            MinBISPDULength  38, 41, 151
         | L |                            MinRDOriginationInterval  140
         +---+                            minRDOriginationTimer  181
                                          minRouteAdvertisementInterval  139,
      lastAckRecv  178                     140, 181
      lastAckSent  178                    minRouteAdvertisementTimer  182
      lastPriorSeqNo  179                 more specific routes  134
      lastSeqNoRecv  179                  MULTI-EXIT_DISC  54, 117, 142,
      lastSeqNoSent  179                   239
      less specific routes  134           multi-homed end routeing
      ListenForOPEN  74, 179               domain  19
      Loc-RIB  24, 27, 28, 95, 96, 100,   multiExit  117, 132, 182
       148                                multiple routes in an UPDATE PDU
         as used by Decision                 distinguishing attributes of
          Process  128--136                   individual route  105
         default identified by Empty         LOCAL_PREF of individual
          RIB-Att  97                         route  105
         validation of  97                   non-distinguishing attributes
      LOCAL_PREF  48, 128, 143                of individual route  105
      LOCALLY DEFINED QOS  55, 120,          ROUTE_ID of individual
       145, 160                               route  105
      localRDI  70, 125, 179                 ROUTE_SEPARATOR as
      localSNPA  149, 180                     delimiter  29, 48, 105
      locExpense  119, 180                   selecting information base for
      LSAP  51, 60                            individual route  29





   Kunzinger                     ISO/IEC 10747                 [ Page 270 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         +---+                            NSAP Addresses
         | N |                               syntax and encoding  34
         +---+

      naming and containment                 +---+
       hierarchy  167                        | O |
      neighbor BIS  33, 72                   +---+
       NET (Network entity title)
         syntax and encoding  34          OPEN PDU  40, 150
      network layer reachability          OPEN-RCVD State  83--85
       information                        OPEN-SENT State  75--76
         as encoded in UPDATE PDU  59     OpenBISpduRDCError  169
         as related to configuration      origination intervals for
          information  70                  routes  140
         information reduction of  141    outstandingPDUs  182
      NEXT_HOP  50, 111, 142              overlapping routes  134
      NLRI                                overload conditions
         See network layer reachability      processor overload  233
          information                        RIB overload  231
      Non-transitive attribute  47
      notificationBISerrorsubcode  168,
       169, 186                              +---+
      notificationBISPDUerrorcode  168,      | P |
       169, 185                              +---+
      notificationBISPDUerrorinfo  168,
       169, 186                           packet bomb  72
      notificationLocalRDCConfig  169,    PacketBomb  170
       186                                partial bit  47
      notificationRemoteBISNET  168,      passive opening of BIS-BIS
       169, 170, 172, 185                  connection
      notificationRemoteRDCConfif  169       See ListenForOPEN
      notificationRemoteRDCConfig  186    password text, untransmitted  89
      notificationRIBIntegrityFailure  170path attributes
       186                                   See also individual attributes
      notificationSourceBISNET  170,         aggregation rules  143--146
       171                                   as identifier for a FIB  28
      notificationSourceBISrdc  170,         as identifier for a RIB  28
       171, 187                              as part of a route  27
      notificationSourceBISrdi  170,         categories of  102
       171, 187                              encoding in UPDATE PDU  47--59
                                             usage rules  105--124


   Kunzinger                     ISO/IEC 10747                 [ Page 271 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      policy, routeing                    RDC (Routeing Domain
         detecting inconsistencies  25,    Confederation) (continued)
          128                                and HIERARCHICAL RECORDING
            external                          attribute  121
             inconsistencies  128            associated managed object  70
            internal                         boundary of  126
             inconsistencies  128            configuration information
         indirect expression in UPDATE        for  125
          PDUs  25                           definition  20
         local setting of  25                disjoint  20, 121
         policy information base             entering a confederation  121,
          (PIB)  20, 26, 128, 145, 146        126
         syntax and semantics                exiting a confederation  121,
          of  244--266                        126
      positioning of IDRP                    formation and deletion
         with respect to ISO 8473  11         of  234, 242
         within the Network layer  11,       in OPEN PDU  43
          23                                 nested  20, 107, 108, 109, 121
      PRIORITY  59, 124, 146, 182            overlapping  20, 107, 108, 109
                                             permissible policies of  125
                                             recursive nature of  27
         +---+                               updating the RD_PATH attribute
         | Q |                                on entry or exit  107, 108,
         +---+                                109
                                             use of RDI to identify  27, 33
      quality of service (QOS)            rdcConfig  107, 108, 109, 125,
         See LOCALLY DEFINED QOS           126, 183
                                          RDI (routeing domain identifier)
                                             as encoded in RD_PATH
         +---+                                attribute  49
         | R |                               conformance to ISO 8348  33
         +---+                               in updated RD_PATH
                                              attributes  107, 108, 109
      RD_HOP_COUNT  57, 122                  syntax and encoding  34
      RD_PATH  49, 107, 143, 146, 147     rdLRE  118, 183
         as encoded in UPDATE PDU  49     rdTransitDelay  118, 183
      RD_SEQ  49, 107, 108, 109, 143      real link
      RD_SET  49, 107, 108, 109, 143,        See inter-domain link
       147                                RESIDUAL ERROR  55, 118, 145, 160
      RDC (Routeing Domain                retransmissionTime  183
       Confederation)  20, 27, 125


   Kunzinger                     ISO/IEC 10747                 [ Page 272 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

      RIB REFRESH PDU  65, 99, 156        routeServer  114, 184
      RIB-Attributes (RIB-Att)  27, 29,
       96, 100, 148, 151, 153
         as coded in OPEN PDU  41            +---+
         as identifier for information       | S |
          bases  28                          +---+
         empty RIB-Att  41, 97
         in RIB REFRESH PDU  65           SECURITY  57, 123, 146, 160
         matching to NPDU-derived         sequence numbers of BISPDUs  90
          distinguishing attribute  160   size of BISPDUs
         type specific  43                   maximum, of OPEN PDU  38, 40
         type-value specific  43             of the entire BISPDU  38
         validity  103                    state  184
      RibAttsSet  41, 70, 96, 97, 151,    stub end routeing domain  19
       184                                supplyOnCreate-B  187
      route aggregation
         of NLRI  143
         of path attributes  142--143        +---+
         of the RD_PATH                      | T |
          attribute  143--147                +---+
      ROUTE-ID  48, 105, 143
      ROUTE_SEPARATOR  48, 128, 143       tie breaking  132
      routeing domains                    totalBISPDUsIn  184
         adjacent (definition)  19        totalBISPDUsOut  184
         as part of global OSIE  25       TR 9575 (Routeing Framework)  11,
         end routeing domain  19, 27       23
         transit routeing domain  19,     TRANSIT DELAY  55, 118, 145, 160
          27                              transitive attribute  47
      routeing information bases
         See Adj-RIB-In
         See Adj-RIB-Out
         See Loc-RIB
         See RIB-Attributes (RIB-Att)
      routeing policy
         See policy, routeing
      routes
         as expressed in UPDATE PDU  45
         definition of  27
         destinations  27
         path attributes  27



   Kunzinger                     ISO/IEC 10747                 [ Page 273 ]

   October 1993      Inter-Domain Routing Protocol (IDRP)          RFC 14xx

         +---+
         | U |
         +---+

      UPDATE PDU  45, 152
      updatesIn  185
      updatesOut  185

         +---+
         | V |
         +---+

      validation of BISPDUs  87
      version  185
      version negotiation  95
      virtual link
         See inter-domain link

         +---+
         | W |
         +---+

      withdrawing routes from
       service  45, 46, 126







   Kunzinger                     ISO/IEC 10747                 [ Page 274 ]