[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.123, available from
https://tools.ietf.org/tools/rfcmarkup/