Network Working Group Susan Hares
Request for Comments: DRAFT NSFNET/MERIT
draft-ietf-ipidrp-sip-01.txt October 1993
IDRP for SIP
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-domain routing
protocol in the Internet that supports SIP/IPAE ([6], [8]). IDRP with
this adaptation will be called "IDRP for SIP" in this document.
Multiprotocol IDRP, that is, a single instance of IDRP that can
simultaneously support Inter-Domain/Inter-Autonomous System routing
for multiple network layer protocols (e.g. SIP, IP, CLNP) Internets
is outside the scope of this document.
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. 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.
The network reachability information exchanged via IDRP provides
sufficient information to detect routing loops and enforce routing
decisions based on performance preference and policy constraints as
outlined in RFC 1104 [7]. In particular, IDRP exchanges routing
information containing full domain-level paths and enforces routing
policies based on configuration information.
IDRP may be viewed as an extension of BGP-4 [12] that provides (among
other things) much better scaling with respect to support for routing
Expiration Date April 1994 [Page 1]
draft-ietf-ipidrp-sip-01.txt October 1993
- 2 -
information aggregation and reduction based on CIDR, as well as
stronger capabilities for policy based routeing (e.g. ability to
impose control over transit traffic). IDRP also provides capability
to carry reachability and forwarding information associated with
multiple network layer protocols (e.g. SIP, IP, CLNP).
This document contains the appropriate adaptation of the IDRP
protocol definition that enables it to be used as a protocol for the
exchange of inter-domain system routing information among routers to
support the forwarding of SIP packets across multiple domains.
The adaptation is defined is such a way that a Multiprotocol IDRP
will be able to fully interoperate with IDRP for SIP.
2. Terminology
This document assumes that the reader is familiar with the
following documents:
- SIP protocol specification [6], and
- IDRP specification (IS 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 SIP packet
PDU - a packet
SNPA - subnetwork point of attachment (MAC address)
Expiration Date April 1994 [Page 2]
- 3 -
draft-ietf-ipidrp-sip-01.txt October 1993
3. Assumptions
The IDRP for SIP protocol assumes that within a single connected
internet network addresses are unique. The uniqueness of SIP
addresses is assumed to be provided by means outside of the protocol.
The IDRP for SIP protocol cannot be guaranteed to work in an
environment where network addresses within a single connected
internet are not unique.
All of the discussions in this document are based on the assumption
that the Internet is a collection of arbitrarily connected domains.
That is, the Internet will be modeled as a general graph whose nodes
are domains and whose edges are connections between pairs of domains.
The classic definition of a domain is a set of routers under a single
technical administration, using an interior gateway protocol and
common metrics to route packets within the domain and using an
exterior gateway protocol to route packets to other domains. Since
this classic definition was developed, it has become common for a
single domain to use several interior gateway protocols and sometimes
several sets of metrics within a domain. The use of the term domain
here stresses the fact that, even when multiple IGPs and metrics are
used, the administration of a domain appears to other domains to have
a single coherent interior routing plan and presents a consistent
picture of which networks are reachable through it.
Domains are assumed to be administered by a single administrative
entity, at least for the purposes of representation of routing
information to systems outside of the domain.
4. 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.
While this protocol was developed within ISO, it make few, if any,
ISO-specific assumptions. In particular, it 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
Expiration Date April 1994 [Page 3]
- 4 -
draft-ietf-ipidrp-sip-01.txt October 1993
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 SIP can provide connectionless service between routers, and
since reachable SIP destinations can be expressed as SIP address
prefixes, IDRP can be easily adapted to be an inter-domain routing
protocol which can be used in the pure SIP Internet.
Certain IDRP Distinguishing Attributes may be used in conjuction with
the Flow Label field in the SIP header. At the present moment the
content of that field is specified to be an extension of the IP Type
of Service (Tos) field. Mapping between the following IDRP
Distinguishing Attributes
- Transit Delay
- Residual Error
- Expense
and the SIP Type of Service (TOS) parameters is defined in Section
5.2.3 of this document.
While conceptually it should be possible to define mapping between
other IDRP Distinguishing Attributes and the Flow Label, such
definition is outside the scope of this document. Therefore, the use
of the following IDRP Distinguishing Attributes for SIP packets will
not be defined in this document:
- Priority
- Locally Defined QOS
- Security
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
SIP implementation that will support routing sensitive to the
parameters present in the TOS field of the SIP header will be
compatible with the implementation that does not provide such
support.
Expiration Date April 1994 [Page 4]
- 5 -
draft-ietf-ipidrp-sip-01.txt October 1993
5. Implementor's Guide for SIP specific functions.
In order to implement IDRP for SIP, only a subset of the features of
the IDRP protocol must be implemented.
5.1 Features in IDRP which shall not be implemented
The functions of the IDRP protocol which shall not be implemented
for IDRP for SIP are those functions which deal with the following
(all references are with respect to the IDRP document [1]):
- Locally Defined QOS according to section 7.12.11
- Security according to section 7.12.14
- Priority according to section 7.12.16
- Forwarding CLNP packets according to section 8
- The interface to CLNP according to section 9
- support of the Network Management information described in the
IDRP GDMO according to section 11
Therefore, with IDRP for SIP the following items dealing with CLNP in
the IDRP conformance clause (section 12.1 of [1]) shall not be
implemented:
- clause (d): Locally Defined QOS, Security, Priority
- clause (r)
- clause (s)
- clause (t)
5.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 SIP. All references in this
section are with respect to [1]. All items with PICS Status as
Optional need not be implemented in IDRP for SIP. Specifically, IDRP
for SIP does not require (and, indeed, does not need) support for
Expiration Date April 1994 [Page 5]
- 6 -
draft-ietf-ipidrp-sip-01.txt October 1993
the following items:
A.4.3 Table 9:
MGT
A.4.8 (Table 14):
PSRCRT, DATTS
A.4.11 (Table 17):
LQOSG, SECG, PRTY
A.4.11 (Table 18):
LQOSP, SECP, PRTYP
A.4.11 (Table 19):
LQOSR, SECR, PRTYR
Implementation of all other items with Optional Status not listed in
the previous paragraph is optional.
5.2 Features in IDRP which shall be implemented
An implementation of IDRP for SIP shall contain all mandatory
features of IDRP, except those mentioned in Section 5.1 of this
document. In addition, a BIS for IDRP for SIP shall implement:
- an interface to the SIP protocol described in section 5.2.1 of
this document
- the ability to identify and extract SIP reachability and SIP
forwarding information as described in section 5.2.2 of this
document
- SIP packet forwarding functions described in section 5.2.6 of
this document
- domain configuration information listed in section 5.2.5 of
this document
- the advertisement of SIP address information in NLRI as
described in section 5.3 of this document
Expiration Date April 1994 [Page 6]
- 7 -
5.2.1 Exchanging IDRP information between SIP-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 SIP, these BISPDUs are carried in
the data field of SIP packets of protocol type %%TBD%%.
If a domain doesn't support SIP internally (some of the routers
within the domain are not SIP-capable), then SIP packets carrying
BISPDU shall be carried accross the domain using IPAE [8].
5.2.2 Identifying SIP reachability and SIP forwarding information
NLRI passed by the UPDATE PDU has an indication of the protocol
family for the destinations depicted by the NLRI. The indication is
encoded in the Proto_type, Proto_length and Protocol fields. An
implementation of IDRP for SIP shall have the following values in the
NLRI:
Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI)
Proto_Length: 6
Protocol: hexadecimal "80:00:00:00:86:DD"
Addr_Length: variable (the value shall be between 2 and 64)
Addr_Info: SIP address prefixes, encoded in binary, as follows:
This is a variable length field that contains a list of SIP
address prefixes for the routes that are being advertised.
Each SIP 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 SIP
Expiration Date April 1994 [Page 7]
- 8 -
address prefix. A length of zero indicates a prefix that
matches all SIP addresses (with prefix, itself, of zero
octets).
b) Prefix:
The Prefix field contains SIP 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.
An implementation of IDRP for SIP shall ignore any NLRI indicating a
different protocol type.
The NEXT_HOP attribute in the UPDATE PDU also has a Proto_type,
Proto_Length and Protocol fields which indicate the protocol family
for the address of the NEXT_HOP. An implementation of IDRP for SIP
shall have the following values in the NEXT_HOP field:
Proto_Type: 1 (ISO/IEC TR 9577 IPI/SPI)
Proto_Length: 6
Protocol: hexadecimal "80:00:00:00:86:DD"
Length of NET: 8
NET of Next Hop: a SIP address, encoded in binary
SNPA information: as appropriate for the subnetwork type in use
An implementation of IDRP for SIP shall ignore any NEXT_HOP
information indicating a different protocol type.
Note that the Protocol component of the NLRI field and the NEXT_HOP
field consists of the IPI/SPI indicating an IEEE 802.1a SNAP header
followed by the IEEE 802.1a SNAP header itself.
5.2.3 Mapping between SIP Type Of Service parameters and IDRP
Distinguishing Attributes.
SIP defines four distinct Type of Service (TOS) Parameters:
- minimize delay
Expiration Date April 1994 [Page 8]
- 9 -
- maximize throughput
- maximize reliability
- minimize monetary cost
A SIP packet can carry at most one of the above TOSs in its Flow
Label field. Therefore, a RIB in IDRP for SIP can have at most one
Distinguishing Attribute.
IDRP for SIP supports the following Distinguishing Attributes:
- Transit Delay
- Residual Error
- Expense
A conformant implementation is required to recognize these attributes
when received from an adjacent BIS.
A SIP-derived Distinguishing Attribute is defined as the TOS
parameter extracted from a SIP packet that needs to be forwarded by a
BIS.
The mapping between the SIP-derived Distinguishing Attribute and a
RIB-Att is defined as follows:
SIP ToS IDRP Distinguishing Attribute
------- -----------------------------
minimize delay Transit Delay
maximize reliability Residual Error
minimize monetary cost Expense
maximize throughput default
5.2.4 Confederations of domains.
IDRP supports the ability to group Routing Domains into a Routing
Domain Confederation. Likewise, IDRP for SIP supports the ability to
group a collection of domains into a Confederation of domains.
Expiration Date April 1994 [Page 9]
- 10 -
5.2.5 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. 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 SIP
protocol is:
a) Location and identity of adjacent Intra-Domain ISs (routers)
The MIB table INTRA-IS lists the SIP 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 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 SIP 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 SIP addresses which identify the BISs in the domain.
c) Location and identity of BISs in adjacent domains:
Each BIS needs information to identify the SIP 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 SIP
addresses.
d) SIP 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 SIP network
address information shall be expressed in terms of SIP address
prefixes. A single prefix can be used to describe:
Expiration Date April 1994 [Page 10]
- 11 -
- a host address,
- a subnetwork number,
- a network number, or
- a collection of contiguous network numbers
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 7 of this document, the RDI
for an IDRP for SIP routing domain has an NSAP Address format.
This NSAP Address format is built out of a fixed "header" and
the domain identifier of this routing domain.
f) RIB-AttSet
The RIB-AttSet contains information about the QoS functions
a BIS will support. As described in section 4, this shall be
empty.
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 7 of this document.
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.
h) Local SIP addresses
The LOCAL SIP MIB table contains a list of SIP addresses
assigned to the interfaces of a BIS. This information is used
to determine what interface should be used to forward outgoing
NPDUs.
5.2.6 Forwarding of SIP packets
This section is intended to define the same function for SIP
Expiration Date April 1994 [Page 11]
- 12 -
packets as is defined for CLNP packets in the "Forwarding Process for
CLNS" (Section 8 in [1]).
It is assumed that a BIS is capable of distinguishing between a FIB
constructed by means of an intra-domain routing protocol and a FIB
constructed by means of IDRP.
After a BIS determines the packet's destination SIP address, the BIS
shall proceed as follows:
a) If the destination address depicts a system located within the
domain of the receiving BIS, then the BIS shall forward the SIP
packet to any of the ISs listed in the managed object INTRA-IS.
That is, any further forwarding of the SIP packet is the
responsibility of the intra-domain routing protocol; otherwise,
b) the destination system is located in a different domain, and
the local BIS shall perform the following actions:
It shall determine the SIP-Derived Distinguishing Attribute,
according to clause 5.2.3. It shall next apply the procedures
of clause 5.2.3 to determine if the SIP-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 5.2.3 identify a non-default SIP-
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 ToS bits in the Flow Label field of the SIP packet to 0 and
uses FIB with no Distinguishing Attributes.
The incoming SIP packet shall be forwarded based on the FIB
entry that has the longest SIP address prefix that matches the
destination of the incoming SIP packet, as follows:
1) If the entry in the inter-domain FIB that corresponds
to the destination address of an incoming SIP 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 SIP 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 SIP packet contains
a NEXT_HOP entry that identifies an interface of a BIS such
Expiration Date April 1994 [Page 12]
- 13 -
that the interface is not attached to any of the subnets
attached to the local BIS, then the local BIS has the
following options:
i) Encapsulate the SIP packet
The local BIS may encapsulate the SIP packet, using
IPAE with 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.
ii) Use paths calculated by the intra-domain routing
protocols
The local BIS may query the FIB constructed by the
intra-domain 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-domain routing protocols delivers the SIP packet
to the appropriate next-hop BIS, then the SIP packet
may be forwarded using the FIB constructed by the
intra-domain routing protocols.
ITEM Questions/Features Refer. Status Support
----------------------------------------------------------------
IP_EXTFWD Does the BIS correctly forward 5.3 M Yes___
SIP packets with destinations
outside its routing domain?
IP_INTFWD Does the BIS correctly forward 5.3 M Yes___
SIP packets with destinations
inside its routing domain?
---------------------------------------------------------------
Table 1: PICS Proforma for IDRP: SIP packet forwarding
Expiration Date April 1994 [Page 13]
- 14 -
The "ITEM" column describes the feature in the SIP 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.)
5.3 Advertising NLRI information for SIP addresses
The NLRI field in an UPDATE PDU contains SIP address information
about systems that reside within a given routing domain or whose SIP
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 SIP address that is valid within the SIP
context. Within the NLRI, the address information for a set of SIP
addresses may be represented by a SIP prefix. A SIP prefix is the
sequence of bits in a 8 byte SIP address which are common between a
set of SIP addresses.
For example, the addresses 4005:0000:0000:0000 through
4005:FFFF:FFFF:FFFF have the first 16 bits of the address
information in common. These 16 bits of the SIP address may be
called a SIP prefix which represents the set of SIP addresses
4005:0000:0000:0000 through 4005:FFFF:FFFF:FFFF.
A SIP prefix must contain a contiguous set of bits starting at the
most significant bit, but the bits may cover any part of the 8 byte
SIP address. The following guidelines for inclusion of SIP address
prefixes in the NLRI field of the UPDATE PDUs originated within a
routing domain will provide efficient use of this protocol:
a) Only SIP prefixes representing SIP 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 SIP prefixes can
represent SIP addresses for systems which are:
- online,
- offline, or
Expiration Date April 1994 [Page 14]
- 15 -
- allocated to the network, but not yet allocated to a machine.
b) SIP prefixes representing SIP 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 SIP prefixes for SIP
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 a domain (or group of
domains) 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.
6 Determining the forwarding address (Next Hop)
NEXT_HOP information associated with a particular route shall be
derived from the NEXT_HOP attribute in the UPDATE BISPDU that carries
the route. If that attribute is not present, it shall be derived from
the source SIP address of the SIP packet that carries the UPDATE
BISPDU containing the route.
7 Routing Domain Identifiers used for both SIP and OSI
Routing Domain Identifiers (RDIs) are identifiers used in BISPDUs
to uniquely identify individual routing domains and routing domain
confederations.
An RDI of a pure SIP domain should be constructed as a concatenation
of a unique NSAP address prefix 47:00:05:c0:02 and the unique
identifier taken out of the SIP address space. While the unique
identifier is just a number which identifies the routing domain, and
need not bear any relationship to any reachable addresses within the
domain, using the cluster identifier of one of the networks belonging
to the routing domain may potentially offer some advantages.
Alternatively an RDI of a SIP domain can be constructed by a
concatenation of a unique NSAP address prefix assigned by a valid
Expiration Date April 1994 [Page 15]
- 16 -
addressing authority and an appropriately assigned autonomous system
number as follows:
47:00:05:c0:01:aa:aa
where 47:00:05:c0:01 is a unique NSAP prefix, and aa.aa is the
autonomous system number.
8 Deployment Guidelines for IDRP for SIP
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 SIP are
required within domains. These guidelines represent only the
required deployment guidelines, and not details on the usage of IDRP
for SIP in the Internet.
8.1 Minimum configuration of a domain
A domain using IDRP for SIP must as a minimum contain:
- one BIS, and
- one BIS capable of delivering NPDUs to the intra-domain routing
function if the domain contains hosts.
8.2 Multiple IDRP sessions between the same pair of routers
A SIP router may have multiple SIP 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, a SIP
router may potentially have multiple IDRP sessions with another
router, since each BIS may have multiple SIP addresses, and one BIS
may not be able to ascertain that those addresses correspond to the
same BIS. Multiple IDRP sessions between SIP BISs may not be
efficient, but they are not illegal, nor do they impact the
robustness of the IDRP for SIP protocol; they will simply appear as
multiple paths to the same neighboring domain. One possible way of
avoiding multiple parallel IDRP sessions between a pair of BISs
Expiration Date April 1994 [Page 16]
- 17 -
within a single domain is to bind all source addresses of outgoing
BISPDUs to the SIP address of a particular interface of the BIS.
Likewise, for a pair of BISs located in adjacent domains, 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. 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 (an example of such policy is presented in Annex K
of [1]). 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:
1. 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 granularity of a single SIP 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.
2. IDRP implementations should allow a domain to prefer a
particular path to a destination (when more than one path is
available). This function may be implemented by allowing
system administrators to assign "weights" to domain
identifiers, and by having the route selection process select a
route with the lowest "weight" (where "weight" of a route is
defined as a sum of "weights" of all domains in the RD_PATH
path attribute associated with that route).
3. IDRP implementations should allow a domain to ignore routes
with certain domains in the RD_PATH path attribute. Such
function can be implemented by using the technique outlined in
[10], and by assigning "infinity" as "weights" for such
domains. The route selection process must ignore routes that
have "weight" equal to "infinity".
Expiration Date April 1994 [Page 17]
- 18 -
10 Security Considerations
Security issues are not discussed in this document.
11. Acknowledgements
We would like to acknowledge comments from Christian Huitema and
Steve Deering.
12. References
[1] ISO/IEC IS 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, 1993.
[2] Hares, S., "IDRP Document Family Tree", Internet Draft
[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] Deering, S., "Simple Internet Protocol (SIP) Specification",
Internet Draft November 1992
[7] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
Merit/NSFNET, June 1989.
[8] Crocker, D., Hinden, B., "IP Address Encapsulation (IPAE): A
Mechanism for Introducing a New IP", Internet Draft, November 1992
Expiration Date April 1994 [Page 18]
- 19 -
Authors' Addresses
Susan Hares
Merit, Inc
1071 Beal Avenue
Ann Arbor, MI 4810x
Phone: (313)936-2095
Email: skh@merit.edu
Expiration Date April 1994 [Page 19]