lanL1DesignatedIntermediateSystemChange
NOTIFICATION
BEHAVIOUR
lanL1DesignatedIntermediateSystemChange-B
BEHAVIOUR
DEFINED AS The LAN L1 Designated Intermediate
System Change Notification is generated when the
local system either elects itself or resigns as being
the LAN L1 Designated Intermediate System on this
circuit. The relative order of these events must be
preserved. The occurance of this event is counted by
the lanL1DesignatedIntermediateSystemChanges
counter.;;
MODE NON-CONFIRMED;
PARAMETERS
notificationDesignatedIntermediateSystemChange;
WITH INFORMATION SYNTAX
ISO10589-ISIS.NotificationInfo;
REGISTERED AS {ISO10589-ISIS.noi
lanL1DesignatedIntermediateSystemChange (14)};
exceededMaximumSVCAdjacencies NOTIFICATION
BEHAVIOUR exceededMaximumSVCAdjacencies-B
BEHAVIOUR
DEFINED AS The Exceeded Maximum SVC Adjacen
cies Notification is generated when there is no free
adjacency on which to establish an SVC for a new
destination.(see clause 8.3.2.3) The occurance of
this event is counted by the
timesExceededMaximumSVCAdjacencies counter.;;
MODE NON-CONFIRMED;
WITH INFORMATION SYNTAX
ISO10589-ISIS.NotificationInfo;
REGISTERED AS {ISO10589-ISIS.noi
exceededMaximumSVCAdjacencies (15)};
exceededMaximumCallAttempts NOTIFICATION
BEHAVIOUR exceededMaximumCallAttempts-B
BEHAVIOUR
DEFINED AS The Exceeded Maximum Call Attempts
Notification is generated when recallCount becomes
equal to maximumCallAttempts. The occurance of
this event is counted by the timesExceededMaxi
mumCallAttempts counter.;;
MODE NON-CONFIRMED;
WITH INFORMATION SYNTAX
ISO10589-ISIS.NotificationInfo;
REGISTERED AS {ISO10589-ISIS.noi
exceededMaximumCallAttempts (16)};
lanL2DesignatedIntermediateSystemChange
NOTIFICATION
BEHAVIOUR
lanL2DesignatedIntermediateSystemChange-B
BEHAVIOUR
DEFINED AS The LAN L2 Designated Intermediate
System Change Notification is generated when the
local system either elects itself or resigns as being
the LAN L2 Designated Intermediate System on this
circuit. The relative order of these events must be
preserved. The occurance of this event is counted by
the lanL2DesignatedIntermediateSystemChanges
counter.;;
MODE NON-CONFIRMED;
PARAMETERS
notificationDesignatedIntermediateSystemChange;
WITH INFORMATION SYNTAX
ISO10589-ISIS.NotificationInfo;
REGISTERED AS {ISO10589-ISIS.noi
lanL2DesignatedIntermediateSystemChange (17)};
authenticationFailure NOTIFICATION
BEHAVIOUR authenticationFailure-B BEHAVIOUR
DEFINED AS Generated when a PDU is received with
an incorrect Authentication information field;;
MODE NON-CONFIRMED;
PARAMETERS
notificationAdjacentSystem;
WITH INFORMATION SYNTAX
ISO10589-ISIS.NotificationInfo;
REGISTERED AS {ISO10589-ISIS.noi
authenticationFailure (18)};
11.2.13 Action Definitions
-- Note: The following actions have been proposed (in
SC21 N4977) for inclusion in DMI. Until such time
as this is completed, the definitions of these actions
are given here.
--
activate ACTION
BEHAVIOUR activate-B BEHAVIOUR
DEFINED AS Sets OperationalState to `enabled' and
commences operation;;
MODE CONFIRMED;
PARAMETERS successResponse, failureResponse,
failureReason;
WITH INFORMATION SYNTAX
ISO10589-ISIS.ActionInfo;
WITH REPLY SYNTAX ISO10589-ISIS.ActionReply;
REGISTERED AS {ISO10589-ISIS.acoi activate (1)};
deactivate ACTION
BEHAVIOUR deactivate-B BEHAVIOUR
DEFINED AS Sets OperationalState to `disabled' and
ceases operation;;
MODE CONFIRMED;
PARAMETERS successResponse, failureResponse,
failureReason;
WITH INFORMATION SYNTAX
ISO10589-ISIS.ActionInfo;
WITH REPLY SYNTAX ISO10589-ISIS.ActionReply;
REGISTERED AS {ISO10589-ISIS.acoi deactivate (2)};
11.2.14 Parameter Definitions
iSO10589-NB-p1 PARAMETER
CONTEXT CREATE-INFO;
WITH SYNTAX ISO10589-ISIS.ISType;
BEHAVIOUR iSO10589-NB-p1-B BEHAVIOUR
DEFINED AS The value to be given to the iStype at
tribute on MO creation. This parameter is manda
tory;;
REGISTERED AS {ISO10589-ISIS.proi
iSO10589-NB-p1 (1)};
iSO10589Circuit-MO-p1 PARAMETER
CONTEXT CREATE-INFO;
WITH SYNTAX ISO10589-ISIS.CircuitType;
BEHAVIOUR iSO10589Circuit-MO-p1-B
BEHAVIOUR
DEFINED AS The value to be given to the type attrib
ute on MO creation. This parameter is mandatory;;
REGISTERED AS {ISO10589-ISIS.proi
iSO10589Circuit-MO-p1 (2)};
reachableAddressP1 PARAMETER
CONTEXT CREATE-INFO;
WITH SYNTAX ISO10589-ISIS.AddressPrefix;
BEHAVIOUR reachableAddressp1-B BEHAVIOUR
DEFINED AS The value to be given to the addressPre
fix attribute on MO creation. This parameter is man
datory;;
REGISTERED AS {ISO10589-ISIS.proi
reachableAddressP1 (3)};
reachableAddressP2 PARAMETER
CONTEXT CREATE-INFO;
WITH SYNTAX ISO10589-ISIS.MappingType;
BEHAVIOUR reachableAddressp2-B BEHAVIOUR
DEFINED AS The value to be given to the map
pingType attribute on MO creation. This parameter
is only permitted when the `type' of the parent cir
cuit is either `broadcast' or `DA'. In those cases the
default value is `manual';;
REGISTERED AS {ISO10589-ISIS.proi
reachableAddressP2 (4)};
manualAdjacencyP1 PARAMETER
CONTEXT CREATE-INFO;
WITH SYNTAX ISO10589-ISIS.LANAddress;
BEHAVIOUR manualAdjacencyP1-B BEHAVIOUR
DEFINED AS The value to be given to the lANAd
dress attribute on MO creation;;
REGISTERED AS {ISO10589-ISIS.proi
manualAdjacencyP1 (5)};
manualAdjacencyP2 PARAMETER
CONTEXT CREATE-INFO;
WITH SYNTAX ISO10589-ISIS.EndSystemIDs;
BEHAVIOUR manualAdjacencyP2-B BEHAVIOUR
DEFINED AS The value to be given to the endSys
temIDs attribute on MO creation;;
REGISTERED AS {ISO10589-ISIS.proi
manualAdjacencyP2 (6)};
successResponse PARAMETER
CONTEXT ACTION-REPLY;
WITH SYNTAX ISO10589-ISIS.ResponseCode;
BEHAVIOUR successResponse-B BEHAVIOUR
DEFINED AS Returned in the responseCode field of
an ActionReply when the action has completed suc
cessfully.;;
REGISTERED AS {ISO10589-ISIS.proi successResponse
(7)};
failureResponse PARAMETER
CONTEXT ACTION-REPLY;
WITH SYNTAX ISO10589-ISIS.ResponseCode;
BEHAVIOUR failureResponse-B BEHAVIOUR
DEFINED AS Returned in the responseCode field of
an ActionReply when the action failed to complete.
The failureReason parameter is returned with this re
sponseCode, giving additional information;;
REGISTERED AS {ISO10589-ISIS.proi failureResponse
(8)};
failureReason PARAMETER
CONTEXT ACTION-REPLY;
WITH SYNTAX ISO10589-ISIS.ActionFailureReason;
BEHAVIOUR failureReason-B BEHAVIOUR
DEFINED AS Gives the reason why an entity failed to
activate or deactivate.;;
REGISTERED AS {ISO10589-ISIS.proi failureReason
(9)};
constraintViolation PARAMETER
CONTEXT SPECIFIC-ERROR;
WITH SYNTAX
ISO10589-ISIS.ConstraintViolationReason;
BEHAVIOUR constraintViolation-B BEHAVIOUR
DEFINED AS The specific error returned on failure of
a REPLACE operation when the MO prohibits such
operations under certain conditions, for example
while the MO is in the disabled operational state.;;
REGISTERED AS {ISO10589-ISIS.proi
constraintViolation (10)};
notificationReceivingAdjacency PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX
ISO10589-ISIS.LocalDistinguishedName;
BEHAVIOUR notificationReceivingAdjacency-B
BEHAVIOUR
DEFINED AS The local managed object name of the
adjacency upon which the NPDU was received;;
REGISTERED AS {ISO10589-ISIS.proi
notificationReceivingAdjacency (11)};
notificationIDLength PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.IDLength;
BEHAVIOUR notificationIDLength-B BEHAVIOUR
DEFINED AS The IDLength specified in the ignored
PDU;;
REGISTERED AS {ISO10589-ISIS.proi
notificationIDLength (12)};
notificationAreaAddress PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.AreaAddress;
BEHAVIOUR notificationAreaAddress-B BEHAVIOUR
DEFINED AS The Area Address which caused Maxi
mumAreaAddresses to be exceeded;;
REGISTERED AS {ISO10589-ISIS.proi
notificationAreaAddress (13)};
notificationSourceID PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.SourceID;
BEHAVIOUR notificationSourceID-B BEHAVIOUR
DEFINED AS The source ID of the LSP;;
REGISTERED AS {ISO10589-ISIS.proi
notificationSourceID (14)};
notificationVirtualLinkChange PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.VirtualLinkChange;
BEHAVIOUR notificationVirtualLinkChange-B
BEHAVIOUR
DEFINED AS This indicates whether the event was
genrated as a result of the creation or deletion of a
Virtual Link between two Level 2 Intermediate Sys
tems.;;
REGISTERED AS {ISO10589-ISIS.proi
notificationVirtualLinkChange (15)};
notificationVirtualLinkAddress PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.NetworkEntityTitle;
BEHAVIOUR notificationVirtualLinkAddress-B
BEHAVIOUR
DEFINED AS The Network Entity Title of the Level 2
Intermediate System at the remote end of the virtual
link;;
REGISTERED AS {ISO10589-ISIS.proi
notificationVirtualLinkAddress (16)};
notificationNewCircuitState PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.NewCircuitState;
BEHAVIOUR notificationNewCircuitState-B
BEHAVIOUR
DEFINED AS The direction of the Circuit state change
specified as the resulting state. i.e. a change from On
to Off is specified as Off;;
REGISTERED AS {ISO10589-ISIS.proi
notificationNewCircuitState (17)};
notificationNewAdjacencyState PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.NewAdjacencyState;
BEHAVIOUR notificationNewAdjacencyState-B
BEHAVIOUR
DEFINED AS The direction of the Adjacency state
change specified as the resulting state. i.e. a change
from Up to Down is specified as Down. Any state
other than Up is considered to be Down.;;
REGISTERED AS {ISO10589-ISIS.proi
notificationNewAdjacencyState (18)};
notificationAdjacentSystem PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.SystemID;
BEHAVIOUR notificationAdjacentSystem-B
BEHAVIOUR
DEFINED AS The system ID of the adjacent system;;
REGISTERED AS {ISO10589-ISIS.proi
notificationAdjacentSystem (19)};
notificationReason PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.Reason;
BEHAVIOUR notificationReason-B BEHAVIOUR
DEFINED AS The associated Reason;;
REGISTERED AS {ISO10589-ISIS.proi
notificationReason (20)};
notificationPDUHeader PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.PDUHeader;
BEHAVIOUR notificationPDUHeader-B BEHAVIOUR
DEFINED AS The header of the PDU which caused
the notification;;
REGISTERED AS {ISO10589-ISIS.proi
notificationPDUHeader (21)};
notificationCalledAddress PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.SNPAAddress;
BEHAVIOUR notificationCalledAddres-B
BEHAVIOUR
DEFINED AS The SNPA Address which was being
called when the Adjacency was taken down as a re
sult of a call reject;;
REGISTERED AS {ISO10589-ISIS.proi
notificationCalledAddress (22)};
notificationVersion PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.Version;
BEHAVIOUR notificationVersion-B BEHAVIOUR
DEFINED AS The version number reported by the
other system;;
REGISTERED AS {ISO10589-ISIS.proi
notificationVersion (23)};
notificationDesignatedIntermediateSystemChange
PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.DesignatedISChange;
BEHAVIOUR
notificationDesignatedIntermediateSystemChange-B
BEHAVIOUR
DEFINED AS The direction of the change in Desig
nated Intermediate System status of this system;;
REGISTERED AS {ISO10589-ISIS.proi
notificationDesignatedIntermediateSystemChange
(24)};
notificationOverloadStateChange PARAMETER
CONTEXT EVENT-INFO;
WITH SYNTAX ISO10589-ISIS.OverloadStateChange;
BEHAVIOUR notificationOverloadStateChange-B
BEHAVIOUR
DEFINED AS The direction of the change in Overload
status;;
REGISTERED AS {ISO10589-ISIS.proi
notificationOverloadStateChange (25)};
11.2.15 Attribute Groups
counters ATTRIBUTE GROUP
DESCRIPTION The group of all counters;
REGISTERED AS {ISO10589-ISIS.agoi counters (1)};
11.2.16 Behaviour Definitions
resettingTimer-B BEHAVIOUR
DEFINED AS This attribute specifies the interval be
tween certain events in the operation of the protocol
state machine. If the value of this attribute is
changed to a new value t while the protocol state
machine is in operation, the implementation shall
take the necessary steps to ensure that for any time
interval which was in progress when the correspond
ing attribute was changed, the next expiration of the
that interval takes place t seconds from the original
start of that interval, or immediately, whichever is
later. The precision with which this time shall be im
plemented shall be the same as that associated with
the basic operation of the timer attribute;
replaceOnlyWhileDisabled-B BEHAVIOUR
DEFINED AS This attribute shall only permit the RE
PLACE operation to be performed on it while the
MO is in the Disabled Operational State. An at
tempt to perform a REPLACE operation while the
MO is in the Enabled Operation State shall fail with
the generation of the constraintViolation specific er
ror.;
resourceLimiting-B BEHAVIOUR
DEFINED AS This attribute places limits on some re
source". In general implementations may allocate
reources up to this limit when the managed object is
enabled and it may be impossible to change the allo
cation without first disabling and re-enabling the
managed object. Therefore this International Stan
dard only requires that it shall be possible to perform
a REPLACE operation on this attribute while the
MO is disabled. However some implementations
may be able to to change the allocation of resources
without first disabling the MO. In this case it is per
mitted to increase the value of the atribute at any
time, but it shall not be decreased below the cur
rently used" value of the resource. Where an at
tempt to perform a REPLACE operation fails either
because the MO is enabled, or because an attempt
has been made to decrease the value, the REPLACE
operation shall fail with the generation of the con
straintViolation specific error.;
11.2.17 ASN1 Modules
ISO10589-ISIS{tbd1}
DEFINITIONS ::= BEGIN
-- object identifier definitions
sc6 OBJECT IDENTIFIER ::= {joint-iso-ccitt sc6(?)}
-- value to be assigned by SC21 secretariat
isisoi OBJECT IDENTIFIER ::= {sc6 iSO10589(?)}
-- value to be assigned by SC6 secretariat
moi OBJECT IDENTIFIER ::= {isisoi objectClass (3)}
poi OBJECT IDENTIFIER ::= {isisoi package (4)}
proi OBJECT IDENTIFIER ::= {isisoi parameter (5)}
nboi OBJECT IDENTIFIER ::= {isisoi nameBinding (6)}
aoi OBJECT IDENTIFIER ::= {isisoi attribute (7)}
agoi OBJECT IDENTIFIER ::= {isisoi attributeGroup
(8)}
acoi OBJECT IDENTIFIER ::= {isisoi action (10)}
noi OBJECT IDENTIFIER ::= {isisoi notification (11)}
ActionFailureReason ::= ENUMERATED{
reason1(0),
reason2(1)}
-- Note: actual reasons TBS
ActionInfo ::= SET OF Parameter
ActionReply ::= SEQUENCE{
responseCode OBJECT IDENTIFIER,
responseArgs SET OF Parameter OPTIONAL}
AddressPrefix ::= OCTETSTRING(SIZE(0..20))
AdjacencyState ::= ENUMERATED{
initializing(0),
up(1),
failed(2)}-- was 4 in N5821 , is it required at all?
AreaAddress ::= OCTETSTRING(SIZE(1..20))
AreaAddresses ::= SET OF AreaAddress
Boolean ::= BOOLEAN
CircuitID ::= OCTETSTRING(SIZE(1..10))
CompleteSNPInterval ::= INTEGER(1..600)
ConstraintViolationReason ::= OBJECT IDENTIFIER;
DRISISHelloTimer ::= INTEGER(1..65535)
DatabaseState ::= ENUMERATED{
off(0),
on(1),
waiting(2)}
DesignatedISChange ::= ENUMERATED{
resigned(0),
elected(1)}
DefaultESHelloTimer ::= INTEGER(1..65535)
EndSystemIDs ::= SET OF SystemID
GraphicString ::= GRAPHICSTRING
HelloTimer ::= INTEGER(1..65535)
HoldingTimer ::= INTEGER(1..65535)
HopMetric ::= INTEGER(0..63)
ISISHelloTimer ::= INTEGER(1..65535)
IDLength ::= INTEGER(0..9)
IdleTimer ::= INTEGER(1..65535)
InitialMinimumTimer ::= INTEGER(1..65535)
IntermediateSystemPriority ::= INTEGER(1..127)
ISType ::= ENUMERATED{
level1IS(1),
level2IS(2)}
LANAddress ::= OCTETSTRING(SIZE(6))
AdjacencyUsageType::= ENUMERATED{
undefined(0),
level1(1),
level2(2),
level1and2(3)}
LocalDistinguishedName ::= CMIP-1.ObjectInstance
-- A suitable free standing definition is requred
LSPID ::= OCTETSTRING(SIZE(2..11))
MappingType ::= ENUMERATED{
manual(0),
x121(1)}
MaximumBuffers ::= INTEGER(1..65535)
MaximumCallAttempts ::= INTEGER(1..65535)
MaximumLSPGenerationInterval ::= INTEGER(1..65535)
MaximumPathSplits ::= INTEGER(1..32)
MaximumSVCAdjacencies ::= INTEGER(1..65535)
MaximumVirtualAdjacencies ::= INTEGER(0..32)
MetricIncrement ::= INTEGER(0..63)
MetricType ::= ENUMERATED{
internal(0),
external(1)}
MinimumBroadcastLSPTransmissionInterval ::=
INTEGER(1..65535)
MinimumLSPGenerationInterval ::= INTEGER(1..65535)
MinimumLSPTransmissionInterval ::=
INTEGER(1..65535)
NeighbourSystemType ::= ENUMERATED{
unknown(0),
endSystem(1),
intermediateSystem(2),
l1IntermediateSystem(3),
l2IntermediateSystem(4)}
NetworkEntityTitle ::= OCTETSTRING(SIZE(1..19))
NewAdjacencyState ::= ENUMERATED{
down(0),
up(1)}
NewCircuitState ::= ENUMERATED{
off(0),
on(1)}
NonWrappingCounter ::= INTEGER(0..264-1)
NotificationInfo ::= SET OF Parameter
NSAPAddress ::= OCTETSTRING(SIZE(1..20))
OctetString ::= OCTETSTRING
OriginatingLSPBufferSize ::= INTEGER(512..1492)
OutputAdjacencies ::= SET OF LocalDistinguishedName
OverloadStateChange ::= ENUMERATED{
on(0),
waiting(1)}
Parameter ::= SEQUENCE{
paramIdOBJECT IDENTIFIER,
paramInfoANY DEFINED BY paramID}
PartialSNPInterval ::= INTEGER(1..65535)
Password ::= OCTETSTRING(SIZE(0..254)
Passwords ::= SET OF Password
PathMetric ::= INTEGER(0..1023)
PDUHeader ::= OCTETSTRING(SIZE(0..255))
PollESHelloRate ::= INTEGER(1..65535)
Reason ::= ENUMERATED{
holdingTimerExpired(0),
checksumError(1),
oneWayConnectivity(2),
callRejected(3),
reserveTimerExpired(4),
circuitDisabled(5),
versionSkew(6),
areaMismatch(7),
maximumBroadcastIntermediateSystemsExceeded(8),
maximumBroadcastEndSystemsExceeded(9),
wrongSystemType(10)}
ResponseCode ::= OBJECT IDENTIFIER
RecallTimer ::= INTEGER(1..65535)
ReserveTimer ::= INTEGER(1..65535)
SNPAAddress ::=
NUMERICSTRING(FROM("0"|"1"|"2"|"3"|"4"|"5"|
"6"|"7"|"8"|"9"))(SIZE(0..15))
-- Up to 15 Digits 0..9
SNPAAddresses ::= SET OF SNPAAddress
CircuitType ::= ENUMERATED{
broadcast(0),
ptToPt(1),
staticIN(2),
staticOut(3),
dA(4)}
SourceID ::= OCTETSTRING(SIZE(1..10))
SystemID ::= OCTETSTRING(SIZE(0..9))
VirtualLinkChange ::= ENUMERATED{
deleted(0),
created(1)}
Version ::= GRAPHICSTRING
WaitingTime ::= INTEGER(1..65535)
maximumPathSplits-Default INTEGER ::= 2
MaximumPathSplits-Permitted ::= INTEGER(1..32)
maximumBuffers-Default INTEGER ::= ImpSpecific
MaximumBuffers-Permitted ::= INTEGER(1..ImpSpecific)
minimumLSPTransmissionInterval-Default INTEGER ::=
5
MinimumLSPTransmissionInterval-Permitted ::=
INTEGER(5..30)
maximumLSPGenerationInterval-Default INTEGER ::=
900
MaximumLSPGenerationInterval-Permitted ::=
INTEGER(60..900)
minimumBroadcastLSPTransmissionInterval-Default
INTEGER ::=33
MinimumBroadcastLSPTransmissionInterval-Permitted ::=
INTEGER(1..65535)
completeSNPInterval-Default INTEGER ::= 10
CompleteSNPInterval-Permitted ::= INTEGER(1..600)
originatingL1LSPBufferSize-Default INTEGER ::=
receiveLSPBufferSize
OriginatingL1LSPBufferSize-Permitted ::=
INTEGER(512..receiveLSPBufferSize)
manualAreaAddresses-Default AreaAddresses ::= {}
ManualAreaAddresses-Permitted ::= AreaAddresses
(SIZE(0..MaximumAreaAddresses))
minimumLSPGenerationInterval-Default INTEGER ::= 30
MinimumLSPGenerationInterval-Permitted ::=
INTEGER(5..300)
defaultESHelloTime-Default INTEGER ::= 600
DefaultESHelloTime-Permitted ::= INTEGER(1..65535)
pollESHelloRate-Default INTEGER ::= 50
PollESHelloRate-Permitted ::= INTEGER(1..65535)
partialSNPInterval-Default INTEGER ::= 2
PartialSNPInterval-Permitted ::= INTEGER(1..65535)
waitingTime-Default INTEGER ::= 60
WaitingTime-Permitted ::= INTEGER(1..65535)
dRISISHelloTimer-Default INTEGER ::= 1
DRISISHelloTimer-Permitted ::= INTEGER(1..65535)
originatingL2LSPBufferSize-Default INTEGER ::=
receiveLSPBufferSize
OriginatingL2LSPBufferSize-Permitted ::=
INTEGER(512..receiveLSPBufferSize)
maximumVirtualAdjacencies-Default INTEGER ::= 2
MaximumVirtualAdjacencies-Permitted ::=
INTEGER(0..32)
helloTimer-Default INTEGER ::= 10
HelloTimer-Permitted ::= INTEGER(1..21845)
defaultMetric-Default INTEGER ::= 20
DefaultMetric-Permitted ::= INTEGER(1..MaxLinkMetric)
optionalMetric-Default INTEGER ::= 0
OptionalMetric-Permitted ::=
INTEGER(0..MaxLinkMetric)
metricType-Default MetricType ::= Internal
iSISHelloTimer-Default INTEGER ::= 3
ISISHelloTimer-Permitted ::= INTEGER(1..21845)
externalDomain-Default BOOLEAN ::= TRUE
l1IntermediateSystemPriority-Default INTEGER ::= 64
L1IntermediateSystemPriority-Permitted ::=
INTEGER(1..127)
callEstablishmentMetricIncrement-Default INTEGER ::= 0
CallEstablishmentMetricIncrement-Permitted ::=
INTEGER(0..MaxLinkMetric)
idleTimer-Default INTEGER ::= 30
IdleTimer-Permitted ::= INTEGER(0..65535)
initialMinimumTimer-Default INTEGER ::= 55
InitialMinimumTimer-Permitted ::= INTEGER(1..65535)
reserveTimer-Default INTEGER ::= 600
ReserveTimer-Permitted ::= INTEGER(1..65535)
maximumSVCAdjacencies-Default INTEGER ::= 1
MaximumSVCAdjacencies-Permitted ::=
INTEGER(1..65535)
reservedAdjacency-Default BOOLEAN ::= FALSE
neighbourSNPAAddress-Default INTEGER ::= 0
recallTimer-Default INTEGER ::= 60
RecallTimer-Permitted ::= INTEGER(0..65535)
maximumCallAttempts-Default INTEGER ::= 10
MaximumCallAttempts-Permitted ::= INTEGER(0..255)
manualL2OnlyMode-Default BOOLEAN ::= FALSE
l2IntermediateSystemPriority-Default INTEGER ::= 64
L2IntermediateSystemPriority-Permitted ::=
INTEGER(1..127)
lANAddress-Default LANAddress ::= 000000000000
sNPAAddresses-Default SNPAAddresses::= {}
password-Default Password ::= {}
passwords-Default Passwords ::= {} -- The empty set
END
12 Conformance
12.1 Static Conformance Requirements
12.1.1 Protocol Implementation Conformance
Statement
A Protocol Implementation Conformance Statement (PICS)
shall be completed in respect of any claim for conformance
of an implementation to this International Standard: the
PICS shall be produced in accordance with the relevant
PICS pro-forma in Annex A.
12.1.2 Static Conformance for all ISs
A system claiming conformance to this International Stan
dard shall be capable of:
a)calculating a single minimum cost route to each desti
nation according to 7.2.6 for the default metric speci
fied in 7.2.2;
b)utilising Link State information from a system only
when an LSP with LSP number 0 and remaining life
time>0 is present according to 7.2.5;
c)removing excess paths according to 7.2.7
d)performing the robustness checks according to 7.2.8;
e)constructing a forwarding database according to 7.2.9;
f)if (and only if) Area Partition Repair is supported,
1)performing the operations according to 7.2.10;
2)performing the encapsulation operations in the for
warding process according to 7.4.3.2; and
3)performing the decapsulation operations in the re
ceive process according to 7.4.4;
TEMPORARY NOTE may need to reor
ganise clause 7.4.4 in order to make it crystal
clear what is required in the receive process in
the presence/absence of partition repair
g)computing area addresses according to 7.2.11;
h)generating local Link State information as required by
7.3.2;
i)including information from Manual Adjacencies ac
cording to 7.3.3.1;
j)if (and only if) Reachable Addresses are supported, in
cluding information from Reachable Addresses ac
cording to 7.3.3.2;
k)generating multiple LSPs according to 7.3.4;
l)generating LSPs periodically according to 7.3.5;
m)generating LSPs on the occurrence of events accord
ing to 7.3.6;
n)generating an LSP checksum according to 7.3.11;
o)operating the Update Process according to 7.3.12
7.3.17 including controlling the rate of LSP transmis
sion only for each broadcast circuit (if any) according
to 7.3.15.6;
p)operating the LSP database overload procedures ac
cording to 7.3.19.1;
q)selecting the appropriate forwarding database accord
ing to 7.4.2;
r)forwarding ISO 8473 PDUs according to 7.4.3.1 and
7.4.3.3;
s)operating the receive process according to 7.4.4;
TEMPORARY NOTE item 1 of the second bulleted
list is only required if you implement partition repair.
We need to reorganise the structure so we can pull
this out.
t)performing on each supported Point-to-Point circuit (if
any):
1)forming and maintaining adjacencies according to
8.2;
u)performing on each supported ISO 8208 circuit (if
any)
1)SVC establishment according to 8.3.2.1 using the
network layer protocols according to 8.3.1;
2)If Reachable Addresses are supported, the opera
tions specified in 8.3.2.2 8.3.5.6.
3)If call
Estab
lish
ment
Met
ricIncrement greater
than zero are supported, the operations specified in
8.3.5.3.
4)If the Reverse Path Cache is supported, the opera
tions specified in 8.3.3
v)performing on each supported broadcast circuit (if
any)
1)the pseudonode operations according to 7.2.3;
2)controlling the rate of LSP transmission according
to 7.3.15.6;
3)the operations specified in 8.4.18.4.4 and 8.4.6;
4)the operations specified in 8.4.5.
w)constructing and correctly parsing all PDUs according
to clause 9;
x)providing a system environment in accordance with
clause 10;
y)being managed via the system management attributes
defined in clause 11. For all attributes referenced inthe
normative text, the default value (if any) shall be sup
ported. Other values shall be supported if referenced
in a REQUIRED VALUES clause of the GDMO
definition;
z)If authentication procedures are implemented:
1)the authentication field processing functions of
clauses 7.3.77.3.10, 7.3.15.17.3.15.4, 8.2.3
8.2.4, and 8.4.1.1;
2)the Authentication Information field of the
PDU in clauses 9.59.13.
12.1.3 Static Conformance Requirements for
level 1 ISs
A system claiming conformance to this International Stan
dard as a level 1 IS shall conform to the requirements of
12.1.2 and in addition shall be capable of
a)identifying the nearest Level 2 IS according to 7.2.9.1;
b)generating Level 1 LSPs according to 7.3.7;
c)generating Level 1 pseudonode LSPs for each sup
ported broadcast circuit (if any) according to 7.3.8;
d)performing the actions in Level 1 Waiting State ac
cording to 7.3.19.2
12.1.4 Static Conformance Requirements for
level 2 ISs
A system claiming conformance to this International Stan
dard as a level 2 IS shall conform to the requirements of
12.1.2 and in addition shall be capable of
a)setting the attached flag according to 7.2.9.2;
b)generating Level 2 LSPs according to 7.3.9;
c)generating Level 2 pseudonode LSPs for each sup
ported broadcast circuit (if any) according to 7.3.10;
d)performing the actions in Level 2 Waiting State ac
cording to 7.3.19.3.
12.2 Dynamic Conformance
12.2.1 Receive Process Conformance
Requirements
Any protocol function supported shall be implemented in
accordance with 7.4.4.
12.2.2 Update Process Conformance
Requirements
Any protocol function supported shall be implemented in
accordance with 7.3 and its subclauses.
Any PDU transmitted shall be constructed in accordance
with the appropriate subclauses of 9.
12.2.3 Decision Process Conformance
Requirements
Any protocol function supported shall be implemented in
accordance with 7.2 and its subclauses.
12.2.4 Forwarding Process Conformance
Requirements
Any protocol function supported shall be implemented in
accordance with 7.4 and its subclauses.
12.2.5 Performance Requirements
This International Standard requires that the following per
formance criteria be met. These requirements apply regard
less of other demands on the system; if an Intermediate sys
tem has other tasks as well, those will only get resources
not required to meet these criteria.
Each Intermediate system implementation shall specify (in
its PICS):
a)the maximum number of other Intermediate systems it
can handle. (For L1 Intermediate systems that means
Intermediate systems in the area; for L2 Intermediate
systems that is the sum of Intermediate systems in the
area and Intermediate systems in the L2 subdomain.)
Call this limit N.
b)the maximum supported forwarding rate in ISO 8473
PDUs per second.
12.2.5.1 Performance requirements on the Update
process
The implementation shall guarantee the update process
enough resources to process N LSPs per 30 seconds. (Re
sources = CPU, memory, buffers, etc.)
In a stable topology the arrival of a single new LSP on a
circuit shall result in the propagation of that new LSP over
the other circuits of the IS within one second, irrespective
of the forwarding load for ISO 8473 data PDUs.
12.2.5.2 Performance requirement on the Decision
process
The implementation shall guarantee the decision process
enough resources to complete (i.e. start to finish) within 5
seconds, in a stable topology while forwarding at the maxi
mum rate. (For L2 Intermediate Systems, this applies to the
two levels together, not each level separately.)
12.2.5.3 Reception and Processing of PDUs
An ideal Intermediate system would be able to correctly
process all PDUs, both control and data, with which it was
presented, while simultaneously running the decision proc
ess and responding to management requests. However, in
the implementations of real Intermediate systems some
compromises must be made. The way in which these com
promises are made can dramatically affect the correctness
of operation of the Intermediate system. The following gen
eral principles apply.
a)A stable topology should result in stable routes when
forwarding at the maximum rated forwarding rate.
b)Some forwarding progress should always be made (al
beit over incorrect routes) even in the presence of a
maximally unstable topology.
In order to further characterise the required behaviour, it is
necessary to identify the following types of traffic.
a)IIH traffic. This traffic is important for maintaining In
termediate system adjacencies and hence the Interme
diate system topology. In order to prevent gratuitous
topology changes it is essential that Intermediate sys
tem adjacencies are not caused to go down errone
ously. In order to achieve this no more than
ISISHoldingMultiplier - 1 IIH PDUs may be
dropped between any pair of Intermediate systems. A
safer requirement is that no IIH PDUs are dropped.
The rate of arrival of IIH PDUs is approximately con
stant and is limited on Pointto-Point links to 1/iSIS
Hello
Timer and on LANs to a value of approxi
mately 2(n/iSIS
Hello
Timer) + 2, where n is the
number of Intermediate systems on the LAN (assum
ing the worst case that they are all Level 2 Intermedi
ate systems).
b)ESH PDU traffic. This traffic is important for main
taining End system adjacencies, and has relatively low
processing latency. As with IIH PDUs, loss of End
system adjacencies will cause gratuitous topology
changes which will result in extra control traffic.
The rate of arrival of ESH PDUs on Pointto-Point
links is limited to approximately 1/Default
ES
Hello
Timer under all conditions. On LANs the background
rate is approximately n/DefaultESHelloTimer
where n is the number of End systems on the LAN.
The maximum rate during polling is limited to ap
proximately n/pollESHelloRate averaged over a pe
riod of about 2 minutes. (Note that the actual peak ar
rival rate over a small interval may be much higher
than this.)
c)LSP (and SNP) traffic. This traffic will be
retransmitted indefinitely by the update process if it is
dropped, so there is no requirement to be able to proc
ess every received PDU. However, if a substantial
proportion are lost, the rate of convergence to correct
routes will be affected, and bandwidth and processing
power will be wasted.
On Point-to-Point links the peak rate of arrival is lim
ited only by the speed of the data link and the other
traffic flowing on that link. The maximum average
rate is determined by the topology.
On LANs the rate is limited at a first approximation to
a maximum rate of 1000/min
i
mum
Broad
cast
LSP
Trans
mis
sion
Int
er
val, however it is possible that
this may be multiplied by a factor of up to n, where n
is the number of Intermediate systems on the LAN, for
short periods. A Intermediate system shall be able to
receive and process at least the former rate without
loss, even if presented with LSPs at the higher rate.
(i.e. it is permitted to drop LSPs, but must process at
least 1000/min
i
mum
Broad
cast
LSP
Trans
mis
sion
Int
er
val per second of those presented.)
The maximum background rate of LSP traffic (for a
stable topology) is dependent on the maximum sup
ported configuration size and the settings of
maximumLSPGenerationInterval. For these pur
poses the default value of 900 seconds can be as
sumed. The number of LSPs per second is then very
approximately (n1 + n2 +ne/x)/900 where n1 is the
number of level 1 Intermediate systems, n2 the num
ber of level 2 Intermediate systems, ne the number of
End system IDs and x the number of ID which can be
fitted into a single LSP.
NOTE This gives a value around 1 per second for
typical maximum configurations of:
4000 IDs
100 L1 Intermediate systems per area
400 L2 Intermediate systems.
d)Data Traffic. This is theoretically unlimited and can
arrive at the maximum data rate of the Pointto-Point
link or LAN (for ISO 8802.3 this is 14,000 PDUs per
second). In practice it will be limited by the operation
of the congestion avoidance and control algorithms,
but owing to the relatively slow response time of these
algorithms, substantial peaks are likely to occur.
An Intermediate system shall state in its PICS its
maximum forwarding rate. This shall be quoted under
at least the following conditions.
1)A stable topology of maximum size.
2)A maximally unstable topology. This figure shall
be non-zero, but may reasonably be as low as 1
PDU per second.
The following constraints must be met.
a)The implementation shall be capable of receiving the
maximum rate of ISH PDUs without loss whenever
the following conditions hold
1)The data forwarding traffic rate averaged over any
period of one second does not exceed the rate
which the implementation claims to support
2)The ESH and LSP rates do not exceed the back
ground (stable topology) rate.
b)If it is unavoidable that PDUs are dropped, it is a goal
that the order of retaining PDUs shall be as follows
(i.e. It is least desirable for IIH PDUs to be dropped).
1)IIH PDUs
2)ESH PDUs
3)LSPs and SNPs
4)data PDUs.
However, no class of traffic shall be completely
starved. One way to achieve this is to allocate a queue
of suitable length to each class of traffic and place the
PDUs onto the appropriate queue as they arrive. If the
queue is full the PDUs are discarded. Processor re
sources shall be allocated to the queues to ensure that
they all make progress with the same priorities as
above. This model assumes that an implementation is
capable of receiving PDUs and selecting their correct
queue at the maximum possible data rate (14,000
PDUs per second for a LAN). If this is not the case,
reception of data traffic at a rate greater than some
limit (which must be greater than the maximum rated
limit) will cause loss of some IIH PDUs even in a sta
ble topology. This limit shall be quoted in the PICS if
it exists.
NOTE - Starting from the stable topology condition at maxi
mum data forwarding rate, an increase in the arrival rate of
data PDUs will initially only cause some data NPDUs to be
lost. As the rate of arrival of data NPDUs is further in
creased a point may be reached at which random PDUs are
dropped. This is the rate which must be quoted in the PICS
12.2.5.4 Transmission
Sufficient processor resources shall be allocated to the
transmission process to enable it to keep pace with recep
tion for each PDU type. Where prioritisation is required, the
same order as for reception of PDU types applies.
Annex A
PICS Proforma
(This annex is normative)
A.1 Introduction
The supplier of a protocol implementation which is claimed
to conform to International Standard ISO 10589, whether as
a level 1 or level 2 Intermediate system implementation,
shall complete the applicable Protocol Implementation
Conformance Statement (PICS) proforma.
A completed PICS proforma is the PICS for the implemen
tation in question. The PICS is a statement of which capa
bilities and options of the protocol have been implemented.
The PICS can have a number of uses, including use:
-by the protocol implementor, as a check-list to reduce
the risk of failure to conform to the standard through
oversight;
-by the supplier and acquirer or potential acquirer
of the implementation, as a detailed indication of
the capabilities of the implementation, stated relative
to the common basis for understanding provided by
the standard PICS proforma;
-by the user or potential user of the implementa
tion, as a basis for initially checking the possibility of
interworking with another implementation (note that,
while interworking can never be guaranteed, failure to
interwork can often be predicted from incompatible
PICS's);
-by a protocol tester, as the basis for selecting appropri
ate tests against which to assess the claim for
conformance of the implementation.
A.2 Abbreviations and Special Symbols
A.2.1 Status-related symbols
M mandatory
O optional
O.<n> optional, but support of at least one of the
group of options labelled by the same numeral
<n> is required.
X prohibited
not applicable
c.<p> conditional requirement, according to condi
tion <p>
A.3 Instructions for Completing the
PICS Proformas
A.3.1 General structure of the PICS proforma
The first part of the PICS proforma Implementation
Identification and Protocol Summary is to be completed
as indicated with the information necessary to identify fully
both the supplier and the implementation.
The main part of the PICS proforma is a fixed-format ques
tionnaire divided into subclauses each containing a group of
individual items. Answers to the questionnaire items are to
be provided in the rightmost column, either by simply
marking an answer to indicate a restricted choice (usually
Yes or No), or by entering a value or a set or range of val
ues. (Note that there are some items where two or more
choices from a set of possible answers can apply: all rele
vant choices are to be marked.)
Each item is identified by an item reference in the first col
umn; the second column contains the question to be an
swered; the third column contains the reference or refer
ences to the material that specifies the item in the main
body of the standard. the remaining columns record the
status of the item whether support is mandatory, optional
or conditional and provide the space for the answers: see
A.3.4 below.
A supplier may also provide or be required to provide
further information, categorised as either Additional Infor
mation or Exception Information. When present, each kind
of further information is to be provided in a further sub
clause of items labelled A<i> or X<i> respectively for
cross-referencing purposes, where <i> is any unambiguous
identification for the item (e.g. simply a number): there are
no other restrictions on its format and presentation.
A completed PICS proforma, including any Additional In
formation and Exception Information, is the Protocol Im
plementation Conformance Statement for the implementa
tion in question.
NOTE - Where an implementation is capable of being con
figured in more than one way, a single PICS may be able to
describe all such configurations. However, the supplier has
the choice of providing more than one PICS, each covering
some subset of the implementation's configuration capabili
ties, in case this makes for easier and clearer presentation of
the information.
A.3.2 Additional Information
Items of Additional Information allow a supplier to provide
further information intended to assist the interpretation of
the PICS. It is not intended or expected that a large quantity
will be supplied, and a PICS can be considered complete
without any such information. Examples might be an out
line of the ways in which a (single) implementation can be
set up to operate in a variety of environments and configu
rations.
References to items of Additional information may be en
tered next to any answer in the questionnaire, and may be
included in items of Exception Information.
A.3.3 Exception Information
It may occasionally happen that a supplier will wish to an
swer an item with mandatory or prohibited status (after any
conditions have been applied) in a way that conflicts with
the indicated requirement. No pre-printed answer will be
found in the Support column for this, but the Supplier may
write the desired answer into the Support column. If this is
done, the supplier is required to provide an item of Excep
tion Information containing the appropriate rationale, and a
cross-reference from the inserted answer to the Exception
item.
An implementation for which an Exception item is required
in this way does not conform to ISO 10589.
NOTE - A possible reason for the situation described above
is that a defect report is being progressed, which is expected
to change the requirement that is not met by the implemen
tation.
A.3.4 Conditional Status
A.3.4.1 Conditional items
The PICS proforma contains a number of conditional items.
These are items for which the status mandatory, optional
or prohibited that applies is dependent upon whether or
not certain other items are supported, or upon the values
supported for other items. In many cases, whether or not the
item applies at all is conditional in this way, as well as the
status when the item does apply.
Individual conditional items are indicated by a conditional
symbol in the Status column as described in A.3.4.2 below.
Where a group of items are subject to the same condition
for applicability, a separate preliminary question about the
condition appears at the head of the group, with an instruc
tion to skip to a later point in the questionnaire if the Not
Applicable answer is selected.
A.3.4.2 Conditional symbols and conditions
A conditional symbol is of the form c.<n> or c.G<n> where
<n> is a numeral. For the first form, the numeral identifies
a condition appearing in a list at the end of the subclause
containing the item. For the second form, c.G<n>, the nu
meral identifies a condition appearing in the list of global
conditions at the end of the PICS.
A simple condition is of the form:if <p> then <s1> else <s2>
where <p> is a predicate (see A.3.4.3 below), and <s1> and
<s2> are either basic status symbols (M,O,O.<n>, or X) or
the symbol . An extended condition is of the formif <p1> then <s1> else <s2>
else if <p2> then <s2>
[else if <p3> ...]
else <sn>
where <p1> etc. are predicates and <s1> etc. are basic
status symbols or .
The status symbol applicable to an item governed by a sim
ple condition is <s1> if the predicate of the condition is
true, and <s2> otherwise; the status symbol applicable to an
item governed by an extended condition is <si> where <pi>
is the first true predicate, if any, in the sequence <p1>,
<p2>..., and <sn> if no predicate is true.
A.3.4.3 Predicates
A simple predicate in a condition is either
a)a single item reference; or
b)a relation containing a comparison operator (=, <, etc.)
with one (or both) of its operands being an item refer
ence for an item taking numerical values as its answer.
In case (a) the predicate is true if the item referred to is
marked as supported, and false otherwise. In case (b), the
predicate is true if the relation holds when each item refer
ence is replaced by the value entered in the Support column
as answer to the item referred to.
Compound predicates are boolean expressions constructed
by combining simple predicates using the boolean operators
AND, OR and NOT, and parentheses, in the usual way. A
compound predicate is true if and only if the boolean ex
pression evaluates to true when the simple predicates are in
terpreted as described above.
Items whose references are used in predicates are indicated
by an asterisk in the Item column.
A.3.4.4 Answering conditional items
To answer a conditional item, the predicate(s) of the condi
tion is (are) evaluated as described in A.3.4.3 above, and
the applicable status symbol is determined as described in
A.3.4.2. If the status symbol is this indicates that the
item is to be marked in this case; otherwise, the Support
column is to be completed in the usual way.
When two or more basic status symbols appear in a condi
tion for an item, the Support column for the item contains
one line for each such symbol, labelled by the relevant sym
bol. the answer for the item is to be marked in the line la
belled by the symbol selected according to the value of the
condition (unselected lines may be crossed out for added
clarity).
For example, in the item illustrated below, the N/A column
would be marked if neither predicate were true; the answer
line labelled M: would be marked if item A4 was marked as supported,
and the answer line labelled O: would be marked if
the condition including items D1 and B52 applied.Item
References
Status
N/A
Support
H3
Is ... supported?
42.3(d)
C.1
M: Yes
O: Yes No
C.1if A4 then M
else if D1 AND (B52 < 3) then O else
A.4 Identification
A.4.1 Implementation IdentificationSupplierContact point for
queriesabout this PICSImplementation Name(s)and Version(s)Operating
systemName(s and Version(s)Other Hardware and Operating
SystemsClaimedSystem Name(s)(if different)Notes:
a)Only the first three items are required for all implementations; others may be
completed as appropriate in meeting the requirements for full identification.
b)The terms Name and Version should be interpreted appropriately to correspond
with a supplier's terminology (using, e.g., Type, Series, Model)
A.4.2 Protocol Summary: ISO 10589:19xxProtocol VersionAddenda
Implemented(if applicable)AmmendmentsImplementedDate of StatementHave
any Exception items been required (see A.3.3)? No Yes
(The answer Yes means that the implementation does not conform to ISO 10589)
PICS Proforma: Item
References
Status
N/A
Support
AllIS
Are all basic ISIS routeing functions
implemented?
12.1.2
M
M: Yes
C.1if L2IS then O else
C.2if 8208 then O else
PartitionRe
pair
Is Level 1 Partition Repair imple
mented?
12.1.2.f
C.1
O: Yes No
L1IS
Are Level 1 ISIS routeing functions
implemented?
12.1.3
M
M: Yes
L2IS
Are Level 2 ISIS routeing functions
implemented?
12.1.4
O
O: Yes No
PtPt
Are point-to-point circuits imple
mented?
12.1.2.t
O.1
O: Yes No
8208
Are ISO 8208 circuits implemented?
12.1.2.u
O.1
O: Yes No
LAN
Are broadcast circuits implemented?
12.1.2.v
O.1
O: Yes No
EqualCost
Paths
Is computation of equal minimum cost
paths implemented?
7.2.6
O
O: Yes No
Downstream
Is computation of downstream routes
implemented?
7.2.6
O
O: Yes No
DelayMetric
Is path computation based on the delay
metric implemented?
7.2.2
O
O: Yes No
ExpenseMet
ric
Is path computation based on the Ex
pense metric implemented?
7.2.2
O
O: Yes No
Prefixes
Are Reachable Address Prefixes imple