metrics are used to describe links/routes to destinations in
ternal to the routeing domain. External metrics are used to
describe links/routes to destinations outside of the routeing
domain. These two types of metrics are not directly compa
rable, except the internal routes are always preferred over
external routes. In other words an internal route will always
be selected even if an external route with lower total cost
exists.
7.2.3 Broadcast Subnetworks
Instead of treating a broadcast subnetwork as a fully con
nected topology, the broadcast subnetwork is treated as a
pseudonode, with links to each attached system. Attached
systems shall only report their link to the pseudonode. The
designated Intermediate system, on behalf of the
pseudonode, shall construct Link State PDUs reporting the
links to all the systems on the broadcast subnetwork with a
zero value for each supported routeing metric33They are set to zero
metric values since they have already been assigned metrics by the
link to the pseudonode. Assigning a non-zero value in the
pseudonode LSP would have the effect of doubling the actual value.
.
The pseudonode shall be identified by the sourceID of the
Designated Intermediate system, followed by a non-zero
pseudonodeID assigned by the Designated Intermediate
system. The pseudonodeID is locally unique to the Desig
nated Intermediate system.
Designated Intermediate systems are determined separately
for level 1 and level 2. They are known as the LAN Level 1
Designated IS and the LAN Level 2 Designated IS respec
tively. See 8.4.4.
An Intermediate system may resign as Designated Interme
diate System on a broadcast circuit either because it (or it's
SNPA on the broadcast subnetwork) is being shut down or
because some other Intermediate system of higher priority
has taken over that function. When an Intermediate system
resigns as Designated Intermediate System, it shall initiate a
network wide purge of its pseudonode Link State PDU(s)
by setting their Remaining Lifetime to zero and performing
the actions described in 7.3.16.4. A LAN Level 1 Desig
nated Intermediate System purges Level 1 Link State PDUs
and a LAN Level 2 Designated Intermediate System purges
Level 2 Link State PDUs. An Intermediate system which
has resigned as both Level 1 and Level 2 Designated Inter
mediate System shall purge both sets of LSPs.
When an Intermediate system declares itself as designated
Intermediate system and it is in possession of a Link State
PDU of the same level issued by the previous Designated
Intermediate System for that circuit (if any), it shall initiate
a network wide purge of that (or those) Link State PDU(s)
as above.
7.2.4 Links
Two Intermediate systems are not considered neighbours
unless each reports the other as directly reachable over one
of their SNPAs. On a Connection-oriented subnetwork
(either point-to-point or general topology), the two Interme
diate systems in question shall ascertain their neighbour re
lationship when a connection is established and hello PDUs
exchanged. A malfunctioning IS might, however, report an
other IS to be a neighbour when in fact it is not. To detect
this class of failure the decision process checks that each
link reported as up in a LSP is so reported by both Inter
mediate systems. If an Intermediate system considers a link
down it shall not mention the link in its Link State PDUs.
On broadcast subnetworks, this class of failure shall be de
tected by the designated IS, which has the responsibility to
ascertain the set of Intermediate systems that can all com
municate on the subnetwork. The designated IS shall in
clude these Intermediate systems (and no others) in the
Link State PDU it generates for the pseudonode represent
ing the broadcast subnetwork.
7.2.5 Multiple LSPs for the same system
The Update process is capable of dividing a single logical
LSP into a number of separate PDUs for the purpose of
conserving link bandwidth and processing (see 7.3.4). The
Decision Process, on the other hand, shall regard the LSP
with LSP Number zero in a special way. If the LSP with
LSP Number zero and remaining lifetime > 0, is not present
for a particular system then the Decision Process shall not
process any LSPs with non-zero LSP Number which may
be stored for that system.
The following information shall be taken only from the LSP
with LSP Number zero. Any values which may be present
in other LSPs for that system shall be disregarded by the
Decision Process.
a)The setting of the LSP Database Overload bit.
b)The value of the IS Type field.
c)The Area Addresses option.
7.2.6 Routeing Algorithm Overview
The routeing algorithm used by the Decision Process is a
shortest path first (SPF) algorithm. Instances of the algo
rithm are run independently and concurrently by all Inter
mediate systems in a routeing domain. Intra-Domain route
ing of a PDU occurs on a hop-by-hop basis: that is, the al
gorithm determines only the next hop, not the complete
path, that a data PDU will take to reach its destination. To
guarantee correct and consistent route computation by
every Intermediate system in a routeing domain, this Inter
national Standard depends on the following properties:
a)All Intermediate systems in the routeing domain con
verge to using identical topology information; and
b)Each Intermediate system in the routeing domain gen
erates the same set of routes from the same input to
pology and set of metrics.
The first property is necessary in order to prevent inconsis
tent, potentially looping paths. The second property is nec
essary to meet the goal of determinism stated in 6.6.
A system executes the SPF algorithm to find a set of legal
paths to a destination system in the routeing domain. The
set may consist of:
a)a single path of minimum metric sum: these are
termed minimum cost paths;
b)a set of paths of equal minimum metric sum: these are
termed equal minimum cost paths; or
c)a set of paths which will get a PDU closer to its desti
nation than the local system: these are called down
stream paths.
Paths which do not meet the above conditions are illegal
and shall not be used.
The Decision Process, in determining its paths, also ascer
tains the identity of the adjacency which lies on the first
hop to the destination on each path. These adjacencies are
used to form the Forwarding Database, which the forward
ing process uses for relaying PDUs.
Separate route calculations are made for each pairing of a
level in the routeing hierarchy (i.e. L1 and L2) with a sup
ported routeing metric. Since there are four routeing metrics
and two levels some systems may execute multiple in
stances of the SPF algorithm. For example,
-if an IS is a L2 Intermediate system which supports all
four metrics and computes minimum cost paths for all
metrics, it would execute the SPF calculation eight
times.
-if an IS is a L1 Intermediate system which supports all
four metrics, and additionally computes downstream
paths, it would execute the algorithm 4 W (number of
neighbours + 1) times.
Any implementation of an SPF algorithm meeting both the
static and dynamic conformance requirements of clause 12
of this International Standard may be used. Recommended
implementations are described in detail in Annex C.
7.2.7 Removal of Excess Paths
When there are more than max
i
mum
Path
Splits legal
paths to a destination, this set shall be pruned until only
max
i
mum
Path
Splits remain. The Intermediate system
shall discriminate based upon:
NOTE - The precise precedence among the paths is speci
fied in order to meet the goal of determinism defined in 6.6.
-adjacency type: Paths associated with End system or
level 2 reachable address prefix adjacencies are re
tained in preference to other adjacencies
-metric sum: Paths having a lesser metric sum are re
tained in preference to paths having a greater metric
sum. By metric sum is understood the sum of the
metrics along the path to the destination.
-neighbour ID: where two or more paths are associ
ated with adjacencies of the same type, an adjacency
with a lower neighbour ID is retained in preference to
an adjacency with a higher neighbour id.
-circuit ID: where two or more paths are associated
with adjacencies of the same type, and same neigh
bour ID, an adjacency with a lower circuit ID is re
tained in preference to an adjacency with a higher cir
cuit ID, where circuit ID is the value of:
7ptPtCircuitID for non-broadcast circuits,
7l1CircuitID for broadcast circuits when running
the Level 1 Decision Process, and
7l2CircuitID for broadcast circuits when running
the Level 2 Decision Process.
-lANAddress: where two or more adjacencies are of
the same type, same neighbour ID, and same circuit
ID (e.g. a system with multiple LAN adapters on the
same circuit) an adjacency with a lower lANAddress
is retained in preference to an adjacency with a higher
lANAddress.
7.2.8 Robustness Checks
7.2.8.1 Computing Routes through Overloaded
Intermediate systems
The Decision Process shall not utilise a link to an Interme
diate system neighbour from an IS whose LSPs have the
LSP Database Overload indication set. Such paths may in
troduce loops since the overloaded IS does not have a com
plete routeing information base. The Decision Process shall,
however utilise the link to reach End system neighbours
since these paths are guaranteed to be non-looping.
7.2.8.2 Two-way connectivity check
The Decision Process shall not utilise a link between two
Intermediate Systems unless both ISs report the link.
NOTE - the check is not applicable to links to an End Sys
tem.
Reporting the link indicates that it has a defined value for at
least the default routeing metric. It is permissible for two
endpoints to report different defined values of the same
metric for the same link. In this case, routes may be asym
metric.
7.2.9 Construction of a Forwarding Database
The information that is needed in the forwarding database
for routeing metric k is the set of adjacencies for each sys
tem N.
7.2.9.1 Identification of Nearest Level 2 IS by a
Level 1 IS
Level 1 Intermediate systems need one additional piece of
information per routeing metric: the next hop to the nearest
level 2 Intermediate system according to that routeing met
ric. A level 1 IS shall ascertain the set, R, of attached
level 2 Intermediate system(s) for metric k such that the to
tal cost to R for metric k is minimal.
If there are more adjacencies in this set than max
i
mum
Path
Splits, then the IS shall remove excess adjacencies as
described in 7.2.7.
7.2.9.2 Setting the Attached Flag in Level 2
Intermediate Systems
If a level 2 Intermediate system discovers, after computing
the level 2 routes for metric k, that it cannot reach any other
areas using that metric, it shall:
-set AttachedFlag for metric k to False;
-regenerate its Level 1 LSP with LSP number zero; and
-compute the nearest level 2 Intermediate system for
metric k for insertion in the appropriate forwarding
database, according to the algorithm described in
7.2.9.1 for level 1 Intermediate systems.
NOTE - AttachedFlag for each metric k is examined by the
Update Process, so that it will report the value in the ATT
field of its Link State PDUs.
If a level 2 Intermediate system discovers, after computing
the level 2 routes for metric k, that it can reach at least one
other area using that metric, it shall
-set AttachedFlag for metric k to True;
-regenerate its Level 1 LSP with LSP number zero; and
-set the level 1 forwarding database entry for metric k
which corresponds to nearest level 2 Intermediate
system to Self.
7.2.10 Information for Repairing Partitioned
Areas
An area may become partitioned as a result of failure of one
or more links in the area. However, if each of the partitions
has a connection to the level 2 subdomain, it is possible to
repair the partition via the level 2 subdomain, provided that
the level 2 subdomain itself is not partitioned. This is illus
trated in Figure 4.
All the systems A I, R and P are in the same area n.
When the link between D and E is broken, the area be
comes partitioned. Within each of the partitions the Parti
tion Designated Level 2 Intermediate system is selected
from among the level 2 Intermediate systems in that parti
tion. In the case of partition 1 this is P, and in the case of
partition 2 this is R. The level 1 repair path is then estab
lished between between these two level 2 Intermediate sys
tems. Note that the repaired link is now between P and R,
not between D and E.
The Partition Designated Level 2 Intermediate Systems re
pair the partition by forwarding NPDUs destined for other
partitions of the area through the level 2 subdomain. They
do this by acting in their capacity as Level 1 Intermediate
Systems and advertising in their Level 1 LSPs adjacencies
to each Partition Designated Level 2 Intermediate System
in the area. This adjacency is known as a Virtual Adja
cency or Virtual Link. Thus other Level 1 Intermediate
Systems in a partition calculate paths to the other partitions
through the Partition Designated Level 2 Intermediate Sys
tem. A Partition Designated Level 2 Intermediate System
forwards the Level 1 NPDUs through the level 2 subdomain
by encapsulating them in 8473 Data NPDUs with its Virtual
Network Entity Title as the source NSAP and the adja
cent Partition Designated Level 2 Intermediate System's
Virtual Network Entity Title as the destination NSAP. The
following sub-clauses describe this in more detail.
7.2.10.1 Partition Detection and Virtual Level 1
Link Creation
Partitions of a Level 1 area are detected by the Level 2 In
termediate System(s) operating within the area. In order to
participate in the partition repair process, these Level 2 In
termediate systems must also act as Level 1 Intermediate
systems in the area. A partition of a given area exists when
ever two or more Level 2 ISs located in that area are re
ported in the L2 LSPs as being a Partition Designated
Level 2 IS. Conversely, when only one Level 2 IS in an
area is reported as being the Partition Designated Level 2
IS, then that area is not partitioned. Partition repair is ac
complished by the Partition Designated Level 2 IS. The
election of the Partition Designated Level 2 IS as described
in the next subsection must be done before the detection
and repair process can begin.
In order to repair a partition of a Level 1 area, the Partition
designated Level 2 IS creates a Virtual Network Entity to
represent the partition. The Network Entity Title for this
virtual network entity shall be constructed from the first
listed area address from its Level 2 Link State PDU, and the
ID of the Partition Designated Level 2 IS. The IS shall also
construct a virtual link (represented by a new Virtual Adja
cency managed object) to each Partition Designated Level 2
IS in the area, with the NET of the partition recorded in the
Identifier attribute. The virtual links are the repair paths for
the partition. They are reported by the Partition Designated
Level 2 IS into the entire Level 1 area by adding the ID of
each adjacent Partition Designated Level 2 IS to the In
termediate System Neighbours field of its Level 1 Link
State PDU. The Virtual Flag shall be set True for these
Intermediate System neighbours. The metric value for this
virtual link shall be the default metric value d(N) obtained
from this system's Level 2 PATHS database, where N is the
adjacent Partition Designated Level 2 IS via the Level 2
subdomain.
An Intermediate System which operates as the Partition
Designated Level 2 Intermediate System shall perform the
following steps after completing the Level 2 shortest path
computation in order to detect partitions in the Level 1 area
and create repair paths:
a)Examine Level 2 Link State PDUs of all Level 2 Inter
mediate systems. Search area
Addresses for any ad
dress that matches any of the addresses in partition
Area
Addresses. If a match is found, and the Parti
tion Designated Level 2 Intermediate system's ID
does not equal this system's ID, then inform the level
1 update process at this system of the identity of the
Partition Designated Level 2 Intermediate system, to
gether with the path cost for the default routeing met
ric to that Intermediate system.
b)Continue examining Level 2 LSPs until all Partition
Designated Level 2 Intermediate systems in other par
titions of this area are found, and inform the Level 1
Update Process of all of the other Partition Designated
Level 2 Intermediate systems in other partitions of this
area, so that
1)Level 1 Link State PDUs can be propagated to all
other Partition designated level 2 Intermediate sys
tems for this area (via the level 2 subdomain).
2)All the Partition Designated Level 2 Intermediate
systems for other partitions of this area can be re
ported as adjacencies in this system's Level 1 Link
State PDUs.
If a partition has healed, the IS shall destroy the associated
virtual network entity and virtual link by deleting the Vir
tual Adjacency. The Partition Designated Level 2 IS de
tects a healed partition when another Partition Designated
Level 2 IS listed as a virtual link in its Level 1 Link State
PDU was not found after running the partition detection and
virtual link creation algorithm described above.
If such a Virtual Adjacency is created or destroyed, the IS
shall generate a partitionVirtualLinkChange notification.
7.2.10.2 Election of Partition Designated Level 2
Intermediate System
The Partition Designated Level 2 IS is a Level 2 IS which:
-reports itself as attached by the default metric in its
LSPs;
-reports itself as implementing the partition repair op
tion;
-operates as a Level 1 IS in the area;
-is reachable via Level 1 routeing without traversing
any virtual links; and
-has the lowest ID
The election of the Partition Designated Level 2 IS is per
formed by running the decision process algorithm after the
Level 1 decision process has finished, and before the
Level 2 decision process to determine Level 2 paths is exe
cuted.
In order to guarantee that the correct Partition Designated
Level 2 IS is elected, the decision process is run using only
the Level 1 LSPs for the area, and by examining only the
Intermediate System Neighbours whose Virtual Flag is
FALSE. The results of this decision process is a set of all
the Level 1 Intermediate Systems in the area that can be
reached via Level 1, non-virtual link routeing. From this
set, the Partition Designated Level 2 IS is selected by
choosing the IS for which
-IS Type (as reported in the Level 1 LSP) is Level 2
Intermediate System;
-ATT indicates attached by the default metric;
-P indicates support for the partition repair option; and
-ID is the lowest among the subset of attached Level 2
Intermediate Systems.
7.2.10.3 Computation of Partition area addresses
A Level 2 Intermediate System shall compute the set of
partition
Area
Addresses, which is the union of all
manual
area
Addresses as reported in the Level 1 Link
State PDUs of all Level 2 Intermediate systems reachable in
the partition by the traversal of non-virtual links. If more
than max
i
mum
Area
Addresses are present, the Interme
diate system shall retain only those areas with numerically
lowest area address (as described in 7.1.5). If one of the lo
cal system's manual
Area
Addresses is so rejected the
notification manualAddressDroppedFromArea shall be
generated.
7.2.10.4 Encapsulation of NPDUs Across the
Virtual Link
All NPDUs sent over virtual links shall be encapsulated as
ISO 8473 Data NPDUs. The encapsulating Data NPDU
shall contain the Virtual Network Entity Title of the Parti
tion Designated Level 2 IS that is forwarding the NPDU
over the virtual link in the Source Address field, and the
Virtual NET of the adjacent Partition Designated Level 2
IS in the Destination Address field. The SEL field in
both NSAPs shall contain the IS-IS routeing selector
value. The QoS Maintenance field of the outer PDU shall
be set to indicate forwarding via the default routeing metric
(see table 1 on page 32).
For Data and Error Report NPDUs the Segmentation
Permitted and Error Report flags and the Lifetime field
of the outer NPDU shall be copied from the inner NPDU.
When the inner NPDU is decapsulated, its Lifetime field
shall be set to the value of the Lifetime field in the outer
NPDU.
For LSPs and SNPs the Segmentation Permitted flag
shall be set to True and the Error Report flag shall be set
to False. The Lifetime field shall be set to 255. When an
inner LSP is decapsulated, its remaining lifetime shall be
decremented by half the difference between 255 and the
value of the Lifetime field in the outer NPDU.
Data NPDUs shall not be fragmented before encapsulation,
unless the total length of the Data NPDU (including header)
exceeds 65535 octets. In that case, the original Data NPDU
shall first be fragmented, then encapsulated. In all cases,
the encapsulated Data NPDU may need to be fragmented
by ISO 8473 before transmission in which case it must be
reassembled and decapsulated by the destination Partition
Designated Level 2 IS. The encapsulation is further de
scribed as part of the forwarding process in 7.4.3.2. The
decapsulation is described as part of the Receive process in
7.4.4.
7.2.11 Computation of area addresses
A Level 1 or Level 2 Intermediate System shall compute
the values of area
Addresses (the set of area addresses
for this Level 1 area), by forming the union of the sets of
manual
area
Addresses reported in the Area Addresses
field of all Level 1 LSPs with LSP number zero in the local
Intermediate system's link state database.
NOTE - This includes all source systems, whether currently
reachable or not. It also includes the local Intermediate sys
tem's own Level 1 LSP with LSP number zero.
NOTE - There is no requirement for this set to be updated
immediately on each change to the database contents. It is
permitted to defer the computation until the next running of
the Decision Process.
If more than max
i
mum
Area
Addresses are present, the
Intermediate system shall retain only those areas with nu
merically lowest area address (as described in 7.1.5). If one
of the local system's manual
area
Addresses is rejected
the notification manual
Address
Dropped
From
Area shall
be generated.
7.2.12 Order of Preference of Routes
If an Intermediate system takes part in level 1 routeing, and
determines (by looking at the area address) that a given des
tination is reachable within its area, then that destination
will be reached exclusively by use of level 1 routeing. In
particular:
a)Level 1 routeing is always based on internal metrics.
b)Amongst routes in the area, routes on which the re
quested QoS (if any) is supported are always preferred
to routes on which the requested QoS is not supported.
c)Amongst routes in the area of the same QoS, the short
est routes are preferred. For determination of the
shortest path, if a route with specific QoS support is
available, then the specified QoS metric is used, other
wise the default metric is used.
d)Amongst routes of equal cost, load splitting may be
performed.
If an Intermediate system takes part in level 1 routeing,
does not take part in level 2 routeing, and determines (by
looking at the area address) that a given destination is not
reachable within its area, and at least one attached level 2
IS is reachable in the area, then that destination will be
reached by routeing to a level 2 Intermediate system as fol
lows:
a)Level 1 routeing is always based on internal metrics.
b)Amongst routes in the area to attached level 2 ISs,
routes on which the requested QoS (if any) is sup
ported are always preferred to routes on which the re
quested QoS is not supported.
c)Amongst routes in the area of the same QoS to at
tached level 2 ISs, the shortest route is preferred. For
determination of the shortest path, if a route on which
the specified QoS is available, then the specified QoS
metric is used, otherwise the default metric is used.
d)Amongst routes of equal cost, load splitting may be
performed.
If an Intermediate system takes part in level 2 routeing and
is attached, and the IS determines (by looking at the area
address) that a given destination is not reachable within its
area, then that destination will be reached as follows:
a)Routes on which the requested QoS (if any) is sup
ported are always preferred to routes on which the re
quested QoS is not supported.
b)Amongst routes of the same QoS, routes are priori
tised as follows:
1)Highest precedence: routes matching the area ad
dress of any area in the routeing domain
2)Medium precedence: Routes matching a reachable
address prefix with an internal metric. For destina
tions matching multiple reachable address prefix
entries all with internal metrics, the longest prefix
shall be preferred.
3)Lowest precedence: Routes matching a reachable
address prefix with an external metric. For destina
tions matching multiple reachable address prefix
entries all with external metrics, the longest prefix
shall be preferred.
c)For routes with equal precedence as specified above,
the shortest path shall be preferred. For determination
of the shortest path, a route supporting the specified
QoS is used if available; otherwise a route using the
default metric shall be used. Amongst routes of equal
cost, load splitting may be performed.
7.3 The Update Process
The Update Process is responsible for generating and
propagating Link State information reliably throughout the
routeing domain.
The Link State information is used by the Decision Process
to calculate routes.
7.3.1 Input and Output
INPUT
-Adjacency Database maintained by the Subnetwork
Dependent Functions
-Reachable Address managed objects - maintained by
System Management
-Notification of Adjacency Database Change notifi
cation by the Subnetwork Dependent Functions that
an adjacency has come up, gone down, or changed
cost. (Circuit up, Circuit down, Adjacency Up, Adja
cency Down, and Cost change events)
-AttachedFlag (level 2 Intermediate systems only),
a flag computed by the Level 2 Decision Process indi
cating whether this system can reach (via level 2
routeing) other areas
-Link State PDUs The Receive Process passes Link
State PDUs to the Update Process, along with an indi
cation of which adjacency it was received on.
-Sequence Numbers PDUs The Receive Process
passes Sequence Numbers PDUs to the Update Proc
ess, along with an indication of which adjacency it
was received on.
-Other Partitions The Level 2 Decision Process
makes available (to the Level 1 Update Process on a
Level 2 Intermediate system) a list of aPartition Desig
nated Level 2 Intermediate system, Level 2 default
metric valueq pairs, for other partitions of this area.
OUTPUT
-Link State Database
-Signal to the Decision Process of an event, which is
either the receipt of a Link State PDU with different
information from the stored one, or the purging of a
Link State PDU from the database. The reception of a
Link State PDU which has a different sequence num
ber or Remaining Lifetime from one already stored in
the database, but has an identical variable length por
tion, shall not cause such an event.
NOTE - An implementation may compare the checksum of
the stored Link State PDU, modified according to the
change in sequence number, with the checksum of the re
ceived Link State PDU. If they differ, it may assume that the
variable length portions are different and an event signalled
to the Decision Process. However, if the checksums are the
same, an octet for octet comparison must be made in order
to determine whether or not to signal the event.
7.3.2 Generation of Local Link State
Information
The Update Process is responsible for constructing a set of
Link State PDUs. The purpose of these Link State PDUs is
to inform all the other Intermediate systems (in the area, in
the case of Level 1, or in the Level 2 subdomain, in the case
of Level 2), of the state of the links between the Intermedi
ate system that generated the PDUs and its neighbours.
The Update Process in an Intermediate system shall gener
ate one or more new Link State PDUs under the following
circumstances:
a)upon timer expiration;
b)when notified by the Subnetwork Dependent Func
tions of an Adjacency Database Change;
c)when a change to some Network Management charac
teristic would cause the information in the LSP to
change (for example, a change in manual
area
Addresses).
7.3.3 Use of Manual Routeing Information
Manual routeing information is routeing information en
tered by system management. It may be specified in two
forms.
a)Manual Adjacencies
b)Reachable Addresses
These are described in the following sub-clauses.
7.3.3.1 Manual Adjacencies
An End system adjacency may be created by System Man
agement. Such an adjacency is termed a manual End sys
tem adjacency. In order to create a manual End system ad
jacency, system managements shall specify:
a)the (set of) system IDs reachable over that adjacency;
and
b)the corresponding SNPA Address.
These adjacencies shall appear as adjacencies with type
Manual, neighbourSystemType End system and
state Up. Such adjacencies provide input to the Update
Process in a similar way to adjacencies created through the
operation of ISO 9542. When the state changes to Up the
adjacency information is included in the Intermediate Sys
tem's own Level 1 LSPs.
NOTE - Manual End system adjacencies shall not be in
cluded in a Level 1 LSPs issued on behalf of a pseudonode,
since that would presuppose that all Intermediate systems on
a broadcast subnetwork had the same set of manual adjacen
cies as defined for this circuit.
Metrics assigned to Manual adjacencies must be Internal
metrics.
7.3.3.2 Reachable Addresses
A Level 2 Intermediate system may have a number of
Reachable Address managed objects created by System
management. When a Reachable Address is in state On
and its parent Circuit is also in state On, the name and
each of its defined routeing metrics shall be included in
Level 2 LSPs generated by this system.
Metrics assigned to Reachable Address managed objects
may be either Internal or External.
A reachable address is considered to be active when all
the following conditions are true:
a)The parent circuit is in state On;
b)the Reachable Address is in state On; and
c)the parent circuit is of type broadcast or is in data link
state Running.
Whenever a reachable address changes from being inac
tive to active a signal shall be generated to the Update
process to cause it to include the Address Prefix of the
reachable address in the Level 2 LSPs generated by that
system as described in 7.3.9.
Whenever a reachable address changes from being active
to inactive, a signal shall be generated to the Update
process to cause it to cease including the Address Prefix of
the reachable address in the Level 2 LSPs.
7.3.4 Multiple LSPs
Because a Link State PDU is limited in size to Receive
LSP
Buffer
Size, it may not be possible to include infor
mation about all of a system's neighbours in a single LSP.
In such cases, a system may use multiple LSPs to convey
this information. Each LSP in the set carries the same
sourceID field (see clause 9), but sets its own LSP Num
ber field individually. Each of the several LSPs is handled
independently by the Update Process, thus allowing distri
bution of topology updates to be pipelined. However, the
Decision Process recognises that they all pertain to a com
mon originating system because they all use the same
sourceID.
NOTE - Even if the amount of information is small enough
to fit in a single LSP, a system may optionally choose to use
several LSPs to convey it; use of a single LSP in this situ
ation is not mandatory.
NOTE - In order to minimise the transmission of redundant
information, it is advisable for an IS to group Reachable
Address Prefix information by the circuit with which it is as
sociated. Doing so will ensure that the minimum number of
LSP fragments need be transmitted if a circuit to another
routeing domain changes state.
The maximum sized Level 1 or Level 2 LSP which may be
generated by a system is controlled by the values of the
management parameters originating
L1
LSP
Buf
fer
Size or
ori
ginat
ing
L2
LSP
Buffer
Size respectively.
NOTE - These parameters should be set consistently by sys
tem management. If this is not done, some adjacencies will
fail to initialise.
The IS shall treat the LSP with LSP Number zero in a spe
cial way, as follows:
a)The following fields are meaningful to the decision
process only when they are present in the LSP with
LSP Number zero:
1)The setting of the LSP Database Overload bit.
2)The value of the IS Type field.
3)The Area Addresses option. (This is only present
in the LSP with LSP Number zero, see below).
b)When the values of any of the above items are
changed, an Intermediate System shall re-issue the
LSP with LSP Number zero, to inform other Interme
diate Systems of the change. Other LSPs need not be
reissued.
Once a particular adjacency has been assigned to a particu
lar LSP Number, it is desirable that it not be moved to an
other LSP Number. This is because moving an adjacency
from one LSP to another can cause temporary loss of
connectivity to that system. This can occur if the new ver
sion of the LSP which originally contained information
about the adjacency (which now does not contain that infor
mation) is propagated before the new version of the other
LSP (which now contains the information about the adja
cency). In order to minimise the impact of this, the follow
ing restrictions are placed on the assignment of information
to LSPs.
a)The Area Addresses option field shall occur only in
the LSP with LSP Number zero.
b)Intermediate System Neighbours options shall occur
after the Area Addresses option and before any End
System (or in the case of Level 2, Prefix) Neigh
bours options.
c)End System (or Prefix) Neighbour options (if any)
shall occur after any Area Address or Intermediate
System Neighbour options.
NOTE In this context, after means at a higher octet
number from the start of the same LSP or in an LSP with
a higher LSP Number.
NOTE An implementation is recommended to ensure
that the number of LSPs generated for a particular system
is within approximately 10% of the optimal number
which would be required if all LSPs were densely packed
with neighbour options. Where possible this should be
accomplished by re-using space in LSPs with a lower
LSP Number for new adjacencies. If it is necessary to
move an adjacency from one LSP to another, the
SRMflags (see 7.3.15) for the two new LSPs shall be
set as an atomic action.44If the two SRMflags are not set atomically, a
race condition will exist in which one of the two LSPs may be
propagated quickly, while the other waits for
an entire propagation cycle. If this occurs, adjacencies will be
falsely eliminated from the topology and routes may become unstable for
period of time
potentially as large as maximumLSPGeneratonInterval.
When some event requires changing the LSP information
for a system, the system shall reissue that (or those) LSPs
which would have different contents. It is not required to
reissue the unchanged LSPs. Thus a single End system ad
jacency change only requires the reissuing of the LSP con
taining the End System Neighbours option referring to
that adjacency. The parameters max
imum
LSP
Gen
er
a
tion
Int
er
val and minimumLSPGenerationInterval shall
apply to each LSP individually.
7.3.5 Periodic LSP Generation
The Update Process shall periodically re-generate and
propagate on every circuit with an IS adjacency of the ap
propriate level (by setting SRMflag on each circuit), all the
LSPs (Level 1 and/or Level 2) for the local system and any
pseudonodes for which it is responsible. The Intermediate
system shall re-generate each LSP at intervals of at most
max
i
mum
LSP
Gen
era
tion
Interval seconds, with jitter
applied as described in 10.1.
These LSPs may all be generated on expiration of a single
timer or alternatively separate timers may be kept for each
LSP Number and the individual LSP generated on expira
tion of this timer.
7.3.6 Event Driven LSP Generation
In addition to the periodic generation of LSPs, an Interme
diate system shall generate an LSP when an event occurs
which would cause the information content to change. The
following events may cause such a change.
-an Adjacency or Circuit Up/Down event
- a change in Circuit metric
-a change in Reachable Address metric
-a change in manual
Area
Addresses
-a change in systemID
-a change in Designated Intermediate System status
-a change in the waiting status
When such an event occurs the IS shall re-generate changed
LSP(s) with a new sequence number. If the event necessi
tated the generation of an LSP which had not previously
been generated (for example, an adjacency Up event for
an adjacency which could not be accommodated in an exist
ing LSP), the sequence number shall be set to one. The IS
shall then propagate the LSP(s) on every circuit by setting
SRMflag for each circuit. The timer maximum
LSP
Gen
er
ation
Interval shall not be reset.
There is a hold-down timer (min
i
mum
LSP
Generation
Interval) on the generation of each individual LSP.
7.3.7 Generation of Level 1 LSPs
(non-pseudonode)
The Level 1 Link State PDU not generated on behalf of a
pseudonode contains the following information in its vari
able length fields.
-In the Area Addresses option the set of manual
Area
Addresses for this Intermediate System.
-In the Intermediate System Neighbours option
the set of Intermediate system IDs of neighbouring In
termediate systems formed from:
7The set of neighbourSystemIDs with an ap
pended zero octet (indicating non-pseudonode)
from adjacencies in the state Up, on circuits of
type Point-Point, In or Out, with
xneighbourSystemType L1 Intermediate
System
xneighbourSystemType L2 Intermediate
System and adjacencyUsage Level 2 or
Level1 and 2.
The metrics shall be set to the values of Level 1
metrick of the circuit for each supported routeing
metric.
7The set of l1CircuitIDs for all circuits of type
Broadcast (i.e. the neighbouring pseudonode
IDs) .
The metrics shall be set to the values of Level 1
metrick of the circuit for each supported routeing
metric.
7The set of IDs with an appended zero octet derived
from the Network Entity Titles of all Virtual Adja
cencies of this IS. (Note that the Virtual Flag is set
when encoding these entries in the LSP see
7.2.10.)
The default metric shall be set to the total cost to
the virtual NET for the default routeing metric.
The remaining metrics shall be set to the value in
dicating unsupported.
-In the End System Neighbours option the set of
IDs of neighbouring End systems formed from:
7The systemID of the Intermediate System itself,
with a value of zero for all supported metrics.
7The set of endSystemIDs from all adjacencies
with type Auto-configured, in state Up, on
circuits of type Point-to-Point, In or Out,
with neighbourSystemType End system.
The metrics shall be set to the values of Level 1
metrick of the circuit for each supported routeing
metric.
7The set of endSystemIDs from all adjacencies
with type Manual in state Up, on all circuits.
The metrics shall be set to the values of Level 1
metrick of the circuit for each supported routeing
metric.
-In the Authentication Information field if the
system's areaTransmitPassword is non-null, in
clude the Authentication Information field contain
ing an Authentication Type of Password, and the
value of the areaTransmitPassword.
7.3.8 Generation of Level 1 Pseudonode LSPs
An IS shall generate a Level 1 pseudonode Link State PDU
for each circuit for which this Intermediate System is the
Level 1 LAN Designated Intermediate System. The LSP
shall specify the following information in its variable length
fields. In all cases a value of zero shall be used for all sup
ported routeing metrics
-The Area Addresses option is not present.
Note - This information is not required since the set of
area addresses for the node issuing the pseudonode
LSP will already have been made available via its own
non-pseudonode LSP.
-In the Intermediate System Neighbours option
the set of Intermediate System IDs of neighbouring In
termediate Systems on the circuit for which this
pseudonode LSP is being generated formed from:
7The Designated Intermediate System's own sys
temID with an appended zero octet (indicating
non-pseudonode).
7The set of neighbourSystemIDs with an ap
pended zero octet (indicating non-pseudonode)
from adjacencies on this circuit in the state Up,
with
xneighbourSystemType L1 Intermediate
System
xL2 Intermediate System and adjacency
Usage Level 1.
-In the End System Neighbours option the set of
IDs of neighbouring End systems formed from:
7The set of endSystemIDs from all adjacencies
with type Auto-configured, in state Up, on
the circuit for which this pseudonode is being gen
erated, with neighbourSystemType End sys
tem.
-In the Authentication Information field if the
system's areaTransmitPassword is non-null, in
clude the Authentication Information field contain
ing an Authentication Type of Password, and the
value of the areaTransmitPassword.
7.3.9 Generation of Level 2 LSPs
(non-pseudonode)
The Level 2 Link State PDU not generated on behalf of a
pseudonode contains the following information in its vari
able length fields:
-In the Area Addresses option the set of area
Addresses for this Intermediate system computed as
described in 7.2.11.
-In the Partition Designated Level 2 IS option the
ID of the Partition Designated Level 2 Intermediate
System for the partition.
-In the Intermediate System Neighbours option
the set of Intermediate system IDs of neighbouring In
termediate systems formed from:
7The set of neighbourSystemIDs with an ap
pended zero octet (indicating non-pseudonode)
from adjacencies in the state Up, on circuits of
type Point-to-Point, In or Out, with neigh
bourSystemType L2 Intermediate System.
7The set of l2CircuitIDs for all circuits of type
Broadcast. (i.e. the neighbouring pseudonode
IDs)
The metric and metric type shall be set to the val
ues of Level 2 metrick of the circuit for each sup
ported routeing metric.
-In the Prefix Neighbours option the set of vari
able length prefixes formed from:
7The set of names of all Reachable Address man
aged objects in state On, on all circuits in state
On.
The metrics shall be set to the values of Level 2
metrick for the reachable address.
-In the Authentication Information field if the
system's domainTransmitPassword is non-null,
include the Authentication Information field con
taining an Authentication Type of Password, and
the value of the domainTransmitPassword.
7.3.10 Generation of Level 2 Pseudonode LSPs
A Level 2 pseudonode Link State PDU is generated for
each circuit for which this Intermediate System is the
Level 2 LAN Designated Intermediate System and contains
the following information in its variable length fields. In all
cases a value of zero shall be used for all supported route
ing metrics.
-The Area Addresses option is not present.
Note - This information is not required since the set of
area addresses for the node issuing the pseudonode
LSP will already have been made available via its own
non-pseudonode LSP.
-In the Intermediate System Neighbours option
the set of Intermediate System IDs of neighbouring In
termediate Systems on the circuit for which this
pseudonode LSP is being generated formed from:
7The Designated Intermediate System's own sys
temID with an appended zero octet (indicating
non-pseudonode).
7The set of neighbourSystemIDs with an ap
pended zero octet (indicating non-pseudonode)
from adjacencies on this circuit in the state Up
with neighbourSystemType L2 Intermediate
System.
-The Prefix Neighbours option is not present.
-In the Authentication Information field if the
system's domainTransmitPassword is non-null,
include the Authentication Information field con
taining an Authentication Type of Password, and
the value of the domainTransmitPassword.
7.3.11 Generation of the Checksum
This International Standard makes use of the checksum
function defined in ISO 8473.
The source IS shall compute the LSP Checksum when the
LSP is generated. The checksum shall never be modified by
any other system. The checksum allows the detection of
memory corruptions and thus prevents both the use of in
correct routeing information and its further propagation by
the Update Process.
The checksum shall be computed over all fields in the LSP
which appear after the Remaining Lifetime field. This
field (and those appearing before it) are excluded so that the
LSP may be aged by systems without requiring re-
computation.
As an additional precaution against hardware failure, when
the source computes the Checksum, it shall start with the
two checksum variables (C0 and C1) initialised to what
they would be after computing for the systemID portion
(i.e. the first 6 octets) of its Source ID. (This value is com
puted and stored when the Network entity is enabled and
whenever systemID changes.) The IS shall then resume
Checksum computation on the contents of the PDU after
the first ID Length octets of the Source ID field.
NOTE - All Checksum calculations on the LSP are per
formed treating the Source ID field as the first octet. This
procedure prevents the source from accidentally sending out
Link State PDUs with some other system's ID as source.
7.3.12 Initiating Transmission
The IS shall store the generated Link State PDU in the Link
State Database, overwriting any previous Link State PDU
with the same LSP Number generated by this system. The
IS shall then set all SRMflags for that Link State PDU, in
dicating it is to be propagated on all circuits with Intermedi
ate System adjacencies.
An Intermediate system shall ensure (by reserving re
sources, or otherwise) that it will always be able to store
and internalise its own non-pseudonode zeroth LSP. In the
event that it is not capable of storing and internalising one
of its own LSPs it shall enter the overloaded state as de
scribed in 7.3.19.1.
NOTE - It is recommended that an Intermediate system en
sure (by reserving resources, or otherwise) that it will al
ways be able to store and internalise all its own (zero and
non-zero, pseudonode and non-pseudonode) LSPs.
7.3.13 Preservation of order
When an existing Link State PDU is re-transmitted (with
the same or a different sequence number), but with the
same information content (i.e. the variable length part) as a
result of there having been no changes in the local topology
databases, the order of the information in the variable
length part shall be the same as that in the previously trans
mitted LSP.
NOTE - If a sequence of changes result in the state of the
database returning to some previous value, there is no re
quirement to preserve the ordering. It is only required when
there have been no changes whatever. This allows the re
ceiver to detect that there has been no change in the infor
mation content by performing an octet for octet comparison
of the variable length part, and hence not re-run the decision
process.
7.3.14 Propagation of LSPs
The update process is responsible for propagating Link