One document matched: draft-hares-idrp-02.txt
Differences from draft-hares-idrp-01.txt
Network Working Group Susan Hares
INTERNET DRAFT NSFNET/MERIT
June 1992
IDRP for IP
Status of this memo
This memo specifies the adaptation of the ISO Inter-Domain Routing
Protocol ([1]) that enables it to be used as an Inter-Autonomous
System routing protocol in the TCP/IP Internet. IDRP with this
adaptation will be called "IDRP for IP" in this document. Dual
IDRP, that is, a single instance of IDRP that can simultaneously
support Inter-Domain/Inter-Autonomous System routing in the TCP/IP
and OSI Internets is outside the scope of this document. The whole
family of IDRP related documents and their functions are listed in
[2].
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
1. Acknowledgements
A large set of thanks to Dave Katz(cisco) who helped edit this help
with the document. I would also like to express my thanks to Scott
Brim (Cornell University) for his review and constructive comments.
2. Overview
IDRP ([1]) is defined as the protocol for exchange of
Inter-Domain routing information between routers to support
forwarding of ISO 8473 (Connectionless Network Layer Protocol
(CLNP))[3] PDUs. This document contains the appropriate
Expiration Date December 1992 [Page 1]
RFC DRAFT June 1992
adaptation of the IDRP protocol definition that enables it to be used
as protocol for the exchange of inter-autonomous system information
among routers to support the forwarding of IP packets across multiple
autonomous systems.
The adaptation is defined is such a way that a Dual IDRP will be
able to fully interoperate with IDRP for IP.
3. The Adaptation Layer
The Inter-Domain Routing Protocol (IDRP) or, more formally,
"The Protocol for the Exchange of Inter-Domain Routeing
information among Intermediate Systems to support Forwarding
of ISO 8473 PDUs (IDRP)"
is the inter-domain routing protocol defined to support the
forwarding of Connectionless Network Layer Protocol (CLNP) [ISO
8473] packets that traverse multiple routing domains.
This ISO protocol does not require participating domains to
support any specific ISO Intra-Domain protocol, such as IS-IS (ISO
IS 10589)[4], nor does it require participating routers to run ES-IS
(ISO 9542)[5]. The only requirements imposed by the protocol on the
participating routers is that the protocol information can be
exchanged between them over a connectionless network layer, which
in the case of OSI is CLNP, and that the network layer connectivity
between routers within a single routing domain should be
provided by means outside of IDRP (e.g., via some intra-domain
routing protocol). IDRP does not place any restrictions on the
structure of reachability information, as long it can be expressed
as an arbitrary set of variable length address prefixes.
Since IP can provide connectionless service between routers, and
since reachable IP destinations can be expressed as IP address
prefixes, IDRP can be easily adapted to be an Inter-Autonomous
system routing protocol which can be used in the pure TCP/IP
Internet.
IDRP for IP provides a set of mechanisms to support "classless"
inter-autonomous system routing. These mechanisms include support for
treating IP reachability information as a prefixes of variable
length, without any distinction between class A/B/C network
addresses. Thus, IDRP for IP is well suited to support the proposed
Expiration Date December 1992 [Page 2]
RFC DRAFT June 1992
supernetting scheme [8].
This document assumes that the reader is familiar with the
following documents:
- IP protocol specification (RFC 791)[6], and
- IDRP specification (CD/DIS 10747).
A few definitions are in order to aid the reader:
BIS - a Boundary Intermediate System (or border router)
BISPDU - an IDRP message exchanged between a pair of BISs
FIB - Forwarding Information Base (IP forwarding table)
IS - Intermediate System (router)
NET - Network Entity Title - an ISO network address for a
router
NLRI - Network Layer Reachability Information (set of reachable
destinations)
NPDU - an IP packet
PDU - a packet
SNPA - SubNetwork Point of Attachment
While conceptually it is possible to define a mapping between the
security field of an IP header and IDRP NPDU-derived Distinguishing
Attributes, this mapping is outside the scope of this document. In
addition, address-specific QoSs (Source Specific QoS and Destination
Specific QoS) have no counterparts in IP. Therefore, the use of the
following IDRP Distinguishing Attributes for IP packets will not be
defined in this document:
- Priority
- Source Specific QOS
- Destination Specific QOS
- Source Specific Security
Expiration Date December 1992 [Page 3]
RFC DRAFT June 1992
- Destination Specific Security
Mapping between the following IDRP Distinguishing Attributes:
- Transit Delay
- Residual Error
- Expense
- Capacity
and the IP Type of Service (TOS) parameters is defined in Section
4.2.3.
Note that an implementation that does not support any of the
NPDU-derived Distinguishing Attributes can fully interoperate
with an implementation that does support them. Therefore, an IDRP for
IP implementation that will support routing sensitive to the
parameters present in the TOS field of the IP header will be
compatible with the implementation that does not provide such
support.
4. Implementor's Guide for IP specific functions.
In order to implement IDRP for IP, only a subset of the features of
the IDRP protocol must be implemented.
4.1 Features in IDRP which shall not be implemented
The functions of the IDRP protocol which shall not be implemented
for IDRP for IP are those functions which deal with the following
(all references are with respect to the IDRP document [1]):
- Source Specific QOS according to section 8.12.12
- Destination Specific QOS according to section 8.12.13
- Source Specific Security according to section 8.12.16
- Destination Specific Security according to section 8.12.17
- Priority according to section 8.12.19
Expiration Date December 1992 [Page 4]
RFC DRAFT June 1992
- Forwarding CLNP packets according to section 9
- The interface to CLNP (ISO 8473) according to section 10
- support of the Network Management information described in the
IDRP GDMO according to section 12
Therefore, with IDRP for IP the following items dealing with CLNP in
the IDRP conformance clause (section 13.1 of [1]) shall not be
implemented:
- clause (d): SOURCE SPECIFIC QOS, DESTINATION SPECIFIC QOS,
SOURCE SPECIFIC SECURITY, DESTINATION SPECIFIC SECURITY, PRIORITY
- clause (r)
- clause (s)
- clause (t)
4.1.1 PICS Table Information
The PICS (Protocol Implementation Conformance Statement) provides a
convenient and concise mechanism to define which function need and
need not be implemented for IDRP for IP. All references in this
section are with respect to [1]. All items with PICS Status as
Optional need not be implemented in IDRP for IP. Specifically, IDRP
for IP does not require (and, indeed, does not need) support for the
following items in A.4.10 Table 16:
TDLY, RERR, EXP, SQOS, DQOS, SSEC, DSEC, CAPY, PRTY,
in A.4.10 Table 17:
TDLYP, RERRP, EXPP, SQOSP, DQOSP, SSECP, DSECP, CAPYP, PRTYP,
in A.4.8 Table 14 (IDRP CLNS Forwarding), and BISMGT in A.4.3
Table 9 (ISO Network Management support).
Implementation of all other items with Optional Status not listed in
the previous paragraph is optional.
4.2 Features in IDRP which shall be implemented
An implementation of IDRP for IP shall contain all mandatory
features of IDRP, except those mentioned in Section 4.1. In
addition, a BIS for IDRP for IP shall implement:
Expiration Date December 1992 [Page 5]
RFC DRAFT June 1992
1.) an interface to the IP protocol described in section 4.2.1 of
this document
2.) the ability to identify and extract IP reachability and IP
forwarding information as described in section 4.2.2 of this
document
3.) IP packet forwarding functions described in section 4.2.4 of
this document
4.) domain configuration information listed in section 4.2.6 of
this document
5.) the advertisement of IP address information in NLRI as
described in section 4.3 of this document
4.2.1 Exchanging IDRP information between IP-only routers.
IDRP assumes pair-wise communication between participating BISs.
IDRP information is carried between a pair of BISs in the form of
BISPDUs. In the case of IDRP for IP, these BISPDUs are carried in
the data field of IP packets of protocol type X.
4.2.2 Identifying IP reachability and IP forwarding information
NLRI passed by the UPDATE PDU has an indication of protocol type. An
implementation of IDRP for IP shall have the following values in the
NLRI field:
Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI)
Proto_Length: 1
Protocol: x'CC'
Addr_Length: variable
Addr_Info: IP address prefixes, encoded in binary
An implementation of IDRP for IP shall ignore any NLRI indicating a
different protocol type.
The NEXT_HOP attribute in the UPDATE PDU also has a Type field
which indicates the protocol family for the address of the
NEXT_HOP. An implementation of IDRP for IP shall have the following
Expiration Date December 1992 [Page 6]
RFC DRAFT June 1992
values in the NEXT_HOP field:
Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI)
Proto_Length: 1
Protocol: x'CC'
Length of NET: 4
NET of Next Hop: an IP address, encoded in binary
SNPA information: as appropriate for the subnetwork type in use
An implementation of IDRP for IP shall ignore any NEXT_HOP
information indicating a different protocol type.
4.2.3 Mapping between IP Type Of Service parameters and IDRP
Distinguishing Attributes.
IDRP for IP supports the following distinguishing attributes:
- Transit Delay
- Residual Error
- Expense
- Capacity
A conformant implementation is required to recognize these attributes
when received from an adjacent BIS.
IP defines four distinct Type of Service Parameters (see [X]):
- minimize delay
- maximize throughput
- maximize reliability
- minimize monetary cost
An IP packet can carry at most one of the above ToSs. Therefore, a
RIB in IDRP can have at most one distinguishing attribute.
Expiration Date December 1992 [Page 7]
RFC DRAFT June 1992
An IP-derived distinguishing attribute is defined as the ToS
parameter extracted from an IP packet that needs to be forwarded by a
BIS.
If the value of the MBZ bit (7th bit) of the Type of Service octet in
the IP header is 1, then the IP-derived distinguishing attribute is
mapped into the "default" RIB-Att (RIB with no distinguishing
attributes). Otherwise, the mapping between the IP-derived
distinguishing attribute and a RIB-Att is defined as follows:
IP ToS IDRP Distinguishing Attribute
------ -----------------------------
minimize delay Transit Delay
maximize throughput Capacity
maximize reliability Residual Error
minimize monetary cost Expense
4.2.4 Forwarding of IP packets
This section is intended to define the same function for IP
packets as is defined for CLNP packets in the "Forwarding Process for
CLNS" (Section 9 in [1]).
It is assumed that a BIS is capable of distinguishing between a FIB
constructed by means of an intra-autonomous system routing protocol
and a FIB constructed by means of IDRP.
After a BIS determines the packet's destination IP address, the BIS
shall proceed as follows:
a.) If the destination address depicts a system located within the
autonomous system of the receiving BIS, then the BIS shall forward
the IP packet to any of the ISs listed in the managed object
INTRA-IS. That is, any further forwarding of the IP packet is the
responsibility of the intra-autonomous system routing protocol;
otherwise,
b.) the destination system is located in a different autonomous
system, and the local BIS shall perform the following actions:
Expiration Date December 1992 [Page 8]
RFC DRAFT June 1992
It shall determine the IP-Derived Distinguishing Attribute,
according to clause 4.2.3. It shall next apply the procedures
of clause 4.2.3 to determine if the IP-Derived Distinguishing
Attribute matches any of the RIB-Atts of the information
base(s) supported by the local BIS. If such a match is found,
then the FIB with the matched RIB-Atts is used for forwarding.
If the procedures of clause 4.2.3 identify a non-default IP-
Derived Distinguishing Attribute, but the local BIS does not
maintain a FIB with the matching RIB-Atts, or the local BIS
maintains a FIB with the matching RIB-Atts but this FIB does
not have a route to the destination, then the local system sets
the MBZ bit (the 7th bit) of the Type Of Service field in the
IP packet to 1 and uses FIB with no distinguishing attributes.
The incoming IP packet shall be forwarded based on the FIB
entry that has the longest IP address prefix that matches the
destination of the incoming IP packet, as follows:
1.) If the entry in the inter-domain FIB that
corresponds to the destination address of an incoming
IP packet contains a NEXT_HOP that identifies an interface
of a BIS such that the interface is attached to a subnet
shared with the local BIS, then the IP packet shall be
forwarded directly to the BIS indicated in the NEXT_HOP
entry over that interface; otherwise,
2.) if the entry in the inter-domain FIB that corresponds to
the destination address of the incoming IP packet contains
a NEXT_HOP entry that identifies an interface of a BIS such
that the interface is not attached to any of the subnets
attached to the local BIS, then the local BIS has the
following options:
a.) Encapsulate the IP packet
The local BIS may encapsulate the IP packet, using its
own IP address as the source address and the IP
address of the next-hop BIS contained in the NEXT_HOP
entry as the destination address.
b.) Use paths calculated by the intra-autonomous system
routing protocols
Expiration Date December 1992 [Page 9]
RFC DRAFT June 1992
The local BIS may query the FIB constructed by the
intra-autonomous system routing protocols to ascertain
if that FIB contains a route to the destination
system. If that is the case, and if the path
constructed by the intra-autonomous system routing
protocols delivers the IP packet to the appropriate
next-hop BIS, then the IP packet may be forwarded
using the FIB constructed by the intra-autonomous
system routing protocols.
Table 1) PICS Proforma for IDRP: IP packet forwarding
ITEM Questions/Features Refer. Status Support
----------------------------------------------------------------
IP_EXTFWD Does the BIS correctly forward 5.3 M Yes___
IP packets with destinations
outside its routing domain?
IP_INTFWD Does the BIS correctly forward 5.3 M Yes___
IP packets with destinations
inside its routing domain?
The "ITEM" column describes the feature in the IP forwarding
function that the IDRP implementation is to provide. The
"Question/Feature" section seeks to describe the feature. The
Reference is the section in this document that describes this
feature. The status gives an indication of "M" - Mandatory
feature for an IDRP implementation or "O" - optional feature. The
"Support" column is a column for the implementor to check whether
this feature is available in a particular
implementation.)
Expiration Date December 1992 [Page 10]
RFC DRAFT June 1992
4.2.5 Confederations of Autonomous Systems.
IDRP supports the ability to group Routing Domains into a Routing
Domain Confederation. Likewise, IDRP for IP supports the ability to
group a collection of autonomous systems into a Confederation of
autonomous systems. With respect to the IDRP document in the context
of IDRP for IP, the terms "Routing Domain Confederation" and
"Confederation of autonomous systems" should be treated as
synonymous.
4.2.6 Domain Configuration Information
Correct Operation of IDRP described in [1] 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. The specific
format of this information is defined in the RFC IDRP MIB document
[7]. The information required by a BIS that implements the IDRP for
IP protocol is:
a.) Location and identity of adjacent Intra-Domain ISs (routers)
The MIB table INTRA-IS 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 Intra-IS table support the intra-domain
routing protocol of this autonomous system, 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
listed in the INTRA- IS 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 INTERNAL-BIS, which contains a
set of IP addresses which identify the BISs in the domain.
c.) Location and identity of BISs in adjacent domains:
Expiration Date December 1992 [Page 11]
RFC DRAFT June 1992
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 EXTERNAL-BIS-NEIGHBORS, 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 INTERNAL-SYSTEMS. The IP
network address information can include:
- host addresses,
- Network and subnet mask sequences, or
- Supernetting network sequences.
Please refer the IDRP MIB specification for the specific
details of the INTERNAL-SYSTEMS table.
The IDRP for IP protocol provides support for
the Supernetting approach described in [8] for the assignment
and aggregation of IP network reachability information. The
IDRP for IP Usage document [9] provides details on how to:
- carry IP information in the IDRP NLRI, and
- use the Supernetting approach to aggregate IP network
reachability information.
e.) LOCAL RDI
This information is contained in managed object LOCAL-RDI; it
is the RDI of the routing domain in which the BIS is
located. As specified in section 8 of this document, the RDI
for an IDRP for IP routing domain has an NSAP Address format.
This NSAP Address format is built out of a fixed "header" and
the autonomous system number of this autonomous system (routing
domain).
f.) RIB-AttSet
Expiration Date December 1992 [Page 12]
RFC DRAFT June 1992
The RIB-AttSet contains information about the QoS functions
a BIS will support. As described in section 3, this can be
none, any, or all of the Transit Delay, Residual Error,
Expense, and Capacity distinguishing attributes.
g.) 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
RDC-Config.
Each RDC is identified by an RDI which has the format
described in section 8 of this document.
h.) Local SNPAs
The LOCAL SNPA MIB table contains a list of SNPAs (Subnetwork
Points of Attachment, i.e. subnetwork addresses) per IP address
of the BIS.
4.3 Advertising NLRI information for IP addresses
The NLRI field in an UPDATE PDU contains IP address information
about systems that reside within a given routing domain or whose IP
address space is under the control of the administrator of the
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 from offline to
online.
End systems (hosts) and Intermediate systems (routers) within a RD
using IDRP may use any IP address that is valid within the IP
context. Within the NLRI, the address information for a set of IP
addresses may be represented by an IP prefix. An IP prefix is the
sequence of bits in a 4 byte IP address which are common between
a set of IP addresses.
For example, the addresses 192.5.0.0 through 192.5.255.255 have the
first 16 bits of the address information in common. These 16 bits
of the IP address may be called an IP prefix which represents
the set of IP addresses 192.5.0.0 through 192.5.255.255.
Expiration Date December 1992 [Page 13]
RFC DRAFT June 1992
An IP prefix must contain a contiguous set of bits starting at the
most significant bit, but the bits may cover any part of the 4 byte
IP address. The following guidelines for inclusion of IP address
prefixes in the NLRI field of the UPDATE PDUs originated within a
routing domain will provide efficient use of this protocol:
a.) Only IP prefixes representing IP addresses that are within the
control of the Administrator of a given routing domain may be
reported in the NLRI field for a RD. These IP prefixes can
represent IP addresses for systems which are:
- online,
- offline, or
- allocated to the network, but not yet allocated to a machine.
b.) IP prefixes representing IP addresses outside of the RD
administrator's control shall not be included in the NLRI.
c.) For efficient use of the protocol, the WITHDRAW ROUTES field
should not be used to report the NLRI of systems that are offline.
This field should be used only to advertise IP prefixes for IP
addresses that are no longer under the control of the
administrator of the local routing domain, regardless of
whether the systems are online or offline.
A conformant implementation is required to have the ability to
specify when an aggregated route may be generated out of partial
routing information. A BIS at the border of an autonomous system (or
group of autonomous systems) must be able to generate an aggregated
route for a whole set of NLRIs over which is has administrative
control, even when not all of them are reachable at the same time.
4.4 Exchanging information with EGP2
The following guidelines for exchanging routing information between
IDRP and EGP2 are consistent with the ones presented in [8].
To provide for graceful migration, a BIS may participate in EGP2 as
well as in IDRP. Thus, a BIS may receive IP reachability information
by means of EGP2, as well as by means of IDRP for IP. The
information received by EGP2 can be injected into IDRP with the
EXT_INFO path attribute. Likewise, the information received via
Expiration Date December 1992 [Page 14]
RFC DRAFT June 1992
IDRP can be injected into EGP2 as well. In the latter case, however,
one needs to be aware of the potential information explosion when a
given IP prefix received from IDRP denotes a set of consecutive A/B/C
class networks. Injection of IDRP-received NLRI that denotes IP
subnets requires the BIS to inject the corresponding network into
EGP2. In all cases the local system has to provide mechanisms that
allow for the control of information exchange between EGP2 and IDRP.
Specifically, a conformant implementation is required to allow export
of only non-aggregated NLRI.
4.5 Exchanging information with BGP-3
The following guidelines for exchanging routing information between
IDRP and BGP-3 are consistent with the ones presented in [8].
To provide for graceful migration, a BIS may participate in BGP-3 as
well as in IDRP. Thus, a BIS may receive IP reachability information
by means of BGP-3, as well as by means of IDRP. The information
received by BGP-3 can be injected into as follows:
- translate each AS_PATH into an RD_PATH of the type RD_SEQUENCE
(note that such translation requires reversing the order of
elements).
- if the ORIGIN path attribute in BGP-3 denotes anything else but
IGP, the BGP-3 derived information shall be transmitted with the
EXT_INFO IDRP path attribute.
A BIS may inject the information received by IDRP into BGP-3 as
follows. Translate RD_PATH into AS_PATH, regardless of whether the
RD_PATH contains path segments of the type RD_SEQUENCE or RD_SET. If
the IDRP route carries EXT_INFO path attribute, set the value of the
ORIGIN path attribute to INCOMPLETE; otherwise set the value of the
ORIGIN path attribute to IGP. While injecting IDRP derived IP NLRI
into BGP-3, one needs to be aware of the potential information
explosion when a given IP prefix denotes a set of consecutive A/B/C
class networks. Injection of IDRP-derived NLRI that denotes IP
subnets requires the BIS to inject the corresponding network into
BGP-3. In all cases, the local system has to provide mechanisms that
allow the control of information exchange between BGP-3 and IDRP.
Specifically, a conformant implementation is required to support
export of only non-aggregated NLRI.
Expiration Date December 1992 [Page 15]
RFC DRAFT June 1992
The exchange of routing information via BGP-3 between a BIS
participating in IDRP for IP and a pure BGP-3 speaker may occur only
at domain (autonomous system) boundaries.
5 Determining the forwarding address (Next Hop)
NEXT_HOP information shall be derived from the NEXT_HOP attribute in
the UPDATE BISPDU. If that attribute is not present, it shall be
derived from the source IP address of the IP packet that carries
the UPDATE BISPDU.
6 Routing Domain Identifiers used for both IP and OSI
Routing Domain Identifiers (RDIs) are identifiers used in BISPDUs
to uniquely identify individual routing domains and routing domain
confederations.
For ease of administration, the RDI is taken out of the NSAP
address space. However, the RDI is just a number which identifies
the routing domain, and need not bear any relationship to any
reachable addresses within the domain.
For ease of interworking with other IP inter-autonomous system
routing protocols, The RDI used for an autonomous system running IDRP
for IP should be derived from an appropriately assigned Autonomous
System Number as follows:
xx.xx.xx.xx.aa.aa
Where xx.xx.xx.xx is a unique prefix assigned by a valid
addressing authority (TO BE DETERMINED), and aa:aa is the
autonomous system nummber.
This encoding of the RDI contains a "fixed header" (the
xx.xx.xx.xx sequence) plus the AS value.
(Note: While AS values are currently 2 octets long, IDRP allows
Routing Domain Identifiers to be of arbitrary length. Thus, if the
space of AS numbers is expanded to be greater than two octets, this
may be accommodated by simply lengthening the above encoding--the AS
number following the fixed header is considered to be right
justified, and its size can be unambiguously determined from the RDI
Expiration Date December 1992 [Page 16]
RFC DRAFT June 1992
length.)
7 Deployment Guidelines for IDRP for IP
The correct and efficient operation of the IDRP protocol requires
that certain guidelines are used for deployment with ISO routing
Domains. Some equivalent deployment guidelines for IDRP for IP are
required within Autonomous Systems. These guidelines
represent only the required deployment guidelines, and not details on
the usage of IDRP for IP in the Internet. The details of the Usage
of IDRP for IP are contained in [9].
7.1 Minimum configuration of an Autonomous System
An autonomous system using IDRP for IP must as a minimum contain:
- one BIS, and
- one BIS capable of delivering NPDUs to the intra-domain routing
function if the AS contains hosts.
7.2 Multiple autonomous systems per IP prefix
An IP prefix carried in the NLRI field of a route originated by a BIS
in a given autonomous system is to be associated with only that
autonomous system; that is, no system identified by that prefix
should reside in different autonomous systems. However, the only
implication of violating the above assumption is potentially
ambiguous routing, if IP addresses are not globally unique. In all
other cases, IDRP provides correct forwarding, even if the above
assumption is violated.
7.3 Multiple IDRP sessions between the same pair of routers
An IP router may have multiple IP addresses, one for each interface.
In contrast, an OSI Intermediate System has only one Network Entity
Title (network address). An OSI BIS thus may not have multiple
IDRP sessions with another BIS, since the NET is unique and there is
no mechanism for multiplexing sessions. However, an IP router may
Expiration Date December 1992 [Page 17]
RFC DRAFT June 1992
potentially have multiple IDRP sessions with another router, since
each BIS may have multiple IP addresses, and one BIS may not be able
to ascertain that those addresses correspond to the same BIS.
Multiple IDRP sessions between IP BISs may not be efficient,
but they are not illegal, nor do they impact the robustness of
the IDRP for IP protocol; they will simply appear as multiple
paths to the same neighboring AS. One possible way of avoiding
multiple parallel IDRP sessions between a pair of BISs within a
single autonomous system is to bind all source addresses of
outgoing BISPDUs to the IP address of a particular interface of
the BIS. Likewise, for a pair of BISs located in adjacent
autonomous systems, binding the source addresses to a single
address of an interface attached to a common subnetwork allows
for the elimination of multiple parallel sessions.
9. References
[1] ISO/IEC DIS 10747 - Information Processing Systems -
Telecommunications and Information Exchange between Systems -
Protocol for Exchange of Inter-domain Routeing Information among
Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1992.
[2] RFC xxx - (Sue Hares) IDRP Document Family Tree
[3] ISO 8473 - Information Processing Systems - Data
Communications - Protocol for Providing the Connectionless-mode
Network Service, 1988.
[4] ISO/IEC 10589 - Information Processing Systems -
Telecommunications and Information Exchange between systems -
Intermediate System to Intermediate System Intra-Domain routeing
information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service (ISO
8473), 1992.
[5] ISO 9542 - Information Processing Systems -
Telecommunications and information exchange between systems - End
system to Intermediate system routeing exchange protocol for use in
conjunction with the Protocol for providing the connectionless-mode
network service (ISO 8473)
[6] RFC 791 (Jon Postel, editor) - Internet Protocol - DARPA
Internet Program Protocol Specification (September 1981)
[7] RFC xxx (Susan Hares) - IDRP MIB
Expiration Date December 1992 [Page 18]
RFC DRAFT June 1992
[8] Fuller, V., Li, T., Yu, J, and Varadhan, K., "Supernetting: an
Address Assignment and Aggregation Strategy", Internet Draft, April
1992
[9] RFC xxx (Susan Hares) - Usage of IDRP for IP
Expiration Date December 1992 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 02:50:50 |