Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|PS|PDF|HTML] [Tracker] [IPR] [Info page]
Obsoleted by:7142 HISTORIC
Network Working Group D. Oran, EditorRequest for Comments: 1142 Digital Equipment Corp. February 1990OSI IS-IS Intra-domain Routing ProtocolStatus of this Memo This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard. Distribution of this memo is unlimited.NOTE: This is a bad ASCII version of this document. The officialdocument is the PostScript file, which has the diagrams in place.Please use the PostScript version of this memo.ISO/IEC DIS 10589Information technology Telecommunications and information exchangebetween systems Interme diate system to Intermediate systemIntra-Domain routeing exchange protocol for use in Conjunction withthe Protocol for providing the Connectionless- mode Network Service(ISO 8473) Technologies de l'information Communication de donnies etichange d'information entre systhmes Protocole intra-domain de routaged'un systhme intermediare ` un systhme intermediare ` utiliserconjointement avec le protocole fournissant le service de riseau enmode sans connexion (ISO 8473) UDC 00000.000 : 000.0000000000Descriptors:Contents Introduction iv 1 Scope and Field of Application 1 2 References 1 3 Definitions 2 4 Symbols and Abbreviations 3 5 Typographical Conventions 4 6 Overview of the Protocol 4 7 Subnetwork Independent Functions 9 8 Subnetwork Dependent Functions 35 9 Structure and Encoding of PDUs 47 10 System Environment 65 11 System Management 67 12 Conformance 95 Annex A PICS Proforma 99 Annex B Supporting Technical Material 105 Annex C Implementation Guidelines and Examples 109 Annex D Congestion Control and Avoidance 115IntroductionThis Protocol is one of a set of International Standards produced tofacilitate the interconnection of open systems. The set of standardscovers the services and protocols re quired to achieve suchinterconnection. This Protocol is positioned with respect to otherrelated standards by the layers defined in the ISO 7498 and by thestructure defined in the ISO 8648. In particular, it is a protocol ofthe Network Layer. This protocol permits Intermediate Systems within arouteing Domain to exchange configuration and routeing information tofacilitate the operation of the route ing and relaying functions ofthe Network Layer. The protocol is designed to operate in closeconjunction with ISO 9542 and ISO 8473. ISO 9542 is used to establishconnectivity and reachability between End Systems and Inter mediateSystems on individual Subnetworks. Data is carried by ISO 8473. Therelated algo rithms for route calculation and maintenance are alsodescribed. The intra-domain ISIS routeing protocol is intended tosupport large routeing domains consisting of combinations of manytypes of subnetworks. This includes point-to-point links, multipointlinks, X.25 subnetworks, and broadcast subnetworks such as ISO 8802LANs. In order to support large routeing domains, provision is madefor Intra-domain routeing to be organised hierarchically. A largedomain may be administratively divided into areas. Each systemresides in exactly one area. Routeing within an area is referred to asLevel 1 routeing. Routeing between areas is referred to as Level 2routeing. Level 2 Intermediate systems keep track of the paths todestination areas. Level 1 Intermediate systems keep track of therouteing within their own area. For an NPDU destined to another area,a Level 1 Intermediate system sends the NPDU to the nearest level 2 ISin its own area, re gardless of what the destination area is. Then theNPDU travels via level 2 routeing to the destination area, where itagain travels via level 1 routeing to the destination End System.Information technologyTelecommunications and information exchange between systemsIntermediate system to Intermediate system Intra-Domain routeingexchange protocol for use in Conjunction with the Protocol forproviding the Connectionless-mode Network Service (ISO 8473)1 Scope and Field of ApplicationThis International Standard specifies a protocol which is used byNetwork Layer entities operating ISO 8473 in In termediate Systems tomaintain routeing information for the purpose of routeing within asingle routeing domain. The protocol herein described relies upon theprovision of a connectionless-mode underlying service.11See ISO 8473and its Addendum 3 for the mechanisms necessary to realise thisservice on subnetworks based on ISO 8208, ISO 8802, and the OSI DataLink Service.This Standard specifies:a)procedures for the transmission of configuration androuteing information between network entities residing in Intermediate Systems within a single routeingdomain;b)the encoding of the protocol data units used for thetransmission of the configuration and routeing information;c)procedures for the correct interpretation of protocolcontrol information; andd)the functional requirements for implementationsclaiming conformance to this Standard.The procedures are defined in terms of:a)the interactions between Intermediate system Networkentities through the exchange of protocol data units;andb)the interactions between a Network entity and an underlying service provider through the exchange ofsubnetwork service primitives.c)the constraints on route determination which must beobserved by each Intermediate system when each hasa routeing information base which is consistent withthe others.2 References2.1 Normative ReferencesThe following standards contain provisions which, through reference inthis text, constitute provisions of this Interna tional Standard. Atthe time of publication, the editions in dicated were valid. Allstandards are subject to revision, and parties to agreements based onthis International Stan dard are encouraged to investigate thepossibility of apply ing the most recent editions of the standardslisted below. Members of IEC and ISO maintain registers of currentlyvalid International Standards. ISO 7498:1984, Information processingsystems Open Systems Interconnection Basic Reference Model. ISO7498/Add.1:1984, Information processing systems Open SystemsInterconnection Basic Reference Model Addendum 1: Connectionless-modeTransmission. ISO 7498-3:1989, Information processing systems OpenSystems Interconnection Basic Reference Model Part 3: Naming andAddressing. ISO 7498-4:1989, Information processing systems OpenSystems Interconnection Basic Reference Model Part 4: ManagementFramework. ISO 8348:1987, Information processing systems Datacommunications Network Service Definition. ISO 8348/Add.1:1987,Information processing systems Data communications Network ServiceDefinition Addendum 1: Connectionless-mode transmission. ISO8348/Add.2:1988, Information processing systems Data communicationsNetwork Service Definition Addendum 2: Network layer addressing. ISO8473:1988, Information processing systems Data communications Protocolfor providing the connectionless-mode network service. ISO8473/Add.3:1989, Information processing systems Telecommunications andinformation exchange betweensystems Protocol for providing the connectionless-mode network service Addendum 3: Provision of theunderlying service assumed by ISO 8473 oversubnetworks which provide the OSI data link service.ISO 8648:1988, Information processing systems OpenSystems Interconnection Internal organisation of theNetwork Layer.ISO 9542:1988, Information processing systems Telecommunications and information exchange between systems End system to Intermediate system Routeing exchange protocol for use in conjunction with the protocolfor providing the connectionless -mode network service(ISO 8473).ISO 8208:1984, Information processing systems Datacommunications X.25 packet level protocol for Dataterminal equipmentISO 8802:1988, Information processing systems Telecommunications and information exchange between systems Local area networks.ISO/TR 9575:1989, Information technology Telecommunications and information exchange between systems OSI Routeing Framework.ISO/TR 9577:1990, Information technology Telecommunications and information exchange between systems Protocol Identification in the Network Layer.ISO/IEC DIS 10165-4:, Information technology Opensystems interconnection Management Information Services Structure of Management Information Part 4:Guidelines for the Definition of Managed Objects.ISO/IEC 10039:1990, IPS-T&IEBS MAC Service Definition.2.2 Other ReferencesThe following references are helpful in describing some ofthe routeing algorithms:McQuillan, J. et. al., The New Routeing Algorithm for theARPANET, IEEE Transactions on Communications, May1980.Perlman, Radia, Fault-Tolerant Broadcast of Routeing Information, Computer Networks, Dec. 1983. Also in IEEEINFOCOM 83, April 1983.Aho, Hopcroft, and Ullman, Data Structures and Algorithms, P204208 Dijkstra algorithm.3 Definitions3.1 Reference Model definitionsThis International Standard makes use of the followingterms defined in ISO 7498:a)Network Layerb)Network Service access pointc)Network Service access point addressd)Network entitye)Routeingf)Network protocolg)Network relayh)Network protocol data unit3.2 Network Layer architecturedefinitionsThis International Standard makes use of the followingterms defined in ISO 8648:a)Subnetworkb)End systemc)Intermediate systemd)Subnetwork servicee)Subnetwork Access Protocolf)Subnetwork Dependent Convergence Protocolg)Subnetwork Independent Convergence Protocol3.3 Network Layer addressingdefinitionsThis International Standard makes use of the followingterms defined in ISO 8348/Add.2:a)Subnetwork addressb)Subnetwork point of attachmentc)Network Entity Title3.4 Local Area Network Definitions This International Standard makes use of the followingterms defined in ISO 8802:a)Multi-destination addressb)Media access controlc)Broadcast medium3.5 Routeing Framework Definitions This document makes use of the following terms defined inISO/TR 9575:a)Administrative Domainb)Routeing Domainc)Hopd)Black hole3.6 Additional DefinitionsFor the purposes of this International Standard, the following definitions apply:3.6.1Area: A routeing subdomain which maintains detailed routeing information about its own internalcomposition, and also maintains routeing information which allows it to reach other routeing subdomains. It corresponds to the Level 1 subdomain.3.6.2Neighbour: An adjacent system reachable by traversal of a single subnetwork by a PDU.3.6.3Adjacency: A portion of the local routeing information which pertains to the reachability of a single neighbour ES or IS over a single circuit.Adjacencies are used as input to the Decision Process for forming paths through the routeing domain.A separate adjacency is created for each neighbouron a circuit, and for each level of routeing (i.e.level 1 and level 2) on a broadcast circuit.3.6.4Circuit: The subset of the local routeing information base pertinent to a single local SNPA.3.6.5Link: The communication path between twoneighbours.A Link is up when communication is possiblebetween the two SNPAs.3.6.6Designated IS: The Intermediate system on aLAN which is designated to perform additional duties. In particular it generates Link State PDUs onbehalf of the LAN, treating the LAN as apseudonode.3.6.7Pseudonode: Where a broadcast subnetwork has nconnected Intermediate systems, the broadcastsubnetwork itself is considered to be apseudonode.The pseudonode has links to each of the n Intermediate systems and each of the ISs has a single linkto the pseudonode (rather than n-1 links to each ofthe other Intermediate systems). Link State PDUsare generated on behalf of the pseudonode by theDesignated IS. This is depicted below in figure 1.3.6.8Broadcast subnetwork: A subnetwork which supports an arbitrary number of End systems and Intermediate systems and additionally is capable oftransmitting a single SNPDU to a subset of thesesystems in response to a single SN_UNITDATArequest.3.6.9General topology subnetwork: A subnetworkwhich supports an arbitrary number of End systems and Intermediate systems, but does not support a convenient multi-destination connectionlesstrans
mission facility, as does a broadcast sub
net
work.3.6.10Routeing Subdomain: a set of Intermediate systems and End systems located within the sameRouteing domain.3.6.11Level 2 Subdomain: the set of all Level 2 Intermediate systems in a Routeing domain.4 Symbols and Abbreviations4.1 Data UnitsPDU Protocol Data UnitSNSDU Subnetwork Service Data UnitNSDU Network Service Data UnitNPDU Network Protocol Data UnitSNPDU Subnetwork Protocol Data Unit4.2 Protocol Data UnitsESH PDU ISO 9542 End System Hello Protocol DataUnitISH PDU ISO 9542 Intermediate System Hello ProtocolData UnitRD PDU ISO 9542 Redirect Protocol Data UnitIIH Intermediate system to Intermediate systemHello Protocol Data UnitLSP Link State Protocol Data UnitSNP Sequence Numbers Protocol Data UnitCSNP Complete Sequence Numbers Protocol DataUnitPSNP Partial Sequence Numbers Protocol Data Unit4.3 AddressesAFI Authority and Format IndicatorDSP Domain Specific PartIDI Initial Domain IdentifierIDP Initial Domain PartNET Network Entity TitleNSAP Network Service Access PointSNPA Subnetwork Point of Attachment4.4 MiscellaneousDA Dynamically AssignedDED Dynamically Established Data linkDTE Data Terminal EquipmentES End SystemIS Intermediate SystemL1 Level 1L2 Level 2LAN Local Area NetworkMAC Media Access ControlNLPID Network Layer Protocol IdentifierPCI Protocol Control InformationQoS Quality of ServiceSN SubnetworkSNAcP Subnetwork Access ProtocolSNDCP Subnetwork Dependent Convergence ProtocolSNICP Subnetwork Independent Convergence ProtocolSRM Send Routeing MessageSSN Send Sequence Numbers MessageSVC Switched Virtual Circuit5 Typographical ConventionsThis International Standard makes use of the following typographical conventions:a)Important terms and concepts appear in italic typewhen introduced for the first time;b)Protocol constants and management parameters appearin sansSerif type with multiple words run together.The first word is lower case, with the first character ofsubsequent words capitalised;c)Protocol field names appear in San Serif type witheach word capitalised.d)Values of constants, parameters, and protocol fieldsappear enclosed in double quotes.6 Overview of the Protocol6.1 System TypesThere are the following types of system:End Systems: These systems deliver NPDUs to other systems and receive NPDUs from other systems, but donot relay NPDUs. This International Standard doesnot specify any additional End system functions beyond those supplied by ISO 8473 and ISO 9542.Level 1 Intermediate Systems: These systems deliver andreceive NPDUs from other systems, and relayNPDUs from other source systems to other destination systems. They route directly to systems withintheir own area, and route towards a level 2 Intermediate system when the destination system is in a different area.Level 2 Intermediate Systems: These systems act as Level 1Intermediate systems in addition to acting as a system in the subdomain consisting of level 2 ISs. Systems in the level 2 subdomain route towards a destination area, or another routeing domain.6.2 Subnetwork TypesThere are two generic types of subnetworks supported.a)broadcast subnetworks: These are multi-accesssubnetworks that support the capability of addressinga group of attached systems with a single NPDU, forinstance ISO 8802.3 LANs.b)general topology subnetworks: These are modelled asa set of point-to-point links each of which connectsexactly two systems.There are several generic types of general topologysubnetworks:1)multipoint links: These are links between morethan two systems, where one system is a primarysystem, and the remaining systems are secondary(or slave) systems. The primary is capable of directcommunication with any of the secondaries, butthe secondaries cannot communicate directlyamong themselves.2)permanent point-to-point links: These are linksthat stay connected at all times (unless broken, orturned off by system management), for instanceleased lines or private links.3)dynamically established data links (DEDs): theseare links over connection oriented facilities, for instance X.25, X.21, ISDN, or PSTN networks.Dynamically established data links can be used in oneof two ways:i)static point-to-point (Static): The call is established upon system management action andcleared only on system management action (orfailure).ii)dynamically assigned (DA): The call is established upon receipt of traffic, and broughtdown on timer expiration when idle. The address to which the call is to be established isdetermined dynamically from information inthe arriving NPDU(s). No ISIS routeingPDUs are exchanged between ISs on a DA circuit.All subnetwork types are treated by the Subnetwork Independent functions as though they were connectionlesssubnetworks, using the Subnetwork Dependent Convergence functions of ISO 8473 where necessary to provide aconnectionless subnetwork service. The Subnetwork Dependent functions do, however, operate differently onconnectionless and connection-oriented subnetworks.6.3 TopologiesA single organisation may wish to divide its AdministrativeDomain into a number of separate Routeing Domains.This has certain advantages, as described in ISO/TR 9575.Furthermore, it is desirable for an intra-domain routeingprotocol to aid in the operation of an inter-domain routeingprotocol, where such a protocol exists for interconnectingmultiple administrative domains.In order to facilitate the construction of such multi-domaintopologies, provision is made for the entering of staticinter-domain routeing information. This information is provided by a set of Reachable Address Prefixes entered bySystem Management at the ISs which have links whichcross routeing domain boundaries. The prefix indicates thatany NSAPs whose NSAP address matches the prefix maybe reachable via the SNPA with which the prefix is associated. Where the subnetwork to which this SNPA is connected is a general topology subnetwork supporting dynamically established data links, the prefix also has associated with it the required subnetwork addressinginformation, or an indication that it may be derived fromthe destination NSAP address (for example, an X.121 DTEaddress may sometimes be obtained from the IDI of theNSAP address).The Address Prefixes are handled by the level 2 routeing algorithm in the same way as information about a level 1 areawithin the domain. NPDUs with a destination addressmatching any of the prefixes present on any Level 2 Intermediate System within the domain can therefore be relayed(using level 2 routeing) by that IS and delivered out of thedomain. (It is assumed that the routeing functions of theother domain will then be able to deliver the NPDU to itsdestination.)6.4 AddressesWithin a routeing domain that conforms to this standard,the Network entity titles of Intermediate systems shall bestructured as described in 7.1.1.All systems shall be able to generate and forward dataPDUs containing NSAP addresses in any of the formatsspecified by ISO 8348/Add.2. However, NSAP addressesof End systems should be structured as described in 7.1.1 inorder to take full advantage of ISIS routeing. Within sucha domain it is still possible for some End Systems to haveaddresses assigned which do not conform to 7.1.1, providedthey meet the more general requirements ofISO 8348/Add.2, but they may require additional configuration and be subject to inferior routeing performance.6.5 Functional OrganisationThe intra-domain ISIS routeing functions are divided intotwo groups-Subnetwork Independent Functions-Subnetwork Dependent Functions6.5.1 Subnetwork Independent FunctionsThe Subnetwork Independent Functions supply full-duplexNPDU transmission between any pair of neighbour systems. They are independent of the specific subnetwork ordata link service operating below them, except for recognising two generic types of subnetworks:-General Topology Subnetworks, which includeHDLC point-to-point, HDLC multipoint, and dynamically established data links (such as X.25, X.21, andPSTN links), and-Broadcast Subnetworks, which include ISO 8802LANs.The following Subnetwork Independent Functions are identified-Routeing. The routeing function determines NPDUpaths. A path is the sequence of connected systemsand links between a source ES and a destination ES.The combined knowledge of all the Network Layerentities of all the Intermediate systems within a routeing domain is used to ascertain the existence of a path,and route the NPDU to its destination. The routeingcomponent at an Intermediate system has the following specific functions:7It extracts and interprets the routeing PCI in anNPDU.7It performs NPDU forwarding based on the destination address.7It manages the characteristics of the path. If a system or link fails on a path, it finds an alternateroute.7It interfaces with the subnetwork dependent functions to receive reports concerning an SNPAwhich has become unavailable, a system that hasfailed, or the subsequent recovery of an SNPA orsystem.7It informs the ISO 8473 error reporting functionwhen the forwarding function cannot relay anNPDU, for instance when the destination is unreachable or when the NPDU would have neededto be segmented and the NPDU requested no segmentation.-Congestion control. Congestion control manages theresources used at each Intermediate system.6.5.2 Subnetwork Dependent FunctionsThe subnetwork dependent functions mask the characteristics of the subnetwork or data link service from thesubnetwork independent functions. These include:-Operation of the Intermediate system functions ofISO 9542 on the particular subnetwork, in order to7Determine neighbour Network entity title(s) andSNPA address(es)7Determine the SNPA address(s) of operational Intermediate systems-Operation of the requisite Subnetwork DependentConvergence Function as defined in ISO 8473 and itsAddendum 3, in order to perform7Data link initialisation7Hop by hop fragmentation over subnetworks withsmall maximum SNSDU sizes7Call establishment and clearing on dynamically established data links6.6 Design GoalsThis International Standard supports the following designrequirements. The correspondence with the goals for OSIrouteing stated in ISO/TR 9575 are noted.-Network Layer Protocol Compatibility. It is compatible with ISO 8473 and ISO 9542. (See clause 7.5of ISO/TR 9575),-Simple End systems: It requires no changes to endsystems, nor any functions beyond those supplied byISO 8473 and ISO 9542. (See clause 7.2.1 of ISO/TR9575),-Multiple Organisations: It allows for multiple routeing and administrative domains through the provisionof static routeing information at domain boundaries.(See clause 7.3 of ISO/TR 9575),-Deliverability It accepts and delivers NPDUs addressed to reachable destinations and rejects NPDUsaddressed to destinations known to be unreachable.-Adaptability. It adapts to topological changes withinthe routeing domain, but not to traffic changes, exceptpotentially as indicated by local queue lengths. Itsplits traffic load on multiple equivalent paths. (Seeclause 7.7 of ISO/TR 9575),-Promptness. The period of adaptation to topologicalchanges in the domain is a reasonable function of thedomain diameter (that is, the maximum logical distance between End Systems within the domain) andData link speeds. (See clause 7.4 of ISO/TR 9575),-Efficiency. It is both processing and memory efficient. It does not create excessive routeing trafficoverhead. (See clause 7.4 of ISO/TR 9575),-Robustness. It recovers from transient errors such aslost or temporarily incorrect routeing PDUs. It tolerates imprecise parameter settings. (See clause 7.7 ofISO/TR 9575),-Stability. It stabilises in finite time to good routes,provided no continuous topological changes or continuous data base corruptions occur.-System Management control. System Managementcan control many routeing functions via parameterchanges, and inspect parameters, counters, and routes.It will not, however, depend on system managementaction for correct behaviour.-Simplicity. It is sufficiently simple to permit performance tuning and failure isolation.-Maintainability. It provides mechanisms to detect,isolate, and repair most common errors that may affectthe routeing computation and data bases. (See clause7.8 of ISO/TR 9575),-Heterogeneity. It operates over a mixture of networkand system types, communication technologies, andtopologies. It is capable of running over a wide varietyof subnetworks, including, but not limited to: ISO8802 LANs, ISO 8208 and X.25 subnetworks, PSTNnetworks, and the OSI Data Link Service. (See clause7.1 of ISO/TR 9575),-Extensibility. It accommodates increased routeingfunctions, leaving earlier functions as a subset.-Evolution. It allows orderly transition from algorithmto algorithm without shutting down an entire domain.-Deadlock Prevention. The congestion control component prevents buffer deadlock.-Very Large Domains. With hierarchical routeing, anda very large address space, domains of essentially unlimited size can be supported. (See clause 7.2 ofISO/TR 9575),-Area Partition Repair. It permits the utilisation oflevel 2 paths to repair areas which become partitioneddue to failing level 1 links or ISs. (See clause 7.7 ofISO/TR 9575),-Determinism. Routes are a function only of the physical topology, and not of history. In other words, thesame topology will always converge to the same set ofroutes.-Protection from Mis-delivery. The probability ofmis-delivering a NPDU, i.e. delivering it to a Transport entity in the wrong End System, is extremely low.-Availability. For domain topologies with cut setgreater than one, no single point of failure will partition the domain. (See clause 7.7 of ISO/TR 9575),-Service Classes. The service classes of transit delay,expense22Expense is referred to as cost in ISO 8473. The latter term isnot used here because of possible confusion with the more general usageof the term toindicate path cost according to any routeing metric., and residual error probability of ISO 8473are supported through the optional inclusion of multiple routeing metrics.-Authentication. The protocol is capable of carryinginformation to be used for the authentication of Intermediate systems in order to increase the security androbustness of a routeing domain. The specific mechanism supported in this International Standard however, only supports a weak form of authentication using passwords, and thus is useful only for protectionagainst accidental misconfiguration errors and doesnot protect against any serious security threat. In thefuture, the algorithms may be enhanced to providestronger forms of authentication than can be providedwith passwords without needing to change the PDUencoding or the protocol exchange machinery.6.6.1 Non-GoalsThe following are not within the design scope of the intra-domain ISIS routeing protocol described in this International Standard:-Traffic adaptation. It does not automatically modifyroutes based on global traffic load.-Source-destination routeing. It does not determineroutes by source as well as destination.-Guaranteed delivery. It does not guarantee deliveryof all offered NPDUs.-Level 2 Subdomain Partition Repair. It will not utilise Level 1 paths to repair a level 2 subdomain partition. For full logical connectivity to be available, aconnected level 2 subdomain is required.-Equal treatment for all ES Implementations. TheEnd system poll function defined in 8.4.5 presumesthat End systems have implemented the Suggested ESConfiguration Timer option of ISO 9542. An End system which does not implement this option may experience a temporary loss of connectivity following certain types of topology changes on its localsubnetwork.6.7 Environmental RequirementsFor correct operation of the protocol, certain guarantees arerequired from the local environment and the Data LinkLayer.The required local environment guarantees are:a)Resource allocation such that the certain minimum resource guarantees can be met, including1)memory (for code, data, and buffers)2)processing;See 12.2.5 for specific performance levels required forconformanceb)A quota of buffers sufficient to perform routeing functions;c)Access to a timer or notification of specific timer expiration; andd)A very low probability of corrupting data.The required subnetwork guarantees for point-to-point linksare:a)Provision that both source and destination systemscomplete start-up before PDU exchange can occur;b)Detection of remote start-up;c)Provision that no old PDUs be received after start-upis complete;d)Provision that no PDUs transmitted after a particularstartup is complete are delivered out of sequence;e)Provision that failure to deliver a specific subnetworkSDU will result in the timely disconnection of thesubnetwork connection in both directions and that thisfailure will be reported to both systems; andf)Reporting of other subnetwork failures and degradedsubnetwork conditions.The required subnetwork guarantees for broadcast links are:a)Multicast capability, i.e., the ability to address a subsetof all connected systems with a single PDU;b)The following events are low probability, whichmeans that they occur sufficiently rarely so as not toimpact performance, on the order of once per thousand PDUs1)Routeing PDU non-sequentiality,2)Routeing PDU loss due to detected corruption; and3)Receiver overrun;c)The following events are very low probability,which means performance will be impacted unlessthey are extremely rare, on the order of less than oneevent per four years1)Delivery of NPDUs with undetected data corruption; and2)Non-transitive connectivity, i.e. where system Acan receive transmissions from systems B and C,but system B cannot receive transmissions fromsystem C.The following services are assumed to be not availablefrom broadcast links:a)Reporting of failures and degraded subnetwork conditions that result in NPDU loss, for instance receiverfailure. The routeing functions are designed to accountfor these failures.6.8 Functional Organisation ofSubnetwork IndependentComponentsThe Subnetwork Independent Functions are broken downinto more specific functional components. These are described briefly in this sub-clause and in detail in clause 7.This International Standard uses a functional decompositionadapted from the model of routeing presented in clause 5.1of ISO/TR 9575. The decomposition is not identical to thatin ISO/TR 9575, since that model is more general and notspecifically oriented toward a detailed description of intra-domain routeing functions such as supplied by this protocol.The functional decomposition is shown below in figure 2.6.8.1 RouteingThe routeing processes are:-Decision Process-Update ProcessNOTE this comprises both the Information Collectionand Information Distribution components identified inISO/TR 9575.-Forwarding Process-Receive Process6.8.1.1 Decision ProcessThis process calculates routes to each destination in the domain. It is executed separately for level 1 and level 2 routeing, and separately within each level for each of the routeing metrics supported by the Intermediate system. It usesthe Link State Database, which consists of informationfrom the latest Link State PDUs from every other Intermediate system in the area, to compute shortest paths from thisIS to all other systems in the area 9in figure 2. TheLink State Data Base is maintained by the Update Process.Execution of the Decision Process results in the determination of [circuit, neighbour] pairs (known as adjacencies),which are stored in the appropriate Forwarding Informationbase 10 and used by the Forwarding process as pathsalong which to forward NPDUs.Several of the parameters in the routeing data base that theDecision Process uses are determined by the implementation. These include:-maximum number of Intermediate and End systemswithin the IS's area;-maximum number of Intermediate and End systemneighbours of the IS, etc.,so that databases can be sized appropriately. Also parameters such as-routeing metrics for each circuit; and-timerscan be adjusted for enhanced performance. The completelist of System Management set-able parameters is listed inclause 11.6.8.1.2 Update ProcessThis process constructs, receives and propagates Link StatePDUs. Each Link State PDU contains information about theidentity and routeing metric values of the adjacencies ofthe IS that originated the Link State PDU.The Update Process receives Link State and SequenceNumbers PDUs from the Receive Process 4in figure2. It places new routeing information in the routeing information base 6 and propagates routeing information toother Intermediate systems 7and 8 .General characteristics of the Update Process are:-Link State PDUs are generated as a result of topological changes, and also periodically. They may also begenerated indirectly as a result of System Management actions (such as changing one of the routeingmetrics for a circuit).-Level 1 Link State PDUs are propagated to all Intermediate systems within an area, but are not propagated out of an area.-Level 2 Link State PDUs are propagated to all Level 2Intermediate systems in the domain.-Link State PDUs are not propagated outside of a domain.-The update process, through a set of System Management parameters, enforces an upper bound on theamount of routeing traffic overhead it generates.6.8.1.3 Forwarding ProcessThis process supplies and manages the buffers necessary tosupport NPDU relaying to all destinations.It receives, via the Receive Process, ISO 8473 PDUs to beforwarded 5 in figure 2.It performs a lookup in the appropriate33The appropriate ForwardingDatabase is selected by choosing a routeing metric based on fields inthe QoS Maintenance option of ISO 8473. Forwarding Database 11 to determine the possible output adjacenciesto use for forwarding to a given destination, chooses oneadjacency 12, generates error indications to ISO 8473 14 , and signals ISO 9542 to issue Redirect PDUs13.6.8.1.4 Receive ProcessThe Receive Process obtains its inputs from the followingsources-received PDUs with the NPID of Intra-Domain routeing 2 in figure 2,-routeing information derived by the ESIS protocolfrom the receipt of ISO 9542 PDUs 1; and-ISO 8473 data PDUs handed to the routeing functionby the ISO 8473 protocol machine 3.It then performs the appropriate actions, which may involvepassing the PDU to some other function (e.g. to the Forwarding Process for forwarding 5).7 Subnetwork IndependentFunctionsThis clause describes the algorithms and associated databases used by the routeing functions. The managed objectsand attributes defined for System Management purposes aredescribed in clause 11.The following processes and data bases are used internallyby the subnetwork independent functions. Following eachprocess or data base title, in parentheses, is the type of systems which must keep the database. The system types areL2 (level 2 Intermediate system), and L1 (level 1 Intermediate system). Note that a level 2 Intermediate system isalso a level 1 Intermediate system in its home area, so itmust keep level 1 databases as well as level 2 databases.Processes:-Decision Process (L2, L1)-Update Process (L2, L1)-Forwarding Process (L2, L1)-Receive Process (L2, L1)Databases:-Level 1 Link State data base (L2, L1)-Level 2 Link State data base (L2)-Adjacency Database (L2, L1)-Circuit Database (L2, L1)-Level 1 Shortest Paths Database (L2, L1)-Level 2 Shortest Paths Database (L2)-Level 1 Forwarding Databases one per routeingmetric (L2, L1)-Level 2 Forwarding Database one per routeingmetric (L2)7.1 AddressesThe NSAP addresses and NETs of systems are variablelength quantities that conform to the requirements of ISO8348/Add.2. The corresponding NPAI contained in ISO8473 PDUs and in this protocol's PDUs (such as LSPs andIIHs) must use the preferred binary encoding; the underlying syntax for this information may be either abstract binarysyntax or abstract decimal syntax. Any of the AFIs andtheir corresponding DSP syntax may be used with this protocol.7.1.1 NPAI Of Systems Within A RouteingDomainFigure 3 illustrates the structure of an encoded NSAP address or NET.The structure of the NPAI will be interpreted in the following way by the protocol described in this international standard:Area Addressaddress of one area within a routeing domain avariable length quantity consisting of the entire high-order part of the NPAI, excluding the ID and SELfields, defined below.ID System identifier a variable length field from 1 to8 octets (inclusive). Each routeing domain employing this protocol shall select a single size for the IDfield and all Intermediate systems in the routeing domain shall use this length for the system IDs of allsystems in the routeing domain. The set of ID lengths supported by an implementation is an implementation choice, provided that atleast one value in the permitted range can be accepted. The routeing domain administrator must ensure that all ISs included in a routeing domain areable to use the ID length chosen for that domain.SEL NSAP Selector a 1-octet field which acts as a selector for the entity which is to receive the PDU(thismay be a Transport entity or the Intermediate systemNetwork entity itself). It is the least significant (last)octet of the NPAI.7.1.2 Deployment of SystemsFor correct operation of the routeing protocol defined inthis international standard, systems deployed in a routeingdomain must meet the following requirements:a)For all systems:1)Each system in an area must have a unique systemID: that is, no two systems (IS or ES) in anarea can use the same ID value.2)Each area address must be unique within the globalOSIE: that is, a given area address can be associated with only one area.3)All systems having a given value of area addressmust be located in the same area.b)Additional Requirements for Intermediate systems:1)Each Level 2 Intermediate system within a routeing domain must have a unique value for its IDfield: that is, no two level 2 ISs in a routeing domain can have the same value in their ID fields.c)Additional Requirements for End systems:1)No two End systems in an area may have addresses that match in all but the SEL fields.d)An End system can be attached to a level 1 IS only ifits area address matches one of the entries in the adjacent IS's manual
Area
Addresses parameter.It is the responsibility of the routeing domain's administrative authority to enforce the requirements of 7.1.2. The protocol defined in this international standard assumes thatthese requirements are met, but has no means to verifycompliance with them.7.1.3 Manual area addressesThe use of several synonymous area addresses by an IS isaccommodated through the use of the management parameter manual
Area
Addresses. This parameter is set locallyfor each level 1 IS by system management; it contains a listof all synonymous area addresses associated with the IS, including the IS's area address as contained in its own NET.Each level 1 IS distributes its manual
Area
Addresses inits Level 1 LSP's Area Addresses field, thus allowinglevel 2 ISs to create a composite list of all area addressessupported within a given area. Level 2 ISs in turn advertisethe composite list throughout the level 2 subdomain by including it in their Level 2 LSP's Area Addresses field,thus distributing information on all the area addresses associated with the entire routeing domain. The procedures forestablishing an adjacency between two level 1 ISs requirethat there be at least one area address in common betweentheir two manual
Area
Addresses lists, and the procedures for establishing an adjacency between a level 1 Is andan End system require that the End system's area addressmust match an entry in the IS's manual
Area
Addresseslist. Therefore, it is the responsibility of System Management to ensure that each area address associated with an ISis included: in particular, system management must ensurethat the area addresses of all ESs and Level 1 ISs adjacentto a given level 1 IS are included in that IS's manual
Area
Addresses list.If the area address field for the destination address of an8473 PDUor for the next entry in its source routeingfield, when present is not listed in the parameter area
Addresses of a level 1 IS receiving the PDU, then thedestination system does not reside in the IS's area. SuchPDUs will be routed by level-2 routeing.7.1.4 Encoding of Level 2 AddressesWhen a full NSAP address is encoded according to the preferred binary encoding specified in ISO 8348/Add.2, theIDI is padded with leading digits (if necessary) to obtain themaximum IDP length specified for that AFI.A Level 2 address prefix consists of a leading sub-string ofa full NSAP address, such that it matches a set of fullNSAP addresses that have the same leading sub-string.However this truncation and matching is performed on theNSAP represented by the abstract syntax of the NSAP address, not on the encoded (and hence padded) form.11An example ofprefix matching may be found in annex B, clause B.1.Level 2 address prefixes are encoded in LSPs in the sameway as full NSAP addresses, except when the end of theprefix falls within the IDP. In this case the prefix is directlyencoded as the string of semi-octets with no padding.7.1.5 Comparison of AddressesUnless otherwise stated, numerical comparison of addressesshall be performed on the encoded form of the address, bypadding the shorter address with trailing zeros to the lengthof the longer address, and then performing a numericalcomparison.The addresses to which this precedure applies includeNSAP addresses, Network Entity Titles, and SNPA addresses.7.2 The Decision ProcessThis process uses the database of Link State information tocalculate the forwarding database(s), from which the forwarding process can know the proper next hop for eachNPDU. The Level 1 Link State Database is used for calculating the Level 1 Forwarding Database(s), and the Level 2Link State Database is used for calculating the Level 2 Forwarding Database(s).7.2.1 Input and outputINPUT-Link State Database This database is a set of information from the latest Link State PDUs from allknown Intermediate systems (within this area, forLevel 1, or within the level 2 subdomain, for Level 2).This database is received from the Update Process.-Notification of an Event This is a signal from theUpdate Process that a change to a link has occurredsomewhere in the domain. OUTPUT-Level 1 Forwarding Databases one per routeingmetric-(Level 2 Intermediate systems only) Level 2 Forwarding Databases one per routeing metric-(Level 2 Intermediate systems only) The Level 1 Decision Process informs the Level 2 Update Process ofthe ID of the Level 2 Intermediate system within thearea with lowest ID reachable with real level 1 links(as opposed to a virtual link consisting of a paththrough the level 2 subdomain)-(Level 2 Intermediate systems only) If this Intermediate system is the Partition Designated Level 2 Intermediate system in this partition, the Level 2 DecisionProcess informs the Level 1 Update Process of thevalues of the default routeing metric to and ID of thepartition designated level 2 Intermediate system ineach other partition of this area.7.2.2 Routeing metricsThere are four routeing metrics defined, corresponding tothe four possible orthogonal qualities of service defined bythe QoS Maintenance field of ISO 8473. Each circuit emanating from an Intermediate system shall be assigned avalue for one or more of these metrics by System management. The four metrics are as follows:a)Default metric: This is a metric understood by everyIntermediate system in the domain. Each circuit shallhave a positive integral value assigned for this metric.The value may be associated with any objective function of the circuit, but by convention is intended tomeasure the capacity of the circuit for handling traffic,for example, its throughput in bits-per-second. Highervalues indicate a lower capacity.b)Delay metric: This metric measures the transit delayof the associated circuit. It is an optional metric, whichif assigned to a circuit shall have a positive integralvalue. Higher values indicate a longer transit delay.c)Expense metric: This metric measures the monetarycost of utilising the associated circuit. It is an optionalmetric, which if assigned to a circuit shall have a positive integral value22The path computation algorithm utilised in thisInternational Standard requires that all circuits be assigned apositive value for a metric. Therefore, it isnot possible to represent a free circuit by a zero value of the expensemetric. By convention, the value 1 is used to indicate a free circuit.. Higher values indicate a largermonetary expense.d)Error metric: This metric measures the residual errorprobability of the associated circuit. It is an optionalmetric, which if assigned to a circuit shall have a non-zero value. Higher values indicate a larger probabilityof undetected errors on the circuit.NOTE - The decision process combines metric values bysimple addition. It is important, therefore, that the values ofthe metrics be chosen accordingly.Every Intermediate system shall be capable of calculatingroutes based on the default metric. Support of any or all ofthe other metrics is optional. If an Intermediate system supports the calculation of routes based on a metric, its updateprocess may report the metric value in the LSPs for the associated circuit; otherwise, the IS shall not report the metric.When calculating paths for one of the optional routeingmetrics, the decision process only utilises LSPs with avalue reported for the corresponding metric. If no value isassociated with a metric for any of the IS's circuits the system shall not calculate routes based on that metric.NOTE - A consequence of the above is that a system reachable via the default metric may not be reachable by anothermetric.See 7.4.2 for a description of how the forwarding processselects one of these metrics based on the contents of theISO 8473 QoS Maintenance option.Each of the four metrics described above may be of twotypes: an Internal metric or an External metric. Internalmetrics are used to describe links/routes to destinations internal to the routeing domain. External metrics are used todescribe links/routes to destinations outside of the routeingdomain. These two types of metrics are not directly comparable, except the internal routes are always preferred overexternal routes. In other words an internal route will alwaysbe selected even if an external route with lower total costexists.7.2.3 Broadcast SubnetworksInstead of treating a broadcast subnetwork as a fully connected topology, the broadcast subnetwork is treated as apseudonode, with links to each attached system. Attachedsystems shall only report their link to the pseudonode. Thedesignated Intermediate system, on behalf of thepseudonode, shall construct Link State PDUs reporting thelinks to all the systems on the broadcast subnetwork with azero value for each supported routeing metric33They are set to zerometric values since they have already been assigned metrics by thelink to the pseudonode. Assigning a non-zero value in thepseudonode LSP would have the effect of doubling the actual value..The pseudonode shall be identified by the sourceID of theDesignated Intermediate system, followed by a non-zeropseudonodeID assigned by the Designated Intermediatesystem. The pseudonodeID is locally unique to the Designated Intermediate system.Designated Intermediate systems are determined separatelyfor level 1 and level 2. They are known as the LAN Level 1Designated IS and the LAN Level 2 Designated IS respectively. See 8.4.4.An Intermediate system may resign as Designated Intermediate System on a broadcast circuit either because it (or it'sSNPA on the broadcast subnetwork) is being shut down orbecause some other Intermediate system of higher priorityhas taken over that function. When an Intermediate systemresigns as Designated Intermediate System, it shall initiate anetwork wide purge of its pseudonode Link State PDU(s)by setting their Remaining Lifetime to zero and performingthe actions described in 7.3.16.4. A LAN Level 1 Designated Intermediate System purges Level 1 Link State PDUsand a LAN Level 2 Designated Intermediate System purgesLevel 2 Link State PDUs. An Intermediate system whichhas resigned as both Level 1 and Level 2 Designated Intermediate System shall purge both sets of LSPs.When an Intermediate system declares itself as designatedIntermediate system and it is in possession of a Link StatePDU of the same level issued by the previous DesignatedIntermediate System for that circuit (if any), it shall initiatea network wide purge of that (or those) Link State PDU(s)as above.7.2.4 LinksTwo Intermediate systems are not considered neighboursunless each reports the other as directly reachable over oneof their SNPAs. On a Connection-oriented subnetwork(either point-to-point or general topology), the two Intermediate systems in question shall ascertain their neighbour relationship when a connection is established and hello PDUsexchanged. A malfunctioning IS might, however, report another IS to be a neighbour when in fact it is not. To detectthis class of failure the decision process checks that eachlink reported as up in a LSP is so reported by both Intermediate systems. If an Intermediate system considers a linkdown it shall not mention the link in its Link State PDUs.On broadcast subnetworks, this class of failure shall be detected by the designated IS, which has the responsibility toascertain the set of Intermediate systems that can all communicate on the subnetwork. The designated IS shall include these Intermediate systems (and no others) in theLink State PDU it generates for the pseudonode representing the broadcast subnetwork.7.2.5 Multiple LSPs for the same systemThe Update process is capable of dividing a single logicalLSP into a number of separate PDUs for the purpose ofconserving link bandwidth and processing (see 7.3.4). TheDecision Process, on the other hand, shall regard the LSPwith LSP Number zero in a special way. If the LSP withLSP Number zero and remaining lifetime > 0, is not presentfor a particular system then the Decision Process shall notprocess any LSPs with non-zero LSP Number which maybe stored for that system.The following information shall be taken only from the LSPwith LSP Number zero. Any values which may be presentin other LSPs for that system shall be disregarded by theDecision Process.a)The setting of the LSP Database Overload bit.b)The value of the IS Type field.c)The Area Addresses option.7.2.6 Routeing Algorithm OverviewThe routeing algorithm used by the Decision Process is ashortest path first (SPF) algorithm. Instances of the algorithm are run independently and concurrently by all Intermediate systems in a routeing domain. Intra-Domain routeing of a PDU occurs on a hop-by-hop basis: that is, the algorithm determines only the next hop, not the completepath, that a data PDU will take to reach its destination. Toguarantee correct and consistent route computation byevery Intermediate system in a routeing domain, this International Standard depends on the following properties:a)All Intermediate systems in the routeing domain converge to using identical topology information; andb)Each Intermediate system in the routeing domain generates the same set of routes from the same input topology and set of metrics.The first property is necessary in order to prevent inconsistent, potentially looping paths. The second property is necessary to meet the goal of determinism stated in 6.6.A system executes the SPF algorithm to find a set of legalpaths to a destination system in the routeing domain. Theset may consist of:a)a single path of minimum metric sum: these aretermed minimum cost paths;b)a set of paths of equal minimum metric sum: these aretermed equal minimum cost paths; orc)a set of paths which will get a PDU closer to its destination than the local system: these are called downstream paths.Paths which do not meet the above conditions are illegaland shall not be used.The Decision Process, in determining its paths, also ascertains the identity of the adjacency which lies on the firsthop to the destination on each path. These adjacencies areused to form the Forwarding Database, which the forwarding process uses for relaying PDUs.Separate route calculations are made for each pairing of alevel in the routeing hierarchy (i.e. L1 and L2) with a supported routeing metric. Since there are four routeing metricsand two levels some systems may execute multiple instances of the SPF algorithm. For example,-if an IS is a L2 Intermediate system which supports allfour metrics and computes minimum cost paths for allmetrics, it would execute the SPF calculation eighttimes.-if an IS is a L1 Intermediate system which supports allfour metrics, and additionally computes downstreampaths, it would execute the algorithm 4 W (number ofneighbours + 1) times.Any implementation of an SPF algorithm meeting both thestatic and dynamic conformance requirements of clause 12of this International Standard may be used. Recommendedimplementations are described in detail in Annex C.7.2.7 Removal of Excess PathsWhen there are more than max
i
mum
Path
Splits legalpaths to a destination, this set shall be pruned until onlymax
i
mum
Path
Splits remain. The Intermediate systemshall discriminate based upon:NOTE - The precise precedence among the paths is specified in order to meet the goal of determinism defined in 6.6.-adjacency type: Paths associated with End system orlevel 2 reachable address prefix adjacencies are retained in preference to other adjacencies-metric sum: Paths having a lesser metric sum are retained in preference to paths having a greater metricsum. By metric sum is understood the sum of themetrics along the path to the destination.-neighbour ID: where two or more paths are associated with adjacencies of the same type, an adjacencywith a lower neighbour ID is retained in preference toan adjacency with a higher neighbour id.-circuit ID: where two or more paths are associatedwith adjacencies of the same type, and same neighbour ID, an adjacency with a lower circuit ID is retained in preference to an adjacency with a higher circuit ID, where circuit ID is the value of:7ptPtCircuitID for non-broadcast circuits,7l1CircuitID for broadcast circuits when runningthe Level 1 Decision Process, and7l2CircuitID for broadcast circuits when runningthe Level 2 Decision Process.-lANAddress: where two or more adjacencies are ofthe same type, same neighbour ID, and same circuitID (e.g. a system with multiple LAN adapters on thesame circuit) an adjacency with a lower lANAddressis retained in preference to an adjacency with a higherlANAddress.7.2.8 Robustness Checks7.2.8.1 Computing Routes through OverloadedIntermediate systemsThe Decision Process shall not utilise a link to an Intermediate system neighbour from an IS whose LSPs have theLSP Database Overload indication set. Such paths may introduce loops since the overloaded IS does not have a complete routeing information base. The Decision Process shall,however utilise the link to reach End system neighbourssince these paths are guaranteed to be non-looping.7.2.8.2 Two-way connectivity checkThe Decision Process shall not utilise a link between twoIntermediate Systems unless both ISs report the link.NOTE - the check is not applicable to links to an End System.Reporting the link indicates that it has a defined value for atleast the default routeing metric. It is permissible for twoendpoints to report different defined values of the samemetric for the same link. In this case, routes may be asymmetric.7.2.9 Construction of a Forwarding DatabaseThe information that is needed in the forwarding databasefor routeing metric k is the set of adjacencies for each system N.7.2.9.1 Identification of Nearest Level 2 IS by aLevel 1 ISLevel 1 Intermediate systems need one additional piece ofinformation per routeing metric: the next hop to the nearestlevel 2 Intermediate system according to that routeing metric. A level 1 IS shall ascertain the set, R, of attachedlevel 2 Intermediate system(s) for metric k such that the total cost to R for metric k is minimal.If there are more adjacencies in this set than max
i
mum
Path
Splits, then the IS shall remove excess adjacencies asdescribed in 7.2.7.7.2.9.2 Setting the Attached Flag in Level 2Intermediate SystemsIf a level 2 Intermediate system discovers, after computingthe level 2 routes for metric k, that it cannot reach any otherareas using that metric, it shall:-set AttachedFlag for metric k to False;-regenerate its Level 1 LSP with LSP number zero; and-compute the nearest level 2 Intermediate system formetric k for insertion in the appropriate forwardingdatabase, according to the algorithm described in7.2.9.1 for level 1 Intermediate systems.NOTE - AttachedFlag for each metric k is examined by theUpdate Process, so that it will report the value in the ATTfield of its Link State PDUs.If a level 2 Intermediate system discovers, after computingthe level 2 routes for metric k, that it can reach at least oneother area using that metric, it shall-set AttachedFlag for metric k to True;-regenerate its Level 1 LSP with LSP number zero; and-set the level 1 forwarding database entry for metric kwhich corresponds to nearest level 2 Intermediatesystem to Self.7.2.10 Information for Repairing PartitionedAreasAn area may become partitioned as a result of failure of oneor more links in the area. However, if each of the partitionshas a connection to the level 2 subdomain, it is possible torepair the partition via the level 2 subdomain, provided thatthe level 2 subdomain itself is not partitioned. This is illustrated in Figure 4.All the systems A I, R and P are in the same area n.When the link between D and E is broken, the area becomes partitioned. Within each of the partitions the Partition Designated Level 2 Intermediate system is selectedfrom among the level 2 Intermediate systems in that partition. In the case of partition 1 this is P, and in the case ofpartition 2 this is R. The level 1 repair path is then established between between these two level 2 Intermediate systems. Note that the repaired link is now between P and R,not between D and E.The Partition Designated Level 2 Intermediate Systems repair the partition by forwarding NPDUs destined for otherpartitions of the area through the level 2 subdomain. Theydo this by acting in their capacity as Level 1 IntermediateSystems and advertising in their Level 1 LSPs adjacenciesto each Partition Designated Level 2 Intermediate Systemin the area. This adjacency is known as a Virtual Adjacency or Virtual Link. Thus other Level 1 IntermediateSystems in a partition calculate paths to the other partitionsthrough the Partition Designated Level 2 Intermediate System. A Partition Designated Level 2 Intermediate Systemforwards the Level 1 NPDUs through the level 2 subdomainby encapsulating them in 8473 Data NPDUs with its VirtualNetwork Entity Title as the source NSAP and the adjacent Partition Designated Level 2 Intermediate System'sVirtual Network Entity Title as the destination NSAP. Thefollowing sub-clauses describe this in more detail.7.2.10.1 Partition Detection and Virtual Level 1Link CreationPartitions of a Level 1 area are detected by the Level 2 Intermediate System(s) operating within the area. In order toparticipate in the partition repair process, these Level 2 Intermediate systems must also act as Level 1 Intermediatesystems in the area. A partition of a given area exists whenever two or more Level 2 ISs located in that area are reported in the L2 LSPs as being a Partition DesignatedLevel 2 IS. Conversely, when only one Level 2 IS in anarea is reported as being the Partition Designated Level 2IS, then that area is not partitioned. Partition repair is accomplished by the Partition Designated Level 2 IS. Theelection of the Partition Designated Level 2 IS as describedin the next subsection must be done before the detectionand repair process can begin.In order to repair a partition of a Level 1 area, the Partitiondesignated Level 2 IS creates a Virtual Network Entity torepresent the partition. The Network Entity Title for thisvirtual network entity shall be constructed from the firstlisted area address from its Level 2 Link State PDU, and theID of the Partition Designated Level 2 IS. The IS shall alsoconstruct a virtual link (represented by a new Virtual Adjacency managed object) to each Partition Designated Level 2IS in the area, with the NET of the partition recorded in theIdentifier attribute. The virtual links are the repair paths forthe partition. They are reported by the Partition DesignatedLevel 2 IS into the entire Level 1 area by adding the ID ofeach adjacent Partition Designated Level 2 IS to the Intermediate System Neighbours field of its Level 1 LinkState PDU. The Virtual Flag shall be set True for theseIntermediate System neighbours. The metric value for thisvirtual link shall be the default metric value d(N) obtainedfrom this system's Level 2 PATHS database, where N is theadjacent Partition Designated Level 2 IS via the Level 2subdomain.An Intermediate System which operates as the PartitionDesignated Level 2 Intermediate System shall perform thefollowing steps after completing the Level 2 shortest pathcomputation in order to detect partitions in the Level 1 areaand create repair paths:a)Examine Level 2 Link State PDUs of all Level 2 Intermediate systems. Search area
Addresses for any address that matches any of the addresses in partition
Area
Addresses. If a match is found, and the Partition Designated Level 2 Intermediate system's IDdoes not equal this system's ID, then inform the level1 update process at this system of the identity of thePartition Designated Level 2 Intermediate system, together with the path cost for the default routeing metric to that Intermediate system.b)Continue examining Level 2 LSPs until all PartitionDesignated Level 2 Intermediate systems in other partitions of this area are found, and inform the Level 1Update Process of all of the other Partition DesignatedLevel 2 Intermediate systems in other partitions of thisarea, so that1)Level 1 Link State PDUs can be propagated to allother Partition designated level 2 Intermediate systems for this area (via the level 2 subdomain).2)All the Partition Designated Level 2 Intermediatesystems for other partitions of this area can be reported as adjacencies in this system's Level 1 LinkState PDUs.If a partition has healed, the IS shall destroy the associatedvirtual network entity and virtual link by deleting the Virtual Adjacency. The Partition Designated Level 2 IS detects a healed partition when another Partition DesignatedLevel 2 IS listed as a virtual link in its Level 1 Link StatePDU was not found after running the partition detection andvirtual link creation algorithm described above.If such a Virtual Adjacency is created or destroyed, the ISshall generate a partitionVirtualLinkChange notification.7.2.10.2 Election of Partition Designated Level 2Intermediate System The Partition Designated Level 2 IS is a Level 2 IS which:-reports itself as attached by the default metric in itsLSPs;-reports itself as implementing the partition repair option;-operates as a Level 1 IS in the area;-is reachable via Level 1 routeing without traversingany virtual links; and-has the lowest IDThe election of the Partition Designated Level 2 IS is performed by running the decision process algorithm after theLevel 1 decision process has finished, and before theLevel 2 decision process to determine Level 2 paths is executed.In order to guarantee that the correct Partition DesignatedLevel 2 IS is elected, the decision process is run using onlythe Level 1 LSPs for the area, and by examining only theIntermediate System Neighbours whose Virtual Flag isFALSE. The results of this decision process is a set of allthe Level 1 Intermediate Systems in the area that can bereached via Level 1, non-virtual link routeing. From thisset, the Partition Designated Level 2 IS is selected bychoosing the IS for which-IS Type (as reported in the Level 1 LSP) is Level 2Intermediate System;-ATT indicates attached by the default metric;-P indicates support for the partition repair option; and-ID is the lowest among the subset of attached Level 2Intermediate Systems.7.2.10.3 Computation of Partition area addressesA Level 2 Intermediate System shall compute the set ofpartition
Area
Addresses, which is the union of allmanual
area
Addresses as reported in the Level 1 LinkState PDUs of all Level 2 Intermediate systems reachable inthe partition by the traversal of non-virtual links. If morethan max
i
mum
Area
Addresses are present, the Intermediate system shall retain only those areas with numericallylowest area address (as described in 7.1.5). If one of the local system's manual
Area
Addresses is so rejected thenotification manualAddressDroppedFromArea shall begenerated.7.2.10.4 Encapsulation of NPDUs Across theVirtual LinkAll NPDUs sent over virtual links shall be encapsulated asISO 8473 Data NPDUs. The encapsulating Data NPDUshall contain the Virtual Network Entity Title of the Partition Designated Level 2 IS that is forwarding the NPDUover the virtual link in the Source Address field, and theVirtual NET of the adjacent Partition Designated Level 2IS in the Destination Address field. The SEL field inboth NSAPs shall contain the IS-IS routeing selectorvalue. The QoS Maintenance field of the outer PDU shallbe set to indicate forwarding via the default routeing metric(see table 1 on page 32).For Data and Error Report NPDUs the SegmentationPermitted and Error Report flags and the Lifetime fieldof the outer NPDU shall be copied from the inner NPDU.When the inner NPDU is decapsulated, its Lifetime fieldshall be set to the value of the Lifetime field in the outerNPDU.For LSPs and SNPs the Segmentation Permitted flagshall be set to True and the Error Report flag shall be setto False. The Lifetime field shall be set to 255. When aninner LSP is decapsulated, its remaining lifetime shall bedecremented by half the difference between 255 and thevalue of the Lifetime field in the outer NPDU.Data NPDUs shall not be fragmented before encapsulation,unless the total length of the Data NPDU (including header)exceeds 65535 octets. In that case, the original Data NPDUshall first be fragmented, then encapsulated. In all cases,the encapsulated Data NPDU may need to be fragmentedby ISO 8473 before transmission in which case it must bereassembled and decapsulated by the destination PartitionDesignated Level 2 IS. The encapsulation is further described as part of the forwarding process in 7.4.3.2. Thedecapsulation is described as part of the Receive process in7.4.4.7.2.11 Computation of area addressesA Level 1 or Level 2 Intermediate System shall computethe values of area
Addresses (the set of area addressesfor this Level 1 area), by forming the union of the sets ofmanual
area
Addresses reported in the Area Addressesfield of all Level 1 LSPs with LSP number zero in the localIntermediate system's link state database.NOTE - This includes all source systems, whether currentlyreachable or not. It also includes the local Intermediate system's own Level 1 LSP with LSP number zero.NOTE - There is no requirement for this set to be updatedimmediately on each change to the database contents. It ispermitted to defer the computation until the next running ofthe Decision Process.If more than max
i
mum
Area
Addresses are present, theIntermediate system shall retain only those areas with numerically lowest area address (as described in 7.1.5). If oneof the local system's manual
area
Addresses is rejectedthe notification manual
Address
Dropped
From
Area shallbe generated.7.2.12 Order of Preference of RoutesIf an Intermediate system takes part in level 1 routeing, anddetermines (by looking at the area address) that a given destination is reachable within its area, then that destinationwill be reached exclusively by use of level 1 routeing. Inparticular:a)Level 1 routeing is always based on internal metrics.b)Amongst routes in the area, routes on which the requested QoS (if any) is supported are always preferredto routes on which the requested QoS is not supported.c)Amongst routes in the area of the same QoS, the shortest routes are preferred. For determination of theshortest path, if a route with specific QoS support isavailable, then the specified QoS metric is used, otherwise the default metric is used.d)Amongst routes of equal cost, load splitting may beperformed.If an Intermediate system takes part in level 1 routeing,does not take part in level 2 routeing, and determines (bylooking at the area address) that a given destination is notreachable within its area, and at least one attached level 2IS is reachable in the area, then that destination will bereached by routeing to a level 2 Intermediate system as follows:a)Level 1 routeing is always based on internal metrics.b)Amongst routes in the area to attached level 2 ISs,routes on which the requested QoS (if any) is supported are always preferred to routes on which the requested QoS is not supported.c)Amongst routes in the area of the same QoS to attached level 2 ISs, the shortest route is preferred. Fordetermination of the shortest path, if a route on whichthe specified QoS is available, then the specified QoSmetric is used, otherwise the default metric is used.d)Amongst routes of equal cost, load splitting may beperformed.If an Intermediate system takes part in level 2 routeing andis attached, and the IS determines (by looking at the areaaddress) that a given destination is not reachable within itsarea, then that destination will be reached as follows:a)Routes on which the requested QoS (if any) is supported are always preferred to routes on which the requested QoS is not supported.b)Amongst routes of the same QoS, routes are prioritised as follows:1)Highest precedence: routes matching the area address of any area in the routeing domain2)Medium precedence: Routes matching a reachableaddress prefix with an internal metric. For destinations matching multiple reachable address prefixentries all with internal metrics, the longest prefixshall be preferred.3)Lowest precedence: Routes matching a reachableaddress prefix with an external metric. For destinations matching multiple reachable address prefixentries all with external metrics, the longest prefixshall be preferred.c)For routes with equal precedence as specified above,the shortest path shall be preferred. For determinationof the shortest path, a route supporting the specifiedQoS is used if available; otherwise a route using thedefault metric shall be used. Amongst routes of equalcost, load splitting may be performed.7.3 The Update ProcessThe Update Process is responsible for generating andpropagating Link State information reliably throughout therouteing domain.The Link State information is used by the Decision Processto calculate routes.7.3.1 Input and OutputINPUT-Adjacency Database maintained by the SubnetworkDependent Functions-Reachable Address managed objects - maintained bySystem Management-Notification of Adjacency Database Change notification by the Subnetwork Dependent Functions thatan adjacency has come up, gone down, or changedcost. (Circuit up, Circuit down, Adjacency Up, Adjacency Down, and Cost change events)-AttachedFlag (level 2 Intermediate systems only),a flag computed by the Level 2 Decision Process indicating whether this system can reach (via level 2routeing) other areas-Link State PDUs The Receive Process passes LinkState PDUs to the Update Process, along with an indication of which adjacency it was received on.-Sequence Numbers PDUs The Receive Processpasses Sequence Numbers PDUs to the Update Process, along with an indication of which adjacency itwas received on.-Other Partitions The Level 2 Decision Processmakes available (to the Level 1 Update Process on aLevel 2 Intermediate system) a list of aPartition Designated Level 2 Intermediate system, Level 2 defaultmetric valueq pairs, for other partitions of this area. OUTPUT-Link State Database-Signal to the Decision Process of an event, which iseither the receipt of a Link State PDU with differentinformation from the stored one, or the purging of aLink State PDU from the database. The reception of aLink State PDU which has a different sequence number or Remaining Lifetime from one already stored inthe database, but has an identical variable length portion, shall not cause such an event.NOTE - An implementation may compare the checksum ofthe stored Link State PDU, modified according to thechange in sequence number, with the checksum of the received Link State PDU. If they differ, it may assume that thevariable length portions are different and an event signalledto the Decision Process. However, if the checksums are thesame, an octet for octet comparison must be made in orderto determine whether or not to signal the event.7.3.2 Generation of Local Link StateInformationThe Update Process is responsible for constructing a set ofLink State PDUs. The purpose of these Link State PDUs isto inform all the other Intermediate systems (in the area, inthe case of Level 1, or in the Level 2 subdomain, in the caseof Level 2), of the state of the links between the Intermediate system that generated the PDUs and its neighbours.The Update Process in an Intermediate system shall generate one or more new Link State PDUs under the followingcircumstances:a)upon timer expiration;b)when notified by the Subnetwork Dependent Functions of an Adjacency Database Change;c)when a change to some Network Management characteristic would cause the information in the LSP tochange (for example, a change in manual
area
Addresses).7.3.3 Use of Manual Routeing InformationManual routeing information is routeing information entered by system management. It may be specified in twoforms.a)Manual Adjacenciesb)Reachable AddressesThese are described in the following sub-clauses.7.3.3.1 Manual AdjacenciesAn End system adjacency may be created by System Management. Such an adjacency is termed a manual End system adjacency. In order to create a manual End system adjacency, system managements shall specify:a)the (set of) system IDs reachable over that adjacency;andb)the corresponding SNPA Address. These adjacencies shall appear as adjacencies with typeManual, neighbourSystemType End system andstate Up. Such adjacencies provide input to the UpdateProcess in a similar way to adjacencies created through theoperation of ISO 9542. When the state changes to Up theadjacency information is included in the Intermediate System's own Level 1 LSPs.NOTE - Manual End system adjacencies shall not be included in a Level 1 LSPs issued on behalf of a pseudonode,since that would presuppose that all Intermediate systems ona broadcast subnetwork had the same set of manual adjacencies as defined for this circuit.Metrics assigned to Manual adjacencies must be Internalmetrics.7.3.3.2 Reachable AddressesA Level 2 Intermediate system may have a number ofReachable Address managed objects created by Systemmanagement. When a Reachable Address is in state Onand its parent Circuit is also in state On, the name andeach of its defined routeing metrics shall be included inLevel 2 LSPs generated by this system.Metrics assigned to Reachable Address managed objectsmay be either Internal or External.A reachable address is considered to be active when allthe following conditions are true:a)The parent circuit is in state On;b)the Reachable Address is in state On; andc)the parent circuit is of type broadcast or is in data linkstate Running.Whenever a reachable address changes from being inactive to active a signal shall be generated to the Updateprocess to cause it to include the Address Prefix of thereachable address in the Level 2 LSPs generated by thatsystem as described in 7.3.9.Whenever a reachable address changes from being activeto inactive, a signal shall be generated to the Updateprocess to cause it to cease including the Address Prefix ofthe reachable address in the Level 2 LSPs.7.3.4 Multiple LSPsBecause a Link State PDU is limited in size to Receive
LSP
Buffer
Size, it may not be possible to include information about all of a system's neighbours in a single LSP.In such cases, a system may use multiple LSPs to conveythis information. Each LSP in the set carries the samesourceID field (see clause 9), but sets its own LSP Number field individually. Each of the several LSPs is handledindependently by the Update Process, thus allowing distribution of topology updates to be pipelined. However, theDecision Process recognises that they all pertain to a common originating system because they all use the samesourceID.NOTE - Even if the amount of information is small enoughto fit in a single LSP, a system may optionally choose to useseveral LSPs to convey it; use of a single LSP in this situation is not mandatory.NOTE - In order to minimise the transmission of redundantinformation, it is advisable for an IS to group ReachableAddress Prefix information by the circuit with which it is associated. Doing so will ensure that the minimum number ofLSP fragments need be transmitted if a circuit to anotherrouteing domain changes state.The maximum sized Level 1 or Level 2 LSP which may begenerated by a system is controlled by the values of themanagement parameters originating
L1
LSP
Buf
fer
Size orori
ginat
ing
L2
LSP
Buffer
Size respectively.NOTE - These parameters should be set consistently by system management. If this is not done, some adjacencies willfail to initialise.The IS shall treat the LSP with LSP Number zero in a special way, as follows:a)The following fields are meaningful to the decisionprocess only when they are present in the LSP withLSP Number zero:1)The setting of the LSP Database Overload bit.2)The value of the IS Type field.3)The Area Addresses option. (This is only presentin the LSP with LSP Number zero, see below).b)When the values of any of the above items arechanged, an Intermediate System shall re-issue theLSP with LSP Number zero, to inform other Intermediate Systems of the change. Other LSPs need not bereissued.Once a particular adjacency has been assigned to a particular LSP Number, it is desirable that it not be moved to another LSP Number. This is because moving an adjacencyfrom one LSP to another can cause temporary loss ofconnectivity to that system. This can occur if the new version of the LSP which originally contained informationabout the adjacency (which now does not contain that information) is propagated before the new version of the otherLSP (which now contains the information about the adjacency). In order to minimise the impact of this, the following restrictions are placed on the assignment of informationto LSPs.a)The Area Addresses option field shall occur only inthe LSP with LSP Number zero.b)Intermediate System Neighbours options shall occurafter the Area Addresses option and before any EndSystem (or in the case of Level 2, Prefix) Neighbours options.c)End System (or Prefix) Neighbour options (if any)shall occur after any Area Address or IntermediateSystem Neighbour options.NOTE In this context, after means at a higher octetnumber from the start of the same LSP or in an LSP witha higher LSP Number.NOTE An implementation is recommended to ensurethat the number of LSPs generated for a particular systemis within approximately 10% of the optimal numberwhich would be required if all LSPs were densely packedwith neighbour options. Where possible this should beaccomplished by re-using space in LSPs with a lowerLSP Number for new adjacencies. If it is necessary tomove an adjacency from one LSP to another, theSRMflags (see 7.3.15) for the two new LSPs shall beset as an atomic action.44If the two SRMflags are not set atomically, arace condition will exist in which one of the two LSPs may bepropagated quickly, while the other waits foran entire propagation cycle. If this occurs, adjacencies will befalsely eliminated from the topology and routes may become unstable forperiod of timepotentially as large as maximumLSPGeneratonInterval.When some event requires changing the LSP informationfor a system, the system shall reissue that (or those) LSPswhich would have different contents. It is not required toreissue the unchanged LSPs. Thus a single End system adjacency change only requires the reissuing of the LSP containing the End System Neighbours option referring tothat adjacency. The parameters max
imum
LSP
Gen
er
a
tion
Int
er
val and minimumLSPGenerationInterval shallapply to each LSP individually.7.3.5 Periodic LSP GenerationThe Update Process shall periodically re-generate andpropagate on every circuit with an IS adjacency of the appropriate level (by setting SRMflag on each circuit), all theLSPs (Level 1 and/or Level 2) for the local system and anypseudonodes for which it is responsible. The Intermediatesystem shall re-generate each LSP at intervals of at mostmax
i
mum
LSP
Gen
era
tion
Interval seconds, with jitterapplied as described in 10.1.These LSPs may all be generated on expiration of a singletimer or alternatively separate timers may be kept for eachLSP Number and the individual LSP generated on expiration of this timer.7.3.6 Event Driven LSP GenerationIn addition to the periodic generation of LSPs, an Intermediate system shall generate an LSP when an event occurswhich would cause the information content to change. Thefollowing events may cause such a change.-an Adjacency or Circuit Up/Down event- a change in Circuit metric-a change in Reachable Address metric-a change in manual
Area
Addresses-a change in systemID-a change in Designated Intermediate System status-a change in the waiting statusWhen such an event occurs the IS shall re-generate changedLSP(s) with a new sequence number. If the event necessitated the generation of an LSP which had not previouslybeen generated (for example, an adjacency Up event foran adjacency which could not be accommodated in an existing LSP), the sequence number shall be set to one. The ISshall then propagate the LSP(s) on every circuit by settingSRMflag for each circuit. The timer maximum
LSP
Gen
er
ation
Interval shall not be reset.There is a hold-down timer (min
i
mum
LSP
Generation
Interval) on the generation of each individual LSP.7.3.7 Generation of Level 1 LSPs(non-pseudonode)The Level 1 Link State PDU not generated on behalf of apseudonode contains the following information in its variable length fields.-In the Area Addresses option the set of manual
Area
Addresses for this Intermediate System.-In the Intermediate System Neighbours optionthe set of Intermediate system IDs of neighbouring Intermediate systems formed from:7The set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode)from adjacencies in the state Up, on circuits oftype Point-Point, In or Out, withxneighbourSystemType L1 IntermediateSystemxneighbourSystemType L2 IntermediateSystem and adjacencyUsage Level 2 orLevel1 and 2.The metrics shall be set to the values of Level 1metrick of the circuit for each supported routeingmetric.7The set of l1CircuitIDs for all circuits of typeBroadcast (i.e. the neighbouring pseudonodeIDs) .The metrics shall be set to the values of Level 1metrick of the circuit for each supported routeingmetric.7The set of IDs with an appended zero octet derivedfrom the Network Entity Titles of all Virtual Adjacencies of this IS. (Note that the Virtual Flag is setwhen encoding these entries in the LSP see7.2.10.)The default metric shall be set to the total cost tothe virtual NET for the default routeing metric.The remaining metrics shall be set to the value indicating unsupported.-In the End System Neighbours option the set ofIDs of neighbouring End systems formed from:7The systemID of the Intermediate System itself,with a value of zero for all supported metrics.7The set of endSystemIDs from all adjacencieswith type Auto-configured, in state Up, oncircuits of type Point-to-Point, In or Out,with neighbourSystemType End system.The metrics shall be set to the values of Level 1metrick of the circuit for each supported routeingmetric.7The set of endSystemIDs from all adjacencieswith type Manual in state Up, on all circuits.The metrics shall be set to the values of Level 1metrick of the circuit for each supported routeingmetric.-In the Authentication Information field if thesystem's areaTransmitPassword is non-null, include the Authentication Information field containing an Authentication Type of Password, and thevalue of the areaTransmitPassword.7.3.8 Generation of Level 1 Pseudonode LSPsAn IS shall generate a Level 1 pseudonode Link State PDUfor each circuit for which this Intermediate System is theLevel 1 LAN Designated Intermediate System. The LSPshall specify the following information in its variable lengthfields. In all cases a value of zero shall be used for all supported routeing metrics-The Area Addresses option is not present.Note - This information is not required since the set ofarea addresses for the node issuing the pseudonodeLSP will already have been made available via its ownnon-pseudonode LSP.-In the Intermediate System Neighbours optionthe set of Intermediate System IDs of neighbouring Intermediate Systems on the circuit for which thispseudonode LSP is being generated formed from:7The Designated Intermediate System's own systemID with an appended zero octet (indicatingnon-pseudonode).7The set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode)from adjacencies on this circuit in the state Up,withxneighbourSystemType L1 IntermediateSystemxL2 Intermediate System and adjacencyUsage Level 1.-In the End System Neighbours option the set ofIDs of neighbouring End systems formed from:7The set of endSystemIDs from all adjacencieswith type Auto-configured, in state Up, onthe circuit for which this pseudonode is being generated, with neighbourSystemType End system.-In the Authentication Information field if thesystem's areaTransmitPassword is non-null, include the Authentication Information field containing an Authentication Type of Password, and thevalue of the areaTransmitPassword.7.3.9 Generation of Level 2 LSPs(non-pseudonode)The Level 2 Link State PDU not generated on behalf of apseudonode contains the following information in its variable length fields:-In the Area Addresses option the set of area
Addresses for this Intermediate system computed asdescribed in 7.2.11.-In the Partition Designated Level 2 IS option theID of the Partition Designated Level 2 IntermediateSystem for the partition.-In the Intermediate System Neighbours optionthe set of Intermediate system IDs of neighbouring Intermediate systems formed from:7The set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode)from adjacencies in the state Up, on circuits oftype Point-to-Point, In or Out, with neighbourSystemType L2 Intermediate System.7The set of l2CircuitIDs for all circuits of typeBroadcast. (i.e. the neighbouring pseudonodeIDs)The metric and metric type shall be set to the values of Level 2 metrick of the circuit for each supported routeing metric.-In the Prefix Neighbours option the set of variable length prefixes formed from:7The set of names of all Reachable Address managed objects in state On, on all circuits in stateOn.The metrics shall be set to the values of Level 2metrick for the reachable address.-In the Authentication Information field if thesystem's domainTransmitPassword is non-null,include the Authentication Information field containing an Authentication Type of Password, andthe value of the domainTransmitPassword.7.3.10 Generation of Level 2 Pseudonode LSPsA Level 2 pseudonode Link State PDU is generated foreach circuit for which this Intermediate System is theLevel 2 LAN Designated Intermediate System and containsthe following information in its variable length fields. In allcases a value of zero shall be used for all supported routeing metrics.-The Area Addresses option is not present.Note - This information is not required since the set ofarea addresses for the node issuing the pseudonodeLSP will already have been made available via its ownnon-pseudonode LSP.-In the Intermediate System Neighbours optionthe set of Intermediate System IDs of neighbouring Intermediate Systems on the circuit for which thispseudonode LSP is being generated formed from:7The Designated Intermediate System's own systemID with an appended zero octet (indicatingnon-pseudonode).7The set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode)from adjacencies on this circuit in the state Upwith neighbourSystemType L2 IntermediateSystem.-The Prefix Neighbours option is not present.-In the Authentication Information field if thesystem's domainTransmitPassword is non-null,include the Authentication Information field containing an Authentication Type of Password, andthe value of the domainTransmitPassword.7.3.11 Generation of the ChecksumThis International Standard makes use of the checksumfunction defined in ISO 8473.The source IS shall compute the LSP Checksum when theLSP is generated. The checksum shall never be modified byany other system. The checksum allows the detection ofmemory corruptions and thus prevents both the use of incorrect routeing information and its further propagation bythe Update Process.The checksum shall be computed over all fields in the LSPwhich appear after the Remaining Lifetime field. Thisfield (and those appearing before it) are excluded so that theLSP may be aged by systems without requiring re-computation.As an additional precaution against hardware failure, whenthe source computes the Checksum, it shall start with thetwo checksum variables (C0 and C1) initialised to whatthey would be after computing for the systemID portion(i.e. the first 6 octets) of its Source ID. (This value is computed and stored when the Network entity is enabled andwhenever systemID changes.) The IS shall then resumeChecksum computation on the contents of the PDU afterthe first ID Length octets of the Source ID field.NOTE - All Checksum calculations on the LSP are performed treating the Source ID field as the first octet. Thisprocedure prevents the source from accidentally sending outLink State PDUs with some other system's ID as source.7.3.12 Initiating TransmissionThe IS shall store the generated Link State PDU in the LinkState Database, overwriting any previous Link State PDUwith the same LSP Number generated by this system. TheIS shall then set all SRMflags for that Link State PDU, indicating it is to be propagated on all circuits with Intermediate System adjacencies.An Intermediate system shall ensure (by reserving resources, or otherwise) that it will always be able to storeand internalise its own non-pseudonode zeroth LSP. In theevent that it is not capable of storing and internalising oneof its own LSPs it shall enter the overloaded state as described in 7.3.19.1.NOTE - It is recommended that an Intermediate system ensure (by reserving resources, or otherwise) that it will always be able to store and internalise all its own (zero andnon-zero, pseudonode and non-pseudonode) LSPs.7.3.13 Preservation of orderWhen an existing Link State PDU is re-transmitted (withthe same or a different sequence number), but with thesame information content (i.e. the variable length part) as aresult of there having been no changes in the local topologydatabases, the order of the information in the variablelength part shall be the same as that in the previously transmitted LSP.NOTE - If a sequence of changes result in the state of thedatabase returning to some previous value, there is no requirement to preserve the ordering. It is only required whenthere have been no changes whatever. This allows the receiver to detect that there has been no change in the information content by performing an octet for octet comparisonof the variable length part, and hence not re-run the decisionprocess.7.3.14 Propagation of LSPsThe update process is responsible for propagating LinkState PDUs throughout the domain (or in the case ofLevel 1, throughout the area).The basic mechanism is flooding, in which each Intermediate system propagates to all its neighbour Intermediate systems except that neighbour from which it received thePDU. Duplicates are detected and dropped.Link state PDUs are received from the Receive Process.The maximum size control PDU (Link State PDU or Sequence Numbers PDU) which a system expects to receiveshall be Receive
LSP
Buffer
Size octets. (i.e. the Updateprocess must provide buffers of at least this size for the reception, storage and forwarding of received Link StatePDUs and Sequence Numbers PDUs.) If a control PDUlarger than this size is received, it shall be treated as if ithad an invalid checksum (i.e. ignored by the Update Process and a corruptedLSPReceived notification generated).Upon receipt of a Link State PDU the Update Process shallperform the following functions:a)Level 2 Link State PDUs shall be propagated on circuits which have at least one Level 2 adjacency.b)Level 1 Link State PDUs shall be propagated on circuits which have at least one Level 1 adjacency or atleast one Level 2 adjacency not marked Level 2only.c)When propagating a Level 1 Link State PDU on abroadcast subnetwork, the IS shall transmit to themulti-destination subnetwork address AllL1IS.d)When propagating a Level 2 Link State PDU on abroadcast subnetwork, the IS shall transmit to themulti-destination subnetwork address AllL2IS.NOTE When propagating a Link State PDU on ageneral topology subnetwork the Data Link Addressis unambiguous (because Link State PDUs are notpropagated across Dynamically Assigned circuits).e)An Intermediate system receiving a Link State PDUwith an incorrect LSP Checksum or with an invalidPDU syntax shall1)log a circuit notification, corruptedLSPReceived,2)overwrite the Checksum and Remaining Lifetimewith 0, and3)treat the Link State PDU as though its RemainingLifetime had expired (see 7.3.16.4.)f)A Intermediate system receiving a Link State PDUwhich is new (as identified in 7.3.16) shall1)store the Link State PDU into Link State database,and2)mark it as needing to be propagated upon all circuits except that upon which it was received.g)When a Intermediate system receives a Link StatePDU from source S, which it considers older than theone stored in the database for S, it shall set theSRMflag for S's Link State PDU associated with thecircuit from which the older Link State PDU was received. This indicates that the stored Link State PDUneeds to be sent on the link from which the older onewas received.h)When a system receives a Link State PDU which isthe same (not newer or older) as the one stored, the Intermediate system shall1)acknowledge it if necessary, as described in 7.3.17,and2)clear the SRMflag for that circuit for that LinkState PDU.i)A Link State PDU received with a zero checksumshall be treated as if the Remaining Lifetime were 0.The age, if not 0, shall be overwritten with 0.The Update Process scans the Link State Database for LinkState PDUs with SRMflags set. When one is found, provided the timestamp lastSent indicates that it was propagated no more recently than min
i
mum
LSP
Trans
mis
sion
Int
er
val, the IS shalla)transmit it on all circuits with SRMflags set, andb)update lastSent.7.3.15 Manipulation of SRM and SSN FlagsFor each Link State PDU, and for each circuit over whichrouteing messages are to be exchanged (i.e. not on DA circuits), there are two flags:Send Routeing Message (SRMflag) if set, indicates thatLink State PDU should be transmitted on that circuit. On broadcast circuits SRMflag is cleared assoon as the LSP has been transmitted, but on non-broadcast circuits SRMflag is only cleared on reception of a Link State PDU or Sequence NumbersPDU as described below. SRMflag shall never be set for an LSP with sequence number zero, nor on a circuit whose externalDomain attribute is True (See 7.3.15.2).Send Sequence Numbers (SSNflag) if set, indicates thatinformation about that Link State PDU should be included in a Partial Sequence Numbers PDU transmitted on that circuit. When the Sequence NumbersPDU has been transmitted SSNflag is cleared. Notethat the Partial Sequence Numbers PDU serves as anacknowledgement that a Link State PDU was received. SSNflag shall never be set on a circuit whose externalDomain attribute is True.7.3.15.1 Action on Receipt of a Link State PDU When a Link State PDU is received on a circuit C, the ISshall perform the following functionsa)Perform the following PDU acceptance tests:1)If the LSP was received over a circuit whose externalDomain attribute is True, the IS shall discard the PDU.2)If the ID Length field of the PDU is not equal tothe value of the IS's routeingDomainIDLength,the PDU shall be discarded and an iDFieldLengthMismatch notification generated.3)If this is a level 1 LSP, and the set of areaReceivePasswords is non-null, then perform thefollowing tests:i)If the PDU does not contain the Authentication Information field then the PDU shall bediscarded and an authenticationFailure notification generated.ii)If the PDU contains the Authentication Information field, but the AuthenticationType is not equal to Password, then thePDU shall be accepted unless the IS implements the authenticatiion procedure indicatedby the Authentication Type. In this casewhether the IS accepts or ignores the PDU isoutside the scope of this International Standard.iii)Otherwise, the IS shall compare the passwordin the received PDU with the passwords in theset of areaReceivePasswords, augmentedby the value of the areaTransmitPassword.If the value in the PDU matches any of thesepasswords, the IS shall accept the PDU forfurther processing. If the value in the PDUdoes not match any of the above values, thenthe IS shall ignore the PDU and generate anauthenticationFailure notification.4)If this is a level 2 LSP, and the set of domainReceivePasswords is non-null, then perform thefollowing tests:i)If the PDU does not contain the Authentication Information field then the PDU shall bediscarded and an authenticationFailure notification generated.ii)If the PDU contains the Authentication Information field, but the AuthenticationType is not equal to Password, then thePDU shall be accepted unless the IS implements the authenticatiion procedure indicatedby the Authentication Type. In this casewhether the IS accepts or ignores the PDU isoutside the scope of this International Standard.iii)Otherwise, the IS shall compare the passwordin the received PDU with the passwords in theset of domainReceivePasswords, augmented by the value of the domainTransmitPassword. If the value in the PDU matchesany of these passwords, the IS shall accept thePDU for further processing. If the value in thePDU does not match any of the above values,then the IS shall ignore the PDU and generatean authenticationFailure notification.b)If the LSP has zero Remaining Lifetime, perform theactions described in 7.3.16.4.c)If the source S of the LSP is an IS or pseudonode forwhich all but the last octet are equal to the systemIDof the receiving Intermediate System, and the receiving Intermediate System does not have that LSP in itsdatabase, or has that LSP, but no longer considers it tobe in the set of LSPs generated by this system (e.g. itwas generated by a previous incarnation of the system), then initiate a network wide purge of that LSP asdescribed in 7.3.16.4.d)If the source S of the LSP is a system (pseudonode orotherwise) for which the first ID Length octets areequal to the systemID of the receiving Intermediatesystem, and the receiving Intermediate system has anLSP in the set of currently generated LSPs from thatsource in its database (i.e. it is an LSP generated bythis Intermediate system), perform the actions described in 7.3.16.1.e)Otherwise, (the source S is some other system),1)If the LSP is newer than the one in the database, orif an LSP from that source does not yet exist in thedatabase:i)Store the new LSP in the database, overwritingthe existing database LSP for that source (ifany) with the received LSP.ii)Set SRMflag for that LSP for all circuitsother than C.iii)Clear SRMflag for C.iv)If C is a non-broadcast circuit, set SSNflagfor that LSP for C.v)Clear SSNflag for that LSP for the circuitsother than C.2)If the LSP is equal to the one in the database (sameSequence Number, Remaining Lifetimes both zeroor both non-zero, same checksums):i)Clear SRMflag for C.ii)If C is a non-broadcast circuit, set SSNflagfor that LSP for C.3)If the LSP is older than the one in the database:i)Set SRMflag for C.ii)Clear SSNflag for C.When storing a new LSP, the Intermediate system shall firstensure that it has sufficient memory resources to both storethe LSP and generate whatever internal data structures willbe required to process the LSP by the Update Process. Ifthese resources are not available the LSP shall be ignored.It shall neither be stored nor acknowledged. When an LSPis ignored for this reason the IS shall enter the WaitingState. (See 7.3.19).When attempting to store a new version of an existing LSP(with the same LSPID), which has a length less than orequal to that of the existing LSP, the existing LSP shall beremoved from the routeing information base and the newLSP stored as a single atomic action. This ensures that suchan LSP (which may be carrying the LSP Database Overloadindication from an overloaded IS) will never be ignored asa result of a lack of memory resources.7.3.15.2 Action on Receipt of a Sequence NumbersPDUWhen a Sequence Numbers PDU (Complete or Partial, see7.3.17) is received on circuit C the IS shall perform the following functions:a)Perform the following PDU acceptance tests:1)If the SNP was received over a circuit whose externalDomain attribute is True, the IS shall discard the PDU.2)If the ID Length field of the PDU is not equal tothe value of the IS's routeingDomainIDLength,the PDU shall be discarded and an iDField
Length
Mismatch notification generated.3)If this is a level 1 SNP and the set of areaReceivePasswords is non-null, then perform thefollowing tests:i)If the PDU does not contain the Authentication Information field then the PDU shall bediscarded and an authenticationFailure notification generated.ii)If the PDU contains the Authentication Information field, but the AuthenticationType is not equal to Password, then thePDU shall be accepted unless the IS implements the authenticatiion procedure indicatedby the Authentication Type. In this casewhether the IS accepts or ignores the PDU isoutside the scope of this International Standard.iii)Otherwise, the IS shall compare the passwordin the received PDU with the passwords in theset of areaReceivePasswords, augmentedby the value of the areaTransmitPassword.If the value in the PDU matches any of thesepasswords, the IS shall accept the PDU forfurther processing. If the value in the PDUdoes not match any of the above values, thenthe IS shall ignore the PDU and generate anauthenticationFailure notification.4)If this is a level 2 SNP, and the set of domainReceivePasswords is non-null, then perform thefollowing tests:i)If the PDU does not contain the Authentication Information field then the PDU shall bediscarded and an authenticationFailure notification generated.ii)If the PDU contains the Authentication Information field, but the AuthenticationType is not equal to Password, then thePDU shall be accepted unless the IS implements the authenticatiion procedure indicatedby the Authentication Type. In this casewhether the IS accepts or ignores the PDU isoutside the scope of this International Standard.iii)Otherwise, the IS shall compare the passwordin the received PDU with the passwords in theset of domainReceivePasswords, augmented by the value of the domainTransmitPassword. If the value in the PDU matchesany of these passwords, the IS shall accept thePDU for further processing. If the value in thePDU does not match any of the above values,then the IS shall ignore the PDU and generatean authenticationFailure notification.b)For each LSP reported in the Sequence NumbersPDU:1)If the reported value equals the database value andC is a non-broadcast circuit, Clear SRMflag for Cfor that LSP.2)If the reported value is older than the databasevalue, Clear SSNflag, and Set SRMflag.3)If the reported value is newer than the databasevalue, Set SSNflag, and if C is a non-broadcastcircuit Clear SRMflag.4)If no database entry exists for the LSP, and the reported Remaining Lifetime, Checksum and Sequence Number fields of the LSP are all non-zero, create an entry with sequence number 0 (see7.3.16.1), and set SSNflag for that entry and circuit C. Under no circumstances shall SRMflag beset for such an LSP with zero sequence number.NOTE - This is because possessing a zero sequencenumber LSP is semantically equivalent to having noinformation about that LSP. If such LSPs werepropagated by setting SRMflag it would result in anunnecessary consumption of both bandwidth andmemory resources.c)If the Sequence Numbers PDU is a Complete Sequence Numbers PDU, Set SRMflags for C for allLSPs in the database (except those with zero sequencenumber or zero remaining lifetime) with LSPIDswithin the range specified for the CSNP by the StartLSPID and End LSPID fields, which were not mentioned in the Complete Sequence Numbers PDU (i.e.LSPs this system has, which the neighbour does notclaim to have).7.3.15.3 Action on expiration of Complete SNPIntervalThe IS shall perform the following actions everyCompleteSNPInterval seconds for circuit C:a)If C is a broadcast circuit, then1)If this Intermediate system is a Level 1 DesignatedIntermediate System on circuit C, transmit a complete set of Level 1 Complete Sequence NumbersPDUs on circuit C. Ignore the setting of SSNflagon Level 1 Link State PDUs.If the value of the IS's areaTransmitPasswordis non-null, then the IS shall include the Authentication Information field in the transmittedCSNP, indicating an Authentication Type ofPassword and containing the areaTransmitPassword as the authentication value.2)If this Intermediate system is a Level 2 DesignatedIntermediate System on circuit C, transmit a complete set of Level 2 Complete Sequence NumbersPDUs on circuit C. Ignore the setting of SSNflagon Level 2 Link State PDUs.If the value of the IS's domainTransmitPassword is non-null, then the IS shall include theAuthentication Information field in the transmitted CSNP, indicating an Authentication Typeof Password and containing the domainTransmitPassword as the authentication value.A complete set of CSNPs is a set whose startLSPIDand endLSPID ranges cover the complete possiblerange of LSPIDs. (i.e. there is no possible LSPIDvalue which does not appear within the range of oneof the CSNPs in the set). Where more than one CSNPis transmitted on a broadcast circuit, they shall beseparated by an interval of at least min
i
mum
Broad
cast
LSP
TransmissionInterval seconds.NOTE An IS is permitted to transmit a small numberof CSNPs (no more than 10) with a shorter separation interval, (or even back to back), provided that no morethan 1000/minimum
Broad
cast
LSP
Trans
mis
sion
Int
er
val CSNPs are transmitted in any one second period.b)Otherwise (C is a point to point circuit, including non-DA DED circuits and virtual links), do nothing.CSNPs are only transmitted on point to point circuitsat initialisation.7.3.15.4 Action on expiration of Partial SNPIntervalThe maximum sized Level 1 or Level 2 PSNP which maybe generated by a system is controlled by the values oforiginating
L1
LSP
Buf
fer
Size or originating
L2
LSP
Buffer
Size respectively. An Intermediate system shall perform the following actions every partialSNPInterval seconds for circuit C with jitter applied as described in 10.1:a)If C is a broadcast circuit, then1)If this Intermediate system is a Level 1 Intermediate System or a Level 2 Intermediate System withmanual
L2
Only
Mode False, but is not aLevel 1 Designated Intermediate System on circuitC, transmit a Level 1 Partial Sequence NumbersPDU on circuit C, containing entries for as manyLevel 1 Link State PDUs with SSNflag set as willfit in the PDU, and then clear SSNflag for theseentries. To avoid the possibility of starvation, thescan of the LSP database for those with SSNflagset shall commence with the next LSP which wasnot included in the previous scan. If there were noLevel 1 Link State PDUs with SSNflag set, donot transmit a Level 1 Partial Sequence NumbersPDU.If the value of the IS's areaTransmitPasswordis non-null, then the IS shall include the Authentication Information field in the transmittedPSNP, indicating an Authentication Type ofPassword and containing the areaTransmitPassword as the authentication value.2)If this Intermediate system is a Level 2 Intermediate System, but is not a Level 2 Designated Intermediate System on circuit C, transmit a Level 2Partial Sequence Numbers PDU on circuit C, containing entries for as many Level 2 Link StatePDUs with SSNflag set as will fit in the PDU,and then clear SSNflag for these entries. To avoidthe possibility of starvation, the scan of the LSPdatabase for those with SSNflag set shall commence with the next LSP which was not includedin the previous scan. If there were no Level 2 LinkState PDUs with SSNflag set, do not transmit aLevel 2 Partial Sequence Numbers PDU.If the value of the IS's domainTransmitPassword is non-null, then the IS shall include theAuthentication Information field in the transmitted PSNP, indicating an Authentication Typeof Password and containing the domainTransmitPassword as the authentication value.b)Otherwise (C is a point to point circuit, including non-DA DED circuits and virtual links)1)If this system is a Level 1 Intermediate system,transmit a Level 1 Partial Sequence Numbers PDUon circuit C, containing entries for as many Level1 Link State PDUs with SSNflag set as will fit inthe PDU, and then clear SSNflag for these entries. To avoid the possibility of starvation, thescan of the LSP database for those with SSNflagset shall commence with the next LSP which wasnot included in the previous scan. If there were noLevel 1 Link State PDUs with SSNflag set, donot transmit a Partial Sequence Numbers PDU.If the value of the IS's areaTransmitPasswordis non-null, then the IS shall include the Authentication Information field in the transmittedPSNP, indicating an Authentication Type ofPassword and containing the areaTransmitPassword as the authentication value.2)If this system is a Level 2 Intermediate system,transmit a Level 2 Partial Sequence Numbers PDUon circuit C, containing entries for as many Level2 Link State PDUs with SSNflag set as will fit inthe PDU, and then clear SSNflag for these entries. To avoid the possibility of starvation, thescan of the LSP database for those with SSNflagset shall commence with the next LSP which wasnot included in the previous scan. If there were noLevel 2 Link State PDUs with SSNflag set, donot transmit a Partial Sequence Numbers PDU.If the value of the IS's domainTransmitPassword is non-null, then the IS shall include theAuthentication Information field in the transmitted PSNP, indicating an Authentication Typeof Password and containing the domainTransmitPassword as the authentication value.7.3.15.5 Action on expiration of Minimum LSPTransmission IntervalAn IS shall perform the following actions every min
i
mum
LSP
Trans
mis
sion
Int
er
val seconds with jitter applied asdescribed in 10.1.a)For all Point to Point circuits C transmit all LSPs thathave SRMflag set on circuit C, but do not clear theSRMflag. The SRMflag will subsequently becleared by receipt of a Complete or Partial SequenceNumbers PDU.The interval between two consecutive transmissions of thesame LSP shall be at least min
i
mum
LSP
Trans
mis
sion
Int
er
val. Clearly, this can only be achieved precisely by keeping a separate timer for each LSP. This would be an unwarranted overhead. Any technique which ensures the intervalwill be between min
i
mum
LSP
Trans
mis
sion
Int
er
val and2 * min
i
mum
LSP
Trans
mis
sion
Int
er
val is acceptable.7.3.15.6 Controlling the Rate of Transmission onBroadcast CircuitsThe attribute min
i
mum
Broad
cast
LSP
Trans
mis
sion
Inter
val indicates the minimum interval between PDU arrivals which can be processed by the slowest IntermediateSystem on the LAN.Setting SRMflags on an LSP for a broadcast circuit doesnot cause the LSP to be transmitted immediately. Insteadthe Intermediate system shall scan the LSP database everymin
i
mum
Broad
cast
LSP
Trans
mis
sion
Int
er
val (withjitter applied as described in 10.1), and from the set of LSPswhich have SRMflags set for this circuit, one LSP shall bechosen at random. This LSP shall be multicast on the circuit, and SRMflags cleared.NOTE - In practice it would be very inefficient to scan thewhole database at this rate, particularly when only a fewLSPs had SRMflags set. Implementations may require additional data structures in order to reduce this overhead.NOTE - An IS is permitted to transmit a small number ofLSPs (no more than 10) with a shorter separation interval,(or even back to back), provided that no more than1000/min
i
mum
Broad
cast
LSP
Trans
mis
sion
Int
er
val LSPsare transmitted in any one second period.In addition, the presence of any LSPs which have been received on a particular circuit and are queued awaiting processing shall inhibit transmission of LSPs on that circuit.However, LSPs may be transmitted at a minimum rate ofone per second even in the presence of such a queue.7.3.16 Determining the Latest InformationThe Update Process is responsible for determining, given areceived link state PDU, whether that received PDU represents new, old, or duplicate information with respect towhat is stored in the database.It is also responsible for generating the information uponwhich this determination is based, for assigning a sequencenumber to its own Link State PDUs upon generation, andfor correctly adjusting the Remaining Lifetime field uponbroadcast of a link state PDU generated originally by anysystem in the domain.7.3.16.1 Sequence NumbersThe sequence number is a 4 octet unsigned value. Sequencenumbers shall increase from zero to (SequenceModulus- 1). When a system initialises, it shall start with sequencenumber 1 for its own Link State PDUs.55It starts with 1 rather than 0so that the value 0 can be reserved to be guaranteed to be less thanthe sequence number of any actually generated Link StatePDU. This is a useful property for Sequence Numbers PDUs.The sequence numbers the Intermediate system generatesfor its Link State PDUs with different values for LSP number are independent. The algorithm for choosing the numbers is the same, but operationally the numbers will not besynchronised.If an Intermediate system R somewhere in the domain hasinformation that the current sequence number for source Sis greater than that held by S, R will return to S a Link StatePDU for S with R's value for the sequence number. When Sreceives this LSP it shall change its sequence number to bethe next number greater than the new one received, andshall generate a link state PDU.If an Intermediate system needs to increment its sequencenumber, but the sequence number is already equal toSequenceModulus 1, the notification attempt
To
Ex
ceed
Maximum
Se
quence
Num
ber shall be generated andthe Routeing Module shall be disabled for a period of atleast MaxAge + ZeroAgeLifetime, in order to be surethat any versions of this LSP with the high sequence number have expired. When it is re-enabled the IS shall startagain with sequence number 1.7.3.16.2 LSP ConfusionIt is possible for an LSP generated by a system in a previous incarnation to be alive in the domain and have the samesequence number as the current LSP.To ensure database consistency among the IntermediateSystems, it is essential to distinguish two such PDUs. Thisis done efficiently by comparing the checksum on a received LSP with the one stored in memory.If the sequence numbers match, but the checksums do notand the LSP is not in the current set of LSPs generated bythe local system, then the system that notices the mismatchshall treat the LSP as if its Remaining Lifetime had expired.It shall store one of the copies of the LSP, with zero writtenas the Remaining Lifetime, and flood the LSP.If the LSP is in the current set of LSPs generated by the local system then the IS shall change the LSP's sequencenumber to be the next number greater than that of the received LSP and regenerate the LSP.7.3.16.3 Remaining Lifetime fieldWhen the source generates a link state PDU, it shall set theRemaining Lifetime to MaxAge.When a system holds the information for some time beforesuccessfully transmitting it to a neighbour, that system shalldecrement the Remaining Lifetime field according to theholding time. Before transmitting a link state PDU to aneighbour, a system shall decrement the Remaining Lifetime in the PDU being transmitted by at least 1, or morethan 1 if the transit time to that neighbour is estimated tobe greater than one second. When the Remaining Lifetimefield reaches 0, the system shall purge that Link State PDUfrom its database. In order to keep the Intermediate Systems' databases synchronised, the purging of an LSP due toRemaining Lifetime expiration is synchronised by floodingan expired LSP. See 7.3.16.4.If the RemainingLifetime of the received LSP is zero itshall be processed as described in 7.3.16.4. If the Remaining Lifetime of the received LSP is non-zero, but there is anLSP in the database with the same sequence number andzero Remaining Lifetime, the LSP in the database shall beconsidered most recent. Otherwise, the PDU with the largersequence number shall be considered the most recent.If the value of Remaining Lifetime is greater thanMaxAge, the LSP shall be processed as if there were achecksum error.7.3.16.4 LSP Expiration SynchronisationWhen the Remaining Lifetime on an LSP in memory becomes zero, the IS shalla)set all SRMflags for that LSP, andb)retain only the LSP header.c)record the time at which the Remaining Lifetime forthis LSP became zero. When ZeroAgeLifetime haselapsed since the LSP Remaining Lifetime becamezero, the LSP header shall be purged from the database.NOTE - A check of the checksum of a zero Remaining Lifetime LSP succeeds even though the data portion is not presentWhen a purge of an LSP with non-zero Remaining Lifetimeis initiated, the header shall be retained for MaxAge.If an LSP from source S with zero Remaining Lifetime isreceived on circuit C :a)If no LSP from S is in memory, then the IS shall1)send an acknowledgement of the LSP on circuit C,but2)shall not retain the LSP after the acknowledgementhas been sent.b)If an LSP from S is in the database, then1)If the received LSP is newer than the one in the database (i.e. received LSP has higher sequencenumber, or same sequence number and databaseLSP has non-zero Remaining Lifetime) the ISshall:i)overwrite the database LSP with the receivedLSP, and note the time at which the zero Remaining Lifetime LSP was received, so thatafter ZeroAgeLifetime has elapsed, that LSPcan be purged from the database,ii)set SRMflag for that LSP for all circuits otherthan C,iii)clear SRMflag for C,iv)if C is a non-broadcast circuit, set SSNflagfor that LSP for C, andv)clear SSNflag for that LSP for the circuitsother than C.2)If the received LSP is equal to the one in the database (i.e. same Sequence Number, RemainingLifetimes both zero) the IS shall:i)clear SRMflag for C, andii)if C is a non-broadcast circuit, set SSNflagfor that LSP for C.3)If the received LSP is older than the one in the database (i.e. received LSP has lower sequence number) the IS shall:i)set SRMflag for C, andii)clear SSNflag for C.c)If this system (or pseudonode) is S and there is an un-expired LSP from S (i.e. its own LSP) in memory,then the IS:1)shall not overwrite with the received LSP, but2)shall change the sequence number of the un-expired LSP from S as described in 7.3.16.1,3)generate a new LSP; and4)set SRMflag on all circuits.7.3.17 Making the Update ReliableThe update process is responsible for making sure the latestlink state PDUs reach every reachable Intermediate Systemin the domain.On point-to-point links the Intermediate system shall sendan explicit acknowledgement encoded as a Partial SequenceNumbers PDU (PSNP) containing the following information:a)source's IDb)PDU type (Level 1 or 2)c)sequence numberd)Remaining Lifetimee)checksumThis shall be done for all received link state PDUs whichare newer than the one in the database, or duplicates of theone in the database. Link state PDUs which are older thanthat stored in the database are answered instead by a newerlink state PDU, as specified in 7.3.14 above.On broadcast links, instead of explicit acknowledgementsfor each link state PDU by each Intermediate system, a special PDU known as a Complete Sequence Numbers PDU(CSNP), shall be multicast periodically by the DesignatedIntermediate System. The PDU shall contain a list of allLSPs in the database, together with enough information sothat Intermediate systems receiving the CSNP can comparewith their LSP database to determine whether they and theCSNP transmitter have synchronised LSP databases. Themaximum sized Level 1 or Level 2 Sequence NumbersPDU which may be generated by a system is controlled bythe values of originating
L1
LSP
Buf
fer
Size or originatingL2LSPBufferSize respectively. In practice, the information required to be transmitted in a single CSNP may begreater than will fit in a single PDU. Therefore each CSNPcarries an inclusive range of LSPIDs to which it refers. Thecomplete set of information shall be conveyed by transmitting a series of individual CSNPs, each referring to a subsetof the complete range. The ranges of the complete set ofCSNPs shall be contiguous (though not necessarily transmitted in order) and shall cover the entire range of possibleLSPIDs.The LAN Level 1 Designated Intermediate System shallperiodically multicast complete sets of Level 1 CSNPs tothe multi-destination address AllL1ISs. The LAN Level 2Designated Intermediate System shall periodically multicastcomplete sets of Level 2 CSNPs to the multi-destination address AllL2ISs.Absence of an LSPID from a Complete Sequence NumbersPDU whose range includes that LSPID indicates total lackof information about that LSPID.If an Intermediate system, upon receipt of a Complete Sequence Numbers PDU, detects that the transmitter was outof date, the receiver shall multicast the missing information.NOTE - Receipt of a link state PDU on a link is the same assuccessfully transmitting the Link State PDU on that link, soonce the first Intermediate system responds, no others will,unless they have already transmitted replies.If an Intermediate system detects that the transmitter hadmore up to date information, the receiving Intermediate system shall multicast a Partial Sequence Numbers PDU(PSNP), containing information about LSPs for which it hasolder information. This serves as an implicit request for themissing information. Although the PSNP is multicast, onlythe Designated Intermediate System of the appropriate levelshall respond to the PSNP.NOTE - This is equivalent to the PSNP being transmitted directly to the Designated Intermediate System, in that itavoids each Intermediate System unnecessarily sending thesame LSP(s) in response. However, it has the advantage ofpreserving the property that all routeing messages can be received on the multi-destination addresses, and hence by aLAN adapter dedicated to the multi-destination address.When a non-broadcast circuit (re)starts, the IS shall:a)set SRMflag for that circuit on all LSPs, andb)send a Complete set of Complete Sequence NumbersPDUs on that circuit.7.3.18 Validation of DatabasesAn Intermediate System shall not continue to operate for anextended period with corrupted routeing information. TheIS shall therefore operate in a fail-stop manner. If a failureis detected, the Intermediate system Network entity shall bedisabled until the failure is corrected. In the absence of animplementation-specific method for ensuring this, the ISshall perform the following checks at least every max
i
mum
LSPGenerationInterval seconds:a)On expiration of this timer the IS shall re-check thechecksum of every LSP in the LSP database (exceptthose with a Remaining Lifetime of zero) in order todetect corruption of the LSP while in memory. If thechecksum of any LSP is incorrect, the notificationcorruptedLSPDetected shall be logged, and as aminimum the entire Link State Database shall be deleted and action taken to cause it to be re-acquired.One way to achieve this is to disable and re-enable theIS Network entity.NOTE On point to point links, this requires at leastthat a CSNP be transmitted.b)On completion of these checks the decision processshall be notified of an event (even if any newly generated LSPs have identical contents to the previousones). This causes the decision process to be run andthe forwarding databases re-computed, thus protectingagainst possible corruption of the forwarding databases in memory, which would not otherwise be detected in a stable topology.c)The IS shall reset the timer for a period ofmaximumLSPGenerationInterval with jitter applied as described in 10.1.7.3.19 LSP Database OverloadAs a result of network mis-configuration, or certain transitory conditions, it is possible that there may be insufficientmemory resources available to store a received Link StatePDU. When this occurs, an IS needs to take certain steps toensure that if its LSP database becomes inconsistent withthe other ISs', that these ISs do not rely on forwardingpaths through the overloaded IS.7.3.19.1 Entering the Waiting StateWhen an LSP cannot be stored, the LSP shall be ignoredand Waiting State shall be entered. A timer shall be startedfor waitingTime seconds, and the Intermediate Systemshall generate and flood its own LSP with zero LSP numberwith the LSP Database Overload Bit set. This preventsthis Intermediate system from being considered as a forwarding path by other Intermediate Systems.It is possible that although there are sufficient resources tostore an LSP and permit the operation of the Update Process on that LSP, the Decision Process may subsequently require further resources in order to complete. If these resources are not available, the Intermediate system shall then(i.e. during the attempt to run the Decision Process) enterWaiting State until such time as they are available andwaitingTime seconds have elapsed since the last LSP wasignored by the Update Process.An implementation shall partition the available memory resources between the Level 1 and Level 2 databases. Anoverload condition can therefore exist independently forLevel 1 or Level 2 (or both). The status attributes l1Stateand l2State indicate the condition for the Level 1 andLevel 2 databases respectively. On entering Level 1 Waiting State the IS shall generate the lSP
L1
Data
base
Over
load notification, and on entering Level 2 Waiting Statethe IS shall generate the lSP
L2
Data
base
Over
load notification.7.3.19.2 Actions in Level 1 Waiting StateWhile in Level 1 waiting statea)If a Link State PDU cannot be stored, the IS shall ignore it and restart the timer for waitingTime seconds.b)The IS shall continue to run the Decision and Forwarding processes as normal.c)When the waitingTime timer expires, the IS shall:1)Generate an lSP
L1
Data
base
Over
load (recovered) notification.2)Clear the LSP Database Overload bit in its ownLevel 1 LSP with zero LSP number and re-issue it.3)Set the l1State to On.4)Resume normal operation.7.3.19.3 Actions in Level 2 Waiting StateWhile in Level 2 waiting statea)If a Link State PDU cannot be stored, the IS shall ignore it and restart the timer for waitingTime seconds.b)The IS shall continue to run the Decision and Forwarding processes as normal.c)When the waitingTime timer expires, the IS shall:1)Generate an lSP
L2
Data
base
Over
load (recovered) notification.2)Clear the LSP Database Overload bit in its ownLevel 2 LSP with zero LSP number and re-issue it.3)Set the l2State to On.4)Resume normal operation.7.3.20 Use of the Link State DatabaseThe only portion of the database relevant to the DecisionProcess is the data portion of the Link State PDUs.The Update Process additionally uses the fields SequenceNumber, Remaining Lifetime, and variable SRMflag.The Remaining Lifetimes in the stored link state PDUs caneither be periodically decremented, or converted upon receipt into an internal timestamp, and converted back into aRemaining Lifetime upon transmission.7.3.20.1 Synchronisation with the Decision ProcessSince the Update Process and the Decision Process sharethe Link State Database, care must be taken that the UpdateProcess does not modify the Link State Database while theDecision Process is running.There are two approaches to this. In one approach, the Decision Process signals when it is running. During this time,the Update Process queues incoming Link State PDUs, anddoes not write them into the Link State Database. If moreLink State PDUs arrive than can fit into the queue allottedwhile the Decision Process is running, the Update Processdrops them and does not acknowledge them.Another approach is to have two copies of the Link StateDatabase one in which the Decision Process is computing, and the other in which the Update Process initially copies over the first database, and in which all new Link StatePDUs are written. Additionally, depending on the hashingscheme, it is likely that a second copy of the address hashtable will be required, so that the Update Process can do arehash occasionally for efficiency.When the Decision Process is ready to run again, it locksthe new copy of the Link State Database, leaving the Update Process to copy over the information into the first area,and write new updates while the Decision Process runsagain.The advantage of the first approach is that it takes lessmemory. The advantage of the second approach is that LinkState PDUs will never need to be dropped.NOTE - If the decision process is implemented according tothe specification in C.2, a finer level of parallelism is possible, as described below.Arrival of a Link State PDU for a system before that systemhas been put into TENT is permitted. The new Link StatePDU is used when that system is eventually put into TENT.Similarly, arrival of a new Link State PDU for a system after that system has been put into PATHS is permitted. Thatsystem has already been completely processed. The arrivalof the new Link State PDU is noted and the decision processre-executed when the current execution has completed. Anin-progress execution of the decision process shall not beabandoned, since this could prevent the decision processfrom ever completing.Arrival of a Link State PDU for a system between that system being put on TENT and being transferred to PATHSshall be treated as equivalent to one of the previous twocases (for example, by buffering, or taking some correctiveaction).7.3.20.2 Use of Buffers and Link BandwidthImplementations shall have a buffer management strategythat does not prevent other clients of the buffering servicefrom acquiring buffers due to excessive use by the UpdateProcess. They shall also ensure that the Update Processdoes not consume all the available bandwidth of links. Inparticular no type of traffic should experience starvation forlonger than its acceptable latency. Acceptable latencies areapproximately as follows:-Hello traffic Hello timer W 0.5-Data Traffic 10 seconds.NOTE - The first of these requirements can be met by restricting the Update process to the use of a single buffer oneach circuit for transmission. This may also cause the second requirement to be met, depending on the processorspeed.7.3.21 ParametersMaxAge This is the amount of time that may elapsesince the estimated origination of the stored LinkState PDU by the source before the LSP is considered expired. The expired LSP can be deleted fromthe database after a further ZeroAgeLifetime hasexpired. MaxAge shall be larger than maximum
LSP
Generation
Interval, so that a system is notpurged merely because of lack of events for reporting Link State PDUs. MaxAge is an architectural constant equal to 20minutes.ZeroAgeLifetime - This is the minimum amount of timefor which the header of an expired LSP shall be retained after it has been flooded with zero RemainingLifetime. A very safe value for this would be2 W MaxAge.However all that is required is thatthe header be retained until the zero Remaining Lifetime LSP has been safely propagated to all theneighbours. ZeroAgeLifetime is an architectural constant witha value of 1 minute.maximumLSPGenerationInterval This is the maximum amount of time allowed to elapse between generation of Link State PDUs by a source. It shall beless than MaxAge. Setting this parameter too fast adds overhead to thealgorithms (a lot of Link State PDUs). Setting thisparameter too slow (and not violating constraints)causes the algorithm to wait a long time to recoverin the unlikely event that incorrect Link State information exists somewhere in the domain about thesystem. A reasonable setting is 15 minutes.minimumLSPGenerationInterval This is the minimumtime interval between generation of Link StatePDUs. A source Intermediate system shall wait atleast this long before re-generating one of its ownLink State PDUs. Setting this too large causes a delay in reporting newinformation. Setting this too small allows too muchoverhead. A reasonable setting is 30 seconds.min
i
mum
LSP
Trans
mis
sion
Int
er
val This is the amountof time an Intermediate system shall wait before further propagating another Link State PDU from thesame source system. Setting this too large causes a delay in propagationof routeing information and stabilisation of therouteing algorithm. Setting this too small allows thepossibility that the routeing algorithm, under lowprobability circumstances, will use too many resources (CPU and bandwidth). Setting min
i
mum
LSP
Trans
mis
sion
Int
er
val greaterthan minimumLSPGenerationInterval makes nosense, because the source would be allowed to generate LSPs more quickly than they'd be allowed tobe broadcast. Setting min
i
mum
LSP
Trans
mis
sion
Int
er
val smaller than min
i
mum
LSP
Generation
Inter
val is desirable to recover from lost LSPs. A reasonable value is 5 seconds.CompleteSNPInterval This is the amount of time between periodic transmissions of a complete set ofSequence Number PDUs by the Designated Intermediate system on a broadcast link. Setting this too lowslows down the convergence of the routeing algorithm when Link State PDUs are lost due to thedatagram environment of the Data Link layer on thebroadcast link. Setting this too high results in extra control trafficoverhead. A reasonable value is 10 seconds.7.4 The Forwarding ProcessThe forwarding process is responsible both for transmittingNPDUs originated by this system, and for forwardingNPDUs originated by other systems7.4.1 Input and OutputINPUT-NPDUs from the ISO 8473 protocol machine-PDUs from Update Process-PDUs from Receive Process-Forwarding Databases (Level 1 and 2) one for eachrouteing metricOUTPUT-PDUs to Data Link Layer7.4.2 Routeing Metric SelectionThe Forwarding process selects a forwarding database foreach NPDU to be relayed based on:-the level at which the forwarding is to occur: level 1or level 2; and-a mapping of the ISO 8473 QoS Maintenance fieldonto one of the Intermediate system's supported routeing metrics.The former selection is made by examining the DestinationAddress field of the NPDU.The latter selection is made as follows:a)If the QoS Maintenance field is not present in theNPDU, then the IS shall select the forwarding database calculated for the default metric.b)If the QoS Maintenance field is present, the IS shallexamine bits 7 and 8 of the parameter value octet. Ifthese two bits specify any combination other than 11 (meaning globally unique QoS), then the IS shallselect the forwarding database calculated for the default metric, otherwisec)The IS shall select a forwarding database by mappingthe values of bits 3, 2 and 1 of the parameter value asshown below in table 1 and shall proceed as follows:1)If the IS does not support the selected routeingmetric, the IS shall forward based upon the defaultmetric;2)If the forwarding database for one of the optionalrouteing metrics is selected and the database eitherdoes not contain an entry for the Destination Address in the NPDU being relayed, or contains anentry indicating that the destination is unreachableusing that metric, then the IS shall attempt to forward based upon the default metric;3)Otherwise, forward based on the selected optionalmetric.Table 1 - QoS Maintenance bits to routeingmetric mappingsSelected Routeing Metricbit 3bit 2bit 1expense metric000default metric001expense metric010delay metric100error metric011delay metric101error metric111default metric1107.4.3 Forwarding Decision7.4.3.1 Basic OperationLet DEST = the Network Layer destination address of thePDU to be forwarded, or the next entry in the source routeing field, if present. It consists of sub-fields Area Address,ID, and SEL.NOTE - The SEL field in the destination address is not examined by Intermediate Systems. It is used by End Systemsto select the proper Transport entity to which to deliver NSDUs.This system's (the one examining this PDU for proper forwarding decision) address consists of sub-fields area address and ID.a)If the local system type is a level 1 Intermediate system, or the local system type is a level 2 Intermediatesystem and AttachedFlagk = False, then:1)If the Area Address in the PDU to be forwardedmatches any one of the area addresses of this IS,then consult the level 1 forwarding database to determine the adjacency which is the next hop on thepath to the NPDU's destination. Forward theNPDU on this adjacency.2)Otherwise, consult the level 1 forwarding databaseto determine the adjacency which is the next hopon the path to the nearest level 2 is in the area, andforward the NPDU on this adjacency.b)If the local system type is Level 2, and AttachedFlagk = True then:1)If the Area Address in the PDU to be forwardedmatches any one of the area addresses of this IS,then consult the level 1 forwarding database to determine the adjacency which is the next hop on thepath to the NPDU's destination. Forward theNPDU on this adjacency.2)Otherwise, consult the level 2 forwarding databaseto determine the adjacency which is the next hopon the path to the destination area, and forward theNPDU on this adjacency.7.4.3.2 Encapsulation for Partition RepairIf this Intermediate system is the Partition DesignatedLevel 2 IS for this partition, and the PDU is being forwarded onto the special adjacency to a Partition DesignatedLevel 2 Intermediate system in a different partition of thisarea, encapsulate the complete PDU as the data field of adata NPDU (i.e., with an additional layer of header), making this system the Source address and the other PartitionDesignated Level 2 Intermediate system (obtained from theidentifier attribute of the Virtual Adjacency managed object) the Destination Address field in the outer PDUheader. Set the QoS Maintenance field of the outer PDUto indicate forwarding via the default routeing metric (seetable 1). Then forward the encapsulated PDU onto an adjacency ADJ, obtained by calling the Forward procedure, described below.7.4.3.3 The Procedure ForwardThis procedure chooses, from a Level 1 forwarding database if level is level1, or from a Level 2 forwarding database if level is level2, an adjacency on which to forward NPDUs for destination dest. A pointer to the adjacency is returned in adj, and the procedure returns the valueTrue. A destination of 0 at level 1 selects the adjacencyfor the nearest level 2 IS computed as described in 7.2.9.1.If there are multiple possible adjacencies, as a result of multiple minimum cost paths, then one of those adjacenciesshall be chosen. An implementation may chose the adjacency at random, or may use the possible adjacencies inround robin fashion.If there is no entry in the selected forwarding database forthe address dest, and the NPDU originated from the a localTransport entity and the system has one or more Intermediate System adjacencies, then one of those is chosen at random (or in round robin fashion) and the procedure returnsthe value True. Otherwise the procedure returns the valueFalse.66This is done so that a system in the overloaded state willstill be able to originate or forward NPDUs. If a system with a partialrouteing information basewere prohibited from attempting to forward to an unknown destination,system management would be unable to either communicate with this system, orroute through it, for the purpose of diagnosing and/or correcting theunderlying fault.NOTE - Since the local adjacency database is pre-loadedinto the decision process, there will always be an entry inthe forwarding database for destinations to which an adjacency exists.NOTE - The PDU to be forwarded may require fragmentation, depending on which circuit it is to be forwarded over.Generating Redirect PDUsIn addition to forwarding an NPDU, the IS shall inform thelocal ISO 9542 protocol machine to generate a RedirectPDU if the PDU is being forwarded onto the same circuitfrom which it came, and if the source SNPA address of theNPDU indicates that the NPDU was received from an EndSystem.7.4.4 The Receive ProcessThe Receive Process is passed information from any of thefollowing sources.-received PDUs with the NLPID of Intra-Domainrouteing,-configuration information from the ISO 9542 protocolmachine,-ISO 8473 data PDUs handed to the routeing functionby the ISO 8473 protocol machine.When an area is partitioned, a level 2 path is used as alevel 1 link to repair the partitioned area. When this occurs,all PDUs (between the neighbours which must utilise amulti-hop path for communication) shall be encapsulated ina data NPDU, addressed to the Intra-Domain routeing selector. Control traffic (LSPs, Sequence Numbers PDUs)shall also be encapsulated, as well as data NPDUs that areto be passed between the neighbours.NOTE - It is not necessary to transmit encapsulated IIHPDUs over a virtual link, since virtual adjacencies are established and monitored by the operation of the Decision Process and not the Subnetwork Dependent functionsThe Receive Process shall perform the following functions:-If it is a data NPDU, addressed to this system withSEL = Intra-Domain routeing, then7decapsulate the NPDU (remove the outer NPDUheader).7If the decapsulated PDU is a data NPDU, movethe congestion indications to the decapsulatedNPDU, and pass it to the ISO 8473 protocol machine.7Otherwise, if the decapsulated PDU is not an ISO8473 PDU, perform the following steps on the decapsulated 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 Update Process-If it is an IIH PDU, pass it to the appropriateSubnetwork Dependent Function-If it is a data NPDU or Error Report for another destination, pass it to the Forwarding Process-Otherwise, ignore the PDU7.5 Routeing ParametersThe routeing parameters setable by System Managementare listed for each managed object in clause 11.7.5.1 Architectural ConstantsThe architectural constants are described in Table 2.Table 2 - Routeing architectural constantsNameValueDescriptionMaxLinkMetric63.Maximum value of a routeing metric assignable to a circuitMaxPathMetric1023.Maximum total metric value for a completepathAllL1ISs01-80-C2-00-00-14The multi-destination address All Level 1 Intermediate SystemsAllL2ISs01-80-C2-00-00-15The multi-destination address All Level 2 Intermediate SystemsAllIntermediateSystems09-00-2B-00-00-05The multi-destination address All Intermediate Systems used by ISO 9542ISO-SAPFEThe SAP for ISO Network Layer onISO 8802-3 LANsIntradomainRoute
ing-PD10000011The Network Layer Protocol Discriminatorassigned by ISO/TR 9577 for this ProtocolIntradomainRouteingSelector0.The NSAP selector for the Intermediate System Network entitySequenceModulus232Size of the sequence number space used bythe Update ProcessReceiveLSPBuffer
Size1492.The size of LSP which all Intermediate systems must be capable of receiving.MaxAge1200.Number of seconds before LSP considered expired.ZeroAgeLifetime60.Number of seconds that an LSP with zero Remaining Lifetime shall be retained afterpropagating a purge.AllEndSystems09-00-2B-00-00-04The multi-destination address All End Systems used by ISO 9542Max
i
mum
Area
Addresses3.The maximum number of area addresseswhich may exist for a single area.HoldingMultiplier3.The number by which to multiply hello
Timerto obtain Holding Timer for ISH PDUs andfor Point to Point IIH PDUs.ISISHoldingMultiplier10.The number by which to multiply iSISHelloTimer to obtain Holding Timer for Level 1and Level 2 LAN IIH PDUs.Jitter25.The percentage of jitter which is applied to thegeneration of periodic PDUs.8 Subnetwork DependentFunctionsThe Subnetwork Dependent Functions mask the characteristics of the different kinds of Subnetworks from theSubnetwork Independent Routeing Functions. The onlytwo types of circuits the Subnetwork Independent Functionsrecognise are broadcast and general topology.The Subnetwork Dependent Functions include:-The use of the ISO 8473 Subnetwork DependentConvergence Functions (SNDCF) so that this protocol may transmit and receive PDUs over the samesubnetwork types, using the same techniques, as doesISO 8473.-Co-ordination with the operation of the ESIS protocol (ISO 9542) in order to determine the Networklayer addresses (and on Broadcast subnetworks, thesubnetwork points of attachment) and identities (EndSystem or Intermediate System) of all adjacent neighbours. This information is held in the Adjacency database. It is used to construct Link State PDUs.-The exchange of IIH PDUs. While it is possible for anIntermediate System to identify that it has an Intermediate System neighbour by the receipt of an ISO 9542ISH PDU, there is no provision within ISO 9542 to indicate whether the neighbour is a Level 1 or a Level 2Intermediate System. Specific PDUs (LAN Level 1,LAN Level 2 and Point to point IIH PDUs) are defined to convey this information.8.1 Multi-destination Circuits on ISs ata Domain BoundaryRouteing information (e.g. Link State PDUs) is not exchanged across a routeing domain boundary. All routeinginformation relating to a circuit connected to another routeing domain is therefore entered via the Reachable Addressmanaged objects. This information is disseminated to therest of the routeing domain via Link State PDUs as described in 7.3.3.2. This has the effect of causing NPDUsdestined for NSAPs which are included in theaddressPrefixes of the Reachable Addresses to be relayed to that Intermediate System at the domain boundary.On receipt of such an NPDU the Intermediate system shallforward it onto the appropriate circuit, based on its ownLink State information. However in the case of multi-destination subnetworks (such as an ISO 8208 subnetworkusing Dynamic Assignment, a broadcast subnetwork, or aconnectionless subnetwork) it is necessary to ascertain additional subnetwork dependent addressing information inorder to forward the NPDU to a suitable SNPA. (This maybe the target End system or an Intermediate system withinthe other domain.)In general the SNPA address to which an NPDU is to beforwarded can be derived from the destination NSAP of theNPDU. It may be possible to perform some algorithmic manipulation of the NSAP address in order to derive theSNPA address. However there may be some NSAPs wherethis is not possible. In these cases it is necessary to havepre-configured information relating an address prefix to aparticular SNPA address.This is achieved by additional information contained in theReachable Address managed object. The mappingTypeattribute may be specified as Manual, in which case aparticular SNPA address or set of SNPA addresses is specified in the SNPA Address characteristic. Alternatively thename of an SNPA address extraction algorithm may bespecified.8.2 Point to Point SubnetworksThis clause describes the identification of neighbours onboth point to point links and Static circuits.The IS shall operate the ISO 9542 protocol, shall be able toreceive ISO 9542 ISH PDUs from other ISs, and shall storethe information so obtained in the adjacency database.8.2.1 Receipt of ESH PDUsDatabase of EndSystemsAn IS shall enter an End system into the adjacency databasewhen an ESH PDU is received on a circuit. If an ESH PDUis received on the same circuit, but with a different NSAPaddress, the new address shall be added to the adjacency,with a separate timer. A single ESH PDU may contain morethan one NSAP address. When a new data link address orNSAP address is added to the adjacency database, the ISshall generate an adjacencyStateChange (Up) notification on that adjacency.The IS shall set a timer for the value of Holding Time inthe received ESH PDU. If another ESH PDU is not received from the ES before that timer expires, the ES shallbe purged from the database, provided that the SubnetworkIndependent Functions associated with initialising the adjacency have been completed. Otherwise the IS shall clear theadjacency as soon as those functions are completed.When the adjacency is cleared, the Subnetwork Independent Functions shall be informed of an adjacencyStateChange (Down) notification, and the adjacency can be re-used after the Subnetwork Independent Functions associated with bringing down the adjacency have been completed.8.2.2 Receiving ISH PDUs by an IntermediateSystemOn receipt of an ISH PDU by an Intermediate System, theIS shall create an adjacency (with state Initialising andneighbourSystemType Unknown), if one does not already exist, and then perform the following actions:.a)If the Adjacency state is Up and the ID portion ofthe NET field in the ISH PDU does not match theneighbourID of the adjacency then the IS shall:1)generate an adjacencyStateChange (Down) notification;2)delete the adjacency; and3)create a new adjacency with:i)state set to Initialising, andii)neighbourSystemType set to Unknown.4)perform the following actions..b)If the Adjacency state is Initialising, and theneighbourSystemType status is Intermediate System, the ISH PDU shall be ignored.c)If the Adjacency state is Initialising and the neighbourSystemType status is not Intermediate System, a point to point IIH PDU shall be transmitted asdescribed in 8.2.3.d)The neighbourSystemType status shall be set to Intermediate System indicating that the neighbour is anIntermediate system, but the type (L1 or L2) is, as yet,unknown.8.2.3 Sending Point to Point IIH PDUsAn IS shall send Point-to-Point IIH PDUs on those Point-to-Point circuits whose externalDomain attribute is setFalse. The IIH shall be constructed and transmitted asfollows:a)The Circuit Type field shall be set according to Table 3.b)The Local Circuit ID field shall be set to a value assigned by this Intermediate system when the circuit iscreated. This value shall be unique among all the circuits of this Intermediate system.c)The first Point to Point IIH PDU (i.e. that transmittedas a result of receiving an ISH PDU, rather than as aresult of timer expiration) shall be padded (with trailing PAD options containing arbitrary valued octets) sothat the SNSDU containing the IIH PDU has a lengthof at least maxsize - 1 octets77The minimum length of PAD which may beadded is 2 octets, since that is the size of the option header. Wherepossible the PDU should be padded tomaxsize, but if the PDU length is maxsize- 1 octets no padding ispossible (or required). where maxsize is themaximum of1)dataLinkBlocksize2)originating
L1
LSP
Buf
fer
Size3)originatingL2LSPBufferSizeThis is done to ensure that an adjacency will only beformed between systems which are capable of exchanging PDUs of length up to maxsize octets. In theabsence of this check, it would be possible for an adjacency to exist with a lower maximum block size, withthe result that some LSPs and SNPs (i.e. those longerthan this maximum, but less than maxsize) would notbe exchanged.NOTE - It is necessary for the manager to ensure that thevalue of dataLinkBlocksize on a circuit which will beused to form an Intermediate system to Intermediate system adjacency is set to a value greater than or equal to themaximum of the LSPBufferSize characteristics listedabove. If this is not done, the adjacency will fail to initialise. It is not possible to enforce this requirement, since itis not known until initialisation time whether or not theneighbour on the circuit will be an End system or an Intermediate system. An End system adjacency may operate with a lower value for dataLinkBlocksize.d)If the value of the circuitTransmitPassword for thecircuit is non-null, then the IS shall include theAuthentication Information field in the transmittedIIH PDU, indicating an Authentication Type ofPassword and containing the circuitTransmitPassword as the authentication value.8.2.4 Receiving Point to Point IIH PDUs8.2.4.1 PDU Acceptance TestsOn receipt of a Point-to-Point IIH PDU, perform the following PDU acceptance tests:a)If the IIH PDU was received over a circuit whose externalDomain attribute is set True, the IS shall discard the PDU.b)If the ID Length field of the PDU is not equal to thevalue of the IS's routeingDomainIDLength, thePDU shall be discarded and an iDFieldLengthMismatch notification generated.c)If the set of circuitReceivePasswords for this circuit is non-null, then perform the following tests:1)If the PDU does not contain the AuthenticationInformation field then the PDU shall be discardedand an authenticationFailure notification generated.2)If the PDU contains the Authentication Information field, but the Authentication Type is notequal to Password, then the PDU shall be accepted unless the IS implements the authenticatiion procedure indicated by the AuthenticationType. In this case whether the IS accepts or ignores the PDU is outside the scope of this International Standard.3)Otherwise, the IS shall compare the password inthe received PDU with the passwords in the set ofcircuitReceivePasswords for the circuit onwhich the PDU was received. If the value in thePDU matches any of these passwords, the IS shallaccept the PDU for further processing. If the valuein the PDU does not match any of the circuitReceivePasswords, then the IS shall ignore thePDU and generate an authenticationFailure notification.8.2.4.2 IIH PDU ProcessingWhen a Point to Point IIH PDU is received by an Intermediate system, the area addresses of the two IntermediateSystems shall be compared to ascertain the validity of theadjacency. If the two Intermediate systems have an area address in common, the adjacency is valid for all combinations of Intermediate system types (except where a Level 1Intermediate system is connected to a Level 2 Intermediatesystem with manualL2OnlyMode set True). However,if they have no area address in common, the adjacency isonly valid if both Intermediate systems are Level 2, and theIS shall mark the adjacency as Level 2 Only. This is described in more detail below.On receipt of a Point to Point IIH PDU, each of the area addresses from the PDU shall be compared with the set ofarea addresses in the manual
Area
Addresses attribute.a)If a match is detected between any pair the followingactions are taken.1)If the local system is of iSType L1
Inter
mediate
Sys
tem the IS shall perform the action indicatedby Table 4.2)If the local system is of iSType L2
Intermediate
System and the Circuit manualL2OnlyModehas the value False, the IS shall perform the action indicated by Table 5.3)If the local system is of iSType L2
Intermediate
System and the Circuit manualL2OnlyModehas the value True, the IS shall perform the action indicated by Table 6.b)If a no match is detected between any pair, the following 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 generate 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 ISshall delete the adjacency and generate an adjacencyStateChange (Down Area Mismatch)notification .3)If the local system is of iSType L2
Intermediate
System the IS shall perform the action indicatedby Table 7 (irrespective of the value of manualL2OnlyMode for this circuit).c)If the action taken is Up, as detailed in the tablesreferenced above, the IS shall compare the Source IDfield of the PDU with the local systemID.1)If the local Intermediate system has the higherSource ID, the IS shall set the Circuit CircuitIDstatus to the concatenation of the local systemIDand the Local Circuit ID (as sent in the Local Circuit ID field of point to point IIH PDUs from thisIntermediate System) of this circuit.2)If the remote Intermediate system has the higherSource ID, the IS shall set the Circuit CircuitIDstatus to the concatenation of the remote system'sSource ID (from the Source ID field of the PDU),and the remote system's Local Circuit ID (from theLocal Circuit ID field of the PDU).3)If the two source IDs are the same (i.e. the systemis initialising to itself), the local systemID is used.NOTE The circuitID status is not used to generatethe Local Circuit ID to be sent in the Local CircuitID field of IIH PDUs transmitted by this Intermediate system. The Local Circuit ID value is assignedonce, when the circuit is created and is not subsequently changed.d)If the action taken is Accept and the new value computed for the circuitID is different from that in the existing adjacency, the IS shall1)generate an adjacencyStateChange(Down) notification, and2)delete the adjacency.e)If the action taken is Up or Accept the IS shall1)copy the Adjacency neighbourAreas entriesfrom the PDU,2)set the holdingTimer to the value of the HoldingTime from the PDU, and3)set the neighbourSystemID to the value of theSource ID from the PDU.8.2.5 Monitoring Point-to-point AdjacenciesThe IS shall keep a holding time (adjacency holding
Timer) for the point-to-point adjacency. The value of theholding
Timer shall be set to the Holding Time as reportedin the Holding Timer field of the Pt-Pt IIH PDU. If a neighbour is not heard from in that time, the IS shalla)purge it from the database; andb)generate an adjacencyStateChange (Down) notification.8.3 ISO 8208 Subnetworks8.3.1 Network Layer ProtocolsThe way in which the underlying service assumed by ISO8473 is provided for ISO 8208 subnetworks is described inclause 8 of ISO 8473. This defines a set of Subnetwork Dependent Convergence Functions (SNDCFs) that relate theservice provided by specific individual ISO-standardsubnetworks to the abstract underlying service defined inclause 5.5 of ISO 8473. In particular 8.4.3 describes theSubnetwork Dependent Convergence Functions used withISO 8208 Subnetworks.8.3.2 SVC Establishment8.3.2.1 Use of ISO 8473 Subnetwork DependentConvergence FunctionsSVCs shall be established according to the procedures defined in the ISO 8208 Subnetwork Dependent ConvergenceFunctions of ISO 8473 (this may be on system managementaction or on arrival of data depending on the type of circuit). The Call Request shall contain a Protocol Discriminator specifying ISO 8473 in the first octet of Call Userdata.In the case of a static circuit, an SVC shall be establishedonly upon system management action. The IS shall useneighbourSNPAAddress as the called SNPA address.In the case of a DA circuit, the call establishment procedures are initiated by the arrival of traffic for the circuit.8.3.2.2 Dynamically Assigned CircuitsA dynamically assigned circuit has multiple adjacencies,and can therefore establish SVCs to multiple SNPAs. Ingeneral the SNPA address to which a call is to be established can be derived from the NSAP to which an NPDU isto be forwarded. In the case where all the NSAPs accessibleover the ISO 8208 subnetwork have IDIs which are theirSNPA addresses, the correct SNPA can be ascertained byextracting 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 oftheir point of attachment to the ISO 8208 subnetwork. TheIDI may refer to some other SNPA address which is sub-optimally connected to the target NSAP (or not even connected at all), or the IDP may not contain an X.121 addressat all (e.g. ISO DCC scheme). In these cases the IS shallhave pre-configured information relating an IDP (or addressprefix) to a particular SNPA address to call.This is achieved, as described in 8.1, by additional information contained in the Reachable Address managed object.The address extraction algorithm may be specified to extract the IDI portion where the IDI is the required X.121 address. An example of a set of Reachable Addresses isshown in Table 8.Table 8 - Example of address prefixesAddress Prefix
3937 aaaaa37*37 DSNPA Address123XBYExtract X.121 SNPA addressR, S, TThis is interpreted as follows:a)For the ISO DCC prefix 39 123, call the SNPA address X.b)For the X.121 IDI address prefix 37 aaaaa, don'tcall aaaaa, but call B instead.c)For all IDPs based on SNPAs with DNIC D (i.e. withaddress prefix 37 D), call the address Y (whichwould probably be a gateway to a subnetwork withDNIC D).d)For any other X.121 IDI (i.e. address prefix 37) callthe SNPA whose address is used as the IDI.e)Anything else (* in table 8) call one of the SNPAaddresses R, S or T. These would typically be theSNPA addresses of Level 2 Intermediate Systemsthrough which any other addresses could potentiallybe reached.NOTE - If a DA circuit is defined with a reachable addressprefix which includes the addresses reachable over a DCMor STATIC circuit, the cost(s) for the DA circuit must begreater than those of the STATIC circuit. If this is not thecase, the DA circuit may be used to establish a call to the remote SNPA supporting the STATIC circuit, which wouldthen (wrongly) assume it was the STATIC circuit.8.3.2.3 Initiating Calls (Level 2 IntermediateSystems)When an NPDU is to be forwarded on a dynamically assigned circuit, for destination NSAP address D, the IS shall:a)Calculate D's subnetwork address, either as explicitlystated in the circuit database, or as extracted from theIDP.1)If this system is an ES and there is an entry in theRedirectCache or ReversePathCache for D, use thesubnetwork address in the cache entry.2)If this system is an ES or Level 2 Intermediate system, and the address matches one of the listedreachable address prefixes (including *, if present), the subnetwork address is that specified according to the mappingType attribute (eitherManual, indicating that the set of addresses inthe sNPAAddresses attribute of that ReachableAddress are to be used, or Algorithm, indicatingthat it is to be extracted from the IDP using thespecified algorithm). If multiple SNPA addressesare specified, and there is already an adjacency upto one of those SNPA addresses, then choose thatsubnetwork address, otherwise choose thesubnetwork address with the oldest timestamp asdescribed in 8.3.2.4.3)If the address does not match one of the listedreachable address prefixes (and there is no * entry), invoke the ISO 8473 Discard PDU function.b)Scan the adjacencies for one already open to D'ssubnetwork address (i.e. reserveTimer has not yetexpired). If one is found, transmit the NPDU on thatadjacency.c)If no adjacency has a call established to the requiredsubnetwork address, but there is a free adjacency, attempt to establish the call using that subnetwork address.d)If there is no free adjacency invoke the ISO 8473 Discard PDU function.NOTE Where possible, when an adjacency is reserved(when an SVC has been cleared as a result of theidleTimer expiring, but the reserveTimer has not yet expired), resources within the subnetwork service providershould be reserved, in order to minimise the probabilitythat the adjacency will not be able to initiate a call whenrequired.8.3.2.4 Call Attempt FailuresThe Reachable Address managed objects may contain a setof SNPA addresses, each of which has an associated time-stamp. The time-stamps shall be initialised to infinitelyold.Some of the SNPAs in this set may be unreachable. If a callattempt fails to one of the SNPA addresses listed, the ISshall mark that entry in the list with the time of the latestfailed attempt. When an SNPA address is to be chosen fromthe list, the IS shall choose the one with the oldest time-stamp , unless the oldest time-stamp is more recent thanrecallTimer. If the oldest time-stamp is more recent thanrecallTimer, all SNPAs in the set shall be assumed temporarily unreachable and no call attempt is made. The IS shallinstead invoke the ISO 8473 Discard PDU function.When attempting to establish a connection to a single specific subnetwork address (not through one of a set of SNPAaddresses), if a call attempt to a particular SNPA address,A, fails for any reason, the IS shall invoke the ISO 8473Discard PDU function. Additionally the adjacency onwhich the call attempt was placed shall be placed inFailed state, and the recall timer set. Until it expires, theIS shall not attempt call establishment for future NPDUs tobe forwarded over subnetwork address A, but instead the ISshall invoke the ISO 8473 Discard PDU function.When the recall timer expires, the IS shall free the adjacency for calls to a different destination or retry attempts tosubnetwork address A.NOTE - If an implementation can store the knowledge ofSNPA addresses that have failed along with the time sincethe attempt was made in a location other than the adjacencyon which the call was attempted, then that adjacency can beused for other calls.8.3.3 Reverse Path Forwarding on DA CircuitsWhere a subdomain is attached to a Connection-orientedsubnetwork by two or more SNPAs, the IDP for the addresses within the subdomain may be chosen to be constructed 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 IDPcould be chosen; e.g. ISO DCC.) Traffic to the subdomainfrom some other SNPA will cause a call to be established tothe SNPA corresponding to the IDP of the addresses in thesubdomain. Traffic from the subdomain may use either ofthe SNPAs depending on the routeing decisions made bythe subdomain. This is illustrated in the diagram below (figure 5).Figure 5 - B.xB.yC.zISO 8208 SubnetworkBACExample for reverse pathforwardingThe subdomain is attached to the connection-orientedsubnetwork via SNPAs A and B. The addresses on thesubdomain are constructed using the SNPA address of B asthe IDI. If traffic for C.z is sent from B.x, a call will be established from A to C. The reverse traffic from C.z to B.xwill cause another call to be established from C to B. Thustwo SVCs have been established where only one is required.This problem is prevented by the local system retaining acache (known as the ReversePathCache) of NSAP addresses from which traffic has been received over each adjacency. When it has traffic to forward over the connection-oriented subnetwork, the IS shall it first check to see if thedestination NSAP is in the cache of any of its adjacencies,and if so forwards the traffic over that adjacency. An NSAPshall only be added to the cache when the remote SNPA address of the adjacency over which it is received differs fromthe SNPA address to be called which would be generatedby checking against the Circuit Reachable Addresses managed objects. If the cache is full, the IS shall overwrite theleast recently used entry. The ReversePathCache, if implemented, shall have a size of at least one entry. The IS shallpurge the cache when the adjacency is taken down (i.e.when the reserve timer expires).8.3.4 Use of ISO 9542 on ISO 8208subnetworksSTATIC and DA circuits are equivalent to point to pointlinks, and as such permit the operation of ISO 9542 as described for point to point links in 8.2.For DA circuits, it is impractical to use ISO 9542 to obtainconfiguration information, such as the location of Intermediate systems, since this would require calls to be established 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 orISH PDU, and the circuit shall complete initialisation without waiting for their arrival.The IS shall not send Point to point IIH PDU on DA circuits. The IS shall ignore receipt of a point-point IIH PDU.(This would only occur if a STATIC or DA circuit becameerroneously connected to an SVC being used for a DA circuit.)8.3.5 Interactions with the Update ProcessA dynamically assigned circuit contains a list of <reachableaddress prefix, cost, SNPA address> tuples. Also, each dynamically assigned circuit has a specified call establishmentcost measured by call
Estab
lish
ment
Met
rick (where k indexes the four defined metrics). The call establishment costis always an internal metric, and is therefore directly comparable with the reachable address metric only if the reachable address metric is also internal.When the circuit is enabled, the Subnetwork Dependentfunctions in an Intermediate system shall report (to the Update Process) adjacency cost change events for all address prefixes in the circuit Reachable Address managedobject, together with the Reachable address metrick + Deltak increment. If reachable address metrick is internal, thenDeltak = call
Estab
lish
ment
Met
rick. If reachable addressmetrick is external, then Deltak = 0.This causes this information to be included in subsequentlygenerated LSPs as described in 7.3.3.2.Routeing PDUs (LSPs and Sequence number PDUs) shallnot be sent on dynamically assigned circuits.NOTE - In the following sub-clauses, it is assumed that theReachable Addresses referenced are only those which havebeen enabled (i.e. that have state On), and whose parentcircuit is also in state On.8.3.5.1 Adjacency CreationAfter an SVC to SNPA address D is successfully established and a new adjacency created for it (whether it was initiated by the local or the remote system), if call
Estab
lish
ment
Met
rickIncrement is greater than 0, the IS shall scanthe circuit Reachable Address managed objects for alladdressPrefixes listed with D as (one of) the sNPAAddress(es).For Reachable Addresses with mappingType Algorithm, the IS shall construct an implied address prefix88i.e. someaddress prefix which matches the addressPrefix of the ReachableAddress, and which would generate the SNPA Address D when the extraction algorithm is appliedfrom the actual remote SNPA address D and the address extraction algorithm. The IS shall generate an Adjacency costchange event for each such address prefix (both actual andimplied) with the Reachable Address metrick (without theadded call
Estab
lish
ment
Met
rickIncrement). This causesinformation that those address prefixes are reachable withthe lower cost to be included in subsequently generatedLSPs. The effect of this is to encourage the use of alreadyestablished SVCs where possible.8.3.5.2 Adjacency DeletionWhen the adjacency with sNPAAddress D is freed (Reserve Timer has expired, or the adjacency is deleted by System Management action) then if call
Estab
lish
ment
Met
rickIncrement is greater than 0, the IS shall scan the Circuit Reachable Address managed objects for all those withmappingType Manual and (one of) their sNPAAddresses equal to D. The IS shall generate Adjacencycost change events to the Update Process for all such address prefixes with the Reachable Address metrick + Deltakincrement (where Deltak is the same as defined above). ForReachable Addresses with mappingType X.121 forwhich it is possible to construct an implied address prefixas above, the IS shall generate an adjacencyStateChange notification for that implied prefix.A cost change event shall only be generated when the countof the number of subnetwork addresses which have an established SVC changes between 1 and 0.8.3.5.3 Circuit Call Establishment IncrementChangeOn a dynamically assigned circuit, when system management changes the Circuit call
Estab
lish
ment
Met
rickIncrement for that circuit, the IS shall generate adjacency cost change events for all address prefixes affectedby the change (i.e. those for which calls are not currentlyestablished).The IS shall scan all the Reachable Address managed objects of that Circuit. If the Reachable Address hasmappingType X.121, the IS shall generate an adjacency cost change event for that name with the Reachable Address metrick + the new value of Deltak. If (basedon the new value of callEstab
lish
ment
Met
rickIncrement)the Reachable Address has mappingType Manual, theIS shall scan all the Adjacencies of the Circuit for an Adjacency with sNPAAddress equal to (one of) the sNPAAddresses of that Reachable Address. If no such adjacency is found the IS shall generate an adjacency costchange event for that name with the Reachable Addressmetrick + the new value of Deltak (based on the new valueof callEstlishmentMetrickIncrement).8.3.5.4 Reachable Address Cost ChangeWhen the metrick characteristic of a Reachable Address instate On is changed by system management, the IS shallgenerate cost change events to the Update Process to reflectthis change.If the Reachable Address has mappingType Manual,the IS shall scan all the Adjacencies of the Circuit for anAdjacency with sNPAAddress equal to (one of) the sNPAAddresses of that Reachable Address. If one or moresuch adjacencies are found, the IS shall generate an adjacency cost change event for that name with the newReachable Address metrick. If no such adjacency is foundthe IS shall generate an adjacency cost change event forthat name with the new Reachable Address metrick.If the Reachable Address has mappingType X.121, theIS shall generate an adjacency cost change event for thatname 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 Circuitwith an sNPAAddress for which an implied address prefix can be generated for this Reachable Address, the ISshall generate an adjacency cost change event for that implied address prefix and the new Reachable Address metrick.8.3.5.5 Disabling a Reachable AddressWhen a Reachable Address managed object is disabled viamanagement action, the IS shall generate an Adjacencydown event to the Update Process for the name of thatReachable Address and also for any implied prefixes associated with that Reachable Address.8.3.5.6 Enabling a Reachable AddressWhen a Reachable Address is enabled via system management action, the IS shall generate Adjacency cost changeevents as described for Reachable Address cost change in8.3.5.4 above.8.4 Broadcast Subnetworks8.4.1 Broadcast Subnetwork IIH PDUsAll Intermediate systems on broadcast circuits (bothLevel 1 and Level 2) shall transmit LAN IIH PDUs as described in 8.4.3. Level 1 Intermediate systems shall transmitonly Level 1 LAN IIH PDUs. Level 2 Intermediate Systemson circuits with manualL2OnlyMode set to the valueTrue, shall transmit only Level 2 LAN IIH PDUs.Level 2 Intermediate systems on circuits with manualL2OnlyMode set to the value False, shall transmitboth.Level n LAN IIH PDUs contain the transmitting Intermediate system's ID, holding timer, Level n Priority andmanual
Area
Addresses, plus a list containing the lANAddresses of all the adjacencies of neighbourSystemType Ln Intermediate System (in state Initialising orUp) on this circuit.LAN IIH PDUs shall be padded (with trailing PAD optionscontaining arbitrary valued octets) so that the SNSDU containing the IIH PDU has a length of at least maxsize- 1 octets99The minimum length of PAD which may be added is 2 octets, sincethat is the size of the option header. Where possible the PDU should be padded tomaxsize, but if the PDU length is maxsize- 1 octets no padding ispossible (or required). where maxsize for Level 1 IIH PDUs is the maximumof-dataLinkBlocksize-originating
L1
LSP
Buf
fer
Sizeand for Level 2 IIH PDUs is the maximum of-dataLinkBlocksize-originatingL2LSPBufferSizeThis is done to ensure that an adjacency will only beformed between systems which are capable of exchangingPDUs of length up to maxsize octets. In the absence of thischeck, it would be possible for an adjacency to exist with alower maximum block size, with the result that some LSPsand SNPs (i.e. those longer than this maximum, but lessthan maxsize) would not be exchanged.NOTE - An example of a topology where this could occur isone where an extended LAN is constructed from LAN segments with different maximum block sizes. If, as a result ofmis-configuration or some dynamic reconfiguration, a pathexists between two Intermediate systems on separate LANsegments having a large maximum block size, which involves transit of a LAN segment with a smaller maximumblock size, loss of larger PDUs will occur if the Intermediatesystems continue to use the larger maximum block size. It isbetter to refuse to bring up the adjacency in these circumstances.Level 1 Intermediate systems shall transmit Level 1 LANIIH PDUs to the multi-destination address AllL1ISs, andalso listen on that address. They shall also listen for ESHPDUs on the multi-destination address AllIntermediateSystems. The list of neighbour Intermediate systems shall contain only Level 1 Intermediate Systems within the samearea. (i.e. Adjacencies of neighbourSystemType L1 Intermediate System.)Level 2 Only Intermediate systems (i.e. Level 2 Intermediate systems which have the Circuit manualL2OnlyModecharacteristic set to the value True) shall transmit Level 2LAN IIH PDUs to the multi-destination address AllL2ISs,and also listen on that address. The list of neighbour Intermediate systems shall contain only Level 2 Intermediatesystems. (i.e. Adjacencies of neighbourSystemType L2Intermediate System.)Level 2 Intermediate systems (with manualL2OnlyModeFalse) shall perform both of the above actions. SeparateLevel 1 and Level 2 LAN IIH PDUs shall be sent to themulti-destination addresses AllL1ISs and AllL2ISs describing the neighbour Intermediate systems for Level 1and Level 2 respectively. Separate adjacencies shall be created by the receipt of Level 1 and Level 2 LAN IIH PDUs.8.4.1.1 IIH PDU Acceptance TestsOn receipt of a Broadcast IIH PDU, perform the followingPDU acceptance tests:a)If the IIH PDU was received over a circuit whose externalDomain attribute is True, the IS shall discardthe PDU.b)If the ID Length field of the PDU is not equal to thevalue of the IS's routeingDomainIDLength, thePDU shall be discarded and an iDFieldLengthMismatch notification generated.c)If the set of circuitReceivePasswords for this circuit is non-null, then perform the following tests:1)If the PDU does not contain the AuthenticationInformation field then the PDU shall be discardedand an authenticationFailure notification generated.2)If the PDU contains the Authentication Information field, but the Authentication Type is notequal to Password, then the PDU shall be accepted unless the IS implements the authenticatiion procedure indicated by the AuthenticationType. In this case whether the IS accepts or ignores the PDU is outside the scope of this International Standard.3)Otherwise, the IS shall compare the password inthe received PDU with the passwords in the set ofcircuitReceivePasswords for the circuit onwhich the PDU was received. If the value in thePDU matches any of these passwords, the IS shallaccept the PDU for further processing. If the valuein the PDU does not match any of the circuitReceivePasswords, then the IS shall ignore thePDU and generate an authenticationFailure notification.8.4.1.2 Receipt of Level 1 IIH PDUsOn receipt of a Level 1 LAN IIH PDU on the multi-destination address AllL1ISs, the IS shall compare each ofthe area addresses, from the received IIH PDU with the setof area addresses in the manual
Area
Addresses characteristic. If a match is not found between any pair (i.e. the local and remote system have no area address in common),the IS shall reject the adjacency and generate an initialisationFailure (area mismatch) notification. Otherwise (amatch is found) the IS shall accept the adjacency and set theAdjacency neighbourSystemType to L1 IntermediateSystem.8.4.1.3 Receipt of Level 2 IIH PDUsOn receipt of a Level 2 LAN IIH PDU on the multi-destination address AllL2ISs, the IS shall accept the adjacency, and set the Adjacency neighbourSystemType toL2 Intermediate System.8.4.1.4 Existing AdjacenciesWhen a Level n LAN IIH PDU (Level 1 or Level 2) is received from an Intermediate system for which there is already an adjacency witha)the Adjacency lANAddress equal to the MAC Sourceaddress of the PDU, andb)the Adjacency neighbourSystemID equal to theSource ID field from the PDU andc)the neighbourSystemType equal to Ln Intermediate System,the IS shall update the holding timer, LAN Priority andneighbourAreas according to the values in the PDU.8.4.1.5 New AdjacenciesWhena)a Level n LAN IIH PDU (Level 1 or Level 2) is received (from Intermediate system R), andb)there is no adjacency for which the Adjacency lANAddress is equal to the MAC Source address of thePDU; andc)the Adjacency neighbourSystemID is equal to theSource ID field from the PDU, andd)neighbourSystemType is Ln Intermediate System,the IS shall create a new adjacency. However, if there is insufficient space in the adjacency database, to permit thecreation of a new adjacency the IS shall instead perform theactions described in 8.4.2.The IS shalla)set neighbourSystemType status to Ln Intermediate System (where n is the level of the IIH PDU),b)set the holding timer, LAN Priority, neighbourIDand neighbourAreas according to the values in thePDU., andc)set the lANAddress according to the MAC source address of the PDU.The IS shall set the state of the adjacency to initialising,until it is known that the communication between this system and the source of the PDU (R) is two-way. However Rshall be included in future Level n LAN IIH PDUs transmitted by this system.When R reports this circuit's lANAddress in its Level nLAN IIH PDUs, the IS shalla)set the adjacency's state to Up, andb)generate an adjacencyStateChange (Up) notification.The IS shall keep a separate Holding Time (Adjacencyholding
Timer) for each Ln Intermediate System adjacency. The value of holding
Timer shall be set to the Holding Time as reported in the Holding Timer field of theLevel n LAN IIH PDUs. If a neighbour is not heard from inthat time, the IS shalla)purge it from the database; andb)generate an adjacencyStateChange (Down) notification.If a Level n LAN IIH PDU is received from neighbour N,and this system's lANAddress is no longer in N's IIHPDU, the IS shalla)set the adjacency's state to initialising, andb)generate an adjacencyStateChange (Down) notification.8.4.2 Insufficient Space in Adjacency DatabaseIf an IS needs to create a new Intermediate system adjacency, but there is insufficient space in the adjacency database, the adjacency of neighbourSystemType Ln Intermediate System with lowest lANPriority (or if more thanone adjacency has the lowest priority, the adjacency withthe lowest lANAddress, from among those with the lowestpriority) shall be purged from the database. If the new adjacency would have the lowest priority, it shall be ignored,and a rejectedAdjacency notification generated.If an old adjacency must be purged, the IS shall generate anadjacencyStateChange (Down) notification for that adjacency. After the Subnetwork Independent Functions issuean adjacency down complete, the IS may create a new adjacency.8.4.3 Transmission of LAN IIH PDUsA Level 1 IS shall transmit a Level 1 LAN IIH PDU immediately when any circuit whose externalDomain attributeis False has been enabled. A Level 2 Intermediate System shall transmit a Level 2 LAN IIH PDU. A Level 2 Intermediate System shall also transmit a Level 1 LAN IIHPDU unless the circuit is marked as manualL2OnlyModeTrue.The IS shall also transmit a LAN IIH PDU when at least 1second has transpired since the last transmission of a LANIIH PDU of the same type on this circuit by this systemand:a)iSIS
Hello
Timer seconds have elapsed1010Jitter is applied as described in 10.1. since the lastperiodic LAN IIH PDU transmissionThe Holding Time is set to ISISHoldingMultiplier WiSIS
Hello
Timer. For a Designated Intermediate System the value of dRISIS
Hello
Timer1111 In this case jitter is not applied, since it would result inintervals of less than one second. is used insteadof iSISHelloTimer. The Holding Time for this PDUshall therefore be set to ISISHoldingMultiplier WdR
ISIS
Hello
Timer seconds. This permits failingDesignated Intermediate Systems to be detected morerapidly,orb)the contents of the next IIH PDU to be transmittedwould differ from the contents of the previous IIHPDU transmitted by this system, orc)this system has determined that it is to become or resign as LAN Designated Intermediate System for thatlevel.To minimise the possibility of the IIH PDU transmissionsof all Intermediate systems on the LAN becoming synchronised, the Hello Time timer shall only be reset when a IIHPDU is transmitted as a result of timer expiration, or on becoming or resigning as Designated Intermediate System.Where an Intermediate system is transmitting both Level 1and Level 2 LAN IIH PDUs, it shall maintain a separatetimer (separately jittered) for the transmission of theLevel 1 and Level 2 IIH PDUs. This avoids correlation between the Level 1 and Level 2 IIH PDUs and allows the reception buffer requirements to be minimised.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 circuitTransmitPassword as the authenticationvalue.8.4.4 LAN Designated Intermediate SystemsA LAN Designated Intermediate System is the highest priority Intermediate system in a particular set on the LAN,with numerically highest MAC source lANAddress breaking ties. (See 7.1.5 for how to compare LAN addresses.)There are, in general, two LAN Designated IntermediateSystems on each LAN, namely the LAN Level 1 Designated Intermediate System and the LAN Level 2 Designated Intermediate System. They are elected as follows.a)Level 1 Intermediate systems elect the LAN Level 1Designated Intermediate System.b)Level 2 Only Intermediate systems (i.e. Level 2 Intermediate Systems which have the Circuit manual
L2
Only
Mode characteristic set to the value True)elect the LAN Level 2 Designated Intermediate System.c)Level 2 Intermediate systems (with manualL2OnlyMode False) elect both the LAN Level 1and LAN Level 2 Designated Intermediate Systems.The set of Intermediate systems to be considered includesthe local Intermediate system, together with all Intermediate systems of the appropriate type as follows.a)For the LAN Level 1 Designated Intermediate System,it is the set of Intermediate systems from which LANLevel 1 IIH PDUs are received and to which Level 1adjacencies exist in state Up. When the local system either becomes or resigns as LAN Level 1 Designated Intermediate System, the IS shall generate a lanLevel1
Designated
Inter
mediate
Sys
tem
Changenotification. In addition, when it becomes LANLevel 1 Designated Intermediate System, it shall perform the following actions.1)Generate and transmit Level 1 pseudonode LSPsusing the existing End system configuration.2)Purge the Level 1 pseudonode LSPs issued by theprevious LAN Level 1 Designated IntermediateSystem (if any) as described in 7.2.3.3)Solicit the new End system configuration as described in 8.4.5.b)For the LAN Level 2 Designated Intermediate System,it is the set of Intermediate systems from which LANLevel 2 IIH PDUs are received and to which Level 2adjacencies exist in state Up. When the local system either becomes or resigns as LAN Level 2 Designated Intermediate System, the IS shall generate a lanLevel2
Designated
Inter
mediate
System
Changenotification. In addition, when it becomes LANLevel 2 Designated Intermediate System, it shall perform the following actions.1)Generate and transmit a Level 2 pseudonode LSP.2)Purge the Level 2 pseudonode LSPs issued by theprevious LAN Level 2 Designated IntermediateSystem (if any) as described in 7.2.3.When an Intermediate system resigns as LAN Level 1 orLevel 2 Designated Intermediate System it shall performthe actions on Link State PDUs described in 7.2.3.When the broadcast circuit is enabled on an Intermediatesystem the IS shall perform the following actions.a)Commence sending IIH PDUs with the LAN ID fieldset to the concatenation of its own systemID and itslocally assigned one octet Local Circuit ID.b)Solicit the End system configuration as described in8.4.5.c)Start listening for ISO 9542 ISH PDUs and ESHPDUs and acquire adjacencies as appropriate. Do notrun the Designated Intermediate System election process.d)After waiting iSIS
Hello
Timer * 2 seconds, run theLevel 1 and or the Level 2 Designated IntermediateSystem election process depending on the Intermediate system type. This shall be run subsequently whenever an IIH PDU is received or transmitted as described in 8.4.3. (For these purposes, the transmissionof the system's own IIH PDU is equivalent to receiving it). If there has been no change to the informationon which the election is performed since the last timeit was run, the previous result can be assumed. Therelevant information is1)the set of Intermediate system adjacency states,2)the set of Intermediate System priorities (includingthis system's) and3)the existence (or otherwise) of at least one UpEnd system (not including Manual Adjacencies) orIntermediate system adjacency on the circuit.An Intermediate system shall not declare itself to be a LANDesignated Intermediate system of any type until it has atleast one Up End system (not including Manual Adjacencies) or Intermediate system adjacency on the circuit. (Thisprevents an Intermediate System which has a defective receiver and is incapable of receiving any PDUs from erroneously electing itself LAN Designated Intermediate System.)The LAN ID field in the LAN IIH PDUs transmitted by thissystem shall be set to the value of the LAN ID field reportedin the LAN IIH PDU (for the appropriate level) receivedfrom the system which this system considers to be the Designated Intermediate System. This value shall also bepassed to the Update Process, as the pseudonode ID, to enable Link State PDUs to be issued for this system claimingconnectivity to the pseudonode.If this system, as a result of the Designated IntermediateSystem election process, considers itself to be designatedIntermediate System, the LAN ID field shall be set to theconcatenation of this system's own system ID and the locally assigned one octet Local Circuit ID.8.4.5 Soliciting the ES configurationWhen there is a change in the topology or configuration ofthe LAN (for example the partitioning of a LAN into twosegments by the failure of a repeater or bridge), it is desirable for the (new) Designated Intermediate System to acquire the new End system configuration of the LAN asquickly as possible in order that it may generate Link StatePDUs which accurately reflect the actual configuration.This is achieved as follows.When the circuit is enabled, or the Intermediate system detects a change in the set of Intermediate systems on theLAN, or a change in the Designated Intermediate SystemID, the IS shall initiate a poll of the ES configuration byperforming the following actions.a)Delay a random interval between 0 and iSIS
Hello
Timer seconds. (This is to avoid synchronisation withother Intermediate systems which have detected thechange.)b)If (and only if) an Intermediate System had been removed from the set of Intermediate systems on theLAN, reset the entryRemainingTime field in theendSystemIDs adjacency database record of all adjacencies on this circuit to the value(iSIS
Hello
Timer + pollESHelloRate) WHoldingMultiplieror the existing value whichever is the lower. (Thiscauses any End systems which are no longer presenton the LAN to be rapidly timed out, but not beforethey have a chance to respond to the poll.)c)Transmit HoldingMultiplier ISH PDUs for each NETpossessed by the Intermediate system with a Suggested ES Configuration Timer value of poll
ES
Hello
Rate at an interval between them of iSIS
Hello
Timer seconds and a holding time of hello
Timer *HoldingMultiplier.d)Resume sending ISH PDUs at intervals of hello
Timer seconds with a Suggested ES ConfigurationTimer value of defaultESHelloTimer.8.4.6 Receipt of ESH PDUsDatabase of EndSystemsAn IS shall enter an End system into the adjacency databasewhen an ESH PDU is received from a new data link address. If an ESH PDU is received with the same data linkaddress as a current adjacency, but with a different NSAPaddress, the new address shall be added to the adjacency,with a separate timer. A single ESH PDU may contain morethan one NSAP address. When a new data link address orNSAP address is added to the adjacency database, the ISshall generate an adjacencyStateChange (Up) notification on that adjacency.The IS shall set a timer for the value of the Holding Timefield in the received ESH PDU. If another ESH PDU is notreceived from the ES before that timer expires, the ES shallbe purged from the database, provided that the SubnetworkIndependent Functions associated with initialising the adjacency have been completed. Otherwise the IS shall clear theadjacency as soon as those functions are completed.When the adjacency is cleared, the Subnetwork Independent Functions shall be informed of an adjacencyStateChange (Down) notification, and the adjacency can be re-used after the Subnetwork Independent Functions associated with bringing down the adjacency have been completed.9 Structure and Encoding of PDUsThis clause describes the PDU formats of the Intra-DomainRouteing protocol.9.1 General encoding RulesOctets in a PDU are numbered starting from 1, in increasingorder. Bits in a octet are numbered from 1 to 8, where bit 1is the least significant bit and is pictured on the right. Whenconsecutive octets are used to represent a number, the loweroctet number has the most significant value.Fields marked Reserved (or simply R) are transmitted aszero, and ignored on receipt, unless otherwise noted.Values are given in decimal. All numeric fields are unsigned integers, unless otherwise noted.9.2 Encoding of Network LayerAddressesNetwork Layer addresses (NSAP addresses, NETs, area addresses and Address Prefixes) are encoded in PDUs according to the preferred binary encoding specified inISO 8348/Add.2; the entire address, taken as a whole is represented explicitly as a string of binary octets. This string isconveyed in its entirety in the address fields of the PDUs.The rules governing the generation of the preferred binaryencoding are described in ISO 8348/Add.2. The address sogenerated is encoded with the most significant octet (i.e. theAFI) of the address being the first octet transmitted, and themore significant semi-octet of each pair of semi-octets inthe address is encoded in the more significant semi-octet ofeach octet (i.e. in the high order 4 bits). Thus the address/371234 is encoded asFigure 6 - 111No. of Octets371234Address encoding example9.3 Encoding of SNPA AddressesSNPA addresses (e.g. lANAddress) shall be encoded according to the rules specified for the particular type ofsubnetwork being used. In the case of an ISO 8802subnetwork, the SNPA address is the MAC address definedin ISO 10039, which is encoded according to the binaryrepresentation of MAC addresses specified in ISO 10039.9.4 PDU TypesThe types of PDUs are:-Level 1 LAN IS to IS Hello PDU-Level 2 LAN IS to IS Hello PDU-Point-to-Point IS to IS Hello PDU-Level 1 Link State PDU-Level 2 Link State PDU-Level 1 Complete Sequence Numbers PDU-Level 2 Complete Sequence Numbers PDU-Level 1 Partial Sequence Numbers PDU-Level 2 Partial Sequence Numbers PDUThese are described in the following subclauses.9.5 Level 1 LAN IS to IS Hello PDUThis PDU is multicast by Intermediate systems on broadcast circuits to the multi-destination address AllL1ISs.The purpose of this PDU is for Intermediate systems onbroadcast circuits to discover the identity of other Level 1Intermediate systems on that circuit. Trailing Pad optionsare inserted to make PDU Length equal to at least maxsize- 1 where maxsize is the maximum of-dataLinkBlocksize-originating
L1
LSP
Buf
fer
Size(see 8.4.1). 11No. of Octets1111111ID Length2ID Length +121VARIABLEIntradomain RouteingProtocol DiscriminatorLength IndicatorVersion/Protocol ID ExtensionID LengthPDU TypeRRRVersionECOUser ECOReserved/Circuit TypeSource IDHolding TimeLAN IDPDU LengthPriorityRVARIABLE LENGTH FIELDS-Intradomain Routeing Protocol Discriminatorarchitectural constant-Length Indicator Length of the fixed header in octets-Version/Protocol ID Extension 1-ID Length Length of the ID field of NSAP addresses and NETs used in this routeing domain. Thisfield shall take on one of the following values:7An integer between 1 and 8, inclusive, indicatingan ID field of the corresponding length7The value zero, which indicates a 6 octet ID fieldlength7The value 255, whhich means a null ID field (i.e.zero length)All other values are illegal and shall not be used.-PDU Type (bits 1 through 5) 15. Note bits 6, 7 and8 are Reserved, which means they are transmitted as 0and ignored on receipt.-Version 1-ECO transmitted as zero, ignored on receipt-User ECO transmitted as zero, ignored on receipt-Reserved/Circuit Type Most significant 6 bits reserved (Transmitted as zero, ignored on receipt). Loworder bits (bits 1 and 2) indicate:70 reserved value (if specified the entire PDUshall be ignored)71 Level 1 only72 Level 2 only (sender is Level 2 Intermediatesystem with manualL2OnlyMode set True forthis circuit, and will use this link only for Level 2traffic)73 both Level 1 and Level 2 (sender is Level 2 Intermediate system, and will use this link both forLevel 1 and Level 2 traffic)NOTE In a LAN Level 1 IIH PDU the CircuitType shall be either 1 or 3.-Source ID the system ID of transmitting Intermediate system-Holding Time Holding Timer to be used for this Intermediate system-PDU Length Entire length of this PDU, in octets,including header-Reserved/Priority Bit 8 reserved (Transmitted aszero, ignored on receipt). Bits 1 through 7 priorityfor being LAN Level 1 Designated Intermediate System. Higher number has higher priority for being LANLevel 1 Designated Intermediate System. Unsignedinteger.-LAN ID a field composed the system ID (18 octets)of the LAN Level 1 Designated Intermediate System,plus a low order octet assigned by LAN Level 1 Designated Intermediate System. Copied from LANLevel 1 Designated Intermediate System's IIH PDU.-VARIABLE LENGTH FIELDS fields of the form:11No. of OctetsLENGTHCODELENGTHVALUEAny codes in a received PDU that are not recognisedshall be ignored.Currently defined codes are:7Area Addresses the set of manual
Area
Addresses of this Intermediate System.xCODE 1xLENGTH total length of the value field.xVALUE 1Address Length1Address LengthNo. of OctetsAddress LengthArea AddressAddress LengthArea Address7Address Length Length of Area Address in octets.7Area Address Area address.7Intermediate System Neighbours This optionfield can occur multiple times. The set of Intermediate systems on this LAN to which adjacencies ofneighbourSystemType L1 Intermediate System exist in state Up or Initialising (i.e.those from which Level 1 IIH PDUs have beenheard).xCODE 6xLENGTH total length of the value field.xVALUE 66No. of OctetsLAN AddressLAN Address7LAN Address 6 octet MAC Address ofIntermediate System neighbour.7Padding This option may occur multiple times.It is used to pad the PDU to at least maxsize - 1.xCODE 8.xLENGTH total length of the value field (maybe zero).xVALUE LENGTH octets of arbitrary value.7Authentication Information information forperforming authentication of the originator of thePDU.xCODE 10.xLENGTH variable from 1254 octetsxVALUE 1VARIABLENo. of OctetsAuthentication TypeAuthentication Value7Authentication Type a one octet identifier for the type of authentication to becarried out. The following values are defined:0 RESERVED1 Cleartext Password2254 RESERVED255 Routeing Domain privateauthentication method7Authentication Value determined bythe value of the authentication type. IfCleartext Password as defined in this International Standard is used, then the authentication value is an octet string.9.6 Level 2 LAN IS to IS Hello PDUThis PDU is multicast by Intermediate systems on broadcast circuits to the multi-destination address AllL2ISs.The purpose of this PDU is for Intermediate systems onbroadcast circuits to discover the identity of other Level 2Intermediate systems on that circuit. Trailing Pad optionsare inserted to make PDU Length equal to at least maxsize- 1 where-dataLinkBlocksize-originatingL2LSPBufferSize(see 8.4.1). 11No. of Octets1111111ID Length2ID Length +121VARIABLEIntradomain RouteingProtocol DiscriminatorLength IndicatorVersion/Protocol ID ExtensionID LengthPDU TypeRRRVersionECOUser ECOReserved/Circuit TypeSource IDHolding TimeLAN IDPDU LengthPriorityRVARIABLE LENGTH FIELDS-Intradomain Routeing Protocol Discriminator architectural constant-Length Indicator Length of fixed header in octets-Version/Protocol ID Extension 1-ID Length Length of the ID field of NSAP addresses and NETs used in this routeing domain. Thisfield shall take on one of the following values:7An integer between 1 and 8, inclusive, indicatingan ID field of the corresponding length7The value zero, which indicates a 6 octet ID fieldlength7The value 255, whhich means a null ID field (i.e.zero length)All other values are illegal and shall not be used.-PDU Type (bits 1 through 5) 16. Note bits 6, 7 and8 are Reserved, which means they are transmitted as 0and ignored on receipt.-Version 1-ECO transmitted as zero, ignored on receipt-User ECO transmitted as zero, ignored on receipt-Reserved/Circuit Type Most significant 6 bits reserved (Transmitted as zero, ignored on receipt). Loworder bits (bits 1 and 2) indicate:70 reserved value (if specified the entire PDUshall be ignored)71 Level 1 only72 Level 2 only (sender is Level 2 IntermediateSystem with manualL2OnlyMode set True forthis circuit, and will use this link only for Level 2traffic)73 both Level 1 and Level 2 (sender is Level 2 Intermediate System, and will use this link both forLevel 1 and Level 2 traffic)NOTE In a LAN Level 2 IIH PDU the Circuit Typeshall be either 2 or 3.-Source ID the system ID of transmitting Intermediate System-Holding Time Holding Timer to be used for this Intermediate System-PDU Length Entire length of this PDU, in octets,including header-Reserved/Priority Bit 8 reserved (Transmitted aszero, ignored on receipt). Bits 1 through 7 priorityfor being LAN Level 2 Designated Intermediate System. Higher number has higher priority for being LANLevel 2 Designated Intermediate System. Unsignedinteger.-LAN ID a field composed the system ID (18 octets)of the LAN Level 1 Designated Intermediate System,plus a low order octet assigned by LAN Level 1 Designated Intermediate System. Copied from LANLevel 1 Designated Intermediate System's IIH PDU.-VARIABLE LENGTH FIELDS fields of the form:11No. of OctetsLENGTHCODELENGTHVALUEAny codes in a received PDU that are not recognisedshall be ignored.Currently defined codes are:7Area addresses the set of manual
Area
Addresses of this Intermediate system.xCODE 1xLENGTH total length of the value field.xVALUE 1Address Length1Address LengthNo. of OctetsAddress LengthArea AddressAddress LengthArea Address7Address Length Length of area addressin octets.7Area Address Area address.7Intermediate System Neighbours This optioncan occur multiple times. The set of Intermediatesystems on this LAN to which adjacencies ofneighbourSystemType L2 Intermediate System exist in state Up or Initialising (i.e.those from which Level 2 IIH PDUs have beenheard).xCODE 6xLENGTH total length of the value field.xVALUE 66No. of OctetsLAN AddressLAN AddressxLAN Address 6 octet MAC Address of Intermediate System neighbour7Padding This option may occur multiple times.It is used to pad the PDU to at least maxsize 1.xCODE 8.xLENGTH total length of the value field (maybe zero).xVALUE LENGTH octets of arbitrary value.7Authentication Information information forperforming authentication of the originator of thePDU.xCODE 10.xLENGTH variable from 1254 octetsxVALUE 1VARIABLENo. of OctetsAuthentication TypeAuthentication Value7Authentication Type a one octet identifier for the type of authentication to becarried out. The following values are defined:0 RESERVED1 Cleartext Password2254 RESERVED255 Routeing Domain privateauthentication method7Authentication Value determined bythe value of the authentication type. IfCleartext Password as defined in this International Standard is used, then the authentication value is an octet string.9.7 Point-to-Point IS to IS Hello PDUThis PDU is transmitted by Intermediate systems on non-broadcast circuits, after receiving an ISH PDU from theneighbour system. Its purpose is to determine whether theneighbour is a Level 1 or a Level 2 Intermediate System.Trailing pad options are inserted to make PDU Lengthequal to at least maxsize 1 where maxsize is the maximum of-dataLinkBlocksize-originating
L1
LSP
Buf
fer
Size-originatingL2LSPBufferSize(see 8.2.3).11No. of Octets1111111ID Length212VARIABLEIntradomain RouteingProtocol DiscriminatorLength IndicatorVersion/Protocol ID ExtensionID LengthPDU TypeRRRVersionECOUser ECOReserved/Circuit TypeSource IDHolding TimeLocal Circuit IDPDU LengthVARIABLE LENGTH FIELDS-Intradomain Routeing Protocol Discriminatorarchitectural constant-Length Indicator Length of fixed header in octets-Version/Protocol ID Extension 1-ID Length Length of the ID field of NSAP addresses and NETs used in this routeing domain. Thisfield shall take on one of the following values:7An integer between 1 and 8, inclusive, indicatingan ID field of the corresponding length7The value zero, which indicates a 6 octet ID fieldlength7The value 255, whhich means a null ID field (i.e.zero length)All other values are illegal and shall not be used.-PDU Type (bits 1 through 5) 17. Note bits 6, 7and 8 are Reserved, which means they are transmittedas 0 and ignored on receipt.-Version 1-ECO transmitted as zero, ignored on receipt-User ECO transmitted as zero, ignored on receipt-Reserved/Circuit Type Most significant 6 bits reserved (Transmitted as zero, ignored on receipt). Loworder bits (bits 1 and 2) indicate:70 reserved value (if specified the entire PDUshall be ignored)71 Level 1 only72 Level 2 only (sender is Level 2 Intermediatesystem with manualL2OnlyMode set True forthis circuit, and will use this link only for Level 2traffic)73 both Level 1 and Level 2 (sender is Level 2 Intermediate system and will use this link both forLevel 1 and Level 2 traffic)-Source ID the system ID of transmitting Intermediate system-Holding Time Holding Timer to be used for this Intermediate system-PDU Length Entire length of this PDU, in octets,including header-Local Circuit ID 1 octet unique ID assigned to thiscircuit when it is created by this Intermediate system.The actual ID by which the circuit is known to bothends of the link is determined by the Intermediate system with the lower Source ID.-VARIABLE LENGTH FIELDS fields of the form:11No. of OctetsLENGTHCODELENGTHVALUEAny codes in a received PDU that are not recognisedshall be ignored.Currently defined codes are:7Area addresses the set of manual
Area
Addresses of this Intermediate systemxCODE 1xLENGTH total length of the value field.xVALUE 1Address Length1Address LengthNo. of OctetsAddress LengthArea AddressAddress LengthArea Address7Address Length Length of area addressin octets.7Area Address Area address.7Padding This option may occur multiple times.It is used to pad the PDU to at least maxsize 1.xCODE 8.xLENGTH total length of the value field (maybe zero).xVALUE LENGTH octets of arbitrary value.7Authentication Information information forperforming authentication of the originator of thePDU.xCODE 10.xLENGTH variable from 1254 octetsxVALUE 1VARIABLENo. of OctetsAuthentication TypeAuthentication Value7Authentication Type a one octet identifier for the type of authentication to becarried out. The following values are defined:0 RESERVED1 Cleartext Password2254 RESERVED255 Routeing Domain privateauthentication method7Authentication Value determined bythe value of the authentication type. IfCleartext Password as defined in this International Standard is used, then the authentication value is an octet string.9.8 Level 1 Link State PDULevel 1 Link State PDUs are generated by Level 1 andLevel 2 Intermediate systems, and propagated throughoutan area. The contents of the Level 1 Link State PDU indicates the state of the adjacencies to neighbour IntermediateSystems, or pseudonodes, and End systems of the Intermediate system that originally generated the PDU.11No. ofOctets11111122ID Length + 214VARIABLE2Intradomain RouteingProtocol DiscriminatorLength IndicatorVersion/Protocol ID ExtensionID LengthPDU TypeRRRVersionECOUser ECOPDU LengthRemaining LifetimeLSP IDPSequence NumberVARIABLE LENGTH FIELDSLSPDBOLIS TypeChecksumATT-Intradomain Routeing Protocol Discriminator architectural constant-Length Indicator Length if fixed header in octets-Version/Protocol ID Extension 1-ID Length Length of the ID field of NSAP addresses and NETs used in this routeing domain. Thisfield shall take on one of the following values:7An integer between 1 and 8, inclusive, indicatingan ID field of the corresponding length7The value zero, which indicates a 6 octet ID fieldlength7The value 255, whhich means a null ID field (i.e.zero length)All other values are illegal and shall not be used.-PDU Type (bits 1 through 5) 18. Note bits 6, 7 and8 are Reserved, which means they are transmitted as 0and ignored on receipt.-Version 1-ECO transmitted as zero, ignored on receipt-User ECO transmitted as zero, ignored on receipt-PDU Length Entire Length of this PDU, in octets,including header-Remaining Lifetime Number of seconds beforeLSP considered expired-LSP ID the system ID of the source of the LinkState PDU. It is structured as follows:ID Length1No. of Octets1Source IDPseudonode IDLSP Number-Sequence Number sequence number of LSP-Checksum Checksum of contents of LSP fromSource ID to end. Checksum is computed as described in 7.3.11.-P/ATT/LSPDBOL/IS Type-P Bit 8, indicates when set that the issuing Intermediate System supports the Partition Repair optionalfunction.7ATT - Bits 7-4 indicate, when set, that the issuingIntermediate System is `attached' to other areasusing:xBit 4 - the Default MetricxBit 5 - the Delay MetricxBit 6 - the Expense MetricxBit 7 - the Error Metric.7LSPDBOL Bit 3 A value of 0 indicates noLSP Database Overload, and a value of 1 indicatesthat the LSP Database is Overloaded. An LSP withthis bit set will not be used by any decision process to calculate routes to another IS through theoriginating system.7IS Type Bits 1 and 2 indicate the type of Intermediate System One of the following values:x0 Unused valuex1 ( i.e. bit 1 set) Level 1 Intermediate systemx2 Unused valuex3 (i.e. bits 1 and 2 set) Level 2 Intermediatesystem.-VARIABLE LENGTH FIELDS fields of the form:11No. of OctetsLENGTHCODELENGTHVALUEAny codes in a received LSP that are not recognisedare ignored and passed through unchanged.Currently defined codes are:7Area Addresses the set of manual
Area
Addresses of this Intermediate system. ForLSPs not generated on behalf of the pseudonodethis option shall always be present in the LSP withLSP number zero, and shall never be present in anLSP with non-zero LSP number. It shall appearbefore any Intermediate System Neighbours orEnd System Neighbours options. This optionshall never be present in pseudonode LSPs.xCODE 1xLENGTH total length of the value field.xVALUE 1Address Length1Address LengthNo. of OctetsAddress LengthArea AddressAddress LengthArea Address7Address Length Length of area addressin octets.7Area Address Area address.7Intermediate System Neighbours Intermediate system and pseudonode neighbours.This is permitted to appear multiple times, and inan LSP with any LSP number. However, all theIntermediate System Neighbours optionsshall precede the End System Neighbours options. i.e. they shall appear before any End systemNeighbour options in the same LSP and no Endsystem Neighbour options shall appear in an LSPwith lower LSP number.xCODE 2.xLENGTH 1. plus a multiple of 11.xVALUE No. of Octets11ID Length + 11111ID Length + 1111Virtual FlagDefault MetricNeighbour IDDelay MetricExpense MetricError MetricI/E0I/ESI/ESI/ESDefault MetricNeighbour IDDelay MetricExpense MetricError MetricI/E0I/ESI/ESI/ES7Virtual Flag is a Boolean. If equal to 1, thisindicates the link is really a Level 2 path torepair an area partition. (Level 1 Intermediate Systems would always report this octetas 0 to all neighbours).7Default Metric is the value of the defaultmetric for the link to the listed neighbour.Bit 8 of this field is reserved. Bit 7 of thisfield (marked I/E) indicates the metric type,and shall contain the value 0, indicatingan Internal metric.7Delay Metric is the value of the delay metric for the link to the listed neighbour. Ifthis IS does not support this metric it shallset the bit S to 1 to indicate that the metric is unsupported. Bit 7 of this field(marked I/E) indicates the metric type, andshall contain the value 0, indicating anInternal metric.7Expense Metric is the value of the expense metric for the link to the listed neighbour. If this IS does not support this metricit shall set the bit S to 1 to indicate thatthe metric is unsupported. Bit 7 of this field(marked I/E) indicates the metric type, andshall contain the value 0, indicating anInternal metric.7Error Metric is the value of the error metricfor the link to the listed neighbour. If thisIS does not support this metric it shall setthe bit S to 1 to indicate that the metric isunsupported. Bit 7 of this field (markedI/E) indicates the metric type, and shallcontain the value 0, indicating an Internalmetric.7Neighbour ID. For Intermediate Systemneighbours, the first ID Length octets arethe neighbour's system ID, and the last octet is 0. For pseudonode neighbours, thefirst ID Length octets is the LAN Level 1Designated Intermediate System's ID, andthe last octet is a non-zero quantity definedby the LAN Level 1 Designated Intermediate System.7End System Neighbours End system neighboursThis may appear multiple times, and in an LSPwith any LSP number. See the description of theIntermediate System Neighbours optionabove for the relative ordering constraints. Onlyadjacencies with identical costs can appear in thesame list.xCODE 3.xLENGTH 4. plus a multiple of 6.xVALUE ID LengthNo. of Octets1ID Length111Neighbour IDDefault MetricNeighbour IDDelay MetricExpense MetricError MetricI/E0I/ESI/ESI/ES7Default Metric is the value of the defaultmetric for the link to each of the listedneighbours. Bit 8 of this field is reserved.Bit 7 of this field (marked I/E) indicates themetric type, and shall contain the value 0,indicating an Internal metric.7Delay Metric is the value of the delay metric for the link to each of the listed neighbours. If this IS does not support this metric it shall set the bit S to 1 to indicatethat the metric is unsupported. Bit 7 of thisfield (marked I/E) indicates the metric type,and shall contain the value 0, indicatingan Internal metric.7Expense Metric is the value of the expense metric for the link to each of thelisted neighbours. If this IS does not support this metric it shall set the bit S to 1to indicate that the metric is unsupported.Bit 7 of this field (marked I/E) indicates themetric type, and shall contain the value 0,indicating an Internal metric.7Error Metric is the value of the error metricfor the link to each of the listed neighbour.If this IS does not support this metric itshall set the bit S to 1 to indicate that themetric is unsupported. Bit 7 of this field(marked I/E) indicates the metric type, andshall contain the value 0, indicating anInternal metric.7Neighbour ID system ID of End systemneighbour.7Authentication Information information forperforming authentication of the originator of thePDU.xCODE 10.xLENGTH variable from 1254 octetsxVALUE 1VARIABLENo. of OctetsAuthentication TypeAuthentication Value7Authentication Type a one octet identifier for the type of authentication to becarried out. The following values are defined:0 RESERVED1 Cleartext Password2254 RESERVED255 Routeing Domain privateauthentication method7Authentication Value determined bythe value of the authentication type. IfCleartext Password as defined in this International Standard is used, then the authentication value is an octet string.9.9 Level 2 Link State PDULevel 2 Link State PDUs are generated by Level 2 Intermediate systems, and propagated throughout the level 2 domain. The contents of the Level 2 Link State PDU indicatesthe state of the adjacencies to neighbour Level 2 Intermediate Systems, or pseudonodes, and to reachable address prefixes of the Intermediate system that originally generatedthe PDU.11No. of Octets11111122ID Length + 214VARIABLE2Intradomain RouteingProtocol DiscriminatorLength IndicatorVersion/Protocol ID ExtensionID LengthPDU TypeRRRVersionECOUser ECOPDU LengthRemaining LifetimeLSP IDPSequence NumberVARIABLE LENGTH FIELDSLSPDBOLIS TypeChecksumATT-Intradomain Routeing Protocol Discriminator architectural constant-Length Indicator Length of fixed header in octets-Version/Protocol ID Extension 1-ID Length Length of the ID field of NSAP addresses and NETs used in this routeing domain. Thisfield shall take on one of the following values:7An integer between 1 and 8, inclusive, indicatingan ID field of the corresponding length7The value zero, which indicates a 6 octet ID fieldlength7The value 255, whhich means a null ID field (i.e.zero length)All other values are illegal and shall not be used.-PDU Type (bits 1 through 5) 20. Note bits 6, 7 and8 are Reserved, which means they are transmitted as 0and ignored on receipt.-Version 1-ECO transmitted as zero, ignored on receipt-User ECO transmitted as zero, ignored on receipt-PDU Length Entire Length of this PDU, in octets,including header.-Remaining Lifetime Number of seconds beforeLSP considered expired-LSP ID the system ID of the source of the LinkState PDU. It is structured as follows:ID Length1No. of Octets1Source IDPseudonode IDLSP Number-Sequence Number sequence number of LSP-Checksum Checksum of contents of LSP fromSource ID to end. Checksum is computed as described in 7.3.11.-P/ATT/LSPDBOL/IS Type7P Bit 8, indicates when set that the issuing Intermediate System supports the Partition Repair optional function.7ATT - Bits 7-4 indicate, when set, that the issuingIntermediate System is `attached' to other areasusing:xBit 4 - the Default MetricxBit 5 - the Delay MetricxBit 6 - the Expense MetricxBit 7 - the Error Metric.7LSPDBOL Bit 3 A value of 0 indicates noLSP Database Overload, and a value of 1 indicatesthat the LSP Database is Overloaded. An LSP withthis bit set will not be used by any decision process to calculate routes to another IS through theoriginating system.7IS Type Bits 1 and 2 indicate the type of Intermediate System One of the following values:x0 Unused valuex1 ( i.e. bit 1 set) Level 1 Intermediate systemx2 Unused valuex3 (i.e. bits 1 and 2 set) Level 2 Intermediatesystem.NOTE In a Level 2 Link State PDU, IS Typeshall be 3.-VARIABLE LENGTH FIELDS fields of the form:11No. of OctetsLENGTHCODELENGTHVALUEAny codes in a received LSP that are not recognisedare ignored and passed through unchanged.Currently defined codes are:7Area Addresses the set of partition
Area
Addresses of this Intermediate system. For non-pseudonode LSPs this option shall always be present in the LSP with LSP number zero, and shallnever be present in an LSP with non-zero LSPnumber. It shall appear before any IntermediateSystem Neighbours or Prefix Neighbours options. This option shall never be present inpseudonode LSPs.xCODE 1xLENGTH total length of the value field.xVALUE 1Address Length1Address LengthNo. of OctetsAddress LengthArea AddressAddress LengthArea Address7Address Length Length of area addressin octets.7Area Address Area address.7Partition Designated Level 2 IntermediateSystem ID of Designated Level 2 IntermediateSystem for the partition. For non-pseudonodeLSPs issued by Intermediate Systems which support the partition repair optional function this option shall always be present in the LSP with LSPnumber zero, and shall never be present in an LSPwith non-zero LSP number. It shall appear beforeany Intermediate System Neighbours or PrefixNeighbours options. This option shall never bepresent in pseudonode LSPs.xCODE 4.xLENGTH 6xVALUE ID of Partition Designated Level 2Intermediate System for the partition.7Intermediate System Neighbours Intermediate system and pseudonode neighbours.This is permitted to appear multiple times, and inan LSP with any LSP number. However, all theIntermediate System Neighbours optionsshall precede the Prefix Neighbours options.i.e. they shall appear before any Prefix Neighbouroptions in the same LSP and no Prefix Neighbouroptions shall appear in an LSP with lower LSPnumber.xCODE 2.xLENGTH 1. plus a multiple of 11.xVALUE No. of Octets11ID Length + 11111ID Length + 1111Virtual FlagDefault MetricNeighbour IDDelay MetricExpense MetricError MetricI/E0I/ESI/ESI/ESDefault MetricNeighbour IDDelay MetricExpense MetricError MetricI/E0I/ESI/ESI/ES7Virtual Flag is a Boolean. If equal to 1, thisindicates the link is really a Level 2 path torepair an area partition. (Level 1 Intermediate Systems would always report this octetas 0 to all neighbours).7Default Metric is the value of the defaultmetric for the link to the listed neighbour.Bit 8 of this field is reserved. Bit 7 of thisfield (marked I/E) indicates the metric type,and shall contain the value 0, indicatingan Internal metric.7Delay Metric is the value of the delay metric for the link to the listed neighbour. Ifthis IS does not support this metric it shallset bit S to 1 to indicate that the metric isunsupported. Bit 7 of this field (markedI/E) indicates the metric type, and shallcontain the value 0, indicating an Internalmetric.7Expense Metric is the value of the expense metric for the link to the listed neighbour. If this IS does not support this metricit shall set bit S to 1 to indicate that themetric is unsupported. Bit 7 of this field(marked I/E) indicates the metric type, andshall contain the value 0, indicating anInternal metric.7Error Metric is the value of the error metricfor the link to the listed neighbour. If thisIS does not support this metric it shall setbit S to 1 to indicate that the metric is unsupported. Bit 7 of this field (marked I/E)indicates the metric type, and shall containthe value 0, indicating an Internal metric.7Neighbour ID. For Intermediate Systemneighbours, the first ID Length octets arethe neighbour's system ID, and the last octet is 0. For pseudonode neighbours, thefirst ID Length octets is the LAN Level 1Designated Intermediate System's ID, andthe last octet is a non-zero quantity definedby the LAN Level 1 Designated Intermediate System.7Prefix Neighbours reachable address prefixneighboursThis may appear multiple times, and in an LSPwith any LSP number. See the description of theIntermediate System Neighbours optionabove for the relative ordering constraints. Onlyadjacencies with identical costs can appear in thesame list.xCODE 5.xLENGTH Total length of the VALUE field.xVALUE 1iAddress Prefix Length /2y1No. of OctetsiAddress Prefix Length/2y1111Address Prefix LengthAddress PrefixAddress Prefix LengthAddress PrefixDefault MetricDelay MetricExpense MetricError MetricI/E0I/ESI/ESI/ES7Default Metric is the value of the defaultmetric for the link to each of the listedneighbours. Bit 8 of this field is reserved.Bit 7 (marked I/E) indicates the metrictype, and may be set to zero indicating aninternal metric, or may be set to 1 indicating an external metric.7Delay Metric is the value of the delay metric for the link to each of the listed neighbours. If this IS does not support this metric it shall set the bit S to 1 to indicatethat the metric is unsupported. Bit 7(marked I/E) indicates the metric type, andmay be set to zero indicating an internalmetric, or may be set to 1 indicating an external metric.7Expense Metric is the value of the expense metric for the link to each of thelisted neighbours. If this IS does not support this metric it shall set the bit S to 1to indicate that the metric is unsupported.Bit 7 (marked I/E) indicates the metrictype, and may be set to zero indicating aninternal metric, or may be set to 1 indicating an external metric.7Error Metric is the value of the error metricfor the link to each of the listed neighbour.If this IS does not support this metric itshall set the bit S to 1 to indicate that themetric is unsupported. Bit 7 (marked I/E)indicates the metric type, and may be set tozero indicating an internal metric, or maybe set to 1 indicating an external metric.7Address Prefix Length is the length insemi-octets of the following prefix. Alength of zero indicates a prefix thatmatches all NSAPs.7Address Prefix is a reachable address prefix encoded as described in 7.1.4. If thelength in semi-octets is odd, the prefix ispadded out to an integral number of octetswith a trailing zero semi-octet.Note that the area addresses listed in the Area Addresses option of Level 2 Link State PDU withLSP number zero, are understood to be reachableaddress neighbours with cost 0. They are not listedseparately in the Prefix Neighbours options.7Authentication Information information forperforming authentication of the originator of thePDU.xCODE 10.xLENGTH variable from 1254 octetsxVALUE 1VARIABLENo. of OctetsAuthentication TypeAuthentication Value7Authentication Type a one octet identifier for the type of authentication to becarried out. The following values are defined:0 RESERVED1 Cleartext Password2254 RESERVED255 Routeing Domain privateauthentication method7Authentication Value determined bythe value of the authentication type. IfCleartext Password as defined in this International Standard is used, then the authentication value is an octet string.9.10 Level 1 Complete SequenceNumbers PDU11No. of Octets1111112ID Length + 1ID Length + 2ID Length +2VARIABLEIntradomain RouteingProtocol DiscriminatorLength IndicatorVersion/Protocol ID ExtensionID LengthPDU TypeRRRVersionECOUser ECOPDU LengthSource IDStart LSP IDEnd LSP IDVARIABLE LENGTH FIELDS-Intradomain Routeing Protocol Discriminator architectural constant-Length Indicator Length of fixed header in octets-Version/Protocol ID Extension 1-ID Length Length of the ID field of NSAP addresses and NETs used in this routeing domain. Thisfield shall take on one of the following values:7An integer between 1 and 8, inclusive, indicatingan ID field of the corresponding length7The value zero, which indicates a 6 octet ID fieldlength7The value 255, whhich means a null ID field (i.e.zero length)All other values are illegal and shall not be used.-PDU Type (bits 1 through 5) 24. Note bits 6, 7 and8 are Reserved, which means they are transmitted as 0and ignored on receipt.-Version 1-ECO transmitted as zero, ignored on receipt-User ECO transmitted as zero, ignored on receipt-PDU Length Entire Length of this PDU, in octets,including header-Source ID the system ID of Intermediate System(with zero Circuit ID) generating this Sequence Numbers PDU.-Start LSP ID the system ID of first LSP in therange covered by this Complete Sequence NumbersPDU.-End LSP ID the system ID of last LSP in the rangecovered by this Complete Sequence Numbers PDU.-VARIABLE LENGTH FIELDS fields of the form:11No. of OctetsLENGTHCODELENGTHVALUEAny codes in a received CSNP that are not recognisedare ignored.Currently defined codes are:7LSP Entries This may appear multiple times.The option fields, if they appear more than once,shall appear sorted into ascending LSPID order.xCODE 9xLENGTH total length of the value field.xVALUE a list of LSP entries of the form:4No. of Octets2ID Length +2242ID Length + 22LSP Sequence NumberChecksumRemaining LifetimeLSP IDLSP Sequence NumberChecksumRemaining LifetimeLSP ID7Remaining Lifetime Remaining Lifetime of LSP.7LSP ID system ID of the LSP to whichthis entry refers.7LSP Sequence Number Sequencenumber of LSP.7Checksum Checksum reported in LSP.The entries shall be sorted into ascendingLSPID order (the LSP number octet of theLSPID is the least significant octet).7Authentication Information information forperforming authentication of the originator of thePDU.xCODE 10.xLENGTH variable from 1254 octetsxVALUE 1VARIABLENo. of OctetsAuthentication TypeAuthentication Value7Authentication Type a one octet identifier for the type of authentication to becarried out. The following values are defined:0 RESERVED1 Cleartext Password2254 RESERVED255 Routeing Domain privateauthentication method7Authentication Value determined bythe value of the authentication type. IfCleartext Password as defined in this International Standard is used, then the authentication value is an octet string.9.11 Level 2 Complete SequenceNumbers PDU11No. of Octets1111112ID Length + 1ID Length + 2ID Length +2VARIABLEIntradomain RouteingProtocol DiscriminatorLength IndicatorVersion/Protocol ID ExtensionID LengthPDU TypeRRRVersionECOUser ECOPDU LengthSource IDStart LSP IDEnd LSP IDVARIABLE LENGTH FIELDS-Intradomain Routeing Protocol Discriminator architectural constant-Length Indicator Length of fixed header in octets-Version/Protocol ID Extension 1-ID Length Length of the ID field of NSAP addresses and NETs used in this routeing domain. Thisfield shall take on one of the following values:7An integer between 1 and 8, inclusive, indicatingan ID field of the corresponding length7The value zero, which indicates a 6 octet ID fieldlength7The value 255, whhich means a null ID field (i.e.zero length)All other values are illegal and shall not be used.-PDU Type (bits 1 through 5) 25. Note bits 6, 7 and8 are Reserved, which means they are transmitted as 0and ignored on receipt.-Version 1-ECO transmitted as zero, ignored on receipt-User ECO transmitted as zero, ignored on receipt-PDU Length Entire Length of this PDU, in octets,including header-Source ID the system ID of Intermediate System(with zero Circuit ID) generating this Sequence Numbers PDU.-Start LSP ID the system ID of first LSP in therange covered by this Complete Sequence NumbersPDU.-End LSP ID the system ID of last LSP in the rangecovered by this Complete Sequence Numbers PDU.-VARIABLE LENGTH FIELDS fields of the form:11No. of OctetsLENGTHCODELENGTHVALUEAny codes in a received CSNP that are not recognisedare ignored.Currently defined codes are:7LSP Entries this may appear multiple times.The option fields, if they appear more than once,shall appear sorted into ascending LSPID order.xCODE 9xLENGTH total length of the value field.xVALUE a list of LSP entries of the form:4No. of Octets2ID Length +2242ID Length + 22LSP Sequence NumberChecksumRemaining LifetimeLSP IDLSP Sequence NumberChecksumRemaining LifetimeLSP ID7Remaining Lifetime Remaining Lifetime of LSP.7LSP ID the system ID of the LSP towhich this entry refers.7LSP Sequence Number Sequencenumber of LSP.7Checksum Checksum reported in LSP.The entries shall be sorted into ascendingLSPID order (the LSP number octet of theLSPID is the least significant octet).7Authentication Information information forperforming authentication of the originator of thePDU.xCODE 10.xLENGTH variable from 1254 octetsxVALUE 1VARIABLENo. of OctetsAuthentication TypeAuthentication Value7Authentication Type a one octet identifier for the type of authentication to becarried out. The following values are defined:0 RESERVED1 Cleartext Password2254 RESERVED255 Routeing Domain privateauthentication method7Authentication Value determined bythe value of the authentication type. IfCleartext Password as defined in this International Standard is used, then the authentication value is an octet string.9.12 Level 1 Partial Sequence NumbersPDU11No. of Octets1111112ID Length + 1VARIABLEIntradomain RouteingProtocol DiscriminatorLength IndicatorVersion/Protocol ID ExtensionID LengthPDU TypeRRRVersionECOUser ECOPDU LengthSource IDVARIABLE LENGTH FIELDS-Intradomain Routeing Protocol Discriminator architectural constant-Length Indicator Length of fixed header in octets-Version/Protocol ID Extension 1-ID Length Length of the ID field of NSAP addresses and NETs used in this routeing domain. Thisfield shall take on one of the following values:7An integer between 1 and 8, inclusive, indicatingan ID field of the corresponding length7The value zero, which indicates a 6 octet ID fieldlength7The value 255, whhich means a null ID field (i.e.zero length)All other values are illegal and shall not be used.-PDU Type (bits 1 through 5) 26. Note bits 6, 7 and8 are Reserved, which means they are transmitted as 0and ignored on receipt.-Version 1-ECO transmitted as zero, ignored on receipt-User ECO transmitted as zero, ignored on receipt-PDU Length Entire Length of this PDU, in octets,including header-Source ID the system ID of Intermediate system(with zero Circuit ID) generating this Sequence Numbers PDU.-VARIABLE LENGTH FIELDS fields of the form:11No. of OctetsLENGTHCODELENGTHVALUEAny codes in a received PSNP that are not recognisedare ignored.Currently defined codes are:7LSP Entries this may appear multiple times.The option fields, if they appear more than once,shall appear sorted into ascending LSPID order.xCODE 9xLENGTH total length of the value field.xVALUE a list of LSP entries of the form:4No. of Octets2ID Length +2242ID Length + 22LSP Sequence NumberChecksumRemaining LifetimeLSP IDLSP Sequence NumberChecksumRemaining LifetimeLSP ID7Remaining Lifetime Remaining Lifetime of LSP.7LSP ID the system ID of the LSP towhich this entry refers.7LSP Sequence Number Sequencenumber of LSP.7Checksum Checksum reported in LSP.The entries shall be sorted into ascendingLSPID order (the LSP number octet of theLSPID is the least significant octet).7Authentication Information information forperforming authentication of the originator of thePDU.xCODE 10.xLENGTH variable from 1254 octetsxVALUE 1VARIABLENo. of OctetsAuthentication TypeAuthentication Value7Authentication Type a one octet identifier for the type of authentication to becarried out. The following values are defined:0 RESERVED1 Cleartext Password2254 RESERVED255 Routeing Domain privateauthentication method7Authentication Value determined bythe value of the authentication type. IfCleartext Password as defined in this International Standard is used, then the authentication value is an octet string.9.13 Level 2 Partial Sequence NumbersPDU11No. of Octets1111112ID Length + 1VARIABLEIntradomain RouteingProtocol DiscriminatorLength IndicatorVersion/Protocol ID ExtensionID LengthPDU TypeRRRVersionECOUser ECOPDU LengthSource IDVARIABLE LENGTH FIELDS-Intradomain Routeing Protocol Discriminator architectural constant-Length Indicator Length of fixed header in octets-Version/Protocol ID Extension 1-ID Length Length of the ID field of NSAP addresses and NETs used in this routeing domain. Thisfield shall take on one of the following values:7An integer between 1 and 8, inclusive, indicatingan ID field of the corresponding length7The value zero, which indicates a 6 octet ID fieldlength7The value 255, whhich means a null ID field (i.e.zero length)All other values are illegal and shall not be used.-PDU Type (bits 1 through 5) 27. Note bits 6, 7 and8 are Reserved, which means they are transmitted as 0and ignored on receipt.-Version 1-ECO transmitted as zero, ignored on receipt-User ECO transmitted as zero, ignored on receipt-PDU Length Entire Length of this PDU, in octets,including header-Source ID the system ID of Intermediate system(with zero Circuit ID) generating this Sequence Numbers PDU.-VARIABLE LENGTH FIELDS fields of the form:11No. of OctetsLENGTHCODELENGTHVALUEAny codes in a received PSNP that are not recognisedare ignored.Currently defined codes are:7LSP Entries this may appear multiple times.The option fields, if they appear more than once,shall appear sorted into ascending LSPID order.xCODE 9xLENGTH total length of the value field.xVALUE a list of LSP entries of the form:4No. of Octets2ID Length +2242ID Length + 22LSP Sequence NumberChecksumRemaining LifetimeLSP IDLSP Sequence NumberChecksumRemaining LifetimeLSP ID7Remaining Lifetime Remaining Lifetime of LSP.7LSP ID the system ID of the LSP towhich this entry refers.7LSP Sequence Number Sequencenumber of LSP.7Checksum Checksum reported in LSP.The entries shall be sorted into ascendingLSPID order (the LSP number octet of theLSPID is the least significant octet).7Authentication Information information forperforming authentication of the originator of thePDU.xCODE 10.xLENGTH variable from 1254 octetsxVALUE 1VARIABLENo. of OctetsAuthentication TypeAuthentication Value7Authentication Type a one octet identifier for the type of authentication to becarried out. The following values are defined:0 RESERVED1 Cleartext Password2254 RESERVED255 Routeing Domain privateauthentication method7Authentication Value determined bythe value of the authentication type. IfCleartext Password as defined in this International Standard is used, then the authentication value is an octet string.10 System Environment10.1 Generating Jitter on TimersWhen PDUs are transmitted as a result of timer expiration,there is a danger that the timers of individual systems maybecome synchronised. The result of this is that the trafficdistribution will contain peaks. Where there are a largenumber of synchronised systems, this can cause overloading of both the transmission medium and the systems receiving the PDUs. In order to prevent this from occurring,all periodic timers, the expiration of which can cause thetransmission of PDUs, shall have jitter introduced as defined in the following algorithm.CONSTANTJitter = 25;(* The percentage jitter as defined in the architecturalconstant Jitter *)Resolution = 100;(* The timer resolution in milliseconds *)PROCEDURE Random(max : Integer): Integer; (* This procedure delivers a Uniformly distributedrandom integer R such that 0 < R < max *)PROCEDUREDefineJitteredTimer(baseTimeValueInSeconds: Integer;expirationAction : Procedure);VARbaseTimeValue, maximumTimeModifier, waitTime :Integer;nextexpiration : Time;BEGINbaseTimeValue := baseTimeValueInSeconds * 1000 /Resolution;maximumTimeModifier := baseTimeValue * Jitter /100; (* Compute maximum possible jitter *)WHILE running DOBEGIN(* First compute next expiration time *)randomTimeModifier :=Random(maximumTimeModifier);waitTime := baseTimeValue -randomTimeModifier;nextexpiration := CurrentTime + waitTime;(* Then perform expiration Action *)expirationAction;WaitUntil(nextexpiration);END (* of Loop *)END (* of DefineJitteredTimer *)Thus the call DefineJitteredTimer(HelloTime, SendHelloPDU); where HelloTime is 10 seconds, will cause theaction SendHelloPDU to be performed at random intervals of between 7.5 and 10 seconds. The essential point ofthis algorithm is that the value of randomTimeModifier israndomised within the inner loop. Note that the new expiration time is set immediately on expiration of the last interval, rather than when the expiration action has been completed.The time resolution shall be less than or equal to 100 milliseconds. It is recommended to be less than or equal to 10milliseconds. The time resolution is the maximum intervalthat can elapse without there being any change in the valueof the timer. The periodic transmission period shall be random or pseudo-random in the specified range, with uniformdistribution across similar implementations.10.2 Resolution of TimersAll timers specified in units of seconds shall have a resolution of no less than 11 second.All timers specified in units of milliseconds shall have aresolution of no less than 110 milliseconds10.3 Requirements on the Operation ofISO 9542This International Standard places certain requirements onthe use of ISO 9542 by Intermediate systems which go beyond those mandatory requirements stated in theconformance clause of ISO 9542. These requirements are:a)The IS shall operate the Configuration Informationfunctions on all types of subnetworks supported by theIS. This includes the reception of ESH PDUs, and thereception and transmission of ISH PDUs.b)The IS shall enable the All Intermediate Systemsmulti-destination subnetwork address.11 System Management11.1 GeneralThe operation of the Intra-domain ISIS routeing functionsmay be monitored and controlled using System Management. This clause is the management specification for ISO10589 in the GDMO notation as defined in ISO 10165-4.11.1.1 Naming HierarchyThe containment hierarchy for ISO 10589 is illustrated below in figure8NetworkVirtualAdjacencyAdjacencyDestinationSystemDestinationAreaCircuitReachableAddressEntityCLNS(ISO 10589 Package)(ISO 10589Package)ManualAdjacencyLevel 2 OnlyFigure 8 - Containment and Naming Hierarchy.11.1.2 Resetting of TimersMany of the attributes defined herein represent the valuesof timers. They specify the interval between certain eventsin the operation of the routeing state machines. If the valueof one of these characteristics is changed to a new value twhile the routeing state machine is in operation the implementation shall take the necessary actions to ensure that forany time interval which was in progress when the corresponding attribute was changed, the next expiration of thatinterval takes place t seconds from the original start of thatinterval, or immediately, whichever is the later.Where this action is necessary it is indicated in the applicable behaviour clause of the GDMO. See 11.2.1611.1.3 Resource Limiting CharacteristicsCertain attributes place limits on some resource, such asmax
imum
SVC
Adjacencies. In general, implementations may allocate memory resources up to this limit whenthe managed object is enabled and it may be impossible tochange the allocation without first disabling and re-enablingthe corresponding Network entity. Therefore this International Standard only requires that system management shallbe able to change these attributes when the managed objectis disabled (i.e. in the state off).However some implementations may be able to change theallocation of resources without first disabling the Networkentity. In this case it is permitted to increase the value ofthe characteristic at any time, but it shall not be decreasedbelow the currently used value of the resource. For example, maximumSVCAdjacencies shall not be decreasedbelow the current number of SVCs which have been created.Characteristics of this type are indicated in the behaviourclause of the GDMO. See 11.2.16.11.2 GDMO Definition11.2.1 Name BindingsiSO10589-NB NAME BINDINGSUBORDINATE OBJECT CLASS cLNS;NAMED BYSUPERIOR OBJECT CLASS"ISO/IEC xxxxx":networkEntity;WITH ATTRIBUTE"ISO/IEC xxxxx":cLNS-MO-Name;CREATE with-automatic-instance-namingiSO10589-NB-p1;DELETE only-if-no-contained-objects;REGISTERED AS {ISO10589-ISIS.nboi iSO10589-NB(1)};level1ISO10589Circuit-NB NAME BINDINGSUBORDINATE OBJECT CLASS circuit;NAMED BYSUPERIOR OBJECT CLASS cLNS;WITH ATTRIBUTE"ISO/IEC xxxxx":circuit-MO-Name;CREATE with-reference-objectiSO10589Circuit-MO-p1;DELETE only-if-no-contained-objects;REGISTERED AS {ISO10589-ISIS.nboilevel1ISO10589Circuit-NB (2)};destinationSystem-NB NAME BINDINGSUBORDINATE OBJECT CLASS destinationSystem;NAMED BYSUPERIOR OBJECT CLASS cLNS;WITH ATTRIBUTE networkEntityTitle;REGISTERED AS {ISO10589-ISIS.nboidestinationSystem-NB (3)};destinationArea-NB NAME BINDINGSUBORDINATE OBJECT CLASS destinationArea;NAMED BYSUPERIOR OBJECT CLASS cLNS;WITH ATTRIBUTE addressPrefix;BEHAVIOUR destinationArea-NB-B BEHAVIOURDEFINED AS This name binding is only applicablewhere the superior object has an iSType of Level2;;REGISTERED AS {ISO10589-ISIS.nboidestinationArea-NB (4)};virtualAdjacency-NB NAME BINDINGSUBORDINATE OBJECT CLASS virtualAdjacency;NAMED BYSUPERIOR OBJECT CLASS cLNS;WITH ATTRIBUTE networkEntityTitle;BEHAVIOUR virtualAdjacency-NB-B BEHAVIOURDEFINED AS This name binding is only applicablewhere the superior object has an iSType of Level2;;REGISTERED AS {ISO10589-ISIS.nboivirtualAdjacency-NB (5)};reachableAddress-NB NAME BINDINGSUBORDINATE OBJECT CLASS reachableAddress;NAMED BYSUPERIOR OBJECT CLASS circuit;WITH ATTRIBUTE addressPrefix;BEHAVIOUR reachableAddress-NB-B BEHAVIOURDEFINED AS This name binding is only applicablewhere the superior object of the Circuit instance isan object with iSType level2IS;;CREATE with-reference-object reachableAddressP1reachableAddressP2;DELETE only-if-no-contained-objects;REGISTERED AS {ISO10589-ISIS.nboireachableAddress-NB (6)};adjacency-NB NAME BINDINGSUBORDINATE OBJECT CLASS adjacency;NAMED BYSUPERIOR OBJECT CLASS circuit;WITH ATTRIBUTE adjacencyName;REGISTERED AS {ISO10589-ISIS.nboi adjacency-NB(7)};manualAdjacency-NB NAME BINDINGSUBORDINATE OBJECT CLASS manualAdjacency;NAMED BYSUPERIOR OBJECT CLASS circuit;WITH ATTRIBUTE adjacencyName;BEHAVIOUR manualAdjacency-NB-B BEHAVIOURDEFINED AS When an instance name is specified inthe CREATE operation, that value shall be used forthe adjacencyName, otherwise automatic instancenaming shall be used;;CREATE with-reference-object,with-automatic-instance-namingmanualAdjacencyP1 manualAdjacencyP2;DELETE only-if-no-contained-objects;REGISTERED AS {ISO10589-ISIS.nboimanualAdjacency-NB (8)};11.2.2 The CLNS Managed Object for ISO10589cLNS MANAGED OBJECT CLASSDERIVED FROM "ISO/IEC xxxx":cLNS;-- To be replaced by the number of the network layerMO definitions when assigned.CONDITIONAL PACKAGESlevel1ISO10589PackagePRESENT IF The Intermediate System is a Level 1Intermediate System,level2ISO10589PackagePRESENT IF The Intermediate System is a Level 2Intermediate System (i.e. the value of iSType isLevel2),partitionRepairPackagePRESENT IF The Intermediate System is a Level 2Intermediate System and the partition repair optionis implemented,level1AuthenticationPackagePRESENT IF The authentication procedures are implemented,level2AuthenticationPackagePRESENT IF The Intermediate System is a Level 2Intermediate System and the authentication procedures are implemented;REGISTERED AS {ISO10589-ISIS.moi cLNS (1)};level1ISO10589Package PACKAGEATTRIBUTESversion GET,iSType GET,maximumPathSplitsREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.maximumPathSplits-DefaultPERMITTED VALUESISO10589-ISIS.MaximumPathSplits-PermittedGET-REPLACE,maximumBuffersREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.maximumBuffers-DefaultPERMITTED VALUESISO10589-ISIS.MaximumBuffers-PermittedGET-REPLACE,minimumLSPTransmissionIntervalREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.minimumLSPTransmissionInterval-DefaultPERMITTED VALUESISO10589-ISIS.MinimumLSPTransmissionInterval-PermittedGET-REPLACE,maximumLSPGenerationIntervalREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.maximumLSPGenerationInterval-DefaultPERMITTED VALUESISO10589-ISIS.MaximumLSPGenerationInterval-PermittedGET-REPLACE,minimumBroadcastLSPTransmissionIntervalREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.minimumBroadcastLSPTransmissionInterval-DefaultPERMITTED VALUESISO10589-ISIS.MinimumBroadcastLSPTransmissionInterval-PermittedGET-REPLACE,-- Note this is defined for all Circuits, but would onlybe required if one of them were a broadcast CircuitcompleteSNPIntervalREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.completeSNPInterval-DefaultPERMITTED VALUESISO10589-ISIS.CompleteSNPInterval-PermittedGET-REPLACE,-- DittooriginatingL1LSPBufferSizeREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.originatingL1LSPBufferSize-DefaultPERMITTED VALUESISO10589-ISIS.OriginatingL1LSPBufferSize-PermittedGET-REPLACE,-- Note: redirectHoldingTime moved toISO9542ISPackagemanualAreaAddressesREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.manualAreaAddresses-DefaultPERMITTED VALUESISO10589-ISIS.ManualAreaAddresses-PermittedGET ADD-REMOVE,minimumLSPGenerationIntervalREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.minimumLSPGenerationInterval-DefaultPERMITTED VALUESISO10589-ISIS.MinimumLSPGenerationInterval-PermittedGET-REPLACE,defaultESHelloTimerREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.defaultESHelloTime-DefaultPERMITTED VALUESISO10589-ISIS.DefaultESHelloTime-PermittedGET-REPLACE,pollESHelloRateREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.pollESHelloRate-DefaultPERMITTED VALUESISO10589-ISIS.PollESHelloRate-PermittedGET-REPLACE,partialSNPIntervalREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.partialSNPInterval-DefaultPERMITTED VALUESISO10589-ISIS.PartialSNPInterval-PermittedGET-REPLACE,waitingTimeREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.waitingTime-DefaultPERMITTED VALUESISO10589-ISIS.WaitingTime-PermittedGET-REPLACE,dRISISHelloTimerREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.dRISISHelloTimer-DefaultPERMITTED VALUESISO10589-ISIS.DRISISHelloTimer-PermittedGET-REPLACE,l1State GET,areaAddresses GET,-- PDUFormatErrors now in network layer MOcorruptedLSPsDetected GET,lSPL1DatabaseOverloads GET,manualAddressesDroppedFromArea GET,attemptsToExceedMaximumSequenceNumber GET,sequenceNumberSkips GET,ownLSPPurges GET,iDFieldLengthMismatches GET;ATTRIBUTE GROUPScounters-- PDUFormatErrors now in Network Layer MOcorruptedLSPsDetectedlSPL1DatabaseOverloadsmanualAddressesDroppedFromAreaattemptsToExceedMaximumSequenceNumbersequenceNumberSkipsownLSPPurgesiDFieldLengthMismatches;-- activate and deactivate actions now in Network LayerMONOTIFICATIONS"ISO/IEC xxxxx":pduFormatErrornotificationReceivingAdjacency,-- extra parameter for ISO 10589corruptedLSPDetected,lSPL1DatabaseOverload,manualAddressDroppedFromArea,attemptToExceedMaximumSequenceNumber,sequenceNumberSkip,ownLSPPurge,iDFieldLengthMismatch;REGISTERED AS {ISO10589-ISIS.poilevel1ISO10589Package (1)};level2ISO10589Package PACKAGEATTRIBUTESoriginatingL2LSPBufferSizeREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.originatingL2LSPBufferSize-DefaultPERMITTED VALUESISO10589-ISIS.OriginatingL2LSPBufferSize-PermittedGET-REPLACE,l2State GET,lSPL2DatabaseOverloads GET;ATTRIBUTE GROUPScounterslSPL2DatabaseOverloads;NOTIFICATIONSlSPL2DatabaseOverload;REGISTERED AS {ISO10589-ISIS.poilevel2ISO10589Package (2)};partitionRepairPackage PACKAGEBEHAVIOUR DEFINITIONS partitionRepairPackage-BBEHAVIOURDEFINED AS Present when the partition repair optionis implemented;;ATTRIBUTESmaximumVirtualAdjacenciesREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.maximumVirtualAdjacencies-DefaultPERMITTED VALUESISO10589-ISIS.MaximumVirtualAdjacencies-PermittedGET-REPLACE,partitionAreaAddresses GET,partitionDesignatedL2IntermediateSystem GET,partitionVirtualLinkChanges GET;ATTRIBUTE GROUPScounterspartitionVirtualLinkChanges;NOTIFICATIONSpartitionVirtualLinkChange;REGISTERED AS {ISO10589-ISIS.poipartitionRepairPackage (3)};level1AuthenticationPackage PACKAGEBEHAVIOUR DEFINITIONSlevel1AuthenticationPackage-B BEHAVIOURDEFINED AS Present when the authentication procedures option is implemented;;ATTRIBUTESareaTransmitPasswordREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.password-DefaultGET-REPLACE,areaReceivePasswordsREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.passwords-DefaultGET-REPLACEADD-REMOVE,authenticationFailuresGET;ATTRIBUTE GROUPScountersauthenticationFailures;NOTIFICATIONSauthenticationFailure;REGISTERED AS {ISO10589-ISIS.poilevel1AuthenticationPackage (4)};level2AuthenticationPackage PACKAGEBEHAVIOUR DEFINITIONSlevel2AuthenticationPackage-B BEHAVIOURDEFINED AS Present when the authentication procedures option is implemented and the value of theiSType attribute is Level2;;ATTRIBUTESdomainTransmitPasswordREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.password-DefaultGET-REPLACE,domainReceivePasswordsREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.passwords-DefaultGET-REPLACEADD-REMOVE;REGISTERED AS {ISO10589-ISIS.poilevel2AuthenticationPackage (5)};11.2.3 The Circuit Managed Object for ISO10589circuit MANAGED OBJECT CLASSDERIVED FROM "ISO/IEC xxxx":circuit;-- xxxx to be replaced with the number of the networklayer managed object definitions when one isassignedCONDITIONAL PACKAGESlevel1ISO10589CircuitPackagePRESENT IF the Circuit is a level 1 ISO 10589 Circuit,level1ISO10589BroadcastCircuitPackagePRESENT IF the Circuit is a level 1 ISO 10589broadcast Circuit,level1ISO10589PtToPtCircuitPackagePRESENT IF the Circuit is a level 1 ISO 10589 Pointto Point Circuit,level2ISO10589DACircuitPackagePRESENT IF the Circuit is a level 2 ISO 10589 X.25DA Circuit,level1ISO10589StaticCircuitPackagePRESENT IF the Circuit is a level 1 ISO10589 X.25STATIC Circuit (IN or OUT),level1ISO10589StaticOutCircuitPackagePRESENT IF the Circuit is a level1 ISO 10589 X.25STATIC OUT SNAP,level2ISO10589CircuitPackagePRESENT IF the IS is a Level2 ISO 10589 IS,level2ISO10589BroadcastCircuitPackagePRESENT IF the Circuit is a level 1 ISO 10589broadcast Circuit and the IS is a L2 IS,dACircuitCallEstablishmentMetricIncrementPackagePRESENT IF the Circuit is an X.25 DA circuit andsupport is implemented for call establishement metric increment values greater than zero,circuitAuthenticationPackagePRESENT IF the authentication procedures are implemented on this IS;REGISTERED AS {ISO10589-ISIS.moi circuit (2)};level1ISO10589CircuitPackage PACKAGEATTRIBUTEStype GET,helloTimerREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.helloTimer-DefaultPERMITTED VALUESISO10589-ISIS.HelloTimer-PermittedGET-REPLACE,l1DefaultMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.defaultMetric-DefaultPERMITTED VALUESISO10589-ISIS.DefaultMetric-PermittedGET-REPLACE,l1DelayMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.optionalMetric-DefaultPERMITTED VALUESISO10589-ISIS.OptionalMetric-PermittedGET-REPLACE,l1ExpenseMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.optionalMetric-DefaultPERMITTED VALUESISO10589-ISIS.OptionalMetric-PermittedGET-REPLACE,l1ErrorMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.optionalMetric-DefaultPERMITTED VALUESISO10589-ISIS.OptionalMetric-PermittedGET-REPLACE,externalDomainREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.externalDomain-DefaultGET-REPLACE,circuitChanges GET,changesInAdjacencyState GET,initializationFailures GET,rejectedAdjacencies GET,controlPDUsSent GET,controlPDUsReceived GET,iDFieldLengthMismatches GET;ATTRIBUTE GROUPScounterscircuitChangeschangesInAdjacencyStateinitializationFailuresrejectedAdjacenciescontrolPDUsSentcontrolPDUsReceivediDFieldLengthMismatches;-- Note: activate and deactivate are now imported fromthe network layer definition of circuit MONOTIFICATIONScircuitChange,adjacencyStateChange,initializationFailure,rejectedAdjacency,iDFieldLengthMismatch;REGISTERED AS {ISO10589-ISIS.poilevel1ISO10589CircuitPackage (6)};level1ISO10589BroadcastCircuitPackage PACKAGEBEHAVIOUR DEFINITIONSlevel1BroadcastCircuitPackage-B BEHAVIOURDEFINED AS Present when the Circuit is of typeBroadcast;;ATTRIBUTESiSISHelloTimerREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.iSISHelloTimer-DefaultPERMITTED VALUESISO10589-ISIS.ISISHelloTimer-PermittedGET-REPLACE,l1IntermediateSystemPriorityREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.l1IntermediateSystemPriority-DefaultPERMITTED VALUESISO10589-ISIS.L1IntermediateSystemPriority-PermittedGET-REPLACE,l1CircuitID GET,l1DesignatedIntermediateSystem GET,lanL1DesignatedIntermediateSystemChanges GET;ATTRIBUTE GROUPScounterslanL1DesignatedIntermediateSystemChanges;NOTIFICATIONSlanL1DesignatedIntermediateSystemChange;REGISTERED AS {ISO10589-ISIS.poilevel1ISO10589BroadcastCircuitPackage (7)};level1ISO10589PtToPtCircuitPackage PACKAGEBEHAVIOUR DEFINITIONSlevel1PtToPtCircuitPackage-B BEHAVIOURDEFINED AS Present when the Circuit is of type PtToPt;;ATTRIBUTESptPtCircuitID GET;REGISTERED AS {ISO10589-ISIS.poilevel1ISO10589PtToPtCircuitPackage (8)};dACircuitCallEstablishmentMetricIncrementPackagePACKAGEBEHAVIOUR DEFINITIONSdACircuitCallEstablishmentMetricIncrementPackage-B BEHAVIOURDEFINED AS Present when values of call establishment metric increment greater than zero are supported and the parent iS MO has iSType Level2;;ATTRIBUTEScallEstablishmentDefaultMetricIncrementREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.callEstablishmentMetricIncrement-DefaultPERMITTED VALUESISO10589-ISIS.CallEstablishmentMetricIncrement-PermittedGET-REPLACE,callEstablishmentDelayMetricIncrementREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.callEstablishmentMetricIncrement-DefaultPERMITTED VALUESISO10589-ISIS.CallEstablishmentMetricIncrement-PermittedGET-REPLACE,callEstablishmentExpenseMetricIncrementREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.callEstablishmentMetricIncrement-DefaultPERMITTED VALUESISO10589-ISIS.CallEstablishmentMetricIncrement-PermittedGET-REPLACE,callEstablishmentErrorMetricIncrementREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.callEstablishmentMetricIncrement-DefaultPERMITTED VALUESISO10589-ISIS.CallEstablishmentMetricIncrement-PermittedGET-REPLACE;REGISTERED AS {ISO10589-ISIS.poidACircuitCallEstablishmentMetricIncrementPackage (9)};level2ISO10589DACircuitPackage PACKAGEBEHAVIOUR DEFINITIONSlevel2ISO10589DACircuitPackage-BBEHAVIOURDEFINED AS Present when the Circuit is of type DA,and the IS is operating as a L2 IS;;-- Note: a DA Circuit is only permitted on an L2 ISATTRIBUTESrecallTimerREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.recallTimer-DefaultPERMITTED VALUESISO10589-ISIS.RecallTimer-PermittedGET-REPLACE,idleTimerREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.idleTimer-DefaultPERMITTED VALUESISO10589-ISIS.IdleTimer-PermittedGET-REPLACE,initialMinimumTimerREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.initialMinimumTimer-DefaultPERMITTED VALUESISO10589-ISIS.InitialMinimumTimer-PermittedGET-REPLACE,reserveTimerREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.reserveTimer-DefaultPERMITTED VALUESISO10589-ISIS.ReserveTimer-PermittedGET-REPLACE,maximumSVCAdjacenciesREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.maximumSVCAdjacencies-DefaultPERMITTED VALUESISO10589-ISIS.MaximumSVCAdjacencies-PermittedGET-REPLACE,reservedAdjacencyREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.reservedAdjacency-DefaultGET-REPLACE,-- Note: it is not clear that this attribute is requiredcallsPlaced GET,callsFailed GET,timesExceededMaximumSVCAdjacencies GET;ATTRIBUTE GROUPScounterscallsPlacedcallsFailedtimesExceededMaximumSVCAdjacencies;NOTIFICATIONSexceededMaximumSVCAdjacencies;REGISTERED AS {ISO10589-ISIS.poilevel2ISO10589DACircuitPackage (10)};level1ISO10589StaticCircuitPackage PACKAGEBEHAVIOUR DEFINITIONSlevel1StaticCircuitPackage-B BEHAVIOURDEFINED AS Present when the Circuit is of typeStatic;;ATTRIBUTESneighbourSNPAAddressREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.neighbourSNPAAddress-DefaultGET-REPLACE,-- Note: should this be handled by an X.25 IVMO?ptPtCircuitID GET;REGISTERED AS {ISO10589-ISIS.poilevel1ISO10589StaticCircuitPackage (11)};level1ISO10589StaticOutCircuitPackage PACKAGEBEHAVIOUR DEFINITIONSlevel1StsticOutCircuitPackage-B BEHAVIOURDEFINED AS Present when the Circuit is of type StaticOut;;ATTRIBUTESrecallTimerREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.recallTimer-DefaultPERMITTED VALUESISO10589-ISIS.RecallTimer-PermittedGET-REPLACE,maximumCallAttemptsREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.maximumCallAttempts-DefaultPERMITTED VALUESISO10589-ISIS.MaximumCallAttempts-PermittedGET-REPLACE,callsPlaced GET,callsFailed GET,timesExceededMaximumCallAttempts GET;ATTRIBUTE GROUPScounterscallsPlacedcallsFailedtimesExceededMaximumCallAttempts;NOTIFICATIONSexceededMaximumCallAttempts ;REGISTERED AS {ISO10589-ISIS.poilevel1ISO10589StaticOutCircuitPackage (12)};level2ISO10589CircuitPackage PACKAGEBEHAVIOUR DEFINITIONS level2CircuitPackage-BBEHAVIOURDEFINED AS Present when IS is an L2 IS;;ATTRIBUTESl2DefaultMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.defaultMetric-DefaultPERMITTED VALUESISO10589-ISIS.DefaultMetric-PermittedGET-REPLACE,l2DelayMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.optionalMetric-DefaultPERMITTED VALUESISO10589-ISIS.OptionalMetric-PermittedGET-REPLACE,l2ExpenseMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.optionalMetric-DefaultPERMITTED VALUESISO10589-ISIS.OptionalMetric-PermittedGET-REPLACE,l2ErrorMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.optionalMetric-DefaultPERMITTED VALUESISO10589-ISIS.OptionalMetric-PermittedGET-REPLACE,manualL2OnlyModeREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.manualL2OnlyMode-DefaultGET-REPLACE;REGISTERED AS {ISO10589-ISIS.poilevel2ISO10589CircuitPackage (13)};level2ISO10589BroadcastCircuitPackage PACKAGEBEHAVIOUR DEFINITIONSlevel2BroadcastCircuitPackage-B BEHAVIOURDEFINED AS Present when the Circuit is of typeBroadcast and the IS is an L2 IS;;ATTRIBUTESl2IntermediateSystemPriorityREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.l2IntermediateSystemPriority-DefaultPERMITTED VALUESISO10589-ISIS.L2IntermediateSystemPriority-PermittedGET-REPLACE,l2CircuitID GET,l2DesignatedIntermediateSystem GET,lanL2DesignatedIntermediateSystemChanges GET;ATTRIBUTE GROUPScounterslanL2DesignatedIntermediateSystemChanges;NOTIFICATIONSlanL2DesignatedIntermediateSystemChange;REGISTERED AS {ISO10589-ISIS.poilevel2ISO10589BroadcastCircuitPackage (14)};circuitAuthenticationPackage PACKAGEBEHAVIOUR DEFINITIONScircuitAuthenticationPackage-B BEHAVIOURDEFINED AS Present when the authentication procedures option is implemented;;ATTRIBUTEScircuitTransmitPasswordREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.password-DefaultGET-REPLACE,circuitReceivePasswordsREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.passwords-DefaultGET-REPLACEADD-REMOVE,authenticationFailures GET;ATTRIBUTE GROUPScountersauthenticationFailures;NOTIFICATIONSauthenticationFailure;REGISTERED AS {ISO10589-ISIS.poicircuitAuthenticationPackage (15)};11.2.4 The Adjacency managed Objectadjacency MANAGED OBJECT CLASSDERIVED FROM "ISO/IEC 10165-2":top;CHARACTERIZED BY adjacencyPackage PACKAGEATTRIBUTESadjacencyName GET,adjacencyState GET;-- Note: this is NOT operational state;;CONDITIONAL PACKAGESbroadcastAdjacencyPackagePRESENT IF the parent Circuit is of type broadcast,dAAdjacencyPackagePRESENT IF the parent Circuit is of type DA,ptToPtAdjacencyPackagePRESENT IF the parent Circuit is of type PtToPt orSTATIC,iSAdjacencyPackagePRESENT IF the adjacency is to an IS (i.e theneighbourSystemType is Intermediate System L1Intermediate System or L2 Intermediate System),broadcastISAdjacencyPackagePRESENT IF the parent Circuit is of type broadcastand is to an IS as above,eSAdjacencyPackagePRESENT IF the adjacency is to an ES (i.e. theneighbourSystemType is EndSystem;REGISTERED AS {ISO10589-ISIS.moi adjacency (3)};broadcastAdjacencyPackage PACKAGEBEHAVIOUR DEFINITIONSbroadcastAdjacencyPackage-B BEHAVIOURDEFINED AS present if the parent Circuit is of typebroadcast;;ATTRIBUTESneighbourLANAddress GET,neighbourSystemType GET;REGISTERED AS {ISO10589-ISIS.poibroadcastAdjacencyPackage (16)};dAAdjacencyPackage PACKAGEBEHAVIOUR DEFINITIONS dAAdjacencyPackage-BBEHAVIOURDEFINED AS present if the parent Circuit is of typeDA;;ATTRIBUTESsNPAAddress GET;REGISTERED AS {ISO10589-ISIS.poidAAdjacencyPackage (17)};ptToPtAdjacencyPackage PACKAGEBEHAVIOUR DEFINITIONSptToPtAdjacencyPackage-B BEHAVIOURDEFINED AS present if the parent Circuit is of typePtToPt;;ATTRIBUTESneighbourSystemType GET;REGISTERED AS {ISO10589-ISIS.poiptToPtAdjacencyPackage (18)};iSAdjacencyPackage PACKAGEBEHAVIOUR DEFINITIONS iSAdjacencyPackage-BBEHAVIOURDEFINED AS present if the adjacency is to an IS;;ATTRIBUTESadjacencyUsageType GET,neighbourSystemID GET,neighbourAreas GET,holdingTimer GET;REGISTERED AS {ISO10589-ISIS.poiiSAdjacencyPackage (19)};broadcastISAdjacencyPackage PACKAGEBEHAVIOUR DEFINITIONSbroadcastISAdjacencyPackage-B BEHAVIOURDEFINED AS present if the parent Circuit is of typebroadcast and the adjacency is to an IS;;ATTRIBUTESlANPriority GET;REGISTERED AS {ISO10589-ISIS.poibroadcastISAdjacencyPackage (20)};eSAdjacencyPackage PACKAGEBEHAVIOUR DEFINITIONS eSAdjacencyPackage-BBEHAVIOURDEFINED AS present if the adjacency is to an ES;;ATTRIBUTESendSystemIDs GET;REGISTERED AS {ISO10589-ISIS.poieSAdjacencyPackage (21)};11.2.5 The Manual Adjacency ManagedObjectmanualAdjacency MANAGED OBJECT CLASSDERIVED FROM "ISO/IEC 10165-2":top;CHARACTERIZED BY manualAdjacencyPackagePACKAGEATTRIBUTESadjacencyName GET,neighbourLANAddress GET,endSystemIDs GET;;;REGISTERED AS {ISO10589-ISIS.moimanualAdjacency (4)};11.2.6 The Virtual Adjacency managed ObjectvirtualAdjacency MANAGED OBJECT CLASSDERIVED FROM "ISO/IEC 10165-2":top;CHARACTERIZED BY virtualAdjacencyPackagePACKAGEATTRIBUTESnetworkEntityTitle GET,metric GET;;;REGISTERED AS {ISO10589-ISIS.moi virtualAdjacency(5)};11.2.7 The Destination Managed Object-- The destination MO class is never instantiated. It existsonly to allow the destinationSystem anddestinationArea MO classes to be derived from it.destination MANAGED OBJECT CLASSDERIVED FROM "ISO/IEC 10165-2":top;CHARACTERIZED BY destinationPackagePACKAGEATTRIBUTESdefaultMetricPathCost GET,defaultMetricOutputAdjacencies GET,delayMetricPathCost GET,delayMetricOutputAdjacencies GET,expenseMetricPathCost GET,expenseMetricOutputAdjacencies GET,errorMetricPathCost GET,errorMetricOutputAdjacencies GET;;; -- no need for an object ID since it is neverinstantiated, but GDMO needs oneREGISTERED AS {ISO10589-ISIS.moi destination (6)};11.2.8 The Destination System ManagedObjectdestinationSystem MANAGED OBJECT CLASSDERIVED FROM destination;CHARACTERIZED BY destinationSystemPackagePACKAGEATTRIBUTESnetworkEntityTitle GET;;;REGISTERED AS {ISO10589-ISIS.moidestinationSystem (7)};11.2.9 The Destination Area Managed ObjectdestinationArea MANAGED OBJECT CLASSDERIVED FROM destination;CHARACTERIZED BY destinationAreaPackagePACKAGEATTRIBUTESaddressPrefix GET;;;REGISTERED AS {ISO10589-ISIS.moi destinationArea(8)};11.2.10 The Reachable Address ManagedObjectreachableAddress MANAGED OBJECT CLASSDERIVED FROM "ISO/IEC 10165-2":top;CHARACTERIZED BY reachableAddressPackagePACKAGEATTRIBUTESaddressPrefix GET,defaultMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.defaultMetric-DefaultPERMITTED VALUESISO10589-ISIS.DefaultMetric-PermittedGET-REPLACE,delayMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.optionalMetric-DefaultPERMITTED VALUESISO10589-ISIS.OptionalMetric-PermittedGET-REPLACE,expenseMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.optionalMetric-DefaultPERMITTED VALUESISO10589-ISIS.OptionalMetric-PermittedGET-REPLACE,errorMetricREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.optionalMetric-DefaultPERMITTED VALUESISO10589-ISIS.OptionalMetric-PermittedGET-REPLACE,defaultMetricTypeREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.metricType-DefaultGET-REPLACE,delayMetricTypeREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.metricType-DefaultGET-REPLACE,expenseMetricTypeREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.metricType-DefaultGET-REPLACE,errorMetricTypeREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.metricType-DefaultGET-REPLACE,"ISO/IEC 10165-2":operationalState GET;ACTIONSactivate,deactivate;;;CONDITIONAL PACKAGESmappingRAPackagePRESENT IF the parent Circuit is of type broadcastor DA,broadcastRAPackagePRESENT IF the parent Circuit is of type broadcastand the value of mappingType is `manual',dARAPackagePRESENT IF the parent Circuit is of type DA andthe value of mappingType is `manual';REGISTERED AS {ISO10589-ISIS.moireachableAddress (9)};mappingRAPackage PACKAGEBEHAVIOUR DEFINITIONS mappingRAPackage-BBEHAVIOURDEFINED AS When present, the NSAP to Circuitmapping is controlled by the value of the mappingType attribute;;ATTRIBUTESmappingType GET;REGISTERED AS {ISO10589-ISIS.poimappingRAPackage (22)};broadcastRAPackage PACKAGEBEHAVIOUR DEFINITIONS broadcastRAPackage-BBEHAVIOURDEFINED AS When present, the remote SNPA addressis determined by the value of the lANAddress attribute;;ATTRIBUTESlANAddressREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.lANAddress-DefaultGET-REPLACE;REGISTERED AS {ISO10589-ISIS.poibroadcastRAPackage (23)};dARAPackage PACKAGEBEHAVIOUR DEFINITIONS dARAPackage-BBEHAVIOURDEFINED AS When present, the remote SNPA addressis determined by the value of the sNPAAddresses attribute;;ATTRIBUTESsNPAAddressesREPLACE-WITH-DEFAULTDEFAULT VALUEISO10589-ISIS.sNPAAddresses-DefaultGET-REPLACE;REGISTERED AS {ISO10589-ISIS.poi dARAPackage(24)};11.2.11 Attribute Definitionsversion ATTRIBUTEWITH ATTRIBUTE SYNTAX ISO10589-ISIS.Version;MATCHES FOR Equality, Ordering;BEHAVIOUR version-B BEHAVIOURDEFINED AS The version number of this InternationalStandard to which the implementation conforms;;REGISTERED AS {ISO10589-ISIS.aoi version (1)};iSType ATTRIBUTEWITH ATTRIBUTE SYNTAX ISO10589-ISIS.ISType;MATCHES FOR Equality;BEHAVIOUR iSType-B BEHAVIOURDEFINED AS The type of this Intermediate System.The value of this attribute is only settable via thecreate parameter;;REGISTERED AS {ISO10589-ISIS.aoi iSType (2)};maximumPathSplits ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MaximumPathSplits;MATCHES FOR Equality, Ordering;BEHAVIOUR maximumPathSplits-B BEHAVIOURDEFINED AS Maximum number of paths with equalrouteing metric value which it is permitted to splitbetween;,replaceOnlyWhileDisabled-B;PARAMETERS constraintViolation;REGISTERED AS {ISO10589-ISIS.aoimaximumPathSplits (3)};maximumBuffers ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MaximumBuffers;MATCHES FOR Equality, Ordering;BEHAVIOUR maximumBuffers-B BEHAVIOURDEFINED AS Maximum guaranteed number of buffersfor forwarding. This is the number of forwardingbuffers that is to be reserved, more may be used ifthey are available. (See clause D.1.1);,resourceLimiting-B;PARAMETERS constraintViolation;REGISTERED AS {ISO10589-ISIS.aoi maximumBuffers(4)};minimumLSPTransmissionInterval ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MinimumLSPTransmissionInterval;MATCHES FOR Equality, Ordering;BEHAVIOUR minimumLSPTransmissionInterval-BBEHAVIOURDEFINED AS Minimum interval, in seconds, betweenre- transmissions of an LSP;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoiminimumLSPTransmissionInterval (5)};maximumLSPGenerationInterval ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MaximumLSPGenerationInterval;MATCHES FOR Equality, Ordering;BEHAVIOUR maximumLSPGenerationInterval-BBEHAVIOURDEFINED AS Maximum interval, in seconds, betweengenerated LSPs by this system;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoimaximumLSPGenerationInterval (6)};minimumBroadcastLSPTransmissionInterval ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MinimumBroadcastLSPTransmissionInterval;MATCHES FOR Equality, Ordering;BEHAVIOURminimumBroadcastLSPTransmissionInterval-BBEHAVIOURDEFINED AS Minimum interval, in milliseconds, between transmission of LSPs on a broadcast circuit(See clause 7.3.15.6);,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoiminimumBroadcastLSPTransmissionInterval (7)};completeSNPInterval ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.CompleteSNPInterval;MATCHES FOR Equality, Ordering;BEHAVIOUR completeSNPInterval-B BEHAVIOURDEFINED AS Interval, in seconds, between generationof Complete Sequence Numbers PDUs by a Designated Intermediate System on a broadcast circuit;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoicompleteSNPInterval (8)};originatingL1LSPBufferSize ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.OriginatingLSPBufferSize;MATCHES FOR Equality, Ordering;BEHAVIOUR originatingL1LSPBufferSize-BBEHAVIOURDEFINED AS The maximum size of Level 1 LSPs andSNPs originated by this system;,replaceOnlyWhileDisabled-B;PARAMETERS constraintViolation;REGISTERED AS {ISO10589-ISIS.aoioriginatingL1LSPBufferSize (9)};manualAreaAddresses ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.AreaAddresses;MATCHES FOR Equality, Set Comparison, SetIntersection;BEHAVIOUR manualAreaAddresses-B BEHAVIOURDEFINED AS Area Addresses to be used for this Intermediate System. At least one value must be supplied. The maximum number of Area Addresseswhich may exist in the set is MaximumAreaAddresses;;REGISTERED AS {ISO10589-ISIS.aoimanualAreaAddresses (10)};minimumLSPGenerationInterval ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MinimumLSPGenerationInterval;MATCHES FOR Equality, Ordering;BEHAVIOUR minimumLSPGenerationInterval-BBEHAVIOURDEFINED AS Maximum interval in seconds betweensuccessive generation of LSPs with the same LSPIDby this IS;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoiminimumLSPGenerationInterval (11)};defaultESHelloTimer ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.DefaultESHelloTimer;MATCHES FOR Equality, Ordering;BEHAVIOUR defaultESHelloTimer-B BEHAVIOURDEFINED AS The value to be used for the suggestedES configuration timer in ISH PDUs when not soliciting the ES configuration;;REGISTERED AS {ISO10589-ISIS.aoidefaultESHelloTimer (12)};pollESHelloRate ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.PollESHelloRate;MATCHES FOR Equality, Ordering;BEHAVIOUR pollESHelloRate-B BEHAVIOURDEFINED AS The value to be used for the suggestedES configuration timer in ISH PDUs when solicitingthe ES configuration;;REGISTERED AS {ISO10589-ISIS.aoi pollESHelloRate(13)};partialSNPInterval ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.PartialSNPInterval;MATCHES FOR Equality, Ordering;BEHAVIOUR partialSNPInterval-B BEHAVIOURDEFINED AS Minimum interval between sending Partial Sequence Number PDUs;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoipartialSNPInterval (14)};waitingTime ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.WaitingTime;MATCHES FOR Equality, Ordering;BEHAVIOUR waitingTime-B BEHAVIOURDEFINED AS Number of seconds to delay in waitingstate before entering On state;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoi waitingTime(15)};dRISISHelloTimer ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.DRISISHelloTimer;MATCHES FOR Equality, Ordering;BEHAVIOUR dRISISHelloTimer-B BEHAVIOURDEFINED AS The interval in seconds between thegeneration of IIH PDUs by the designated IS on aLAN;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoidRISISHelloTimer (16)};l1State ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.DatabaseState;MATCHES FOR Equality;BEHAVIOUR l1State-B BEHAVIOURDEFINED AS The state of the Level 1 database;;REGISTERED AS {ISO10589-ISIS.aoi l1State (17)};areaAddresses ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.AreaAddresses;MATCHES FOR Equality, Set Comparison, SetIntersection;BEHAVIOUR areaAddresses-B BEHAVIOURDEFINED AS The union of the sets of manualAreaAddresses reported in all Level 1 Link State PDUs received by this Intermediate System;;REGISTERED AS {ISO10589-ISIS.aoi areaAddresses(18)};corruptedLSPsDetected ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR corruptedLSPsDetected-B BEHAVIOURDEFINED AS Number of Corrupted LSP Detectedevents generated;;REGISTERED AS {ISO10589-ISIS.aoicorruptedLSPsDetected (19)};lSPL1DatabaseOverloads ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR lSPL1DatabaseOverloads-BBEHAVIOURDEFINED AS Number of times the LSP L1 DatabaseOverload event has been generated;;REGISTERED AS {ISO10589-ISIS.aoilSPL1DatabaseOverloads (20)};manualAddressesDroppedFromArea ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR manualAddressesDroppedFromArea-BBEHAVIOURDEFINED AS Number of times the Manual AddressesDropped From Area event has been generated;;REGISTERED AS {ISO10589-ISIS.aoimanualAddressesDroppedFromArea (21)};attemptsToExceedMaximumSequenceNumberATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOURattemptsToExceedMaximumSequenceNumber-BBEHAVIOURDEFINED AS Number of times the Attempt To ExceedMaximum Sequence Number event has beengenerated;;REGISTERED AS {ISO10589-ISIS.aoiattemptsToExceedMaximumSequenceNumber(22)};sequenceNumberSkips ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR sequenceNumberSkips-B BEHAVIOURDEFINED AS Number of times the Sequence NumberSkipped event has been generated;;REGISTERED AS {ISO10589-ISIS.aoisequenceNumberSkips (23)};ownLSPPurges ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR ownLSPPurges-B BEHAVIOURDEFINED AS Number of times the Own LSP Purgedevent has been generated;;REGISTERED AS {ISO10589-ISIS.aoi ownLSPPurges(24)};iDFieldLengthMismatches ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR iDFieldLengthMismatches-BBEHAVIOURDEFINED AS Number of times the iDFieldLengthMismatch event has been generated;;REGISTERED AS {ISO10589-ISIS.aoiiDFieldLengthMismatches (25)};originatingL2LSPBufferSize ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.OriginatingLSPBufferSize;MATCHES FOR Equality, Ordering;BEHAVIOUR originatingL2LSPBufferSize-BBEHAVIOURDEFINED AS The maximum size of Level 2 LSPs andSNPs originated by this system;,replaceOnlyWhileDisabled-B;PARAMETERS constraintViolation;REGISTERED AS {ISO10589-ISIS.aoioriginatingL2LSPBufferSize (26)};maximumVirtualAdjacencies ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MaximumVirtualAdjacencies;MATCHES FOR Equality, Ordering;BEHAVIOUR maximumVirtualAdjacencies-BBEHAVIOURDEFINED AS Maximum number of Virtual Adjacencies which may be created to repair partitionedLevel 1 domains;;REGISTERED AS {ISO10589-ISIS.aoimaximumVirtualAdjacencies (27)};l2State ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.DatabaseState;MATCHES FOR Equality, Ordering;BEHAVIOUR l2State-B BEHAVIOURDEFINED AS The state of the Level 2 database;;REGISTERED AS {ISO10589-ISIS.aoi l2State (28)};partitionAreaAddresses ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.AreaAddresses;MATCHES FOR Equality, Set Comparison, SetIntersection;BEHAVIOUR partitionAreaAddresses-B BEHAVIOURDEFINED AS The set union of all manualAreaAddresses of all Intermediate systems in the partitionreachable by non-virtual links (calculated from theirLevel 1 LSPs);;REGISTERED AS {ISO10589-ISIS.aoipartitionAreaAddresses (29)};partitionDesignatedL2IntermediateSystem ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.SystemID;MATCHES FOR Equality;BEHAVIOURpartitionDesignatedL2IntermediateSystem-BBEHAVIOURDEFINED AS The ID of the Partition DesignatedLevel 2 Intermediate System for this system;;REGISTERED AS {ISO10589-ISIS.aoipartitionDesignatedL2IntermediateSystem (30)};partitionVirtualLinkChanges ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR partitionVirtualLinkChanges-BBEHAVIOURDEFINED AS Number of times the Partition VirtualLink Change Notification has been generated;;REGISTERED AS {ISO10589-ISIS.aoipartitionVirtualLinkChanges (31)};lSPL2DatabaseOverloads ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR lSPL2DatabaseOverloads-BBEHAVIOURDEFINED AS Number of times the LSP L2 DatabaseOverload event has been generated;;REGISTERED AS {ISO10589-ISIS.aoilSPL2DatabaseOverloads (32)};type ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.CircuitType;MATCHES FOR Equality;BEHAVIOUR type-B BEHAVIOURDEFINED AS The type of the circuit. This attributemay only be set when the Circuit is created. Subsequently it is read-only;;REGISTERED AS {ISO10589-ISIS.aoi type (33)};helloTimer ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HelloTimer;MATCHES FOR Equality, Ordering;BEHAVIOUR helloTimer-B BEHAVIOURDEFINED AS The period, in seconds, between ISHPDUs;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoi helloTimer (34)};l1DefaultMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR l1defaultMetric-B BEHAVIOURDEFINED AS The default metric value of this circuitfor Level 1 traffic. The value of zero is reserved toindicate that this metric is not supported;;REGISTERED AS {ISO10589-ISIS.aoi l1DefaultMetric(35)};l1DelayMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR l1DelayMetric-B BEHAVIOURDEFINED AS The delay metric value of this circuit forLevel 1 traffic. The value of zero is reserved to indicate that this metric is not supported;;REGISTERED AS {ISO10589-ISIS.aoi l1DelayMetric(36)};l1ExpenseMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR l1ExpenseMetric-B BEHAVIOURDEFINED AS The expense metric value of this circuitfor Level 1 traffic. The value of zero is reserved toindicate that this metric is not supported;;REGISTERED AS {ISO10589-ISIS.aoi l1ExpenseMetric(37)};l1ErrorMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR l1ErrorMetric-B BEHAVIOURDEFINED AS The error metric value of this circuit forLevel 1 traffic. The value of zero is reserved to indicate that this metric is not supported;;REGISTERED AS {ISO10589-ISIS.aoi l1ErrorMetric(38)};circuitChanges ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR circuitChanges-B BEHAVIOURDEFINED AS Number of times this Circuit statechanged between On and Off and vice versa;;REGISTERED AS {ISO10589-ISIS.aoi circuitChanges(39)};changesInAdjacencyState ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR changesInAdjacencyState-BBEHAVIOURDEFINED AS Number of Adjacency State Changeevents generated;;REGISTERED AS {ISO10589-ISIS.aoichangesInAdjacencyState (40)};initializationFailures ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR initializationFailures-B BEHAVIOURDEFINED AS Number of Initialization Failure eventsgenerated;;REGISTERED AS {ISO10589-ISIS.aoiinitializationFailures (41)};rejectedAdjacencies ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR rejectedAdjacencies-B BEHAVIOURDEFINED AS Number of Rejected Adjacency eventsgenerated;;REGISTERED AS {ISO10589-ISIS.aoirejectedAdjacencies (42)};controlPDUsSent ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR controlPDUsSent-B BEHAVIOURDEFINED AS Number of control PDUs sent on thiscircuit;;REGISTERED AS {ISO10589-ISIS.aoi controlPDUsSent(43)};controlPDUsReceived ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR controlPDUsReceived-B BEHAVIOURDEFINED AS Number of control PDUs received onthis circuit;;REGISTERED AS {ISO10589-ISIS.aoicontrolPDUsReceived (44)};iSISHelloTimer ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.ISISHelloTimer;MATCHES FOR Equality, Ordering;BEHAVIOUR iSISHelloTimer-B BEHAVIOURDEFINED AS The period, in seconds, between LANLevel 1 and Level 2 IIH PDUs. It is also used as theperiod between ISH PDUs when polling the ES configuration;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoi iSISHelloTimer(45)};externalDomain ATTRIBUTEWITH ATTRIBUTE SYNTAX ISO10589-ISIS.Boolean;MATCHES FOR Equality;BEHAVIOUR externalDomain-B BEHAVIOURDEFINED AS If TRUE, suppress notmal transmissionof and interpretation of Intra-domain ISIS PDUs onthis circuit.;;REGISTERED AS {ISO10589-ISIS.aoi externalDomain(46)};l1IntermediateSystemPriority ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.IntermediateSystemPriority;MATCHES FOR Equality, Ordering;BEHAVIOUR l1IntermediateSystemPriority-BBEHAVIOURDEFINED AS Priority for becoming LAN Level 1Designated Intermediate System;;REGISTERED AS {ISO10589-ISIS.aoil1IntermediateSystemPriority (47)};l1CircuitID ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.CircuitID;MATCHES FOR Equality;BEHAVIOUR l1CircuitID-B BEHAVIOURDEFINED AS The LAN ID allocated by the LANLevel 1 Designated Intermediate System. Where thissystem is not aware of the value (because it is notparticipating in the Level 1 Designated IntermediateSystem election), this attribute has the value whichwould be proposed for this circuit. (i.e. the concatenation of the local system ID and the one octet localCircuit ID for this circuit.;;REGISTERED AS {ISO10589-ISIS.aoi l1CircuitID(48)};l1DesignatedIntermediateSystem ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.SystemID;MATCHES FOR Equality;BEHAVIOUR l1DesignatedIntermediateSystem-BBEHAVIOURDEFINED AS The ID of the LAN Level 1 DesignatedIntermediate System on this circuit. If, for any reason this system is not partaking in the relevant Designated Intermediate System election process, thenthe value returned is zero;;REGISTERED AS {ISO10589-ISIS.aoil1DesignatedIntermediateSystem (49)};lanL1DesignatedIntermediateSystemChangesATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOURlanL1DesignatedIntermediateSystemChanges-BBEHAVIOURDEFINED AS Number of LAN L1 Designated Intermediate System Change events generated;;REGISTERED AS {ISO10589-ISIS.aoilanL1DesignatedIntermediateSystemChanges (50)};ptPtCircuitID ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.CircuitID;MATCHES FOR Equality;BEHAVIOUR ptPtCircuitID-B BEHAVIOURDEFINED AS The ID of the circuit allocated duringinitialization. If no value has been negotiated (eitherbecause the adjacency is to an End system, orbecause initialization has not yet successfullycompleted), this attribute has the value which wouldbe proposed for this circuit. (i.e. the concatenation ofthe local system ID and the one octet local CircuitID for this circuit.;;REGISTERED AS {ISO10589-ISIS.aoi ptPtCircuitID(51)};callEstablishmentDefaultMetricIncrement ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MetricIncrement;MATCHES FOR Equality, Ordering;BEHAVIOURcallEstablishmentDefaultMetricIncrement-BBEHAVIOURDEFINED AS Additional value to be reported for thedefault metric value of unestablished DA adjacencies;;REGISTERED AS {ISO10589-ISIS.aoicallEstablishmentDefaultMetricIncrement (52)};callEstablishmentDelayMetricIncrement ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MetricIncrement;MATCHES FOR Equality, Ordering;BEHAVIOURcallEstablishmentDelayMetricIncrement-BBEHAVIOURDEFINED AS Additional value to be reported for thedelay metric value of unestablished DA adjacencies;;REGISTERED AS {ISO10589-ISIS.aoicallEstablishmentDelayMetricIncrement (53)};callEstablishmentExpenseMetricIncrement ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MetricIncrement;MATCHES FOR Equality, Ordering;BEHAVIOURcallEstablishmentExpenseMetricIncrement-BBEHAVIOURDEFINED AS Additional value to be reported for theExpense metric value of unestablished DA adjacencies;;REGISTERED AS {ISO10589-ISIS.aoicallEstablishmentExpenseMetricIncrement (54)};callEstablishmentErrorMetricIncrement ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MetricIncrement;MATCHES FOR Equality, Ordering;BEHAVIOUR callEstablishmentErrorMetricIncrement-BBEHAVIOURDEFINED AS Additional value to be reported for theError metric value of unestablished DA adjacencies;;REGISTERED AS {ISO10589-ISIS.aoicallEstablishmentErrorMetricIncrement (55)};recallTimer ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.RecallTimer;MATCHES FOR Equality, Ordering;BEHAVIOUR recallTimer-B BEHAVIOURDEFINED AS Number of seconds that must elapse between a call failure on a DED circuit and a recall;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoi recallTimer(56)};idleTimer ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.IdleTimer;MATCHES FOR Equality, Ordering;BEHAVIOUR idleTimer-B BEHAVIOURDEFINED AS Number of seconds of idle time beforecall is cleared;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoi idleTimer (57)};initialMinimumTimer ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.InitialMinimumTimer;MATCHES FOR Equality, Ordering;BEHAVIOUR initialMinimumTimer-B BEHAVIOURDEFINED AS Number of seconds that a call remainsconnected after being established, irrespective oftraffic. (Note. This should be set small enough sothat the call is cleared before the start of the nextcharging interval.);,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoiinitialMinimumTimer (58)};reserveTimer ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.ReserveTimer;MATCHES FOR Equality, Ordering;BEHAVIOUR reserveTimer-B BEHAVIOURDEFINED AS Number of seconds, after call is cleareddue to lack of traffic, during which the SVC remainsreserved for the previous SNPA address;,resettingTimer-B;REGISTERED AS {ISO10589-ISIS.aoi reserveTimer(59)};maximumSVCAdjacencies ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MaximumSVCAdjacencies;MATCHES FOR Equality, Ordering;BEHAVIOUR maximumSVCAdjacencies-BBEHAVIOURDEFINED AS Number of Adjacencies to reserve forSVCs for this circuit. This is the maximum numberof simultaneous calls which are possible on this circuit;,resourceLimiting-B;PARAMETERS constraintViolation;REGISTERED AS {ISO10589-ISIS.aoimaximumSVCAdjacencies (60)};reservedAdjacency ATTRIBUTEWITH ATTRIBUTE SYNTAX ISO10589-ISIS.Boolean;MATCHES FOR Equality;BEHAVIOUR reservedAdjacency-B BEHAVIOURDEFINED AS When True, indicates that one SVCmust be reserved for a connection to an IntermediateSystem;,replaceOnlyWhileDisabled-B;PARAMETERS constraintViolation;REGISTERED AS {ISO10589-ISIS.aoireservedAdjacency (61)};callsPlaced ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR callsPlaced-B BEHAVIOURDEFINED AS Number of Call attempts (successful orunsuccessful);;REGISTERED AS {ISO10589-ISIS.aoi callsPlaced (62)};callsFailed ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR callsFailed-B BEHAVIOURDEFINED AS Number of Unsuccessful Call attempts;;REGISTERED AS {ISO10589-ISIS.aoi callsFailed (63)};timesExceededMaximumSVCAdjacencies ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOURtimesExceededMaximumSVCAdjacencies-BBEHAVIOURDEFINED AS Number of Exceeded Maximum SVCAdjacencies events generated;;REGISTERED AS {ISO10589-ISIS.aoitimesExceededMaximumSVCAdjacencies (64)};neighbourSNPAAddress ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.SNPAAddress;MATCHES FOR Equality;BEHAVIOUR neighbourSNPAAddress-BBEHAVIOURDEFINED AS SNPA Address to call, or SNPA Address from which to accept call;;REGISTERED AS {ISO10589-ISIS.aoineighbourSNPAAddress (65)};maximumCallAttempts ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MaximumCallAttempts;MATCHES FOR Equality, Ordering;BEHAVIOUR maximumCallAttempts-B BEHAVIOURDEFINED AS Maximum number of successive callfailures before halting. (A value of zero means infinite retries.;;REGISTERED AS {ISO10589-ISIS.aoimaximumCallAttempts (66)};timesExceededMaximumCallAttempts ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR timesExceededMaximumCallAttempts-BBEHAVIOURDEFINED AS Number of Exceeded Maximum CallAttempts events generated;;REGISTERED AS {ISO10589-ISIS.aoitimesExceededMaximumCallAttempts (67)};l2DefaultMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR l2defaultMetric-B BEHAVIOURDEFINED AS The default metric value of this circuitfor Level 2 traffic. The value of zero is reserved toindicate that this metric is not supported;;REGISTERED AS {ISO10589-ISIS.aoi l2DefaultMetric(68)};l2DelayMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR l2DelayMetric-B BEHAVIOURDEFINED AS The delay metric value of this circuit forLevel 2 traffic. The value of zero is reserved to indicate that this metric is not supported;;REGISTERED AS {ISO10589-ISIS.aoi l2DelayMetric(69)};l2ExpenseMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR l2ExpenseMetric-B BEHAVIOURDEFINED AS The expense metric value of this circuitfor Level 2 traffic. The value of zero is reserved toindicate that this metric is not supported;;REGISTERED AS {ISO10589-ISIS.aoi l2ExpenseMetric(70)};l2ErrorMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR l2ErrorMetric-B BEHAVIOURDEFINED AS The error metric value of this circuit forLevel 2 traffic. The value of zero is reserved to indicate that this metric is not supported;;REGISTERED AS {ISO10589-ISIS.aoi l2ErrorMetric(71)};manualL2OnlyMode ATTRIBUTEWITH ATTRIBUTE SYNTAX ISO10589-ISIS.Boolean;MATCHES FOR Equality;BEHAVIOUR manualL2OnlyMode-B BEHAVIOURDEFINED AS When True, indicates that this Circuit isto be used only for Level 2;,replaceOnlyWhileDisabled-B;PARAMETERS constraintViolation;REGISTERED AS {ISO10589-ISIS.aoimanualL2OnlyMode (72)};l2IntermediateSystemPriority ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.IntermediateSystemPriority;MATCHES FOR Equality, Ordering;BEHAVIOUR l2IntermediateSystemPriority-BBEHAVIOURDEFINED AS Priority for becoming LAN Level 2Designated Intermediate System;;REGISTERED AS {ISO10589-ISIS.aoil2IntermediateSystemPriority (73)};l2CircuitID ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.CircuitID;MATCHES FOR Equality;BEHAVIOUR l2CircuitID-B BEHAVIOURDEFINED AS The LAN ID allocated by the LANLevel 2 Designated Intermediate System. Where thissystem is not aware of the value (because it is notparticipating in the Level 2 Designated IntermediateSystem election), this attribute has the value whichwould be proposed for this circuit. (i.e. the concatenation of the local system ID and the one octet localCircuit ID for this circuit.;;REGISTERED AS {ISO10589-ISIS.aoi l2CircuitID(74)};l2DesignatedIntermediateSystem ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.SystemID;MATCHES FOR Equality;BEHAVIOUR l2DesignatedIntermediateSystem-BBEHAVIOURDEFINED AS The ID of the LAN Level 2 DesignatedIntermediate System on this circuit. If, for any reason this system is not partaking in the relevant Designated Intermediate System election process, thenthe value returned is ;;REGISTERED AS {ISO10589-ISIS.aoil2DesignatedIntermediateSystem (75)};lanL2DesignatedIntermediateSystemChangesATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOURlanL2DesignatedIntermediateSystemChanges-BBEHAVIOURDEFINED AS Number of LAN L2 Designated Intermediate System Change events generated;;REGISTERED AS {ISO10589-ISIS.aoilanL2DesignatedIntermediateSystemChanges (76)};adjacencyName ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.GraphicString;MATCHES FOR Equality, Substrings;BEHAVIOUR adjacencyName-B BEHAVIOURDEFINED AS A string which is the Identifier for theAdjacency and which is unique amongst the set ofAdjacencies maintained for this Circuit. If this is amanually created adjacency (i.e. the type is Manual)it is set by the System Manager when the Adjacencyis created, otherwise it is generated by the implementation such that it is unique. The set of identifiercontaining the leading string "Auto" are reserved forAutomatic Adjacencies. An attempt to create a Manual Adjacency with such an identifier will cause anexception to be raised;;REGISTERED AS {ISO10589-ISIS.aoi adjacencyName(77)};adjacencyState ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.AdjacencyState;MATCHES FOR Equality;BEHAVIOUR adjacencyState-B BEHAVIOURDEFINED AS The state of the adjacency;;REGISTERED AS {ISO10589-ISIS.aoi adjacencyState(78)};neighbourLANAddress ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.LANAddress;MATCHES FOR Equality;BEHAVIOUR neighbourLANAddress-B BEHAVIOURDEFINED AS The MAC address of the neighbour system on a broadcast circuit;,replaceOnlyWhileDisabled-B;PARAMETERS constraintViolation;REGISTERED AS {ISO10589-ISIS.aoineighbourLANAddress (79)};neighbourSystemType ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.NeighbourSystemType;MATCHES FOR Equality;BEHAVIOUR neighbourSystemType-B BEHAVIOURDEFINED AS The type of the neighbour system oneof: Unknown End system Intermediate system L1Intermediate system L2 Intermediate system;;REGISTERED AS {ISO10589-ISIS.aoineighbourSystemType (80)};sNPAAddress ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.SNPAAddress;MATCHES FOR Equality;BEHAVIOUR sNPAAddress-B BEHAVIOURDEFINED AS The SNPA Address of the neighboursystem on an X.25 circuit;,replaceOnlyWhileDisabled-B;PARAMETERS constraintViolation;REGISTERED AS {ISO10589-ISIS.aoi sNPAAddress(81)};adjacencyUsageType ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.AdjacencyUsageType;MATCHES FOR Equality;BEHAVIOUR level-B BEHAVIOURDEFINED AS The usage of the Adjacency. AnAdjacency of type Level 1" will be used for Level 1traffic only. An adjacency of type Level 2" will beused for Level 2 traffic only. An adjacency of typeLevel 1 and 2" will be used for both Level 1 andLevel 2 traffic. There may be two adjacencies (oftypes Level 1" and Level 2" between the same pairof Intermediate Systems.;;REGISTERED AS {ISO10589-ISIS.aoiadjacencyUsageType (82)};neighbourSystemID ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.SystemID;MATCHES FOR Equality;BEHAVIOUR neighbourSystemID-B BEHAVIOURDEFINED AS The SystemID of the neighbouring Intermediate system from the Source ID field of theneighbour's IIH PDU. The Intermediate System IDfor this neighbour is derived by appending zero tothis value.;;REGISTERED AS {ISO10589-ISIS.aoineighbourSystemID (83)};neighbourAreas ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.AreaAddresses;MATCHES FOR Equality, Set Comparison, SetIntersection;BEHAVIOUR neighbourAreas-B BEHAVIOURDEFINED AS This contains the Area Addresses of aneighbour Intermediate System from the IIH PDU.;;REGISTERED AS {ISO10589-ISIS.aoi neighbourAreas(84)};holdingTimer ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HoldingTimer;MATCHES FOR Equality, Ordering;BEHAVIOUR holdingTimer-B BEHAVIOURDEFINED AS Holding time for this adjacency updatedfrom the IIH PDUs;;REGISTERED AS {ISO10589-ISIS.aoi holdingTimer(85)};lANPriority ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.IntermediateSystemPriority;MATCHES FOR Equality, Ordering;BEHAVIOUR lANPriority-B BEHAVIOURDEFINED AS Priority of neighbour on this adjacencyfor becoming LAN Level 1 Designated IntermediateSystem if adjacencyType is L1 Intermediate Systemor LAN Level 2 Designated Intermediate System ifadjacencyType is L2 Intermediate System;;REGISTERED AS {ISO10589-ISIS.aoi lANPriority(86)};endSystemIDs ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.EndSystemIDs;MATCHES FOR Equality, Set Comparison, SetIntersection;BEHAVIOUR endSystemIDs-B BEHAVIOURDEFINED AS This contains the system ID(s) of aneighbour End system. Where (in a IntermediateSystem) an adjacency has been created manually,these will be the set of IDs given in the manualIDsparameter of the create directive.;;REGISTERED AS {ISO10589-ISIS.aoi endSystemIDs(87)};networkEntityTitle ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.NetworkEntityTitle;MATCHES FOR Equality, Ordering;BEHAVIOUR networkEntityTitle-B BEHAVIOURDEFINED AS The Network entity Title which is thedestination of a Virtual link being used to repair apartitioned Level 1 area (see clause 7.2.10);;REGISTERED AS {ISO10589-ISIS.aoinetworkEntityTitle (88)};metric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.PathMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR metric-B BEHAVIOURDEFINED AS Cost of least cost L2 path(s) to destination area based on the default metric;;REGISTERED AS {ISO10589-ISIS.aoi metric (89)};defaultMetricPathCost ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.PathMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR defaultMetricPathCost-B BEHAVIOURDEFINED AS Cost of least cost path(s) using the default metric to destination;;REGISTERED AS {ISO10589-ISIS.aoidefaultMetricPathCost (90)};defaultMetricOutputAdjacencies ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.OutputAdjacencies;MATCHES FOR Equality, Set Comparison, SetIntersection;BEHAVIOUR defaultMetricOutputAdjacencies-BBEHAVIOURDEFINED AS The set of Adjacency (or Reachable Address) managed object identifiers representing theforwarding decisions based upon the default metricfor the destination;;REGISTERED AS {ISO10589-ISIS.aoidefaultMetricOutputAdjacencies (91)};delayMetricPathCost ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.PathMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR delayMetricPathCost-B BEHAVIOURDEFINED AS Cost of least cost path(s) using the delaymetric to destination;;REGISTERED AS {ISO10589-ISIS.aoidelayMetricPathCost (92)};delayMetricOutputAdjacencies ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.OutputAdjacencies;MATCHES FOR Equality, Set Comparison, SetIntersection;BEHAVIOUR delayMetricOutputAdjacencies-BBEHAVIOURDEFINED AS The set of Adjacency (or Reachable Address) managed object identifiers representing theforwarding decisions based upon the delay metricfor the destination;;REGISTERED AS {ISO10589-ISIS.aoidelayMetricOutputAdjacencies (93)};expenseMetricPathCost ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.PathMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR expenseMetricPathCost-B BEHAVIOURDEFINED AS Cost of least cost path(s) using the expense metric to destination;;REGISTERED AS {ISO10589-ISIS.aoiexpenseMetricPathCost (94)};expenseMetricOutputAdjacencies ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.OutputAdjacencies;MATCHES FOR Equality, Set Comparison, SetIntersection;BEHAVIOUR expenseMetricOutputAdjacencies-BBEHAVIOURDEFINED AS The set of Adjacency (or Reachable Address) managed object identifiers representing theforwarding decisions based upon the expense metricfor the destination;;REGISTERED AS {ISO10589-ISIS.aoiexpenseMetricOutputAdjacencies (95)};errorMetricPathCost ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.PathMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR errorMetricPathCost-B BEHAVIOURDEFINED AS Cost of least cost path(s) using the errormetric to destination;;REGISTERED AS {ISO10589-ISIS.aoierrorMetricPathCost (96)};errorMetricOutputAdjacencies ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.OutputAdjacencies;MATCHES FOR Equality, Set Comparison, SetIntersection;BEHAVIOUR errorMetricOutputAdjacencies-BBEHAVIOURDEFINED AS The set of Adjacency (or Reachable Address) managed object identifiers representing theforwarding decisions based upon the error metric forthe destination;;REGISTERED AS {ISO10589-ISIS.aoierrorMetricOutputAdjacencies (97)};addressPrefix ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.AddressPrefix;MATCHES FOR Equality, Substrings;BEHAVIOUR addressPrefix-B BEHAVIOURDEFINED AS An Area Address (or prefix) of a destination area;;REGISTERED AS {ISO10589-ISIS.aoi addressPrefix(98)};defaultMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR defaultMetric-B BEHAVIOURDEFINED AS The default metric value for reachingthe specified prefix over this Circuit. If this attributeis changed while both the Reachable Address andthe Circuit are Enabled (i.e. state On), the actionsdescribed in clause 8.3.5.4 must be taken. The valueof zero is reserved to indicate that this metric is notsupported;;REGISTERED AS {ISO10589-ISIS.aoi defaultMetric(99)};delayMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR delayMetric-B BEHAVIOURDEFINED AS The delay metric value for reaching thespecified prefix over this Circuit.BEHAVIOURIfthis attribute is changed while both the ReachableAddress and the Circuit are Enabled (i.e. state On),the actions described in clause 8.3.5.4 must be taken.The value of zero is reserved to indicate that thismetric is not supported;;REGISTERED AS {ISO10589-ISIS.aoi delayMetric(100)};expenseMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR expenseMetric-B BEHAVIOURDEFINED AS The expense metric value for reachingthe specified prefix over this Circuit. If this attributeis changed while both the Reachable Address andthe Circuit are Enabled (i.e. state On), the actionsdescribed in clause 8.3.5.4 must be taken. The valueof zero is reserved to indicate that this metric is notsupported;;REGISTERED AS {ISO10589-ISIS.aoi expenseMetric(101)};errorMetric ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.HopMetric;MATCHES FOR Equality, Ordering;BEHAVIOUR errorMetric-B BEHAVIOURDEFINED AS The error metric value for reaching thespecified prefix over this Circuit. If this attribute ischanged while both the Reachable Address and theCircuit are Enabled (i.e. state On), the actions described in clause 8.3.5.4 must be taken. The value ofzero is reserved to indicate that this metric is notsupported;;REGISTERED AS {ISO10589-ISIS.aoi errorMetric(102)};defaultMetricType ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MetricType;MATCHES FOR Equality;BEHAVIOUR defaultMetricType-B BEHAVIOURDEFINED AS Indicates whether the default metric isinternal or external;;REGISTERED AS {ISO10589-ISIS.aoidefaultMetricType (103)};delayMetricType ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MetricType;MATCHES FOR Equality;BEHAVIOUR delayMetricType-B BEHAVIOURDEFINED AS Indicates whether the delay metric is internal or external;;REGISTERED AS {ISO10589-ISIS.aoi delayMetricType(104)};expenseMetricType ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MetricType;MATCHES FOR Equality;BEHAVIOUR expenseMetricType-B BEHAVIOURDEFINED AS Indicates whether the expense metric isinternal or external;;REGISTERED AS {ISO10589-ISIS.aoiexpenseMetricType (105)};errorMetricType ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MetricType;MATCHES FOR Equality;BEHAVIOUR errorMetricType-B BEHAVIOURDEFINED AS Indicates whether the error metric is internal or extternal;;REGISTERED AS {ISO10589-ISIS.aoi errorMetricType(106)};mappingType ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.MappingType;MATCHES FOR Equality;BEHAVIOUR mappingType-B BEHAVIOURDEFINED AS The type of mapping to be employed toascertain the SNPA Address to which a call shouldbe placed for this prefix. X.121 indicates that theX.121 address extraction algorithm is to be employed. This will extract the SNPA address from theIDI of an X.121 format IDP of the NSAP address towhich the NPDU is to be forwarded. Manual indicates that the set of addresses in the sNPAAddressesor LANAddresses characteristic are to be used. ForBroadcast circuits, only the value Manual is permitted;;REGISTERED AS {ISO10589-ISIS.aoi mappingType(107)};lANAddress ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.LANAddress;MATCHES FOR Equality;BEHAVIOUR lANAddress-B BEHAVIOURDEFINED AS Asingle LAN addresses to which anNPDU may be directed in order to reach an addresswhich matches the address prefix of the ReachableAddress. An exception is raised if an attempt ismade to enable the Reachable Address with the default value;;REGISTERED AS {ISO10589-ISIS.aoi lANAddress(108)};sNPAAddresses ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.SNPAAddresses;MATCHES FOR Equality;BEHAVIOUR sNPAAddresses-B BEHAVIOURDEFINED AS A set of SNPA addresses to which a callmay be directed in order to reach an address whichmatches the address prefix of the Reachable Address. Associated with each SNPA Address, but notvisible to System Management, is a variable lastFailure of Type BinaryAbsoluteTime;;REGISTERED AS {ISO10589-ISIS.aoi sNPAAddresses(109)};nonWrappingCounter ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.NonWrappingCounter;MATCHES FOR Equality, Ordering;BEHAVIOUR nonWrappingCounter-B BEHAVIOURDEFINED AS Non-replaceable, non-wrappingcounter;;-- This attibute is only defined in order to allow othercounter attributes to be derived from it.REGISTERED AS {ISO10589-ISIS.aoinonWrappingCounter (110)};areaTransmitPassword ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.Password;MATCHES FOR Equality;BEHAVIOUR areaTransmitPassword-B BEHAVIOURDEFINED AS The value to be used as a transmit password in Level 1 LSP, and SNP PDUs transmitted bythis Intermediate System;;REGISTERED AS {ISO10589-ISIS.aoiareaTransmitPassword (111)};areaReceivePasswords ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.Passwords;MATCHES FOR Equality;BEHAVIOUR areaReceivePasswords-B BEHAVIOURDEFINED AS The values to be used as receive passwords to check the receipt of Level 1 LSP, and SNPPDUs;;REGISTERED AS {ISO10589-ISIS.aoiareaReceivePasswords (112)};domainTransmitPassword ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.Password;MATCHES FOR Equality;BEHAVIOUR domainTransmitPassword-BBEHAVIOURDEFINED AS The value to be used as a transmit password in Level 2 LSP, and SNP PDUs transmitted bythis Intermediate System;;REGISTERED AS {ISO10589-ISIS.aoidomainTransmitPassword (113)};domainReceivePasswords ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.Passwords;MATCHES FOR Equality;BEHAVIOUR domainReceivePasswords-BBEHAVIOURDEFINED AS The values to be used as receive passwords to check the receipt of Level 2 LSP, and SNPPDUs;;REGISTERED AS {ISO10589-ISIS.aoidomainReceivePasswords (114)};circuitTransmitPassword ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.Password;MATCHES FOR Equality;BEHAVIOUR circuitTransmitPassword-BBEHAVIOURDEFINED AS The value to be used as a transmit password in IIH PDUs transmitted by this IntermediateSystem;;REGISTERED AS {ISO10589-ISIS.aoicircuitTransmitPassword (115)};circuitReceivePasswords ATTRIBUTEWITH ATTRIBUTE SYNTAXISO10589-ISIS.Passwords;MATCHES FOR Equality;BEHAVIOUR circuitReceivePasswords-BBEHAVIOURDEFINED AS The values to be used as receive passwords to check the receipt of IIH PDUs;;REGISTERED AS {ISO10589-ISIS.aoicircuitReceivePasswords (116)};authenticationFailures ATTRIBUTEDERIVED FROM nonWrappingCounter;BEHAVIOUR authenticationFailures-B BEHAVIOURDEFINED AS Count of authentication Failure notifications generated;;REGISTERED AS {ISO10589-ISIS.aoiauthenticationFailures (117)};11.2.12 Notification Definitions-- Note pduFormatError notification now included inNetwork layer definitionscorruptedLSPDetected NOTIFICATIONBEHAVIOUR corruptedLSPDetected-B BEHAVIOURDEFINED AS The Corrupted LSP Detected Notification is generated when a corrupted Link State PDUis detected in memory. The occurance of this eventis counted by the corruptedLSPsDetected counter.;;MODE NON-CONFIRMED;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noicorruptedLSPDetected (1)};lSPL1DatabaseOverload NOTIFICATIONBEHAVIOUR lSPL1DatabaseOverload-BBEHAVIOURDEFINED AS The LSP L1 Database Overload Notification is generated when the l1State of the systemchanges between On and Waiting or Waiting andOn. The stateChange argument is set to indicate theresulting state, and in the case of Waiting the sourceID is set to indicate the source of the LSP whichprecipitated the overload. The occurance of thisevent is counted by the lSPL1DatabaseOverloadscounter.;;MODE NON-CONFIRMED;PARAMETERSnotificationOverloadStateChange,notificationSourceID;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noilSPL1DatabaseOverload (2)};manualAddressDroppedFromArea NOTIFICATIONBEHAVIOUR manualAddressDroppedFromArea-BBEHAVIOURDEFINED AS The Manual Address Dropped FromArea Notification is generated when one of the manualAreaAddresses (specified on this system) is ignored when computing partitionAreaAddresses orareaAddresses because there are more than MaximumAreaAddresses distinct Area Addresses. TheareaAddress argument is set to the ignored Area Address. It is generated once for each Area Address inmanualAreaAddresses which is dropped. It is notlogged again for that Area Address until after it hasbeen reinstated into areaAddresses (i.e. it is only theaction of dropping the Area Address and not thestate of being dropped, which causes the event to begenerated). The occurance of this event is countedby the manualAddressDroppedFromAreas counter.;;MODE NON-CONFIRMED;PARAMETERSnotificationAreaAddress;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noimanualAddressDroppedFromArea (3)};attemptToExceedMaximumSequenceNumberNOTIFICATIONBEHAVIOURattemptToExceedMaximumSequenceNumber-BBEHAVIOURDEFINED AS The Attempt To Exceed Maximum Sequence Number Notification is generated when anattempt is made to increment the sequence numberof an LSP beyond the maximum sequence number.Following the generation of this event the operationof the Routeing state machine shall be disabled for atleast (MaxAge + ZeroAgeLifetime) seconds. Theoccurance of this event is counted by theattemptsToExceedMaximumSequenceNumbercounter.;;MODE NON-CONFIRMED;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noiattemptToExceedMaximumSequenceNumber (4)};sequenceNumberSkip NOTIFICATIONBEHAVIOUR sequenceNumberSkip-B BEHAVIOURDEFINED AS The Sequence Number Skipped Notification is generated when the sequence number of anLSP is incremented by more than one. The occurance of this event is counted by the sequenceNumberSkips counter.;;MODE NON-CONFIRMED;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noisequenceNumberSkip (5)};ownLSPPurge NOTIFICATIONBEHAVIOUR ownLSPPurge-B BEHAVIOURDEFINED AS The Own LSP Purged Notification isgenerated when a zero aged copy of a system's ownLSP is received from some other system. This represents an erroneous attempt to purge the local system's LSP. The occurance of this event is countedby the ownLSPPurges counter.;;MODE NON-CONFIRMED;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noi ownLSPPurge(6)};partitionVirtualLinkChange NOTIFICATIONBEHAVIOUR partitionVirtualLinkChange-BBEHAVIOURDEFINED AS The Partition Virtual Link Change Notification is generated when a virtual link (for the purposes of Level 1 partition repair) is either created ordeleted. The relative order of events relating to thesame Virtual Link must be preserved. The occurance of this event is counted by the partitionVirtualLinkChanges counter.;;MODE NON-CONFIRMED;PARAMETERSnotificationVirtualLinkChange,notificationVirtualLinkAddress;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noipartitionVirtualLinkChange (7)};lSPL2DatabaseOverload NOTIFICATIONBEHAVIOUR lSPL2DatabaseOverload-BBEHAVIOURDEFINED AS The LSP L2 Database Overload Notification is generated when the l2State of the systemchanges between On and Waiting or Waiting andOn. The stateChange argument is set to indicate theresulting state, and in the case of Waiting the sourceID is set to indicate the source of the LSP whichprecipitated the overload. The occurance of thisevent is counted by the lSPL2DatabaseOverloadscounter.;;MODE NON-CONFIRMED;PARAMETERSnotificationOverloadStateChange,notificationSourceID;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noilSPL2DatabaseOverload (8)};iDFieldLengthMismatch NOTIFICATIONBEHAVIOUR iDFieldLengthMismatch-BBEHAVIOURDEFINED AS The iDFieldLengthMismatch Notification is generated when a PDU is received with a different value for ID field length to that of thereceiving Intermediate system. The occurance of thisevent is counted by the iDFieldLengthMismatchescounter.;;MODE NON-CONFIRMED;PARAMETERSnotificationIDLength,notificationSourceID;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noiiDFieldLengthMismatch (9)};circuitChange NOTIFICATIONBEHAVIOUR circuitChange-B BEHAVIOURDEFINED AS The Circuit Change Notification is generated when the state of the Circuit changes from Onto Off or from Off to On. The relative order ofevents relating to the same Circuit must be preserved. The occurance of this event is counted bythe circuitChanges counter.;;MODE NON-CONFIRMED;PARAMETERSnotificationNewCircuitState;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noi circuitChange(10)};adjacencyStateChange NOTIFICATIONBEHAVIOUR adjacencyStateChange-B BEHAVIOURDEFINED AS The Adjacency State Change Notification is generated when the state of an Adjacency onthe Circuit changes from Up to Down or Down toUp (in the latter case the Reason argument is omitted). For these purposes the states Up andUp/dormant are considered to be Up, and any otherstate is considered to be Down. The relative order ofevents relating to the same Adjacency must be preserved. The occurance of this event is counted bythe adjacencyStateChanges counter.;;MODE NON-CONFIRMED;PARAMETERSnotificationAdjacentSystem,notificationNewAdjacencyState,notificationReason,notificationPDUHeader,notificationCalledAddress,notificationVersion;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noiadjacencyStateChange (11)};initializationFailure NOTIFICATIONBEHAVIOUR initializationFailure-B BEHAVIOURDEFINED AS The Initialisation Failure Notification isgenerated when an attempt to initialise with an adjacent system fails as a result of either Version Skewor Area Mismatch. In the case of Version Skew, theAdjacent system argument is not present. The occurance of this event is counted by the initializationFailures counter.;;MODE NON-CONFIRMED;PARAMETERSnotificationAdjacentSystem,notificationReason,notificationPDUHeader,notificationCalledAddress,notificationVersion;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noiinitializationFailure (12)};rejectedAdjacency NOTIFICATIONBEHAVIOUR rejectedAdjacency-B BEHAVIOURDEFINED AS The Rejected Adjacency Notification isgenerated when an attempt to create a new adjacency is rejected, because of a lack of resources.The occurance of this event is counted by the rejectedAdjacencies counter.;;MODE NON-CONFIRMED;PARAMETERSnotificationAdjacentSystem,notificationReason,notificationPDUHeader,notificationCalledAddress,notificationVersion;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noirejectedAdjacency (13)};lanL1DesignatedIntermediateSystemChangeNOTIFICATIONBEHAVIOURlanL1DesignatedIntermediateSystemChange-BBEHAVIOURDEFINED AS The LAN L1 Designated IntermediateSystem Change Notification is generated when thelocal system either elects itself or resigns as beingthe LAN L1 Designated Intermediate System on thiscircuit. The relative order of these events must bepreserved. The occurance of this event is counted bythe lanL1DesignatedIntermediateSystemChangescounter.;;MODE NON-CONFIRMED;PARAMETERSnotificationDesignatedIntermediateSystemChange;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noilanL1DesignatedIntermediateSystemChange (14)};exceededMaximumSVCAdjacencies NOTIFICATIONBEHAVIOUR exceededMaximumSVCAdjacencies-BBEHAVIOURDEFINED AS The Exceeded Maximum SVC Adjacencies Notification is generated when there is no freeadjacency on which to establish an SVC for a newdestination.(see clause 8.3.2.3) The occurance ofthis event is counted by thetimesExceededMaximumSVCAdjacencies counter.;;MODE NON-CONFIRMED;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noiexceededMaximumSVCAdjacencies (15)};exceededMaximumCallAttempts NOTIFICATIONBEHAVIOUR exceededMaximumCallAttempts-BBEHAVIOURDEFINED AS The Exceeded Maximum Call AttemptsNotification is generated when recallCount becomesequal to maximumCallAttempts. The occurance ofthis event is counted by the timesExceededMaximumCallAttempts counter.;;MODE NON-CONFIRMED;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noiexceededMaximumCallAttempts (16)};lanL2DesignatedIntermediateSystemChangeNOTIFICATIONBEHAVIOURlanL2DesignatedIntermediateSystemChange-BBEHAVIOURDEFINED AS The LAN L2 Designated IntermediateSystem Change Notification is generated when thelocal system either elects itself or resigns as beingthe LAN L2 Designated Intermediate System on thiscircuit. The relative order of these events must bepreserved. The occurance of this event is counted bythe lanL2DesignatedIntermediateSystemChangescounter.;;MODE NON-CONFIRMED;PARAMETERSnotificationDesignatedIntermediateSystemChange;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noilanL2DesignatedIntermediateSystemChange (17)};authenticationFailure NOTIFICATIONBEHAVIOUR authenticationFailure-B BEHAVIOURDEFINED AS Generated when a PDU is received withan incorrect Authentication information field;;MODE NON-CONFIRMED;PARAMETERSnotificationAdjacentSystem;WITH INFORMATION SYNTAXISO10589-ISIS.NotificationInfo;REGISTERED AS {ISO10589-ISIS.noiauthenticationFailure (18)};11.2.13 Action Definitions-- Note: The following actions have been proposed (inSC21 N4977) for inclusion in DMI. Until such timeas this is completed, the definitions of these actionsare given here.--activate ACTIONBEHAVIOUR activate-B BEHAVIOURDEFINED AS Sets OperationalState to `enabled' andcommences operation;;MODE CONFIRMED;PARAMETERS successResponse, failureResponse,failureReason;WITH INFORMATION SYNTAXISO10589-ISIS.ActionInfo;WITH REPLY SYNTAX ISO10589-ISIS.ActionReply;REGISTERED AS {ISO10589-ISIS.acoi activate (1)};deactivate ACTIONBEHAVIOUR deactivate-B BEHAVIOURDEFINED AS Sets OperationalState to `disabled' andceases operation;;MODE CONFIRMED;PARAMETERS successResponse, failureResponse,failureReason;WITH INFORMATION SYNTAXISO10589-ISIS.ActionInfo;WITH REPLY SYNTAX ISO10589-ISIS.ActionReply;REGISTERED AS {ISO10589-ISIS.acoi deactivate (2)};11.2.14 Parameter DefinitionsiSO10589-NB-p1 PARAMETERCONTEXT CREATE-INFO;WITH SYNTAX ISO10589-ISIS.ISType;BEHAVIOUR iSO10589-NB-p1-B BEHAVIOURDEFINED AS The value to be given to the iStype attribute on MO creation. This parameter is mandatory;;REGISTERED AS {ISO10589-ISIS.proiiSO10589-NB-p1 (1)};iSO10589Circuit-MO-p1 PARAMETERCONTEXT CREATE-INFO;WITH SYNTAX ISO10589-ISIS.CircuitType;BEHAVIOUR iSO10589Circuit-MO-p1-BBEHAVIOURDEFINED AS The value to be given to the type attribute on MO creation. This parameter is mandatory;;REGISTERED AS {ISO10589-ISIS.proiiSO10589Circuit-MO-p1 (2)};reachableAddressP1 PARAMETERCONTEXT CREATE-INFO;WITH SYNTAX ISO10589-ISIS.AddressPrefix;BEHAVIOUR reachableAddressp1-B BEHAVIOURDEFINED AS The value to be given to the addressPrefix attribute on MO creation. This parameter is mandatory;;REGISTERED AS {ISO10589-ISIS.proireachableAddressP1 (3)};reachableAddressP2 PARAMETERCONTEXT CREATE-INFO;WITH SYNTAX ISO10589-ISIS.MappingType;BEHAVIOUR reachableAddressp2-B BEHAVIOURDEFINED AS The value to be given to the mappingType attribute on MO creation. This parameteris only permitted when the `type' of the parent circuit is either `broadcast' or `DA'. In those cases thedefault value is `manual';;REGISTERED AS {ISO10589-ISIS.proireachableAddressP2 (4)};manualAdjacencyP1 PARAMETERCONTEXT CREATE-INFO;WITH SYNTAX ISO10589-ISIS.LANAddress;BEHAVIOUR manualAdjacencyP1-B BEHAVIOURDEFINED AS The value to be given to the lANAddress attribute on MO creation;;REGISTERED AS {ISO10589-ISIS.proimanualAdjacencyP1 (5)};manualAdjacencyP2 PARAMETERCONTEXT CREATE-INFO;WITH SYNTAX ISO10589-ISIS.EndSystemIDs;BEHAVIOUR manualAdjacencyP2-B BEHAVIOURDEFINED AS The value to be given to the endSystemIDs attribute on MO creation;;REGISTERED AS {ISO10589-ISIS.proimanualAdjacencyP2 (6)};successResponse PARAMETERCONTEXT ACTION-REPLY;WITH SYNTAX ISO10589-ISIS.ResponseCode;BEHAVIOUR successResponse-B BEHAVIOURDEFINED AS Returned in the responseCode field ofan ActionReply when the action has completed successfully.;;REGISTERED AS {ISO10589-ISIS.proi successResponse(7)};failureResponse PARAMETERCONTEXT ACTION-REPLY;WITH SYNTAX ISO10589-ISIS.ResponseCode;BEHAVIOUR failureResponse-B BEHAVIOURDEFINED AS Returned in the responseCode field ofan ActionReply when the action failed to complete.The failureReason parameter is returned with this responseCode, giving additional information;;REGISTERED AS {ISO10589-ISIS.proi failureResponse(8)};failureReason PARAMETERCONTEXT ACTION-REPLY;WITH SYNTAX ISO10589-ISIS.ActionFailureReason;BEHAVIOUR failureReason-B BEHAVIOURDEFINED AS Gives the reason why an entity failed toactivate or deactivate.;;REGISTERED AS {ISO10589-ISIS.proi failureReason(9)};constraintViolation PARAMETERCONTEXT SPECIFIC-ERROR;WITH SYNTAXISO10589-ISIS.ConstraintViolationReason;BEHAVIOUR constraintViolation-B BEHAVIOURDEFINED AS The specific error returned on failure ofa REPLACE operation when the MO prohibits suchoperations under certain conditions, for examplewhile the MO is in the disabled operational state.;;REGISTERED AS {ISO10589-ISIS.proiconstraintViolation (10)};notificationReceivingAdjacency PARAMETERCONTEXT EVENT-INFO;WITH SYNTAXISO10589-ISIS.LocalDistinguishedName;BEHAVIOUR notificationReceivingAdjacency-BBEHAVIOURDEFINED AS The local managed object name of theadjacency upon which the NPDU was received;;REGISTERED AS {ISO10589-ISIS.proinotificationReceivingAdjacency (11)};notificationIDLength PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.IDLength;BEHAVIOUR notificationIDLength-B BEHAVIOURDEFINED AS The IDLength specified in the ignoredPDU;;REGISTERED AS {ISO10589-ISIS.proinotificationIDLength (12)};notificationAreaAddress PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.AreaAddress;BEHAVIOUR notificationAreaAddress-B BEHAVIOURDEFINED AS The Area Address which caused MaximumAreaAddresses to be exceeded;;REGISTERED AS {ISO10589-ISIS.proinotificationAreaAddress (13)};notificationSourceID PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.SourceID;BEHAVIOUR notificationSourceID-B BEHAVIOURDEFINED AS The source ID of the LSP;;REGISTERED AS {ISO10589-ISIS.proinotificationSourceID (14)};notificationVirtualLinkChange PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.VirtualLinkChange;BEHAVIOUR notificationVirtualLinkChange-BBEHAVIOURDEFINED AS This indicates whether the event wasgenrated as a result of the creation or deletion of aVirtual Link between two Level 2 Intermediate Systems.;;REGISTERED AS {ISO10589-ISIS.proinotificationVirtualLinkChange (15)};notificationVirtualLinkAddress PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.NetworkEntityTitle;BEHAVIOUR notificationVirtualLinkAddress-BBEHAVIOURDEFINED AS The Network Entity Title of the Level 2Intermediate System at the remote end of the virtuallink;;REGISTERED AS {ISO10589-ISIS.proinotificationVirtualLinkAddress (16)};notificationNewCircuitState PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.NewCircuitState;BEHAVIOUR notificationNewCircuitState-BBEHAVIOURDEFINED AS The direction of the Circuit state changespecified as the resulting state. i.e. a change from Onto Off is specified as Off;;REGISTERED AS {ISO10589-ISIS.proinotificationNewCircuitState (17)};notificationNewAdjacencyState PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.NewAdjacencyState;BEHAVIOUR notificationNewAdjacencyState-BBEHAVIOURDEFINED AS The direction of the Adjacency statechange specified as the resulting state. i.e. a changefrom Up to Down is specified as Down. Any stateother than Up is considered to be Down.;;REGISTERED AS {ISO10589-ISIS.proinotificationNewAdjacencyState (18)};notificationAdjacentSystem PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.SystemID;BEHAVIOUR notificationAdjacentSystem-BBEHAVIOURDEFINED AS The system ID of the adjacent system;;REGISTERED AS {ISO10589-ISIS.proinotificationAdjacentSystem (19)};notificationReason PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.Reason;BEHAVIOUR notificationReason-B BEHAVIOURDEFINED AS The associated Reason;;REGISTERED AS {ISO10589-ISIS.proinotificationReason (20)};notificationPDUHeader PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.PDUHeader;BEHAVIOUR notificationPDUHeader-B BEHAVIOURDEFINED AS The header of the PDU which causedthe notification;;REGISTERED AS {ISO10589-ISIS.proinotificationPDUHeader (21)};notificationCalledAddress PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.SNPAAddress;BEHAVIOUR notificationCalledAddres-BBEHAVIOURDEFINED AS The SNPA Address which was beingcalled when the Adjacency was taken down as a result of a call reject;;REGISTERED AS {ISO10589-ISIS.proinotificationCalledAddress (22)};notificationVersion PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.Version;BEHAVIOUR notificationVersion-B BEHAVIOURDEFINED AS The version number reported by theother system;;REGISTERED AS {ISO10589-ISIS.proinotificationVersion (23)};notificationDesignatedIntermediateSystemChangePARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.DesignatedISChange;BEHAVIOURnotificationDesignatedIntermediateSystemChange-BBEHAVIOURDEFINED AS The direction of the change in Designated Intermediate System status of this system;;REGISTERED AS {ISO10589-ISIS.proinotificationDesignatedIntermediateSystemChange(24)};notificationOverloadStateChange PARAMETERCONTEXT EVENT-INFO;WITH SYNTAX ISO10589-ISIS.OverloadStateChange;BEHAVIOUR notificationOverloadStateChange-BBEHAVIOURDEFINED AS The direction of the change in Overloadstatus;;REGISTERED AS {ISO10589-ISIS.proinotificationOverloadStateChange (25)};11.2.15 Attribute Groupscounters ATTRIBUTE GROUPDESCRIPTION The group of all counters;REGISTERED AS {ISO10589-ISIS.agoi counters (1)};11.2.16 Behaviour DefinitionsresettingTimer-B BEHAVIOURDEFINED AS This attribute specifies the interval between certain events in the operation of the protocolstate machine. If the value of this attribute ischanged to a new value t while the protocol statemachine is in operation, the implementation shalltake the necessary steps to ensure that for any timeinterval which was in progress when the corresponding attribute was changed, the next expiration of thethat interval takes place t seconds from the originalstart of that interval, or immediately, whichever islater. The precision with which this time shall be implemented shall be the same as that associated withthe basic operation of the timer attribute;replaceOnlyWhileDisabled-B BEHAVIOURDEFINED AS This attribute shall only permit the REPLACE operation to be performed on it while theMO is in the Disabled Operational State. An attempt to perform a REPLACE operation while theMO is in the Enabled Operation State shall fail withthe generation of the constraintViolation specific error.;resourceLimiting-B BEHAVIOURDEFINED AS This attribute places limits on some resource". In general implementations may allocatereources up to this limit when the managed object isenabled and it may be impossible to change the allocation without first disabling and re-enabling themanaged object. Therefore this International Standard only requires that it shall be possible to performa REPLACE operation on this attribute while theMO is disabled. However some implementationsmay be able to to change the allocation of resourceswithout first disabling the MO. In this case it is permitted to increase the value of the atribute at anytime, but it shall not be decreased below the currently used" value of the resource. Where an attempt to perform a REPLACE operation fails eitherbecause the MO is enabled, or because an attempthas been made to decrease the value, the REPLACEoperation shall fail with the generation of the constraintViolation specific error.;11.2.17 ASN1 ModulesISO10589-ISIS{tbd1}DEFINITIONS ::= BEGIN-- object identifier definitionssc6 OBJECT IDENTIFIER ::= {joint-iso-ccitt sc6(?)}-- value to be assigned by SC21 secretariatisisoi OBJECT IDENTIFIER ::= {sc6 iSO10589(?)}-- value to be assigned by SC6 secretariatmoi 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 TBSActionInfo ::= SET OF ParameterActionReply ::= 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 AreaAddressBoolean ::= BOOLEANCircuitID ::= 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 SystemIDGraphicString ::= GRAPHICSTRINGHelloTimer ::= 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 requredLSPID ::= 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 ParameterNSAPAddress ::= OCTETSTRING(SIZE(1..20))OctetString ::= OCTETSTRINGOriginatingLSPBufferSize ::= INTEGER(512..1492)OutputAdjacencies ::= SET OF LocalDistinguishedNameOverloadStateChange ::= 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 PasswordPathMetric ::= 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 IDENTIFIERRecallTimer ::= 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..9SNPAAddresses ::= SET OF SNPAAddressCircuitType ::= 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 ::= GRAPHICSTRINGWaitingTime ::= INTEGER(1..65535)maximumPathSplits-Default INTEGER ::= 2MaximumPathSplits-Permitted ::= INTEGER(1..32)maximumBuffers-Default INTEGER ::= ImpSpecificMaximumBuffers-Permitted ::= INTEGER(1..ImpSpecific)minimumLSPTransmissionInterval-Default INTEGER ::=5MinimumLSPTransmissionInterval-Permitted ::=INTEGER(5..30)maximumLSPGenerationInterval-Default INTEGER ::=900MaximumLSPGenerationInterval-Permitted ::=INTEGER(60..900)minimumBroadcastLSPTransmissionInterval-DefaultINTEGER ::=33MinimumBroadcastLSPTransmissionInterval-Permitted ::=INTEGER(1..65535)completeSNPInterval-Default INTEGER ::= 10CompleteSNPInterval-Permitted ::= INTEGER(1..600)originatingL1LSPBufferSize-Default INTEGER ::=receiveLSPBufferSizeOriginatingL1LSPBufferSize-Permitted ::=INTEGER(512..receiveLSPBufferSize)manualAreaAddresses-Default AreaAddresses ::= {}ManualAreaAddresses-Permitted ::= AreaAddresses(SIZE(0..MaximumAreaAddresses))minimumLSPGenerationInterval-Default INTEGER ::= 30MinimumLSPGenerationInterval-Permitted ::=INTEGER(5..300)defaultESHelloTime-Default INTEGER ::= 600DefaultESHelloTime-Permitted ::= INTEGER(1..65535)pollESHelloRate-Default INTEGER ::= 50PollESHelloRate-Permitted ::= INTEGER(1..65535)partialSNPInterval-Default INTEGER ::= 2PartialSNPInterval-Permitted ::= INTEGER(1..65535)waitingTime-Default INTEGER ::= 60WaitingTime-Permitted ::= INTEGER(1..65535)dRISISHelloTimer-Default INTEGER ::= 1DRISISHelloTimer-Permitted ::= INTEGER(1..65535)originatingL2LSPBufferSize-Default INTEGER ::=receiveLSPBufferSizeOriginatingL2LSPBufferSize-Permitted ::=INTEGER(512..receiveLSPBufferSize)maximumVirtualAdjacencies-Default INTEGER ::= 2MaximumVirtualAdjacencies-Permitted ::=INTEGER(0..32)helloTimer-Default INTEGER ::= 10HelloTimer-Permitted ::= INTEGER(1..21845)defaultMetric-Default INTEGER ::= 20DefaultMetric-Permitted ::= INTEGER(1..MaxLinkMetric)optionalMetric-Default INTEGER ::= 0OptionalMetric-Permitted ::=INTEGER(0..MaxLinkMetric)metricType-Default MetricType ::= InternaliSISHelloTimer-Default INTEGER ::= 3ISISHelloTimer-Permitted ::= INTEGER(1..21845)externalDomain-Default BOOLEAN ::= TRUEl1IntermediateSystemPriority-Default INTEGER ::= 64L1IntermediateSystemPriority-Permitted ::=INTEGER(1..127)callEstablishmentMetricIncrement-Default INTEGER ::= 0CallEstablishmentMetricIncrement-Permitted ::=INTEGER(0..MaxLinkMetric)idleTimer-Default INTEGER ::= 30IdleTimer-Permitted ::= INTEGER(0..65535)initialMinimumTimer-Default INTEGER ::= 55InitialMinimumTimer-Permitted ::= INTEGER(1..65535)reserveTimer-Default INTEGER ::= 600ReserveTimer-Permitted ::= INTEGER(1..65535)maximumSVCAdjacencies-Default INTEGER ::= 1MaximumSVCAdjacencies-Permitted ::=INTEGER(1..65535)reservedAdjacency-Default BOOLEAN ::= FALSEneighbourSNPAAddress-Default INTEGER ::= 0recallTimer-Default INTEGER ::= 60RecallTimer-Permitted ::= INTEGER(0..65535)maximumCallAttempts-Default INTEGER ::= 10MaximumCallAttempts-Permitted ::= INTEGER(0..255)manualL2OnlyMode-Default BOOLEAN ::= FALSEl2IntermediateSystemPriority-Default INTEGER ::= 64L2IntermediateSystemPriority-Permitted ::=INTEGER(1..127)lANAddress-Default LANAddress ::= 000000000000sNPAAddresses-Default SNPAAddresses::= {}password-Default Password ::= {}passwords-Default Passwords ::= {} -- The empty setEND
12 Conformance12.1 Static Conformance Requirements12.1.1 Protocol Implementation ConformanceStatementA Protocol Implementation Conformance Statement (PICS)shall be completed in respect of any claim for conformanceof an implementation to this International Standard: thePICS shall be produced in accordance with the relevantPICS pro-forma in Annex A.12.1.2 Static Conformance for all ISsA system claiming conformance to this International Standard shall be capable of:a)calculating a single minimum cost route to each destination according to 7.2.6 for the default metric specified in 7.2.2;b)utilising Link State information from a system onlywhen an LSP with LSP number 0 and remaining lifetime>0 is present according to 7.2.5;c)removing excess paths according to 7.2.7d)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 forwarding process according to 7.4.3.2; and3)performing the decapsulation operations in the receive process according to 7.4.4;TEMPORARY NOTE may need to reorganise clause 7.4.4 in order to make it crystalclear what is required in the receive process inthe presence/absence of partition repairg)computing area addresses according to 7.2.11;h)generating local Link State information as required by7.3.2;i)including information from Manual Adjacencies according to 7.3.3.1;j)if (and only if) Reachable Addresses are supported, including information from Reachable Addresses according 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 according to 7.3.6;n)generating an LSP checksum according to 7.3.11;o)operating the Update Process according to 7.3.127.3.17 including controlling the rate of LSP transmission only for each broadcast circuit (if any) accordingto 7.3.15.6;p)operating the LSP database overload procedures according to 7.3.19.1;q)selecting the appropriate forwarding database according to 7.4.2;r)forwarding ISO 8473 PDUs according to 7.4.3.1 and7.4.3.3;s)operating the receive process according to 7.4.4;TEMPORARY NOTE item 1 of the second bulletedlist is only required if you implement partition repair.We need to reorganise the structure so we can pullthis out.t)performing on each supported Point-to-Point circuit (ifany):1)forming and maintaining adjacencies according to8.2;u)performing on each supported ISO 8208 circuit (ifany)1)SVC establishment according to 8.3.2.1 using thenetwork layer protocols according to 8.3.1;2)If Reachable Addresses are supported, the operations specified in 8.3.2.2 8.3.5.6.3)If call
Estab
lish
ment
Met
ricIncrement greaterthan zero are supported, the operations specified in8.3.5.3.4)If the Reverse Path Cache is supported, the operations specified in 8.3.3v)performing on each supported broadcast circuit (ifany)1)the pseudonode operations according to 7.2.3;2)controlling the rate of LSP transmission accordingto 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 accordingto clause 9;x)providing a system environment in accordance withclause 10;y)being managed via the system management attributesdefined in clause 11. For all attributes referenced inthenormative text, the default value (if any) shall be supported. Other values shall be supported if referencedin a REQUIRED VALUES clause of the GDMOdefinition;z)If authentication procedures are implemented:1)the authentication field processing functions ofclauses 7.3.77.3.10, 7.3.15.17.3.15.4, 8.2.38.2.4, and 8.4.1.1;2)the Authentication Information field of thePDU in clauses 9.59.13.12.1.3 Static Conformance Requirements forlevel 1 ISsA system claiming conformance to this International Standard as a level 1 IS shall conform to the requirements of12.1.2 and in addition shall be capable ofa)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 supported broadcast circuit (if any) according to 7.3.8;d)performing the actions in Level 1 Waiting State according to 7.3.19.212.1.4 Static Conformance Requirements forlevel 2 ISsA system claiming conformance to this International Standard as a level 2 IS shall conform to the requirements of12.1.2 and in addition shall be capable ofa)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 supported broadcast circuit (if any) according to 7.3.10;d)performing the actions in Level 2 Waiting State according to 7.3.19.3.12.2 Dynamic Conformance12.2.1 Receive Process ConformanceRequirementsAny protocol function supported shall be implemented inaccordance with 7.4.4.12.2.2 Update Process ConformanceRequirementsAny protocol function supported shall be implemented inaccordance with 7.3 and its subclauses.Any PDU transmitted shall be constructed in accordancewith the appropriate subclauses of 9.12.2.3 Decision Process ConformanceRequirementsAny protocol function supported shall be implemented inaccordance with 7.2 and its subclauses.12.2.4 Forwarding Process ConformanceRequirementsAny protocol function supported shall be implemented inaccordance with 7.4 and its subclauses.12.2.5 Performance RequirementsThis International Standard requires that the following performance criteria be met. These requirements apply regardless of other demands on the system; if an Intermediate system has other tasks as well, those will only get resourcesnot required to meet these criteria.Each Intermediate system implementation shall specify (inits PICS):a)the maximum number of other Intermediate systems itcan handle. (For L1 Intermediate systems that meansIntermediate systems in the area; for L2 Intermediatesystems that is the sum of Intermediate systems in thearea and Intermediate systems in the L2 subdomain.)Call this limit N.b)the maximum supported forwarding rate in ISO 8473PDUs per second.12.2.5.1 Performance requirements on the UpdateprocessThe implementation shall guarantee the update processenough resources to process N LSPs per 30 seconds. (Resources = CPU, memory, buffers, etc.)In a stable topology the arrival of a single new LSP on acircuit shall result in the propagation of that new LSP overthe other circuits of the IS within one second, irrespectiveof the forwarding load for ISO 8473 data PDUs.12.2.5.2 Performance requirement on the DecisionprocessThe implementation shall guarantee the decision processenough resources to complete (i.e. start to finish) within 5seconds, in a stable topology while forwarding at the maximum rate. (For L2 Intermediate Systems, this applies to thetwo levels together, not each level separately.)12.2.5.3 Reception and Processing of PDUsAn ideal Intermediate system would be able to correctlyprocess all PDUs, both control and data, with which it waspresented, while simultaneously running the decision process and responding to management requests. However, inthe implementations of real Intermediate systems somecompromises must be made. The way in which these compromises are made can dramatically affect the correctnessof operation of the Intermediate system. The following general principles apply.a)A stable topology should result in stable routes whenforwarding at the maximum rated forwarding rate.b)Some forwarding progress should always be made (albeit over incorrect routes) even in the presence of amaximally unstable topology.In order to further characterise the required behaviour, it isnecessary to identify the following types of traffic.a)IIH traffic. This traffic is important for maintaining Intermediate system adjacencies and hence the Intermediate system topology. In order to prevent gratuitoustopology changes it is essential that Intermediate system adjacencies are not caused to go down erroneously. In order to achieve this no more thanISISHoldingMultiplier - 1 IIH PDUs may bedropped between any pair of Intermediate systems. Asafer requirement is that no IIH PDUs are dropped.The rate of arrival of IIH PDUs is approximately constant and is limited on Pointto-Point links to 1/iSIS
Hello
Timer and on LANs to a value of approximately 2(n/iSIS
Hello
Timer) + 2, where n is thenumber of Intermediate systems on the LAN (assuming the worst case that they are all Level 2 Intermediate systems).b)ESH PDU traffic. This traffic is important for maintaining End system adjacencies, and has relatively lowprocessing latency. As with IIH PDUs, loss of Endsystem adjacencies will cause gratuitous topologychanges which will result in extra control traffic.The rate of arrival of ESH PDUs on Pointto-Pointlinks is limited to approximately 1/Default
ES
Hello
Timer under all conditions. On LANs the backgroundrate is approximately n/DefaultESHelloTimerwhere n is the number of End systems on the LAN.The maximum rate during polling is limited to approximately n/pollESHelloRate averaged over a period of about 2 minutes. (Note that the actual peak arrival rate over a small interval may be much higherthan this.)c)LSP (and SNP) traffic. This traffic will beretransmitted indefinitely by the update process if it isdropped, so there is no requirement to be able to process every received PDU. However, if a substantialproportion are lost, the rate of convergence to correctroutes will be affected, and bandwidth and processingpower will be wasted.On Point-to-Point links the peak rate of arrival is limited only by the speed of the data link and the othertraffic flowing on that link. The maximum averagerate is determined by the topology.On LANs the rate is limited at a first approximation toa maximum rate of 1000/min
i
mum
Broad
cast
LSP
Trans
mis
sion
Int
er
val, however it is possible thatthis may be multiplied by a factor of up to n, where nis the number of Intermediate systems on the LAN, forshort periods. A Intermediate system shall be able toreceive and process at least the former rate withoutloss, even if presented with LSPs at the higher rate.(i.e. it is permitted to drop LSPs, but must process atleast 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 astable topology) is dependent on the maximum supported configuration size and the settings ofmaximumLSPGenerationInterval. For these purposes the default value of 900 seconds can be assumed. The number of LSPs per second is then veryapproximately (n1 + n2 +ne/x)/900 where n1 is thenumber of level 1 Intermediate systems, n2 the number of level 2 Intermediate systems, ne the number ofEnd system IDs and x the number of ID which can befitted into a single LSP.NOTE This gives a value around 1 per second fortypical maximum configurations of:4000 IDs100 L1 Intermediate systems per area400 L2 Intermediate systems.d)Data Traffic. This is theoretically unlimited and canarrive at the maximum data rate of the Pointto-Pointlink or LAN (for ISO 8802.3 this is 14,000 PDUs persecond). In practice it will be limited by the operationof the congestion avoidance and control algorithms,but owing to the relatively slow response time of thesealgorithms, substantial peaks are likely to occur.An Intermediate system shall state in its PICS itsmaximum forwarding rate. This shall be quoted underat least the following conditions.1)A stable topology of maximum size.2)A maximally unstable topology. This figure shallbe non-zero, but may reasonably be as low as 1PDU per second.The following constraints must be met.a)The implementation shall be capable of receiving themaximum rate of ISH PDUs without loss wheneverthe following conditions hold1)The data forwarding traffic rate averaged over anyperiod of one second does not exceed the ratewhich the implementation claims to support2)The ESH and LSP rates do not exceed the background (stable topology) rate.b)If it is unavoidable that PDUs are dropped, it is a goalthat the order of retaining PDUs shall be as follows(i.e. It is least desirable for IIH PDUs to be dropped).1)IIH PDUs2)ESH PDUs3)LSPs and SNPs4)data PDUs.However, no class of traffic shall be completelystarved. One way to achieve this is to allocate a queueof suitable length to each class of traffic and place thePDUs onto the appropriate queue as they arrive. If thequeue is full the PDUs are discarded. Processor resources shall be allocated to the queues to ensure thatthey all make progress with the same priorities asabove. This model assumes that an implementation iscapable of receiving PDUs and selecting their correctqueue at the maximum possible data rate (14,000PDUs per second for a LAN). If this is not the case,reception of data traffic at a rate greater than somelimit (which must be greater than the maximum ratedlimit) will cause loss of some IIH PDUs even in a stable topology. This limit shall be quoted in the PICS ifit exists.NOTE - Starting from the stable topology condition at maximum data forwarding rate, an increase in the arrival rate ofdata PDUs will initially only cause some data NPDUs to belost. As the rate of arrival of data NPDUs is further increased a point may be reached at which random PDUs aredropped. This is the rate which must be quoted in the PICS12.2.5.4 TransmissionSufficient processor resources shall be allocated to thetransmission process to enable it to keep pace with reception for each PDU type. Where prioritisation is required, thesame order as for reception of PDU types applies.Annex APICS Proforma(This annex is normative)A.1 IntroductionThe supplier of a protocol implementation which is claimedto conform to International Standard ISO 10589, whether asa level 1 or level 2 Intermediate system implementation,shall complete the applicable Protocol ImplementationConformance Statement (PICS) proforma.A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities 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 reducethe risk of failure to conform to the standard throughoversight;-by the supplier and acquirer or potential acquirer of the implementation, as a detailed indication ofthe capabilities of the implementation, stated relativeto the common basis for understanding provided bythe standard PICS proforma;-by the user or potential user of the implementation, as a basis for initially checking the possibility ofinterworking with another implementation (note that,while interworking can never be guaranteed, failure tointerwork can often be predicted from incompatiblePICS's);-by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim forconformance of the implementation.A.2 Abbreviations and Special SymbolsA.2.1 Status-related symbolsM mandatoryO optionalO.<n> optional, but support of at least one of thegroup of options labelled by the same numeral<n> is required.X prohibited not applicablec.<p> conditional requirement, according to condition <p>A.3 Instructions for Completing thePICS ProformasA.3.1 General structure of the PICS proformaThe first part of the PICS proforma ImplementationIdentification and Protocol Summary is to be completedas indicated with the information necessary to identify fullyboth the supplier and the implementation.The main part of the PICS proforma is a fixed-format questionnaire divided into subclauses each containing a group ofindividual items. Answers to the questionnaire items are tobe provided in the rightmost column, either by simplymarking an answer to indicate a restricted choice (usuallyYes or No), or by entering a value or a set or range of values. (Note that there are some items where two or morechoices from a set of possible answers can apply: all relevant choices are to be marked.)Each item is identified by an item reference in the first column; the second column contains the question to be answered; the third column contains the reference or references to the material that specifies the item in the mainbody of the standard. the remaining columns record thestatus of the item whether support is mandatory, optionalor conditional and provide the space for the answers: seeA.3.4 below.A supplier may also provide or be required to providefurther information, categorised as either Additional Information or Exception Information. When present, each kindof further information is to be provided in a further subclause of items labelled A<i> or X<i> respectively forcross-referencing purposes, where <i> is any unambiguousidentification for the item (e.g. simply a number): there areno other restrictions on its format and presentation.A completed PICS proforma, including any Additional Information and Exception Information, is the Protocol Implementation Conformance Statement for the implementation in question.NOTE - Where an implementation is capable of being configured in more than one way, a single PICS may be able todescribe all such configurations. However, the supplier hasthe choice of providing more than one PICS, each coveringsome subset of the implementation's configuration capabilities, in case this makes for easier and clearer presentation ofthe information.A.3.2 Additional InformationItems of Additional Information allow a supplier to providefurther information intended to assist the interpretation ofthe PICS. It is not intended or expected that a large quantitywill be supplied, and a PICS can be considered completewithout any such information. Examples might be an outline of the ways in which a (single) implementation can beset up to operate in a variety of environments and configurations.References to items of Additional information may be entered next to any answer in the questionnaire, and may beincluded in items of Exception Information.A.3.3 Exception InformationIt may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after anyconditions have been applied) in a way that conflicts withthe indicated requirement. No pre-printed answer will befound in the Support column for this, but the Supplier maywrite the desired answer into the Support column. If this isdone, the supplier is required to provide an item of Exception Information containing the appropriate rationale, and across-reference from the inserted answer to the Exceptionitem.An implementation for which an Exception item is requiredin this way does not conform to ISO 10589.NOTE - A possible reason for the situation described aboveis that a defect report is being progressed, which is expectedto change the requirement that is not met by the implementation.A.3.4 Conditional StatusA.3.4.1 Conditional itemsThe PICS proforma contains a number of conditional items.These are items for which the status mandatory, optionalor prohibited that applies is dependent upon whether ornot certain other items are supported, or upon the valuessupported for other items. In many cases, whether or not theitem applies at all is conditional in this way, as well as thestatus when the item does apply.Individual conditional items are indicated by a conditionalsymbol in the Status column as described in A.3.4.2 below.Where a group of items are subject to the same conditionfor applicability, a separate preliminary question about thecondition appears at the head of the group, with an instruction to skip to a later point in the questionnaire if the NotApplicable answer is selected.A.3.4.2 Conditional symbols and conditionsA conditional symbol is of the form c.<n> or c.G<n> where<n> is a numeral. For the first form, the numeral identifiesa condition appearing in a list at the end of the subclausecontaining the item. For the second form, c.G<n>, the numeral identifies a condition appearing in the list of globalconditions 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) orthe 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 basicstatus symbols or .The status symbol applicable to an item governed by a simple condition is <s1> if the predicate of the condition istrue, and <s2> otherwise; the status symbol applicable to anitem 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 PredicatesA simple predicate in a condition is eithera)a single item reference; orb)a relation containing a comparison operator (=, <, etc.)with one (or both) of its operands being an item reference for an item taking numerical values as its answer.In case (a) the predicate is true if the item referred to ismarked as supported, and false otherwise. In case (b), thepredicate is true if the relation holds when each item reference is replaced by the value entered in the Support columnas answer to the item referred to.Compound predicates are boolean expressions constructedby combining simple predicates using the boolean operatorsAND, OR and NOT, and parentheses, in the usual way. Acompound predicate is true if and only if the boolean expression evaluates to true when the simple predicates are interpreted as described above.Items whose references are used in predicates are indicatedby an asterisk in the Item column.A.3.4.4 Answering conditional itemsTo answer a conditional item, the predicate(s) of the condition is (are) evaluated as described in A.3.4.3 above, andthe applicable status symbol is determined as described inA.3.4.2. If the status symbol is this indicates that theitem is to be marked in this case; otherwise, the Supportcolumn is to be completed in the usual way.When two or more basic status symbols appear in a condition for an item, the Support column for the item containsone line for each such symbol, labelled by the relevant symbol. the answer for the item is to be marked in the line labelled by the symbol selected according to the value of thecondition (unselected lines may be crossed out for addedclarity).For example, in the item illustrated below, the N/A columnwould be marked if neither predicate were true; the answerline labelled M: would be marked if item A4 was marked as supported,and the answer line labelled O: would be marked ifthe condition including items D1 and B52 applied.ItemReferencesStatusN/ASupportH3Is ... supported?42.3(d)C.1M: YesO: Yes NoC.1if A4 then Melse if D1 AND (B52 < 3) then O elseA.4 IdentificationA.4.1 Implementation IdentificationSupplierContact point forqueriesabout this PICSImplementation Name(s)and Version(s)OperatingsystemName(s and Version(s)Other Hardware and OperatingSystemsClaimedSystem Name(s)(if different)Notes:a)Only the first three items are required for all implementations; others may becompleted as appropriate in meeting the requirements for full identification.b)The terms Name and Version should be interpreted appropriately to correspondwith a supplier's terminology (using, e.g., Type, Series, Model)A.4.2 Protocol Summary: ISO 10589:19xxProtocol VersionAddendaImplemented(if applicable)AmmendmentsImplementedDate of StatementHaveany 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: ItemReferencesStatusN/ASupportAllISAre all basic ISIS routeing functionsimplemented?12.1.2MM: YesC.1if L2IS then O elseC.2if 8208 then O elsePartitionRepairIs Level 1 Partition Repair implemented?12.1.2.fC.1O: Yes NoL1ISAre Level 1 ISIS routeing functionsimplemented?12.1.3MM: YesL2ISAre Level 2 ISIS routeing functionsimplemented?12.1.4OO: Yes NoPtPtAre point-to-point circuits implemented?12.1.2.tO.1O: Yes No8208Are ISO 8208 circuits implemented?12.1.2.uO.1O: Yes NoLANAre broadcast circuits implemented?12.1.2.vO.1O: Yes NoEqualCostPathsIs computation of equal minimum costpaths implemented?7.2.6OO: Yes NoDownstreamIs computation of downstream routesimplemented?7.2.6OO: Yes NoDelayMetricIs path computation based on the delaymetric implemented?7.2.2OO: Yes NoExpenseMetricIs path computation based on the Expense metric implemented?7.2.2OO: Yes NoPrefixesAre Reachable Address Prefixes implemented?12.1.2.jC.1O: Yes NoForward
ingRateHow many ISO 8473 PDUs can the implementation forward per second?12.2.5.1.bM PDUs/secL2 ISCountHow many Level 2 ISs does the implementation support?12.2.5.1.C.1N =call
Estab
lish
ment
Met
ricIncrementAre non-zero values of the call
Estab
lish
ment
Met
ricIncrement supported?12.1.2.u.3C.2O: Yes NoL1 ISCountHow many Level 1 ISs does the implementation support?12.2.5.1.MN =ReversePathCacheIs the 8208 Reverse Path Cache supported?12.1.2.u.4C.2O: Yes NoErrorMetricIs path computation based on the Errormetric implemented?7.2.2OO: Yes NoISO 10589:19xxPICS Proforma: ItemReferencesStatusN/ASupportC.1if L2IS then O elseC.2if 8208 then O elseID fieldLengthWhat values of the routeingDomain
ID
Length are supported by this implementation?7.1.1MValues =Is the value Setable by SystemMan
agement?Yes NoPDU AuthenticationIs PDU Authentication based on Passwords implemented?12.1.2.zOO: Yes NoISO 10589:19xx (continued)Annex BSupporting Technical Material(This annex is informative)B.1 Matching of Address PrefixesThe following example shows how address prefixes may bematched according to the rules defined in 7.1.4.The prefix 37-123matches both the full NSAP addresses 37-1234::AF< and 37-123::AF<which are encoded as 3700000000001234AF< and 3700000000000123AF<respectively.This can be achieved by first converting the address to becompared to an internal decoded form (i.e. any padding, asindicated by the particular AFI, is removed), which corresponds to the external representation of the address. Theposition of the end of the IDP must be marked, since it canno longer be deduced. This is done by inserting the semi-octet F after the last semi-octet of the IDP. (There can beno confusion, since the abstract syntax of the IDP is decimal digits).Thus the examples above become in decoded form 371234FAF< and 37123FAF< and the prefix 37-123 matches as a leading sub-string ofboth of them.For comparison purposes the prefix is converted to the internal decoded form as above.B.2 Addressing and RouteingIn order to ensure the unambiguous identification of Network and Transport entities across the entire OSIE, someform of address administration is mandatory. ISO8348/Add.2 specifies a hierarchical structure for networkaddresses, with a number of top-level domains responsiblefor administering addresses on a world-wide basis. Theseaddress registration authorities in turn delegate to sub-authorities the task of administering portions of the addressspace. There is a natural tendency to repeat this sub-division to a relatively fine level of granularity in order toease the task of each sub-authority, and to assign responsibility for addresses to the most localised administrativebody feasible. This results in (at least in theory) reducedcosts of address administration and reduced danger of massive address duplication through administrative error. Furthermore, political factors come into play which require thecreation of sub-authorities in order to give competing interests the impression of hierarchical parity. For example atthe top level of the ISO geographic address space, everycountry is assigned an equally-sized portion of the addressspace even though some countries are small and might inpractice never want to undertake administration of theirown addresses. Other examples abound at lower levels ofthe hierarchy, where divisions of a corporation each wish tooperate as an independent address assignment authorityeven though this is inefficient operationally and may wastemonumental amounts of potential address space.If network topologies and traffic matrices aligned naturallywith the hierarchical organisation of address administrationauthorities, this profligate use of hierarchy would pose littleproblem, given the large size (20 octets) of the N-addressspace. Unfortunately, this is not usually the case, especiallyat higher levels of the hierarchy. Network topologies maycross address administration boundaries in many cases, forexample:-Multi-national Corporations with a backbone networkthat spans several countries-Community-of-interest networks, such as academic orresearch networks, which span organisations and geographies-Military networks, which follow treaty alignmentsrather than geographic or national administrations-Corporate networks where divisions at times operateas part of a contractor's network, such as with tradeconsortia or government procurements.These kinds of networks also exhibit rich internal topologies and large scale (105 systems), which require sophisticated routeing technology such as that provided by this International Standard. In order to deploy such networks effectively, a considerable amount of address space must beleft over for assignment in a way which produces efficientroutes without undue consumption of memory andbandwidth for routeing overhead11This is just a fancy way of sayingthat hierarchical routing, with its natural effect on addressassignment, is a mandatory requirement for such networks..Similarly important is the inter-connection of these networks via Inter-domain routeing technology. If all of the assignment flexibility of the addressing scheme is exhaustedin purely administrative hierarchy (at the high-order end ofthe address) and in Intra-Domain routeing assignment (atthe low end of the address) there may be little or no addressspace left to customise to the needs of inter-domain routing.The considerations for how addresses may be structured forthe Intra- and Inter-domain cases are discussed in more detail in the following two clauses.B.2.1 Address Structure for Intra-domainRouteingThe IS-IS Intra-domain routeing protocol uses a preferredaddressing scheme. There are a number of reasons the designers of this protocol chose to specify a single addressstructure, rather than leaving the matter entirely open to theaddress assignment authorities and the routeing domain administrators:a)If one address structure is very common and known apriori, the forwarding functions can be made muchfaster;b)If part of the address is known to be assigned locallyto an end system, then the routeing can be simpler, useless memory, and be potentially faster, by not havingto discriminate based on that portion of the address.c)If part of the address can be designated as globallyunique by itself (as opposed to only the entire addresshaving this property) a number of benefits accrue:1)Errors in address administration causing duplicateaddresses become much less likely2)Automatic and dynamic NSAP address assignmentbecomes feasible without global knowledge orsynchronisation3)Routeing on this part of the address can be madesimple and fast, since no address collisions will occur in the forwarding database.d)If a part of the address can be reserved for assignmentpurely on the basis of topological efficiency (as opposed to political or address administration ease), hierarchical routeing becomes much more memory andbandwidth efficient, since the addresses and the topology are in close correspondence.e)If an upper bound can be placed on the amount of address space consumed by the Intra-domain routeingscheme, then the use of address space by Inter-domainrouteing can be made correspondingly more flexible.The preferred address format of the Intra-domain ISISprotocol achieves these goals by being structured into twofixed-sized fields as follows shown in figure 91#ID#81Used by level 1routeingKey:Used by level 2 routeingIDSELHO-DSPIDPIDP Initial Domain PartHO-DSP High Order Domain Specific PartID System IdentifierSEL NSAP SelectorFigure 9 - Preferred Address Format below:The field marked IDP in the figure is precisely the IDPspecified in ISO 8348/Add.2. The field marked HO-DSPis that portion of the DSP from ISO 8348/Add.2 whosestructure, assignment, and meaning are not specified orconstrained by the Intra-domain ISIS routeing protocol.However, the design presumes that the routeing domain administrator has at least some flexibility in assigning a portion of the HO-DSP field. The purpose and usage of thefields specified by the Intra-domain ISIS routeing protocolis explained in the following paragraphs.B.2.1.1 The IDP + HO-DSPSince the Intra-domain ISIS protocol is customised for operation with ISO 8473, all addresses are specified to use thepreferred binary encoding of ISO 8348/Add.2.B.2.1.2 The Selector (SEL) FieldThe SEL field is intended for two purposes. Its main use isto allow for multiple higher-layer entities in End systems(such as multiple transport entities) for those systems whichneed this capability. This allows up to 256 NSAPs in a single End system. The advantage of reserving this field exclusively for local system administration the Intra-domainrouting functions need not store routeing information about,nor even look at this field. If each individual NSAP wererepresented explicitly in routing tables, the size of these tables would grow with the number of NSAPs, rather thanwith the number of End systems. Since Intra-domain routing routes to systems, explicit recording of each NSAPbrings no efficiency benefit and potentially consumes largeamounts of memory in the Intermediate systems.A second use for the SEL field is in Intermediate systems.Certain ISIS functions require that PDUs be encapsulatedand sent to the Network Entity in an Intermediate systemrather than to an NSAP and upward to a Transport entity.An example of this is the Partition Repair function of thisInternational Standard. In order to use a level 2 path as if itwere a single subnetwork in a level 1 area, PDUs are encapsulated and addressed to an IS on the other side of the partition11This is a gross oversimplification for the purpose ofillustrating the need for the SEL field. See 7.2.10.. By reserving certain values of the SEL field in Intermediate systems for direct addressing of Intermediate system Network entities, the normal addressing and relayingfunctions of other Intermediate systems can be transparently used for such purposes.B.2.1.3 The Identifier (ID) FieldThe ID field is a flat, large identifier space for identifyingOSI systems. The purpose of this field is to allow very fast,simple routeing to a large (but not unconstrained) numberof End systems in a routeing domain. The Intra-Domain ISIS protocol uses this field for routeing within a area. Whilethis field is only required to be unambiguous within a singlearea, if the values are chosen to be globally unambiguousthe Intra-domain ISIS design can exploit this fact in thefollowing ways.First, a certain amount of parallelism can be obtained during relaying. An IS can be simultaneously processing the IDfield along with other fields (i.e. IDP, HO-DSP). If the IDis found in the forwarding table, the IS can initiate forwarding while checking to make sure that the other fields havethe expected value. Conversely, if the ID is not found theIS can assume that either the addressed NSAP is unreachable or exists only in some other area or routeing domain.In the case where the ID is not globally unique, the forwarding table can indicate this fact and relaying delayeduntil the entire address is analysed and the route looked up.Second, a considerable savings can be obtained in manualaddress administration for all systems in the routeing domain. If the ID is chosen from the ISO 8802 48-bit addressspace, the ID is known to be globally unique. Furthermore,since LAN systems conforming to ISO 8802 often havetheir 48-bit MAC address stored in ROM locally, each system can be guaranteed to have a globally unambiguousNET and NSAP(s) without centralised address administration at the area level.22Note, however, that the use of the ISO 8802addresses does not avoid the necessity to run ISO 9542 or to maintaintables mapping NSAP addresses toMAC (i.e. SNPA) addresses on the ISO 8802 subnetwork. This is becausethere is no guarantee that a particular MAC address is always enabled (the LANcontroller may be turned off) or that a system has only a single MAC address. This not only eliminates administrative overhead, but also drastically reduces the possibility ofduplicate NSAP addresses, which are illegal, difficult to diagnose, and often extremely difficult to isolate.An alternative to a large, flat space for the lowest level ofrouteing would be to hierarchically subdivide this field toallow more levels of routeing within a single routeing domain. The designers of the Intra-domain ISIS protocolconsidered that this would lead to an inferior routeing architecture, since:a)The cost of memory in the ISs was sufficiently reasonable that large (e.g. 104 system) areas were quite feasible, thus requiring at least 2 octets per level to addressb)Two levels of routeing within a routeing domain weresufficient (allowing domains of 106107 systems) because it was unlikely that a single organisation wouldwish to operate and manage a routeing domain muchlarger than that.c)Administrative boundaries often become the dominantconcern once routeing domains reach a certain size.d)The additional burdens and potential for error in manual address assignment were deemed serious enoughto permit the use of a large, flat space.B.3 Use of the HO-DSP field inIntra-domain routeingUse of a portion of the HO-DSP field provides for hierarchical routeing within a routeing domain. A value is assigned to a set of ISs in order to group the ISs into a singlearea for the usual benefits of hierarchical routeing:a)Limiting the size of routeing tables in the ISs;b)conserving bandwidth by hierarchical summarisationof routeing information;c)designating portions of the network which are to haveoptimal routeing within themselves; andd)moderate firewalling of portions of the routeing domain from failures in other portions.It is important to note that the assignment of HO-DSP values is intended to provide the routeing domain administrator with a mechanism to optimise the routeing within alarge routeing domain. The Intra-domain ISIS designersdid not intend the HO-DSP to be entirely consumed bymany levels of address registration authority. Reserving theassignment of a portion of the HO-DSP field to the routeing domain administrator also allows the administrator tostart with a single assigned IDP+HO-DSP and run therouting domain as a single area. As the routeing domaingrows, the routeing domain administrator can then add areas without the need to go back to the address administration authority for further assignments. Areas can be addedand re-assigned within the routeing domain without involving the external address administration authority.A useful field to reserve as part of the HO-DSP would be 2octets,permitting up to 65,536 areas in a routeing domain.This is viewed as a reasonable compromise between routeing domain size and address space consumption. The fieldmay be specified as flat for the same reasons that the IDfield may be flat.B.3.1 Addressing considerations forInter-domain RouteingIt is in the Inter-domain arena where the goals of routeingefficiency and administrative independence collide moststrongly. Although the OSI Routeing Framework explicitlygives priority in Inter-domain routeing to considerations ofautonomy and firewalls over efficiency, it must be feasibleto construct an Inter-Domain topology that both producesisolable domains and relays data at acceptable cost. Sinceno routeing information is exchanged across domainboundaries with static routeing, the practicality of a givenInter-domain topology is essentially determined by the sizeof the routeing tables that are present at the boundary ISs. Ifthese tables become too large, the memory needed to storethem, the processing needed to search them, and thebandwidth needed to transmit them within the routeing domain all combine to disallow certain forms ofinterconnection.Inter-domain routeing primarily computes routes to otherrouteing domains33This International Standard also uses staticInter-domain tables for routeing to individual End systems acrossdynamically assigned circuits, and also toEnd systems whose addresses do not conform to the address construction rules.. If there is no correspondence betweenthe address registration hierarchy and the organisation ofrouteing domains (and their interconnection) then the taskof static table maintenance quickly becomes a nightmare,since each and every routeing domain in the OSIE wouldneed a table entry potentially at every boundary IS of everyother routeing domain. Luckily, there is some reason to believe that a natural correspondence exists, since at least atthe global level the address registration authorities fallwithin certain topological regions. For example, most of therouteing domains which obtained their IDP+HO-DSPfrom a hierarchy of French authorities are likely to reside inFrance and be more strongly connected with other routeingdomains in France that with routeing domains in othercountries.There are enough exceptions to this rule, however, to be acause for concern. The scenarios cited in B.2 all exist todayand may be expected to remain common for the foreseeablefuture. Consider as a practical case the High Energy Physics Network (HEPnet), which contains some 17000 Endsystems, and an unknown number of intermediate systems44The number ofISs is hard to estimate since some ISs and links are in fact sharedwith other networks, such as the similarly organised NASA SpacePhysics network, or SPAN..This network operates as a single routeing domain in orderto provide a known set of services to a known communityof users, and is funded and cost-justified on this basis. Thisnetwork is international in scope (at least 10 countries inNorth America, Europe, and the far east) and yet its topology does not map well onto existing national boundaries.Connectivity is richer between CERN and FERMIlab, forexample than between many points within the U.S.More importantly, this network has rich connectivity with anumber of other networks, including the PDNs of the various countries, the NSFnet in the U.S., the internationalESnet (Energy Sciences Network), the general researchInternet, and military networks in the U.S. and elsewhere.None of these other networks shares a logical part of theNSAP address hierarchy with HEPnet55It is conceivable that ISO wouldsanction such networks by assigning a top-level IDI from the ISOnon-geographic AFI, but this is unlikely and wouldonly exacerbate the problem if many such networks were assignedtop-level registrations. . If the only methodof routing from the HEPnet to these other networks was toplace each within one and only one of the existing registration authorities, and to build static tables showing these relationships, the tables would clearly grow as O(n2).It seems therefore, that some means must be available to assign addresses in a way that captures the Inter-Domain topology, and which co-exists cleanly with both the administrative needs of the registration authorities, and the algorithms employed by both the Intra- and Inter-domainrouteing protocols. As alluded to in an earlier clause, itseems prudent to leave some portion of the address space(most likely from the HO-DSP part) sufficiently undefinedand flexible that various Inter-domain topologies may beefficiently constructed.Annex CImplementation Guidelines and Examples(This annex is informative)C.1 Routeing DatabasesEach database contains records as defined in the followingsub-clauses. The following datatypes are defined.FROM CommonMgmt IMPORT NSAPAddress,AddressPrefix, BinaryAbsoluteTime;PDU TypelspID = ARRAY [0..7] OF Octet;systemID = ARRAY [0..5] OF Octet;octetTimeStamp = BinaryAbsoluteTime;C.1.1 Level 1 Link State DatabaseThis database is kept by Level 1 and Level 2 IntermediateSystems, and consists of the latest Level 1 Link State PDUsfrom each Intermediate System (or pseudonode) in the area.The Level 1 Link State PDU lists Level 1 links to the Intermediate System that originally generated the Link StatePDU.RECORDadr: lspID; (* 8 octet ID of LSP originator*)type: (Level1IntermediateSystem,AttachedLevel2IntermediateSystem,UnattachedLevel2IntermediateSystem);seqnum: [0..SequenceModulus 1];LSPage: [0..MaxAge]; (*Remaining Lifetime *)expirationTime: TimeStamp;(*Time at which LSP agebecame zero (see 7.3.16.4). *)SRMflags: ARRAY[1..(maximumCircuits +maximumVirtualAdjacencies)]OF BOOLEAN;(*Indicates this LSP to be sent on this circuit. Notethat level 2 Intermediate systems may send level 1LSPs to other partitions (if any exist). Only one level2 Intermediate system per partition does this. Forlevel 1 Intermediate Systems the array is justmaximumCircuits long. *)SSNflags: ARRAY[1..maximumCircuits +maximumVirtualAdjacencies]OF BOOLEAN;(*Indicates that information about this LSP shall beincluded in the next partial sequence number PDUtransmitted on this circuit. *)POINTER TO LSP; (*The received LSP *)END;C.1.2 Level 2 Link State DatabaseThis database is kept by Level 2 Intermediate Systems, andconsists of the latest Level 2 Link State PDUs from eachLevel 2 Intermediate System (or pseudonode) in the domain. The Level 2 Link State PDU lists Level 2 links to theIntermediate System that originally generated the LinkState PDU.RECORDadr: lspID; (* 8 octet ID of LSP originator *)type: (AttachedLevel2IntermediateSystem,UnattachedLevel2IntermediateSystem);seqnum: [0..SequenceModulus 1];LSPage: [0..MaxAge]; (*Remaining Lifetime *)expirationTime: TimeStamp;(*Time at which LSP agebecame zero (see 7.3.16.4). *)SRMflags: ARRAY[1..(maximumCircuits)] OFBOOLEAN;(*Indicates this LSP to be sent on this circuit. *)SSNflags: ARRAY[1..maximumCircuits] OFBOOLEAN;(*Indicates that information about this LSP must beincluded in the next partial sequence number PDUtransmitted on this circuit. *)POINTER TO LSP; (*The received LSP *)END;C.1.3 Adjacency Database This database is kept by all systems. Its purpose is to keeptrack of neighbours.For Intermediate systems, the adjacency database comprisesa database with an entry for each:-Adjacency on a Point to Point circuit.-Broadcast Intermediate System Adjacency. (Note thatboth a Level 1 and a Level 2 adjacency can exist between the same pair of systems.)-Broadcast End system Adjacency.-potential SVC on a DED circuit (max
i
mum
SVC
Adja
cencies for a DA circuit, or 1 for a Static circuit).-Virtual Link Adjacency.Each entry contains the parameters in Clause 11 for the Adjacency managed object. It also contains the variable usedto store the remaining holding time for each AdjacencyIDEntry and NETEntry entry, as defined below.IDEntry = RECORDID: systemID;(* The 6 octet System ID of a neighbour End systemextracted from the SOURCE ADDRESS field of itsESH PDUs. *)entryRemainingTime: Unsigned [1..65535](* The remaining holding time in seconds for thisentry. This value is not accessible to systemmanagement. An implementation may choose toimplement the timer rules without an explicitremainingTime being maintained. For example bythe use of asynchronous timers. It is present here inorder to permit a consistent description of the timerrules. *)ENDNETEntry = RECORDNET: NetworkEntityTitle;(* The NET of a neighbour Intermediate systemas reported in its IIH PDUs. *)entryRemainingTime: Unsigned [1..65535] (* The remaining holding time in seconds for thisentry. This value is not accessible to systemmanagement. An implementation may choose toimplement the timer rules without an explicitremainingTime being maintained. For example bythe use of asynchronous timers. It is present here inorder to permit a consistent description of the timerrules. *)END;C.1.4 Circuit DatabaseThis database is kept by all systems. Its purpose is to keepinformation about a circuit. It comprises an ARRAY[1..maximumCircuits].Each entry contains the parameters in Clause 11 for a Circuit managed object (see 11.3). It also contains the remainingHelloTime (WordUnsigned [1..65535] seconds) variable for the Circuit. This variable not accessible to systemmanagement. An implementation may choose to implementthe timer rules without an explicit remainingHelloTimebeing maintained. For example by the use of asynchronoustimers. It is present here in order to permit a consistent description of the timer rules. Additionally, for Circuits oftype X.25 Static Outgoing or X.25 DA, it contains therecallCount (Unsigned[0..255]) variable for the Circuit.This variable is not accessible to system management. Itused to keep track of recall attempts.C.1.5 Level 1 Shortest Paths DatabaseThis database is kept by Level 1 and Level 2 IntermediateSystems (unless each circuit is Level 2 Only). It is computed by the Level 1 Decision Process, using the Level 1Link State Database. The Level 1 Forwarding Database is asubset of this database.RECORDadr: systemId; (*6 octet ID of destination system *)cost: [1..MaxPathMetric];(*Cost of best path to destination system *)adjacencies: ARRAY[1..max
i
mum
Path
Splits]OF POINTER TO Adjacency;(*Pointer to adjacency for forwarding to system adr*)END;C.1.6 Level 2 Shortest Paths DatabaseThis database is kept by Level 2 Intermediate Systems. It iscomputed by the Level 2 Decision Process, using theLevel 2 Link State Database. The Level 2 Forwarding Database is a subset of this database.RECORDadr: AddressPrefix; (*destination prefix *)cost: [1..MaxPathMetric];(*Cost of best path to destination prefix *)adjacencies: ARRAY[1..max
i
mum
Path
Splits]OF POINTER TO Adjacency;(*Pointer to adjacency for forwarding to prefix adr*)END;C.1.7 Level 1 Forwarding DatabaseThis database is kept by Level 1 and Level 2 IntermediateSystems (unless each circuit is Level 2 Only). It is usedto determine where to forward a data NPDU with destination within this system's area. It is also used to determinehow to reach a Level 2 Intermediate System within the area,for data PDUs with destinations outside this system's area.RECORDadr:systemId;(*6 octet ID of destination system. Destination0 is special, meaningnearest level 2Intermediate system *)splits: [0..max
i
mum
Path
Splits];(* Number of valid output adj's for reachingadr(0 indicates it is unreachable) *) nextHop: ARRAY[1..max
i
mum
Path
Splits] OFPOINTER TO adjacency;(*Pointer to adjacency for forwarding to destinationsystem *)END;C.1.8 Level 2 Forwarding DatabaseThis database is kept by Level 2 Intermediate systems. It isused to determine where to forward a data NPDU with destination outside this system's area.RECORDadr: AddressPrefix; (*address of destination area.*)splits: [0..max
i
mum
Path
Splits];(*Number of valid output adj's for reaching adr(0 indicates it is unreachable) *)nextHop: ARRAY[1..max
i
mum
Path
Splits] OFPOINTER TO adjacency;(*Pointer to adjacency for forwarding to destinationarea. *)END;C.2 SPF Algorithm for ComputingEqual Cost PathsAn algorithm invented by Dijkstra (see references) knownas shortest path first (SPF), is used as the basis for theroute calculation. It has a computational complexity of thesquare of the number of nodes, which can be decreased tothe number of links in the domain times the log of the number of nodes for sparse networks (networks which are nothighly connected).A number of additional optimisations are possible:a)If the routeing metric is defined over a small finitefield (as in this International Standard), the factor oflog n may be removed by using data structures whichmaintain a separate list of systems for each value ofthe metric rather than sorting the systems by logicaldistance.b)Updates can be performed incrementally without requiring a complete recalculation. However, a full update must be done periodically to recover from datacorruption, and studies suggest that with a very smallnumber of link changes (perhaps 2) the expected computation complexity of the incremental update exceedsthe complete recalculation. Thus, this InternationalStandard specifies the algorithm only for the full update.c)If only End system LSP information has changed, it isnot necessary to re-compute the entire Dijkstra tree forthe IS. If the proper data structures exist, End Systemsmay be attached and detached as leaves of the tree andtheir forwarding information base entries altered asappropriateThe original SPF algorithm does not support load splittingover multiple paths. The algorithm in this InternationalStandard does permit load splitting by identifying a set ofequal cost paths to each destination rather than a singleleast cost path.C.2.1 DatabasesPATHS This represents an a
cyclic directed graph ofshortest paths from the system S performing the calculation. It is stored as a set of triples of the formaN,d(N),{Adj(N)}q, where: N is a system Identifier. In the level 1 algorithm, N isa 7 octet ID. For a non-pseudonode it is the 6 octetsystem ID, with a 0 appended octet. For apseudonode it is a true 7 octet quantity, comprised ofthe 6 octet Designated Intermediate System ID andthe extra octet assigned by the Designated Intermediate System. In the level 2 algorithm it is either a7 octet Intermediate System or pseudonode ID (as inthe level 1 algorithm), or it is a variable length address prefix (which will always be a leaf, i.e. Endsystem, in PATHS). d(N) is N's distance from S (i.e. the total metricvalue from N to S).{Adj(N)} is a set of valid adjacencies that S may usefor forwarding to N. When a system is placed on PATHS, the path(s)designated by its position in the graph is guaranteedto be a shortest path.TENT This is a list of triples of the formaN,d(N),{Adj(N)}q, where N, d(N) and {Adj(N)} areas defined above for PATHS. TENT can intuitively be thought of as a tentativeplacement of a system in PATHS. In other words,the triple aN,x,{A}q in TENT means that if N wereplaced in PATHS, d(N) would be x, but N cannot beplaced on PATHS until it is guaranteed that no pathshorter than x exists. The triple aN,x,{A,B}q in TENT means that if Nwere placed in PATHS, d(N) would be x via eitheradjacency A or BNOTE - As described above, (see 7.2.6), it is suggested thatthe implementation keep the database TENT as a set of listsof triples of the form a*,Dist,*q, for each possible distanceDist. In addition it is necessary to be able to process thosesystems which are pseudonodes before any non-pseudonodes at the same distance Dist.C.2.2 Use of Metrics in the SPF CalculationInternal metrics are not comparable to external metrics.Therefore, the cost of the path from N to S for externalroutes (routes to destinations outside of the routing domain)may include both internal and external metrics. The cost ofthe path from N to S (called d(N) below in databasePATHS) may therefore be maintained as a two-dimensioned vector quantity (specifying internal and external metric values). In incrementing d(N) by 1, if the internalmetric value is less than the maximum valueMaxPathMetric, then the internal metric value is incremented by one and the external metric value left unchanged; if the internal metric value is equal to the maximum value MaxPathMetric, then the internal metric valueis set to 0 and the external metric value is incremented by 1.Note that this can be implemented in a straightforwardmanner by maintaining the external metric as the high orderbits of the distance.NOTE - In the code of the algorithm below, the current pathlength is held in a variable tentlength. This variable is atwo-dimensional quantity tentlength=(internal,external)and is used for comparing the current path length with d(N)as described above.C.2.3 Overview of the AlgorithmThe basic algorithm, which builds PATHS from scratch,starts out by putting the system doing the computation onPATHS (no shorter path to SELF can possibly exist).TENT is then pre-loaded from the local adjacency database.Note that a system is not placed in PATHS unless noshorter path to that system exists. When a system N isplaced in PATHS, the path to each neighbour M of N,through N, is examined, as the path to N plus the link fromN to M. If aM,*,*q is in PATHS, this new path will belonger, and thus ignored.If aM,*,*q is in TENT, and the new path is shorter, the oldentry is removed from TENT and the new path is placed inTENT. If the new path is the same length as the one inTENT, then the set of potential adjacencies {adj(M)} is setto the union of the old set (in TENT) and the new set{adj(N)}. If M is not in TENT, then the path is added toTENT.Next the algorithm finds the triple aN,x,{Adj(N)}q inTENT, with minimal x.NOTE - This is done efficiently because of the optimisationdescribed above. When the list of triples for distance Dist isexhausted, the algorithm then increments Dist until it finds alist with a triple of the form a*,Dist,*q.N is placed in PATHS. We know that no path to N can beshorter than x at this point because all paths through systems already in PATHS have already been considered, andpaths through systems in TENT will have to be greater thanx because x is minimal in TENT.When TENT is empty, PATHS is complete.C.2.4 The AlgorithmThe Decison Process Algorithm must be run once for eachsupported routeing metric. A Level 1 Intermediate Systemruns the algorithm using the Level 1 LSP database to compute Level 1 paths. In addition a Level 2 Intermediate System runs the algorithm using the Level 2 LSP database tocompute Level 2 paths.If this system is a Level 2 Intermediate System which supports the partition repair optional function the DecisionProcess algorithm for computing Level 1 paths must be runtwice for the default metric. The first execution is done todetermine which of the area's manual
Area
Addressesare reachable in this partition, and elect a Partition Designated Level 2 Intermediate System for the partition. ThePartition Designated Level 2 Intermediate System will determine if the area is partitioned and will create virtualLevel 1 links to the other Partition Designated Level 2 Intermediate Systems in the area in order to repair the Level 1partition. This is further described in 7.2.10.Step 0: Initialise TENT and PATHS to empty. Initialisetentlength to (0,0).(tentlength is the pathlength of elements in TENTwe are examining.)a)Add aSELF, 0, Wq to PATHS, where W is a specialvalue indicating traffic to SELF is passed up to Transport (rather than forwarded).b)Now pre-load TENT with the local adjacency database. (Each entry made to TENT must be marked asbeing either an End system or an Intermediate Systemto enable the check at the end of Step 2 to be madecorrectly.) For each adjacency Adj(N), (includingManual Adjacencies, or for Level 2 enabled Reachable Addresses) on enabled circuits, to system N ofSELF in state Up, computed(N) = cost of the parent circuit of the adjacency(N), obtained from metrick, where k = one of default metric, delay metric, monetary metric, error metric.Adj(N) = the adjacency number of the adjacencyto Nc)If a triple aN,x,{Adj(M)}q is in TENT, then:If x = d(N), then Adj(M) , {Adj(M)} H Adj(N).d)If there are now more adjacencies in {Adj(M)} thanmax
i
mum
Path
Splits, then remove excess adjacencies as described in 7.2.7.e)If x < d(N), do nothing.f)If x > d(N), remove aN,x,{Adj(M)}q from TENT andadd the triple aN,d(N),Adj(N)q.g)If no triple aN, x,{Adj(M)}q is in TENT, then add aN,d(N),Adj(N)q to TENT.h)Now add any systems to which the local Intermediatesystem does not have adjacencies, but which are mentioned in neighbouring pseudonode LSPs. The adjacency for such systems is set to that of the DesignatedIntermediate System.i)For all broadcast circuits in state On, find the LSPwith LSP number zero and with the first 7 octets ofLSPID equal to the LnCircuitID for that circuit (i.e.pseudonode LSP for that circuit). If it is present, forall the neighbours N reported in all the LSPs of thispseudonode which do not exist in TENT add an entryaN,d(N),Adj(N)q to TENT, whered(N) = metrick of the circuit.Adj(N) = the adjacency number of the adjacency to theDR.j)Go to Step 2.Step 1: Examine the zeroth Link State PDU of P, the system just placed on PATHS (i.e. the Link State PDU withthe same first 7 octets of LSPID as P, and LSP numberzero).a)If this LSP is present, and the LSP Database Overload bit is clear, then for each LSP of P (i.e. all theLink State PDUs with the same first 7 octets of LSPIDas P, irrespective of the value of LSP number) computedist(P,N) = d(P) + metrick(P,N).for each neighbour N (both Intermediate System andEnd system) of the system P. If the LSP DatabaseOverload bit is set, only consider the End systemneighbours of the system P. d(P) is the second element of the tripleaP,d(P),{Adj(P)qand metrick(P,N) is the cost of the link from P to N asreported in P's Link State PDUb)If dist(P,N) > MaxPathMetric, then do nothing.c)If aN,d(N),{Adj(N)}q is in PATHS, then do nothing.NOTE d(N) must be less than dist(P,N), or else Nwould not have been put into PATHS. An additional sanity check may be done here to ensure d(N) is in fact lessthan dist(P,N).d)If a triple aN,x,{Adj(N)}q is in TENT, then:1)If x = dist(P,N), then Adj(N) , {Adj(N)} HAdj(P).2)If there are now more adjacencies in {Adj(N)} thanmax
i
mum
Path
Splits, then remove excess adjacencies, as described in 7.2.7.3)If x < dist(P,N), do nothing.4)If x > dist(P,N), remove aN,x,{Adj(N)}q fromTENT and add aN,dist(P,N),{Adj(P)}q.e)If no triple aN, x,{Adj(N)}q is in TENT, then add aN,dist(P,N),{P}q to TENT.Step 2: If TENT is empty, stop, else:a)Find the element aP,x,{Adj(P)}q, with minimal x asfollows:1)If an element a*,tentlength,*q remains in TENTin the list for tentlength, choose that element. Ifthere are more than one elements in the list fortentlength, choose one of the elements (if any)for a system which is a pseudonode in preferenceto one for a non-pseudonode. If there are no moreelements in the list for tentlength increment tentlength and repeat Step 2.2)Remove aP,tentlength,{Adj(P)}q from TENT.3)Add aP,d(P),{Adj(P)}q to PATHS.4)If this is the Level 2 Decision Process running, andthe system just added to PATHS listed itself asPartition Designated Level 2 Intermediate system,then additionally add aAREA.P, d(P), {adj(P)}q toPATHS, where AREA.P is the Network EntityTitle of the other end of the Virtual Link, obtainedby taking the first AREA listed in P's Level 2 LSPand appending P's ID.5)If the system just added to PATHS was an Endsystem, go to Step 2, Else go to Step 1.NOTE - In the Level 2 context, the End systems are theset of Reachable Address Prefixes and the set of area addresses with zero cost.C.3 Forwarding ProcessC.3.1 Example pseudo-code for the forwardingprocedure described in 7.4.3This procedure chooses, from the Level 1 forwarding database if level is level1, or from the Level 2 forwardingdatabase if level is level2, an adjacency on which to forward PDUs for destination dest. A pointer to the adjacencyis returned in adj, and the procedure returns the valueTrue. If no suitable adjacency exists the procedure returnsthe value False, in which case a call should be made toDrop(Destination Address Unreachable, octetNumber).If queue length values are available to the forwarding process, the minimal queue length of all candidate circuits ischosen, otherwise, they are used in round robin fashion.PROCEDURE Forward(level: (level1, level2),dest: NetworkLayerAddress,VAR adj: POINTER TO adjacency) :BOOLEANVARadjArray: ARRAY OFForwardingDatabaseRecords;temp, index, minQueue: CARDINAL;BEGIN(*Set adjArray to appropriate database} *)IF level = level1 THENadjArray := level1ForwardingDatabaseELSEadjArray := level2ForwardingDatabaseEND; (*Perform appropriate hashing function to obtain anindex into the database *) IF Hash(level, dest, index) THENIF adjArray[index].splits > 0 THEN(*Find minimum queue size for all equal costpaths *)minQueue := MaxUnsigned;temp := adjArray[index].lastChosen + 1;(*start off after last time *)FOR i := 1 TO adjArray[index].splits DO(*for all equal cost paths to dest *)IF temp > adjArray[index].splits THEN(*after end of valid entries, wrap to first*)temp := 1ELSEtemp := temp + 1END;IFQueueSize(adjArray[index].nextHop[temp])< minQueue THENminQueue :=QueueSize(adjArray[index].nextHop[temp]);adj := adjArray[index].nextHop[temp];adjArray[index].lastChosen := temp;END;Forward := trueEND;ELSEForward := false (*There must be at least onevalid output adjacency *)ENDELSEForward := false (*Hash returned destinationunknown *)ENDEND forward;Annex DCongestion Control and Avoidance(This annex is informative)D.1 Congestion ControlThe transmit management subroutine handles congestioncontrol. Transmit management consists of the followingcomponents:Square root limiter. Reduces buffer occupancytime per PDU by using a square root limiter algorithm. The square root limiter also queues PDUs foran output circuit, and prevents buffer deadlock bydiscarding PDUs when the buffer pool is exhausted.Clause D.1.1 specifies the Square Root LimiterProcess.Originating PDU limiter. Limits originating NPDUtraffic when necessary to ensure that transit NPDUsare not rejected. An originating NPDU is an NPDUresulting from an NSDU from the Transport at thisES. A transit NPDU is an NPDU from another system to be relayed to another destination ES.Flusher. Flushes PDUs queued for an adjacency thathas gone down.Information for higher layer (Transport) congestion controlprocedures is provided by the setting of the congestion experienced bit in the forwarded data NPDUs.D.1.1 Square Root LimiterThe square root limiter discards a data NPDU by calling theISO 8473 discard PDU function with the reason PDUDiscarded due to Congestion when the number of dataNPDUs on the circuit output queue exceeds the discardthreshold, Ud. Ud is given as follows:=where:Nb = Number of Routeing Layer buffers(maximumBuffers) for all output circuits.Nc = Number of active output circuits (i.e. Circuits in stateOn).The output queue is a queue of buffers containing dataNPDUs which have been output to that circuit by the forwarding process, and which have not yet been transmittedby the circuit. It does not include NPDUs which are heldby the data link layer for the purpose of retransmission.Where a data NPDU is to be fragmented by this Intermediate system over this circuit, each fragment shall occupy aseparate buffer and shall be counted as such in the queuelength. If the addition of all the buffers required for thefragmentation of a single input data NPDU would cause thediscard threshold for that queue to be exceeded, it is recommended that all those fragments (including those whichcould be added without causing the threshold to be exceeded) be discarded.D.1.2 Originating PDU LimiterTEMPORARY NOTE - Strictly this function is an End System function. However it is closely coupled to the routeingfunction, particularly in the case of real systems which areperforming the functions of both an Intermediate Systemand an End System (i.e. systems which can both initiate andterminate data NPDUs and perform relaying functions).Therefore, until a more appropriate location for this information can be determined, this function is described here.The originating PDU limiter first distinguishes betweenoriginating NPDUs and transit NPDUs. It then imposes alimit on the number of buffers that originating NPDUs canoccupy on a per circuit basis. In times of heavy load, originating NPDUs may be rejected while transit NPDUs continue to be routed. This is done because originating NPDUshave a relatively short wait, whereas transit NPDUs, if rejected, have a long wait a transport retransmission period.The originating PDU limiter accepts as input:-An NSDU received from Transport Layer-A transmit complete signal from the circuit for an ISO8473 Data PDU.The originating PDU limiter produces the following as output:-PDU accepted-PDU rejected-Modifications to originating PDU counterThere is a counter, N, and an originating PDU limit,originatingQueueLimit, for each active output circuit.Each N is initialised to 0. The originatingQueueLimit isset by management to the number of buffers necessary toprevent the circuit from idling.D.1.3 FlusherThe flusher ensures that no NPDU is queued on a circuitwhose state is not ON, or on a non-existent adjacency, orone whose state is not Up.D.2 Congestion AvoidanceD.2.1 Buffer ManagementThe Forwarding Process supplies and manages the buffersnecessary for relaying. PDUs shall be discarded if bufferthresholds are exceeded. If the average queue length on theinput circuit or the forwarding processor or the output circuit exceeds QueueThreshold, the congestion experienced bit shall be set in the QoS maintenance option of theforwarded data PDU (provided the QoS maintenance optionis present).Security Considerations Security issues are not discussed in this memo.Author's Address David R. Oran Digital Equipment Corporation LKG 1-2/a 19 550 King Street Littleton, MA 01460 Email: Oran@Oran.enet.dec.com Phone: (508) 4866-7377
[8]ページ先頭