Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1504

Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing

Pages: 82
Informational
Part 2 of 3 – Pages 30 to 59
First   Prev   Next

Top   ToC   RFC1504 - Page 30   prevText
   A single RI-Upd packet may contain different types of update events-
   for example, several Network Added events and several Network Deleted
   events. For information about update events, see the section
   "Routing-Information Update Events" later in this chapter.

   A data sender should send an RI-Upd packet to an exterior router in
   its informed-routers list only if the packet contains one or more
   update events of a type indicated by the SUI flags of the last Open-
   Req or RI-Req received from that exterior router. Because an RI-Upd
   that contains one or more events of a type requested by an exterior
   router may also contain events of types not requested, an exterior
   router must be able to handle events of all types. Thus, a data
   sender can send an RI-Upd that contains various types of update
   events to all exterior routers that have requested update events of
   any of those types.

   Sending Updates Following the Initial Exchange of Routing Information

   While a data sender has update events pending-that is, when update
   events have occurred but the data sender has not yet sent RI-Upd
   packets for those events-another exterior router may establish a new
   connection with the data sender. The data sender must present
   consistent routing information to all exterior routers on the tunnel,
   on both existing connections and any new connections. For example, if
   a pending update event indicated that a new network had become
   available, the newly connected exterior router could be informed of
   that network's presence on the internet either by

      sending it an RI-Rsp packet including routing information for the
      new network

      sending it an RI-Rsp packet that does not include routing
      information for the new network, then sending it the RI-Upd packet
      that includes the pending update event

   AURP does not specify a scheme for sending update information
   following the initial exchange of routing information on a new
   connection.  However, the Appendix, "Implementation Details,"
   describes one possible method of doing this.

   Using AURP-Tr to Update Routing Information

   The following sections describe the use of AURP-Tr for sending
   routing-information updates.

   ROUTING INFORMATION UPDATE PACKETS: Each RI-Upd packet contains the
   following information:
Top   ToC   RFC1504 - Page 31
   Connection ID:  The connection ID identifies the specific one-way
   connection to which the RI-Upd belongs.

   Sequence number:  The sequence number identifies an individual RI-Upd
   on a connection.

   If an update cannot be contained in one RI-Upd packet, the data
   sender must send a sequence of RI-Upd packets. While the data sender
   need not wait for the duration of an update interval before sending
   each RI-Upd packet in a sequence, it must wait for the data receiver
   to acknowledge that it has received the RI-Upd packet that is
   currently outstanding before sending the next RI-Upd packet in the
   sequence.

   If the data sender sending an RI-Upd does not receive an
   acknowledgment, or RI-Ack, from the data receiver within a specified
   period of time, the data sender should periodically retransmit the
   RI-Upd until it receives an acknowledgment from the data receiver.
   Once the data sender retransmits the RI-Upd a specified number of
   times, if it does not receive an RI-Ack, it should assume that the
   one-way connection on which it is the data sender is down. For more
   information about routers going down, see the section "Using AURP-Tr
   to Detect Routers Going Down" later in this chapter.

   ROUTING INFORMATION ACKNOWLEDGMENT PACKET: When a data receiver
   receives an RI-Upd, it verifies the packet's connection ID and
   sequence number.  The connection ID must be the same as that in the
   Open-Req for the connection. The sequence number must be either:

      the last sequence number received, indicating that the previous
      acknowledgment was lost or delayed, and that this is a duplicate
      RI-Upd

      the next number in the sequence, indicating that the RI-Upd
      contains new routing information

   If the sequence number has any other value, the data receiver ignores
   the RI-Upd. Once the data receiver has verified the RI-Upd packet's
   connection ID and sequence number, it responds by sending a Routing
   Information Acknowledgment packet, or RI-Ack, which contains the
   following information:

   Connection ID:  The connection ID is the same as that in the RI-Upd
   packet.

   Sequence number:  The sequence number is the same as that in the RI-
   Upd packet.
Top   ToC   RFC1504 - Page 32
   Figure 3-12 shows a data receiver responding to an RI-Upd by sending
   an RI-Ack.

    <<Figure 3-12  A routing-information update/acknowledgment dialog>>

   When a data sender receives an RI-Ack, it verifies that the RI-Ack
   corresponds to the outstanding RI-Upd-that is, both packets have the
   same connection ID and sequence number. Once the data sender has
   verified the information in the RI-Ack, it responds by sending the
   next RI-Upd in the sequence, if any.

   Routing-Information Update Events

   An RI-Upd packet may contain any of five different types of routing-
   information update events. The following sections describe these
   events.

   NETWORK ADDED EVENT: An exterior router sends a Network Added (NA)
   event under the following circumstances:

      A new network that appears in the exterior router's routing table
      is in the exterior router's local internet and is not hidden-that
      is, it is an exported network.

      The port through which an exterior router accesses a network
      changes from a tunneling port to another port on the router
      and the network is not hidden.

   If a network in an exterior router's routing table becomes accessible
   across the tunnel, the exterior router does not send an NA event. An
   exterior router sends only split-horizoned routing information to
   other exterior routers on the tunnel.

   An NA event lists the network numbers associated with the new network
   and the network's distance in hops. Another exterior router can
   request the zone information associated with the new network at any
   time by sending a ZI-Req, once it receives an RI-Upd containing an NA
   event for the network.

   When using AURP-Tr, an exterior router can request zone information
   for new networks by setting the SZI bit in an RI-Ack that it sends in
   response to an RI-Upd. If a data sender receives an RI-Ack with its
   SZI flag set to 1, the data sender sends the zone information
   associated with each new network for which it sent an NA event in the
   RI-Upd.

   Figure 3-13 shows a data receiver responding to an RI-Upd by sending
   an RI-Ack in which the SZI bit is set to 1, optimizing the flow of
Top   ToC   RFC1504 - Page 33
   zone information by causing the data sender to respond with a ZI-Rsp.

          <<Figure 3-13  An optimized flow of zone information>>

   NETWORK DELETED EVENT: An exterior router sends a Network Deleted
   (ND) event if an exported network that was formerly accessible
   through its local internet no longer appears in its routing table. An
   ND event lists the network numbers associated with the deleted
   network.

   NETWORK ROUTE CHANGE EVENT: An exterior router sends a Network Route
   Change (NRC) event if the path to an exported network through its
   local internet changes to a path through a tunneling port, causing
   split-horizoned processing to eliminate that network's routing
   information. An NRC event lists the network numbers associated with
   the network to which the path changed.

   NETWORK DISTANCE CHANGE EVENT: An exterior router sends a Network
   Distance Change (NDC) event if the distance to an exported network
   accessible through its local internet changes. An NDC event indicates
   the network to which the distance changed and the network's distance
   in hops. An exterior router must send an NDC event even if the
   distance to a network changes to 15 hops. The exterior router that
   receives an NDC event with a hop count of 15 should process that
   event just as it would an ND event.

   ZONE NAME CHANGE EVENT: This event is reserved for future use.

   Processing Update Events

   According to the architectural model, a data receiver that is
   processing an event contained in an RI-Upd packet updates the
   corresponding information in its central routing table. For example,
   if a data receiver receives an RI-Upd containing an ND event or an
   NRC event, it sets the corresponding network's routing-table entry to
   BAD. The data receiver then initiates a notify-neighbor process, by
   sending RTMP data packets that identify bad entries in its routing
   table to routers on its local internet.

   Processing Inconsistent Update Events

   If the data receiver's copy of the data sender's routing table does
   not match that in the data sender's current routing table, it is
   possible that the data receiver might receive an RI-Upd containing an
   event that is incongruous with its current routing-table information.
   For example, this might occur if the information in the data sender's
   routing table were changing during its initial exchange of routing
   information with the data receiver, as described in the section
Top   ToC   RFC1504 - Page 34
   "Sending Updates Following the Initial Exchange of Routing
   Information" earlier in this chapter. The data receiver might receive
   an RI-Upd that contains an ND, NRC, or NDC event for a network not
   known to be in the data sender's routing table; or an NA event for a
   network already known to be in its routing table. The data receiver
   should

      ignore ND and NRC events for unknown networks

      process an NDC event for an unknown network as an NA event

      process an NA event for a known network as an NDC event

   Maintaining a Central Routing Table

   According to the architectural model, an exterior router maintains a
   separate routing table for each other exterior router on a tunnel. In
   a typical implementation, however, an exterior router maintains a
   central routing table that contains information about each path to
   each network known to that exterior router-including its port, next
   internet router (IR), and distance in hops.

   If no loops exist across a tunnel, an exterior router can reach a
   network that is accessible through that tunnel through only one
   exterior router, as shown in Figure 3-14. Such a network is
   accessible neither through the exterior router's local internet nor
   through any other exterior router on the tunnel. Thus, the central
   routing table would contain only one path for that network.

   If a loop exists across a tunnel, an exterior router may be able to
   access a network through two or more exterior routers on the tunnel,
   or through both its local internet and an exterior router. Thus, when
   a loop exists across a tunnel, the central routing table may contain
   more than one path for each network. Figure 3-14 shows two examples
   of internets on which loops exist.

             <<Figure 3-14  Internets with and without loops>>

   Maintaining an Alternative-Paths List

   If a loop exists across a tunnel and an exterior router maintains a
   single central routing table, that table must include an
   alternative-paths list for each network known to the exterior router.
   This alternative-paths list contains the routing information that an
   exterior router might otherwise maintain in separate routing tables
   for the other exterior routers on a tunnel. An entry for each
   alternative path to a network consists of the address of the
   alternative next IR for that network and the network's distance
Top   ToC   RFC1504 - Page 35
   through that next IR.

   Because RTMP periodically retransmits information about alternative
   paths, the exterior router's alternative-paths list needs to provide
   information only about alternative paths to networks across tunneling
   ports. Thus, the alternative-paths list for a network provides
   complete information about all paths to that network across tunnels-
   but not necessarily about all paths through the exterior router's
   local internet.

   An exterior router must maintain an alternative-paths list, because
   once a data sender has reliably sent routing information to a data
   receiver, the data sender does not retransmit that information. Even
   though a path may not currently be the optimal path to a network, an
   exterior router must maintain information about that path, in the
   event that it later becomes the optimal path.

   NOTE:  Zone information is unaffected by the path taken to a network.
   Therefore, an exterior router need not maintain duplicate zone
   information in the alternative-paths list.

   Using the Alternative-Paths List in Event Processing

   An exterior router uses its alternative-paths list when processing
   events.

   PROCESSING A NETWORK ADDED EVENT: If an exterior router receives an
   NA event, it searches its central routing table for the network
   indicated in the event.

      If the exterior router finds no entry for that network in its
      central routing table, it creates a new entry using the routing
      information contained in the NA event.

      If the exterior router finds an existing entry for that network in
      its central routing table and the next IR for that entry is not
      the exterior router that sent the event, it determines whether the
      NA event provides a better path to that network.

         If the NA event provides a better path to the network or the
         state of the routing-table entry for that network is BAD, the
         exterior router replaces the current entry with the routing
         information contained in the NA event. In the current entry, if
         the path to the network is through a tunnel, as indicated by
         the next IR, the exterior router transfers the current entry to
         the network's alternative-paths list.

         If the NA event does not provide a better path to the network,
Top   ToC   RFC1504 - Page 36
         the exterior router adds the routing information contained in
         the NA event to the alternative-paths list for the network.

      If the exterior router finds an existing entry for that network,
      in which the next IR is the exterior router that sent the event,
      the exterior router should process the NA event just as it would
      an NDC event.

   PROCESSING A NETWORK DELETED EVENT:  If an exterior router receives
   an ND event, it searches its central routing table for the network
   indicated in the event.

      If the exterior router finds no entry for that network in its
      central routing table, it ignores the event. See the section
      "Processing Inconsistent Update Events" earlier in this chapter.

      If the exterior router that is the data receiver determines that
      the exterior router that sent the ND event is the next IR for that
      network and there is an alternative-paths list for the network, the
      data receiver replaces the network's current routing information
      with the entry in the network's alternative-paths list that
      provides the shortest distance to that network and removes that
      entry from the network's alternative-paths list. If the network's
      alternative-paths list contains more than one entry providing the
      distance that constitutes the shortest distance to the network, the
      data receiver can use any of those entries.

      If the exterior router that is the data receiver determines that
      the exterior router that sent the ND event is the next IR for that
      network and there is no alternative-paths list for the network, the
      data receiver sets the network's routing-table entry to BAD, then
      initiates a notify-neighbor process.

      If the exterior router that is the data receiver determines that
      the exterior router that sent the ND event is not the next IR for
      that network, the data receiver searches that network's
      alternative-paths list for an entry in which the next IR is the
      data sender and removes that entry from the list.

   PROCESSING A NETWORK ROUTE CHANGE EVENT: If an exterior router
   receives an NRC event, it processes that event as an ND event.
   Generally, an NRC event should not cause an exterior router to set
   the state of a network's routing-table entry to BAD. An NRC event
   indicates that the data sender has an alternative path to the network
   through the tunnel.  The data receiver either is already aware of or
   will soon discover this alternative path.
Top   ToC   RFC1504 - Page 37
   PROCESSING A NETWORK DISTANCE CHANGE EVENT: If an exterior router
   receives an NDC event with a hop count of 15, it processes that event
   just as it would an ND event. Otherwise, it searches its central
   routing table for the network indicated in the event.

      If the exterior router finds no entry for that network in its
      central routing table, it processes that event as an NA event.

      If the exterior router that is the data receiver determines that
      the exterior router that sent the NDC event is the next IR for the
      network, the data receiver replaces the distance to that network
      that is currently in its central routing table with the distance
      indicated in the NDC event.

      If the exterior router that is the data receiver determines that
      the exterior router that sent the NDC event is not the next IR for
      the network, the data receiver

      replaces the distance in the corresponding entry in the network's
      alternative-paths list with the distance indicated in the NDC event
      creates an entry in the alternative-paths list that contains the
      routing information in the NDC event, if it finds no entry for that
      network in the alternative-paths list

   Finally, regardless of whether the central routing table indicates
   that the exterior router that sent the NDC event is the network's
   next IR, the data receiver compares the distances in entries in the
   network's alternative-paths list to the distance in its central
   routing table. If an entry in the alternative-paths list contains a
   shorter path to the network, the exterior router transfers that entry
   to the central routing table. This ensures that the exterior router's
   central routing table contains the shortest path to the network.

      If the data receiver replaces the entry currently in its central
      routing table with that in the NDC event and the current entry
      provides a path to the network through a tunnel, the data receiver
      transfers the current entry to the network's alternative-paths
      list.

      If the data receiver transfers an entry in the network's
      alternative-paths list to its central routing table, it removes
      that entry from the alternative-paths list.

   RESPONDING TO EVENTS IN THE LOCAL INTERNET: An exterior router that
   uses AURP must respond appropriately to events that originate in its
   local internet. Such events occur when the routing information for a
   network in the exterior router's local internet changes and another
   path to that network exists through the tunnel. An exterior router
Top   ToC   RFC1504 - Page 38
   handles such events as follows:

      If the exterior router replaces the current routing-table entry for
      a network with routing information provided by an event originating
      in its local internet-that is, provided by RTMP-and the current
      path to the network is through a tunnel, the exterior router
      transfers the current entry to the network's alternative-paths
      list.

      If the exterior router sets the state of a routing-table entry to
      BAD or removes an entry from its central routing table, the
      exterior router replaces that entry with the entry in the
      alternative-paths list that provides the shortest distance to the
      network in the entry being replaced.

      If the distance to a network in the exterior router's local
      internet changes, the exterior router compares the distances in
      entries in the network's alternative-paths list to the distance in
      its central routing table. If an entry in the alternative-paths
      list provides a shorter distance to the network, the exterior
      router transfers that entry to its central routing table. This
      ensures that the exterior router's central routing table contains
      the shortest path to the network.

   Router-Down Notification

   Prior to going down, or becoming inactive, an exterior router must
   notify all other exterior routers in its informed-routers list that
   it is going down. An exterior router does this by using the
   underlying transport-layer service to close its connection with each
   exterior router.

   Sending a Router Down Packet

   Optionally, an exterior router can send a Router Down packet, or RD
   packet, to each exterior router before it goes down. An RD packet
   contains an error code that indicates the exterior router's reason
   for terminating its connection with each exterior router.

   Generally, only the exterior router functioning as the data sender on
   a one-way connection sends RD packets. However, if just a single
   one-way connection exists between two exterior routers, the exterior
   router functioning as the data receiver on that connection can send
   an RD packet.

   Using AURP-Tr to Notify Other Routers That a Router Is Going Down

   When using AURP-Tr, an exterior router sends an RD packet to
Top   ToC   RFC1504 - Page 39
      notify another exterior router that it is terminating a connection

      pass an error code that indicates its reason for terminating the
      connection

   As shown in Figure 3-15, once the data receiver verifies the RD
   packet's connection ID, it acknowledges that it received the RD
   packet by sending an RI-Ack. Then, the data sender terminates the
   connection.

                <<Figure 3-15  Acknowledging an RD packet>>

   If a Router Goes Down Without Notifying Other Routers

   If an exterior router crashes or goes down without sending an RD
   packet, or becomes inaccessible due to a network problem, other
   exterior routers on the tunnel must be able to discover that the
   exterior router is down.  Generally, the underlying transport-layer
   service provides a mechanism for informing an exterior router that an
   exterior router in its informed-routers list has gone down or become
   inaccessible.

   If an exterior router determines that another exterior router is
   down, it must

      remove that exterior router from its informed-routers list

      remove that exterior router's routing information from all of its
      routing tables

      close any one-way connections with that exterior router

   If an exterior router rediscovers an exterior router that had
   previously gone down, it must again exchange initial routing
   information with that exterior router.

   Using AURP-Tr to Detect Routers Going Down

   An exterior router using AURP-Tr associates a last-heard-from timer
   with each exterior router from which it has received routing
   information-that is, with each one-way connection on which it is the
   data receiver. Each time the exterior router receives an RI-Rsp, RI-
   Upd, or ZI-Rsp over a connection-verifying that its connection with
   the data sender is still active-it resets the last-heard-from timer
   for that connection.

   For each one-way connection on which it is the data receiver, the
   exterior router has a last-heard-from timeout value. If a
Top   ToC   RFC1504 - Page 40
   connection's last-heard-from timer reaches that timeout value, the
   data receiver sends a Tickle packet over that connection. If the data
   sender on the connection is still accessible, it responds with a
   Tickle-Ack, as shown in Figure 3-16. When the data receiver receives
   the Tickle-Ack, it resets the last-heard-from timer for that
   connection. If the data receiver receives no Tickle-Ack-even after
   retransmitting the Tickle several times-it assumes that the
   connection is down.

              <<Figure 3-16  Acknowledging a Tickle packet>>

   If the exterior router determines that the connection is down and an
   associated one-way connection exists on which it is the data sender,
   it should send a null RI-Upd over that connection to determine
   whether that one-way connection is still active.

   If the data receiver on the connection is still accessible, it
   responds with an RI-Ack, as shown in Figure 3-17. If the data sender
   receives no RI-Ack-even after retransmitting the null RI-Upd several
   times-it determines that the one-way connection on which it is the
   data sender is also down.

              <<Figure 3-17  Acknowledging an RI-Upd packet>>

   The value of the last-heard-from timeout should be configurable. The
   minimum last-heard-from timeout should be 30 seconds. If a
   connection's last-heard-from timeout is greater than two minutes-the
   tickle-before-data time-and the data receiver has not reset the
   connection's last-heard-from timer for at least this tickle-before-
   data time, the data receiver must send a Tickle to the data sender
   before forwarding an AppleTalk data packet to it. If the data sender
   on the connection is still accessible, it responds with a Tickle-Ack.
   When the data receiver receives the Tickle-Ack, it resets the last-
   heard-from timer for that connection. If the data receiver receives
   no Tickle-Ack, even after retransmitting the Tickle, it assumes that
   the data sender is no longer accessible and closes the connection.

   Obtaining Zone Information

   AURP supports two commands that allow an exterior router to obtain
   routing information for zones rather than for networks-the Get Domain
   Zone List (GDZL) command and the Get Zone Nets (GZN) command. These
   commands constitute request/response transactions, and are similar to
   ZI-Req and ZI-Rsp. An exterior router sends these commands
   unsequenced over a connection.

   NOTE:  Under AURP, the implementation of the Get Domain Zone List
   command and the Get Zone Nets command in an exterior router is
Top   ToC   RFC1504 - Page 41
   optional.  However, an exterior router must at least be able to
   return an error to a GDZL-Req or a GZN-Req.

   Get Domain Zone List Command

   The Get Domain Zone List command, or GDZL, allows an exterior router
   to obtain a zone list for an internet. As shown in Figure 3-18, GDZL
   functions similarly to the ZIP GetZoneList command. However, a GDZL-
   Rsp returns a split-horizoned zone list-that is, it returns only the
   zones in the exterior router's local internet, rather than the
   exterior router's entire zone list. A GDZL-Rsp does not return zones
   in networks that are accessible through the tunnel, unless those
   zones are also in networks that are accessible through the exterior
   router's local internet.

       <<Figure 3-18  Get Domain Zone List request/response dialog>>

   Get Zone Nets Command

   The Get Zone Nets command, or GZN, allows an exterior router to
   obtain a list of the networks in an exterior router's local internet
   that are associated with a particular zone name. As shown in Figure
   3-19, GZN functions similarly to ZI-Req and ZI-Rsp, but a GZN-Req
   packet contains a single zone name and GZN-Rsp packets contain
   network tuples that have the same format as the tuples in an RI-Rsp.
   A GZN-Rsp returns network tuples only for networks that are
   accessible through the exterior router's local internet.

          <<Figure 3-19  Get Zone Nets request/response dialog>>

   Using AURP-Tr to Process Sequence Numbers

   When an exterior router acting as a data receiver sends an Open-Req
   to establish a one-way connection, it expects the data sender to
   respond by sending sequenced data packets, starting with the sequence
   number 1. The data receiver's response to each packet that it
   receives depends on the packet's sequence number:

     Whenever the data receiver receives an RI-Rsp, RI-Upd, or RD packet
     that has the expected sequence number and connection ID, it sends
     an RI-Ack packet having that sequence number, then increases the
     sequence number that it expects by one, until the sequence number
     reaches 65,535. Sequence numbers wrap around and the sequence
     number 0 is reserved, so the sequence number 1 follows 65,535.
     Thus, when comparing sequence numbers, an exterior router
     interprets the sequence number 65,535 as one less than the sequence
     number 1.
Top   ToC   RFC1504 - Page 42
     If the data receiver expects sequence number n and receives a
     packet with the sequence number n-1, that packet was delayed and is
     a duplicate of another packet already received. The data receiver
     must retransmit an RI-Ack packet, because the data sender may not
     have received the RI-Ack packet previously sent-that is, the RI-Ack
     may have been lost.

     If the data receiver expects sequence number n and receives a
     packet with the sequence number n+1, it should discard the packet
     and terminate the one-way connection on which it is the data
     receiver.  Because AURP-Tr supports only one outstanding
     transaction at a time, the receipt of such a packet indicates that
     the connection is out of sync.

     If the data receiver expects sequence number n and receives a
     packet with a sequence number other than n-1, n, or n+1, the packet
     was delayed and is a duplicate of another packet already received.
     The data receiver need not send an RI-Ack, because the data sender
     must have received an RI-Ack for that sequence number prior to
     sending a packet with the sequence number n-1. The data receiver
     should discard the packet.

   NOTE:  If the sequence numbers have not wrapped around, a sequence
   number greater than n+1 indicates that the connection is out of sync.

   Using AURP-Tr to Process Connection IDs

   If an exterior router acting as either a data receiver or a data
   sender on a one-way connection receives a packet from an exterior
   router with which it has a one-way connection, it checks the
   connection ID in the packet to verify that the packet was sent on
   that connection. If the packet contains a connection ID that does not
   match that expected for the connection, the exterior router discards
   the packet.

   If a data sender receives an Open-Req from an exterior router with
   which it already has a connection and the connection ID does not
   match that for the connection already established, it should not
   discard the packet without verifying whether the connection is still
   active. The receipt of such a packet may indicate that the data
   receiver on the connection has been restarted and has opened a new
   one-way connection, without first terminating its original
   connection. The exterior router acting as the data sender should send
   a null RI-Upd over the connection to determine whether it is still
   active. If the data sender receives an RI-Ack in response to the null
   RI-Upd, it discards the Open-Req and the original connection remains
   active. If the data sender receives no RI-Ack after retransmitting
   the null RI-Upd, it closes the original connection, then sends an
Top   ToC   RFC1504 - Page 43
   Open-Rsp to the next Open-Req received.

   NOTE:  An exterior router can act as the data sender on only a single
   one-way connection between itself and a given exterior router.  That
   is, multiple one-way connections in the same direction cannot exist
   between two exterior routers.

   When establishing a one-way connection with a given data sender, a
   data receiver using AURP-Tr must send an Open-Req that has a
   different connection ID from that used in its last connection with
   the data sender. Otherwise, if the last connection to the data sender
   had terminated abnormally and the new connection used the same
   connection ID, the data sender might determine that the last
   connection was still active and interpret the Open-Req as a
   retransmission of the Open-Req for the last connection. The data
   sender might respond to the Open-Req by sending an Open-Rsp or ignore
   the Open-Req, but would not open a new connection.

   If a data receiver's implementation of AURP-Tr cannot guarantee the
   use of different connection IDs on successive connections with a
   given data sender, the data receiver must send an RI-Req immediately
   after it establishes a connection with a data sender. If the data
   sender already has a connection with the data receiver, it will send
   an RI-Rsp with a sequence number other than 1. The data receiver
   should then terminate that connection and open a new connection using
   a different connection ID.

   Using Retransmission Timers Under AURP-Tr

   When an AppleTalk tunnel exists through a foreign network's internet,
   the delay and loss characteristics of the tunnel's underlying foreign
   network system complicate the setting of retransmission timers. A
   physical connection can be built between two exterior routers using
   different media-for example, a single Ethernet LAN, a fast point-to-
   point link, an IP internet, or a slow link over an asynchronous
   modem.  It is important to minimize performance degradation due to

      packets being dropped or delayed by the underlying foreign network
      system

      the inefficient use of the underlying foreign network system's
      resources due to excessive retransmissions

   Most higher-level transport-layer services provide guaranteed packet
   delivery. It is not necessary to retransmit AURP packets when using
   such transport-layer services. When using AURP-Tr, an exterior router
   should employ an adaptive retransmission algorithm whenever possible.
   An adaptive retransmission strategy like that used in TCP
Top   ToC   RFC1504 - Page 44
      maintains the estimated times required to send a packet and receive
      an acknowledgment-that is, average round-trip times

      maintains standard deviations from the average round-trip times

      derives retransmission timers from the average round-trip times
      While AURP does not specify an adaptive retransmission algorithm,
      the use of such an algorithm is recommended.

   NOTE:  Often, long intervals exist between AURP packets sent
   successively on a connection by an exterior router-for example,
   between RI-Upd packets. Therefore, an adaptive retransmission
   algorithm used with AURP should give more weight to packets sent
   recently over a connection than would be appropriate for a general
   data-stream protocol like TCP.

   When an exterior router initially opens a connection, no transaction
   history is available. It is recommended that the retransmission
   algorithm use a truncated, exponential backoff scheme for the initial
   Open-Req sequence, because the exterior router with which the data
   receiver is establishing a connection may be inaccessible or down. An
   exterior router should not retransmit an Open-Req at a rate faster
   than once every two seconds.

   Hiding Local Networks From Remote Networks

   As described in the section "Hiding Local Networks From Tunnels" in
   Chapter 2, a network administrator can configure an exterior router
   to hide specific networks in its local internet from networks
   connected to other exterior routers on the tunnel. When exchanging
   routing information with other exterior routers on the tunnel, the
   exterior router exports no routing information for hidden networks in
   its local internet to exterior routers from which those networks are
   hidden.

   An exterior router using AURP does not include routing information
   for hidden networks in RI-Rsp, RI-Upd, or GZN-Rsp packets sent to
   exterior routers from which those networks are hidden. The exterior
   router also excludes from GDZL-Rsp packets any zones that appear only
   in the zone lists of hidden networks.

   To maintain network-level security, an exterior router should discard
   any AppleTalk data packet sent to a network in its local internet by
   an exterior router from which that network is hidden.

   NOTE:  An exterior router hides a network by excluding the routing
   information for that network from RI-Rsp, RI-Upd, GZN-Rsp, and GDZL-
   Rsp packets. However, network management packets-such as RTMP Route
Top   ToC   RFC1504 - Page 45
   Data Response (RDR) packets that are not split horizoned, and Simple
   Network Management Protocol (SNMP) packets-should include the routing
   information for hidden networks. For detailed information about the
   effects of AURP on network management, see the section "Network
   Management" in Chapter 4.

   AURP Packet Format

   An exterior router encapsulates both AURP packets and AppleTalk data
   packets using the same headers. Before forwarding AURP packets across
   a tunnel, an exterior router encapsulates the AURP packets in packets
   of the tunnel's underlying foreign network system-by adding the
   headers required by that network system. For more information about
   these headers, see the sections "Forwarding Data," "AppleTalk Data-
   Packet Format," and "AppleTalk Data-Packet Format for IP Tunneling"
   in Chapter 2.

   When using AURP-Tr in conjunction with TCP/IP, an exterior router
   encapsulates AURP packets in UDP packets prior to forwarding them
   across an IP tunnel through UDP port 387. When another exterior
   router on the tunnel receives the UDP packets at UDP port 387, it
   decapsulates the packets.

   Domain Headers in AURP Packets

   When forwarding AURP packets across a tunnel, an exterior router adds
   a domain header immediately preceding each packet. A domain header
   contains additional addressing information, including its source
   domain identifier and destination domain identifier (DI). The last
   two bytes of the domain header are set to 0003, indicating that the
   packet is an AURP packet rather than an AppleTalk packet. AURP data
   follows the domain header. Figure 3-20 shows the protocol headers,
   the domain header, and the routing data header that encapsulate a
   routing data packet sent across an IP tunnel.

          <<Figure 3-20  A routing data packet on an IP tunnel>>

   An exterior router interprets the domain identifiers in the domain
   header of an AURP packet differently from those in the domain headers
   of an AppleTalk data packet. Only network entities with AppleTalk
   addresses have domain identifiers associated with them. Exterior
   routers do not have AppleTalk addresses on the tunnel-thus, they do
   not have true domain identifiers.

   DESTINATION DOMAIN IDENTIFIER: The destination DI in an AURP packet's
   domain header is the DI that is associated with any network numbers
   corresponding to networks that reside in the receiving exterior
   router's domain. Only ZI-Req packets include such network numbers.
Top   ToC   RFC1504 - Page 46
   Whenever possible, a domain header should specify a destination DI-
   that is, the DI for the networks that reside in the domain of the
   exterior router that is to receive the packet. When an exterior
   router sends an Open-Req to open a connection, the destination DI is
   not yet known.  However, under the current version of AURP, the
   exterior router can either derive the destination DI from the
   destination's IP address or, on point-to-point links, include the
   null DI.

   SOURCE DOMAIN IDENTIFIER: The source DI in an AURP packet's domain
   header is the DI that is associated with any network numbers
   corresponding to networks that reside in the sending exterior
   router's domain. RI-Rsp, RI-Upd, ZI-Rsp, and GZN-Rsp packets include
   such network numbers. A domain header should always specify a source
   DI-that is, the DI for the networks that reside in the domain of the
   exterior router that is sending the packet.

   Routing Data Headers in AURP Packets

   The routing data header that immediately precedes the AURP data in a
   routing data packet consists of an AURP-Tr header and an AURP header.
   The AURP-Tr header consists of the following fields:

   Connection ID:  The contents of this two-byte field identify the
   specific one-way connection to which a packet belongs.

   Sequence number:  The contents of this two-byte field identify an
   individual packet on a connection.

   The AURP header consists of these fields:

   Command code:  This two-byte field identifies the command type. For
   information about command types, see the next section, "Command
   Types."

   Flags:  This two-byte field may contain different flags, depending on
   the command code. For information about flags, see the section
   "Routing Flags" later in this chapter.

   Command Types

   AURP defines the command types shown in Table 3-1:
Top   ToC   RFC1504 - Page 47
                         Table 3-1  Command types

                                                          Command
   Command type                           Abbreviation    code   Subcode

   Routing Information Request            RI-Req          1      -
   Routing Information Response           RI-Rsp          2      -
   Routing Information Acknowledgment     RI-Ack          3      -
   Routing Information Update             RI-Upd          4      -
   Router Dow                             RD              5      -
   Zone Information Request               ZI-Req          6      1
   Zone Information Response              ZI-Rsp          7      1 and 2
   Get Zones Net Request                  GZN-Req         6      3
   Get Zones Net Response                 GZN-Rsp         7      3
   Get Domain Zone List Request           GDZL-Req        6      4
   Get Domain Zone List Response          GDZL-Rsp        7      4
   Open Request                           Open-Req        8      -
   Open Response                          Open-Rsp        9      -
   Tickle                                 -               14     -
   Tickle Acknowledgment                  Tickle-Ack      15     -

   Routing Flags

   AURP defines the flags shown in Table 3-2. All other flags are
   reserved.  A data sender should set reserved flags to 0. A data
   receiver should ignore reserved flags.

                             Table 3-2  Flags

   Flag                                Event      Command types       Bit

   Send update information (SUI) flag  NA         Open-Req and RI-Req 14
   Send update information (SUI) flag  ND and NRC Open-Req and RI-Req 13
   Send update information (SUI) flag  NDC        Open-Req and RI-Req 12
   Send update information (SUI) flag  ZC         Open-Req and RI-Req 11
   Last flag                           -          RI-Rsp and GDZL-Rsp 15
   Remapping active flag               -          Open-Rsp            14
   Hop-count reduction active flag     -          Open-Rsp            13
   Reserved environment flags          -          -                   12
                                                                  and 11
   Send zone information (SZI) flag    -          RI-Ack              14

   Figure 3-21 shows the routing flags in Open-Req and RI-Req packets.

       <<Figure 3-21  Routing flags in Open-Req and RI-Req packets>>

   Figure 3-22 shows the routing flags in all packets other than Open-
   Req and RI-Req packets.
Top   ToC   RFC1504 - Page 48
              <<Figure 3-22  Routing flags in other packets>>

   Open Request Packet

   An Open-Req packet initiates the establishment of a one-way
   connection with a data sender. Figure 3-23 shows the format of an
   Open-Req packet.  When sending an Open-Req packet, an exterior router
   inserts the next available connection ID in the packet's AURP-Tr
   header and sets its sequence number to 0. The AURP header of an
   Open-Req contains the command code 8. Its flag bytes contain send
   update information (SUI) flags. For the current version of AURP, the
   version number is 1.

   An Open-Req packet's option data field contains

      an option count-indicating the number of option tuples to follow

      the option tuples

   When the data sender receives an Open-Req, it can discard the option
   tuples for any options it does not implement. For information about
   option tuples, see the section "Option Tuples" later in this chapter.

                  <<Figure 3-23  Open-Req packet format>>

   Open Response Packet

   When the data sender receives an Open-Req, it responds by sending an
   Open-Rsp packet to establish a one-way connection with the data
   receiver. Figure 3-24 shows the format of an Open-Rsp packet. In its
   AURP-Tr header, an Open-Rsp packet contains the connection ID from
   the associated Open-Req packet and the sequence number 0. The AURP
   header of an Open-Rsp contains the command code 9 and its flag bytes
   contain environment flags that provide information about the data
   sender's environment-such as whether network-number remapping or
   hop-count reduction is active. For information about network-number
   remapping and hop-count reduction, see the sections "Network-Number
   Remapping" and "Hop-Count Reduction," respectively, in Chapter 4.

                  <<Figure 3-24  Open-Rsp packet format>>

   An Open-Rsp packet's option data field contains

      a two-byte field that indicates either
         the nominal rate at which the data sender sends updates-in
         multiples of ten seconds
         an error code-which is a negative number-if the data sender
         cannot accept the connection
Top   ToC   RFC1504 - Page 49
      an option count-indicating the number of option tuples to follow

      the option tuples

   For information about error codes, see the section "Error Codes"
   later in this chapter. For information about option tuples, see the
   next section, "Option Tuples."

   Option Tuples

   Both Open-Req and Open-Rsp packets contain option tuples. An option
   tuple contains a one-byte length field that indicates the length of
   the remainder of the tuple, a one-byte type code, and an optional
   data field, as shown in Figure 3-25.

                      <<Figure 3-25  Option tuples>>

   AURP currently defines the option-type codes shown in Table 3-3:

                       Table 3-3  Option-type codes

   Option types                Type codes

   Authentication              1
   Reserved for future use     2-255

   Routing Information Request Packet

   An RI-Req packet requests the data sender to send RI-Rsp packets.
   Figure 3-26 shows the format for an RI-Req packet. When sending an
   RI-Req packet, an exterior router inserts the connection ID for the
   connection on which it is the data receiver in the packet's AURP-Tr
   header and sets the packet's sequence number to 0. The AURP header of
   an RI-Req contains the command code 1 and its flag bytes contain the
   send update information (SUI) flags.

                   <<Figure 3-26  RI-Req packet format>>

   Routing Information Response Packet

   When the data sender receives an RI-Req, it responds by sending a
   sequence of RI-Rsp packets. Figure 3-27 shows the format of an RI-Rsp
   packet. When sending an RI-Rsp packet, a data sender inserts the
   connection ID from the associated RI-Req in the RI-Rsp packet's
   AURP-Tr header and sets its sequence number to the next number in the
   sequence.  The AURP header of an RI-Rsp packet contains the command
   code 2. In the last packet in a sequence of RI-Rsp packets, the
Top   ToC   RFC1504 - Page 50
   last-flag bit is set to 1.

                   <<Figure 3-27  RI-Rsp packet format>>

   An RI-Rsp packet's routing data field contains zero or more routing
   tuples, which have a format similar to those in RTMP packets. An AURP
   tuple for a nonextended network is different from an RTMP tuple for
   an extended network in one respect-the range flag, or the sixth byte,
   in an AURP tuple for a nonextended network is set to 0. Figure 3-28
   shows nonextended and extended network tuples in an RI-Rsp packet.

         <<Figure 3-28  Nonextended and extended network tuples>>

   Routing Information Acknowledgment Packet

   When a data receiver receives an RI-Rsp, RI-Upd, or RD packet, it
   responds by sending an RI-Ack packet. Figure 3-29 shows the format of
   an RI-Ack packet. When sending an RI-Ack packet, a data receiver
   inserts the connection ID and sequence number from the associated
   RI-Rsp, RI-Upd, or RD packet in the RI-Ack packet's AURP-Tr header.
   The AURP header of an RI-Ack contains the command code 3. If the data
   receiver sends an RI-Ack using AURP-Tr, in response to an RI-Rsp or
   RI-Upd packet that contains an NA event, its flag bytes contain the
   send zone information flag. An RI-Ack packet contains no data.

                   <<Figure 3-29  RI-Ack packet format>>

   Routing Information Update Packet

   The occurrence of specified events requires the data sender to send
   an RI-Upd packet. Figure 3-30 shows the format of an RI-Upd packet.
   When sending an RI-Upd packet, a data sender inserts the connection
   ID for the current connection in the RI-Upd packet's AURP-Tr header
   and sets its sequence number to the next number in the sequence. The
   AURP header of an RI-Upd contains the command code 4 and its flag
   bytes are set to 0.

                   <<Figure 3-30  RI-Upd packet format>>

   An RI-Upd packet's data field contains one or more event tuples. An
   event tuple for a nonextended network consists of a one-byte event
   code, the network number, and the distance to that network. An event
   tuple for an extended network consists of a one-byte event code, the
   first network number in the range of network numbers, the distance to
   the network, and the last network number in the range of network
   numbers. Figure 3-31 shows nonextended and extended network tuples in
   an RI-Upd packet.
Top   ToC   RFC1504 - Page 51
      <<Figure 3-31  Nonextended and extended network event tuples>>

   AURP currently defines the event codes shown in Table 3-4:

                          Table 3-4  Event codes

   Event                             Abbreviation     Event code

   Null event                                         0
   Network Added event               NA               1
   Network Deleted event             ND               2
   Network Route Change event        NRC              3
   Network Distance Change event     NDC              4
   Zone Change event                 ZC               5

   A null event tuple contains no event data. The format of NA, ND, NRC,
   and NDC event tuples differs, depending on whether the event pertains
   to a nonextended or an extended network. The distance field does not
   apply to ND or NRC event tuples and should be set to 0. The ZC event
   tuple is not yet defined.

   An RI-Upd packet should never contain two events that pertain to the
   same network. However, to ensure consistent behavior in the event
   that an exterior router receives a packet containing multiple events
   for one network, an exterior router should always process events in
   the order in which they occur in the RI-Upd packet. Thus, if an
   exterior router were to receive an RI-Upd that contained an NA event,
   then an ND event for the same network, the exterior router would
   delete the network from its routing table.

   Router Down Packet

   An exterior router should send an RD packet before it goes down.
   Figure 3-32 shows the format of an RD packet. When sending an RD
   packet, an exterior router inserts the connection ID for the current
   connection in the RD packet's AURP-Tr header. If the data sender
   sends an RD packet, it sets its sequence number to the next number in
   the sequence. If the data receiver sends an RD packet, it sets its
   sequence number to 0. The AURP header of an RD packet contains the
   command code 5 and its flag bytes are set to 0.

                     <<Figure 3-32  RD packet format>>

   An RD packet's data field contains a two-byte error code that
   indicates the exterior router's reason for going down. For
   information about the error codes, see the section "Error Codes"
   later in this chapter.
Top   ToC   RFC1504 - Page 52
   Zone Information Request/Response Transactions

   An exterior router returns information about its zones through
   request/response transactions. Three types of zone requests-ZI-Req,
   GDZL-Req, and GZN-Req-share the same command code and have subcodes
   that indicate the actual request type. Three types of zone
   responses-ZI-Rsp, GDZL-Rsp, and GZN-Rsp-share another command code
   and have subcodes that indicate the actual response type.

   ZONE INFORMATION REQUEST PACKET: A ZI-Req packet causes the data
   sender to send ZI-Rsp packets. Figure 3-33 shows the format of a ZI-
   Req packet.  When sending a ZI-Req packet, an exterior router inserts
   the connection ID for the connection on which it is the data receiver
   in the packet's AURP-Tr header and sets the packet's sequence number
   to 0. The AURP header of a ZI-Req contains the command code 6 and its
   flag bytes are set to 0.

                   <<Figure 3-33  ZI-Req packet format>>

   A ZI-Req packet's data field contains the subcode 1 and a two-byte
   network number for each network about which the exterior router is
   requesting zone information. The network number for an extended
   network is the first network number in its range of network numbers.

   ZONE INFORMATION RESPONSE PACKET: There are two types of ZI-Rsp
   packets-nonextended ZI-Rsp packets and extended ZI-Rsp packets. The
   format of a nonextended ZI-Rsp packet is similar to that of a
   nonextended AppleTalk ZIP Reply packet. When the data sender receives
   a ZI-Req and the zone list for the network or networks for which that
   ZI-Req requested zone information fits in one ZI-Rsp packet, it sends
   a nonextended ZI-Rsp.

   An extended ZI-Rsp packet is similar to an extended AppleTalk ZIP
   Reply packet. When the data sender receives a ZI-Req and the zone
   list for a network about which that ZI-Req requested zone information
   does not fit in a single ZI-Rsp packet, it sends a sequence of
   extended ZI-Rsp packets.

   Figure 3-34 shows the format of a ZI-Rsp packet. When sending a ZI-
   Rsp packet, a data sender inserts the connection ID from the
   associated ZI-Req packet in the packet's AURP-Tr header and sets the
   packet's sequence number to 0. A ZI-Rsp packet's AURP header contains
   the command code 7 and its flag bytes are set to 0. The subcode 1
   indicates a nonextended ZI-Rsp packet, while the subcode 2 indicates
   an extended ZI-Rsp packet.

                   <<Figure 3-34  ZI-Rsp packet format>>
Top   ToC   RFC1504 - Page 53
   A ZI-Rsp packet's data field contains the requested zone information.
   Its format is similar to that of a ZIP Reply packet.

   In a nonextended ZI-Rsp packet, the first two bytes of the data field
   should indicate the number of tuples contained in the packet, while
   the remaining bytes constitute network number/zone name tuples.
   Within the packet, all of the tuples for a given network must be
   contiguous.  NOTE:  When sending a nonextended ZI-Rsp packet, an
   exterior router should attempt to specify the correct number of zone
   tuples. However, an exterior router receiving a nonextended ZI-Rsp
   packet should process all tuples contained in the packet, regardless
   of the number indicated in the header.

   Network number/zone name tuples in a nonextended ZI-Rsp packet can
   use either the long tuple format or the optimized tuple format. A
   long network number/zone name tuple contains a network number,
   followed by the length of the zone name, and the zone name.

   Using the optimized tuple format, an exterior router can compress a
   nonextended ZI-Rsp packet in which more than one network contains the
   same zone name in its zone list. If the high-order bit of the length
   byte for a given zone name is set to 1, the following 15 bits
   represent an offset from the length byte of the first zone name in
   the packet's data field to the actual location of the zone name
   length and the zone name. Whenever possible, it is recommended that
   an exterior router send optimized ZI-Rsp packets. All exterior
   routers must be able to receive optimized ZI-Rsp packets.

   In an extended ZI-Rsp packet, the first two bytes of the data field
   indicate the total number of tuples in the zone list for the network
   or networks for which the corresponding ZI-Req requested zone
   information.  The remaining bytes in the data field of an extended
   ZI-Rsp packet consist of network number/zone name tuples. All tuples
   in a single extended ZI-Rsp packet must contain the same network
   number. However, for consistency with the format of network
   number/zone name tuples in nonextended ZI-Rsp packets, the network
   number precedes each zone name in an extended ZI-Rsp packet.
   Duplicate zone names never exist in extended ZI-Rsp packets-
   therefore, extended ZI-Rsp packets use the long tuple format, rather
   than the optimized tuple format.

   Figure 3-35 shows the long tuple and optimized tuple formats for a
   ZI-Rsp packet.

             <<Figure 3-35  Long and optimized tuple formats>>

   GET DOMAIN ZONE LIST REQUEST PACKET: A Get Domain Zone List Request
   packet, or GDZL-Req, requests the data sender to send GDZL-Rsp
Top   ToC   RFC1504 - Page 54
   packets.  Figure 3-36 shows the format for a GDZL-Req packet. When
   sending a GDZL-Req packet, an exterior router inserts the connection
   ID for the connection on which it is the data receiver in the
   packet's AURP-Tr header and sets its sequence number to 0. The AURP
   header of a GDZL-Req contains the command code 6 and its flag bytes
   are set to 0.

                  <<Figure 3-36  GDZL-Req packet format>>

   A GDZL-Req packet's data field contains the subcode 4 and the start
   index in the data sender's zone list at which to begin returning
   GDZL-Rsp packets.

   GET DOMAIN ZONE LIST RESPONSE PACKET: When the data sender receives a
   GDZL-Req, it responds by sending a GDZL-Rsp packet. Figure 3-37 shows
   the format of a GDZL-Rsp packet. When sending a GDZL-Rsp packet, a
   data sender inserts the connection ID from the associated GDZL-Req
   packet in the packet's AURP-Tr header and sets its sequence number to
   0. The AURP header of a GDZL-Rsp contains the command code 7 and its
   flag bytes are set to 0, except in the last packet containing zone
   information, which has its last flag set to 1.

                  <<Figure 3-37  GDZL-Rsp packet format>>

   A GDZL-Rsp packet's data field contains the subcode 4, the start
   index from the associated GDZL-Req, and the zone list. If the data
   sender does not support the GDZL-Req, it should set the start index
   to -1.

   GET ZONES NET REQUEST PACKET: A Get Zones Net Request packet, or
   GZN-Req, requests the data sender to send zone information for one
   specific zone. Figure 3-38 shows the format of a GZN-Req packet. When
   sending a GZN-Req packet, an exterior router inserts the connection
   ID for the connection on which it is the data receiver in the
   packet's AURP-Tr header and sets its sequence number to 0. The AURP
   header of a GZN-Req contains the command code 6 and its flag bytes
   are set to 0.

                  <<Figure 3-38  GZN-Req packet format>>

   A GZN-Req packet's data field contains the subcode 3 and the name of
   the zone about which the GZN-Req is requesting zone information.

   GET ZONES NET RESPONSE PACKET: When the data sender receives a GZN-
   Req, it responds by sending a GZN-Rsp packet, containing the
   requested zone information. Figure 3-39 shows the format of a GZN-Rsp
   packet. When sending a GZN-Rsp packet, a data sender inserts the
   connection ID from the associated GZN-Req packet in the GZN-Rsp
Top   ToC   RFC1504 - Page 55
   packet's AURP-Tr header and sets the GZN-Rsp packet's sequence number
   to 0. The AURP header of a GZN-Rsp contains the command code 7 and
   its flag bytes are set to 0.

                  <<Figure 3-39  GZN-Rsp packet format>>

   A GZN-Rsp packet's data field contains the subcode 3, the zone name
   from the associated GZN-Req, the total number of network tuples for
   that zone, and as many network tuples as can fit in the packet. These
   tuples have the same format as those in RI-Rsp packets. If the data
   sender has no information about the zone, it returns a GZN-Rsp in
   which the number of network tuples is 0. If the data sender does not
   support the GZN-Req, it should set the number of network tuples to
   -1.

   TICKLE PACKET: The data receiver sends a Tickle packet to verify that
   the data received from the data sender is still valid. Figure 3-40
   shows the format of a Tickle packet. When sending a Tickle packet, an
   exterior router inserts the connection ID for the connection on which
   it is the data receiver in the packet's AURP-Tr header and sets its
   sequence number to 0. The AURP header of a Tickle contains the
   command code 14 and its flag bytes are set to 0. A Tickle packet
   contains no data.

                   <<Figure 3-40  Tickle packet format>>

   TICKLE ACKNOWLEDGMENT PACKET: When the data sender receives a Tickle,
   it responds by sending a Tickle-Ack packet. Figure 3-41 shows the
   format of a Tickle-Ack. When sending a Tickle-Ack, a data sender
   inserts the connection ID from the associated Tickle in the Tickle-
   Ack packet's AURP-Tr header and sets its sequence number to 0. The
   AURP header of a Tickle-Ack packet contains the command code 15 and
   its flag bytes are set to 0. A Tickle-Ack packet contains no data.

                 <<Figure 3-41  Tickle-Ack packet format>>

   Error Codes

   Open-Rsp and RD packets contain error codes. AURP currently defines
   the error codes listed in Table 3-5.

                          Table 3-5  Error codes

   Error code     Error

   -1             Normal connection close
   -2             Routing loop detected
   -3             Connection out of sync
Top   ToC   RFC1504 - Page 56
   -4             Option-negotiation error
   -5             Invalid version number
   -6             Insufficient resources for connection
   -7             Authentication error

4.  REPRESENTING WIDE AREA NETWORK INFORMATION

   This chapter describes optional features of AURP-some of which can
   also be implemented on routers that use RTMP rather than AURP for
   routing-information propagation. It provides detailed information
   about the presentation of wide area network information by exterior
   routers to nodes on their local internets or to other exterior
   routers, including:

      basic security-both network hiding and device hiding

      remapping of remote network numbers

      internet clustering

      loop detection

      hop-count reduction

      hop-count weighting

      backup paths

      network management

   Network Hiding

   An exterior router can hide networks by importing or exporting
   routing information only about specific networks.

   Importing Routing Information About Specific Networks

   A network administrator can configure a tunneling port on an exterior
   router to import only a subset of the routing information that it
   receives through the tunnel. To do so, the administrator hides
   specific networks connected to other exterior routers on the tunnel
   from the exterior router's local internet. For example, an exterior
   router can import only that routing information received from
   specific exterior routers, or routing information for networks in a
   specific network range or zone. By importing routing information only
   about specific networks, an exterior router can greatly reduce
Top   ToC   RFC1504 - Page 57
      the amount of routing information maintained by routers on its
      local internet

      the number of zones and devices that are visible to devices on its
      local internet

   Exporting Routing Information About Specific Networks

   A network administrator can configure a tunneling port on an exterior
   router to export only a subset of its local internet's routing
   information-by hiding from other exterior routers on the tunnel
   specific networks in its local internet. For more information about
   hiding networks from other exterior routers, see the section "Hiding
   Local Networks From Tunnels" in Chapter 2.

   Device Hiding

   A router can prevent a device in its local internet from being
   visible to other nodes on a specific part or all other parts of the
   internet by not forwarding Name Binding Protocol (NBP) LkUp-Reply
   packets from that device. Hiding a device prevents nodes on the part
   of the internet from which it is hidden from knowing the name of the
   hidden device, making it more difficult for those nodes to access the
   hidden device. Any AppleTalk Phase 2 router can hide devices.

   Advantages and Disadvantages

   Device hiding is a flexible security mechanism that is appropriate
   for organizations that do not require true device-specific security.
   It is not a substitute for device-specific security. Device hiding
   can provide a degree of security on devices for which no other form
   of security exists-such as LaserWriter printers.

   A user can write a program that can obtain access to a hidden device
   using its AppleTalk address. Device hiding cannot secure a device
   from a user that is not using NBP to access the device.

   Device hiding does not provide true device-specific security. Many
   devices require device-specific security-for example, AppleShare file
   servers. Device-specific security can provide various levels of
   security, and may allow a network administrator to grant access
   privileges based on registered users and groups.

   Configuring Device Hiding on a Port

   When configuring a port on a router that implements device hiding, a
   network administrator should be able to hide any device that is
   accessible through that port from the other ports on the router. The
Top   ToC   RFC1504 - Page 58
   device being hidden need not reside on the network connected directly
   to the port being configured.

   An administrator should be able to specify the ports from which to
   hide a device-either specific ports or all other ports.

   When hiding devices, an administrator should be able to specify that
   a list of devices either be hidden or visible. The device list should
   include device names and device types-for example, We-B-
   Nets:AFPServer.  An administrator should also be able to hide all
   devices of a given type-for example, all LaserWriter printers-or all
   devices of all types.

   Filtering NBP LkUp-Reply Packets

   To implement device hiding, a router selectively filters NBP LkUp-
   Reply packets. When a port's configuration specifies that devices
   accessible through the port be hidden, the router

      monitors all NBP LkUp-Reply packets received through that port-
      called the incoming port

      determines the port through which it is to forward such a packet-
      called the outgoing port

      obtains-from the port configuration for the incoming port-the list
      of devices to be hidden from the outgoing port

      determines whether it should filter all or part of an NBP LkUp-
      Reply packet

         If a port's configuration does not specify that devices be
         hidden from the outgoing port, the router forwards the packet.

         If a port's configuration specifies that devices be hidden from
         the outgoing port, the router checks each tuple in the NBP LkUp-
         Reply packet to determine whether it is from a device in the
         port's list of hidden devices. It marks tuples from hidden
         devices for deletion. Once the router scans the entire packet,
         it forwards the packet if no tuples were marked for deletion; it
         discards the packet if all tuples were marked for deletion; or,
         if only some tuples were marked for deletion, it rebuilds the
         packet without the tuples marked for deletion, then forwards the
         packet.

   When the router rebuilds a packet, it adjusts the tuple count in the
   packet's NBP header to reflect the number of tuples remaining. If a
   rebuilt packet's DDP header contains a nonzero checksum, the router
Top   ToC   RFC1504 - Page 59
   verifies the original checksum, then sets it to 0.

   This device-hiding scheme can handle both NBP Lookups and NBP
   Confirms, because a node responds to requests of either type with a
   LkUp-Reply packet.

   LkUp-Reply packets do not contain the names of zones in which devices
   reside. Thus, if two devices having the same name and type are
   accessible through a port, a network administrator can hide both
   devices or neither device, but not just one of the devices.

   When configuring ports on routers through which redundant paths to a
   device exist, a network administrator must hide that device on at
   least one port on each path to that device. Otherwise, only a router
   on which such a port was configured to hide the device would filter
   LkUp-Reply packets from the device. A router on which such a port was
   not configured to hide the device would not filter its LkUp-Reply
   packets.  Figure 4-1 shows the proper configuration of device hiding
   when a loop exists on the internet.

     <<Figure 4-1  Device hiding when a loop exists on the internet>>

   Resolving Network-Numbering Conflicts

   In addition to interconnecting different parts of one organization's
   internet, tunnels can interconnect the internets of multiple
   organizations. Each organization administrates its internet
   independently. Therefore, conflicting network numbers may exist on
   the internets, especially when many internets are interconnected. The
   following sections describe the methods that AURP uses to resolve
   various problems due to conflicting network numbers.

   Network-Number Remapping

   Network-number remapping resolves network-numbering conflicts,
   allowing network administrators to build very large internets. When
   configuring a port on an exterior router, an administrator can
   specify a range of AppleTalk network numbers to be used for imported
   networks-that is, networks that are accessible through half-routing
   or tunneling ports, for which the exterior router imports routing
   information from other exterior routers. The remapping range-the
   range of network numbers reserved for network-number remapping-must
   not conflict with any network numbers already in use on the exterior
   router's local internet.

   The exterior router maps the network numbers in incoming packets into
   the remapping range. It converts remapped network numbers back to
   their actual network numbers for outgoing packets. To nodes and


(next page on part 3)

Next Section