rfc1142.txt

RFC 的详细文档！

-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 routeing 
metric  (L2, L1) 
-Level 2 Forwarding Database  one per routeing 
metric  (L2)
7.1 Addresses 
The NSAP addresses and NETs of systems are variable 
length quantities that conform to the requirements of ISO 
8348/Add.2. The corresponding NPAI contained in ISO 
8473 PDUs and in this protocol's PDUs (such as LSPs and 
IIHs) must use the preferred binary encoding; the underly
ing syntax for this information may be either abstract binary 
syntax or abstract decimal syntax. Any of the AFIs and 
their corresponding DSP syntax may be used with this pro
tocol.
7.1.1 NPAI Of Systems Within A Routeing 
Domain 
Figure 3 illustrates the structure of an encoded NSAP ad
dress or NET. 
 
The structure of the NPAI will be interpreted in the follow
ing way by the protocol described in this international stan
dard: 
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 employ
ing this protocol shall select a single size for the ID 
field and all Intermediate systems in the routeing do
main shall use this length for the system IDs of all 
systems in the routeing domain. 
	The set of ID lengths supported by an implementa
tion is an implementation choice, provided that at 
least one value in the permitted range can be ac
cepted. The routeing domain administrator must en
sure 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 se
lector 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 sys
temID: 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 associ
ated 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 route
ing domain must have a unique value for its ID 
field: that is, no two level 2 ISs in a routeing do
main 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 ad
dresses 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 adja
cent IS's manual

Area

Addresses parameter.
It is the responsibility of the routeing domain's administra
tive authority to enforce the requirements of 7.1.2. The pro
tocol 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 parame
ter 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, in
cluding 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 in
cluding it in their Level 2 LSP's Area Addresses field, 
thus distributing information on all the area addresses asso
ciated 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 proce
dures 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 Manage
ment 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 Addresses
When a full NSAP address is encoded according to the pre
ferred 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 ad
dress, not on the encoded (and hence padded) form.11An example of
prefix 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 Addresses
Unless 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 ad
dresses.
7.2 The Decision Process
This process uses the database of Link State information to 
calculate the forwarding database(s), from which the for
warding process can know the proper next hop for each 
NPDU. The Level 1 Link State Database is used for calcu
lating the Level 1 Forwarding Database(s), and the Level 2 
Link State Database is used for calculating the Level 2 For
warding Database(s).
7.2.1 Input and output
INPUT
-Link State Database  This database is a set of infor
mation 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 Forward
ing Databases   one per routeing metric
-(Level 2 Intermediate systems only) The Level 1 De
cision 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 Intermedi
ate system is the Partition Designated Level 2 Inter
mediate 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 metrics
There 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 ema
nating from an Intermediate system shall be assigned a 
value for one or more of these metrics by System manage
ment. 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 func
tion 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 posi
tive integral value22The path computation algorithm utilised in this
International Standard requires that all circuits be assigned a
positive value for a metric. Therefore, it is 
not possible to represent a free circuit by a zero value of the expense
metric. 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 sup
ports the calculation of routes based on a metric, its update 
process may report the metric value in the LSPs for the as
sociated circuit; otherwise, the IS shall not report the met
ric.
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 sys
tem shall not calculate routes based on that metric.
NOTE - A consequence of the above is that a system reach
able 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 in
ternal to the routeing domain. External metrics are used to 
describe links/routes to destinations outside of the routeing 
domain. These two types of metrics are not directly compa
rable, except the internal routes are always preferred over 
external routes. In other words an internal route will always 
be selected even if an external route with lower total cost 
exists.
7.2.3 Broadcast Subnetworks
Instead of treating a broadcast subnetwork as a fully con
nected topology, the broadcast subnetwork is treated as a 
pseudonode, with links to each attached system. Attached 
systems shall only report their link to the pseudonode. The 
designated Intermediate system, on behalf of the 
pseudonode, shall construct Link State PDUs reporting the 
links to all the systems on the broadcast subnetwork with a 
zero value for each supported routeing metric33They are set to zero
metric values since they have already been assigned  metrics by the
link to the pseudonode. Assigning a non-zero value in the 
pseudonode LSP would have the effect of doubling the actual value.
.
The pseudonode shall be identified by the sourceID of the 
Designated Intermediate system, followed by a non-zero 
pseudonodeID assigned by the Designated Intermediate 
system. The pseudonodeID is locally unique to the Desig
nated Intermediate system.
Designated Intermediate systems are determined separately 
for level 1 and level 2. They are known as the LAN Level 1 
Designated IS and the LAN Level 2 Designated IS respec
tively. See 8.4.4.
An Intermediate system may resign as Designated Interme
diate System on a broadcast circuit either because it (or it's 
SNPA on the broadcast subnetwork) is being shut down or 
because some other Intermediate system of higher priority 
has taken over that function. When an Intermediate system 
resigns as Designated Intermediate System, it shall initiate a 
network wide purge of its pseudonode Link State PDU(s) 
by setting their Remaining Lifetime to zero and performing 
the actions described in 7.3.16.4. A LAN Level 1 Desig
nated Intermediate System purges Level 1 Link State PDUs