rfc911.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,136 行 · 第 1/4 页

being switched between the gateway reported by EGP and the assigned gateway.  A
similar thing occurs when using routes to other nets reached via MILNET/ARPANET
gateways.

RFC 911                                                                      11


4. FUTURE ENHANCEMENTS

4.1 Multiple Autonomous Systems

The  present  method  of  acquiring  a  maximum  number of EGP neighbors from a
trusted list implies that all the neighbors are in the same AS.  The  intention
is  that  they all be members of the core AS. When updating the routing tables,
Updates are treated independently with no distinction made as  to  whether  the
advised  routes  are  internal  or  external  to  the peer's AS.  Also, routing
metrics are compared without reference to the AS of the source.

If EGP is to be  conducted  with  additional  AS's  beside  the  core  AS,  all
neighbors  on  the  list  would  need  to  be  acquired in order to ensure that
gateways from both AS's were always acquired. This results  in  an  unnecessary
excess  of  EGP  traffic if redundant neighbors are acquired for reliability. A
more desirable approach would be to have separate lists of trusted EGP gateways
and the maximum number to be acquire, for each AS. Routing entries  would  need
to  have  the  source AS added so that preference could be given to information
received from the owning AS (see Section 5.1.2)


4.2 Interface Monitoring

At present, interface status is only checked immediately prior to  the  sending
of  an  Update  in response to a Poll.  The interface status could be monitored
more regularly and an unsolicited Update sent when a change is  detected.  This
is  one  area where the slow response of EGP polling could be improved. This is
of particular interest to networks that may  be  connected  by  dial-in  lines.
When such a network dials in, its associated interface will be marked as up but
it  will not be able to receive packets until the change has been propagated by
EGP. This is one case where the unsolicited  Update  message  would  help,  but
there  is still the delay for other non-core gateways to poll core EGP gateways
for the new routing information.

This  was  one  case  where  it  was  initially  thought  that  a  kernel   EGP
implementation  might  help.  But  the kernel does not presently pass interface
status changes by interrupts so a new facility would need to  be  incorporated.
If  this was done it may be just as easy to provide a user level signal when an
interface status changes.


4.3 Network Level Status Information

At present, network level status reports, such as IMP  Destination  Unreachable
messages,  are  not used to detect changes in the reachability of EGP neighbors
or other neighbor gateways. This information should  be  used  to  improve  the
response time to changes.

RFC 911                                                                      12


4.4 Interior Gateway Protocol Interface

At  present  any  routing  information that is interior to the AS is static and
read from the initialization file. The internal route management functions have
been written so that it should be reasonably  easy  to  interface  an  IGP  for
dynamic  interior  route  updates. This is facilitated by the separation of the
exterior and interior routing tables.

The outgoing EGP Updates will be correctly prepared from the  interior  routing
table by rt_NRnets() whether or not static or dynamic interior routing is done.
Functions  are  also  provided  for  looking  up, adding, changing and deleting
internal routes, i.e. rt_int_lookup(), rt_add(),  rt_change()  and  rt_delete()
respectively.

The  interaction  of an IGP with the current data structures basically involves
three functions: updating the interior routing table using a  function  similar
to rt_NRupdate(), preparing outgoing interior updates similarly to rt_NRnets(),
and timing out interior routes similarly to rt_time().

RFC 911                                                                      13


5. TOPOLOGY ISSUES

5.1 Topology Restrictions and Routing Loops



5.1.1 Background

EGP  is  not  a  routing  algorithm.  it  merely  enables exterior neighbors to
exchange routing information which is likely to  to  be  needed  by  a  routing
algorithm.  It does not pass sufficient information to prevent routing loops if
cycles exist in the topology [Rosen 82].

Routing loops can occur when two gateways think there are alternate  routes  to
reach a third gateway via each other. When the third gateway goes down they end
up  pointing  to  each  other  forming a routing loop.  Within the present core
system, loops are broken by counting to "infinity" (the  internet  diameter  in
gateway  hops).  This  (usually)  works  satisfactorily  because GGP propagates
changes fairly quickly as routing updates are sent as soon  as  changes  occur.
Also  the  diameter of the internet is quite small (5) and a universal distance
metric, hop count, is used. But this will be changed in the future.

With EGP, changes are propagated  slowly.  Although  a  single  unsolicited  NR
message  can  be  sent,  it  won't  necessarily  be passed straight on to other
gateways who must hear about it  indirectly.  Also,  the  distance  metrics  of
different  AS's  are  quite  independent  and  hence  can't be used to count to
infinity.

The initial proposal was to prevent routing loops by restricting  the  topology
of  AS's to a tree structure so that there are no multiple routes via alternate
AS's.  Multiple routes within the same AS are allowed as  it  is  the  interior
routing strategies responsibility to control loops.

[Mills  84b]  has  noted that even with the tree topology restriction, "we must
assume that transient loops may form within the core system from time  to  time
and  that  this  information  may escape to other systems; however, it would be
expected that these loops would not persist for very long and would  be  broken
in  a  short  time  within the core system itself. Thus a loop between non-core
systems can persist until the first round of Update messages sent to the  other
systems  after  all traces of the loop have been purged from the core system or
until the reachability information ages out of  the  tables,  whichever  occurs
first".

With the initial simple stub EGP systems the tree topology restriction could be
satisfied. But for the long term this does not provide sufficient robustness.

[Mills  83]  proposed a procedure by which the AS's can dynamically reconfigure
themselves such that the topology restriction is always met, without  the  need
for  a  single  "core" AS.  One AS would own a shared net and its neighbor AS's
would just conduct EGP with the owner. The owner would pass on such information
indirectly as the core system does now. If the  owning  AS  is  defined  to  be
closest  to  the  root  of the tree topology, any haphazard interconnection can

RFC 911                                                                      14


form  itself  into  an appropriate tree structured routing topology. By routing
topology I mean the topology as advised in routing updates. There may  well  be
other  physical  connections  but if they are not advised they will not be used
for routing. Each AS can conduct EGP with at most one AS that owns one  of  its
shared nets. Any AS that is not conducting EGP over any net owned by another AS
is  the  root of a subtree. It may conduct EGP with just one other AS that owns
one of its shared nets. This "attachment" combines  the  two  subtrees  into  a
single  subtree  such  that  the  overall  topology  is still a tree.  Topology
violations can be determined because two different AS's will report  that  they
can reach the same net.

With  such  a  dynamic  tree,  there may be preferred and backup links. In such
cases it is necessary to monitor the failed link so that routing can be changed
back to the preferred link when service is restored.

Another aspect to consider is the possibility of detecting  routing  loops  and
then  breaking  them. Expiration of the packet time-to-live (TTL) could be used
to do this. If such a loop is suspected a diagnostic packet, such as ICMP echo,
could be sent over the suspect route to confirm whether it is a loop. If a loop
is detected a special  routing  packet  could  be  sent  over  the  route  that
instructs  each gateway to delete the route after forwarding the packet on. The
acceptance of new routing information may need to be delayed for  a  hold  down
period.  This approach would require sensible selection of the initial TTL. But
this is not done by many hosts.



5.1.2 Current Policy

Considering the general trend to  increased  network  interconnection  and  the
availability of alternative long-haul networks such as ARPANET, WBNET (wideband
satellite  network),  and public data networks the tree topology restriction is
generally unacceptable. A less restrictive topology is  currently  recommended.
The following is taken from [Mills 84b].

EGP topological model:

   - An  autonomous  system  consists  of  a  set of gateways connected by
     networks.  Each gateway in the system must be  reachable  from  every
     other  gateway in its system by paths including only gateways in that
     system.

   - A gateway in a system may run EGP with a gateway in any other  system
     as  long  as the path over which EGP itself is run does not include a
     gateway in a third system.

   - The "core system" is distinguished from the others by the  fact  that
     only  it  is  allowed  to  distribute  reachability information about
     systems other than itself.

   - At least one gateway in every system must have a net in common with a
     gateway in the core system.

RFC 911                                                                      15


   - There  are  no  topological  or  connectivity restrictions other than
     those implied above.

A gateway  will  use  information  derived  from  its  configuration  (directly
connected  nets),  the  IGP of its system, called S in the following, (interior
nets) and EGP (interior and exterior nets of neighboring systems) to  construct
its routing tables. If conflicts with respect to a particular net N occur, they
will be resolved as follows:

   - If  N  is  directly connected to the gateway, all IGP and EGP reports
     about N are disregarded.

   - If N is reported by IGP as  interior  to  S  and  by  EGP  as  either
     interior  or  exterior  to  another  system,  the  IGP  report  takes
     precedence.

   - If N is reported by EGP as interior to one  system  and  exterior  to
     another, the interior report takes precedence.

   - If  N  is  reported  as  interior by two or more gateways of the same
     system using EGP, the reports specifying the smallest hop count  take
     precedence.

   - In all other cases the latest received report takes precedence.

Old information will be aged from the tables.

The   interim   model  provides  an  acceptable  degree  of  self-organization.
Transient routing loops can occur between systems,  but  these  are  eventually
broken by old reachability information being aged out of the tables.  Given the
fact  that  transient  loops  can occur due to temporary core-system loops, the
additional loops that might occur in the case of local nets homed  to  multiple
systems does not seem to increase the risk significantly.


5.2 Present ISI Configuration

A  simplified  version of the ISI network configuration is shown in Figure 5-1.
ISI-Hobgoblin can provide a backup gateway function  to  the  core  ISI-Gateway
between  ARPANET and ISI-NET. ISI-Hobgoblin is a VAX 11/750 which runs Berkeley
Unix  4.2.  The  EGP  implementation  described  in  this  report  is  run   on
ISI-Hobgoblin.

ISI-Troll  is part of a split gateway to the University of California at Irvine
network (UCI-ICS). The complete logical gateway consists of ISI-Troll, the 9600
baud link and UCI-750A [Rose 84]. ISI-Troll runs Berkeley Unix 4.1a  and  hence
cannot  run  the  EGP  program.  It  is  therefore  a non-routing gateway.  The
existence of UCI-ICS net must be advised to the core AS by ISI-Hobgoblin.  This
can be done by including an appropriate entry in the EGPINITFILE.

Hosts on ISI-NET, including ISI-Troll, have  static  route  entries  indicating
ISI-Gateway as the first hop for all networks other than UCI-ICS and ISI-NET.

RFC 911                                                                      16


          -------------------------------------------------
         /                                                 \
        /                      ARPANET                      \
        \                        10                         /
         \                                                 /
          -------------------------------------------------
             |                    |                    |
             |                    |                    |
             |                    |                    |
      +-------------+      +-------------+      +---------------+
      | ISI-PNG11   |      |             |      |               |
      | Arpanet     |      | ISI-GATEWAY |      | ISI-HOBGOBLIN |
      | Address     |      |             |      |   Vax 11/750  |
      | logical     |      |  Core EGP   |      |   Unix 4.2    |
      | multiplexer |      |             |      |               |
      +-------------+      +-------------+      +---------------+
             |                    |                    |
             |                    |                    |
             |                    |                    |
      ---------------          ----------------------------
     /               \        /                            \
    / 3 Mb/s Ethernet \      /           ISI-NET            \
    \     net 10      /      \            128.9             /
     \               /        \                            /
      ---------------          ----------------------------
                                      |
                                      |
                                      |
                               +--------------+
                               |  ISI-TROLL   |
                               |  Vax 11/750  |
                               |  Unix 4.1a   |
                               |  Non-routing |
                               |      |       |
                               |      | 9600  |   ISI-TROLL, UCI-750A
                               |      | baud  |   and the link form a