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
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
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:
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
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
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
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,
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
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.
4 Subnetwork Dependent Functions
4.1 Link Demultiplexing
Dual routers may receive a combination of OSI packets, and IP
packets. It is necessary for the dual routers to be able to clearly
and unambiguously distinguish the two protocol suites.
This problem is not unique to the integrated IS-IS routing protocol.
In fact, this problem will occur in any multi-protocol environment.
This problem is currently being worked on independently, and is
outside of the scope of this specification.
In general, the link type is a configuration parameter. For example,
whether to use PPP, HDLC, or some other point-to-point protocol over
a point-to-point link would be configured. For any particular link
type, a method must be defined for encapsulation of both OSI and IP
packets. Definition of such methods for common link types is outside
of the scope of this specification.
IP packets are encapsulated directly over the underlying link layer
service, using the normal method for transmssion of IP packets over
each type of link. Similarly OSI packets are encapsulated directly
over the underlying link layer service, using the normal method for
transmission of OSI packets over each type of link. Finally, note
that IS-IS packets are encapsulated using the normal method for
transmission of OSI packets over any particular link type. This
implies that all IS-IS routers, including IP-only routers, must be
able to receive IS-IS packets using the normal encapsulation for OSI
packets.
4.2 Multiple IP Addresses per Interface
The integrated IS-IS allows each router to have multiple IP addresses
for each physical interface, up to the maximum number which may be
contained in a single "IP Interface Address" field (i.e., up to a
maximum of 63 addresses per interface). For example, where there are
two logical subnets on the same LAN, the interface may have two IP
addresses, one corresponding to each logical subnet. Each IS-IS Hello
packet contains a list of IP addresses associated with the physical
interface over which the Hello is transmitted.
It is permissible to implement routers which conform to the
Integrated IS-IS specification which restrict the number of IP
addresses per interface. However, IP-capable routers must be able to
interact correctly with other routers which assign multiple IP
addresses per physical interface (up to the maximum of 63 addresses
per interface).
Where appropriate (for example, in some cases on point-to-point
links), some interfaces may have no IP addresses assigned. In this
case, the IS-IS Hello transmitted on that interface may omit the IP
Interface Address field, or may include the IP Interface Address
field with zero entries.
4.3 LANs, Designated Routers, and Pseudonodes
The maintenance of designated routers and pseudonodes is specified in
[1], and is not changed by this proposal. In the case that IP-only
and dual routers (or OSI-only and dual routers) are mixed on the same
LAN in a pure IP area (or a pure OSI area, respectively), any router
on the LAN may be elected designated router.
However, there is a fundamental difference in the way that OSI and
TCP/IP deal with LANs, and other broadcast subnetworks.
With OSI, the use of the ES-IS protocol (ISO 9542) allows the end
systems and routers to automatically determine their connectivity,
thereby allowing all end systems on the LAN to potentially route via
any of the routers on the LAN.
In contract, TCP/IP explictly assigns subnet identifiers to each
local area network. In some cases, a single physical LAN could have
multiple subnet identifiers assigned to it. In this case, end systems
(hosts) which have an address on one logical subnet are explicitly
precluded from sending IP packets directly to a router whose address
places it on a different logical subnet. Each router is manually
configured to know which subnets it can reach on each interface. In
the case that there are multiple logical subnets on the same LAN,
each router can only exchange IP packets with those end systems which
are on the same logical subnet. This implies that it is not
sufficient for the pseudonode LSP to announce all subnets on the LAN
(i.e., all [IP address, subnet mask] pairs reachable on the LAN).
It is therefore necessary for each router to announce in its LSPs
those subnets which it can reach on each interface, including
interfaces to broadcast subnetworks such as LANs. The pseudonode LSP
does not specify the IP addresses which are reachable on the LAN
(i.e., does not contain the the IP reachability field).
As specified elsewhere (see the forthcoming update to the
"Requirements of IP Gateways" [4]), routers may send ICMP redirects
only if: (i) the IP packet is being forwarded over the same physical
interface over which it arrived; and (ii) the source address of the
forwarded IP packet, the IP address of this router's interface (as
indicated by the source address of the ICMP redirect), and the IP
address of the router to which the packet is being redirected (again,
as indicated in the ICMP redirect) are all on the same IP subnet.
4.4 Maintaining Router Adjacencies
The IS-IS determines whether an adjacency is to be established
between two routers using means which are independent of the IP
interface addresses of the routers. Where multiple logical subnets
occur on the same physical LAN, this potentially allows adjacencies
to be brought up between two routers which share physical
connectivity to each other, but which don't have a logical subnet in
common. IP-capable IS-IS routers therefore must be able to forward IP
packets over existing adjacencies to routers with which they share
physical connectivity, even when the IP address of the adjacent
interface of the neighboring router is on a different logical IP
subnet.
For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs,
as the first step in establishing the link between routers. All IS-IS
routers are therefore required to transmit and receive ISO 9542 ISH
packets on point-to-point links.
The "protocols supported" field (defined in section 5 below) must be
present in all IS-IS Hello packets sent by dual and IP-only routers.
If this field is missing, then it is assumed that the packet was
transmitted by an OSI-only router. Similarly, those 9542 ISHs sent
over point-to-point links, where there is (or may be) another IS-IS
router at the other end of the point-to-point link, must also
contains the "protocols supported" field. Note that if this field is
mistakenly sent in a 9542 ISH where there is an ordinary OSI-only End
System at the other end of the link, then (in accordance to ISO 9542)
the End System is required to ignore the field and interpret the ISH
correctly. It is therefore safe to always include this field in ISHs
sent over point-to-point links.
Dual routers must operate in a dual fashion on every link in the
routing domain over which they are running IS-IS. Thus, the value of
the "protocols supported" field must be identical on every link
(i.e., for any one router running IS-IS, all of the Hellos and LSPs
transmitted by it must contain the same "protocols supported"
values).
4.5 Forwarding to Incompatible Routers
There may be times when a dual router has to forward an IP packet to
an OSI-only router, or forward an OSI packet to an IP-only router. In
this case the packet must be discarded. An error report may be
transmitted, in accordance with the IP or ISO 8473 specification
(respectively). The reason for discard specified in the error report
should specify "destination host unreachable" (for IP), or
"destination unreachable" (for OSI).
Similarly, due to errors, in some cases an IP-only router may have to
forward an IP packet to an OSI-only router. Again, the packet must be
discarded, as specified above. This may only occur if IP-only and
OSI-only routers occur in the same area, which is a configuration
error.
5 Structure and Encoding of PDUs
This clause describes the additional packet fields for use of the ISO
IS-IS Intra-Domain Routing protocol in pure IP and dual environments.
Specifically, the same packet types are used as in IS-IS [1], and all
fixed fields remain the same. Additional variable length fields are
defined in this section.
5.1 Overview of IS-IS PDUs
The packets used in IS-IS routing protocol fall into three main
classes: (i) Hello Packets; (ii) Link State Packets (LSPs); and (iii)
Sequence Number Packets (SNPs).
Hello packets are used to initialize and maintain adjacencies between
neighboring routers. There are three types of IS-IS Hello packets:
(i) "Level 1 LAN IS to IS Hello PDUs" are used by level 1 routers on
broadcast LANs. (ii) "Level 2 LAN IS to IS Hello PDUs" are used by
level 2 routers on broadcast LANs. (iii) "Point-to-Point IS to IS
Hello PDUs" are used on non-broadcast media, such as point-to-point
links, or general topology subnetworks.
On point-to-point links, the exchange of ISO 9542 ISHs (intermediate
system Hellos) is used to initialize the link, and to allow each
router to know if there is a router on the other end of the link,
before IS-IS Hellos are exchanged. All routers implementing IS-IS
(whether IP-only, OSI-only, or dual), if they have any interfaces on
point-to-point links, must therefore be able to transmit ISO 9542
ISHs on their point-to-point links.
Link State Packets (LSPs) are used to exchange link state
information. There are two types of LSPs: (i) "Level 1 Link State
PDUs" are transmitted by level 1 routers. (ii) "Level 2 Link State
PDUs" are transmitted by level 2 routers. Note that level 2 routers
will, in most cases, also be level 1 routers, and will therefore
transmit both sorts of LSPs.
Sequence number PDUs are used to ensure that neighboring routers have
the same notion of what is the most recent LSP from each other
router. The sequence number PDUs therefore serve a similar function
to acknowledgement packets, but allow more efficient operation. There
are four types of sequence number packets: (i) "Level 1 Complete
Sequence Numbers PDU"; (ii) "Level 2 Complete Sequence Numbers PDU";
(iii) "Level 1 Partial Sequence Numbers PDU"; and (iv) "Level 2
Partial Sequence Numbers PDU". A partial sequence number packet lists
the most recent sequence number of one or more LSPs, and operates
much like an acknowlegement. A partial sequence number packet differs
from an conventional acknowledgement in the sense that it may
acknowlege multiple LSPs at once, and in the sense that it may act as
a request for information. A complete sequence number packet contains
the most recent sequence number of all LSPs in the database. A
complete sequence number packet may therefore be used to ensure
synchronization of the database between adjacent routers either
periodically, or when a link first comes up.
5.2 Overview of IP-Specific Information for IS-IS
There are six new fields defined for the Integrated IS-IS: (i)
"Protocols Supported"; (ii) "IP Interface Address"; (iii)
"Authentication Information"; (iv) "IP Internal Reachability
Information"; (v) "IP External Reachability Information"; and (vi)
"Inter-Domain Routing Protocol Information".
The "Protocols Supported" field identifies the protocols which are
supported by each router. This field must be included in all IS-IS
Hello packets and all LSPs with LSP number 0 transmitted by IP-
capable routers. If this field is not included in an IS-IS Hello
packet or an LSP with LSP number 0, it may be assumed that the packet
was transmitted by an OSI-only router. The "Protocols Supported"
field must also be included in ISO 9542 ISHs send by IP-capable
routers over point-to-point links to other IS-IS routers.
The "IP Interface Address" is included in all IS-IS Hello packets and
LSPs transmitted by IP-only and dual routers. In the Hello packets,
this field occurs once only, and contains the IP address(es) of the
interface on which the Hello packet is transmitted (up to a maximum
of 63 IP addresses on each interface). If an IS-IS Hello is
transmitted over an interface which does not have an IP address
assigned, then this field may be omitted, or may be included with
zero entries. In Link State Packets, this field contains a list of
one or more IP addresses corresponding to one or more interfaces of
the router which originates the LSP. Each IP-capable router must
include this field in its LSPs. This field may occur multiple times
in an LSP, and may occur in an LSP with any LSP number.
The "Authentication Information" field is optional in all IS-IS PDUs.
If used, it contains information used to authenticate the packet. All
IS-IS packets (including 9542 IS Hellos) may be authenticated by use
of this field.
The "IP Internal Reachability Information" field may be present in
all LSPs transmitted by IP-capable routers. If present, it identifies
a list of zero or more [IP address, subnet mask, metrics] reachable
by the router which originates the LSP. Each entry must contain a
default metric, and may contain delay, expense, and error metrics. If
an IP-capable router does not directly reach any IP addresses, then
it may omit this field, or may include the field with zero [IP
address, subnet mask, metrics] entries. If included in level 1 LSPs,
this field includes only entries directly reachable by the router
which originates the LSP, via one of its interfaces. If included in
level 2 LSPs, this field includes only entries reachable by the
router which originates the LSP, either via one of its interfaces, or
indirectly via level 1 routing. This field may occur multiple times
in an LSP, and may occur in an LSP with any LSP number.
The "IP External Reachability Information" field may be present in
level 2 LSPs transmitted by level 2 IP-capable routers. If present,
it identifies a list of zero or more [IP address, subnet mask,
metrics] entries reachable by the router which originates the level 2
LSP. Each entry must contain a default metric, and may contain delay,
expense, and error metrics. Each entry may contain metrics of type
"internal", or of type "external". If a level 2 router does not have
any external routes (via neighboring routers in other routing
domains), when it may omit this field, or may include the field with
zero entries. This field includes only entries reachable by the
router which originates the LSP, via a direct link to an external
router. This field may occur multiple times in a level 2 LSP, and may
occur in an LSP with any LSP number.
The "Inter-Domain Routing Protocol Information" field may be present
in level 2 LSPs transmitted by level 2 IP-capable routers. This field
is transmitted for the convenience of the external routing protocol,
and is not used by the IS-IS. For example, this may be used to allow
border routers to find each other. This field may occur multiple
times in a level 2 LSP, and may occur in an LSP with any LSP number.
The DP 10589 version of the OSI IS-IS does not currently allow
addition of TLV-encoded variable length fields to Sequence Number
Packets. However, this is being corrected in future versions of
10589. In addition, this is expected to be the only correction to
future versions of 10589 that is not backward-compatible with the DP
version. The Integrated IS-IS therefore makes use of a corrected
version of DP 10589, such that the encoding of SNPs has been fixed.
The correct encoding of sequence number packets (as is expected to
appear in future versions of ISO 10589) is given in Annex B of this
specification.
All IP-specific information is encoded in IS-IS packets as variable
length fields. All variable length fields in IS-IS are encoded as
follows:
No. of Octets
+---------------------------+
| CODE | 1
+---------------------------+
| LENGTH | 1
+---------------------------+
| VALUE | LENGTH
+---------------------------+
Figure 3 - Encoding of Variable Length Fields
Any codes in a received PDU that are not recognised shall be ignored
and, for those packets which are forwarded (specifically Link State
Packets), passed on unchanged.
In general, an IS-IS PDU may contain multiple variable length fields,
some of which contain OSI-specific information (specified in [1]) and
some of which contain IP-specific information (specified below).
Except where explicitly stated otherwise, these variable length
fields may occur in any order.
5.3 Encoding of IP-Specific Fields in IS-IS PDUs
This section specifies the detailed encoding of all IP-specific
fields in IS-IS PDUs. Where a particular field may be present in more
than one type of PDU, the field is repeated for each type of PDU to
which it applies.
Bit and octet numbering is the same as in [1]. In particular, octets
in a PDU are numbered starting from 1, in increasing order. Bits in
an octet are numbered from 1 to 8, where bit 1 is the least
significant bit and is pictured on the right. When consecutive octets
are used to represent a number, the lower octet number has the most
significant value.
5.3.1 Level 1 LAN IS to IS Hello PDU
- Additional codes for IP support are:
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying
x CODE - 129
x LENGTH - total length of the value field (one octet per
protocol supported).
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for
each supported data protocol.
No. of Octets
+---------------------------+
| NLPID | 1
+---------------------------+
: :
: :
|---------------------------|
| NLPID | 1
+---------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
7 IP Interface Address -- the IP address(es) of the interface
corresponding to the SNPA over which this PDU is to be transmitted.
x CODE - 132
x LENGTH - total length of the value field (four octets per address).
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.
7 Authentication Information -- Information used to authenticate the
PDU
x CODE - 133
x LENGTH - total length of the value field.
x VALUE - TBD.
5.3.2 Level 2 LAN IS to IS Hello PDU
- Additional codes for IP support are:
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying
x CODE - 129
x LENGTH - total length of the value field (one octet per protocol
supported).
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each
supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
7 IP Interface Address -- The IP address(es) of the interface
corresponding to the SNPA over which this PDU is to be transmitted.
x CODE - 132
x LENGTH - total length of the value field (four octets per address).
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
5.3.3 Point-to-Point IS to IS Hello PDU
- Additional codes for IP support are:
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying
x CODE - 129
x LENGTH - total length of the value field (one octet per protocol
supported).
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each
supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
7 IP Interface Address -- The IP address(es) of the interface
corresponding to the SNPA over which this PDU is to be transmitted.
x CODE - 132
x LENGTH - total length of the value field (four octets per address).
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
5.3.4 Level 1 Link State PDU
- Additional codes for IP support are:
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying.
This must appear once in LSP number 0.
x CODE - 129
x LENGTH - total length of the value field (one octet per protocol
supported).
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each
supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
7 IP Interface Addresses -- The IP addresss of one or more interfaces
corresponding to the SNPAs enabled on this Intermediate system
(i.e., one or more IP addresses of this router).
This is permitted to appear multiple times, and in an LSP with
any LSP number.
x CODE - 132
x LENGTH - total length of the value field (four octets per address).
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
7 IP Internal Reachability Information -- IP addresses within the
routing domain reachable directly via one or more interfaces on
this Intermediate system.
This is permitted to appear multiple times, and in an LSP with any
LSP number. However, this field must not appear in pseudonode LSPs.
x CODE - 128.
x LENGTH - a multiple of 12.
x VALUE -
No. of Octets
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
DEFAULT METRIC is the value of the default metric for the link
to the listed neighbor. Bit 8 of this field is reserved, and
must be set to zero on tranmission and ignored on reception.
Bit 7 of this field (marked I/E) indicates the metric type
(internal or external) for all four TOS metrics, and must be
set to zero indicating internal metrics.
DELAY METRIC is the value of the delay metric for the link to the
listed neighbor. If this IS does not support this metric it shall
set the bit "S" to 1 to indicate that the metric is unsupported.
Bit 7 of this field is reserved, and must be set to zero on
transmission and ignored on reception.
EXPENSE METRIC is the value of the expense metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set to
zero on transmission and ignored on reception.
ERROR METRIC is the value of the error metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set
to zero on transmission and ignored on reception.
IP ADDRESS is a 4-octet Internet address
SUBNET MASK is a 4 octet IP subnet mask.
5.3.5 Level 2 Link State PDU
- Additional codes for IP support are:
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying.
This must appear once in LSP number 0.
x CODE - 129
x LENGTH - total length of the value field (one octet per
protocol supported).
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for
each supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
7 IP Interface Addresses -- The IP addresss of one or more interfaces
corresponding to the SNPAs enabled on this Intermediate system
(i.e., one or more IP addresses of this router).
This is permitted to appear multiple times, and in an LSP with
any LSP number. Where a router is both a level 1 and level 2 router,
it must include the same IP addresses in its level 1 and level 2 LSPs.
x CODE - 132
x LENGTH - total length of the value field (four octets per address).
x VALUE-
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address
7 Authentication Information -- Information used to authenticate
the PDU
x CODE - 133
x LENGTH - total length of the value field
x VALUE - TBD
7 IP Internal Reachability Information -- IP addresses within the
routing domain reachable directly via one or more interfaces on
this Intermediate system.
This is permitted to appear multiple times, and in an LSP with
any LSP number. However, this field must not appear in pseudonode
LSPs.
x CODE - 128.
x LENGTH - a multiple of 12.
x VALUE -
No. of Octets
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
DEFAULT METRIC is the value of the default metric for the link
to the listed neighbor. Bit 8 of this field is reserved, and must
be set to zero on transmission and ignored on reception. Bit 7
of this field indicates the metric type (internal or external)
for all four TOS metrics, and must be set to zero indicating
internal metrics.
DELAY METRIC is the value of the delay metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set
to zero on transmission and ignored on reception.
EXPENSE METRIC is the value of the expense metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set
to zero on transmission and ignored on reception.