Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1504

Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing

Pages: 82
Informational
Part 3 of 3 – Pages 60 to 82
First   Prev   None

Top   ToC   RFC1504 - Page 60   prevText
   routers within the exterior router's local internet, packets
   containing remapped network numbers apparently originate from or are
   being sent to networks having numbers in the remapping range.

   UNIQUE IDENTIFIERS: In a tunneling environment, many different
   internets may include AppleTalk networks that have the same network
   numbers.  Therefore, each exterior router on an internet must
   associate a unique identifier (UI) with each network that it exports
   across the tunnel-that is, each network in its local internet that is
   not hidden. Generally, some type of global administration of UIs is
   necessary.

   On a given tunnel, each exterior router on which network-number
   remapping is active must have a unique domain identifier (DI). An
   exterior router using AURP derives a network's UI by concatenating
   the exterior router's DI-which is unique on the tunnel-with the
   packet's network number or range-which is unique within the exterior
   router's domain. For more information about domain identifiers, see
   the section "Domain Identifiers" in Chapter 2.

   On a tunneling port, an exterior router refers to AppleTalk network
   numbers and network ranges using UIs. Whenever an exterior router
   sends or receives AppleTalk data packets across the tunnel, it refers
   to any network numbers or ranges in the packets-for example, in a
   packet's DDP header-by their UIs. For example, when an exterior
   router sends an RI- Rsp, which provides a list of network ranges for
   its local internet to other exterior routers on the tunnel, it lists
   the UIs corresponding to those network ranges. When an exterior
   router receives RI-Rsp packets from other exterior routers on the
   tunnel, it interprets the data in each packet as a list of UIs.

   Network-number remapping should be an optional component of any
   tunneling scheme. An administrator should be able to configure a
   tunneling port with or without specifying network-number remapping.
   When network-number remapping is inactive on all of the exterior
   routers on a tunnel, each AppleTalk network number and range
   associated with the exterior routers must be unique.

   MAPPINGS: An exterior router uses the following process to map
   AppleTalk network numbers and ranges to UIs, and vice versa:

      The exterior router logically maps network numbers in the exterior
      router's local internet to the corresponding UIs before sending a
      packet out the tunneling port, as shown in Figure 4-2. The UI
      consists of the source DI in the domain header and the network
      number from the packet. Therefore, the exterior router changes no
      data in the packet to perform this mapping.
Top   ToC   RFC1504 - Page 61
      The exterior router logically maps UIs corresponding to local
      networks in packets received through the tunneling port back to
      their local network numbers before forwarding the packets to the
      exterior router's local internet, as shown in Figure 4-2. The
      exterior router changes no data in the packet. This mapping is the
      inverse of the previous mapping.

      The exterior router maps UIs corresponding to network numbers for
      remote networks-that is, networks connected to other exterior
      routers on the tunnel-that are in packets received through the
      tunneling port to network numbers in the remapping range configured
      for the local internet, as shown in Figure 4-2. An exterior router
      remaps network numbers from the following fields in this way:

         the source network number field in the DDP header of an
         AppleTalk data packet

         the NBP entity address field in an AppleTalk data packet

         the routing data field in an AURP routing-information packet

      The exterior router maps network numbers in the remapping range
      configured for the local internet back to the corresponding UIs
      before sending packets out the tunneling port, as shown in Figure
      4-2. This type of remapping applies only to network numbers that
      reside in a destination network-number field of a DDP header in an
      AppleTalk data packet. This mapping is the inverse of the previous
      mapping.

     <<Figure 4-2 Mappings between local and remote internets' network
                             numbers and UIs>>

   NOTE:  Network-number remapping changes an AppleTalk data packet's
   DDP header and may also change its data. Thus, if a packet contains a
   DDP checksum, when the exterior router remaps network numbers
   contained in the packet, it must verify that the checksum is correct,
   then set the checksum to 0. If the checksum is incorrect, the
   exterior router should discard the packet.

   An exterior router can perform network-number remapping either
   statically or dynamically. Static remapping reserves specific network
   numbers in the remapping range for mapping specific UIs. Dynamic
   remapping assigns network numbers in the remapping range to networks
   as they become known to an exterior router.

   Static remapping is simpler to implement and provides a known mapping
   for use in network management. However, it may limit the number of
   UIs that an exterior router can import into its local internet.
Top   ToC   RFC1504 - Page 62
   Dynamic mapping requires a scheme for network number reuse, but may
   provide connectivity to a greater number of networks across a tunnel.

   To avoid having the same UI refer to two different networks when
   remapping network numbers dynamically, an exterior router should
   reuse network numbers in its remapping range only when no other
   network numbers are available. If a network goes down, an exterior
   router should not immediately reassign the UI that referred to that
   network to another network that just came up on the internet.

   An exterior router connected to more than one tunnel should function
   as though it were two exterior routers-each connected to one tunnel
   and both connected to one AppleTalk internet. Thus, such an exterior
   router must use remapped network numbers when sending routing
   information across a tunnel about networks that are accessible
   through another tunnel.

   Network Numbers in Data

   To remap network numbers properly, an exterior router must be aware
   of their presence within AppleTalk data packets. It is difficult to
   detect network numbers in data packets, because they could be
   anywhere within a data packet. For example, NBP includes network
   addresses as part of its data-in entity addresses. However, the data
   packets for very few protocols contain any network numbers. Some
   third-party protocols may contain network addresses in their data.
   Protocols that contain network addresses in their data may not
   function properly across remapping exterior routers.

   Packets used for network management-such as RTMP Route Data Response
   (RDR) and Simple Network Management Protocol (SNMP) packets-contain
   network numbers in their data. For detailed information about
   handling network numbers in SNMP packets, see the section "Network
   Management" later in this chapter.

   Problems With Loops

   Network-number remapping introduces some problems on an internet when
   loops exist across a tunnel. If network-number remapping is active,
   two AppleTalk internets connected by a tunnel should not be
   interconnected in any other way. If a redundant path to an internet
   exists, a remapped network range can loop back through that path to
   the exterior router that originally remapped the network range. When
   this occurs, two different network ranges-the network range actually
   configured and the remapping of the configured range-refer to one
   network.
Top   ToC   RFC1504 - Page 63
   The remapped network range apparently refers to a new network in the
   exterior router's local internet. Such a network is referred to as a
   shadow network. The exterior router cannot determine that it has
   received a network range that it had previously remapped, because
   there is no apparent difference between a remapped network range and
   an actual network range. Thus, unless an administrator configures an
   exterior router with an explicit list of networks to export, the
   exterior router again remaps the network range, then exports the
   remapped network range, sending it around the loop. The network range
   is remapped repeatedly until the apparent distance to the network
   exceeds the hop-count limit.  Exterior routers that implement
   network-number remapping should avoid establishing such infinite
   loops. For information about preventing such loops, see the section
   "Routing Loops" later in this chapter.

   Redundant Paths

   Under certain circumstances, it might be desirable to create a
   redundant path, which is a special type of loop. Redundant paths
   connect an internet to a tunnel through two or more exterior routers.
   If network-number remapping is active, all redundant exterior routers
   must use the same DI to represent the local internet-and must map UIs
   representing remote networks in incoming packets to the same local
   network numbers.

   To allow redundant exterior routers to achieve such cooperation, a
   network administrator might configure all redundant exterior routers
   with the same DI and complete remapping information for all imported
   networks. Alternatively, a network administrator might configure one
   exterior router with this information and all redundant exterior
   routers could obtain the information from the configured exterior
   router. AURP does not currently support this functionality, but may
   do so in the future.

   Tunnels With Partial Network-Number Remapping

   When network-number remapping is active on a tunneling port, an
   exterior router maps network numbers in packets received through the
   tunnel into the remapping range for its local internet. Because a
   network administrator configures network-number remapping on
   individual exterior routers, network-number remapping may be
   configured on some exterior routers on a tunnel, but not on others-
   potentially causing network-numbering conflicts due to partial
   network-number remapping. Whenever possible, an administrator should
   configure network-number remapping either on all exterior routers on
   a tunnel or on none of them.  Otherwise, network-numbering conflicts
   are likely to occur on some of the exterior routers-especially on
   large, interorganizational internets.
Top   ToC   RFC1504 - Page 64
   In addition to potential network-numbering conflicts, partial
   network-number remapping and the lack of loop detection between
   nonremapping exterior routers may cause shadow copies of networks
   connected to more than one nonremapping exterior router to appear in
   the routing tables on remapping exterior routers.

   An exterior router on which network-number remapping is active
   performs loop detection. Therefore, when network-number remapping is
   active on all of the exterior routers on a tunnel, no loops can exist
   across the tunnel. However, exterior routers on which network-number
   remapping is not active do not perform loop detection. Thus, when
   network-number remapping is not active on some of the exterior
   routers on a tunnel, any loops that exist between nonremapping
   exterior routers are not detected.

   In the example shown in Figure 4-3, shadow copies of all networks
   that are in the local internets of both exterior router B and
   exterior router C, on which network-number remapping is not active,
   appear in the routing table of exterior router A, on which network-
   number remapping is active.

      <<Figure 4-3  A tunnel with partial network-number remapping>>

   Clustering Remapped Networks

   Because a remapping range is a range of sequential network numbers,
   an exterior router can represent multiple remapped networks as a
   single extended network within its local internet-that is, it can
   cluster remapped networks. Clustering greatly reduces the size of the
   routing tables that are maintained and sent by routers within an
   internet, as well as the amount of RTMP traffic on the internet.
   Clustering may also reduce the amount of NBP traffic on an internet.

   For example, as shown in Figure 4-4, if networks in an internet have
   the numbers 1, 100, and 1000, and an exterior router connected to a
   different part of the internet receives these network numbers across
   the tunnel, that exterior router might remap the network numbers to
   21, 22, and 23. When sending RTMP packets within its local internet,
   the remapping exterior router can represent the three networks as a
   single extended network with a network range from 21 to 23. The zones
   associated with the extended network include all of the zones
   associated with the three imported network numbers.

            <<Figure 4-4  Clustering remapped network numbers>>

   An exterior router determines which remapped network numbers it
   should cluster. For example, an exterior router might create one
   cluster for each other exterior router on the tunnel. However, an
Top   ToC   RFC1504 - Page 65
   exterior router can include no more than 255 zones in one cluster.

   An exterior router that implements clustering must maintain the
   actual network range and zone list for each network in a cluster. The
   exterior router monitors all NBP FwdReq packets to be forwarded
   across the tunnel-including those it generates in response to BrRq
   packets. It examines the DDP destination network number in each
   FwdReq packet to determine the cluster to which it is addressed. The
   exterior router then generates one FwdReq packet for each clustered
   network for which the FwdReq packet contains a zone name, and sends
   that packet to the next internet router for the network. The DDP
   destination network number in such a FwdReq packet corresponds to the
   starting network number of a network's actual network range.

   A disadvantage of clustering is that clusters are static. An exterior
   router cannot notify its local internet that a specific network or
   zone in a cluster has gone down. An exterior router's implementation
   of clustering could allow a network administrator to initiate
   reclustering-in which the exterior router notifies the internet that
   an entire cluster has gone down, then creates a new cluster that does
   not include the networks that have gone down. However, such
   reclustering would cause a temporary loss of connectivity to those
   networks in the cluster that are still accessible. Therefore, an
   exterior router should not automatically recluster network numbers.

   REUSING NETWORK NUMBERS WITHIN A CLUSTER: Under certain conditions,
   an exterior router that implements clustering might reuse network
   numbers within a cluster. If a network went down, then came back up
   with the same zone list, an exterior router could map its network
   range into the same remapping range and include it in the same
   cluster. Otherwise, an exterior router should not reuse network
   numbers within a cluster, unless no other network numbers within the
   remapping range are available. In any case, an exterior router can
   reuse network numbers within a cluster only if a new network has a
   network range that fits in an unused range of network numbers within
   the cluster and a zone list that is a subset of the cluster's zone
   list.

   The implementation of clustering in an exterior router is complex.
   See the Appendix, "Implementation Details," for some ways in which
   clustering could be implemented.

   Zone-Name Management

   To enhance zone-name management within an AppleTalk internet, AURP
   provides Get Domain Zone List and Get Zone Nets requests-which
   function similarly to the ZIP GetZoneList command and ZI-Req command,
   respectively. However, as when using RTMP and ZIP, if two networks in
Top   ToC   RFC1504 - Page 66
   an internet include zones that have the same zone name in their zone
   lists, exterior routers merge the zones into one zone-regardless of
   whether network-number remapping is active on one or more of the
   exterior routers.

   Because AppleTalk data packets often contain zone names, AURP
   provides no means of remapping zone names. When importing or
   exporting zone names, an exterior router should not modify them in
   any way.

   On a very large internet, zone names may become unmanageable.
   Therefore, an administrator should use domain-specific prefixes-such
   as Engineering or Sales-for zone names on such an internet. The use
   of a third-party hierarchical Chooser also might simplify zone-name
   management.

   Hop-Count Reduction

   Generally, an exterior router increases the hop count in the DDP
   header of an AppleTalk data packet by at least one when it forwards
   the packet across a tunnel. Once a packet traverses 15 routers-either
   local routers or exterior routers-its hop count exceeds the maximum.
   Thus, when an exterior router receives a packet through its tunneling
   port, it should examine that packet's DDP hop count before forwarding
   the packet. If the exterior router receives a packet with a hop count
   of 15 hops, it does not forward the packet to another router, but
   discards the packet.

   When a tunnel or point-to-point link connects AppleTalk internets,
   the distance that a packet must traverse can easily exceed 15 hops. A
   network administrator might need full connectivity between two
   internets at a distance exceeding 15 hops. If the distance across an
   exterior router's local internet is already at or near the 15-hop
   limit, the exterior router must reduce the perceived distance that a
   packet must traverse to allow the packet to reach a destination at a
   distance that exceeds 15 hops. To overcome DDP's 15-hop limit, an
   exterior router reduces the hop count in the DDP header of an Apple
   data packet received through a tunnel before forwarding the packet
   into its local AppleTalk internet. An exterior router should reduce
   the hop count only by the number of hops necessary to allow the
   packet to reach its destination without exceeding the hop-count
   limit.

   When an exterior router receives a packet through the tunnel, it
   examines the routing-table entry for that packet's destination
   network to determine the remaining distance to that network. If the
   distance already traversed by the packet-the packet's current hop
   count-plus the distance to the destination network is less than 15
Top   ToC   RFC1504 - Page 67
   hops, the exterior router simply forwards the packet. If adding the
   destination network's distance to the packet's current hop count
   causes the hop count to exceed 15 hops, the exterior router sets the
   hop count to the following value: 15 minus the distance in hops to
   the destination network. The exterior router then forwards the
   packet.

   Using hop-count reduction, an exterior router must overcome the 15-
   hop limits imposed by both DDP and RTMP. To overcome RTMP's 15-hop
   limit, an exterior router should represent all networks accessible
   through the tunnel to routers in its local internet as one hop away
   when hop-count reduction is active on a tunneling port. This allows
   routers to maintain and send routing information about networks
   beyond the 15-hop limit and achieve full connectivity.

   Constraints on Hop-Count Reduction

   An interdomain loop exists when a redundant path connects two parts
   of an internet that are connected through two exterior routers on a
   tunnel.  The proper operation of hop-count reduction requires that no
   interdomain loops exist across a tunnel. For detailed information
   about interdomain loops see the next section, "Routing Loops."

   Because network-number remapping requires that no interdomain loops
   exist on the internet, an exterior router can perform hop-count
   reduction whenever network-number remapping is active, without any
   risk of a packet being forwarded in an infinite routing loop.
   Generally, an exterior router should not perform loop detection when
   network-number remapping is inactive.

   Routing Loops

   A routing loop exists when more than one path connects two exterior
   routers-both the path through the tunnel and a path through the
   exterior routers' local internets. When network-number remapping is
   not active on an exterior router, a routing loop can provide an
   alternative path to a network. However, when network-number remapping
   or hop-count reduction is active on an exterior router, all exterior
   routers must avoid establishing loops across the tunnel. Otherwise,
   if a routing loop went undetected, multiple routing-table entries
   that referred to the same actual AppleTalk networks using different
   remapping ranges might fill the routing tables of all of the exterior
   routers on a tunnel.

   First-Order Loops

   In a first-order loop, a pair of exterior routers that are performing
   network-number remapping across a tunnel are also connected through
Top   ToC   RFC1504 - Page 68
   another path, on which there are no remapping exterior routers. In
   Figure 4-5, exterior routers A and B are remapping network numbers
   across an AppleTalk tunnel, and exterior router C-which is not
   remapping network numbers-creates a first-order routing loop.
   Exterior router A's network range, 1 through 4, loops back to it
   through the tunnel and may be remapped again.

                    <<Figure 4-5  A first-order loop>>

   Second-Order Loops

   In a second-order loop, one or more additional pairs of remapping
   exterior routers are in the loop. In Figure 4-6, exterior routers A
   and B are remapping network numbers across the AppleTalk tunnel that
   connects them, and another pair of exterior routers, C1 and C2-which
   are also performing remapping across the tunnel that connects them-
   creates a second-order routing loop. Exterior router A's network
   range, 1 through 4, is remapped by exterior router C2 to the network
   range 101 through 104, then loops back to exterior router A through
   the tunnel.

                    <<Figure 4-6  A second-order loop>>

   Self-Caused and Externally Caused Loops

   Routing loops can be either self-caused or externally caused. A self-
   caused loop results when the detecting exterior router itself comes
   on line. An externally caused loop results when another router comes
   on line somewhere on the internet, after the detecting router has
   been running for some time.

   Loop-Detection Process

   The following sections describe the phases of the minimal loop-
   detection process that an exterior router must employ when either
   network-number remapping or hop-count reduction is active. An
   exterior router can implement an enhanced loop-detection scheme.

   LOOP-INDICATIVE ROUTING INFORMATION: A remapping exterior router
   should always examine routing information received through a tunnel
   for indications that a routing loop may exist. Loop-indicative
   routing information appears to refer to networks across the tunnel.
   However, it may actually refer to networks in the exterior router's
   own local internet if the networks' routing information has looped
   back through the tunnel.

   In the following definition of loop-indicative information,
Top   ToC   RFC1504 - Page 69
      the network range for the network connected to a given port of an
      exterior router is referred to as ns through ne

      the zone list for that network is referred to as z1 through zn

   The routing information that a remapping exterior router receives
   through a tunneling port is loop indicative if both of the following
   conditions are true for some port on the router:

      The size of the network range in the routing information is ne-
      ns+1.

      The zone list in the routing information consists precisely of z1
      through zn.

   Thus, the routing information could represent a remapping of the
   network range for a network connected directly to one of the exterior
   router's ports.

   An exterior router most commonly receives loop-indicative information
   at startup when the process of bringing up the tunnel may create a
   self-caused loop. An exterior router may also receive loop-indicative
   information if another router connects two AppleTalk domains that are
   already connected through the tunnel and creates an externally caused
   loop.

   If a remapping exterior router receives loop-indicative routing
   information through a tunnel, it should start a loop-investigation
   process. For information about the loop-investigation process, see
   the next section, "Loop-Investigation Process."

   LOOP-INVESTIGATION PROCESS: To confirm or deny the existence of a
   suspected loop, an exterior router performs a loop-investigation
   process, in which it sends an AppleTalk data packet out the tunneling
   port, then observes whether that packet loops back through a port
   connected to its local internet. The exterior router sends the packet
   to the address corresponding to its own address on the network that
   it suspects may actually be a shadow copy of a network connected
   directly to one of its ports.

   LOOP PROBE PACKET: A Loop Probe packet is an AppleTalk data packet
   that an exterior router sends out a tunneling port to confirm or deny
   the existence of a loop. It is a new type of RTMP packet and has the
   function code 4. Figure 4-7 shows the format of a Loop Probe packet.

                 <<Figure 4-7  Loop Probe packet format>>

   The source node ID and source network number in a Loop Probe packet
Top   ToC   RFC1504 - Page 70
   should be those of the port for which the exterior router received
   loop-indicative information. An exterior router can send a Loop Probe
   packet through any socket.

   A Loop Probe packet's destination network number is the network
   number to which that port's network number would be remapped if the
   loop-indicative information were actually a shadow copy of that
   port's routing information. Refer to the port's actual network number
   as nu(ns<=nu<=ne). If the network range in the loop-indicative
   information were rs through re, the packet's destination network
   number would be rs+nu-ns.

   A Loop Probe packet's destination node ID is that of the exterior
   router on the port for which the exterior router received loop-
   indicative information. The packet's destination socket is socket 1-
   the RTMP socket.

   A Loop Probe packet's data field always begins with a long word that
   has the value 0. The remainder of the data field should contain
   information that the exterior router that sends the packet can use to
   identify that packet if it receives the packet through its local
   internet. An exterior router might receive a Loop Probe packet sent
   by another exterior router if a loop did not actually exist and the
   other exterior router sent a Loop Probe packet to a random node on
   the internet rather than to itself. The node receiving the Loop Probe
   packet might be an exterior router that also sent a Loop Probe
   packet. To prevent an exterior router that receives such a Loop Probe
   packet from falsely concluding that a loop exists, the exterior
   router sending the packet must insert sufficient data in that
   packet's data field to allow it to recognize the packet as the one it
   sent.

   An exterior router initiating a loop-investigation process should
   forward a Loop Probe packet through the tunnel to the next internet
   router for the packet's destination network-just as it would any
   other AppleTalk data packet. This next internet router should always
   be the exterior router that sent the loop-indicative information.

   A remapping exterior router forwarding a Loop Probe packet into its
   local internet must process that packet differently from other
   AppleTalk data packets in one way. If the exterior router's remapping
   database does not include the source network number in the packet's
   DDP header, the exterior router should forward the packet without
   remapping the source network number. At startup, remapping
   information is generally unavailable. However, the absence of
   remapping information should not affect the loop-detection process.

   If a loop exists, the exterior router that originally sent the Loop
Top   ToC   RFC1504 - Page 71
   Probe packet receives that packet through its local internet. The
   data in the packet remains unchanged. The exterior router can use
   that data to confirm the existence of a loop on the internet.

   If a Loop Probe packet returns to the exterior router through the
   tunnel out which it was sent, a loop exists between two other
   exterior routers on the tunnel, but does not involve the exterior
   router that sent the packet. The sending router need take no action.

   An exterior router should send a Loop Probe packet at least four
   times.  The retransmission timeout should be no less than two
   seconds. Once the exterior router has retransmitted a Loop Probe
   packet four times and that packet has not returned to the exterior
   router through its local internet, the exterior router determines
   that no loop exists.

   If the exterior router receives a Loop Probe packet containing the
   correct data field through its local internet, this confirms the
   existence of a loop. The exterior router should deactivate the
   tunneling port, log an error, and set the state of all routing-table
   entries for exterior routers connected to that tunnel to BAD.

   NOTE:  The exterior router need not deactivate a tunneling port on
   which it detects a loop. However, the exterior router must disconnect
   with the exterior router that sent the loop-indicative information.
   However, disconnecting from only that exterior router might
   inadvertently result in a partially connected tunnel or in a lack of
   connectivity through the tunnel that would be difficult to detect.

   LIMITATIONS OF LOOP DETECTION: This loop-detection process becomes
   ineffective if, at some point in the loop, another exterior router

      hides networks connected directly to the ports of the exterior
      router that sent the Loop Probe packet

      clusters the network ranges of networks connected directly to the
      exterior router's ports

      is not remapping network numbers-resulting in partial network-
      number remapping

   In such cases, the exterior router that initiated the loop-detection
   process may never receive loop-indicative information, even though a
   loop exists.

   Using Alternative Paths

   AURP provides two mechanisms that allow a network administrator to
Top   ToC   RFC1504 - Page 72
   configure a port on an exterior router to forward packets over an
   alternative path to a network only when the primary path to that
   network is unavailable:

      hop-count weighting

      backup paths

   By configuring hop-count weighting on a port or configuring a port as
   a backup path, an administrator can reduce the amount of traffic on a
   slow point-to-point link or tunnel. These mechanisms are also
   available on links using RTMP.

   Hop-Count Weighting

   A network administrator can configure hop-count weighting on a port
   to increase the routing distance through a port by counting a link to
   another exterior router as more than one hop. Increasing the routing
   distance through a port may cause traffic to traverse an alternative
   path. The routers on an internet forward packets over an alternative
   path to a network if

      an alternative path is available

      the perceived distance to that network is shorter over the
      alternative path

   However, a network administrator should not set the hop-count weight
   for a link so high that distances between networks across that link
   exceed the limit of 15 hops. Otherwise, if the link on which hop-
   count weighting was active were the only available path, the exterior
   router would be unable to provide full connectivity to all networks
   on the internet.

   To implement hop-count weighting, an exterior router should make the
   following changes to RTMP and the DDP routing process:

      When an exterior router uses RTMP or AURP to broadcast the
      networks that are accessible through a link on which hop-count
      weighting is active, the distance attributed to each network should
      equal its actual distance plus the hop-count weight specified.

      Before an exterior router forwards a DDP data packet to a network
      across that link, it should add the specified hop-count weight to the
      value in the hop-count field of the packet's DDP header.
Top   ToC   RFC1504 - Page 73
   Backup Paths

   A network administrator can configure a port on an exterior router as
   a backup path. The routers on an internet forward AppleTalk data
   packets across a backup path only when an exterior router on which a
   port is configured as a backup path determines that no other path to
   a specific network or networks is available.

   Regardless of the distance that routing packets must traverse across
   a primary path to a network, routers on the internet use the primary
   path as long as it remains available. When the exterior router on
   which a port is configured as a backup path determines that the
   primary path to a network is no longer available and that network is
   accessible across the backup path, the exterior router broadcasts
   routing information about networks accessible across the backup path
   to its local internet.

   NOTE:  An exterior router at each end of the backup path maintains a
   complete routing table for the entire internet, and sends AURP or
   RTMP routing packets across the backup path, regardless of whether
   the backup path is in use.

   If an exterior router is currently providing access to a network
   through a backup path and the primary path to that network again
   becomes available, the exterior router starts broadcasting routing
   information that indicates the primary path to the network, rather
   than the backup path. The routers on the exterior router's local
   internet can again use the primary path to that network.

   PROBLEMS REACTIVATING THE PRIMARY PATH: When an exterior router is
   providing access to a network through a backup path and the primary
   path to that network again becomes available, it is possible that the
   exterior router may not become aware that the primary path is
   available.  This can occur when other routers in the exterior
   router's local internet use the backup path, rather than a newly
   available primary path, because the backup path traverses a shorter
   distance. The other routers have no way of knowing that an active
   path is a backup path.  They do not notify the exterior router
   connected to the shorter backup path about the primary path's
   availability.

   Once the primary path becomes unavailable and routers on the internet
   use the backup path, reconfiguring the exterior router so it will
   again use the primary path may be necessary.

   Network Management

   A Simple Network Management Protocol (SNMP) Management Information
Top   ToC   RFC1504 - Page 74
   Base (MIB) allows the remote management of tunneling, routing-
   information propagation, and the representation of wide area routing
   information.  Refer to the "IETF Draft: Macintosh System MIB" on
   E.T.O. for detailed information about the structure and content of
   AURP's many remotely manageable parameters.

   Network-Number Remapping and Network Management

   The packets of network-management protocols-regardless of whether
   SNMP forms their basis-often contain information about specific
   AppleTalk network numbers. An exterior router cannot remap network
   numbers in data. Therefore, when querying devices across a tunnel,
   network-management protocols always return network numbers that have
   not been remapped. However, a remote network-management station using
   SNMP could use the AURP MIB to query a remapping exterior router to
   obtain remapped network numbers from the exterior router's remapping
   database.

   Network Hiding and Network Management

   Even though an exterior router is hiding a network from a particular
   port, that network's routing information should be available to a
   network-management station across that port. Network hiding should
   not affect network management. Thus, an exterior router should still
   return routing information for hidden networks in responses to
   network-management queries. A network-management station using SNMP
   could use the AURP MIB to query an exterior router to obtain
   information about hidden networks.

   Unaffected Network-Management Packets

   Network-management packets that network-number remapping and network
   hiding should not affect include:

      SNMP requests received through an AURP port

      SNMP responses sent through an AURP port

      RTMP responses sent through an AURP port

      Route Data responses sent through an AURP port

      ZIP queries received through an AURP port

      ZIP requests received through an AURP port

      ZIP replies sent through an AURP port
Top   ToC   RFC1504 - Page 75
APPENDIX:  IMPLEMENTATION DETAILS

   This appendix provides information that may assist you in
   implementing AURP. It does not specify protocol requirements.

   Developers implementing AURP routers may want to purchase the Apple
   Internet Router, a product of Apple Computer. The Apple Internet
   Router provides many additional examples of how you might implement
   the various features of AURP.

   State Diagrams

   Figure A-1 shows the state diagram for the AURP data receiver.

             <<Figure A-1  AURP data receiver state diagram>>

   Figure A-2 shows the state diagram for the AURP data sender.

              <<Figure A-2  AURP data sender state diagram>>

   AURP Table Overflow

   It is possible for an AURP data receiver to have insufficient storage
   capacity to maintain all of the routing information sent to it by a
   peer data sender. Because the data sender does not retransmit routing
   information, the data receiver should set a flag indicating that a
   table-overflow condition exists. If additional storage later becomes
   available, the data receiver should try to obtain the missing
   information. If zone information is lost, the data receiver can
   obtain complete zone information by sending the appropriate ZI-Req
   packets. If network information is lost, the data receiver should
   send an RI-Req to obtain the complete routing table.

   A Scheme for Updates Following Initial Information Exchange

   As described in the section "Sending Updates Following the Initial
   Exchange of Routing Information" in Chapter 3, an exterior router
   must present complete and accurate routing information to all
   exterior routers, even if a new connection is established with that
   exterior router when the exterior router has update events pending-
   that is, update events not yet sent in RI-Upd packets. This section
   details one scheme for presenting routing information to both new and
   old connections correctly, even if multiple update events occur for a
   given network in an update period during which the exterior router
   establishes new connections. More complex schemes could provide more
   up-to-date information, at the cost of greater implementational
   complexity.
Top   ToC   RFC1504 - Page 76
   Assume that an exterior router has a number of AURP connections
   established with other routers and that a series of update events for
   a given network occur in the exterior router's local internet. Once
   these events have occurred, but before the update interval expires-
   that is, before the exterior router sends RI-Upd packets over its
   connections-the exterior router establishes a new AURP connection
   with another exterior router and receives an RI-Req packet from that
   exterior router. This section describes the information about the
   network that the RI-Rsp packet should contain. It also describes the
   update event that the exterior router should send in the next RI-Upd
   packet, assuming that it receives no additional update events for the
   network.

   Two scenarios are possible. In the first scenario, a network for
   which the exterior router is not exporting information at the
   beginning of an update interval either comes up in the exterior
   router's local internet, or a new path to the network that is shorter
   than the path through the tunnel comes up in the exterior router's
   local internet. In either case, the RI-Rsp packet should not include
   the new network.

   By not including the new network in the RI-Rsp, the implementation
   can simply continue to follow the state diagram provided in the
   section "Sending Routing Information Update Packets" in Chapter 3. If
   only an NDC event or no additional update event occurs for the
   network, the next RI-Upd packet that the exterior router sends on
   both old and new connections should contain an NA event for the
   network. If an NRC or ND event occurs for the network, the exterior
   router should not include an event tuple for the network in the RI-
   Upd. This sequence matches the state diagram precisely. If the RI-Rsp
   did contain information about the network, new connections would
   require a different state diagram.

   In the second scenario, the exterior router initially exports
   information for a network, then an update event occurs for that
   network.  In all cases, the RI-Rsp packet should contain up-to-date
   information about the network from the exterior router's central
   routing table, and the next RI-Upd packet should contain the specific
   event that the state table indicates for that network. For example,
   if an ND or NRC event occurs for the network, the network should not
   be included in the RI-Rsp, while if an NDC event occurs, it should be
   included in the RI-Rsp.

   This scheme may result in some exterior routers receiving unexpected
   update events, which they must process as specified in the section
   "Processing Inconsistent Update Events" in Chapter 3. For example,
   another exterior router with which the exterior router establishes a
   new connection might receive an ND or NRC event for a network of
Top   ToC   RFC1504 - Page 77
   which it was unaware. The receiving exterior router would ignore the
   event.

   In an alternative way of evaluating and possibly implementing this
   scheme, the information for a given network that is sent in the
   initial RI-Rsp packet depends on the particular update event that is
   pending for that network when the exterior router sends the RI-Rsp.
   Specifically, an exterior router should include a network for which
   it has an update event pending in the RI-Rsp packet only if the
   pending update event is an NDC. Otherwise, the exterior router should
   not include the network in the RI-Rsp. Following this RI-Rsp, the
   exterior router sends RI-Upd packets as usual, which include other
   pending events, as necessary.

   Implementation Effort for Different Components of AURP

   AURP contains various enhancements to AppleTalk routing. The only
   components of AURP that are required are those specified in Chapter
   3.  The required components of AURP provide the functionality needed
   to replace RTMP and ZIP, completely and compatibly, on tunnels and
   point-to-point links, without losing any functionality and with
   greatly reduced routing traffic. Optional features of AURP provide
   functionality beyond that of RTMP and ZIP. This functionality is
   especially useful in a wide area network environment.

   The chart shown in Figure A-3 provides rough estimates of the
   percentage of development time needed to implement, debug, and test
   the various components of a complete AURP implementation. It can
   provide developers with some idea of the implementational complexity
   of these components and help developers make tradeoffs between
   features and development time.

              <<Figure A-3  Implementation effort for AURP>>

   Creating Free-Trade Zones

   A useful feature of AURP is that it allows a network administrator to
   create free-trade zones. A free-trade zone is a part of an internet
   that is accessible by two other parts of the internet, neither of
   which can access the other. An administrator might create a free-
   trade zone to provide some form of interchange between two
   organizations that otherwise want to keep their internets isolated
   from each other, or between two organizations that otherwise do not
   have physical connectivity with one another.

   AURP allows the creation of free-trade zones in two ways. In one
   method, described in the section "Fully Connected and Partially
   Connected Tunnels" in Chapter 2, an administrator intentionally
Top   ToC   RFC1504 - Page 78
   creates a partially connected tunnel. The administrator configures
   the exterior router to connect with two exterior routers between
   which a free-trade zone is to be established, but does not configure
   those exterior routers to connect with one another.

   The second method of using AURP to create a free-trade zone involves
   the use of network hiding. An administrator can configure a single
   router to create a free-trade zone. No AURP tunnel need exist. As
   shown in Figure A-4, three ports are configured on a router. One port
   connects to the free-trade zone, while the other two ports connect to
   the parts of the internets that are otherwise isolated from one
   another.

                 <<Figure A-4  Creating free-trade zones>>

   On the port connected to the free-trade zone, the administrator does
   not configure the router to hide any networks. The exterior router
   exports all networks from both organizations to the free-trade zone.
   On each port connected to an organization's internet, the
   administrator configures the router to export only the networks from
   the free-trade zone. The exterior router hides all the networks from
   the other organization's internet. In this way, each organization has
   access to the networks in the free-trade zone, and vice versa, but
   not to the networks in the other organization's internet.

   Implementation Details for Clustering

   The data structures that an exterior router uses to maintain
   information about clustering are key to the implementation of
   clustering. An exterior router should

      maintain mappings between the actual domain identifier and network
      range; the remapped network range; and the associated cluster

      maintain zone lists for each actual network and for the cluster as
      a whole

      use data structures that allow parts of the information to be
      marked for deletion, while maintaining that information for possible
      later reuse-for example, if a network goes down, then comes back up

      use data structures that are bidirectional-supporting both the
      conversion of a single FwdReq into multiple FwdReq packets and the
      manipulation of individual networks within the cluster

   An exterior router can cluster any network numbers that is has
   remapped into an available range of contiguous network numbers. From
   both an implementation and a management point of view, it is
Top   ToC   RFC1504 - Page 79
   generally best for an exterior router to cluster all network numbers
   that it receives from a particular exterior router at a given time.
   For example, it may be desirable to cluster all of the network
   numbers included in the initial information exchange with a
   particular exterior router, then later, to cluster all of the network
   numbers received in NA events in a given RI- Upd packet.

   Maintaining compatibility with AppleTalk Phase 2 complicates the
   implementation of clustering. An exterior router can include a
   maximum of 255 zones in a cluster. This limit may prevent the
   exterior router from clustering all of the network numbers that it
   receives at one time.  When an exterior router receives a list of
   networks from another exterior router, it does not know how many
   different zone names the networks use. The exterior router does not
   have this information until it receives the associated ZI-Rsp
   packets. Therefore, an exterior router should not build a cluster
   until it has received a complete zone list for the network numbers
   being clustered. Once the exterior router has complete zone
   information for the network numbers, it can cluster the maximum
   number of network numbers allowed by the 255 zone limit.

   AURP does not specify the method by which an exterior router, when
   forming a cluster, should determine the hop count for that cluster-
   that is, the apparent distance in hops to the single extended network
   that represents the cluster. Possible implementation options include

      always setting the hop count to a constant value

      setting the hop count to the minimum, average, or maximum of the
      hop counts for the networks within the cluster

   In a large internet, setting the hop count for a cluster too high may
   make the networks in that cluster unreachable from some networks in
   the local internet of the exterior router that is clustering the
   network numbers.

   Modified RTMP Algorithms for a Backup Path

   In the following RTMP maintenance algorithms defined in Inside
   AppleTalk, the backup path is an RTMP link. These algorithms can be
   adapted to AURP according to the architectural model described in the
   section "AURP Architectural Model" in Chapter 3. Proposed
   modifications to these algorithms appear in boldface Courier font.

   On Receiving an RTMP Data Packet Through a Port

   IF P is connected to an AppleTalk network AND P's network
        number range = 0
Top   ToC   RFC1504 - Page 80
   THEN BEGIN
        P's network number range := packet's sender network
             number range;
        IF there is an entry for this network number range
        THEN delete it;
        Create a new entry for this network number range with
             Entry's network number range := packet's sender
                  network number range;
             Entry's distance := 0;
             Entry's next IR := 0;
             Entry's status := Good;
             Entry's port := P;
        END;
   FOR each routing tuple in the RTMP Data packet DO
        IF there is a table entry corresponding to the tuple's
             network number range
             THEN Update-the-Entry
        ELSE IF there is a table entry overlapping with the
             tuple's network number range
             THEN ignore the tuple
        ELSE IF P is not a backup path
             THEN Create-New-Entry
        ELSE     Create-New-Tentative Entry;

   Update-the-Entry

   IF (Entry's port is not a backup port AND P is a
        backup port)
   THEN Return; {Ignore tuple}
   IF (Entry's state = Bad) AND (tuple distance <15)
   THEN Replace-Entry
   ELSE
        IF Entry's distance >= (tuple distance +1) AND (tuple
             distance <15)
             OR  (Entry's port is a backup port and P is not a
                  backup port)
        THEN Replace-Entry
        ELSE IF Entry's next IR = RTMP Data packet's sender node
             address AND Entry's port = P
        THEN IF tuple distance <> 31 THEN BEGIN
             Entry's distance := tuple distance + 1;
             IF Entry's distance < 16
             THEN Entry's state := Good
             ELSE Delete the entry
        END
        Else Entry's state := Bad;
Top   ToC   RFC1504 - Page 81
   An exterior router uses the Create-New-Tentative-Entry algorithm when
   it discovers a previously unknown network across a backup path. An
   exterior router should not add an entry to the routing table being
   broadcast to its local internet until it determines definitely that
   no alternative path to a network is available. While waiting for
   another path to a network to become available, the exterior router
   temporarily stores the routing-table entry in a tentative routing
   table, as defined by the following algorithm:

   Create-New-Tentative-Entry

   IF tentative entry for tuple's network number range does not
        already exist
        THEN BEGIN
             Tentative entry's network number range =
                  tuple's network number range;
             Tentative entry's distance := tuple's distance;
             Tentative entry's next IR = packet's node address;
             Tentative entry's port := P;
             Start a TBD-minute timer for this entry;
        END;
   WHEN timer for this entry expires
        IF there is a table entry corresponding to or
             overlapping with the tentative entry's network
             number range
             THEN ignore the entry
        ELSE Create-New-Entry; {using data from the tentative
             entry}
        Delete tentative entry;
Top   ToC   RFC1504 - Page 82
Security Considerations

   This memo discusses a weak form of security called network hiding or
   device hiding.  More general concerns about security are not
   addressed.

Author's Address

   Alan B. Oppenheimer
   Apple Computer, M/S 35-K
   20525 Mariani Avenue
   Cupertino, California  95014

   Phone: 408-974-4744
   EMail: Oppenheime1@applelink.apple.com

   Note: The author would like to acknowledge the contribution of Pabini
   Gabriel-Petit here at Apple, who translated the engineering
   specification into human-readable form.