ing field, if present. It consists of sub-fields Area Address,
ID, and SEL.
NOTE - The SEL field in the destination address is not ex
amined by Intermediate Systems. It is used by End Systems
to select the proper Transport entity to which to deliver NS
DUs.
This system's (the one examining this PDU for proper for
warding decision) address consists of sub-fields area ad
dress and ID.
a)If the local system type is a level 1 Intermediate sys
tem, or the local system type is a level 2 Intermediate
system and AttachedFlagk = False, then:
1)If the Area Address in the PDU to be forwarded
matches any one of the area addresses of this IS,
then consult the level 1 forwarding database to de
termine the adjacency which is the next hop on the
path to the NPDU's destination. Forward the
NPDU on this adjacency.
2)Otherwise, consult the level 1 forwarding database
to determine the adjacency which is the next hop
on the path to the nearest level 2 is in the area, and
forward the NPDU on this adjacency.
b)If the local system type is Level 2, and Attached
Flagk = True then:
1)If the Area Address in the PDU to be forwarded
matches any one of the area addresses of this IS,
then consult the level 1 forwarding database to de
termine the adjacency which is the next hop on the
path to the NPDU's destination. Forward the
NPDU on this adjacency.
2)Otherwise, consult the level 2 forwarding database
to determine the adjacency which is the next hop
on the path to the destination area, and forward the
NPDU on this adjacency.
7.4.3.2 Encapsulation for Partition Repair
If this Intermediate system is the Partition Designated
Level 2 IS for this partition, and the PDU is being for
warded onto the special adjacency to a Partition Designated
Level 2 Intermediate system in a different partition of this
area, encapsulate the complete PDU as the data field of a
data NPDU (i.e., with an additional layer of header), mak
ing this system the Source address and the other Partition
Designated Level 2 Intermediate system (obtained from the
identifier attribute of the Virtual Adjacency managed ob
ject) the Destination Address field in the outer PDU
header. Set the QoS Maintenance field of the outer PDU
to indicate forwarding via the default routeing metric (see
table 1). Then forward the encapsulated PDU onto an adja
cency ADJ, obtained by calling the Forward procedure, de
scribed below.
7.4.3.3 The Procedure Forward
This procedure chooses, from a Level 1 forwarding data
base if level is level1, or from a Level 2 forwarding da
tabase if level is level2, an adjacency on which to for
ward NPDUs for destination dest. A pointer to the adja
cency is returned in adj, and the procedure returns the value
True. A destination of 0 at level 1 selects the adjacency
for the nearest level 2 IS computed as described in 7.2.9.1.
If there are multiple possible adjacencies, as a result of mul
tiple minimum cost paths, then one of those adjacencies
shall be chosen. An implementation may chose the adja
cency at random, or may use the possible adjacencies in
round robin fashion.
If there is no entry in the selected forwarding database for
the address dest, and the NPDU originated from the a local
Transport entity and the system has one or more Intermedi
ate System adjacencies, then one of those is chosen at ran
dom (or in round robin fashion) and the procedure returns
the value True. Otherwise the procedure returns the value
False.66This is done so that a system in the overloaded state will
still be able to originate or forward NPDUs. If a system with a partial
routeing information base
were prohibited from attempting to forward to an unknown destination,
system management would be unable to either communicate with this system, or
route through it, for the purpose of diagnosing and/or correcting the
underlying fault.
NOTE - Since the local adjacency database is pre-loaded
into the decision process, there will always be an entry in
the forwarding database for destinations to which an adja
cency exists.
NOTE - The PDU to be forwarded may require fragmenta
tion, depending on which circuit it is to be forwarded over.
Generating Redirect PDUs
In addition to forwarding an NPDU, the IS shall inform the
local ISO 9542 protocol machine to generate a Redirect
PDU if the PDU is being forwarded onto the same circuit
from which it came, and if the source SNPA address of the
NPDU indicates that the NPDU was received from an End
System.
7.4.4 The Receive Process
The Receive Process is passed information from any of the
following sources.
-received PDUs with the NLPID of Intra-Domain
routeing,
-configuration information from the ISO 9542 protocol
machine,
-ISO 8473 data PDUs handed to the routeing function
by the ISO 8473 protocol machine.
When an area is partitioned, a level 2 path is used as a
level 1 link to repair the partitioned area. When this occurs,
all PDUs (between the neighbours which must utilise a
multi-hop path for communication) shall be encapsulated in
a data NPDU, addressed to the Intra-Domain routeing se
lector. Control traffic (LSPs, Sequence Numbers PDUs)
shall also be encapsulated, as well as data NPDUs that are
to be passed between the neighbours.
NOTE - It is not necessary to transmit encapsulated IIH
PDUs over a virtual link, since virtual adjacencies are estab
lished and monitored by the operation of the Decision Proc
ess and not the Subnetwork Dependent functions
The Receive Process shall perform the following functions:
-If it is a data NPDU, addressed to this system with
SEL = Intra-Domain routeing, then
7decapsulate the NPDU (remove the outer NPDU
header).
7If the decapsulated PDU is a data NPDU, move
the congestion indications to the decapsulated
NPDU, and pass it to the ISO 8473 protocol ma
chine.
7Otherwise, if the decapsulated PDU is not an ISO
8473 PDU, perform the following steps on the de
capsulated PDU:
-If it is a Link State PDU, pass it to the Update Process
-If it is a Sequence Numbers PDU, pass it to the Up
date Process
-If it is an IIH PDU, pass it to the appropriate
Subnetwork Dependent Function
-If it is a data NPDU or Error Report for another desti
nation, pass it to the Forwarding Process
-Otherwise, ignore the PDU
7.5 Routeing Parameters
The routeing parameters setable by System Management
are listed for each managed object in clause 11.
7.5.1 Architectural Constants
The architectural constants are described in Table 2.
Table 2 - Routeing architectural constantsName
Value
Description
MaxLinkMetric
63.
Maximum value of a routeing metric assign
able to a circuit
MaxPathMetric
1023.
Maximum total metric value for a complete
path
AllL1ISs
01-80-C2-00-00-14
The multi-destination address All Level 1 In
termediate Systems
AllL2ISs
01-80-C2-00-00-15
The multi-destination address All Level 2 In
termediate Systems
AllIntermediateSystems
09-00-2B-00-00-05
The multi-destination address All Intermedi
ate Systems used by ISO 9542
ISO-SAP
FE
The SAP for ISO Network Layer on
ISO 8802-3 LANs
IntradomainRoute
ing-
PD
10000011
The Network Layer Protocol Discriminator
assigned by ISO/TR 9577 for this Protocol
IntradomainRouteing
Selector
0.
The NSAP selector for the Intermediate Sys
tem Network entity
SequenceModulus
232
Size of the sequence number space used by
the Update Process
ReceiveLSPBuffer
Size
1492.
The size of LSP which all Intermediate sys
tems must be capable of receiving.
MaxAge
1200.
Number of seconds before LSP considered ex
pired.
ZeroAgeLifetime
60.
Number of seconds that an LSP with zero Re
maining Lifetime shall be retained after
propagating a purge.
AllEndSystems
09-00-2B-00-00-04
The multi-destination address All End Sys
tems used by ISO 9542
Max
i
mum
Area
Addresses
3.
The maximum number of area addresses
which may exist for a single area.
HoldingMultiplier
3.
The number by which to multiply hello
Timer
to obtain Holding Timer for ISH PDUs and
for Point to Point IIH PDUs.
ISISHoldingMultiplier
10.
The number by which to multiply iSISHel
loTimer to obtain Holding Timer for Level 1
and Level 2 LAN IIH PDUs.
Jitter
25.
The percentage of jitter which is applied to the
generation of periodic PDUs.
8 Subnetwork Dependent
Functions
The Subnetwork Dependent Functions mask the charac
teristics of the different kinds of Subnetworks from the
Subnetwork Independent Routeing Functions. The only
two types of circuits the Subnetwork Independent Functions
recognise are broadcast and general topology.
The Subnetwork Dependent Functions include:
-The use of the ISO 8473 Subnetwork Dependent
Convergence Functions (SNDCF) so that this proto
col may transmit and receive PDUs over the same
subnetwork types, using the same techniques, as does
ISO 8473.
-Co-ordination with the operation of the ESIS proto
col (ISO 9542) in order to determine the Network
layer addresses (and on Broadcast subnetworks, the
subnetwork points of attachment) and identities (End
System or Intermediate System) of all adjacent neigh
bours. This information is held in the Adjacency data
base. It is used to construct Link State PDUs.
-The exchange of IIH PDUs. While it is possible for an
Intermediate System to identify that it has an Interme
diate System neighbour by the receipt of an ISO 9542
ISH PDU, there is no provision within ISO 9542 to in
dicate whether the neighbour is a Level 1 or a Level 2
Intermediate System. Specific PDUs (LAN Level 1,
LAN Level 2 and Point to point IIH PDUs) are de
fined to convey this information.
8.1 Multi-destination Circuits on ISs at
a Domain Boundary
Routeing information (e.g. Link State PDUs) is not ex
changed across a routeing domain boundary. All routeing
information relating to a circuit connected to another route
ing domain is therefore entered via the Reachable Address
managed objects. This information is disseminated to the
rest of the routeing domain via Link State PDUs as de
scribed in 7.3.3.2. This has the effect of causing NPDUs
destined for NSAPs which are included in the
addressPrefixes of the Reachable Addresses to be re
layed to that Intermediate System at the domain boundary.
On receipt of such an NPDU the Intermediate system shall
forward it onto the appropriate circuit, based on its own
Link State information. However in the case of multi-
destination subnetworks (such as an ISO 8208 subnetwork
using Dynamic Assignment, a broadcast subnetwork, or a
connectionless subnetwork) it is necessary to ascertain ad
ditional subnetwork dependent addressing information in
order to forward the NPDU to a suitable SNPA. (This may
be the target End system or an Intermediate system within
the other domain.)
In general the SNPA address to which an NPDU is to be
forwarded can be derived from the destination NSAP of the
NPDU. It may be possible to perform some algorithmic ma
nipulation of the NSAP address in order to derive the
SNPA address. However there may be some NSAPs where
this is not possible. In these cases it is necessary to have
pre-configured information relating an address prefix to a
particular SNPA address.
This is achieved by additional information contained in the
Reachable Address managed object. The mappingType
attribute may be specified as Manual, in which case a
particular SNPA address or set of SNPA addresses is speci
fied in the SNPA Address characteristic. Alternatively the
name of an SNPA address extraction algorithm may be
specified.
8.2 Point to Point Subnetworks
This clause describes the identification of neighbours on
both point to point links and Static circuits.
The IS shall operate the ISO 9542 protocol, shall be able to
receive ISO 9542 ISH PDUs from other ISs, and shall store
the information so obtained in the adjacency database.
8.2.1 Receipt of ESH PDUs Database of End
Systems
An IS shall enter an End system into the adjacency database
when an ESH PDU is received on a circuit. If an ESH PDU
is received on the same circuit, but with a different NSAP
address, the new address shall be added to the adjacency,
with a separate timer. A single ESH PDU may contain more
than one NSAP address. When a new data link address or
NSAP address is added to the adjacency database, the IS
shall generate an adjacencyStateChange (Up) notifica
tion on that adjacency.
The IS shall set a timer for the value of Holding Time in
the received ESH PDU. If another ESH PDU is not re
ceived from the ES before that timer expires, the ES shall
be purged from the database, provided that the Subnetwork
Independent Functions associated with initialising the adja
cency have been completed. Otherwise the IS shall clear the
adjacency as soon as those functions are completed.
When the adjacency is cleared, the Subnetwork Independ
ent Functions shall be informed of an adjacencyState
Change (Down) notification, and the adjacency can be re-
used after the Subnetwork Independent Functions associ
ated with bringing down the adjacency have been com
pleted.
8.2.2 Receiving ISH PDUs by an Intermediate
System
On receipt of an ISH PDU by an Intermediate System, the
IS shall create an adjacency (with state Initialising and
neighbourSystemType Unknown), if one does not al
ready exist, and then perform the following actions:.
a)If the Adjacency state is Up and the ID portion of
the NET field in the ISH PDU does not match the
neighbourID of the adjacency then the IS shall:
1)generate an adjacencyStateChange (Down) no
tification;
2)delete the adjacency; and
3)create a new adjacency with:
i)state set to Initialising, and
ii)neighbourSystemType set to Unknown.
4)perform the following actions..
b)If the Adjacency state is Initialising, and the
neighbourSystemType status is Intermediate Sys
tem, the ISH PDU shall be ignored.
c)If the Adjacency state is Initialising and the neigh
bourSystemType status is not Intermediate Sys
tem, a point to point IIH PDU shall be transmitted as
described in 8.2.3.
d)The neighbourSystemType status shall be set to In
termediate System indicating that the neighbour is an
Intermediate system, but the type (L1 or L2) is, as yet,
unknown.
8.2.3 Sending Point to Point IIH PDUs
An IS shall send Point-to-Point IIH PDUs on those Point-
to-Point circuits whose externalDomain attribute is set
False. The IIH shall be constructed and transmitted as
follows:
a)The Circuit Type field shall be set according to Ta
ble 3.
b)The Local Circuit ID field shall be set to a value as
signed by this Intermediate system when the circuit is
created. This value shall be unique among all the cir
cuits of this Intermediate system.
c)The first Point to Point IIH PDU (i.e. that transmitted
as a result of receiving an ISH PDU, rather than as a
result of timer expiration) shall be padded (with trail
ing PAD options containing arbitrary valued octets) so
that the SNSDU containing the IIH PDU has a length
of at least maxsize - 1 octets77The minimum length of PAD which may be
added is 2 octets, since that is the size of the option header. Where
possible the PDU should be padded to
maxsize, but if the PDU length is maxsize- 1 octets no padding is
possible (or required).
where maxsize is the
maximum of
1)dataLinkBlocksize
2)originating
L1
LSP
Buf
fer
Size
3)originatingL2LSPBufferSize
This is done to ensure that an adjacency will only be
formed between systems which are capable of ex
changing PDUs of length up to maxsize octets. In the
absence of this check, it would be possible for an adja
cency to exist with a lower maximum block size, with
the result that some LSPs and SNPs (i.e. those longer
than this maximum, but less than maxsize) would not
be exchanged.
NOTE - It is necessary for the manager to ensure that the
value of dataLinkBlocksize on a circuit which will be
used to form an Intermediate system to Intermediate sys
tem adjacency is set to a value greater than or equal to the
maximum of the LSPBufferSize characteristics listed
above. If this is not done, the adjacency will fail to initial
ise. It is not possible to enforce this requirement, since it
is not known until initialisation time whether or not the
neighbour on the circuit will be an End system or an In
termediate system. An End system adjacency may oper
ate with a lower value for dataLinkBlocksize.
d)If the value of the circuitTransmitPassword for the
circuit is non-null, then the IS shall include the
Authentication Information field in the transmitted
IIH PDU, indicating an Authentication Type of
Password and containing the circuitTransmit
Password as the authentication value.
8.2.4 Receiving Point to Point IIH PDUs
8.2.4.1 PDU Acceptance Tests
On receipt of a Point-to-Point IIH PDU, perform the fol
lowing PDU acceptance tests:
a)If the IIH PDU was received over a circuit whose ex
ternalDomain attribute is set True, the IS shall dis
card the PDU.
b)If the ID Length field of the PDU is not equal to the
value of the IS's routeingDomainIDLength, the
PDU shall be discarded and an iDFieldLengthMis
match notification generated.
c)If the set of circuitReceivePasswords for this cir
cuit is non-null, then perform the following tests:
1)If the PDU does not contain the Authentication
Information field then the PDU shall be discarded
and an authenticationFailure notification gener
ated.
2)If the PDU contains the Authentication Infor
mation field, but the Authentication Type is not
equal to Password, then the PDU shall be ac
cepted unless the IS implements the authentica
tiion procedure indicated by the Authentication
Type. In this case whether the IS accepts or ig
nores the PDU is outside the scope of this Interna
tional Standard.
3)Otherwise, the IS shall compare the password in
the received PDU with the passwords in the set of
circuitReceivePasswords for the circuit on
which the PDU was received. If the value in the
PDU matches any of these passwords, the IS shall
accept the PDU for further processing. If the value
in the PDU does not match any of the circuitRe
ceivePasswords, then the IS shall ignore the
PDU and generate an authenticationFailure no
tification.
8.2.4.2 IIH PDU Processing
When a Point to Point IIH PDU is received by an Interme
diate system, the area addresses of the two Intermediate
Systems shall be compared to ascertain the validity of the
adjacency. If the two Intermediate systems have an area ad
dress in common, the adjacency is valid for all combina
tions of Intermediate system types (except where a Level 1
Intermediate system is connected to a Level 2 Intermediate
system with manualL2OnlyMode set True). However,
if they have no area address in common, the adjacency is
only valid if both Intermediate systems are Level 2, and the
IS shall mark the adjacency as Level 2 Only. This is de
scribed in more detail below.
On receipt of a Point to Point IIH PDU, each of the area ad
dresses from the PDU shall be compared with the set of
area addresses in the manual
Area
Addresses attribute.
a)If a match is detected between any pair the following
actions are taken.
1)If the local system is of iSType L1
Inter
mediate
Sys
tem the IS shall perform the action indicated
by Table 4.
2)If the local system is of iSType L2
Intermediate
System and the Circuit manualL2OnlyMode
has the value False, the IS shall perform the ac
tion indicated by Table 5.
3)If the local system is of iSType L2
Intermediate
System and the Circuit manualL2OnlyMode
has the value True, the IS shall perform the ac
tion indicated by Table 6.
b)If a no match is detected between any pair, the follow
ing actions shall be performed.
1)If the local system is of iSType L1
Inter
mediate
Sys
tem and the adjacency is not in state Up,
the IS shall delete the adjacency (if any) and gen
erate an initialisationFailure (Area Mismatch)
notification.
2)If the local system is of iSType L1
Inter
mediate
Sys
tem and the adjacency is in state Up, the IS
shall delete the adjacency and generate an adja
cencyStateChange (Down Area Mismatch)
notification .
3)If the local system is of iSType L2
Intermediate
System the IS shall perform the action indicated
by Table 7 (irrespective of the value of manu
alL2OnlyMode for this circuit).
c)If the action taken is Up, as detailed in the tables
referenced above, the IS shall compare the Source ID
field of the PDU with the local systemID.
1)If the local Intermediate system has the higher
Source ID, the IS shall set the Circuit CircuitID
status to the concatenation of the local systemID
and the Local Circuit ID (as sent in the Local Cir
cuit ID field of point to point IIH PDUs from this
Intermediate System) of this circuit.
2)If the remote Intermediate system has the higher
Source ID, the IS shall set the Circuit CircuitID
status to the concatenation of the remote system's
Source ID (from the Source ID field of the PDU),
and the remote system's Local Circuit ID (from the
Local Circuit ID field of the PDU).
3)If the two source IDs are the same (i.e. the system
is initialising to itself), the local systemID is used.
NOTE The circuitID status is not used to generate
the Local Circuit ID to be sent in the Local Circuit
ID field of IIH PDUs transmitted by this Intermedi
ate system. The Local Circuit ID value is assigned
once, when the circuit is created and is not subse
quently changed.
d)If the action taken is Accept and the new value com
puted for the circuitID is different from that in the ex
isting adjacency, the IS shall
1)generate an adjacencyStateChange(Down) noti
fication, and
2)delete the adjacency.
e)If the action taken is Up or Accept the IS shall
1)copy the Adjacency neighbourAreas entries
from the PDU,
2)set the holdingTimer to the value of the Holding
Time from the PDU, and
3)set the neighbourSystemID to the value of the
Source ID from the PDU.
8.2.5 Monitoring Point-to-point Adjacencies
The IS shall keep a holding time (adjacency holding
Timer) for the point-to-point adjacency. The value of the
holding
Timer shall be set to the Holding Time as reported
in the Holding Timer field of the Pt-Pt IIH PDU. If a neigh
bour is not heard from in that time, the IS shall
a)purge it from the database; and
b)generate an adjacencyStateChange (Down) notifi
cation.
8.3 ISO 8208 Subnetworks
8.3.1 Network Layer Protocols
The way in which the underlying service assumed by ISO
8473 is provided for ISO 8208 subnetworks is described in
clause 8 of ISO 8473. This defines a set of Subnetwork De
pendent Convergence Functions (SNDCFs) that relate the
service provided by specific individual ISO-standard
subnetworks to the abstract underlying service defined in
clause 5.5 of ISO 8473. In particular 8.4.3 describes the
Subnetwork Dependent Convergence Functions used with
ISO 8208 Subnetworks.
8.3.2 SVC Establishment
8.3.2.1 Use of ISO 8473 Subnetwork Dependent
Convergence Functions
SVCs shall be established according to the procedures de
fined in the ISO 8208 Subnetwork Dependent Convergence
Functions of ISO 8473 (this may be on system management
action or on arrival of data depending on the type of cir
cuit). The Call Request shall contain a Protocol Discrimina
tor specifying ISO 8473 in the first octet of Call Userdata.
In the case of a static circuit, an SVC shall be established
only upon system management action. The IS shall use
neighbourSNPAAddress as the called SNPA address.
In the case of a DA circuit, the call establishment proce
dures are initiated by the arrival of traffic for the circuit.
8.3.2.2 Dynamically Assigned Circuits
A dynamically assigned circuit has multiple adjacencies,
and can therefore establish SVCs to multiple SNPAs. In
general the SNPA address to which a call is to be estab
lished can be derived from the NSAP to which an NPDU is
to be forwarded. In the case where all the NSAPs accessible
over the ISO 8208 subnetwork have IDIs which are their
SNPA addresses, the correct SNPA can be ascertained by
extracting the IDI. However there may be some NSAPs,
which it is required to reach over the ISO 8208 subnetwork,
whose IDI does not correspond to the SNPA address of
their point of attachment to the ISO 8208 subnetwork. The
IDI may refer to some other SNPA address which is sub-
optimally connected to the target NSAP (or not even con
nected at all), or the IDP may not contain an X.121 address
at all (e.g. ISO DCC scheme). In these cases the IS shall
have pre-configured information relating an IDP (or address
prefix) to a particular SNPA address to call.
This is achieved, as described in 8.1, by additional informa
tion contained in the Reachable Address managed object.
The address extraction algorithm may be specified to ex
tract the IDI portion where the IDI is the required X.121 ad
dress. An example of a set of Reachable Addresses is
shown in Table 8.
Table 8 - Example of address prefixesAddress Prefix
39
37 aaaaa
37
*
37 D
SNPA Address
123X
B
Y
Extract X.121 SNPA address
R, S, T
This is interpreted as follows:
a)For the ISO DCC prefix 39 123, call the SNPA ad
dress X.
b)For the X.121 IDI address prefix 37 aaaaa, don't
call aaaaa, but call B instead.
c)For all IDPs based on SNPAs with DNIC D (i.e. with
address prefix 37 D), call the address Y (which
would probably be a gateway to a subnetwork with
DNIC D).
d)For any other X.121 IDI (i.e. address prefix 37) call
the SNPA whose address is used as the IDI.
e)Anything else (* in table 8) call one of the SNPA
addresses R, S or T. These would typically be the
SNPA addresses of Level 2 Intermediate Systems
through which any other addresses could potentially
be reached.
NOTE - If a DA circuit is defined with a reachable address
prefix which includes the addresses reachable over a DCM
or STATIC circuit, the cost(s) for the DA circuit must be
greater than those of the STATIC circuit. If this is not the
case, the DA circuit may be used to establish a call to the re
mote SNPA supporting the STATIC circuit, which would
then (wrongly) assume it was the STATIC circuit.
8.3.2.3 Initiating Calls (Level 2 Intermediate
Systems)
When an NPDU is to be forwarded on a dynamically as
signed circuit, for destination NSAP address D, the IS shall:
a)Calculate D's subnetwork address, either as explicitly
stated in the circuit database, or as extracted from the
IDP.
1)If this system is an ES and there is an entry in the
RedirectCache or ReversePathCache for D, use the
subnetwork address in the cache entry.
2)If this system is an ES or Level 2 Intermediate sys
tem, and the address matches one of the listed
reachable address prefixes (including *, if pre
sent), the subnetwork address is that specified ac
cording to the mappingType attribute (either
Manual, indicating that the set of addresses in
the sNPAAddresses attribute of that Reachable
Address are to be used, or Algorithm, indicating
that it is to be extracted from the IDP using the
specified algorithm). If multiple SNPA addresses
are specified, and there is already an adjacency up
to one of those SNPA addresses, then choose that
subnetwork address, otherwise choose the
subnetwork address with the oldest timestamp as
described in 8.3.2.4.
3)If the address does not match one of the listed
reachable address prefixes (and there is no * en
try), invoke the ISO 8473 Discard PDU function.
b)Scan the adjacencies for one already open to D's
subnetwork address (i.e. reserveTimer has not yet
expired). If one is found, transmit the NPDU on that
adjacency.
c)If no adjacency has a call established to the required
subnetwork address, but there is a free adjacency, at
tempt to establish the call using that subnetwork ad
dress.
d)If there is no free adjacency invoke the ISO 8473 Dis
card PDU function.
NOTE Where possible, when an adjacency is reserved
(when an SVC has been cleared as a result of the
idleTimer expiring, but the reserveTimer has not yet ex
pired), resources within the subnetwork service provider
should be reserved, in order to minimise the probability
that the adjacency will not be able to initiate a call when
required.
8.3.2.4 Call Attempt Failures
The Reachable Address managed objects may contain a set
of SNPA addresses, each of which has an associated time-
stamp. The time-stamps shall be initialised to infinitely
old.
Some of the SNPAs in this set may be unreachable. If a call
attempt fails to one of the SNPA addresses listed, the IS
shall mark that entry in the list with the time of the latest
failed attempt. When an SNPA address is to be chosen from
the list, the IS shall choose the one with the oldest time-
stamp , unless the oldest time-stamp is more recent than
recallTimer. If the oldest time-stamp is more recent than
recallTimer, all SNPAs in the set shall be assumed tempo
rarily unreachable and no call attempt is made. The IS shall
instead invoke the ISO 8473 Discard PDU function.
When attempting to establish a connection to a single spe
cific subnetwork address (not through one of a set of SNPA
addresses), if a call attempt to a particular SNPA address,
A, fails for any reason, the IS shall invoke the ISO 8473
Discard PDU function. Additionally the adjacency on
which the call attempt was placed shall be placed in
Failed state, and the recall timer set. Until it expires, the
IS shall not attempt call establishment for future NPDUs to
be forwarded over subnetwork address A, but instead the IS
shall invoke the ISO 8473 Discard PDU function.
When the recall timer expires, the IS shall free the adja
cency for calls to a different destination or retry attempts to
subnetwork address A.
NOTE - If an implementation can store the knowledge of
SNPA addresses that have failed along with the time since
the attempt was made in a location other than the adjacency
on which the call was attempted, then that adjacency can be
used for other calls.
8.3.3 Reverse Path Forwarding on DA Circuits
Where a subdomain is attached to a Connection-oriented
subnetwork by two or more SNPAs, the IDP for the ad
dresses within the subdomain may be chosen to be con
structed from the address of one of the points of attachment.
(It need not be. The whole subdomain could be multi-
homed by using both SNPA addresses, or some other IDP
could be chosen; e.g. ISO DCC.) Traffic to the subdomain
from some other SNPA will cause a call to be established to
the SNPA corresponding to the IDP of the addresses in the
subdomain. Traffic from the subdomain may use either of
the SNPAs depending on the routeing decisions made by
the subdomain. This is illustrated in the diagram below (fig
ure 5).
Figure 5 - B.xB.yC.zISO 8208 SubnetworkBACExample for reverse path
forwarding
The subdomain is attached to the connection-oriented
subnetwork via SNPAs A and B. The addresses on the
subdomain are constructed using the SNPA address of B as
the IDI. If traffic for C.z is sent from B.x, a call will be es
tablished from A to C. The reverse traffic from C.z to B.x
will cause another call to be established from C to B. Thus
two SVCs have been established where only one is re
quired.
This problem is prevented by the local system retaining a
cache (known as the ReversePathCache) of NSAP ad
dresses from which traffic has been received over each ad
jacency. When it has traffic to forward over the connection-
oriented subnetwork, the IS shall it first check to see if the
destination NSAP is in the cache of any of its adjacencies,
and if so forwards the traffic over that adjacency. An NSAP
shall only be added to the cache when the remote SNPA ad
dress of the adjacency over which it is received differs from
the SNPA address to be called which would be generated
by checking against the Circuit Reachable Addresses man
aged objects. If the cache is full, the IS shall overwrite the
least recently used entry. The ReversePathCache, if imple
mented, shall have a size of at least one entry. The IS shall
purge the cache when the adjacency is taken down (i.e.
when the reserve timer expires).
8.3.4 Use of ISO 9542 on ISO 8208
subnetworks
STATIC and DA circuits are equivalent to point to point
links, and as such permit the operation of ISO 9542 as de
scribed for point to point links in 8.2.
For DA circuits, it is impractical to use ISO 9542 to obtain
configuration information, such as the location of Interme
diate systems, since this would require calls to be estab
lished to all possible SNPA addresses.
The IS shall not send ISO 9542 ISH PDUs on a DA circuit.
The IS shall take no action on receipt of an ESH PDU or
ISH PDU, and the circuit shall complete initialisation with
out waiting for their arrival.
The IS shall not send Point to point IIH PDU on DA cir
cuits. The IS shall ignore receipt of a point-point IIH PDU.
(This would only occur if a STATIC or DA circuit became
erroneously connected to an SVC being used for a DA cir
cuit.)
8.3.5 Interactions with the Update Process
A dynamically assigned circuit contains a list of <reachable
address prefix, cost, SNPA address> tuples. Also, each dy
namically assigned circuit has a specified call establishment
cost measured by call
Estab
lish
ment
Met
rick (where k in
dexes the four defined metrics). The call establishment cost
is always an internal metric, and is therefore directly com
parable with the reachable address metric only if the reach
able address metric is also internal.
When the circuit is enabled, the Subnetwork Dependent
functions in an Intermediate system shall report (to the Up
date Process) adjacency cost change events for all ad
dress prefixes in the circuit Reachable Address managed
object, together with the Reachable address metrick + Del
tak increment. If reachable address metrick is internal, then
Deltak = call
Estab
lish
ment
Met
rick. If reachable address
metrick is external, then Deltak = 0.
This causes this information to be included in subsequently
generated LSPs as described in 7.3.3.2.
Routeing PDUs (LSPs and Sequence number PDUs) shall
not be sent on dynamically assigned circuits.
NOTE - In the following sub-clauses, it is assumed that the
Reachable Addresses referenced are only those which have
been enabled (i.e. that have state On), and whose parent
circuit is also in state On.
8.3.5.1 Adjacency Creation
After an SVC to SNPA address D is successfully estab
lished and a new adjacency created for it (whether it was in
itiated by the local or the remote system), if call
Estab
lish
ment
Met
rickIncrement is greater than 0, the IS shall scan
the circuit Reachable Address managed objects for all
addressPrefixes listed with D as (one of) the sNPAAd
dress(es).
For Reachable Addresses with mappingType Algo
rithm, the IS shall construct an implied address prefix88i.e. some
address prefix which matches the addressPrefix of the Reachable
Address, and which would generate the SNPA Address D when the extrac
tion algorithm is applied
from the actual remote SNPA address D and the address ex
traction algorithm. The IS shall generate an Adjacency cost
change event for each such address prefix (both actual and
implied) with the Reachable Address metrick (without the
added call
Estab
lish
ment
Met
rickIncrement). This causes
information that those address prefixes are reachable with
the lower cost to be included in subsequently generated
LSPs. The effect of this is to encourage the use of already
established SVCs where possible.
8.3.5.2 Adjacency Deletion
When the adjacency with sNPAAddress D is freed (Re
serve Timer has expired, or the adjacency is deleted by Sys
tem Management action) then if call
Estab
lish
ment
Met
rickIncrement is greater than 0, the IS shall scan the Cir
cuit Reachable Address managed objects for all those with
mappingType Manual and (one of) their sNPAAd
dresses equal to D. The IS shall generate Adjacency
cost change events to the Update Process for all such ad
dress prefixes with the Reachable Address metrick + Deltak
increment (where Deltak is the same as defined above). For
Reachable Addresses with mappingType X.121 for
which it is possible to construct an implied address prefix
as above, the IS shall generate an adjacencyState
Change notification for that implied prefix.
A cost change event shall only be generated when the count
of the number of subnetwork addresses which have an es
tablished SVC changes between 1 and 0.
8.3.5.3 Circuit Call Establishment Increment
Change
On a dynamically assigned circuit, when system manage
ment changes the Circuit call
Estab
lish
ment
Met
rickIncrement for that circuit, the IS shall generate adja
cency cost change events for all address prefixes affected
by the change (i.e. those for which calls are not currently
established).
The IS shall scan all the Reachable Address managed ob
jects of that Circuit. If the Reachable Address has
mappingType X.121, the IS shall generate an adja
cency cost change event for that name with the Reach
able Address metrick + the new value of Deltak. If (based
on the new value of callEstab
lish
ment
Met
rickIncrement)
the Reachable Address has mappingType Manual, the
IS shall scan all the Adjacencies of the Circuit for an Adja
cency with sNPAAddress equal to (one of) the sN
PAAddresses of that Reachable Address. If no such adja
cency is found the IS shall generate an adjacency cost
change event for that name with the Reachable Address
metrick + the new value of Deltak (based on the new value
of callEstlishmentMetrickIncrement).
8.3.5.4 Reachable Address Cost Change
When the metrick characteristic of a Reachable Address in
state On is changed by system management, the IS shall
generate cost change events to the Update Process to reflect
this change.
If the Reachable Address has mappingType Manual,
the IS shall scan all the Adjacencies of the Circuit for an
Adjacency with sNPAAddress equal to (one of) the sN
PAAddresses of that Reachable Address. If one or more
such adjacencies are found, the IS shall generate an adja
cency cost change event for that name with the new
Reachable Address metrick. If no such adjacency is found
the IS shall generate an adjacency cost change event for
that name with the new Reachable Address metrick.
If the Reachable Address has mappingType X.121, the
IS shall generate an adjacency cost change event for that
name with the new Reachable Address metrick + Deltak
(based on the new value of call
Estab
lish
ment
Met
rick
Increment). In addition, for all Adjacencies of the Circuit
with an sNPAAddress for which an implied address pre
fix can be generated for this Reachable Address, the IS
shall generate an adjacency cost change event for that im
plied address prefix and the new Reachable Address met
rick.
8.3.5.5 Disabling a Reachable Address
When a Reachable Address managed object is disabled via
management action, the IS shall generate an Adjacency
down event to the Update Process for the name of that
Reachable Address and also for any implied prefixes asso
ciated with that Reachable Address.
8.3.5.6 Enabling a Reachable Address
When a Reachable Address is enabled via system manage
ment action, the IS shall generate Adjacency cost change
events as described for Reachable Address cost change in
8.3.5.4 above.
8.4 Broadcast Subnetworks
8.4.1 Broadcast Subnetwork IIH PDUs
All Intermediate systems on broadcast circuits (both
Level 1 and Level 2) shall transmit LAN IIH PDUs as de
scribed in 8.4.3. Level 1 Intermediate systems shall transmit
only Level 1 LAN IIH PDUs. Level 2 Intermediate Systems
on circuits with manualL2OnlyMode set to the value
True, shall transmit only Level 2 LAN IIH PDUs.
Level 2 Intermediate systems on circuits with manu
alL2OnlyMode set to the value False, shall transmit
both.
Level n LAN IIH PDUs contain the transmitting Intermedi
ate system's ID, holding timer, Level n Priority and
manual
Area
Addresses, plus a list containing the lA
NAddresses of all the adjacencies of neighbourSystem
Type Ln Intermediate System (in state Initialising or
Up) on this circuit.
LAN IIH PDUs shall be padded (with trailing PAD options
containing arbitrary valued octets) so that the SNSDU con
taining the IIH PDU has a length of at least maxsize- 1 oc
tets99The minimum length of PAD which may be added is 2 octets, since
that is the size of the option header. Where possible the PDU should be padded to
maxsize, but if the PDU length is maxsize- 1 octets no padding is
possible (or required).
where maxsize for Level 1 IIH PDUs is the maximum
of
-dataLinkBlocksize
-originating
L1
LSP
Buf
fer
Size
and for Level 2 IIH PDUs is the maximum of
-dataLinkBlocksize
-originatingL2LSPBufferSize
This is done to ensure that an adjacency will only be
formed between systems which are capable of exchanging
PDUs of length up to maxsize octets. In the absence of this
check, it would be possible for an adjacency to exist with a
lower maximum block size, with the result that some LSPs
and SNPs (i.e. those longer than this maximum, but less
than maxsize) would not be exchanged.
NOTE - An example of a topology where this could occur is
one where an extended LAN is constructed from LAN seg
ments with different maximum block sizes. If, as a result of
mis-configuration or some dynamic reconfiguration, a path
exists between two Intermediate systems on separate LAN
segments having a large maximum block size, which in
volves transit of a LAN segment with a smaller maximum
block size, loss of larger PDUs will occur if the Intermediate
systems continue to use the larger maximum block size. It is
better to refuse to bring up the adjacency in these circum
stances.
Level 1 Intermediate systems shall transmit Level 1 LAN
IIH PDUs to the multi-destination address AllL1ISs, and
also listen on that address. They shall also listen for ESH
PDUs on the multi-destination address AllIntermediateSys
tems. The list of neighbour Intermediate systems shall con
tain only Level 1 Intermediate Systems within the same
area. (i.e. Adjacencies of neighbourSystemType L1 In
termediate System.)
Level 2 Only Intermediate systems (i.e. Level 2 Intermedi
ate systems which have the Circuit manualL2OnlyMode
characteristic set to the value True) shall transmit Level 2
LAN IIH PDUs to the multi-destination address AllL2ISs,
and also listen on that address. The list of neighbour Inter
mediate systems shall contain only Level 2 Intermediate
systems. (i.e. Adjacencies of neighbourSystemType L2
Intermediate System.)
Level 2 Intermediate systems (with manualL2OnlyMode
False) shall perform both of the above actions. Separate
Level 1 and Level 2 LAN IIH PDUs shall be sent to the
multi-destination addresses AllL1ISs and AllL2ISs de
scribing the neighbour Intermediate systems for Level 1
and Level 2 respectively. Separate adjacencies shall be cre
ated by the receipt of Level 1 and Level 2 LAN IIH PDUs.
8.4.1.1 IIH PDU Acceptance Tests
On receipt of a Broadcast IIH PDU, perform the following
PDU acceptance tests:
a)If the IIH PDU was received over a circuit whose ex
ternalDomain attribute is True, the IS shall discard
the PDU.
b)If the ID Length field of the PDU is not equal to the
value of the IS's routeingDomainIDLength, the
PDU shall be discarded and an iDFieldLengthMis
match notification generated.
c)If the set of circuitReceivePasswords for this cir
cuit is non-null, then perform the following tests:
1)If the PDU does not contain the Authentication
Information field then the PDU shall be discarded
and an authenticationFailure notification gener
ated.
2)If the PDU contains the Authentication Infor
mation field, but the Authentication Type is not
equal to Password, then the PDU shall be ac
cepted unless the IS implements the authentica
tiion procedure indicated by the Authentication
Type. In this case whether the IS accepts or ig
nores the PDU is outside the scope of this Interna
tional Standard.
3)Otherwise, the IS shall compare the password in
the received PDU with the passwords in the set of
circuitReceivePasswords for the circuit on
which the PDU was received. If the value in the
PDU matches any of these passwords, the IS shall
accept the PDU for further processing. If the value
in the PDU does not match any of the circuitRe
ceivePasswords, then the IS shall ignore the
PDU and generate an authenticationFailure no
tification.
8.4.1.2 Receipt of Level 1 IIH PDUs
On receipt of a Level 1 LAN IIH PDU on the multi-
destination address AllL1ISs, the IS shall compare each of
the area addresses, from the received IIH PDU with the set
of area addresses in the manual
Area
Addresses charac
teristic. If a match is not found between any pair (i.e. the lo
cal and remote system have no area address in common),
the IS shall reject the adjacency and generate an initialisa
tionFailure (area mismatch) notification. Otherwise (a
match is found) the IS shall accept the adjacency and set the
Adjacency neighbourSystemType to L1 Intermediate
System.
8.4.1.3 Receipt of Level 2 IIH PDUs
On receipt of a Level 2 LAN IIH PDU on the multi-
destination address AllL2ISs, the IS shall accept the adja
cency, and set the Adjacency neighbourSystemType to
L2 Intermediate System.
8.4.1.4 Existing Adjacencies
When a Level n LAN IIH PDU (Level 1 or Level 2) is re
ceived from an Intermediate system for which there is al
ready an adjacency with
a)the Adjacency lANAddress equal to the MAC Source
address of the PDU, and
b)the Adjacency neighbourSystemID equal to the
Source ID field from the PDU and
c)the neighbourSystemType equal to Ln Intermedi
ate System,
the IS shall update the holding timer, LAN Priority and
neighbourAreas according to the values in the PDU.
8.4.1.5 New Adjacencies
When
a)a Level n LAN IIH PDU (Level 1 or Level 2) is re
ceived (from Intermediate system R), and
b)there is no adjacency for which the Adjacency lANAd
dress is equal to the MAC Source address of the
PDU; and
c)the Adjacency neighbourSystemID is equal to the
Source ID field from the PDU, and
d)neighbourSystemType is Ln Intermediate System,
the IS shall create a new adjacency. However, if there is in
sufficient space in the adjacency database, to permit the
creation of a new adjacency the IS shall instead perform the
actions described in 8.4.2.
The IS shall
a)set neighbourSystemType status to Ln Intermedi
ate System (where n is the level of the IIH PDU),
b)set the holding timer, LAN Priority, neighbourID
and neighbourAreas according to the values in the
PDU., and
c)set the lANAddress according to the MAC source ad
dress of the PDU.
The IS shall set the state of the adjacency to initialising,
until it is known that the communication between this sys
tem and the source of the PDU (R) is two-way. However R
shall be included in future Level n LAN IIH PDUs trans
mitted by this system.
When R reports this circuit's lANAddress in its Level n
LAN IIH PDUs, the IS shall
a)set the adjacency's state to Up, and
b)generate an adjacencyStateChange (Up) notifica
tion.
The IS shall keep a separate Holding Time (Adjacency
holding
Timer) for each Ln Intermediate System adja
cency. The value of holding
Timer shall be set to the Hold
ing Time as reported in the Holding Timer field of the
Level n LAN IIH PDUs. If a neighbour is not heard from in
that time, the IS shall
a)purge it from the database; and
b)generate an adjacencyStateChange (Down) notifi
cation.
If a Level n LAN IIH PDU is received from neighbour N,
and this system's lANAddress is no longer in N's IIH
PDU, the IS shall
a)set the adjacency's state to initialising, and