there is a close binding between the circuit manager and the routing
applications - that they are in some way the same 'program'. This is
not necessarily true of all products which are routers.
In particular there are UNIX host implementations in which the
routing application is distinct from the kernel, where the circuit
manager is likely to be installed. In such systems it is possible to
stop (or crash) the routing applications independently of what is
happening in the kernel.
Other implementations might have the circuit manager on a separate
card which again may give the circuit manager a life of its own.
In implementations where the applications and circuit manager have
independent lives, a keep-alive mechanism MUST be provided between
the applications and the circuit manager, so that if the application
or network layer dies and is subsequently re-started they can
resynchronize their state tables.
Ideally, when an application dies, the circuit manager should close
all existing VCs appropriate to the application and make no further
outgoing calls and reject incoming calls until the application is
running again.
If the circuit manager is using some form of encapsulation, several
applications may be sharing the same VC. If this is the case the
circuit manager may wish to filter out datagrams for the appropriate
network layer if only one of the applications is affected. But this
is not an ideal solution.
Conversely if the application believes the circuit manager has died,
it should mark all routes via the circuit manager as unreachable and
advertise them on other interfaces for the duration of the hold down
timer before deleting them.
9. Security Considerations
Security is provided my a number of aspects:
o The circuit manager is required to be provided with a list of
physical addresses to enable it to establish a call to the next
hop router on an X.25 SVC or ISDN B-channel.
The circuit manager SHOULD only allow incoming calls to be
accepted from the same well defined list of routers.
Elsewhere in the system there will be a set of logical address
and physical address tuples to enable the network protocols to
run over the correct circuit. This may be a lookup table, or in
some instances there may be an algorithmic conversion between
the two addresses.
o The routing (or service advertising) task MUST be provided with a
list of logical addresses to which triggered updates are to be
sent on the WAN. The list MAY be a subset of the list of next
hop routers maintained by the circuit manager.
There MAY also be a separate list of next hop routers to which
traditional broadcasts of routing (or service advertising)
updates should be sent. Next hop routers omitted from either
list are assumed to be not participating in routing (or service
advertising) updates.
The list (or lists) doubles as a list of routers from which
routing updates are allowed to be received from the WAN. Any
routing information received from a router not in the
appropriate list MUST be discarded.
10. References
[1] Hedrick. C., "Routing Information Protocol", STD 34, RFC1058,
Rutgers University, June 1988.
[2] Malkin. G., "RIP Version 2 - Carrying Additional Information",
RFC1388, Xylogics, January 1993.
[3] Novell Incorporated., "IPX Router Specification", Version 1.10,
October 1992.
[4] Xerox Corporation., "Internet Transport Protocols", Xerox System
Integration Standard XSIS 028112, December 1981.
[5] Malis. A., Robinson. D., and R. Ullmann, "Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode", RFC1356, BBN
Communications, Computervision Systems Integration, Process
Software Corporation, August 1992.
11. Author's Address
Gerry Meyer
Spider Systems
Stanwell Street
Edinburgh EH6 5NG
Scotland, UK
Phone: (UK) 31 554 9424
Fax: (UK) 31 554 0649
EMail: gerry@spider.co.uk