routing protocol is used to dynamically map between
.TnISONSAP
addresses and
.TnISOSNPA
addresses; to permit End and Intermediate Systems
to learn of each other's existence; and to allow Intermediate Systems
to inform End Systems of (potentially) better routes to use when
forwarding
.TnNPDUNss
to a particular destination.
.Pp
The mapping between
.TnNSAP
addresses and
.TnSNPA
addresses is accomplished by
transmitting hello
.TnPDUNss
between the cooperating Systems. These
.TnPDUNss
are transmitted whenever the
.Emconfiguration
timer expires.
When a hello
.TnPDU
is received, the
.TnSNPA
address that it conveys is stored in the routing table for as long as the
.Emholdingtime
in the
.TnPDU
suggests. The default
.Emholdingtime
(120 seconds) placed in the hello
.TnPDU,
the configuration timer value,
and the system type (End System or Intermediate System) may be changed by
issuing an
.DvSIOCSSTYPE
.Xrioctl2,
which is defined in
.Pa/sys/netiso/iso_snpac.h.
.Pp
The protocol behaves differently depending on whether the System is
configured as an End System or an Intermediate System.
.ShENDSYSTEMOPERATION
When an interface requests a mapping for an address not in the cache,
the
.TnSNPA
of any known Intermediate System is returned. If an Intermediate
System is not known, then the
.Emallendsystems
multicast address
is returned. It is assumed that the intended recipient of the NPDU will
immediately transmit a hello
.TnPDU
back to the originator of the
.TnNPDU.
.Pp
If an
.TnNPDU
is forwarded by the End System, a redirect
.TnPDU
will not be
generated.
However, redirect
.TnPDUNss
received will be processed. This processing
consists of adding an entry in the routing table. If the
redirect is towards an Intermediate System, then an entry is made in the
routing table as well.
The entry in the routing table will mark the
.TnNSAP
address contained in the redirect
.TnPDU
as the gateway for the destination
system (if an NET is supplied), or will create a route with
the NSAP address as the
destination and the
.TnSNPA
address (embodied as a link-level sockaddr) as the
gateway.
.Pp
If the System is configured as an End System, it will report all the
.TnNSAPNss
that have been configured using the ifconfig command, and no others.
It is possible to have more than one
.TnNSAP
assigned to a given interface,
and it is also possible to have the same
.TnNSAP
assigned to multiple
interfaces.
However, any
.TnNSAP
containing an NSEL that is consistent with the
nsellength option (default one) of any interface will be accepted as
an
.TnNSAP
for this System.
.ShINTERMEDIATESYSTEMOPERATION
When an interface requests a mapping for an address not in the routing table,
an error is returned.
.Pp
When an
.TnNPDU
is forwarded out on the same interface that the
.TnNPDU
arrived upon,
a redirect
.TnPDU
is generated.
.ShMANUALROUTINGTABLEMODIFICATION
.Pp
To facilitate communications with systems which do not use
.NmES-IS,
one may add a route whose destination is a sockaddr_iso containing
the
.TnNSAP
in question, and the gateway being a link-level sockaddr,
either by writing a special purpose program, or using the
.Xrroute8
command e.g.:
.Bd-literal
route add -iface -osi 49.0.4.8.0.2b.b.83.bf \
-link qe0:8.0.2b.b.83.bf
.Ed
.Pp
If the
System is configured as an End System and has a single network interface
which does not support multicast reception,
it is necessary to manually configure the location of an
.TnIS,
using the route command in a similar way.
There, the destination address should be
.Dqdefault
(spelled
out literally as 7
.TnASCII
characters), and the gateway should be
once again be a link-level sockaddr specifying the
.TnSNPA
of the
.TnIS.
.ShSEEALSO
.Xrun4,
.Xriso4,
.Xrroute8,
.Xrifconfig8
.Rs
.%T"End system to Intermediate system routing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service"
.%RISO
.%N9542
.Re
.ShBUGS
Redirect
.TnPDUNss
do not contain options from the forwarded
.TnNPDU
which generated
the redirect. The multicast address used on the 802.3 network is taken from
the
.TnNBS
December 1987 agreements. This multicast address is not compatible
with the 802.5 (Token Ring) multicast addresses format. Therefore, broadcast
addresses are used on the 802.5 subnetwork.
Researchers at the University of Wisconsin are constructing an implementation