Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1195

Use of OSI IS-IS for routing in TCP/IP and dual environments

Pages: 85
Proposed Standard
Errata
Updated by:  134953025304
Part 1 of 3 – Pages 1 to 30
None   None   Next

ToP   noToC   RFC1195 - Page 1
Network Working Working Group                                  R. Callon
Request for Comments: 1195                 Digital Equipment Corporation
                                                           December 1990


      Use of OSI IS-IS for Routing in TCP/IP and Dual Environments

Status of this Memo

   This RFC specifies a protocol on the IAB Standards Track for the
   Internet community, and requests discussion and suggestions for
   improvements. Please refer to the current edition of the "IAB
   Official Protocol Standards" for the standardization state and status
   of this protocol. Distribution of this memo is unlimited.

   This RFC is available in both postscript and text versions. Where
   possible, use of the postscript version is recommended. For example,
   this text version may have figures which are less informative or
   missing.

Abstract

   This RFC specifies an integrated routing protocol, based on the OSI
   Intra-Domain IS-IS Routing Protocol, which may be used as an interior
   gateway protocol (IGP) to support TCP/IP as well as OSI. This allows
   a single routing protocol to be used to support pure IP environments,
   pure OSI environments, and dual environments. This specification was
   developed by the IS-IS working group of the Internet Engineering Task
   Force.

   The OSI IS-IS protocol has reached a mature state, and is ready for
   implementation and operational use. The most recent version of the
   OSI IS-IS protocol is contained in ISO DP 10589 [1]. The proposed
   standard for using IS-IS for support of TCP/IP will therefore make
   use of this version (with a minor bug correction, as discussed in
   Annex B).  We expect that future versions of this proposed standard
   will upgrade to the final International Standard version of IS-IS
   when available.

   Comments should be sent to "isis@merit.edu".

Contents

    1   Introduction: Overview of the Protocol
        1.1     What the Integrated IS-IS offers
        1.2     Overview of the ISO IS-IS Protocol
        1.3     Overview of the Integrated IS-IS
        1.4     Support of Mixed Routing Domains
ToP   noToC   RFC1195 - Page 2
        1.5     Advantages of Using Integrated IS-IS

    2   Symbols and Abbreviations

    3   Subnetwork Independent Functions
        3.1     Exchange of Routing Information
        3.2     Hierarchical Abbreviation of IP Reachability Information
        3.3     Addressing Routers in IS-IS Packets
        3.4     External Links
        3.5     Type of Service Routing
        3.6     Multiple LSPs and SNPs
        3.7     IP-Only Operation
        3.8     Encapsulation
        3.9     Authentication
        3.10    Order of Preference of Routes / Dijkstra Computation

    4   Subnetwork Dependent Functions
        4.1     Link Demultiplexing
        4.2     Multiple IP Addresses per Interface
        4.3     LANs, Designated Routers, and Pseudonodes
        4.4     Maintaining Router Adjacencies
        4.5     Forwarding to Incompatible Routers

    5   Structure and Encoding of PDUs
        5.1     Overview of IS-IS PDUs
        5.2     Overview of IP-Specific Information for IS-IS
        5.3     Encoding of IP-Specific Fields in IS-IS PDUs

    6   Security Considerations

    7   Author's Address

    8   References

    A   Inter-Domain Routing Protocol Information
        A.1     Inter-Domain Information Type
        A.2     Encoding

    B   Encoding of Sequence Number Packets
        B.1     Level 1 Complete Sequence Numbers PDU
        B.2     Level 2 Complete Sequence Numbers PDU
        B.3     Level 1 Partial Sequence Numbers PDU
        B.4     Level 2 Partial Sequence Numbers PDU

    C   Dijkstra Calculation and Forwarding
        C.1     SPF Algorithm for IP and Dual Use
        C.2     Forwarding of IP packets
ToP   noToC   RFC1195 - Page 3
    D   Use of the Authentication Field
        D.1     Authentication Field in IS-IS packets
        D.2     Authentication Type 1 - Simple Password

    E   Interaction of the Integrated IS-IS with Brouters
        E.1     The Problem
        E.2     Possible Solutions

Figures

        1       ISO Hierarchical Address Structure
        2       An Example
        3       Encoding of Variable Length Fields

1 Introduction: Overview of the Protocol

   The TCP/IP protocol suite has been growing in importance as a multi-
   vendor communications architecture. With the anticipated emergence of
   OSI, we expect coexistence of TCP/IP and OSI to continue for an
   extended period of time. There is a critical need for routers to
   support both IP traffic and OSI traffic in parallel.

   There are two main methods that are available for routing protocols
   to support dual OSI and IP routers. One method, known as "Ships in
   the Night", makes use of completely independent routing protocols for
   each of the two protocol suites. This specification presents an
   alternate approach, which makes use of a single integrated protocol
   for interior routing (i.e., for calculating routes within a routing
   domain) for both protocol suites.

   This integrated protocol design is based on the OSI Intra-domain IS-
   IS routing protocol [1], with IP-specific functions added. This RFC
   is considered a companion to the OSI IS-IS Routing spec, and will
   only describe the required additional features.

   By supporting both IP and OSI traffic, this integrated protocol
   design supports traffic to IP hosts, OSI end systems, and dual end
   systems.  This approach is "integrated" in the sense that the IS-IS
   protocol can be used to support pure-IP environments, pure-OSI
   environments, and dual environments. In addition, this approach
   allows interconnection of dual (IP and OSI) routing domains with
   other dual domains, with IP-only domains, and with OSI-only domains.

   The protocol specified here is based on the work of the IETF IS-IS
   working group.

1.1 What the Integrated IS-IS offers

   The integrated IS-IS provides a single routing protocol which will
ToP   noToC   RFC1195 - Page 4
   simultaneously provide an efficient routing protocol for TCP/IP, and
   for OSI. This design makes use of the OSI IS-IS routing protocol,
   augmented with IP-specific information. This design provides explicit
   support for IP subnetting, variable subnet masks, TOS-based routing,
   and external routing. There is provision for authentication
   information, including the use of passwords or other mechanisms. The
   precise form of authentication mechanisms (other than passwords) is
   outside of the scope of this document.

   Both OSI and IP packets are forwarded "as is" -- i.e., they are
   transmitted directly over the underlying link layer services without
   the need for mutual encapsulation. The integrated IS-IS is a dynamic
   routing protocol, based on the SPF (Dijkstra) routing algorithm.

   The protocol described in this specification allows for mixing of
   IP-only, OSI-only, and dual (IP and OSI) routers, as defined below.

   An IP-only IS-IS router (or "IP-only" router) is defined to be a
   router which: (i) Uses IS-IS as the routing protocol for IP, as
   specified in this report; and (ii) Does not otherwise support OSI
   protocols. For example, such routers would not be able to forward OSI
   CLNP packets.

   An OSI-only router is defined to be a router which uses IS-IS as the
   routing protocol for OSI, as specified in [1]. Generally, OSI-only
   routers may be expected to conform to OSI standards, and may be
   implemented independent of this specification.

   A dual IS-IS router (or "dual" router) is defined to be a router
   which uses IS-IS as a single integrated routing protocol for both IP
   and OSI, as specified in this report.

   This approach does not change the way that IP packets are handled.
   IP-only and dual routers are required to conform to the requirements
   of Internet Gateways [4]. The integrated IS-IS protocol described in
   this report outlines an Interior Gateway Protocol (IGP) which will
   provide routing within a TCP/IP routing domain (i.e., autonomous
   system). Other aspects of router functionality (e.g., operation of
   ICMP, ARP, EGP, etc.) are not affected by this proposal.

   Similarly, this approach does not change the way that OSI packets are
   handled. There will be no change at all to the contents nor to the
   handling of ISO 8473 Data packets and Error Reports, nor to ISO 9542
   Redirects and ES Hellos. ISO 9542 IS Hellos transmitted on LANs are
   similarly unchanged. ISO 9542 IS Hellos transmitted on point-to-point
   links are unchanged except for the addition of IP-related
   information.  Similarly, other OSI packets (specifically those
   involved in the IS-IS intra-domain routing protocol) remain unchanged
ToP   noToC   RFC1195 - Page 5
   except for the addition of IP-related information.

   This approach makes use of the existing IS-IS packets, with IP-
   specific fields added. Specifically: (i) authentication information
   may be added to all IS-IS packets; (ii) the protocols supported by
   each router, as well as each router's IP addresses, are specified in
   ISO 9542 IS Hello, IS-IS Hello and Link State Packets; (iii)
   internally reachable IP addresses are specified in all Link State
   Packets; and (iv) externally reachable IP addresses, and external
   routing protocol information, may be specified in level 2 Link State
   Packets. The detailed encoding and interpretation of this in
   formation is specified in sections 3, 4, and 5 of this RFC.

   The protocol described in this report may be used to provide routing
   in an IP-only routing domain, in which all routers are IP-only.
   Similarly, this protocol may be used to provide routing in a pure
   dual domain, in which all routers are dual. Finally, this protocol
   may be used to provide routing in a mixed domain, in which some
   routers are IP-only, some routers are OSI-only, and some routers are
   dual. The specific topological restrictions which apply in this
   latter case are described in detail in section 1.4 ("Support of Mixed
   Routing Domains").  The use of IS-IS for support of pure OSI domains
   is specified in [1].

   This protocol specification does not constrain which network
   management protocol(s) may be used to manage IS-IS-based routers.
   Management information bases (MIBs) for managing IP-only, OSI-only,
   and dual routers, compatible with CMIP, CMOT, and/or SNMP, are the
   subject of a separate, companion document [8].

1.2 Overview of the ISO IS-IS Protocol

   The IS-IS Routing Protocol has been developed in ISO to provide
   routing for pure OSI environments. In particular, IS-IS is designed
   to work in conjunction with ISO 8473 (The ISO Connectionless Network
   Layer Protocol [2]), and ISO 9542 (The ISO End System to Intermediate
   System Protocol [3]). This section briefly describes the manner in
   which IS-IS is used to support pure OSI environments. Enhancements
   for support of IP and dual environments are specified elsewhere in
   this report.

   In IS-IS, the network is partitioned into "routing domains". The
   boundaries of routing domains are defined by network management, by
   setting some links to be "exterior links". If a link is marked as
   "exterior", no IS-IS routing messages are sent on that link.

   Currently, ISO does not have a standard for inter-domain routing
   (i.e., for routing between separate autonomous routing domains).
ToP   noToC   RFC1195 - Page 6
   Instead, manual configuration is used. The link is statically
   configured with the set of address prefixes reachable via that link,
   and with the method by which they can be reached (such as the DTE
   address to be dialed to reach that address, or the fact that the DTE
   address should be extracted from the IDP portion of the ISO address).

   OSI IS-IS routing makes use of two-level hierarchical routing. A
   routing domain is partitioned into areas. Level 1 routers know the
   topology in their area, including all routers and end systems in
   their area. However, level 1 routers do not know the identity of
   routers or destinations outside of their area. Level 1 routers
   forward all traffic for destinations outside of their area to a level
   2 router in their area. Similarly, level 2 routers know the level 2
   topology, and know which addresses are reachable via each level 2
   router. However, level 2 routers do not need to know the topology
   within any level 1 area, except to the extent that a level 2 router
   may also be a level 1 router within a single area. Only level 2
   routers can exchange data packets or routing information directly
   with external routers located outside of the routing domains.

    +----------------------+-------------------------------+
    |        IDP           |              DSP              |
    +----------------------+-------------------------------+
    .                      .                               .
    .                      .                               .
    .                      .                               .
    +-----+----------------+----------+--------------+-----+
    | AFI |      IDI       |  HO-DSP  |      ID      | SEL |
    +-----+----------------+----------+--------------+-----+

         Figure 1 - ISO Hierarchical Address Structure


   As illustrated in figure 1, ISO addresses are subdivided into the
   Initial Domain Part (IDP), and the Domain Specific Part (DSP). The
   IDP is the part which is standardized by ISO, and specifies the
   format and authority responsible for assigning the rest of the
   address. The DSP is assigned by whatever addressing authority is
   specified by the IDP. The DSP is further subdivided into a "High
   Order Part of DSP" (HO-DSP), a system identifier (ID), and an NSAP
   selector (SEL). The HO-DSP may use any format desired by the
   authority which is identified by the IDP. Together, the combination
   of [IDP, HO-DSP] identify both the routing domain and the area within
   the routing domain. The combination of [IDP,HO-DSP] may therefore be
   referred to as the "Area Address".

   Usually, all nodes in an area have the same area address. However,
   sometimes an area might have multiple addresses. Motivations for
ToP   noToC   RFC1195 - Page 7
   allowing this are:

   - It might be desirable to change the address of an area. The most
     graceful way of changing an area from having address A to having
     address B is to first allow it to have both addresses A and B, and
     then after all nodes in the area have been modified to recognize
     both addresses, then one by one the nodes can be modified to
     "forget" address A.

   - It might be desirable to merge areas A and B into one area. The
     method for accomplishing this is to, one by one, add knowledge of
     address B into the A partition, and similarly add knowledge of
     address A into the B  partition.

   - It might be desirable to partition an area C into two areas, A
     and B (where "A" might equal "C", in which case this example
     becomes one of removing a portion of an area). This would be
     accomplished by first introducing knowledge of address A into
     the appropriate nodes (those destined to become area A), and
     knowledge of address B into the appropriate nodes, and then one
     by one removing knowledge of address C.

   Since OSI addressing explicitly identifies the area, it is very easy
   for level 1 routers to identify packets going to destinations outside
   of their area, which need to be forwarded to level 2 routers.

   In IS-IS, there are two types of routers:

   - Level 1 intermediate systems -- these nodes route based on the ID
     portion of the ISO address. They route within an area. They
     recognize, based on the destination address in a packet, whether
     the destination is within the area. If so, they route towards
     the destination. If not, they route to the nearest level 2 router.

   - Level 2 intermediate systems -- these nodes route based on the area
     address (i.e., on the combination of [IDP, HO-DSP]). They route
     towards areas, without regard to the internal structure of an area.
     A level 2 IS may also be a level 1 IS in one area.

   A level 1 router will have the area portion of its address manually
   configured. It will refuse to become a neighbor with a node whose
   area addresses do not overlap its area addresses. However, if level 1
   router has area addresses A,  B, and C, and a neighbor has area
   addresses B and D, then the level 1 router will accept the other node
   as a neighbor.

   A level 2 router will accept another level 2 router as a neighbor,
   regardless of area address. However, if the area addresses do not
ToP   noToC   RFC1195 - Page 8
   overlap, the link would be considered by both routers to be "level 2
   only", and only level 2 LSPs would flow on the link. External links
   (to other routing domains) must be from level 2 routers.

   IS-IS provides an optional partition repair function. In the unlikely
   case that a level 1 area become partitioned, this function, if
   implemented, allows the partition to be repaired via use of level 2
   routes.

   IS-IS requires that the set of level 2 routers be connected. Should
   the level 2 backbone become partitioned, there is no provision for
   use of level 1 links to repair a level 2 partition.

   In unusual cases, a single level 2 router may lose connectivity to
   the level 2 backbone. In this case the level 2 router will indicate
   in its level 1 LSPs that it is not "attached", thereby allowing level
   1 routers in the area to route traffic for outside of the domain to a
   different level 2 router. Level 1 routers therefore route traffic to
   destinations outside of their area only to level 2 routers which
   indicate in their level 1 LSPs that they are "attached".

   An end system may autoconfigure the area portion of its address by
   extracting the area portion of a neighboring router's address. If
   this is the case, then an endnode will always accept a router as a
   neighbor. Since the standard does not specify that the end system
   MUST autoconfigure its area address, an end system may be configured
   with an area address. In this case the end system would ignore router
   neighbors with non-matching area addresses.

   Special treatment is necessary for broadcast subnetworks, such as
   LANs. This solves two sets of issues: (i) In the absence of special
   treatment, each router on the subnetwork would announce a link to
   every other router on the subnetwork, resulting in n-squared links
   reported; (ii) Again, in the absence of special treatment, each
   router on the LAN would report the same identical list of end systems
   on the LAN, resulting in substantial duplication.

   These problems are avoided by use of a "pseudonode", which represents
   the LAN. Each router on the LAN reports that it has a link to the
   pseudonode (rather than reporting a link to every other router on the
   LAN). One of the routers on the LAN is elected "designated router".
   The designated router then sends out an LSP on behalf of the
   pseudonode, reporting links to all of the routers on the LAN. This
   reduces the potential n-squared links to n links. In addition, only
   the pseudonode LSP includes the list of end systems on the LAN,
   thereby eliminating the potential duplication (for further
   information on designated routers and pseudonodes, see [1]).
ToP   noToC   RFC1195 - Page 9
   The IS-IS provides for optional Quality of Service (QOS) routing,
   based on throughput (the default metric), delay, expense, or residual
   error probability. This is described in greater detail in section
   3.5, and in [1].

1.3 Overview of the Integrated IS-IS

   The integrated IS-IS allows a single routing protocol to be used to
   route both IP and OSI packets. This implies that the same two-level
   hierarchy will be used for both IP and OSI routing. Each area will be
   specified to be either IP-only (only IP traffic can be routed in that
   particular area), OSI-only (only OSI traffic can be routed in that
   area), or dual (both IP and OSI traffic can be routed in the area).

   This proposal does not allow for partial overlap of OSI and IP areas.
   For example, if one area is OSI-only, and an other area is IP-only,
   then it is not permissible to have some routers be in both areas.
   Similarly, a single backbone is used for the routing domain. There is
   no provision for independent OSI and IP backbones.

   Similarly, within an IP-only or dual area, the amount of knowledge
   maintained by routers about specific IP destinations will be as
   similar as possible as for OSI. For example, IP-capable level 1
   routers will maintain the topology within the area, and will be able
   to route directly to IP destinations within the area. However, IP-
   capable level 1 routers will not maintain information about
   destinations outside of the area. Just as in normal OSI routing,
   traffic to destinations outside of the area will be forwarded to the
   nearest level 2 router. Since IP routes to subnets, rather than to
   specific end systems, IP routers will not need to keep nor distribute
   lists of IP host identifiers (note that routes to hosts can be
   announced by using a subnet mask of all ones).

   The IP address structure allows networks to be partitioned into
   subnets, and allows subnets to be recursively subdivided into smaller
   subnets. However, it is undesireable to require any specific
   relationship between IP subnet addresses and IS-IS areas. For
   example, in many cases, the dual routers may be installed into
   existing environments, which already have assigned IP and/or OSI
   addresses. In addition, even if IP addresses are not already pre-
   assigned, the address limitations of IP constrain what addresses may
   be assigned. We therefore will not require any specific relationship
   between IP addresses and the area structure. The IP addresses can be
   assigned completely independently of the OSI addresses and IS-IS area
   structure. As will be described in section 3.2 ("Hierarchical
   Abbreviation of IP Reachability Information"), greater efficiency and
   scaling of the routing algorithm can be achieved if there is some
   correspondence between the IP address assignment structure and the
ToP   noToC   RFC1195 - Page 10
   area structure.

   Within an area, level 1 routers exchange link state packets which
   identify the IP addresses reachable by each router. Specifically,
   zero or more [IP address, subnet mask, metric] combinations may be
   included in each Link State Packet. Each level 1 router is manually
   configured with the [IP address, subnet mask, metric] combinations
   which are reachable on each interface. A level 1 router routes as
   follows:

   - If a specified destination address matches an [IP address, subnet
     mask, metric] reachable within the area, the packet is routed via
     level 1 routing.

   - If a specified destination address does not match any [IP address,
     subnet mask, metric] combination listed as reachable within the
     area, the packet is routed towards the nearest level 2 router.

   Flexible use of the limited IP address space is important in order to
   cope with the anticipated growth of IP environments. Thus an area
   (and by implication a routing domain) may simultaneously make use of
   a variety of different address masks for different subnets in the
   area (or domain). Generally, if a specified destination address
   matches more than one [IP address, subnet mask] pair, the more
   specific address is the one routed towards (the one with more "1"
   bits in the mask -- this is known as "best match" routing).

   Level 2 routers include in their level 2 LSPs a complete list of [IP
   address, subnet mask, metric] specifying all IP addresses reachable
   in their area. As described in section 3, this information may be
   obtained from a combination of the level 1 LSPs (obtained from level
   1 routers in the same area), and/or by manual configuration. In
   addition, Level 2 routers may report external reachability
   information, corresponding to addresses which can be reached via
   routers in other routing domains (autonomous systems)

   Default routes may be announced by use of a subnet mask containing
   all zeroes. Default routes should be used with great care, since they
   can result in "black holes". Default routes are permitted only at
   level 2 as external routes (i.e., included in the "IP External
   Reachability Information" field, as explained in sections 3 and 5).
   Default routes are not permitted at level 1.

   The integrated IS-IS provides optional Type of Service (TOS) routing,
   through use of the QOS feature from IS-IS.
ToP   noToC   RFC1195 - Page 11
1.4 Support of Mixed Routing Domains

   The integrated IS-IS proposal specifically allows for three types of
   routing domains:

   - Pure IP

   - Pure OSI

   - Dual

   In a pure IP routing domain, all routers must be IP-capable. IP-only
   routers may be freely mixed with dual routers. Some fields
   specifically related to OSI operation may be included by dual
   routers, and will be ignored by IP-only routers. Only IP traffic will
   be routed in an pure IP domain. Any OSI traffic may be discarded
   (except for the IS-IS packets necessary for operation of the routing
   protocol).

   In a pure OSI routing domain, all routers must be OSI-capable.  OSI-
   only routers may be freely mixed with dual routers. Some fields
   specifically related to IP operation may be included by dual routers,
   and will be ignored by OSI-only routers. Only OSI traffic will be
   routed in a pure OSI domain. Any IP traffic may be discarded.

   In a dual routing domain, IP-only, OSI-only, and dual routers may be
   mixed on a per-area basis. Specifically, each area may itself be
   defined to be pure IP, pure OSI, or dual.

   In a pure IP area within a dual domain, IP-only and dual routers may
   be freely mixed. Only IP traffic can be routed by level 1 routing
   within a pure-IP area.

   In a pure-OSI area within a dual domain, OSI-only and dual routers
   may be freely mixed. Only OSI traffic can be routed by level 1
   routing within a pure OSI area.

   In a dual area within a dual routing domain only dual routers may be
   used. Both IP and OSI traffic can be routed within a dual area.

   Within a dual domain, if both IP and OSI traffic are to be routed
   between areas then all level 2 routers must be dual.

1.5 Advantages of Using Integrated IS-IS

   Use of the integrated IS-IS protocol, as a single protocol for
   routing both IP and OSI packets in a dual environment, has
   significant advantages over using separate protocols for
ToP   noToC   RFC1195 - Page 12
   independently routing IP and OSI traffic.

   An alternative approach is known as "Ships In the Night" (S.I.N.).
   With the S.I.N. approach, completely separate routing protocols are
   used for IP and for OSI. For example, OSPF [5] may be used for
   routing IP traffic, and IS-IS [1] may be used for routing OSI
   traffic. With S.I.N., the two routing protocols operate more or less
   independently. However, dual routers will need to implement both
   routing protocols, and therefore there will be some degree of
   competition for resources.

   Note that S.I.N. and the integrated IS-IS approach are not really
   completely separate options. In particular, if the integrated IS-IS
   is used within a routing domain for routing of IP and OSI traffic, it
   is still possible to use other independent routing protocols for
   routing other protocol suites.

   In the future, optional extensions to IS-IS may be defined for
   routing other common protocol suites. However, such future options
   are outside of the scope of this document. This section will compare
   integrated IS-IS and S.I.N. for routing of IP and OSI only.

   A primary advantage of the integrated IS-IS relates to the network
   management effort required. Since the integrated IS-IS provides a
   single routing protocol, within a single coordinated routing domain
   using a single backbone, this implies that there is less information
   to configure. This combined with a single coordinated MIB simplifies
   network management.

   Note that the operation of two routing protocols with the S.I.N.
   approach are not really independent, since they must share common
   resources. However, with the integrated IS-IS, the interactions are
   explicit, whereas with S.I.N., the interactions are implicit. Since
   the interactions are explicit, again it may be easier to manage and
   debug dual routers.

   Another advantage of the integrated IS-IS is that, since it requires
   only one routing protocol, it uses fewer resources. In particular,
   less implementation resources are needed (since only one protocol
   needs to be implemented), less CPU and memory resources are used in
   the router (since only one protocol needs to be run), and less
   network resources are used (since only one set of routing packets
   need to be transmitted). Primarily this translates into a financial
   savings, since each of these three types of resources cost money.
   This implies that dual routers based on the integrated IS-IS should
   be less expensive to purchase and operate than dual routers based on
   S.I.N.
ToP   noToC   RFC1195 - Page 13
   Note that the operation of two routing protocols with the S.I.N.
   approach are not really independent, since they must share common
   resources. For example, if one routing protocol becomes unstable and
   starts to use excessive resources, the other protocol is likely to
   suffer. A bug in one protocol could crash the other. However, with
   the integrated IS-IS, the interactions are explicit and are defined
   into the protocol and software interactions. With S.I.N., the
   interactions are implicit.

   The use of a single integrated routing protocol similarly reduces the
   likely frequency of software upgrades. Specifically, if you have two
   different routing protocols in your router, then you have to upgrade
   the software any time EITHER of the protocols change. If you make use
   of a single integrated routing protocol, then software changes are
   still likely to be needed, but less frequently.

   Finally, routing protocols have significant real time requirements.
   In IS-IS, these real time requirements have been explicitly
   specified. In other routing protocols, these requirements are
   implicit. However, in all routing protocols, there are real time
   guarantees which must be met in order to ensure correct operation. In
   general, it is difficult enough to ensure compliance with real time
   requirements in the implementation of a single real time system. With
   S.I.N., implementation of two semi-independent real-time protocols in
   a single device makes this more difficult.

   Note that both integrated IS-IS and S.I.N. allow for independence of
   external routes (for traffic from/to outside of the routing domain),
   and allow for independent assignment of OSI and TCP/IP addresses.

2 Symbols and Abbreviations

AA              Administrative Authority
                (a three octet field in the GOSIP version 2.0 NSAP
                address format)

AFI             Authority and Format Identifier
                (the first octet of all OSI NSAP addresses -- identifies
                format of the rest of the address)

CLNP            Connection-Less Network Protocol
                (ISO 8473, the OSI connectionless network layer protocol
                -- very similar to IP)

DFI             DSP Format Identifier
                (a one octet field in the GOSIP version 2.0 NSAP address
                format)
ToP   noToC   RFC1195 - Page 14
ES              End System
                (The OSI term for a host)

ES-IS           End System to Intermediate System Routeing Exchange
                Protocol (ISO 9542 -- OSI protocol between routers
                and end systems)

ICD             International Code Designator
                (ISO standard for identifying organizations)

IP              Internetwork Protocol
                (an Internet Standard Network Layer Protocol)

IS              Intermediate System
                (The OSI term for a router)

IS-IS           Intermediate System to Intermediate System Routeing
                Exchange Protocol
                (the ISO protocol for routing within a single
                routing domain)

IS-IS Hello     An Hello packet defined by the IS-IS protocol
                (a type of packet used by the IS-IS protocol)

ISH             An Hello packet defined by ISO 9542 (ES-IS protocol).
                (not the same as IS-IS Hello)

ISO             International Organization for Standardization
                (an international body which is authorized to write
                standards of many kinds)

LSP             Link State Packet
                (a type of packet used by the IS-IS protocol)

NLPID           Network Layer Protocol ID
                (A one-octet field identifying a network layer protocol)

NSAP            Network Service Access Point
                (a conceptual interface point at which the network
                service is made available)

SEL             NSAP Selector
                (the last octet of NSAP addresses, also called NSEL)

OSI             Open Systems Interconnection
                (an international standard protocol architecture)
ToP   noToC   RFC1195 - Page 15
RD              Routing Domain
                (the set of routers and end systems using a single
                instance of a routing protocol such as IS-IS)

SNPA            Subnetwork Point of Attachment
                (a conceptual interface at which a subnetwork service
                is provided)

TCP             Transmission Control Protocol
                (an Internet Standard Transport Layer Protocol)

TCP/IP          The protocol suite based on TCP, IP, and related
                protocols (the Internet standard protocol
                architecture)

3 Subnetwork Independent Functions

3.1 Exchange of Routing Information

   The exchange of routing information between routers makes use of the
   normal routing packet exchange as defined in the OSI IS-IS routing
   spec, with additional IP-specific information added to the IS-IS
   routing packets.

   The IS-IS protocol provides for the inclusion of variable length
   fields in all IS-IS packets. These fields are encoded using a "Code,
   Length, Value" triplet, where the code and length are encoded in one
   octet each, and the value has the length specified (from 0 to 254
   octets). IS-IS requires that: "Any codes in a received PDU that are
   not recognised are ignored and passed through unchanged". This
   requirement applies to all routers implementing IS-IS, including
   OSI-only, IP-only, and dual routers. This allows IP-specific
   information to be encoded in a manner which OSI-only routers will
   ignore, and also allows OSI-specific information to be encoded in a
   manner which IP-only routers will ignore.

   IP-capable (i.e., all IP-only and dual) routers need to know what
   network layer protocols are supported by other routers in their area.
   This information is made available by inclusion of a "protocols
   supported" field in all IS-IS Hello and Link State Packets. This
   field makes use of the NLPID (Network Layer Protocol Identifier),
   which is a one-octet value assigned by ISO to identify network level
   protocols. NLPID values have been assigned to ISO 8473 and to IP.

   IP-capable routers need to know the IP address of the adjacent
   interface of neighboring routers. This is required for sending ICMP
   redirects (when an IP-capable router sends an ICMP redirect to a
   host, it must include the IP address of the appropriate interface of
ToP   noToC   RFC1195 - Page 16
   the correct next-hop router). This information is made available by
   inclusion of the IP interface address in the IS-IS Hello packets.
   Specifically, each IS-IS Hello packet contains the IP address(es) of
   the interface over which the Hello is transmitted. The IS-IS allows
   multiple IP addresses to be assigned to each physical interface.

   In some cases, it will be useful for IP-capable routers to be able to
   determine an IP address(es) of all other routers at their level
   (i.e., for level 1 routers: all other routers in their area; for
   level 2 routers: all other level 2 routers in the routing domain).
   This is useful whenever an IP packet is to be sent to a router, such
   as for encapsulation or for transmission of network management
   packets. This information is made available by inclusion of IP
   address in LSPs. Specifically, each IS-IS LSP includes one or more IP
   addresses of the router which transmits the LSP. An IP-capable router
   is required to include at least one of its IP addresses in its LSPs,
   and may optionally include several or all of its IP addresses. Where
   a single router operates as both a level 1 and a level 2 router, it
   is required to include the same IP address(es) in its level 1 and
   level 2 LSPs.

   IP-capable routers need to know, for any given IP destination
   address, the correct route to that destination. Specifically, level 1
   routers need to know what IP addresses are reachable from each level
   1 router in their area. In addition, level 1 routers need to find
   level 2 routers (for traffic to IP addresses outside of their area).
   Level 2 routers need to know what IP addresses are reachable
   internally (either directly, or via level 1 routing) from other level
   2 routers, and what addresses are reachable externally from other
   level 2 routers. All of this information is made available by
   inclusion of IP reachable address information in the Link State
   Packets.

   Internal (within the routing domain) and external (outside the
   domain) reachability information is announced separately in level 2
   LSPs. Reachable IP addresses include a default metric, and may
   include multiple TOS-specific metrics. In general, for external
   routes, metrics may be of type "internal" (i.e., directly comparable
   with internal metrics) or of type "external" (i.e., not comparable
   with the internal metric). A route using internal metrics (i.e.,
   either announced as "IP internal reachability information", or
   announced as "IP external reachability information" with an internal
   metric) is always preferred to a route using external metrics (i.e.,
   announced as "IP external reachability information", with an external
   metric).

   The detailed encoding of the IP-specific information included in
   routing packets is provided in section 5 (Structure and Encoding of
ToP   noToC   RFC1195 - Page 17
   PDUs).

3.2 Hierarchical Abbreviation of IP Reachability Information

   Level 2 routers include in their level 2 LSPs a list of all [IP
   address, subnet mask, metric] combinations reachable in their area.
   In general, this information may be determined from the level 1 LSPs
   from all routers in the area. If we ignore resource constraints, then
   it would be permissible for a level 2 router to simply duplicate all
   [IP address, subnet mask, metric] entries from all level 1 routers in
   its area (with appropriate metric adjustment), for inclusion in its
   level 2 LSP. However, in order for hierarchical routing to scale to
   large routing domain sizes, it is highly desired to abbreviate the
   reachable address information.

   This is accomplished by manual configuration of summary addresses.
   Each level 2 router may be configured with one or more [IP address,
   subnet mask, metric] entries for announcement in their level 2 LSPs.

   The set of reachable addresses obtained from level 1 LSPs is compared
   with the configured reachable addresses. Redundant information
   obtained from level 1 LSPs is not included in level 2 LSPs. Generally
   it is expected that the level 2 configured information will specify
   more inclusive addresses (corresponding to a subnet mask with fewer
   bits set to 1). This will therefore allow one configured
   address/submask pair (or a small number of such pairs) to
   hierarchically supercede the information corresponding to multiple
   entries in level 1 LSPs.

   The manually configured addresses are included in level 2 LSPs only
   if they correspond to at least one address which is reachable in the
   area. For manually configured level 2 addresses, the associated
   metric values to announce in level 2 LSPs are also manually
   configured. The configured addresses will supercede reachable address
   entries from level 1 LSPs based only on the IP address and subnet
   mask -- metric values are not considered when determining if a given
   configured address supercedes an address obtained from a level 1 LSP.

   Any address obtained from a level 1 LSP which is not superceded by
   the manually configured information is included in the level 2 LSPs.
   In this case, the metric value announced in the level 2 LSPs is
   calculated from the sum of the metric value announced in the
   corresponding level 1 LSP, plus the distance from the level 2 router
   to the appropriate level 1 router. Note: If this sum results in a
   metric value greater than 63 (the maximum value that can be reported
   in level 2 LSPs), then the value 63 must be used. Delay, expense, and
   error metrics (i.e., those TOS metrics other than the default metric)
   will be included only if (i) the level 2 router supports the specific
ToP   noToC   RFC1195 - Page 18
   TOS; (ii) the path from the level 2 router to the appropropriate
   level 1 router is made up of links which support the specific TOS;
   and (iii) the level 1 router which can reach the address directly
   also supports the specific TOS for this route, as indicated in its
   level 1 LSP.

   In general, the same [IP address, subnet mask] pair may be announced
   in level 1 LSPs sent by multiple level 1 routers in the same area. In
   this case (assuming the entry is not superceded by a manually
   configured entry), then only one such entry shall be included in the
   level 2 LSP. The metric value(s) announced in level 2 LSPs correspond
   to the minimum of the metric value(s) that would be calculated for
   each of the level 1 LSP entries.

   A level 2 router will have IP addresses which are directly reachable
   via its own interfaces. For purposes of inclusion of IP reachable
   address information in level 2 LSPs, these "directly reachable"
   addresses are treated exactly the same as addresses received in level
   1 LSPs.

   Manually configured addresses may hierarchically supercede multiple
   level 1 reachable address entries. However, there may be some IP
   addresses which match the manually configured addresses, but which
   are not reachable via level 1 routing. If a level 2 router receives
   an IP packet whose IP address matches a manually configured address
   which it is including in its level 2 LSP, but which is not reachable
   via level 1 routing in the area, then the packet must be discarded.
   In this case, an error report may be returned (as specified in RFC
   1009), with the reason for discard specifying destination
   unreachable.






           Figure 2 - An Example Routing Domain (not shown)

   An example is illustrated in figure 2. Suppose that the network
   number for the entire routing domain is 17 (a class A network).
   Suppose each area is assigned a subnet number consisting of the next
   8 bits. The area may be further subdivided by assigning the next
   eight bits to each LAN in the area, giving each a 24 bit subnet mask
   (counting the network and subnet fields). Finally 8 bits are left for
   the host field. Suppose that for a particular area (given subnet
   number 17.133) there are a number of IP capable level 1 routers
   announcing (in the special IP entry in their level 1 LSPs) subnets
   17.133.5, 17.133.43, and 17.133.57.
ToP   noToC   RFC1195 - Page 19
   Suppose that in this example, in order to save space in level 2 LSPs,
   the level 2 routers in this area are configured to announce subnet
   17.133. Only this one address needs to be announced in level 2 LSPs.
   Thus if an IP packet comes along for an address in subnet 17.133.5,
   17.133.43 or 17.133.57, then other level 2 routers, in other areas,
   will know to pass the traffic to this area.

   The inclusion of 17.133 in level 2 LSPs means that the three subnet
   addresses starting with 17.133 do not all have to be listed
   separately in level 2 LSPs.

   If any traffic comes along that is for an unreachable address such as
   17.133.124.7, then level 2 routers in other areas in this particular
   domain will think that this area can handle this traffic, will
   forward traffic to level 2 routers in this area, which will have to
   discard this traffic.

   Suppose that subnet number 17.133.125 was actually reachable via some
   other area, such as the lower right hand area. In this case, the
   level 2 router in the left area would be announcing (in its level 2
   LSPs according to manually configured information) reachability to
   subnet 17.133. However, the level 2 router in the lower right area
   would be announcing (in its level 2 LSPs according to information
   taken from its received level 1 LSPs), reachability to subnet
   17.133.125. Due to the use of best match routing, this works
   correctly. All traffic from other areas destined to subnet 17.133.125
   would be sent to the level 2 router in the lower right area, and all
   other traffic to subnet 17.133 (i.e., traffic to any IP address
   starting with 17.133, but not starting with 17.133.125) would be sent
   to the level 2 router in the leftmost area.

3.3 Addressing Routers in IS-IS Packets

   The IS-IS packet formats explicitly require that OSI-style addresses
   of routers appear in the IS-IS packets. For example, these addresses
   are used to determine area membership of routers. It is therefore
   necessary for all routers making use of the IS-IS protocol to have
   OSI style addresses assigned. For IP-only routers, these addresses
   will be used only in the operation of the IS-IS protocol, and are not
   used for any other purpose (such as the operation of EGP, ICMP, or
   other TCP/IP protocols).

   For OSI-only and dual routers, assignment of NSAP addresses is
   straight forward, but is outside of the scope of this specification.
   Address assignment mechanisms are being set up by standards bodies
   which allow globally unique OSI NSAP addresses to be assigned. All
   OSI-only and dual routers may therefore make use of normal OSI
   addresses in the operation of the IS-IS protocol.
ToP   noToC   RFC1195 - Page 20
   For IP-only routers, there are two ways in which NSAP addresses may
   be obtained for use with the IS-IS protocol.

   1) For those environments in which OSI is being used, or in which it
      is anticipated that OSI will be used in the future, it is
      permissible to obtain NSAP address assignments in the normal
      manner, assign normal NSAP addresses to IP-only routers, and use
      these addresses in the operation of IS-IS. This approach is
      recommended even for pure IP routing domains, as it will simplify
      future migration from IP-only to dual operation.

   2) In some cases, routers may have only TCP/IP addresses, and it may
      be undesireable to have to go through the normal mechanisms for
      assignment of NSAP addresses. Instead, an alternate mechanim is
      provided below for algorithmically generating a valid OSI style
      address from existing IP address and autonomous system number
      assignments.

   Where desired, for IP-only routers, for use in IS-IS packet formats
   only, OSI-style addresses (compatible with the USA GOSIP version 2.0
   NSAP address format [9]) may be derived as follows:

        AFI       1 octet       value "47" (specifies ICD format)

        ICD       2 octet       value "00 05" (specifies Internet/Gosip)

        DFI       1 octet       value "xx"

        AA        3 octets      value "xx xx xx" (specifies special
                                IP-only use of NSAPs)

        Reserved  2 octets      must be "00 00"

        RD        2 octets      contains autonomous system number

        Area      2 octets      must be assigned as described below

        ID        6 octets      must be assigned as described below

        SEL       1 octet       used as described below

   The AFI value of "47" and the ICD value of "00 05" specifies the
   Gosip Version 2.0 addressing format. The DFI number of "xx" and the
   AA of "xx xx xx" specify that this special NSAP address format is
   being used, solely for IS-IS packet formats in an IP-only
   environment. The reserved field must contain "00 00", as specified in
   GOSIP version 2.0.
ToP   noToC   RFC1195 - Page 21
   The routing domain field contains the Autonomous System number.
   Strictly speaking, this is not necessary, since the IS-IS packets are
   exchanged within a single AS only. However, inclusion of the AS
   number in this address format will ensure correct operation in the
   event that routers from separate routing domains/ASs are incorrectly
   placed on the same link. The AS number in this context is used only
   for definition of unique NSAP addresses, and does not imply any
   coupling with exterior routing protocols.

   The Area field must be assigned by the authority responsible for the
   routing domain, such that each area in the routing domain must have a
   unique Area value.

   The ID must be assigned by the authority responsible for the routing
   domain. The ID must be assigned such that every router in the routing
   domain has a unique value. It is recommended that one of the
   following methods is used:

   1)use a unique IEEE 802 48 bit station ID

   2)use the value hex "02 00" prepended to an IP address of the router.

   IEEE 802 addresses, if used, must appear in IEEE canonical format.

   Since the IEEE 802 station IDs are assigned to be globally unique,
   use of these values clearly assures uniqueness in the area. Also, all
   assigned IEEE 802 station IDs have the global/local bit set to zero.
   Prepending the indicated pattern to the front of the IP address
   therefore assures that format (2) illustrated above cannot produce
   addresses which collide with format (1). Finally, to the extent that
   IP addresses are also globally unique, format (2) will produce unique
   IDs for routers.

   The indicated hex value is specified in IEEE 802 canonical form [10].
   In IEEE 802 addresses, the multicast bit is the least significant bit
   of the first byte. The global/local bit is the next least significant
   bit of the first byte. The indicated prefix therefore sets the
   global/local bit to 1, and all other bits in the first two octets to
   0.

   Note that within an area, whether ISO addresses are configured into
   the routers through ISO address assignment, or whether the ISO-style
   address is generated directly from the AS number and IP address, all
   routers within an area must have the same high order part of address
   (AFI, ICD, DFI, AA, RD, and Area). This ISO-style address is used in
   IS-IS Hello messages and is the basis by which routers recognize
   whether neighbor nodes are in or out of their area.
ToP   noToC   RFC1195 - Page 22
3.4 External Links

   External connectivity (i.e., communications with routers outside of
   the routing domain) is done only by level 2 routers. The ISO version
   of IS-IS allows external OSI routes to be reported as "reachable
   address prefixes" in level 2 LSPs. The integrated IS-IS also allows
   external IP reachable addresses (i.e., IP addresses reachable via
   inter-domain routing) to be reported in level 2 LSPs in the "IP
   external reachability information" field. External OSI and external
   IP routes are handled independently.

   The routes announced in IP external reachability information entries
   include all routes to outside of the routing domain. This includes
   routes learned from OSPF, EGP, RIP, or any other external protocol.

   External routes may make use of "internal" or "external" metrics.
   Internal metrics are comparable with the metrics used for internal
   routes. Thus in choosing between an internal route, and an external
   route using internal metrics, the metric values may be directly
   compared. In contrast, external metrics cannot be directly compared
   with internal metrics. Any route defined solely using internal
   metrics is always preferred to any route defined using external
   metrics. When an external route using external metrics must be used,
   the lowest value of the external metric is preferred regardless of
   the internal cost to reach the appropriate exit point.

   It is useful, in the operation of external routing protocols, to
   provide a mechanism for border routers (i.e., routers in the same
   routing domain, which have the ability to route externally to other
   domains) to determine each other's existence, and to exchange
   external information (in a form understood only by the border routers
   themselves). This is made possible by inclusion of "inter-domain
   routing protocol information" fields in level 2 LSPs. The inter-
   domain routing protocol information field is not included in
   pseudonode LSPs.

   In general there may be multiple types of external inter-domain
   routing protocol information exchanged between border routers. The
   IS-IS therefore specifies that each occurance of the inter-domain
   routing protocol information field include a "type" field, which
   indicates the type of inter-domain routing protocol information
   enclosed. Values to be used in the type field will be specified in
   future versions of the "Assigned Numbers" RFC. Initial values for
   this field are specified in Annex A of this specification.

   Information contained in the inter-domain routing protocol
   information field will be carried in level 2 LSPs, and will therefore
   need to be stored by all level 2 routers in the domain. However, only
ToP   noToC   RFC1195 - Page 23
   those level 2 routers which are directly involved in external routing
   will use this information. In designing the use of this field, it is
   important to carefully consider the implications that this may have
   on storage requirements in level 2 routers (including those level 2
   routers which are not directly involved in external routing).

   The protocols used to exchange routing information directly between
   border routers, and external routers (in other routing domains /
   autonomous systems) are outside of the scope of this specification.

3.5 Type of Service Routing

   The integrated IS-IS protocol provides IP Type of Service (TOS)
   routing, through use of the Quality of Service (QOS) feature of IS-
   IS. This allows for routing on the basis of throughput (the default
   metric), delay, expense, or residual error probability. Note than any
   particular packet may be routed on the basis of any one of these four
   metrics. Routing on the basis of general combinations of metrics is
   not supported.

   The support for TOS/QOS is optional. If a particular packet calls for
   a specific TOS, and the correct path from the source to destination
   is made up of routers all of which support that particular TOS, then
   the packet will be routed on the optimal path. However, if there is
   no path from the source to destination made up of routers which
   support that particular type of service, then the packet will be
   forwarded using the default metric instead. This allows for TOS
   service in those environments where it is needed, while still
   providing acceptable service in the case where an unsupported TOS is
   requested.

   NOTE - IP does not have a cost TOS. There is therefore no mapping of
   IP TOS metrics which corresponds to the minimum cost metric.

   The IP TOS field is mapped onto the four available metrics as
   follows:

   Bits 0-2 (Precedence):  This field does not affect the route, but
                           rather may affect other aspects of packet
                           forwarding.

   Bits 3 (Delay), 4 (Throughput) and 5 (Reliability):

           000     (all normal)            Use default metric

           100     (low delay)             Use delay metric

           010     (high throughput)       Use default metric
ToP   noToC   RFC1195 - Page 24
           001     (high reliabiity)       Use reliability metric

           other                           Use default metric

3.6 Multiple LSPs and SNPs

   In some cases, IS-IS packets (specifically Link State Packets and
   Complete Sequence Number Packets) may be too large to fit into one
   packet. The OSI IS-IS [1] allows for LSPs and CSNPs to be split into
   multiple packets. This is independent of ISO 8473 segmentation, and
   is also independent of IP fragmentation. Use of independent multiple
   packets has the advantages (with respect to segmentation or
   fragmentation) that: (i) when information in the IS-IS changes, only
   those packets effected need to be re-issued; (ii) when a single
   packet is received, it can be processed without the need to receive
   all other packets of the same type from the same router before
   beginning processing.

   The Integrated IS-IS makes use of the same multiple packet function,
   as defined in [1]. IP-specific fields in IS-IS packets may be split
   across multiple packets. As specified in section 5 ("Structure and
   Encoding of PDUs"), some of the IP-specific fields (those which may
   be fairly long) may be split into several occurences of the same
   field, thereby allowing splitting of the fields across different
   packets.

   Multiple LSPs from the same router are distinguished by LSP number.
   Generally, most variable length fields may occur in an LSP with any
   LSP number. Some specific variable length fields may be required to
   occur in LSP number 0. Except where explicitly stated otherwise, when
   an IS-IS router issues multiple LSPs, the IP-specific fields may
   occur in an LSP with any LSP number.

   Complete Sequence Number Packets may be split into multiple packets,
   with the range to which each packet applies explicitly reported in
   the packet. Partial Sequence Number Packets are inherently partial,
   and so can easily be split into multiple packets if this is
   necessary. Again, where applicable, IP-specific fields may occur in
   any SNP.

3.7 IP-Only Operation

   For IP-only routers, the format for IS-IS packets remains unchanged.
   However, there are some variable length fields from the IS-IS packets
   that can be omitted. Specifically:
ToP   noToC   RFC1195 - Page 25
   IS-IS Hello Packets:

           - no change

   IS-IS Link State Packets:

           - the "End Systems Neighbours" entries are omitted

           - the "Prefix Neighbours" entries are omitted

   IS-IS Sequence Number Packets:

           - no change

3.8 Encapsulation

   Future versions of the Integated IS-IS may specify optional
   encapsulation mechanisms for partition repair, and for forwarding
   packets through incompatible routers (i.e., for forwarding OSI
   packets through IP-only routers, and forwarding IP packets through
   OSI-only routers). The details of encapsulation and decapsulation are
   for further study. Routers complying with the Integrated IS-IS are
   not required to implement encapsulation nor decapsulation.

3.9 Authentication

   The authentication field allows each IS-IS packet to contain
   information used to authenticate the originator and/or contents of
   the packet.  The authentication information contained in each packet
   is used to authenticate the entire packet, including OSI and IP
   parts. If a packet is received which contains invalid authentication
   information, then the entire packet is discarded. If an LSP or SNP is
   split into multiple packets (as described in section 3.6), then each
   is authenticated independently.

   Use of the authentication field is optional. Routers are not required
   to be able to interpret authentication information. As with other
   fields in the integrated IS-IS, if a router does not implement
   authentication then it will ignore any authentication field that may
   be present in an IS-IS packet.

   Annex D specifies a proposed use of the authentication field.

3.10 Order of Preference of Routes / Dijkstra Computation

   We define the term "IP reachability entry" to mean the combination of
   the [IP address, subnet mask]. The Dijkstra calculation must
   calculate routes to each distinct IP reachability entry. For the
ToP   noToC   RFC1195 - Page 26
   Dijkstra calculation, each IP reachability entry can be treated in
   much the same manner as an OSI end system. Naturally, each IP
   reachability entry is treated as distinct from any OSI end systems
   which may also be reachable in the same area or routing domain.

   For any particular IP reachability entry, this is the same as another
   entry if and only if: (i) the subnet masks are identical; and (ii)
   for each bit in the subnet mask which has the value "1", the IP
   address is identical. This can easily be tested by zeroing those bits
   in the IP address which correspond to a zero bit in the mask, and
   then treating the entry as a 64 bit quantity, and testing for
   equality between different 64 bit quantities. The actual calculation
   of routes to IP reachability entries is therefore no more complex
   than calculation of routes to OSI end systems (except for the
   replacement of a 48-bit test with a 64-bit test).

   The Dijkstra computation does not take into consideration whether a
   router is IP-only, OSI-only, or dual. The topological restrictions
   specified in section 1.4 ensure that IP packets will only be sent via
   IP-capable routers, and OSI packets will only be sent via OSI-capable
   routers.

   The Integrated IS-IS prefers routes within the area (via level 1
   routing) whenever possible. If level 2 routes must be used, then
   routes within the routing domain (specifically, those routes using
   internal metrics) are prefered to routes outside of the routing
   domain (using external metrics).

   The Integrated IS-IS protocol makes use of "best match" routing of IP
   packets. This implies that a particular destination address may match
   more than one entry in the forwarding database. If a particular IP
   packet has a destination address which matches two different IP
   reachability entries, then the entry who's mask contains the most "1"
   bits is preferred.

   IP packets whose destination is a router are routed the same way as
   any other IP packet, by forwarding first to the appropriate subnet,
   and then forwarding on that subnet to the destination host (which
   just happens to be a router in this case). In particular, the IP
   forwarding database does not contain explicit routes to the
   individual "IP interface addresses" listed by each router in its LSP.

   However, host routes (routes with a subnet mask of all ones) may of
   course be included in the IP reachability entries, and will be
   handled in the same manner as other IP reachability entries.

   In order to ensure correct interoperation of different router
   implementations, it is necessary to specify the order of preference
ToP   noToC   RFC1195 - Page 27
   of possible routes. For OSI destinations, this is outside of the
   scope of this report. For IP destinations, this is specified in
   section 3.10.1 and 3.10.2 below. Annex C specifies a detailed
   Dijkstra calculation and forwarding algorithm which is compatible
   with the order of preference of routes specified here.

   With IS-IS, if a route to a given destination is advertised, or a
   link between routers is advertised, then metric values associated
   with some or all of the specified TOS metric types may be associated
   with that destination or link. However, the default metric must
   always be available. Normally this ensures that if a route using any
   TOS metric is available, then a route using the default metric will
   also be available. The only exception to this is where the
   corresponding route using the default metric has a total cost (within
   the area, or within the level 2 backbone) greater than MaxPathMetric.

   In determining the route to a particular destination for a specified
   TOS, only routes using either the requested TOS metric, or the
   default TOS metric, are considered.

3.10.1 Order of Preference of Routes In Level 1 Routing

   If a given destination is reachable within an area via a route using
   either the requested TOS or the default TOS, then the IS-IS will
   always make use of a path within the area (via level 1 routing),
   regardless of whether an alternate path exists outside of the area
   (via level 2 routing). In this case, routes within the area are
   selected as follows:

   1) Amongst routes in the area, if the specified destination
      address matches more than one [IP address, subnet mask] pair,
      then the more specific address match (the one with more "1"
      bits in the mask) is prefered.

   2) Amongst routes in the area to equally specific address
      matches, routes on which the requested TOS (if any) is
      supported are always prefered to routes on which the
      requested TOS is not supported.

   3) Amongst routes in the area of the same TOS to equally
      specific address matches, the shortest routes are prefered.
      For determination of the shortest path, if a route on which
      the specified TOS is supported is available, then the
      specified TOS metric is used, otherwise the default metric
      is used. Amongst routes of equal cost, load splitting may
      be performed as specified in [1].

   For a level 1 only router (i.e., a router which does not take part in
ToP   noToC   RFC1195 - Page 28
   level 2 routing, or a level 2 router which is not "attached"), if a
   given destination is not reachable within an area, level 1 routing
   will always route to a level 2 router as follows:

   1) Amongst routes in the area to attached level 2 routers,
      routes on which the requested TOS (if any) is supported
      are always prefered to routes on which the requested TOS
      is not supported.

   2) Amongst routes in the area of the same TOS to attached
      level 2 routers, the shortest routes are prefered. For
      determination of the shortest path, if a route on which
      the specified TOS is supported is available, then the
      specified TOS metric is used, otherwise the default
      metric is used. Amongst routes of equal cost,
      loadsplitting may be performed as specified in [1].

3.10.2 Order of Preference of Routes in Level 2 Routing

   For those level 2 routers which also take part in level 1 routing,
   routes learned via level 1 routing, using either the requested TOS or
   the default TOS, are always prefered to routes learned through level
   2 routing. For destinations which are not reachable via level 1
   routing, or for level 2 only routers (routers which do not take part
   in level 1 routing), then level 2 routes are selected as follows:

   1) Routes using internal metrics only are always preferred
      to routes using external metrics.

   2) If a route using internal metrics only is available:

      a) If the specified destination address matches more
         than one [IP address, subnet mask] pair, then the more
         specific address match (i.e., the largest number of
         "1"s present in the subnet mask) is prefered.

      b) Amongst routes with equally specific address matches
         (i.e., an equal number of "1"s present in the subnet
         mask), routes on which the requested TOS (if any) is
         supported are always preferred to routes on which the
         requested TOS is not supported.

      c) Amongst routes of the same TOS with an equally specific
         address matches, the shortest path is prefered. For
         determination of the shortest path, if a route on which
         the specified TOS is supported is available, then the
         specified TOS metric is used, otherwise the default
         metric is used. Amongst routes of equal cost,
ToP   noToC   RFC1195 - Page 29
         loadsplitting may be performed as specified in [1].

         NOTE: Internal routes (routes to destinations announced
         in the "IP Internal Reachability Information" field),
         and external routes using internal metrics (routes to
         destinations announced in the "IP External Reachability
         Information" field, with a metric of type "internal")
         are treated identically for the purpose of the order of
         preference of routes, and the Dijkstra calculation.

   3) If a route using internal metrics only is not available,
      but a route using external metrics is available:

      a) If the specified destination address matches more than
         one [IP address, subnet mask] pair, then the more
         specific address match is prefered.

         NOTE: For external routes, the subnet mask will normally
         correspond precisely to the network number. This implies
         that this test will always discover equal length matching
         strings.  However, this test is included to allow future
         migration to more general handling of external addresses.

      b) Amongst routes with equally specific matches, routes on
         which the requested TOS (if any) is supported are always
         preferred to routes on which the requested TOS is not
         supported. NOTE: for external routes, the route is
         considered to support the requested TOS only if the
         internal route to the appropriate border router
         supports the requested TOS, and the external route
         reported by the border router also supports the
         requested TOS.

      c) Amongst routes of the same TOS with an equal length
         matching address string, the shortest path is prefered.
         For determination of the shortest path:

         (i)  Routes with a smaller announced external metric
              are always prefered.

         (ii) Amongst routes with an equal external metric,
              routes with a shorter internal metric are prefered.
              Amongst routes of equal cost, loadsplitting may be
              performed as specified in [1].

   For level 2 routers which are announcing manually configured summary
   addresses in their level 2 LSPs, in some cases there will exist IP
   addresses which match the manually configured addresses, but which do
ToP   noToC   RFC1195 - Page 30
   not match any addresses which are actually reachable via level 1
   routing in the area. Generally, packets to such addresses are handled
   according to the following rules:

   1) If the specified destination is reachable via level 1 routing,
      then according to the order of preference of routes specified
      above, the packet will be delivered via level 1 routing.

   2) If the specified destination is not reachable via level 1 routing,
      but is reachable via 2 routing, and there are other level 2
      routers which offer more desireable routes according to the
      rules specified above (for example a route with a more specific
      match, or a route with an equally specific match which supports
      the correct TOS), then level 2 routing will forward the packet
      according to the more desireable route.

   3) If the specified destination is not reachable via level 1 routing,
      and the manually configured summary address advertised by this
      router (the router which has received the packet and is trying
      to forward it) represents the most desireable route, then the
      destination is unreachable and the packet must be discarded.



(page 30 continued on part 2)

Next Section