RFC relevance of addresses

As per Relevance of the word addresses, we have this rfc below:

Network Working Working Group R.
Request for Comments: 1195 Digital Equipment
December 1990

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

Status of this

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

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

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

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

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

1 Introduction: Overview of the
1.1 What the Integrated IS-IS
1.2 Overview of the ISO IS-IS
1.3 Overview of the Integrated IS-
1.4 Support of Mixed Routing

Callon [Page 1]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

1.5 Advantages of Using Integrated IS-

2 Symbols and

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

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

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

6 Security

7 Author's

8

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

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

C Dijkstra Calculation and
C.1 SPF Algorithm for IP and Dual
C.2 Forwarding of IP

Callon [Page 2]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

D Use of the Authentication
D.1 Authentication Field in IS-IS
D.2 Authentication Type 1 - Simple

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

1 ISO Hierarchical Address
2 An
3 Encoding of Variable Length

1 Introduction: Overview of the

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

There are two main methods that are available for routing
to support dual OSI and IP routers. One method, known as "Ships
the Night", makes use of completely independent routing protocols
each of the two protocol suites. This specification presents
alternate approach, which makes use of a single integrated
for interior routing (i.e., for calculating routes within a
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
is considered a companion to the OSI IS-IS Routing spec, and
only describe the required additional features

By supporting both IP and OSI traffic, this integrated
design supports traffic to IP hosts, OSI end systems, and dual
systems. This approach is "integrated" in the sense that the IS-
protocol can be used to support pure-IP environments, pure-
environments, and dual environments. In addition, this
allows interconnection of dual (IP and OSI) routing domains
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-
working group

1.1 What the Integrated IS-IS

The integrated IS-IS provides a single routing protocol which

Callon [Page 3]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

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

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

The protocol described in this specification allows for mixing
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
router which: (i) Uses IS-IS as the routing protocol for IP,
specified in this report; and (ii) Does not otherwise support
protocols. For example, such routers would not be able to forward
CLNP packets

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

A dual IS-IS router (or "dual" router) is defined to be a
which uses IS-IS as a single integrated routing protocol for both
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
of Internet Gateways [4]. The integrated IS-IS protocol described
this report outlines an Interior Gateway Protocol (IGP) which
provide routing within a TCP/IP routing domain (i.e.,
system). Other aspects of router functionality (e.g., operation
ICMP, ARP, EGP, etc.) are not affected by this proposal

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

Callon [Page 4]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

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
may be added to all IS-IS packets; (ii) the protocols supported
each router, as well as each router's IP addresses, are specified
ISO 9542 IS Hello, IS-IS Hello and Link State Packets; (iii
internally reachable IP addresses are specified in all Link
Packets; and (iv) externally reachable IP addresses, and
routing protocol information, may be specified in level 2 Link
Packets. The detailed encoding and interpretation of this
formation is specified in sections 3, 4, and 5 of this RFC

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

This protocol specification does not constrain which
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
subject of a separate, companion document [8].

1.2 Overview of the ISO IS-IS

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

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

Currently, ISO does not have a standard for inter-domain
(i.e., for routing between separate autonomous routing domains).

Callon [Page 5]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

Instead, manual configuration is used. The link is
configured with the set of address prefixes reachable via that link
and with the method by which they can be reached (such as the
address to be dialed to reach that address, or the fact that the
address should be extracted from the IDP portion of the ISO address).

OSI IS-IS routing makes use of two-level hierarchical routing.
routing domain is partitioned into areas. Level 1 routers know
topology in their area, including all routers and end systems
their area. However, level 1 routers do not know the identity
routers or destinations outside of their area. Level 1
forward all traffic for destinations outside of their area to a
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
within any level 1 area, except to the extent that a level 2
may also be a level 1 router within a single area. Only level 2
routers can exchange data packets or routing information
with external routers located outside of the routing domains

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

Figure 1 - ISO Hierarchical Address

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

Callon [Page 6]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

allowing this are

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

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

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

Since OSI addressing explicitly identifies the area, it is very
for level 1 routers to identify packets going to destinations
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
portion of the ISO address. They route within an area.
recognize, based on the destination address in a packet,
the destination is within the area. If so, they route
the destination. If not, they route to the nearest level 2 router

- Level 2 intermediate systems -- these nodes route based on the
address (i.e., on the combination of [IDP, HO-DSP]). They
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
configured. It will refuse to become a neighbor with a node
area addresses do not overlap its area addresses. However, if level 1
router has area addresses A, B, and C, and a neighbor has
addresses B and D, then the level 1 router will accept the other
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

Callon [Page 7]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

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
(to other routing domains) must be from level 2 routers

IS-IS provides an optional partition repair function. In the
case that a level 1 area become partitioned, this function,
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.
the level 2 backbone become partitioned, there is no provision
use of level 1 links to repair a level 2 partition

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

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

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

These problems are avoided by use of a "pseudonode", which
the LAN. Each router on the LAN reports that it has a link to
pseudonode (rather than reporting a link to every other router on
LAN). One of the routers on the LAN is elected "designated router".
The designated router then sends out an LSP on behalf of
pseudonode, reporting links to all of the routers on the LAN.
reduces the potential n-squared links to n links. In addition,
the pseudonode LSP includes the list of end systems on the LAN
thereby eliminating the potential duplication (for
information on designated routers and pseudonodes, see [1]).

Callon [Page 8]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

The IS-IS provides for optional Quality of Service (QOS) routing
based on throughput (the default metric), delay, expense, or
error probability. This is described in greater detail in
3.5, and in [1].

1.3 Overview of the Integrated IS-

The integrated IS-IS allows a single routing protocol to be used
route both IP and OSI packets. This implies that the same two-
hierarchy will be used for both IP and OSI routing. Each area will
specified to be either IP-only (only IP traffic can be routed in
particular area), OSI-only (only OSI traffic can be routed in
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
no provision for independent OSI and IP backbones

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

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

Callon [Page 9]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

area structure

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

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

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

Flexible use of the limited IP address space is important in order
cope with the anticipated growth of IP environments. Thus an
(and by implication a routing domain) may simultaneously make use
a variety of different address masks for different subnets in
area (or domain). Generally, if a specified destination
matches more than one [IP address, subnet mask] pair, the
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 [
address, subnet mask, metric] specifying all IP addresses
in their area. As described in section 3, this information may
obtained from a combination of the level 1 LSPs (obtained from
1 routers in the same area), and/or by manual configuration.
addition, Level 2 routers may report external
information, corresponding to addresses which can be reached
routers in other routing domains (autonomous systems

Default routes may be announced by use of a subnet mask
all zeroes. Default routes should be used with great care, since
can result in "black holes". Default routes are permitted only
level 2 as external routes (i.e., included in the "IP
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

Callon [Page 10]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

1.4 Support of Mixed Routing

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

- Pure

- Pure

-

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

In a pure OSI routing domain, all routers must be OSI-capable. OSI
only routers may be freely mixed with dual routers. Some
specifically related to IP operation may be included by dual routers
and will be ignored by OSI-only routers. Only OSI traffic will
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
mixed on a per-area basis. Specifically, each area may itself
defined to be pure IP, pure OSI, or dual

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

In a pure-OSI area within a dual domain, OSI-only and dual
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
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
between areas then all level 2 routers must be dual

1.5 Advantages of Using Integrated IS-

Use of the integrated IS-IS protocol, as a single protocol
routing both IP and OSI packets in a dual environment,
significant advantages over using separate protocols

Callon [Page 11]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

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
used for IP and for OSI. For example, OSPF [5] may be used
routing IP traffic, and IS-IS [1] may be used for routing
traffic. With S.I.N., the two routing protocols operate more or
independently. However, dual routers will need to implement
routing protocols, and therefore there will be some degree
competition for resources

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

In the future, optional extensions to IS-IS may be defined
routing other common protocol suites. However, such future
are outside of the scope of this document. This section will
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
management effort required. Since the integrated IS-IS provides
single routing protocol, within a single coordinated routing
using a single backbone, this implies that there is less
to configure. This combined with a single coordinated MIB
network management

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

Another advantage of the integrated IS-IS is that, since it
only one routing protocol, it uses fewer resources. In particular
less implementation resources are needed (since only one
needs to be implemented), less CPU and memory resources are used
the router (since only one protocol needs to be run), and
network resources are used (since only one set of routing
need to be transmitted). Primarily this translates into a
savings, since each of these three types of resources cost money
This implies that dual routers based on the integrated IS-IS
be less expensive to purchase and operate than dual routers based
S.I.N

Callon [Page 12]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

Note that the operation of two routing protocols with the S.I.N
approach are not really independent, since they must share
resources. For example, if one routing protocol becomes unstable
starts to use excessive resources, the other protocol is likely
suffer. A bug in one protocol could crash the other. However,
the integrated IS-IS, the interactions are explicit and are
into the protocol and software interactions. With S.I.N.,
interactions are implicit

The use of a single integrated routing protocol similarly reduces
likely frequency of software upgrades. Specifically, if you have
different routing protocols in your router, then you have to
the software any time EITHER of the protocols change. If you make
of a single integrated routing protocol, then software changes
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
specified. In other routing protocols, these requirements
implicit. However, in all routing protocols, there are real
guarantees which must be met in order to ensure correct operation.
general, it is difficult enough to ensure compliance with real
requirements in the implementation of a single real time system.
S.I.N., implementation of two semi-independent real-time protocols
a single device makes this more difficult

Note that both integrated IS-IS and S.I.N. allow for independence
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

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

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

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

DFI DSP Format
(a one octet field in the GOSIP version 2.0 NSAP
format

Callon [Page 13]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

ES End
(The OSI term for a host

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

ICD International Code
(ISO standard for identifying organizations

IP Internetwork
(an Internet Standard Network Layer Protocol

IS Intermediate
(The OSI term for a router

IS-IS Intermediate System to Intermediate System
Exchange
(the ISO protocol for routing within a
routing domain

IS-IS Hello An Hello packet defined by the IS-IS
(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
(an international body which is authorized to
standards of many kinds

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

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

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

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

OSI Open Systems
(an international standard protocol architecture

Callon [Page 14]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

RD Routing
(the set of routers and end systems using a
instance of a routing protocol such as IS-IS

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

TCP Transmission Control
(an Internet Standard Transport Layer Protocol

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

3 Subnetwork Independent

3.1 Exchange of Routing

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

The IS-IS protocol provides for the inclusion of variable
fields in all IS-IS packets. These fields are encoded using a "Code
Length, Value" triplet, where the code and length are encoded in
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
not recognised are ignored and passed through unchanged".
requirement applies to all routers implementing IS-IS,
OSI-only, IP-only, and dual routers. This allows IP-
information to be encoded in a manner which OSI-only routers
ignore, and also allows OSI-specific information to be encoded in
manner which IP-only routers will ignore

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

IP-capable routers need to know the IP address of the
interface of neighboring routers. This is required for sending
redirects (when an IP-capable router sends an ICMP redirect to
host, it must include the IP address of the appropriate interface

Callon [Page 15]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

the correct next-hop router). This information is made available
inclusion of the IP interface address in the IS-IS Hello packets
Specifically, each IS-IS Hello packet contains the IP address(es)
the interface over which the Hello is transmitted. The IS-IS
multiple IP addresses to be assigned to each physical interface

In some cases, it will be useful for IP-capable routers to be able
determine an IP address(es) of all other routers at their
(i.e., for level 1 routers: all other routers in their area;
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,
as for encapsulation or for transmission of network
packets. This information is made available by inclusion of
address in LSPs. Specifically, each IS-IS LSP includes one or more
addresses of the router which transmits the LSP. An IP-capable
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.
a single router operates as both a level 1 and a level 2 router,
is required to include the same IP address(es) in its level 1
level 2 LSPs

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

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

The detailed encoding of the IP-specific information included
routing packets is provided in section 5 (Structure and Encoding

Callon [Page 16]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

PDUs).

3.2 Hierarchical Abbreviation of IP Reachability

Level 2 routers include in their level 2 LSPs a list of all [
address, subnet mask, metric] combinations reachable in their area
In general, this information may be determined from the level 1
from all routers in the area. If we ignore resource constraints,
it would be permissible for a level 2 router to simply duplicate
[IP address, subnet mask, metric] entries from all level 1 routers
its area (with appropriate metric adjustment), for inclusion in
level 2 LSP. However, in order for hierarchical routing to scale
large routing domain sizes, it is highly desired to abbreviate
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
with the configured reachable addresses. Redundant
obtained from level 1 LSPs is not included in level 2 LSPs.
it is expected that the level 2 configured information will
more inclusive addresses (corresponding to a subnet mask with
bits set to 1). This will therefore allow one
address/submask pair (or a small number of such pairs)
hierarchically supercede the information corresponding to
entries in level 1 LSPs

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

Any address obtained from a level 1 LSP which is not superceded
the manually configured information is included in the level 2 LSPs
In this case, the metric value announced in the level 2 LSPs
calculated from the sum of the metric value announced in
corresponding level 1 LSP, plus the distance from the level 2
to the appropriate level 1 router. Note: If this sum results in
metric value greater than 63 (the maximum value that can be
in level 2 LSPs), then the value 63 must be used. Delay, expense,
error metrics (i.e., those TOS metrics other than the default metric
will be included only if (i) the level 2 router supports the

Callon [Page 17]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

TOS; (ii) the path from the level 2 router to the
level 1 router is made up of links which support the specific TOS
and (iii) the level 1 router which can reach the address
also supports the specific TOS for this route, as indicated in
level 1 LSP

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

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

Manually configured addresses may hierarchically supercede
level 1 reachable address entries. However, there may be some
addresses which match the manually configured addresses, but
are not reachable via level 1 routing. If a level 2 router
an IP packet whose IP address matches a manually configured
which it is including in its level 2 LSP, but which is not
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
1009), with the reason for discard specifying
unreachable

Figure 2 - An Example Routing Domain (not shown

An example is illustrated in figure 2. Suppose that the
number for the entire routing domain is 17 (a class A network).
Suppose each area is assigned a subnet number consisting of the
8 bits. The area may be further subdivided by assigning the
eight bits to each LAN in the area, giving each a 24 bit subnet
(counting the network and subnet fields). Finally 8 bits are left
the host field. Suppose that for a particular area (given
number 17.133) there are a number of IP capable level 1
announcing (in the special IP entry in their level 1 LSPs)
17.133.5, 17.133.43, and 17.133.57.

Callon [Page 18]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

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
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
addresses starting with 17.133 do not all have to be
separately in level 2 LSPs

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

Suppose that subnet number 17.133.125 was actually reachable via
other area, such as the lower right hand area. In this case,
level 2 router in the left area would be announcing (in its level 2
LSPs according to manually configured information) reachability
subnet 17.133. However, the level 2 router in the lower right
would be announcing (in its level 2 LSPs according to
taken from its received level 1 LSPs), reachability to
17.133.125. Due to the use of best match routing, this
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
other traffic to subnet 17.133 (i.e., traffic to any IP
starting with 17.133, but not starting with 17.133.125) would be
to the level 2 router in the leftmost area

3.3 Addressing Routers in IS-IS

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

For OSI-only and dual routers, assignment of NSAP addresses
straight forward, but is outside of the scope of this specification
Address assignment mechanisms are being set up by standards
which allow globally unique OSI NSAP addresses to be assigned.
OSI-only and dual routers may therefore make use of normal
addresses in the operation of the IS-IS protocol

Callon [Page 19]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

For IP-only routers, there are two ways in which NSAP addresses
be obtained for use with the IS-IS protocol

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

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

Where desired, for IP-only routers, for use in IS-IS packet
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
IP-only use of NSAPs

Reserved 2 octets must be "00 00"

RD 2 octets contains autonomous system

Area 2 octets must be assigned as described

ID 6 octets must be assigned as described

SEL 1 octet used as described

The AFI value of "47" and the ICD value of "00 05" specifies
Gosip Version 2.0 addressing format. The DFI number of "xx" and
AA of "xx xx xx" specify that this special NSAP address format
being used, solely for IS-IS packet formats in an IP-
environment. The reserved field must contain "00 00", as specified
GOSIP version 2.0.

Callon [Page 20]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

The routing domain field contains the Autonomous System number
Strictly speaking, this is not necessary, since the IS-IS packets
exchanged within a single AS only. However, inclusion of the
number in this address format will ensure correct operation in
event that routers from separate routing domains/ASs are
placed on the same link. The AS number in this context is used
for definition of unique NSAP addresses, and does not imply
coupling with exterior routing protocols

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

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

1)use a unique IEEE 802 48 bit station

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,
assigned IEEE 802 station IDs have the global/local bit set to zero
Prepending the indicated pattern to the front of the IP
therefore assures that format (2) illustrated above cannot
addresses which collide with format (1). Finally, to the extent
IP addresses are also globally unique, format (2) will produce
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
of the first byte. The global/local bit is the next least
bit of the first byte. The indicated prefix therefore sets
global/local bit to 1, and all other bits in the first two octets
0.

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

Callon [Page 21]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

3.4 External

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

The routes announced in IP external reachability information
include all routes to outside of the routing domain. This
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
routes. Thus in choosing between an internal route, and an
route using internal metrics, the metric values may be
compared. In contrast, external metrics cannot be directly
with internal metrics. Any route defined solely using
metrics is always preferred to any route defined using
metrics. When an external route using external metrics must be used
the lowest value of the external metric is preferred regardless
the internal cost to reach the appropriate exit point

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

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

Information contained in the inter-domain routing
information field will be carried in level 2 LSPs, and will
need to be stored by all level 2 routers in the domain. However,

Callon [Page 22]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

those level 2 routers which are directly involved in external
will use this information. In designing the use of this field, it
important to carefully consider the implications that this may
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
border routers, and external routers (in other routing domains /
autonomous systems) are outside of the scope of this specification

3.5 Type of Service

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
metric), delay, expense, or residual error probability. Note than
particular packet may be routed on the basis of any one of these
metrics. Routing on the basis of general combinations of metrics
not supported

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

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

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

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

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

000 (all normal) Use default

100 (low delay) Use delay

010 (high throughput) Use default

Callon [Page 23]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

001 (high reliabiity) Use reliability

other Use default

3.6 Multiple LSPs and

In some cases, IS-IS packets (specifically Link State Packets
Complete Sequence Number Packets) may be too large to fit into
packet. The OSI IS-IS [1] allows for LSPs and CSNPs to be split
multiple packets. This is independent of ISO 8473 segmentation,
is also independent of IP fragmentation. Use of independent
packets has the advantages (with respect to segmentation
fragmentation) that: (i) when information in the IS-IS changes,
those packets effected need to be re-issued; (ii) when a
packet is received, it can be processed without the need to
all other packets of the same type from the same router
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
across multiple packets. As specified in section 5 ("Structure
Encoding of PDUs"), some of the IP-specific fields (those which
be fairly long) may be split into several occurences of the
field, thereby allowing splitting of the fields across
packets

Multiple LSPs from the same router are distinguished by LSP number
Generally, most variable length fields may occur in an LSP with
LSP number. Some specific variable length fields may be required
occur in LSP number 0. Except where explicitly stated otherwise,
an IS-IS router issues multiple LSPs, the IP-specific fields
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
the packet. Partial Sequence Number Packets are inherently partial
and so can easily be split into multiple packets if this
necessary. Again, where applicable, IP-specific fields may occur
any SNP

3.7 IP-Only

For IP-only routers, the format for IS-IS packets remains unchanged
However, there are some variable length fields from the IS-IS
that can be omitted. Specifically

Callon [Page 24]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

IS-IS Hello Packets

- no

IS-IS Link State Packets

- the "End Systems Neighbours" entries are

- the "Prefix Neighbours" entries are

IS-IS Sequence Number Packets

- no

3.8

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

3.9

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

Use of the authentication field is optional. Routers are not
to be able to interpret authentication information. As with
fields in the integrated IS-IS, if a router does not
authentication then it will ignore any authentication field that
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

We define the term "IP reachability entry" to mean the combination
the [IP address, subnet mask]. The Dijkstra calculation
calculate routes to each distinct IP reachability entry. For

Callon [Page 25]

RFC 1195 OSI ISIS for IP and Dual Environments December 1990

Dijkstra calculation, each IP reachability entry can be treated
much the same manner as an OSI end system. Naturally, each
reachability entry is treated as distinct from any OSI end
which may also be reachable in the same area or routing domain

For any particular IP reachability entry, this is the same as
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
address is identical. This can easily be tested by zeroing those
in the IP address which correspond to a zero bit in the mask,
then treating the entry as a 64 bit quantity, and testing
equality between different 64 bit quantities. The actual
of routes to IP reachability entries is therefore no more
than calculation of routes to OSI end systems (except for
replacement of a 48-bit test with a 64-bit test).

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

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

The Integrated IS-IS protocol makes use of "best match" routing of
packets. This implies that a particular destination address may
more than one entry in the forwarding database. If a particular
packet has a destination address which matches two different
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
any other IP packet, by forwarding first to the