rfc911.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

                               |      | link  |   single logical gateway
                               |      |       |
                               |  UCI-750A    |
                               |  Vax 11/750  |
                               |  Unix 4.2    |
                               +--------------+
                                      |
                                      |
                                      |
                            ----------------------
                           /                      \
                          /        UCI-ICS         \
                          \        192.5.19        /
                           \                      /
                            ----------------------


              Figure 5-1:   Simplified ISI Network Configuration

RFC 911                                                                      17


EGP can either be conducted with ISI-Gateway across ARPANET or ISI-NET.



5.2.1 EGP Across ARPANET

ISI-Hobgoblin  will  advise  ISI-Gateway  across  ARPANET,  and  hence the core
system, that it can reach ISI-NET and UCI-ICS.

Packets from AS's exterior to ISI and destined for UCI-ICS will be  routed  via
ISI-Gateway,  ISI-Hobgoblin  and  ISI-Troll.  The extra hop via ISI-Gateway (or
other core EGP gateway) is because the core gateways do not currently  pass  on
indirect-neighbor   exterior   gateway   addresses   in   their   IGP  messages
(Gateway-to-Gateway Protocol).  Packets originating from UCI-ICS  destined  for
exterior  AS's will be routed via ISI-Troll and ISI-Gateway.  Thus the incoming
and out going packet routes are different.

Packets originating from ISI-Hobgoblin as a host and destined for exterior AS's
will be routed via the appropriate gateway on ARPANET.

UCI-ICS can only communicate with exterior AS's if ISI-Troll, ISI-Hobgoblin and
ISI-Gateway are all up. The dependence on ISI-Gateway could  be  eliminated  if
ISI-Troll  routed  packets via ISI-Hobgoblin rather than ISI-Gateway.  However,
as ISI-Hobgoblin is primarily a host and not a gateway it  is  preferable  that
ISI-Gateway route packets when possible.

ISI-Hobgoblin  can  provide a back-up gateway function to ISI-Gateway as it can
automatically switch to an alternative core EGP peer if ISI-Gateway goes  down.
Even  though  ISI-Hobgoblin  normally advises the core system that it can reach
ISI-NET the core uses its own internal route  via  ISI-Gateway  in  preference.
For hosts on ISI-NET to correctly route outgoing packets they need their static
gateway  entries  changed  from  ISI-Gateway to ISI-Hobgoblin.  At present this
would have to be done manually. This would only be appropriate  if  ISI-Gateway
was going to be down for an extended period.



5.2.2 EGP Across ISI-NET

ISI-Hobgoblin   will  advise  ISI-Gateway  across  ISI-NET  that  its  indirect
neighbor, ISI-Troll, can reach UCI-ICS net.

All exterior packet routing  for  UCI-ICS  will  be  via  ISI-Gateway  in  both
directions   with   no  hops  via  ISI-Hobgoblin.    Packets  originating  from
ISI-Hobgoblin as a host and destined for  exterior  AS's  will  be  routed  via
ISI-Gateway, rather than the ARPANET interface, in both directions, thus taking
an additional hop.

UCI-ICS  can  only  communicate with exterior AS's if ISI-Troll and ISI-Gateway
are up and ISI-Hobgoblin has advised  ISI-Gateway  of  the  UCI-ICS  route.  If
ISI-Hobgoblin   goes   down,  communication  will  still  be  possible  because
ISI-gateway (and other core gateways)  do  not  time  out  routes  to  indirect

RFC 911                                                                      18


neighbors.  If  ISI-Gateway  then  goes  down,  it will need to be readvised by
ISI-Hobgoblin of the UCI-ICS route, when it comes up.

Conducting EGP over ISI-NET rather than ARPANET should  provide  more  reliable
service  for  UCI-ICS  for  the  following reasons: ISI-Gateway is specifically
designed as a gateway, it is expected to be up more than ISI-Hobgoblin,  it  is
desirable  to  eliminate  extra  routing  hops where possible and, the exterior
routing  information  will  persist  after  ISI-hobgoblin  goes   down.      If
ISI-Hobgoblin  is to be used in its back-up mode, EGP could be restarted across
ARPANET after the new gateway routes  are  manually  installed  in  the  hosts.
Therefore, EGP across ISI-NET was selected as the preferred mode of operation.



5.2.3 Potential Routing Loop

Because  both  ISI-Gateway and ISI-Hobgoblin provide routes between ARPANET and
ISI-NET there is a potential routing loop. This topology in fact  violates  the
original  tree  structure  restriction. Provided ISI-Hobgoblin does not conduct
EGP simultaneously with ISI-Gateway over ISI-NET and ARPANET, the gateways will
only ever know about the alternative route from the shared EGP network and  not
from  the  other  network.  Thus  a loop cannot occur.  For instance, if EGP is
conducted over ISI-NET, both ISI-Gateway and ISI-Hobgoblin will know about  the
alternative  routes  via  each other to ARPANET from ISI-NET, but they will not
know about the gateway addresses on ARPANET to be able to access  ISI-NET  from
ARPANET.  Thus  they have insufficient routing data to be able to route packets
in a loop between themselves.


5.3 Possible Future Configuration



5.3.1 Gateway to UCI-ICS

An improvement in the reliability and performance of  the  service  offered  to
UCI-ICS  can  be  achieved  by  moving  the UCI-ICS interface from ISI-Troll to
ISI-Hobgoblin. Reliability  will  improve  because  the  connection  will  only
require  ISI-Hobgoblin  and its ARPANET interface to be up and performance will
improve because the extra gateway hop will be eliminated.

This will also allow EGP to be conducted across ARPANET giving  access  to  the
alternative  core gateways running EGP. This will increase the chances of being
able to reliably acquire an EGP neighbor at all times. It will  also  eliminate
the  extra hop via ISI-Gateway for packets originating from ISI-Hobgoblin, as a
host, and destined for exterior networks.

This configuration change will be made at sometime in the future.  It  was  not
done  initially because ISI-Hobgoblin was experimental and down more often than
ISI-Troll.

RFC 911                                                                      19


5.3.2 Dynamic Switch to Backup Gateway

It  was  noted in Section 5.2.1 that ISI-Hobgoblin can provide a backup gateway
function to ISI-Gateway between ARPANET and ISI-NET. Such backup gateways could
become a common approach to providing increased reliability.

At present the change over to the backup gateway requires the new gateway route
to be manually entered for hosts on ISI-NET. This section describes a  possible
method  for achieving this changeover dynamically when the primary gateway goes
down.

The aim is to be able to detect when the primary gateway is down and  have  all
hosts  on  the local network change to the backup gateway with a minimum amount
of additional network traffic. The hosts should  revert  back  to  the  primary
gateway when it comes up again.

The  proposed  method  is  for  only  the backup gateway to monitor the primary
gateway status and for it to notify all hosts of the new gateway  address  when
there is a change.


5.3.2.1 Usual Operation

The backup gateway runs a process which sends reachability-probe messages, such
as  ICMP echoes, to the primary gateway every 30 seconds and uses the responses
to determine reachability as for EGP.  If  the  primary  gateway  goes  down  a
"gateway-address  message"  indicating  the backup gateway address is broadcast
(or preferably multicast) to all hosts.  When  the  primary  gateway  comes  up
another  gateway  message  indicating the primary gateway address is broadcast.
These broadcasts should be done four times at 30 second intervals to avoid  the
need for acknowledgements and knowledge of host addresses.

Each  host  would run a process that listens for gateway-address messages. If a
different gateway is advised it changes the default gateway entry  to  the  new
address.


5.3.2.2 Host Initialization

When  a  host comes up the primary gateway could be down so it needs to be able
to determine that it should use the backup gateway. The  host  could  read  the
address  of  the primary and backup gateways from a static initialization file.
It would then set its default  gateway  as  the  primary  gateway  and  send  a
"gateway-request  message" to the backup gateway requesting the current gateway
address. The backup gateway would respond with a gateway-address message.    If
no response is received the gateway-request should be retransmitted three times
at  30  second intervals.  If no response is received the backup gateway can be
assumed down and the primary gateway retained as the default.

Whenever the backup gateway comes up it broadcasts a gateway-address message.

Alternatively, a broadcast (or  multicast)  gateway-request  message  could  be

RFC 911                                                                      20


defined  to  which  only  gateways  would  respond.  The backup gateway-address
message needs to indicate that it is the backup gateway so that future requests
need not be broadcast. Again, three retransmissions should be used.    But  the
primary gateway also needs to broadcast its address whenever it comes up.


5.3.2.3 When Both the Primary and Backup are Down

If the primary gateway is down and the backup knows it is going down, it should
broadcast  gateway-address  messages indicating the primary gateway in case the
primary gateway comes up first.

But the backup could go down without warning and the primary come up before it.
If the primary gateway broadcasts a gateway-address message when  it  comes  up
there  is  no problem. Otherwise, while hosts are using the backup gateway they
should send a gateway-request message every  10  minutes.  If  no  response  is
received it should be retransmitted 3 times at 30 second intervals and if still
no response the backup assumed down and the primary gateway reverted to.

Thus the only time hosts need to send messages periodically is when the primary
gateway  does  not  send  gateway-address  messages on coming up and the backup
gateway is being used. In some cases, such as at ISI, the  primary  gateway  is
managed  by  a  different  organization  and  experimental  features  cannot be
conveniently added.


5.3.2.4 Unix 4.2 BSD

One difficulty with the above is that there is no standard method of specifying
internet broadcast or multicast addresses. Multicast addressing  is  preferable
as  only those participating need process the message (interfaces with hardware
multicast detection are available). In the case of Unix  4.2  BSD  an  internet
address  with zero local address is assumed for the internet broadcast address.
However, the general Internet Addressing policy is to use an all ones value  to
indicate a broadcast function.

On  Unix  4.2  BSD systems, both the gateway and host processes could be run at
the user level so that kernel modifications are not required.

A User Datagram Protocol (UDP) socket could be reserved for host-backup-gateway
communication.

Super user access to raw sockets for sending and receiving ICMP  Echo  messages
requires a minor modification to the internet-family protocol switch table.

RFC 911                                                                      21


6. ACKNOWLEDGEMENT

I acknowledge with thanks the many people who have helped me with this project,
but  in  particular,  Dave  Mills,  who  suggested  the project, Jon Postel for
discussion and encouragement, Liza Martin for providing the initial  EGP  code,
Berkeley  for  providing  the  "routed"  code, Mike Brescia for assistance with
testing, Telecom Australia for funding me, and ISI for providing facilities.

RFC 911                                                                      22


7. REFERENCES


[Berkeley 83]   "Unix  Programmer's  Manual",  Vol.  1,  4.2  Berkeley Software
                Distribution, University of California, Berkeley.

[Kirton 84]     Kirton, P.A., "EGP Gateway Under Berkeley Unix 4.2", University
                of  Southern  California,   Information   Sciences   Institute,
                Research Report ISI/RR-84-145, to be published.

[Mills 83]      Mills,  D.L.,  "EGP Models and Self-Organizing Systems" Message
                to EGP-PEOPLE@BBN-UNIX, Nov. 1983.

[Mills 84a]     Mills, D.L., "Exterior Gateway Protocol Formal  Specification",
                Network Information Center RFC 904, April 1984.

[Mills 84b]     Mills,  D.L.,  "Revised  EGP  Model  Clarified  and Discussed",
                Message to EGP-PEOPLE@BBN-UNIX, May 1984.

[Postel 84]     Postel, J., "Exterior Gateway Protocol Implementation Schedule"
                Network Information Center RFC 890, Feb. 1984.

[Rose 84]       Rose, M.T., "Low-Tech Connection into  the  ARPA-Internet:  The
                Raw-Packet   Split  Gateway",  Department  of  Information  and
                Computer Science, University of California,  Irvine,  Technical
                Report 216, Feb. 1984.

[Rosen 82]      Rosen,  E.C.,  "Exterior Gateway Protocol", Network Information
                Center RFC 827, Oct. 1982.

[Seamonson & Rosen 84]
                Seamonson,  L.J.  and  Rosen,  E.C.,  "Stub  Exterior   Gateway
                Protocol", Network Information Center RFC 888, Jan. 84.

[Xerox 81]      "Internet   Transport   Protocols",  Xerox  System  Integration
                Standard XSIS 028112, Dec. 1981.