[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                                      Yakov Rekhter
Internet Draft                                       Cisco Systems, Inc.
                                                             Paul Traina
                                                  Juniper Networks, Inc.
Expiration Date: January 1997                                  June 1996


                Inter-Domain Routing Protocol, Version 2

                      draft-ietf-idr-idrp2-00.txt


1. 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
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).



2. Introduction

   The Inter-Domain Routing Protocol (IDRP) permits a routing domain to
   exchange information with other routing domains to facilitate the
   operation of the routing and relaying functions of the Network Layer.


   This protocol calculates path segments which consist of Boundary
   Intermediate systems (BIS aka border routers) and the links that
   interconnect them. A packet destined for an end system in another
   routing domain will be routed via Intra-domain routing to a Boundary
   Intermediate system in the current routing domain. Then, the BIS,
   using the methods of this inter-domain routing protocol, will
   calculate a path to a Boundary Intermediate system in an adjacent
   routing domain lying on a path to the destination. After arriving at
   the next routing domain, the packet may also travel within that



Yakov Rekhter, Paul Traina                                      [Page 1]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   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
   packet arrives at a BIS in the routing domain which contains the
   destination End system. The Boundary IS in this routing domain will
   hand the incoming NPDU over to the domain's intra-domain routing
   protocol, which will construct a path to the destination End system.

   Inter-domain routing protocols place requirements on the type of
   information that a routing domain must provide and on the methods by
   which this information will be distributed to other routing domains.
   These requirements are intended to be minimal, addressing only the
   interactions between Boundary ISs; all other internal operations of
   each routing domain are outside the scope of this protocol. That is,
   this Inter-domain routing protocol does not mandate that a routing
   domain run a particular intra-domain routing protocol.

   The methods of this protocol differ from those generally adopted for
   an intra-domain routing 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 routing policies. IDRP may
   be used when routing domains do not fully trust each other; it
   imposes no upper limit on the number of routing domains that can
   participate in this protocol; and it provides isolation between its
   operations and the internal operations of each routing domain.


3. Scope

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


   This document specifies:


      - the procedures for the exchange of inter-domain reachability and
      path information between BISs

      - the procedures for maintaining inter-domain routing information
      bases within a BIS

      - the encoding of protocol data units used to distribute inter-
      domain routing information between BISs



Yakov Rekhter, Paul Traina                                      [Page 2]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996



       +--------------+   +------------------+         +--------------+
       | End Routing  |   | Transit Routing  |         | End Routing  |
       |   Domain     |   |      Domain      |         |    Domain    |
       +--------------+   +------------------+         +--------------+
              |                   /  |     |                 /
              |                  /   |     |                /
              |                 /    |     |               /
              |                /     |     |              /
            +------------------+     |   +------------------+
            | Transit Routing  |     |   | Transit Routing  |
            |      Domain      |     |   |      Domain      |
            +------------------+     |   +------------------+
                    /      |         |             |
                   /       |         |             |
                  /        |         |             |
       +--------------+  +------------------+      |
       | End Routing  |  | Transit Routing  |      |
       |   Domain     |  |      Domain      |      |
       +--------------+  +------------------+      |
                                  |                |
                                  |                |
                                  |                |
                           +--------------+   +--------------+
                           | End Routing  |   | End Routing  |
                           |   Domain     |   |   Domain     |
                           +--------------+   +--------------+
                                     |              /
                                     |             /
                                     |            /
                                 +------------------+
                                 | Transit Routing  |
                                 |      Domain      |
                                 +------------------+


   Figure 1. Field of Application. The Inter-domain Routing Protocol
             operates between routing domains; intra-domain routing is
             not within its scope.

   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




Yakov Rekhter, Paul Traina                                      [Page 3]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      - constraints on policy feasibility and enforcement which must be
      observed by each Boundary Intermediate system in a routing domain

   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 document operates at
   the level of individual routing domains. The establishment of
   administrative domains is outside the scope of this standard.




4. Definitions

   For the purposes of this document, the following definitions apply.


4.1. Intra-domain routing protocol

   A routing protocol that is run between Intermediate systems in a
   single routing domain to determine routes that pass through only
   systems and links wholly contained within the domain.



4.2. Inter-domain link

   A real (physical) or virtual (logical) link between two or more
   Boundary Intermediate systems. A link between two BISs in the same
   routing domain carry both intra-domain traffic and inter-domain
   traffic; a link between two BISs located in adjacent routing domains
   can carry inter-domain traffic, but not intra-domain traffic.


4.3. Boundary Intermediate system

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


4.4. End Routing Domain

   A routing domain whose local policies permit its BISs to calculate
   inter-domain path segments only for PDUs whose source is located
   within that routing domain. There are two varieties of End routing
   domains: stub and multi-homed. A stub ERD has inter-domain links to



Yakov Rekhter, Paul Traina                                      [Page 4]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   only one adjacent routing domain, while a multi-homed ERD has inter-
   domain links to several adjacent routing domains.



4.5. Transit Routing Domain

   A routing domain whose policies permit its BISs to calculate inter-
   domain path segments for PDUs whose source is located either in the
   local routing domain or in a different routing domain. That is, it
   can provide a relaying service for such PDUs.


4.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.


4.7. RD Path

   A list of the RDIs of the routing domains and routing domain
   confederations through which a given UPDATE PDU has travelled.


4.8. Routing Domain Confederation

   A set of routing domains which have agreed to join together and to
   conform to the rules in 8.13 of this document. To the outside world,
   a confederation is indistinguishable from a routing domain.


4.9. Nested RDCs

   A routing 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










Yakov Rekhter, Paul Traina                                      [Page 5]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


4.10. Overlapping RDCs

   A routing 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.



4.11. Disjoint RDCs

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


4.12. Policy Information Base

   The collection of routing policies that a BIS will apply to the
   routing information that it learns using the protocol described in
   this document. It is not required that all routing 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.


4.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.















Yakov Rekhter, Paul Traina                                      [Page 6]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


5. Symbols and abbreviations


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


5.1. Data unit abbreviations

   BISPDU Boundary Intermediate System PDU (IDRP message)

   NPDU    Network Protocol Data Unit (IPv4 or IPv6 packet)

   PDU     Protocol Data Unit (a packet)



5.2. Addressing abbreviations


   SNPA    Subnetwork Point of Attachment (data link address)



5.3. Other abbreviations

   BIS     Boundary Intermediate System (border router)

   CM      Confederation Member

   ERD     End Routing Domain

   ES      End System

   FIB     Forwarding Information Base

   FSM     Finite State Machine

   IDRP    Inter-domain Routing Protocol (an acronym for the protocol
   described in this document)

   IS      Intermediate System (router)

   MIB     Management Information Base

   NLRI    Network layer reachability information (set of reachable
   destinations)




Yakov Rekhter, Paul Traina                                      [Page 7]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   PIB     Policy Information Base

   RDC     Routing Domain Confederation

   RDI     Routing Domain Identifier

   RIB     Routing Information Base

   TRD     Transit Routing Domain



6. General protocol information

   IDRP uses IP (either v4 or v6) as its transport protocol. In
   particular, BISPDUs are encapsulated as the data portion of IP
   packets.

   IDRP is a connection-oriented protocol which is implemented only in
   Intermediate systems.  Routing and control information is carried in
   BISPDUs (as specified in Section 7 ), 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 8.7 ; methods
   for establishing BIS-BIS connections are described in 8.6

   To emphasize its policy-based nature, the IDRP routing model includes
   a Policy Information Base.

   IDRP can be described in terms of following major components:


      a) BISPDU-Receive Process:

         responsible for accepting and processing control and routing
         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



Yakov Rekhter, Paul Traina                                      [Page 8]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         Update-Receive process (see 8.14 ) is the part of the BISPDU-
         Receive process that deals with the reception of routing
         information after a BIS-BIS connection has been established.)

      b) BISPDU-Send Process:

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

      c) Decision Process:

         responsible for calculating routes which will be consistent
         with local routing 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 8.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.



6.1. Inter-RD topology

   This protocol views an internet as an arbitrary interconnection of
   Transit Routing Domains and End Routing Domains which are connected
   by real inter-domain links placed between BISs located in the
   respective routing domains. This standard provides for the direct
   exchange of routing information between BISs, which may be located
   either in the same routing domain or in adjacent routing domains.


6.2. Routing 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.

   Each routing domain chooses its routing policies independently, and
   insures that all its BISs calculate inter-domain paths which satisfy
   those policies. Local routing policies are applied to information in



Yakov Rekhter, Paul Traina                                      [Page 9]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   the Routing Information Base (RIB) to determine a degree of
   preference for potential paths (see 8.15 ). From those paths which
   are not rejected by the routing 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 routing policies and to insure that policies are both
   feasible and consistent, this protocol:

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

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

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

      - permits each routing 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.


6.3. Types of systems

   An Intermediate system that implements the protocol described in this
   document is called a Boundary Intermediate system (BIS). Each BIS
   resides in a single routing domain, and may optionally act
   simultaneously as a BIS and as an intra-domain IS within its own
   routing domain.



6.4. Types of routing domains

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










Yakov Rekhter, Paul Traina                                     [Page 10]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


6.5. Routing domain confederations

   IDRP provides support for Routing Domain Confederations (RDCs); this
   optional function permits groups of routing 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 routing domains or routing domain
   confederations. Thus, the definition of an RDC is recursive: a
   confederation member may be a single routing domain or another
   confederation.


6.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 address matches address
      prefixes 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 Routing 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 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-Tag (see 6.7 and 6.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.

   IDRP also provides mechanisms by which a BIS can inform its neighbor
   that a previously advertised route is no longer available for use.



Yakov Rekhter, Paul Traina                                     [Page 11]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   There are three methods by which a given BIS can indicate that a
   route has been withdrawn from service:

      a) the NLRI 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 FIB-Tag 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.



6.7. RIB-Tag

   Each RIB-Tag identifies a particular information base which will be
   used to store information about the route. The RIB-tag 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-tags is limited by local decisions - a BIS may
   choose to support only a limited number of RIB-tags.


6.8. Selecting the information bases

   Each RIB is identified by a RIB-Tag, and the same RIB-Tag also
   uniquely identifies the associated FIB.

   For an UPDATE PDU, the BIS determines the RIB-Tag, and the LOCAL_PREF
   associated with each route that is advertised.

   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-Tag, which then unambiguously identifies a
   particular FIB.

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










Yakov Rekhter, Paul Traina                                     [Page 12]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996



      +----------------------------------------------------------------------+
      | Table 1  The IDRP Information Bases.  The indexing                   |
      |          variables and contents of the RIBs and FIBs                 |
      |          are shown.                                                  |
      +-----------------+-----------------+----------------------------------+
      | Information     | Indexed by...   | Contains...                      |
      | Base            |                 |                                  |
      +-----------------+-----------------+----------------------------------+
      |  Adj-RIB-In     | -   BIS-Ident   | -   Path attributes              |
      |                 |     of adjacent | -   NLRI                         |
      |                 |     BIS         |                                  |
      |                 | -   RIB-Tag     |                                  |
      |                 | -   NLRI        |                                  |
      +-----------------+-----------------+----------------------------------+
      |  Loc-RIB        | -   RIB-Tag     | -   Path attributes              |
      |                 |                 | -   NLRI                         |
      +-----------------+-----------------+----------------------------------+
      |  Adj-RIB-Out    | -   BIS-Ident   | -   Path attributes              |
      |                 |     of adjacent | -   NLRI                         |
      |                 |     BIS         |                                  |
      |                 | -   RIB-Tag     |                                  |
      |                 | -   NLRI        |                                  |
      +-----------------+-----------------+----------------------------------+
      |  FIB            | -   RIB-Tag     | -   IP addr of next hop BIS      |
      |                 | -   NLRI        | -   Output SNPA of local BIS     |
      |                 |                 | -   Input SNPA of next hop BIS   |
      +-----------------+-----------------+----------------------------------+


6.9. Routing information exchange

   This document provides several rules governing the distribution and
   exchange of routing information:


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

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


   Routing 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.





Yakov Rekhter, Paul Traina                                     [Page 13]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996



      +----------------------------------------------------------------------+
      | 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-Tag (including the null RIB-Tag) that it supports.      |
      |                                                                      |
      | c)  A BIS maintains a separate Loc-RIB for each RIB-Tag (including   |
      |     the null RIB-Tag) that it supports.                              |
      |                                                                      |
      | d)  For each adjacent BIS, a given BIS maintains an Adj-RIB-Out for  |
      |     each RIB-Tag (including the null RIB-Tag) that it                |
      |     advertises to that neighbor.                                     |
      |                                                                      |
      | e)  A given BIS maintains a separate FIB for each RIB-Tag            |
      |     (including the null RIB-Tag) 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").                                      |
      +----------------------------------------------------------------------+

6.9.1. Internal neighbor BIS

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


6.9.2. External neighbor BIS

   Each BIS may establish and maintain communications with other BISs in
   adjacent routing domains. A BIS has no direct communications link
   with any BIS in another routing domain unless that RD is adjacent to
   it, as defined in 6 : that is, a BIS does not communicate directly
   with a BIS located in a different routing domain unless the pair of



Yakov Rekhter, Paul Traina                                     [Page 14]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   BISs are attached to at least one common subnetwork. The identity of
   neighbor BISs in adjacent routing domains is contained in managed
   object externalBISNeighbors described in 8.3




6.10. Design objectives

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


6.10.1. Within the scope of the protocol

   This document supports the following design requirements:


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

      Autonomous Operation: It provides stable operation in an internet
      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 routing information or policy
      information.

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

      Adaptability: It adapts to topological changes between routing
      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 routing 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
      routing traffic overhead.

      Robustness: It recovers from transient errors such as lost or



Yakov Rekhter, Paul Traina                                     [Page 15]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      temporarily incorrect routing 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 routing and policy information bases.

      Heterogeneity: It is designed to operate correctly over a set of
      routing domains that may employ diverse intra-domain routing
      protocols. It is capable of running over a wide variety of
      subnetworks.

      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.

      Fault isolation: It will provide fault isolation so that:


         - Problems within one routing domain will not affect intra-
         domain routing in any other routing domain

         - Problems within one routing domain will not affect inter-
         domain routing, unless they occur on internal inter-domain
         Links

         - Inter-domain routing will not adversely affect intra-domain
         routing.


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

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


6.10.2. Outside the scope of the protocol

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


      Traffic Adaptation: It does not automatically modify routes based



Yakov Rekhter, Paul Traina                                     [Page 16]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      on the traffic load.

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



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



7. 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








Yakov Rekhter, Paul Traina                                     [Page 17]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


7.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:


         +-------------------------------------------------------------------+
         | BISPDU Length (2 octets)                                          |
         +-------------------------------------------------------------------+
         | BISPDU Type (1 octet)                                             |
         +-------------------------------------------------------------------+
         | 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:

      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:



Yakov Rekhter, Paul Traina                                     [Page 18]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996



         +----------------------------------------------------+------------+
         | BISPDU Type                                        | Code       |
         +----------------------------------------------------+------------+
         | OPEN PDU                                           | 1          |
         +----------------------------------------------------+------------+
         | UPDATE PDU                                         | 2          |
         +----------------------------------------------------+------------+
         | IDRP ERROR PDU                                     | 3          |
         +----------------------------------------------------+------------+
         | KEEPALIVE PDU                                      | 4          |
         +----------------------------------------------------+------------+
         | 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 8.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 8.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 8.7.5

      Validation Pattern:

         This 16-octet field is used to provide a validation function



Yakov Rekhter, Paul Traina                                     [Page 19]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         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 8.7.1
            and 8.7.3 ), or

            - data integrity for the contents of the BISPDU plus
            authentication of the peer BIS (see 8.7.2 ).




7.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)                                       |
         +-------------------------------------------------------------------+
         | BIS-Identifier Length Indicator (1 octet)                         |
         +-------------------------------------------------------------------+
         | BIS-Identifier (variable)                                         |
         +-------------------------------------------------------------------+
         | Source RDI Length Indicator (1 octet)                             |
         +-------------------------------------------------------------------+
         | Source RDI (variable)                                             |
         +-------------------------------------------------------------------+
         | RIB-TagsSet (variable)                                            |
         +-------------------------------------------------------------------+
         | Confed-IDs (variable)                                             |
         +-------------------------------------------------------------------+
         | Optional Parameters Length (2 octets)                             |
         +-------------------------------------------------------------------+
         | Optional Parameters (variable)                                    |
         +-------------------------------------------------------------------+




Yakov Rekhter, Paul Traina                                     [Page 20]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   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 2-octet unsigned integer indicates the number of seconds
         that the sender proposes for the value of the Hold Timer. Upon
         receipt of an OPEN PDU, a BIS shall calculate the value of the
         Hold Timer by using the smaller of its configured Hold Time and
         the Hold Time received in the OPEN PDU. The Hold Time shall be
         either zero or at least three seconds. An implementation may
         reject connections on the basis of the Hold Time. The
         calculated value indicates the maximum number of seconds that
         may elapse between the receipt of successive KEEPALIVE, and/or
         UPDATE messages by the sender (see 8.6.1.4 and 8.18.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.

         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.

      BIS-Identifier Length Indicator:

         This one octet field contains the length in octets of the BIS-
         Identifier field.

      BIS-Identifier

         This field indicates the BIS Identifier of the sender. A given
         BIS sets the value of its BIS Identifier to an IP address
         assigned to that BIS speaker. The value of the BIS Identifier
         is determined on startup and is the same for every local
         interface and every BIS peer.



Yakov Rekhter, Paul Traina                                     [Page 21]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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 routing
         domain in which the BIS that is sending this BISPDU is located.

      RIB-TagsSet:

         This variable length field contains a list of all RIB-Tags 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 RIBTagsSet (See clauses
         8.3 and 8.10.1 ).

         A BIS is not required to list all of its supported RIB-Tags in
         an OPEN PDU that is sent to a neighbor BIS located in an
         adjacent routing domain. It must include only those RIB-Tags
         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-Tags 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-Tags listed in
         managed object RIBTagsSet in an OPEN PDU that is sent to
         another BIS located in its own routing domain. Failure to do so
         will result in an OPEN PDU error, as described in 8.18.2

         The encoding of this field is as follows:



         +-----------------------------------------------------------------+
         | Number of Non-null RIB-Tags (1 octet)                           |
         +-----------------------------------------------------------------+
         | First RIB-Tag (1 octet)                                         |
         +-----------------------------------------------------------------+
         | ....                                                            |
         +-----------------------------------------------------------------+
         | Last RIB-Tag (1 octet)                                          |
         +-----------------------------------------------------------------+


   The field Number of RIB-Tags is one octet long. It contains the total



Yakov Rekhter, Paul Traina                                     [Page 22]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   number of non-null RIB-Tags supported by this BIS. Since every BIS
   supports a null RIB-Tag (see clause 8.10.1 ), the null RIB-Tag shall
   not be listed in the OPEN PDU.

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

   If the Number of Non-null RIB-Tags is non-zero, then the BIS supports
   all of the listed RIB-Tags plus the null RIB-Tag.

      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:

         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.


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


   Optional Parameters Length:

         This 2-octet unsigned integer indicates the total length of the
         Optional Parameters following this field in octets. If the
         value of this field is zero, no Optional Parameters are
         present.

      Optional Parameters:




Yakov Rekhter, Paul Traina                                     [Page 23]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         This field may contain a list of optional parameters, where
         each parameter is encoded as a <Parameter Flags, Parameter
         Type, Parameter Length, Parameter Value> vector.


         +-----------------------------------------------------------------+
         | Parameter Flags  (1 octet)                                      |
         +-----------------------------------------------------------------+
         | Parameter Type (1 octet)                                        |
         +-----------------------------------------------------------------+
         | Parameter Length (1 or 2 octets)                                |
         +-----------------------------------------------------------------+
         | Parameter Value (variable)                                      |
         +-----------------------------------------------------------------+


         Parameter Flags is a one octet field. The high-order bit (bit
         8) of the Parameter Flags octet is the Optional bit. If it is
         set to 1, the parameter is optional; if set to 0, the parameter
         is well-known. The second high-order bit (bit 7) of the
         Parameter Flags is the Extended Length bit. It defines whether
         the Parameter Length is one octet (if set to 0), or two octets
         (if set to 1). Extended Length may be used only if the length
         of the parameter is greater than 255 octets.

         Parameter Type is a one octet field that unambiguously
         identifies individual parameters.

         Parameter Length is a one or two octets field (depending on the
         value of the Extended Length in the Parameter Flags field) that
         contains the length of the Parameter Value field in octets.

         Parameter Value is a variable length field that is interpreted
         according to the value of the Parameter Type field.

         This document defines the following Optional Parameters:

         a) Authentication Information (Parameter Type 1):

            This well-known parameter may be used to authenticate a BIS
            peer. The Parameter Value field contains a 1-octet
            Authentication Code followed by a variable length
            Authentication Data.

            Authentication Code:

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



Yakov Rekhter, Paul Traina                                     [Page 24]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


                  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 8.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 document.
                  Its use is described in 8.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 8.7.3

            Authentication Data:

               The form and meaning of this field is a variable-length
               field that depends on the Authentication Code. The length
               of the authentication data field can be determined from
               the Length field of the BISPDU header.

         Absence of any Authentication Information in an OPEN PDU shall
         be treated as if the PDU carries Authentication Information
         with Authentication Type 1 (see 8.7.1 ).



7.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 6.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:

      - 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



Yakov Rekhter, Paul Traina                                     [Page 25]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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 NLRI, 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                                                      |
         +-------------------------------------------------------------------+
         | FIB Tag (1 octet)                                                 |
         +-------------------------------------------------------------------+
         | Unfeasible Route Count (2 octets)                                 |
         +-------------------------------------------------------------------+
         | Withdrawn Routes (variable)                                       |
         +-------------------------------------------------------------------+
         | Total Path Attributes Length (2 octets)                           |
         +-------------------------------------------------------------------+
         | Path Attributes (variable)                                        |
         +-------------------------------------------------------------------+
         | Network Layer Reachability Information (variable)                 |
         +-------------------------------------------------------------------+



   The use of these fields is as follows:

      FIB Tag:

         This is a 1-octet long field that contains the FIB Tag
         associated with the routes carried in this UPDATE PDU.




Yakov Rekhter, Paul Traina                                     [Page 26]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      Unfeasible Route Count:

         This is a 2-octet long field that contains an unsigned integer
         whose value is equal to the number of routes 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 NLRIs
         for the routes that are being withdrawn from service. Each NLRI
         is encoded as specified in 7.3.2 withdrawn from service. Each
         such route is identified by its NLRI, which unambiguously
         identifies the route in the context of the BIS-BIS connection
         in which it had been previously been advertised.

      Total Path Attribute Length:

         This is a 2-octet long field that contains an unsigned integer
         whose value 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.



7.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.



Yakov Rekhter, Paul Traina                                     [Page 27]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


            - 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 8.11

         Note 4: It is not the intention of this document 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.

      - 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.




7.3.1.1. LOCAL_PREF (Type Code 1)

   LOCAL_PREF is a well-known discretionary attribute that is a four
   octet non-negative integer. It is used by a BIS to inform other BISs
   in its own RD of the originating BIS's degree of preference for an
   advertised route. Usage of this attribute is described in 7.3.1.1



Yakov Rekhter, Paul Traina                                     [Page 28]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


7.3.1.2. INCOMPLETE_PATH (Type Code 2)

   INCOMPLETE_PATH 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.3.1.2


7.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 routing domains
   or for confederations respectively, in the order that the routing
   information has travelled through them. An RD_SET and an ENTRY_SET
   provide an unordered list of RDIs, for routing domains or for
   confederations respectively; the routing 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
   the RDI in octets.




Yakov Rekhter, Paul Traina                                     [Page 29]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   Usage of this attribute is defined in clause 7.3.1.3


7.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 IP address in
      the "Network Address 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:



         +-------------------------------------------------------------------+
         | Address Family (2 octets)                                         |
         +-------------------------------------------------------------------+
         | Length of Network Address (1 octet)                               |
         +-------------------------------------------------------------------+
         | Network Address of Next Hop (variable)                            |
         +-------------------------------------------------------------------+
         | Number of SNPAs (1 octet)                                         |
         +-------------------------------------------------------------------+
         | Length of first SNPA(1 octet)                                     |
         +-------------------------------------------------------------------+
         | First SNPA (variable)                                             |
         +-------------------------------------------------------------------+
         | Length of second SNPA (1 octet)                                   |
         +-------------------------------------------------------------------+
         | Second SNPA (variable)                                            |
         +-------------------------------------------------------------------+
         | ...                                                               |
         +-------------------------------------------------------------------+
         | Length of Last SNPA (1 octet)                                     |
         +-------------------------------------------------------------------+
         | Last SNPA (variable)                                              |
         +-------------------------------------------------------------------+


   The use and meaning of these fields are as follows:

      Address Family



Yakov Rekhter, Paul Traina                                     [Page 30]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         This field carries the identity of the protocol associated with
         the address information that follows. Presently defined values
         for this field are specified in RFC1700.

         A conformant implementation of IDRP for IPv6 may ignore any
         address information indicating other than IPv6.  A conformant
         implementation of IDRP for IPv4 may ignore any address
         information indicating other than IPv4.

      Length of Network Address:

         A 1 octet field whose value expresses the length of the
         "Network Address of Next Hop" field as measured in octets

      Network Address of Next Hop:

         A variable length field that contains the Network Address of
         the next BIS on the path to the destination system

         An implementation of IDRP for IPv4 or IPv6 shall have the
         following values in the Network Address field:

         IPv6:

            Length of Network Address: 16

            Network Address of Next Hop: an IPv6 unicast address

         IPv4:

            Length of Network Address: 4

            Network Address of Next Hop: an IPv4 unicast address

      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.

      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



Yakov Rekhter, Paul Traina                                     [Page 31]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         Network Address is contained in the "Network Address 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.



   Usage of this attribute is defined in clause 7.3.1.4


7.3.1.5. AGGREGATOR (Type Code 5)

   AGGREGATOR is an optional transitive attribute of length 32. The
   attribute contains the last RDI that formed the aggregate route
   (encoded as 16 octets), followed by the IP address of the BIS that
   formed the aggregate route (encoded as 16 octets, IPv4 addresses are
   prefixed with 12 octets of zeros). The BIS that formed the aggregate
   route may decline to encode its address and instead insert a value of
   all zeros into that field.

   Usage of this attribute is defined in clause 7.3.1.5


7.3.1.6. ATOMIC_AGGREGATE (Type Code 6)

   ATOMIC_AGGREGATE is a well-known discretionary attribute of length 0.
   It is used by a BIS to inform other BISs that the local system
   selected for advertisement a less specific route without selecting a
   more specific route which is included in it.

   Usage of this attribute is defined in clause 7.3.1.6



7.3.1.7. MULTI-EXIT_DISC (Type Code 7)

   MULTI-EXIT_DISC (Multi-exit Discriminator) is an optional non-
   transitive attribute that is a 4 octets 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 routing
   domain. Its usage is defined in 7.3.1.7








Yakov Rekhter, Paul Traina                                     [Page 32]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


7.3.1.8. 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 routing domains through which this
   UPDATE PDU has travelled. Its usage is defined in 7.3.1.8



7.3.1.9. 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.3.1.9



7.3.1.10. COMMUNITIES (Type Code 16)

   COMMUNITIES is an optional transitive attribute of variable length.
   The attribute is a tuple <community, scope>, where the first
   component specifies a particular community, and the second component
   specifies the scope within which the community is defined. All routes
   with this attribute belong to the communities listed in the
   attribute.

   Communities are treated as 32 bit values,  however for administrative
   assignment,  the following presumptions may be made: communities
   values ranging from 0x0000000 through 0x0000FFFF and 0xFFFF0000
   through 0xFFFFFFFF are hereby reserved.

   Scope of a community is either an RD, or RDC. Scope is specified by
   an RDI of the associated RD or RDC, encoded as a tuple <length, RDI>.
   Length is a one octet long field that contains the length of the RDI
   in octets.

   The following communities have global significance and their
   operations shall be implemented in any community-attribute-aware BGP
   speaker.

      NO_EXPORT (0xFFFFFF01)

         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised outside an RDC (as specified
         in the Scope component of the attribute) boundary. A stand-
         alone RD that is not part of an RDC should be considered an RDC
         itself).



Yakov Rekhter, Paul Traina                                     [Page 33]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      NO_ADVERTISE (0xFFFFFF02)

         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised to other BISs.

      NO_EXPORT_SUBCONFED (0xFFFFFF03)

         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised to external neighbors.





7.3.2. Network layer reachability information

   The Network Layer Reachability information is a variable length field
   that contains a list of reachable destinations encoded as zero or
   more triples of the form <Address Family, Addr_length, Addr_info>,
   whose fields are described below:


         +---------------------------+
         | Address Family (2 octets) |
         +---------------------------+
         | Addr_length (2 octets)    |
         +---------------------------+
         | Addr_info (variable)      |
         +---------------------------+


   The use and meaning of these fields are as follows:

      Address Family:

         This field carries the identity of the protocol associated with
         the address information that follows. Presently defined values
         for this field are specified in RFC1700.  A conformant
         implementation of IDRP for IPv6 may ignore any address
         information indicating other than IPv6.  A conformant
         implementation of IDRP for IPv4 may ignore any address
         information indicating other than IPv4.

      Addr_Length:

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




Yakov Rekhter, Paul Traina                                     [Page 34]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      Addr_Info:

         This is a variable length field that contains a list of Network
         Layer address prefixes for the routes that are being
         advertised. Each address prefix is encoded as a 2-tuple of the
         form <Length, Prefix>, whose fields are described below:


               +---------------------------+
               |   Length (1 octet)        |
               +---------------------------+
               |   Prefix (variable)       |
               +---------------------------+



         The use and the meaning of these fields are as follows:

         a) Length:

            The Length field indicates the length in bits of the address
            prefix. A length of zero indicates a prefix that matches all
            (as specified by the address family) addresses (with prefix,
            itself, of zero octets).

         b) Prefix:

            The Prefix field contains address prefixes followed by
            enough trailing bits to make the end of the field fall on an
            octet boundary.  Note that the value of trailing bits is
            irrelevant.


7.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:


   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:


      All errors are fatal to the BIS connection.



Yakov Rekhter, Paul Traina                                     [Page 35]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996



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

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

      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:


         b) UPDATE PDU Error subcodes:



         c) Hold_Timer_Expired Error Subcodes:


         d) FSM_Error Error Subcodes:

         When an FSM Error (see 8.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 7.1 ; the



Yakov Rekhter, Paul Traina                                     [Page 36]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


               +-------------------------------------------------+-----------+
               | Subcode                                         | Value     |
               +-------------------------------------------------+-----------+
               | Unsupported_Version_Number                      | 1         |
               +-------------------------------------------------+-----------+
               | Bad_Max_PDU_Size                                | 2         |
               +-------------------------------------------------+-----------+
               | Bad_Peer_RD                                     | 3         |
               +-------------------------------------------------+-----------+
               | Unsupported_Authentication_code                 | 4         |
               +-------------------------------------------------+-----------+
               | Authentication_Failure                          | 5         |
               +-------------------------------------------------+-----------+
               | Bad_RIB-TagsSet                                 | 6         |
               +-------------------------------------------------+-----------+
               | RDC_Mismatch                                    | 7         |
               +-------------------------------------------------+-----------+
               | Unacceptable Hold Time                          | 8         |
               +-------------------------------------------------+-----------+
               | Unsupported well-known parameter                | 9         |
               +-------------------------------------------------+-----------+
         FSM states are encoded as follows:

               +-------------------------------------------------+-----------+
               | FSM State                                       | Encoded   |
               |                                                 | Value     |
               +-------------------------------------------------+-----------+
               | CLOSED                                          | 1         |
               +-------------------------------------------------+-----------+
               | OPEN-RCVD                                       | 2         |
               +-------------------------------------------------+-----------+
               | OPEN-SENT                                       | 3         |
               +-------------------------------------------------+-----------+
               | CLOSE-WAIT                                      | 4         |
               +-------------------------------------------------+-----------+
               | ESTABLISHED                                     | 5         |
               +-------------------------------------------------+-----------+

         e) RIB_REFRESH_PDU_Error Subcodes:

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




Yakov Rekhter, Paul Traina                                     [Page 37]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


               +-------------------------------------------------+-----------+
               | 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_Routing_Loop                                 | 6         |
               +-------------------------------------------------+-----------+
               | 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        |
               +-------------------------------------------------+-----------+

               +-------------------------------------------------+-----------+
               | Subcode                                         | Value     |
               +-------------------------------------------------+-----------+
               | NULL                                            | 0         |
               +-------------------------------------------------+-----------+
         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.








Yakov Rekhter, Paul Traina                                     [Page 38]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


7.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. A reasonable maximum time
   between KEEPALIVE PDUs would be one third of the Hold Time interval.
   An implementation may adjust the rate at which it sends KEEPALIVE
   PDUs as a function of the Hold Time interval.

   If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
   PDUs shall not be sent.

   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.


7.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 8.6.2



7.7. RIB REFRESH PDU

   The RIB REFRESH PDU is used to allow a BIS to send a refresh of the
   routing 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:


   The use and meaning of these fields is as follows:

   There are three OpCode values defined:





Yakov Rekhter, Paul Traina                                     [Page 39]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996



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

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

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

   Its usage is defined in 8.10.2


8. Elements of procedure

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



8.1. Naming and addressing conventions

   IDRP for IPv4 and IPv6 does not assume or require any particular
   structure for IP addresses. That is, as long as the domain
   administrator assigns addresses that are consistent with the
   deployment constraints of section 7 of this document, the protocol
   will operate correctly.

   IP address prefixes provide a compact way for identifying groups of
   systems that reside in a given domain or confederation. A prefix may
   have a length that is either smaller than, or the same size as the IP
   address (an IPv4 or IPv6 address is a special case of an address
   prefix). The length of an encoded prefix is specified in bits.




Yakov Rekhter, Paul Traina                                     [Page 40]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   Each routing domain and routing domain confederation whose BIS(s)
   implement IDRP for IPv4 and IPv6 shall have an unambiguous routing
   domain identifier (RDI), which is an IPv4 or IPv6 address prefix. In
   the case of IPv4 address prefixes, the prefix value shall be
   prepended with 12 octets of zeros.

   An RDI is assigned statically and does not change based on the
   operational status of a routing domain. An RDI identifies routing
   domain or confederation uniquely, but does not necessarily convey any
   information about policies or identities of its members.



8.2. Deployment guidelines

   Hosts and routers may use any IP unicast addresses, provided that
   these addresses are globally unambiguous. However correct and
   efficient operation of this protocol can only be guaranteed if the
   address assignment reflects the actual topology -- addresses are
   topologically significant.



8.3. Domain configuration information

   Correct Operation  of IDRP assumes that a minimum amount of
   information  is  available to both the inter-domain  and intra-domain
   routing protocols. This information  is static in nature, and is not
   expected to change frequently. This document assumes that this
   information is supplied via IDRP MIB. While the following in phrased
   in terms of MIB, this document allows alternative mechanisms (e.g.
   configuration files) as well.

   The information required  by a BIS that implements the IDRP for IPv4
   and IPv6 protocol is:

      a) Location and identity of adjacent Intra-Domain routers:

         The MIB table IntraIS lists the IP addresses of the routers to
         which the local BIS may deliver an inbound NPDU whose
         destination lies within the BIS's routing domain. These routers
         listed in the IntraIS table support the intra-domain routing
         protocol of this domain, and share at least one common subnet
         with the BIS.

         In particular, if the local BIS participates in both  the
         inter-domain routing protocol (IDRP) and the intra-domain
         routing protocol, then the IP address of the local BIS will be



Yakov Rekhter, Paul Traina                                     [Page 41]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         listed in the IntraIS table.

      b) Location and identity of BISs in the BIS's domain:

         This information permits a BIS to identify all other BISs
         located within its routing domain. This information is
         contained in the MIB table internalBISNeighbors, which contains
         a set of IP addresses which identify the BISs in the domain.

      c) Location and identity of BISs in adjacent domains:

         Each BIS needs information to identify the IP address of each
         BIS located in an adjacent RD and reachable via a single
         subnetwork hop.  This information is contained in the IDRP MIB
         table externalBISNeighbors, which is a table of IP addresses.

      d) IP network address information for all systems in the routing
      domain:

         This information is used by the BIS to construct its network
         layer reachability information. This information is contained
         in the MIB table internalSystems, which lists NLRI (expressed
         as address prefixes) of the systems within the routing domain.

      e) Local RDI:

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

      f) RDC-Config:

         This information identifies all the routing 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 the MIB table rdcConfig.

         Note that since a domain is not required to belong to a
         confederation this information is optional and needs to be
         present only at BISs of the domains that are part of one or
         more of RDCs.

      g) RIBTagsSet

         This managed object lists all of the RIB-Tags which are
         supported by the BISs located in this routing domain.






Yakov Rekhter, Paul Traina                                     [Page 42]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.4. Advertising NLRI

   The NLRI field in an UPDATE PDU contains information about the
   addresses of systems that reside within a given routing domain or
   whose Network Layer addresses are under control of the administrator
   of that routing 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 to report that a given system has changed its status from
   online to offline.

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

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

      b) Network Layer addresses that are known to correspond to systems
      that are not under control of the routing domain administrator
      should not be included in the NLRI field for that routing domain.

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

         Note 9: Although the protocol in this document will operate
         correctly if each system is reported individually as a
         maximum-length Network Layer address prefix, this will result
         in a large amount of routing 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 routing domain to implement
         policies that ignore UPDATE PDUs that contain an excessive
         amount of NLRI information or that can cause inefficient



Yakov Rekhter, Paul Traina                                     [Page 43]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         operation of this protocol.




8.5. An interface to IP

   IDRP information is carried between a pair of BISs in the form of
   BISPDUs. For IDRP for IPv6 these BISPDUs are carried in the data
   field of IP packets of protocol type 45.

   IDRP relies on IP to perform the initial processing of incoming
   BISPDUs. The IP protocol machine shall process inbound packets
   according to the appropriate IP functions.

   If a fixed header of an IP packet contains a protocol type that
   identifies IDRP, and the packet's source address identifies any
   system listed in managed objects internalBISNeighbors or
   externalBISNeighbors, then the packet contains a BISPDU. The BISPDU
   shall be passed to the IDRP finite state machine defined in 8.6.1



8.6. BIS-BIS connection management

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


8.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.



   BISPDUs passed to this finite state machine are subject the flow
   control procedures of 8.7.5 if the FSM is in the ESTABLISHED state.
   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,



Yakov Rekhter, Paul Traina                                     [Page 44]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996




         +--- 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                                           |
         |                                                                   |
         +-------------------------------------------------------------------+

   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 8.18 have been
      detected.

      b) Receive with errors means that an error condition defined in
      the appropriate subclause of 8.18 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.






Yakov Rekhter, Paul Traina                                     [Page 45]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.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 8.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 8.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 field shall acknowledge the received OPEN PDU, the
      Credit Available field shall be set according to the procedures of
      8.7.5 (b), 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.



8.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



Yakov Rekhter, Paul Traina                                     [Page 46]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      PDU to its peer, and the FSM shall enter the CLOSE-WAIT state.

      c) If the BIS receives a BISPDU with header errors (see 8.18.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 8.18.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 8.7.5 (b). 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 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



Yakov Rekhter, Paul Traina                                     [Page 47]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         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.



8.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.

      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.




Yakov Rekhter, Paul Traina                                     [Page 48]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


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


















8.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



Yakov Rekhter, Paul Traina                                     [Page 49]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996



      +----------------------------------------------------------------------+
      | Table 2 (Page 1 of 7). BIS Finite State Machine.  This table         |
      |                        summarizes the effects that its inputs will   |
      |                        have on an IDRP FSM, giving both state        |
      |                        transitions and the actions to be taken.      |
      +--------+-----------+-------------+-------------+----------+----------+
      | 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  |             |             |          |          |
      +--------+-----------+-------------+-------------+----------+----------+
      | 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  |           |             |             |          |          |
      +--------+-----------+-------------+-------------+----------+----------+

   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.



Yakov Rekhter, Paul Traina                                     [Page 50]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      +----------------------------------------------------------------------+
      | Table 2 (Page 2 of 7). BIS Finite State Machine.  This table         |
      |                        summarizes the effects that its inputs will   |
      |                        have on an IDRP FSM, giving both state        |
      |                        transitions and the actions to be taken.      |
      +--------+-----------+-------------+-------------+----------+----------+
      | STATE  | CLSD      | OPRC        | OPSN        | CLWT     | ESTB     |
      | >      |           |             |             |          |          |
      +--------+           |             |             |          |          |
      | INPUT  |           |             |             |          |          |
      | V      |           |             |             |          |          |
      +--------+-----------+-------------+-------------+----------+----------+
      | 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  |           |             |             |          |          |
      +--------+-----------+-------------+-------------+----------+----------+
      | 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  |             |          |          |
      +--------+-----------+-------------+-------------+----------+----------+

      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.



Yakov Rekhter, Paul Traina                                     [Page 51]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      +----------------------------------------------------------------------+
      | Table 2 (Page 3 of 7). BIS Finite State Machine.  This table         |
      |                        summarizes the effects that its inputs will   |
      |                        have on an IDRP FSM, giving both state        |
      |                        transitions and the actions to be taken.      |
      +--------+-----------+-------------+-------------+----------+----------+
      | STATE  | CLSD      | OPRC        | OPSN        | CLWT     | ESTB     |
      | >      |           |             |             |          |          |
      +--------+           |             |             |          |          |
      | INPUT  |           |             |             |          |          |
      | V      |           |             |             |          |          |
      +--------+-----------+-------------+-------------+----------+----------+
      | 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    |
      +--------+-----------+-------------+-------------+----------+----------+

      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.

      h) If the BIS receives an UPDATE PDU with no errors, the BIS shall
      perform the actions provided in 8.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 8.10.2 , and shall restart
      its Hold Timer. The FSM shall remain in the ESTABLISHED state.



Yakov Rekhter, Paul Traina                                     [Page 52]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      +----------------------------------------------------------------------+
      | Table 2 (Page 4 of 7). BIS Finite State Machine.  This table         |
      |                        summarizes the effects that its inputs will   |
      |                        have on an IDRP FSM, giving both state        |
      |                        transitions and the actions to be taken.      |
      +--------+-----------+-------------+-------------+----------+----------+
      | 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    |
      +--------+-----------+-------------+-------------+----------+----------+

      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.




Yakov Rekhter, Paul Traina                                     [Page 53]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      +----------------------------------------------------------------------+
      | Table 2 (Page 5 of 7). BIS Finite State Machine.  This table         |
      |                        summarizes the effects that its inputs will   |
      |                        have on an IDRP FSM, giving both state        |
      |                        transitions and the actions to be taken.      |
      +--------+-----------+-------------+-------------+----------+----------+
      | 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 |           |             |             |          |          |
      +--------+-----------+-------------+-------------+----------+----------+





Yakov Rekhter, Paul Traina                                     [Page 54]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      +----------------------------------------------------------------------+
      | Table 2 (Page 6 of 7). BIS Finite State Machine.  This table         |
      |                        summarizes the effects that its inputs will   |
      |                        have on an IDRP FSM, giving both state        |
      |                        transitions and the actions to be taken.      |
      +--------+-----------+-------------+-------------+----------+----------+
      | 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    |
      +--------+-----------+-------------+-------------+----------+----------+

      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.

   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



Yakov Rekhter, Paul Traina                                     [Page 55]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      +----------------------------------------------------------------------+
      | Table 2 (Page 7 of 7). BIS Finite State Machine.  This table         |
      |                        summarizes the effects that its inputs will   |
      |                        have on an IDRP FSM, giving both state        |
      |                        transitions and the actions to be taken.      |
      +--------+-----------+-------------+-------------+----------+----------+
      | 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  |             |          |          |
      +--------+-----------+-------------+-------------+----------+----------+


      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.

      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




Yakov Rekhter, Paul Traina                                     [Page 56]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      +----------------------------------------------------------------------+
      | 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".                      |
      +----------------------------------------------------------------------+

8.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.


8.7. Validation of BISPDUs

   The protocol described in this document 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 8.6 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



Yakov Rekhter, Paul Traina                                     [Page 57]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   authentication. Each mechanism is described below.


8.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 MD5
         Message-Digest algorithm (RFC1321) 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 MD5 Message-Digest
         algorithm (RFC1321) 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.



8.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 document.  However, they must be
   agreed to by the pair of communicating BISs as part of their security
   association.

      Note 12: This document 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



Yakov Rekhter, Paul Traina                                     [Page 58]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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 document.



8.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 method for encoding
   this data is specified in MD5 HMAC (RFC XXXX)  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:

            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 contents of the BISPDU and the
            password text as specified by MD5 HMAC (RFC XXXX) shall be
            generated using the MD5 Message-Digest algorithm (RFC1331)
            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.

            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.



Yakov Rekhter, Paul Traina                                     [Page 59]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


            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.


8.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.

      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.



Yakov Rekhter, Paul Traina                                     [Page 60]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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
      8.7.5 BIS then shall set its lower window edge (see 8.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.
      Alternatively, after a BIS sends a BISPDU with the maximum
      permissible sequence number, the BIS may issue a CEASE BISPDU and
      restart the BIS-BIS connection.




8.7.5. Flow control

   After an IDRP connection is established, the BIS Finite State Machine
   is in state ESTABLISHED (see section 8.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
      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



Yakov Rekhter, Paul Traina                                     [Page 61]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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 8.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.

      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.




Yakov Rekhter, Paul Traina                                     [Page 62]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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 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.




Yakov Rekhter, Paul Traina                                     [Page 63]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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.



8.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.


8.9. Checksum algorithm

   The checksums used in this document for authentication types 1 and 3
   shall be generated in accordance with the MD5 Message-Digest
   algorithm described in RFC1321 and MD5 HMAC described in RFCXXXX.
   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.







Yakov Rekhter, Paul Traina                                     [Page 64]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.10. Routing information bases

   The Routing Information Base (RIB) within a BIS consists of three
   distinct parts:

      a) Adj-RIBs-In: The Adj-RIBs-In store routing 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-Tag (see 8.10.1
      ).

      b) Loc-RIBs: The Loc-RIBs contain the local routing information
      that the BIS has selected by applying its local policies to the
      routing 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-Tag (see clause 8.10.1 ). Information in
      the Loc-RIB is used to build the Adj-RIBs-Out.

      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-Tag (see 8.10.1
      ). The routing 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 routing 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 routing information. The choice of implementation
      (for example, 3 copies of the information vs. 1 copy with
      pointers) is not constrained by this standard.






Yakov Rekhter, Paul Traina                                     [Page 65]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.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-Tag associated with it.

   The managed object RIBTagsSet explicitly enumerates all the RIB-Tags
   that a BIS supports. Managed object RIBTagsSet shall not contain any
   pairs of RIB-Tags that are identical, thus assuring that each RIB-Tag
   is unambiguous within the BIS.

   All BISs located within a given routing domain shall support the same
   RIB-Tags: that is, the managed object RIB-TagsSet of every BIS within
   an RD shall list the same RIB-Tags. When a BIS receives an OPEN PDU
   from another BIS located in its own routing domain, it shall compare
   the information in the field RIB-TagsSet with the information in its
   local managed object RIBTagsSet. If they do not match, then the
   appropriate error handling procedure in 8.18.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 null RIB-Tag.




8.10.2. 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-Tags 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




Yakov Rekhter, Paul Traina                                     [Page 66]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         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 routing information currently
   stored in the Adj-RIB-In which is identified by the FIB-Tag of the
   RIB REFRESH PDU until the refresh cycle has been completed or has
   been aborted.

   The BIS shall accumulate the routing 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 routing information in the associated Adj-RIB-In
   with the routing information that was learned during the refresh
   cycle.

   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
   routing 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.


8.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 7.3








Yakov Rekhter, Paul Traina                                     [Page 67]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996



         +-------------------------------------------------+
         | Table 3. Path Attribute Characteristics         |
         +----------------+--------------+------+----------+
         | Attribute      | Category     | Type |  Length  |
         |                |              | Code | (octets) |
         +----------------+--------------+------+----------+
         | LOCAL_PREF     | well-known   |   1  |     4    |
         |                | discretionary|      |          |
         +----------------+--------------+------+----------+
         |INCOMPLETE_PATH | well-known   |   2  |     0    |
         |                | discretionary|      |          |
         +----------------+--------------+------+----------+
         | RD_PATH        | well-known   |   3  | variable |
         |                | mandatory    |      |          |
         +----------------+--------------+------+----------+
         | NEXT_HOP       | well-known   |   4  | variable |
         |                | discretionary|      |          |
         +----------------+--------------+------+----------+
         | AGGREGATOR     | optional     |   5  |    32    |
         |                | transitive   |      |          |
         +----------------+--------------+------+----------+
         | ATOMIC_AGGREG  | well-known   |   6  |     0    |
         |                | discretionary|      |          |
         +----------------+--------------+------+----------+
         | MULTI-EXIT     | optional     |   7  |     4    |
         | DISC           | non-transitiv|      |          |
         +----------------+--------------+------+----------+
         | RD_HOP_COUNT   | well-known   |  13  |     1    |
         |                | mandatory    |      |          |
         +----------------+--------------+------+----------+
         | CAPACITY       | well-known   |  15  |     1    |
         |                | discretionary|      |          |
         +----------------+--------------+------+----------+
         | COMMUNITIES    | well-known   |  16  | variable |
         |                | discretionary|      |          |
         +----------------+--------------+------+----------+

8.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



Yakov Rekhter, Paul Traina                                     [Page 68]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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
      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



Yakov Rekhter, Paul Traina                                     [Page 69]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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.




8.12. Path attribute usage

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



8.12.1. LOCAL_PREF

   LOCAL_PREF is a well-known discretionary attribute that shall be
   included in all UPDATE PDUsthat a given BIS sends to the other BIS
   located in its own RD. A BIS shall calculate the degree of preference
   for each external route and include the degree of preference when
   advertising a route to BISs that are located in the same RD. The
   higher degree of preference should be preferred. A BIS shall use the
   degree of preference learned via LOCAL_PREF in its decision process
   (see section 8.15.1 ).

   A BIS shall not include this attribute in UPDATE PDUs that it sends
   to BISs located in adjacent RDs.  If it is contained in an UPDATE PDU
   that is received from a BIS which is not located in the same RD as
   the receiving BIS, then this attribute shall be ignored by the
   receiving BIS.



8.12.2. INCOMPLETE_PATH

   INCOMPLETE_PATH 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 document.

   The INCOMPLETE_PATH attribute shall be generated by the RD that
   originates the associated routing information. If the INCOMPLETE_PATH
   attribute was present in a received UPDATE PDU, then it shall also be



Yakov Rekhter, Paul Traina                                     [Page 70]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   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 INCOMPLETE_PATH
   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.

   If a BIS selects a route which has been advertised with the
   INCOMPLETE_PATH attribute, it is possible that there may be
   undetected looping of routing information. Therefore, it is
   recommended that distribution of information not learned by the
   methods of IDRP be tightly controlled. Furthermore, a given RD may
   also enforce policies which prohibit any of its BISs from selecting
   routes which have the INCOMPLETE_PATH attribute associated with them.


8.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 routing domains and routing domain confederations
   through which this route has passed. The path segments can be
   RD_SETs, RD_SEQs, ENTRY_SEQs, or ENTRY_SETs.


8.12.3.1. Generating an RD_PATH attribute

   When a BIS originates a route to destinations contained within its
   own routing domain or to destinations learned by means outside the
   protocol (see 7.3.1.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 routing
   domain is a member. The local BIS shall then construct an RD_PATH
   attribute as follows:

      a) If the local routing 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.




Yakov Rekhter, Paul Traina                                     [Page 71]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         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
         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 routing domain.

      b) If the local routing 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 routing domain.


8.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
      routing 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
      routing domain, the local BIS shall determine if the route has
      entered any confederations (see 8.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 are found. The
            RDI with the lesser octet value (when treated as an unsigned



Yakov Rekhter, Paul Traina                                     [Page 72]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


            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 routing 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 routing domain.


8.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 8.12.3.2 ; and when a route is generated
   locally, the BIS will have created an RD_PATH attribute in accordance
   with 8.12.3.1 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
      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



Yakov Rekhter, Paul Traina                                     [Page 73]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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 routing 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.

            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



Yakov Rekhter, Paul Traina                                     [Page 74]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


            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.



8.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.



   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:



Yakov Rekhter, Paul Traina                                     [Page 75]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996



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

      - 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 Network Layer address and the SNPAs
            of subnetworks that connect itself to the remote BIS in the
            NEXT_HOP attribute of that UPDATE PDU.

            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 Network Layer address of the BIS that
            advertises the UPDATE PDU should be considered to be the
            Network Layer address of the next-hop BIS.




Yakov Rekhter, Paul Traina                                     [Page 76]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      b) Advertising Routing Information

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

            1) The BIS may choose to list its own Network Layer address
            and the SNPAs of subnetworks that connect itself to the
            remote BIS in the NEXT_HOP attribute of an UPDATE PDU that
            propagates the routing 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 Network Layer address and
            SNPAs of the source BIS in its own UPDATE PDUs. If they are
            all satisfied, then instead of listing its own Network Layer
            address and SNPAs, the BIS may optionally list the Network
            Layer address 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:


               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 routing 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.

   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
      routing domain.




Yakov Rekhter, Paul Traina                                     [Page 77]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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.3.1.3

      c) If the Network Layer address and SNPAs are not available in an
      UPDATE PDU, then a BIS that receives it must learn them by means
      outside of this document.

   A BIS must never install a route with itself as the next hop.

   When a BIS advertises the route to a BIS located in its own domain,
   the advertising BIS should not modify the NEXT_HOP attribute
   associated with the route.

   When a BIS receives the route from an internal neighbor BIS, it may
   use the NEXT_HOP address as the forwarding address, provided that the
   address is on a common subnet with the local BIS.



8.12.5. AGGREGATOR

   AGGREGATOR is an optional transitive attribute which may be included
   in updates which are formed by aggregation (see 8.16.2 ). A BIS which
   performs route aggregation may add the AGGREGATOR attribute which
   shall contain BIS's own RDI and IP address.


8.12.6. ATOMIC_AGGREGATE

   ATOMIC_AGGREGATE is a well-known discretionary attribute. If a BIS,
   when presented with a set of overlapping routes from one of its peers
   (see 8.15.4 ), selects the less specific route without selecting the
   more specific one, then the local system shall attach the
   ATOMIC_AGGREGATE attribute to the route when propagating it to other
   BISs (if that attribute is not already present in the received less
   specific route). A BIS that receives a route with the
   ATOMIC_AGGREGATE attribute shall not remove the attribute from the
   route when propagating it to other BISs. A BIS that receives a route
   with the ATOMIC_AGGREGATE attribute shall not make any NLRI of that
   route more specific (as defined in 8.15.4 ) when advertising this
   route to other BISs. A BIS that receives a route with the
   ATOMIC_AGGREGATE attribute needs to be cognizant of the fact that the
   actual path to destinations, as specified in the NLRI of the route,
   while having the loop-free property, may traverse
   domains/confederations that are not listed in the RD_PATH attribute.





Yakov Rekhter, Paul Traina                                     [Page 78]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.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 routing
   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
   shall not re-distribute the attribute to any BISs which are not
   located within its own RD.



8.12.8. 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
      routing 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 routing
      domain.

      d)  This attribute may be modified by administrative proceedures.








Yakov Rekhter, Paul Traina                                     [Page 79]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.12.9. CAPACITY

   This is a well-known discretionary attribute that is used to denote
   the traffic handling capacity of the RD_PATH listed in the same
   UPDATE PDU. Different routing 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 outside the scope of this document
   before a BIS-BIS connection is established.

   The value of capacity that is associated with a given routing domain
   is contained in managed object capacity.

   If a BIS advertises a route whose destinations are located in its own
   routing 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 and the route includes the CAPACITY
   attribute, the attribute shall reflect the lower 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.



8.13. Routing 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 document.

   From the outside, an RDC looks similar to a single routing 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 6 ).


8.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.

   Since a confederation appears to the external world as if it were an



Yakov Rekhter, Paul Traina                                     [Page 80]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   individual RD, IDRP's loop detection methods will detect routing
   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.


8.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 routing
   domain is contained in managed object localRDI, as defined in 8.3


8.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.





Yakov Rekhter, Paul Traina                                     [Page 81]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.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 route (either feasible or unfeasible), the Adj-RIB-In is
   identified by the FIB-Tag carried in 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
      NLRIs 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:

         1) If its NLRI is 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 8.15.4 ) than an earlier route contained in the
         Adj-RIB-In, and the 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 to an earlier
         route contained in the Adj-RIB-In, and is more specific (see
         8.15.4 ) 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 8.15.4 ) 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.





Yakov Rekhter, Paul Traina                                     [Page 82]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.15. 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 routing loops must be ignored by the Decision
   Process. Therefore, any route that was a) received from a BIS located
   in an adjacent routing domain and b) contains in its RD_PATH
   attribute a path segment of type RD_SEQ or RD_SET that contains the
   RDI of the local routing 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.

   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 routing domain

      - selection of routes to be advertised to BISs located in adjacent
      routing 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 routing
      domain, and for advertising to the other BISs in the local Routing



Yakov Rekhter, Paul Traina                                     [Page 83]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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 routing 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.



8.15.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-Tag 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 determine a degree of preference as follow. If the route is
   learned from a BIS in the local RD, the value of the LOCAL_PREF
   attribute shall be taken as the degree of preference. If the route is
   learned from a BGP speaker in a neighboring autonomous system, then
   the degree of preference shall be computed based on preconfigured
   policy information. The exact nature of this policy information and
   the computation involved is a local matter. After a degree of
   preference is determined, the local BIS shall run the internal update
   process of 8.15.7 to select and advertise the most preferable routes.








Yakov Rekhter, Paul Traina                                     [Page 84]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.15.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 routing domain and those received from
   BISs located in adjacent routing 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-Tag associated with this instance
   of the process prior to commencing its function, and shall unlock
   them on completion.

   For each set of destinations for which a feasible route exists in the
   Adj-RIBs-In identified by the RIB-Tag 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 95

   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. The local BIS shall determine the immediate next hop to the
   address depicted by the NEXT_HOP attribute of the selected route by
   performing a lookup in the intra-domain routing and selecting one of
   the possible paths in the intra-domain routing. This immediate next
   hop shall be used when installing the selected route in the Loc-RIB.
   If the route to the address depicted by the NEXT_HOP attribute
   changes such that the immediate next hop changes, route selection
   should be recalculated as specified above.

   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 Network Layer
   address 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



Yakov Rekhter, Paul Traina                                     [Page 85]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   destinations located within the local routing domain if that route
   would exit the local routing domain and later re-enter it. Such
   routes would be rejected by other RDs due to the existence of an RD-
   loop.



8.15.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. 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.

   The following tie-breaking procedure assumes that for each candidate
   route all the BGP speakers within an autonomous system can ascertain
   the cost of a path (interior distance) to the address depicted by the
   NEXT_HOP attribute of the route.  Ties shall be broken according to
   the following algorithm:

      a) If the local BIS is configured to take into account
      MULTI_EXIT_DISC, and the candidate routes differ in their
      MULTI_EXIT_DISC attribute, select the route that has the lowest
      value of the MULTI_EXIT_DISC attribute. If the local BIS is
      configured to take into account MULTI_EXIT_DISC,  but that
      attribute is not present,  a locally defined "default"
      MULTI_EXIT_DISC may be assumed as a basis for performing tie-
      breaking.

      b) Otherwise, if the local BIS can ascertain the cost of a path to
      the entity depicted by the NEXT_HOP attribute of the candidate
      route, select the route with the lowest cost (interior distance)
      to the entity depicted by the NEXT_HOP attribute of the route.  If
      there are several routes with the same cost, then the tie-breaking
      shall be broken as follows:

         - if at least one of the candidate routes was advertised by the
         BIS in an adjacent RD, select the route that was advertised by
         the BIS in an adjacent RD whose IDRP Identifier has the lowest
         value among all other BIS in adjacent RDs;

         - otherwise, select the route that was advertised by the BIS
         whose IDRP Identifier has the lowest value.






Yakov Rekhter, Paul Traina                                     [Page 86]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.15.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 INCOMPLETE_PATH
      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-Tag), replacing the current entries., The path
   attributes are updated in accordance with the appropriate subclause
   of 8.12 8.16 - 96 ) 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 97










Yakov Rekhter, Paul Traina                                     [Page 87]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.15.4. 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 FIB-Tags.
   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)

      b) Install the more specific route received from the given
      neighbor (A) and reject A's less specific route



Yakov Rekhter, Paul Traina                                     [Page 88]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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.


8.15.5. 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 document 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 is in
   progress and that is consistent with the conformance requirements of



Yakov Rekhter, Paul Traina                                     [Page 89]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   this document may be used.


8.15.6. 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 routing domains are given in 97 ; rules for
   information exchange between BIS located in the same domain are given
   in 8.15.7

   Distribution of reachability information between a set of BISs, all
   of which are located in the same routing 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 routing 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 routing 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 routing
   domains, the communicating BISs must be located in adjacent routing
   domains - that is, they must be attached to a common subnetwork.


8.15.7. Internal updates

   The internal update process is concerned with the distribution of
   routing information to BISs located in the local BIS's own routing
   domain. Each BIS selects the most preferable route, if any, that it
   has received from a BIS in an adjacent routing domain, and
   distributes that route to every other BIS in its own routing domain.
   This process ensures that all BISs in a routing domain will select
   the same set of routes.

   The following procedures shall be applied separately for each set of
   FIB-Tags supported by the BIS:

      a) When a BIS receives an UPDATE PDU from another BIS located in
      its own routing domain, the receiving BIS shall not re-distribute
      the routing information contained in that UPDATE PDU to other BISs
      located in its own routing domain.




Yakov Rekhter, Paul Traina                                     [Page 90]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      b) When a BIS receives a new feasible route from a BIS in an
      adjacent routing domain, it shall advertise that route to all
      other BISs in its routing 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 FIB-Tag - that have
         been received from BISs in adjacent routing domains.

         2)  there are no other routes - with the same destinations and
         the same FIB-Tag - that have been received from BISs in
         adjacent routing 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 routing domains and that have the highest
         degree of preference, the same destinations, and the same FIB-
         Tag (see 8.15.7.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 NLRIs 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 FIB-Tag 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 NLRI of 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.






Yakov Rekhter, Paul Traina                                     [Page 91]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.15.7.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 FIB-Tag an all of
   which were advertised by BISs located in adjacent routing 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.

      b) If the local system can ascertain the cost of a path to the
      entity depicted by the NEXT_HOP attribute of the candidate route,
      select the route with the lowest cost.

      c) In all other cases, select the route that was advertised by the
      BIS whose IDRP Identifier has the lowest value.



8.15.8. External updates

   The external update process is concerned with the distribution of
   routing information to BISs located in adjacent routing 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 routing domains by means of
   UPDATE PDUs.

   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.

   A BIS shall not propagate an UPDATE PDU that contains routes with
   FIB-Tag that was not listed in the RIB-TagsSet field of the neighbor
   BIS's OPEN PDU. If such routes are advertised, it will cause the
   BIS-BIS connection to be closed, as described in 8.18.3




Yakov Rekhter, Paul Traina                                     [Page 92]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.15.9. Controlling routing traffic overhead

   The inter-domain routing protocol constrains the amount of routing
   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.


8.15.9.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
   routing 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 routing
   domain. To avoid long-lived black holes, the procedure does not apply
   to the explicit withdrawal of unfeasible routes (that is, routes
   whose NLRI 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.


8.15.9.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 routing domain.









Yakov Rekhter, Paul Traina                                     [Page 93]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.15.9.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.



8.16. Efficient organization of routing information

   Having selected the routing information which it will advertise, a
   BIS may avail itself of several methods to organize this information
   in an efficient manner.


8.16.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 addresses can be represented as address prefixes.
         In cases where there is a correspondence between the address
         structure and the systems under control of a routing 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



Yakov Rekhter, Paul Traina                                     [Page 94]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         algorithm described in 8.16.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 routing 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.



8.16.2. Aggregating routing 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 routing 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.


8.16.2.1. Route aggregation

   Several routes shall not be aggregated into a single route unless the
   FIB-Tags of each of these route are the same.


   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



Yakov Rekhter, Paul Traina                                     [Page 95]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


   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.



8.16.2.2. 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:

      LOCAL_PREF attributes:

         When several routes are aggregated, the advertising BIS shall
         compute a degree of preference for the aggregated route, and
         shall carry this value in the LOCAL_PREF attribute of the
         aggregated route.


      INCOMPLETE_PATH attributes:

         If at least one route among routes that are aggregated has the
         INCOMPLETE_PATH attribute, then the aggregated route must have
         the INCOMPLETE_PATH 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.

         If routes to be aggregated have identical RD_PATH attributes,



Yakov Rekhter, Paul Traina                                     [Page 96]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


         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 8.16.2.2.1 calls the subroutine of
            8.16.2.2.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 8.16.2.2.1 , and the
            subroutine is described in 8.16.2.2.2



Yakov Rekhter, Paul Traina                                     [Page 97]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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.


      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.


8.16.2.2.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 8.16.2.2.2 ), and
      prepend the result to the aggregated RD_PATH attribute.

      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 8.16.2.2.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.



Yakov Rekhter, Paul Traina                                     [Page 98]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.16.2.2.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.

      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.


8.17. 7.19 Maintenance of the forwarding information bases

   As summarized in Table 1, the Forwarding Information Bases contain
   the following information:

      a) the Network Layer address of the next-hop BIS,

      b)  the local SNPA used by the local BIS to forward traffic to the



Yakov Rekhter, Paul Traina                                     [Page 99]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      next-hop BIS,


      e)  if available, the SNPA in the next-hop BIS to which NPDUs will
      be forwarded.



   The RIB-Tag of the Loc-RIB which contains a route is also the RIB-Tag
   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.

   The forwarding information consists of three parts.

   a) Network Layer address 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 8.15.2 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.


8.18. 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.


8.18.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:



Yakov Rekhter, Paul Traina                                    [Page 100]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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



8.18.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 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 Routing 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 Routing Domain
      Identifier may be obtained by means outside the scope of this



Yakov Rekhter, Paul Traina                                    [Page 101]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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-TagsSet field contained in that PDU is different
      from the receiving BIS's managed object RIBTagsSet, then the error
      subcode of the IDRP ERROR PDU shall be set to Bad-RIB-TagsSet.

      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 routing 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.

      g) If the Hold Time field of the OPEN PDU is unacceptable, then
      the Error Subcode shall be set to Unacceptable Hold Time. An
      implementation shall reject Hold Time values of one or two
      seconds.  An implementation may reject any proposed Hold Time. An
      implementation which accepts a Hold Time shall use the negotiated
      value for the Hold Time.

      h) If the OPEN PDU carries one or more well-known optional
      parameters, and if any of these parameters is not recognized, then
      the error subcode of the IDRP ERROR PDU shall be set to
      Unsupported well-known parameter. The Data field of the IDRP ERROR
      PDU shall report the unrecognized parameter (type, length and
      value).


8.18.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



Yakov Rekhter, Paul Traina                                    [Page 102]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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
      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_Routing_Loop.

      The data field of the IDRP ERROR PDU shall report the first RDI



Yakov Rekhter, Paul Traina                                    [Page 103]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      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-null FIB-Tag advertised in an UPDATE PDU received
      from a BIS located in a different routing domain does not match
      any of the RIB-Tags that the local (receiving) BIS had advertised
      to that neighbor in the RIB-TagsSet 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.

      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
      8.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.


         Note 32: This error condition refers to duplicated attributes
         within a single route.




Yakov Rekhter, Paul Traina                                    [Page 104]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      p) If an UPDATE PDU contains more than one instance of a path
      attribute of the same type, 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.



8.18.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 clause 8.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.


8.18.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.


8.18.6. KEEPALIVE PDU error handling

   The KEEPALIVE PDU consists of only the BISPDU Header. Error
   conditions are handled according to 8.18.1









Yakov Rekhter, Paul Traina                                    [Page 105]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


8.18.7. CEASE PDU error handling

   The CEASE PDU consists of only the BISPDU Header. Error conditions
   are handled according to 8.18.1


8.18.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-Tag in the Rib-Tags variable
      length field in the RIB REFRESH PDU for a RIB Refresh Start
      OpCode: indicate RIB REFRESH error with error subcode "Unsupported
      RIB-Tags"



9. Constants


   This constants used by the protocol defined in this document are
   enumerated in Table 6.



10. Required set of supported routing policies

   Policies are provided to IDRP in the form of configuration
   information.  This information is not directly encoded in the
   protocol. Therefore, IDRP can provide support for very complex
   routing policies. However, it is not required that all IDRP
   implementations support such policies.

   We are not attempting to standardize the routing policies that must
   be supported in every IDRP implementation; we strongly encourage all
   implementors to support the following set of routing policies:

      IDRP implementations should allow a domain to control
      announcements of IDRP-learned routes to adjacent domains.
      Implementations should also support such control with at least the



Yakov Rekhter, Paul Traina                                    [Page 106]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996



      +----------------------------------------------------------------------+
      | Table 6. Architectural Constants of IDRP                             |
      +---------------------------+--------------+---------------------------+
      | Name of Constant          | Value        | Description               |
      +---------------------------+--------------+---------------------------+
      | Inter-domain Routing      |  45          | The Protocol the protocol |
      | Protocol Number           |              | described in this         |
      |                           |              | document                  |
      +---------------------------+--------------+---------------------------+
      | MinBISPDULength           | 30           | The size in octets of the |
      |                           |              | smallest allowable        |
      |                           |              | BISPDU.                   |
      +---------------------------+--------------+---------------------------+
      | MinRDOriginationInterval  | 15 min       | The minimum time between  |
      |                           |              | successive UPDATE PDUs    |
      |                           |              | advertising routing       |
      |                           |              | information about the     |
      |                           |              | local RD                  |
      +---------------------------+--------------+---------------------------+
      | Jitter                    | 0,25         | The factor used to        |
      |                           |              | compute jitter according  |
      |                           |              | to clause 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.             |
      +---------------------------+--------------+---------------------------+

      granularity of a single address prefix. Implementations should
      also support such control with the granularity of a domain, where
      the domain may be either the domain that originated the route, or
      the domain that advertised the route to the local system (adjacent
      domain). Care must be taken when a BIS selects a new route that
      can't be announced to a particular external peer, while the
      previously selected route was announced to that peer.
      Specifically, the local system must explicitly indicate to the
      peer that the previous route is now infeasible.

      IDRP implementations should allow a domain to prefer a particular
      path to a destination (when more than one path is available). At



Yakov Rekhter, Paul Traina                                    [Page 107]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      the minimum an implementation shall support this functionality by
      allowing to administratively assign a degree of preference to a
      route based solely on the IP address of the neighbor the route is
      received from.  The allowed range of the assigned degree of
      preference shall be between 0 and 2^(31) - 1.

      IDRP implementations should allow a domain to ignore routes with
      certain domains in the RD_PATH path attribute. Such function can
      be implemented by assigning "infinity" as "weights" for such
      domains. The route selection process must ignore routes that have
      "weight" equal to "infinity".


11. Operations over Switched Virtual Circuits

   When using IDRP over Switched Virtual Circuit (SVC) subnetworks it
   may be desirable to minimize traffic generated by IDRP.
   Specifically, it may be desirable to eliminate traffic associated
   with periodic KEEPALIVE messages. IDRP includes a mechanism for
   operation over switched virtual circuit (SVC) services which avoids
   keeping SVCs permanently open and allows it to eliminates periodic
   sending of KEEPALIVE messages.

   This section describes how to operate without periodic KEEPALIVE
   messages to minimize SVC usage when using an intelligent SVC circuit
   manager. The proposed scheme may also be used on "permanent"
   circuits, which support a feature like link quality monitoring or
   echo request to determine the status of link connectivity.

   The mechanism described in this section is suitable only between the
   BISs that are directly connected over a common virtual circuit.


11.1. Establishing an IDRP Connection

   The feature is selected by specifying zero Hold Time in the OPEN
   BISPDU.


11.2. Circuit Manager Properties


   The circuit manager must have sufficient functionality to be able to
   compensate for the lack of periodic KEEPALIVE BISPDU:

      It must be able to determine link layer unreachability in a
      predictable finite period of a failure occurring.




Yakov Rekhter, Paul Traina                                    [Page 108]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


      On determining unreachability it should:

         - start a configurable dead timer (comparable to a typical Hold
         timer value).

         - attempt to re-establish the Link Layer connection.

      If the dead timer expires it should:

         - send a deactivate indication to IDRP FSM.

      If the connection is re-established it should:

         - cancel the dead timer.

         - transmit any queued BISPDUs.




11.3. Combined Properties

   Some implementations may not be able to guarantee that the IDRP
   process and the circuit manager will operate as a single entity; i.e.
   they can have a separate existence when the other has been stopped or
   has crashed.

   If this is the case, a periodic two-way poll between the IDRP process
   and the circuit manager should be implemented. If the IDRP process
   discovers the circuit manager has gone away it should close all
   relevant BIS-BIS connections.  If the circuit manager discovers the
   IDRP process has gone away it should close all its BIS-BIS
   connections associated with the IDRP process and reject any further
   incoming BIS-BIS connections.


12. Security Considerations

   Security issues are not discussed in this document.












Yakov Rekhter, Paul Traina                                    [Page 109]


Internet Draft        draft-ietf-idr-idrp2-00.txt              June 1996


13. Acknowledgements

   This document is based on a combination of of IDRP version 1
   (ISO10747) and BGP-4. As such, it borrows heavily from both of its
   ancestors. Note that during their development both of the ancestors
   (IDRP and BGP-4) borrowed heaviliy from each other. Thus we would
   like to acknowledge all the individuals who contributed to the design
   of both BGP and IDRP.  We also like to acknowledge all the members of
   both the Inter-Domain Routing Working Group of the IETF and the
   X3S3.3 Working Group of ANSI where BGP and IDRP were designed.


14. References



15. Editors's Addresses


   Yakov Rekhter
   cisco Systems, Inc.
   170 Tasman Dr.
   San Jose, CA 95134
   Phone: (914) 528-0090
   email: yakov@cisco.com

   Paul Traina
   Juniper Networks, Inc.
   101 University Ave.
   Suite 240
   Palo Alto, CA 94301
   Phone: (415) 614-4140
   email: pst@jnx.com


















Yakov Rekhter, Paul Traina                                    [Page 110]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/