Domain Figure 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 Address 	address of one area within a routeing domain  a variable length quantity consisting of the entire high-order part of the NPAI, excluding the ID and SEL fields, defined below. ID	System identifier  a variable length field from 1 to 8 octets (inclusive). Each routeing domain employing this protocol shall select a single size for the ID field and all Intermediate systems in the routeing domain shall use this length for the system IDs of all systems in the routeing domain. 	The set of ID lengths supported by an implementation is an implementation choice, provided that at least one value in the permitted range can be accepted. The routeing domain administrator must ensure that all ISs included in a routeing domain are able 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(this may be a Transport entity or the Intermediate system Network entity itself). It is the least significant (last) octet of the NPAI.7.1.2 Deployment of Systems For correct operation of the routeing protocol defined in this international standard, systems deployed in a routeing domain 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 an area can use the same ID value. 2)Each area address must be unique within the global OSIE: that is, a given area address can be associated with only one area. 3)All systems having a given value of area address must 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 ID field: 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 if its 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 that these requirements are met, but has no means to verify compliance with them.7.1.3 Manual area addresses The use of several synonymous area addresses by an IS is accommodated through the use of the management parameter manualAreaAddresses. This parameter is set locally for each level 1 IS by system management; it contains a list of 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 in its Level 1 LSP's Area Addresses field, thus allowing level 2 ISs to create a composite list of all area addresses supported within a given area. Level 2 ISs in turn advertise the 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 for establishing an adjacency between two level 1 ISs require that there be at least one area address in common between their two manualAreaAddresses lists, and the procedures for establishing an adjacency between a level 1 Is and an End system require that the End system's area address must match an entry in the IS's manualAreaAddresses list. Therefore, it is the responsibility of System Management to ensure that each area address associated with an IS is included: in particular, system management must ensure that the area addresses of all ESs and Level 1 ISs adjacent to 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 an 8473 PDU  or for the next entry in its source routeing field, when present  is not listed in the parameter area Addresses of a level 1 IS receiving the PDU, then the destination system does not reside in the IS's area. Such PDUs 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, the  IDI is padded with leading digits (if necessary) to obtain the maximum IDP length specified for that AFI.A Level 2 address prefix consists of a leading sub-string of a full NSAP address, such that it matches a set of full NSAP addresses that have the same leading sub-string. However this truncation and matching is performed on the NSAP 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 same way as full NSAP addresses, except when the end of the prefix falls within the IDP. In this case the prefix is directly encoded as the string of semi-octets with no padding. 7.1.5 Comparison of AddressesUnless otherwise stated, numerical comparison of addresses shall be performed on the encoded form of the address, by padding the shorter address with trailing zeros to the length of the longer address, and then performing a numerical comparison.The addresses to which this precedure applies include NSAP addresses, Network Entity Titles, and SNPA addresses.7.2 The Decision ProcessThis process uses the database of Link State information to calculate the forwarding database(s), from which the forwarding process can know the proper next hop for each NPDU. The Level 1 Link State Database is used for calculating the Level 1 Forwarding Database(s), and the Level 2 Link 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 all known Intermediate systems (within this area, for Level 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 the Update Process that a change to a link has occurred somewhere in the domain. OUTPUT-Level 1 Forwarding Databases  one per routeing metric-(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 of the ID of the Level 2 Intermediate system within the area with lowest ID reachable with real level 1 links  (as opposed to a virtual link consisting of a path through 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 Decision Process informs the Level 1 Update Process of the values of the default routeing metric to and ID of the partition designated level 2 Intermediate system in each other partition of this area. 7.2.2 Routeing metricsThere are four routeing metrics defined, corresponding to the four possible orthogonal qualities of service defined by the QoS Maintenance field of ISO 8473. Each circuit emanating from an Intermediate system shall be assigned a value 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 every Intermediate system in the domain. Each circuit shall have 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 to measure the capacity of the circuit for handling traffic, for example, its throughput in bits-per-second.  Higher values indicate a lower capacity.b)Delay metric:  This metric measures the transit delay of the associated circuit. It is an optional metric, which if assigned to a circuit shall have a positive integral value. Higher values indicate a longer transit delay.c)Expense metric: This metric measures the monetary cost of utilising the associated circuit. It is an optional metric, 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 is not 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 larger monetary expense.d)Error metric: This metric measures the residual error probability of the associated circuit. It is an optional metric, which if assigned to a circuit shall have a non-zero value. Higher values indicate a larger probability of undetected errors on the circuit.NOTE - The decision process combines metric values by simple addition.  It is important, therefore, that the values of the metrics be chosen accordingly.Every Intermediate system shall be capable of calculating routes based on the default metric. Support of any or all of the other metrics is optional. If an Intermediate system supports the calculation of routes based on a metric, its update process 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 routeing metrics, the decision process only utilises LSPs with a value reported for the corresponding metric. If no value is  associated 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 another metric.See 7.4.2 for a description of how the forwarding process selects one of these metrics based on the contents of the ISO 8473 QoS Maintenance option.Each of the four metrics described above may be of two types: an  Internal metric or an External metric. Internal metrics are used to describe links/routes to destinations internal to the routeing domain. External metrics are used to describe links/routes to destinations outside of the routeing domain. These two types of metrics are not directly comparable, except the internal routes are always preferred over external routes. In other words an internal route will always be selected even if an external route with lower total cost exists.7.2.3 Broadcast SubnetworksInstead of treating a broadcast subnetwork as a fully connected topology, the broadcast subnetwork is treated as a pseudonode, with links to each attached system. Attached systems shall only report their link to the pseudonode. The designated Intermediate system, on behalf of the pseudonode, shall construct Link State PDUs reporting the links to all the systems on the broadcast subnetwork with a zero value for each supported routeing metric33They are set to zerometric values since they have already been assigned  metrics by thelink to the pseudonode. Assigning a non-zero value in the pseudonode LSP would have the effect of doubling the actual value..The pseudonode shall be identified by the sourceID of the Designated Intermediate system, followed by a non-zero pseudonodeID assigned by the Designated Intermediate system. The pseudonodeID is locally unique to the Designated Intermediate system.Designated Intermediate systems are determined separately for level 1 and level 2. They are known as the LAN Level 1 Designated IS and the LAN Level 2 Designated IS respectively. See 8.4.4.An Intermediate system may resign as Designated Intermediate System on a broadcast circuit either because it (or it's SNPA on the broadcast subnetwork) is being shut down or because some other Intermediate system of higher priority has taken over that function. When an Intermediate system resigns as Designated Intermediate System, it shall initiate a network wide purge of its pseudonode Link State PDU(s) by setting their Remaining Lifetime to zero and performing the actions described in 7.3.16.4. A LAN Level 1 Designated Intermediate System purges Level 1 Link State PDUs and a LAN Level 2 Designated Intermediate System purges Level 2 Link State PDUs.  An Intermediate system which has resigned as both Level 1 and Level 2 Designated Intermediate System shall purge both sets of LSPs. When an Intermediate system declares itself as designated Intermediate system and it is in possession of a Link State PDU of the same level issued by the previous Designated Intermediate System for that circuit (if any), it shall initiate a network wide purge of that (or those) Link State PDU(s) as above.7.2.4 LinksTwo Intermediate systems are not considered neighbours unless each reports the other as directly reachable over one of their SNPAs. On a Connection-oriented subnetwork (either point-to-point or general topology), the two Intermediate systems in question shall ascertain their neighbour relationship when a connection is established and hello PDUs exchanged. A malfunctioning IS might, however, report another IS to be a neighbour when in fact it is not. To detect this class of failure the decision process checks that each link reported as up in a LSP is so reported by both Intermediate systems. If an Intermediate system considers a link down it shall not mention the link in its Link State PDUs.On broadcast subnetworks, this class of failure shall be detected by the designated IS, which has the responsibility to ascertain the set of Intermediate systems that can all communicate on the subnetwork. The designated IS shall in