GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1504

Network Working Group A. Oppenheimer Request for Comments: 1504 Apple Computer

                                                           August 1993
              Appletalk Update-Based Routing Protocol:
                     Enhanced Appletalk Routing

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard.  Distribution of this memo is
 unlimited.

Introduction

 This memo is being distributed to members of the Internet community
 to fully document an Apple protocol that may be running over the
 Internet.  While the issues discussed may not be directly relevant to
 the research problems of the Internet, they may be interesting to a
 number of researchers and implementers.

About This Document

 This document provides detailed information about the AppleTalk
 Update-based Routing Protocol (AURP) and wide area routing. AURP
 provides wide area routing enhancements to the AppleTalk routing
 protocols and is fully compatible with AppleTalk Phase 2. The
 organization of this document has as its basis the three major
 components of AURP:
    AppleTalk tunneling, which allows AppleTalk data to pass through
    foreign networks and over point-to-point links
    the propagation of AppleTalk routing information between internet
    routers connected through foreign networks or over point-to-point
    links
    the presentation of AppleTalk network information by an internet
    router to nodes and other Phase 2-compatible routers on its local
    internet

What This Document Contains

 The chapters of this document contain the following information:
    Chapter 1, "Introduction to the AppleTalk Update-Based Routing
    Protocol," introduces the three major components of AURP and the

Oppenheimer [Page 1] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    key wide area routing enhancements that AURP provides to the
    AppleTalk routing protocols.
    Chapter 2, "Wide Area AppleTalk Connectivity," provides
    information about AppleTalk tunneling through IP internets and over
    point-to-point links.
    Chapter 3, "Propagating Routing Information With the AppleTalk
    Update-Based Routing Protocol," describes the essential elements of
    AURP, including the architectural model for update-based routing.
    This chapter provides detailed information about the methods that
    AURP uses to propagate routing information between internet routers
    connected through tunnels.
    Chapter 4, "Representing Wide Area Network Information," 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 gives detailed information about how an exterior
    router represents imported network information to its local
    internet and to other exterior routers. It describes network
    hiding, device hiding, network-number remapping, clustering, loop
    detection, hop-count reduction, hop-count weighting, and backup
    paths.
    The Appendix, "Implementation Details," provides information about
    implementing AURP.

What You Need to Know

 This document is intended for developers of AppleTalk wide area
 routing products. It assumes familiarity with the AppleTalk network
 system, internet routing, and wide area networking terms and
 concepts.

Format of This RFC Document

 The text of this document has been quickly prepared for RFC format.
 However, the art is more complex and is not yet ready in this format.
 We plan to incorporate the art in the future. Consult the official
 APDA document, as indicated below, for the actual art.

For More Information

 The following manuals and books from Apple Computer provide
 additional information about AppleTalk networks. You can obtain books
 published by Addison-Wesley at your local bookstore. Contact APDA,
 Apple's source for developer tools, to obtain technical reference
 materials for developers:

Oppenheimer [Page 2] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    APDA
    Apple Computer, Inc.
    20525 Mariani Avenue, M/S 33-G
    Cupertino, CA  95014-6299
 These manuals provide information about some AppleTalk network
 products:
    The Apple Ethernet NB User's Guide explains how to install and use
    an Apple Ethernet NB Card and EtherTalk software on an AppleTalk
    network.
    The Apple InteroPoll Network Administrator's Guide describes how
    to perform maintenance and troubleshooting on an AppleTalk network
    using InteroPoll, a network administrator's utility program.
    The Apple Internet Router Administrator's Guide explains how to
    install the Apple Internet Router Basic Connectivity Package and
    how to use the Router Manager application program. It provides
    information about setting up the router, configuring ports to
    create local area and wide area internets, monitoring and
    troubleshooting router operation, and planning your internet.
    Using the AppleTalk/IP Wide Area Extension explains how to install
    and use the AppleTalk/IP Wide Area Extension for the Apple Internet
    Router. It provides information about tunneling through TCP/IP
    networks, configuring an IP Tunnel access method for an Ethernet or
    Token Ring port on the Apple Internet Router, troubleshooting IP
    tunneling problems, and configuring MacTCP.
    The AppleTalk Remote Access User's Guide explains how to use a
    Macintosh computer to communicate with another Macintosh computer
    over standard telephone lines to access information and resources
    at a remote location.
    The Apple Token Ring 4/16 NB Card User's Guide explains how to
    install and operate the card and TokenTalk software on a Token Ring
    network.
    The MacTCP Administrator's Guide, version 1.1, explains how to
    install and configure the MacTCP driver, which implements TCP/IP
    (Transmission Control Protocol/Internet Protocol) on a Macintosh
    computer.

Oppenheimer [Page 3] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 The following books provide reference information about AppleTalk
 networks:
    The Advantages of AppleTalk Phase 2 provides a detailed
    description of the enhanced internetworking capabilities of
    AppleTalk Phase 2, and a brief guide to upgrading an AppleTalk
    internet to AppleTalk Phase 2. Available from Apple Computer.
    The AppleTalk Network System Overview provides a technical
    introduction to the AppleTalk network system and its protocol
    architecture. Published by Addison-Wesley Publishing Company.
    The AppleTalk Phase 2 Introduction and Upgrade Guide is a detailed
    guide to upgrading AppleTalk network hardware, drivers, and
    application programs to AppleTalk Phase 2, and briefly describes
    extensions to the AppleTalk network system that enhance its
    support for large networks. Available from Apple Computer.
    The AppleTalk Phase 2 Protocol Specification is an addendum to the
    first edition of Inside AppleTalk that defines AppleTalk Phase 2
    extensions to AppleTalk protocols that provide enhanced AppleTalk
    addressing, routing, and naming services. Available from APDA.
    Inside AppleTalk, second edition, is a technical reference that
    describes the AppleTalk protocols in detail and includes
    information about AppleTalk Phase 2. Published by Addison-Wesley
    Publishing Company.
    The Local Area Network Cabling Guide provides information about
    network media, topologies, and network types. Available from Apple
    Computer.
    Planning and Managing AppleTalk Networks provides in-depth
    information for network administrators about planning and managing
    AppleTalk networks-including AppleTalk terms and concepts, and
    information about network services, media, topologies, security,
    monitoring and optimizing network performance, and
    troubleshooting.  Published by Addison-Wesley Publishing Company.
    Understanding Computer Networks provides an overview of
    networking-including basic information about protocol
    architectures, network media, and topologies. Published by
    Addison-Wesley Publishing Company.
    The AppleTalk Update-Based Routing Protocol Specification is the
    official Apple specification of AURP.  It includes the artwork
    currently missing from this document. Available from APDA.

Oppenheimer [Page 4] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

Table of Contents

1. Introduction to the AppleTalk Update-Based Routing Protocol 6

  Wide area routing enhancements provided by AURP                    6

2. Wide Area AppleTalk Connectivity 7

  AppleTalk tunneling                                                7
  IP tunneling                                                      14
  Point-to-point tunneling                                          17

3. Propagating Routing Information With the AppleTalk Update-Based

  Routing Protocol                                                  18
  AURP architectural model                                          18
  Maintaining current routing information with AURP                 20
  AURP-Tr                                                           21
  One-way connections                                               22
  Initial information exchange                                      22
  Reobtaining routing information                                   28
  Updating routing information                                      28
  Processing update events                                          33
  Router-down notification                                          38
  Obtaining zone information                                        40
  Hiding local networks from remote networks                        44
  AURP packet format                                                45
  Error codes                                                       55

4. Representing Wide Area Network Information 56

  Network hiding                                                    56
  Device hiding                                                     57
  Resolving network-numbering conflicts                             59
  Zone-name management                                              65
  Hop-count reduction                                               66
  Routing loops                                                     67
  Using alternative paths                                           71
  Network management                                                73

Appendix. Implementation Details 75

  State diagrams                                                    75
  AURP table overflow                                               75
  A scheme for updates following initial information exchange       75
  Implementation effort for different components of AURP            76
  Creating free-trade zones                                         77
  Implementation details for clustering                             78
  Modified RTMP algorithms for a backup path                        79

Security Considerations 82 Author's Address 82

Oppenheimer [Page 5] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

1. INTRODUCTION TO THE APPLETALK UPDATE-BASED ROUTING PROTOCOL

 The AppleTalk Update-based Routing Protocol (AURP) provides wide area
 routing enhancements to the AppleTalk routing protocols and is fully
 compatible with AppleTalk Phase 2. AURP consists of three major
 components:
    AppleTalk tunneling through foreign network systems-for example,
    TCP/IP (Transmission Control Protocol/Internet Protocol) and over
    point-to-point links
    the propagation of routing information between internet routers
    connected through foreign network systems or over point-to-point
    links
    the presentation of AppleTalk network information by an internet
    router to nodes or to other Phase 2-compatible routers on its local
    internet-in other words, on the AppleTalk internet connected
    directly to the router
 Chapter 3, "Propagating Routing Information With the AppleTalk
 Update-Based Routing Protocol," describes the elements of AURP that
 are essential for a minimal implementation of AURP. AURP includes
 many optional features for the presentation of network information.
 You can implement many of these optional features on routers that use
 either AURP or RTMP (Routing Table Maintenance Protocol) for
 routing-information propagation.
 Figure 1-1 shows how the three major components of AURP interact.
               <<Figure 1-1  Major components of AURP>>
 Wide Area Routing Enhancements Provided by AURP
 AURP provides AppleTalk Phase 2-compatible routing for large wide
 area networks (WANs). Key wide area routing enhancements provided by
 AURP include:
    tunneling through TCP/IP internets and other foreign network
    systems
    point-to-point tunneling
    basic security-including device hiding and network hiding
    remapping of remote network numbers to resolve numbering conflicts

Oppenheimer [Page 6] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    internet clustering to minimize routing traffic and routing-
    information storage requirements
    hop-count reduction to allow the creation of larger internets
    improved use of alternate paths through hop-count weighting and
    the designation of backup paths

2. WIDE AREA APPLETALK CONNECTIVITY

 This chapter describes the wide area connectivity capabilities
 provided by the AppleTalk Update-based Routing Protocol (AURP),
 including:
    AppleTalk tunneling
    tunneling through TCP/IP internets
    tunneling over point-to-point links
 AppleTalk Tunneling
 Tunneling allows a network administrator to connect two or more
 native internets through a foreign network system to form a large
 wide area network (WAN). For example, an AppleTalk WAN might consist
 of two or more native AppleTalk internets connected through a tunnel
 built on a TCP/IP internet. In such an AppleTalk WAN, native
 internets use AppleTalk protocols, while the foreign network system
 uses a different protocol family.
 A tunnel connecting AppleTalk internets functions as a single,
 virtual data link between the internets. A tunnel can be either a
 foreign network system or a point-to-point link. Figure 2-1 shows an
 AppleTalk tunnel.
                   <<Figure 2-1  AppleTalk tunnel>>
 There are two types of tunnels:
    dual-endpoint tunnels, which have only two routers on a tunnel-for
    example, point-to-point tunnels
    multiple-endpoint tunnels-herein referred to as multipoint tunnels-
    which have two or more routers on a tunnel
 AURP implements multipoint tunneling by providing mechanisms for data
 encapsulation and the propagation of routing information to specific
 routers.

Oppenheimer [Page 7] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 Exterior Routers
 An AppleTalk router with a port that connects an AppleTalk internet
 to a tunnel is an exterior router. An exterior router always sends
 split-horizoned routing information to the other exterior routers on
 a multipoint tunnel. That is, an exterior router on a multipoint
 tunnel sends routing information for only its local internet to other
 exterior routers on that tunnel. An exterior router never exports
 routing information obtained from other exterior routers on the
 tunnel, because the exterior routers communicate their own routing
 information to one another.
 As shown in Figure 2-2, the absence or presence of redundant paths,
 or loops, across a tunnel changes the way an exterior router defines
 its local internet. For more information about redundant paths, see
 the section "Redundant Paths" in Chapter 4. If no loops exist across
 a tunnel, an exterior router's local internet comprises all networks
 connected directly or indirectly to other ports on the exterior
 router.  When loops exist across a tunnel, an exterior router's local
 internet comprises only those networks for which the next internet
 router is not across a tunnel. Using this definition of a local
 internet, two exterior routers' local internets might overlap if
 loops existed across a tunnel.  For more information about routing
 loops, see the section "Routing Loops" in Chapter 4.
          <<Figure 2-2  An exterior router's local internet>>
 An exterior router functions as an AppleTalk router within its local
 internet and as an end node in the foreign network system connecting
 AppleTalk internets. An exterior router uses RTMP to communicate
 routing information to its local internet, and uses AURP and the
 network-layer protocol of the tunnel's underlying foreign network
 system to communicate with other exterior routers connected to the
 tunnel. An exterior router encapsulates AppleTalk data packets using
 the headers required by the foreign network system, then forwards the
 packets to another exterior router connected to the tunnel.
 FORWARDING DATA: When forwarding AppleTalk data packets across a
 multipoint tunnel, an exterior router
    encapsulates the AppleTalk data packets in the packets of the
    tunnel's underlying foreign network system by adding the headers
    required by that network system
    adds an AURP-specific header-called a domain header-immediately
    preceding each AppleTalk data packet

Oppenheimer [Page 8] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 A domain header contains additional addressing information-including
 a source domain identifier and destination domain identifier. For
 more information about domain headers, see the sections "AppleTalk
 Data-Packet Format" and "AppleTalk Data-Packet Format for IP
 Tunneling" later in this chapter. For detailed information about
 domain identifiers, see the section "Domain Identifiers" later in
 this chapter.
 Before forwarding a data packet to a network in another exterior
 router's local internet, an exterior router must obtain the foreign-
 protocol address of the exterior router that is the next internet
 router in the path to the packet's destination network. The exterior
 router then sends the packet to that exterior router's foreign-
 protocol address using the network-layer protocol of the foreign
 network system. The exterior router need not know anything further
 about how the packet traverses this virtual data link.
 Once the destination exterior router receives the packet, it removes
 the headers required by the foreign network system and the domain
 header, then forwards the packet to its destination in the local
 AppleTalk internet.
 If the length of an AppleTalk data packet in bytes is greater than
 that of the data field of a foreign-protocol packet, a forwarding
 exterior router must fragment the AppleTalk data packet into multiple
 foreign-protocol packets, then forward these packets to their
 destination. Once the destination exterior router receives all of the
 fragments that make up the AppleTalk data packet, it reassembles the
 packet.
 CONNECTING MULTIPLE TUNNELS TO AN EXTERIOR ROUTER: An exterior router
 can also connect two or more multipoint tunnels. As shown in Figure
 2-3, when an exterior router connects more than one multipoint
 tunnel, the tunnels can be built on any of the following:
    the same foreign network system
    different foreign network systems
    similar, but distinct foreign network systems
   <<Figure 2-3  Connecting multiple tunnels to an exterior router>>
 Whether the tunnels connected to an exterior router are built on
 similar or different foreign network systems, each tunnel acts as an
 independent, virtual data link. As shown in Figure 2-4, an exterior
 router connected to multiple tunnels functions logically as though it
 were two or more exterior routers connected to the same AppleTalk

Oppenheimer [Page 9] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 network, with each exterior router connected to a different tunnel.
   <<Figure 2-4  An exterior router connected to multiple tunnels>>
 Fully Connected and Partially Connected Tunnels
 An AppleTalk multipoint tunnel functions as a virtual data link. AURP
 assumes full connectivity across a multipoint tunnel-that is, all
 exterior routers on such a tunnel can communicate with one another.
 An exterior router always sends split-horizoned routing information
 to other exterior routers on a multipoint tunnel. That is, an
 exterior router on a multipoint tunnel sends routing information for
 only its local internet to other exterior routers on that tunnel. An
 exterior router never exports routing information obtained from other
 exterior routers on the tunnel, because exterior routers communicate
 their routing information to one another.
 If all exterior routers connected to a multipoint tunnel are aware of
 and can send packets to one another, that tunnel is fully connected.
 If some of the exterior routers on a multipoint tunnel are not aware
 of one another, the tunnel is only partially connected. Figure 2-5
 shows examples of a fully connected tunnel, a partially connected
 tunnel, and two fully connected tunnels.
    <<Figure 2-5  Fully connected and partially connected tunnels>>
 In the second example shown in Figure 2-5, the network administrator
 may have connected the tunnel partially for one of these reasons:
    to prevent the local internets connected to exterior routers A and
    C from communicating with one another, while providing full
    connectivity between the local internets connected to exterior
    router
    B and the local internets connected to both exterior routers A and
    C
    because local internets connected to exterior routers A and C need
    access only to local internets connected to exterior router B-not
    to each other's local internets
    because exterior routers A and C-which should be aware of one
    another-were misconfigured
 Generally, an exterior router cannot determine whether a multipoint
 tunnel is fully connected or partially connected. In the second
 example in Figure 2-5, exterior router B does not know whether
 exterior routers A and C are aware of one another. However, exterior

Oppenheimer [Page 10] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 router B must assume that the tunnel is fully connected, and that
 exterior routers A and C can exchange routing information. An
 exterior router should never forward routing information received
 from other exterior routers back across the tunnel. It should always
 send split-horizoned routing information to other exterior routers.
 If connecting exterior routers A and C directly would be either
 expensive or slow, a network administrator could instead establish
 two independent multipoint tunnels-one connecting exterior routers A
 and B, another connecting exterior routers B and C-as shown in the
 third example in Figure 2-5. Exterior routers A and C could then
 establish connectivity by routing all data packets forwarded by one
 to the other through exterior router B.
 Hiding Local Networks From Tunnels
 When configuring a tunneling port on an exterior router, a network
 administrator can provide network-level security to a network in the
 exterior router's local internet by hiding that network. Hiding a
 specific network in the exterior router's local internet prevents
 internets across a multipoint tunnel from becoming aware of the
 presence of that network. When the exterior router exchanges routing
 information with other exterior routers connected to the tunnel, it
 exports no information about any hidden networks to the exterior
 routers from which the networks are hidden.
 An administrator can specify that certain networks in the exterior
 router's local internet be hidden from a specific exterior router
 connected to the tunnel or from all exterior routers on the tunnel.
 Nodes on the local internet of an exterior router from which a
 network is hidden cannot access that network. Neither the zones on a
 hidden network nor the names of devices in those zones appear in the
 Chooser on computers connected to such an internet. When a network is
 hidden, its nodes are also unable to access internets from which the
 network is hidden. If a node on a hidden network sends a packet
 across a tunnel to a node on an internet from which it is hidden,
 even if the packet arrives at its destination, the receiving node
 cannot respond. The exterior router connected to the receiving node's
 internet does not know the return path to the node on the hidden
 network. Thus, it appears to the node on the hidden network that the
 node to which it sent the packet is inaccessible.
 ADVANTAGES AND DISADVANTAGES OF NETWORK HIDING: Network hiding
 provides the following advantages:
    On large, global WANs, a network administrator can configure
    network-level security for an organization's internets.

Oppenheimer [Page 11] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    It reduces the amount of network traffic across both a tunnel and
    the internets connected to that tunnel.
 Network hiding has the following disadvantages:
    Nodes on hidden networks have limited access to internets across a
    tunnel.
    AppleTalk networking software running on a node on a hidden network
    lists all of the AppleTalk zone names exported by exterior routers
    connected to a tunnel, but may list the names of only some or none
    of the devices in those zones. It cannot list the names of devices
    that are unable to respond to Name Binding Protocol (NBP) lookups
    originating from a node on a hidden network.
 Domain Identifiers
 Exterior routers assign a unique domain identifier to each AppleTalk
 internet, or domain. Domain identifiers enable exterior routers on a
 multipoint tunnel to distinguish individual AppleTalk internets in a
 wide area internet from one another.
 The definition of an AppleTalk domain identifier is extensible to
 allow for future use when many additional types of AppleTalk tunnels
 and tunneling topologies may exist:
    Under the current version of AURP, each exterior router connected
    to a multipoint tunnel assigns a domain identifier to its local
    AppleTalk internet that uniquely identifies that internet on the
    tunnel. If redundant paths connect an AppleTalk internet through
    more than one exterior router on a tunnel, each exterior router can
    assign a different domain identifier to that internet, or AppleTalk
    domain, as shown in Figure 2-6.
    Under future routing protocols, a domain identifier will define the
    boundaries of an AppleTalk domain globally-for all exterior
    routers.  Thus, a domain identifier will be unique among all
    domains in a wide area internet. All exterior routers within a wide
    area internet will use the same domain identifier for a given
    AppleTalk internet, as shown in Figure 2-6.
                  <<Figure 2-6  Domain identifiers>>
 To simplify an exterior router's port configuration, a parameter that
 is already administrated-such as a node address-can serve as the
 basis for an exterior router's domain identifier.

Oppenheimer [Page 12] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 GENERAL DOMAIN-IDENTIFIER FORMAT: Figure 2-7 shows the general form
 of a domain identifier.
           <<Figure 2-7  General domain-identifier format>>
 The general domain identifier (DI) consists of the following fields:
 Length:  Byte 1 represents the length of the DI in bytes, not
 including the length byte. A DI must consist of an even number of
 bytes. Thus, the length byte is always an odd-numbered byte. The
 length field permits tunneling through foreign network systems that
 have addresses of any length-including the long addresses
 characteristic of X.25 and OSI. The value of the length byte varies,
 depending on the format of the DI.
 Authority:  Byte 2 indicates the authority that administrates the
 identifier bytes of the DI. At present, Apple has defined only two
 authority-byte values:
    $01-indicates that the subsequent bytes correspond to a unique,
    centrally administrated IP address
    $00-the null DI-indicates that no additional bytes follow
 All other authority-byte values are reserved and should not be used.
 Identifier:  The identifier field starts at byte 3 and consists of a
 variable number of bytes of the type indicated by the authority byte.
 NULL DOMAIN-IDENTIFIER FORMAT: The use of a null domain identifier is
 appropriate only when there is no need to distinguish the domains
 connected to a tunnel-for example, where a tunnel exists within a
 single internet-or for a point-to-point link. Figure 2-8 shows the
 null form of a domain identifier.
             <<Figure 2-8  Null domain-identifier format>>
 A null domain identifier consists of the following bytes:
 Length:  Byte 1 contains the value $01, defining the length of the
 null DI as one byte.
 Authority:  Byte 2 contains the value $00, indicating a null DI.
 AppleTalk Data-Packet Format
 Part of the format of an AppleTalk data packet sent across a
 multipoint tunnel or a point-to-point link depends on the underlying

Oppenheimer [Page 13] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 foreign network system. The headers required by a foreign-network
 protocol always precede an AppleTalk data packet sent across a
 multipoint tunnel.  A domain header generally immediately precedes
 the AppleTalk data packet. Figure 2-9 shows the format of an
 AppleTalk data packet preceded by a domain header.
   <<Figure 2-9  AppleTalk data-packet format with a domain header>>
 A domain header consists of the following fields:
 Destination DI:  The length of the destination DI field in bytes
 depends on the type of DI.
 Source DI:  The length of the source DI field in bytes depends on the
 type of DI.
 Version number:  The version number field is two bytes in length and
 currently contains the value 0001.
 Reserved:  The two-byte field that follows the version number field
 is reserved for future use and is set to 0000.
 Packet type:  The two-byte packet type field contains the value 0002
 to identify the data that follows as AppleTalk data-distinguishing it
 from other data, such as routing data. In the future, Apple may
 define other values for this field.
 An AppleTalk data packet does not require a domain header if
    it is sent across a multipoint tunnel or point-to-point link that
    provides separate channels for data and routing packets
    the domain header's destination DI and source DI fields would both
    contain null DIs
 Omitting a domain header reduces overhead associated with the
 exchange of routing information, without any loss of routing
 information. Figure 2-10 shows the format of an AppleTalk data packet
 without a domain header.
 <<Figure 2-10  AppleTalk data-packet format without a domain header>>
 IP Tunneling
 The Transmission Control Protocol/Internet Protocol (TCP/IP) protocol
 suite is a widely used communications standard that provides
 interoperability among computers from various vendors, including
 Apple, IBM, Digital Equipment Corporation, Sun, and Hewlett-Packard.

Oppenheimer [Page 14] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 Descriptions of three of the most important TCP/IP protocols follow:
    The Transmission Control Protocol (TCP) is a transport-layer
    protocol that provides reliable data transmission between
    processes-that is, between programs that communicate with one
    another. This connection-oriented, byte-stream protocol ensures
    error-free, sequential data delivery, without loss or duplication.
    The User Datagram Protocol (UDP) is a transport-layer protocol
    that provides best-effort, low-overhead interprocess data
    transmission.  This datagram-oriented protocol allows higher-layer
    protocols that do not require reliability to transmit data without
    incurring the overhead associated with TCP. UDP does no error
    checking, does not acknowledge its successful receipt of data,
    and does not sequence incoming messages. UDP messages may be lost,
    duplicated, or improperly sequenced.
    The Internet Protocol (IP) is a network-layer protocol that
    provides connectionless, best-effort datagram delivery across
    multiple networks. Each host on a TCP/IP network has a unique,
    centrally administrated internet address, called an IP address,
    that identifies the node. The header of an IP datagram contains its
    source and destination IP addresses, allowing any host to route a
    datagram to its destination. TCP/IP provides connectivity between
    many different network types that use data frames of various sizes.
    Therefore, IP can fragment a datagram before sending it across an
    internet.  Datagram fragments can fit into data frames of any size.
    Once all of a datagram's fragments reach their destination, IP
    reassembles the datagram.
 Protocols in higher layers pass data to TCP or UDP for delivery to
 peer processes. TCP and UDP encapsulate the data in segments, using
 the appropriate headers, then pass the segments to IP. IP further
 encapsulates the data in IP datagrams, determines each datagram's
 path to its destination, and sends the datagrams across the internet.
 Figure 2-11 shows how the TCP/IP family of protocols conforms to the
 Open Systems Interconnection (OSI) model.
       <<Figure 2-11  TCP/IP protocol stack and the OSI model>>
 Exterior routers that connect AppleTalk internets through a TCP/IP
 tunnel are configured as nodes on both an AppleTalk internet and on
 the TCP/IP internet. Thus, an exterior router on a TCP/IP tunnel is
 also an IP end node in the TCP/IP network system. Exterior routers
 use the TCP/IP internet only to exchange AppleTalk routing
 information and AppleTalk data packets with one another. An exterior
 router encapsulates AppleTalk data packets in IP datagrams before

Oppenheimer [Page 15] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 sending them across the TCP/IP internet to a forwarding exterior
 router, which decapsulates the packets, then forwards them to their
 destination AppleTalk networks.
 IP Domain-Identifier Format
 Under the current version of AURP, exterior routers on IP tunnels
 must use domain identifiers that are based on IP addresses. An
 exterior router on an IP tunnel derives its domain identifier from
 its IP address. Thus, a network administrator does not need to
 configure an exterior router's domain identifier. Figure 2-12 shows
 the IP form of a domain identifier.
             <<Figure 2-12  IP domain-identifier format>>
 An IP domain identifier consists of the following fields:
 Length:  Byte 1 contains the value $07, defining the length of the IP
 DI as seven bytes.
 Authority:  Byte 2 contains the value $01, indicating that the
 remainder of the DI is based on an IP address.
 Distinguisher:  Bytes 3 and 4 are reserved for future use and are set
 to 0 ($00).
 IP address:  Bytes 5 through 8 contain the four-byte IP address of
 either the sending or the receiving exterior router.
 NOTE:  Future versions of AURP will allow exterior routers to
 usealternative formats for domain identifiers, even on IP tunnels.
 AppleTalk Data-Packet Format for IP Tunneling
 The following protocol headers precede an AppleTalk data packet that
 is forwarded across an IP tunnel by an exterior router:
    a data-link header
    an IP header
    a User Datagram Protocol (UDP) header
    a domain header
 An exterior router encapsulates AppleTalk data packets in UDP packets
 when forwarding them through its UDP port 387, across an IP tunnel,
 to UDP port 387 on another exterior router. When encapsulating data

Oppenheimer [Page 16] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 packets, an exterior router should always use UDP checksums. When a
 destination exterior router receives the UDP packets at UDP port 387,
 it decapsulates the packets.
 A domain header consists of the following fields:
 Destination DI:  This field contains the DI of the exterior router to
 which a packet is being forwarded.
 Source DI:  This field contains the DI of the exterior router that is
 forwarding a packet.
 Version number:  The version number field is two bytes in length and
 currently contains the value 0001.
 Reserved:  The two-byte field that follows the version number field
 is reserved for future use and is set to 0000.
 Packet type:  The two-byte packet type field contains the value 0002
 to identify the data that follows as AppleTalk data-distinguishing it
 from other data, such as routing data.
 An AppleTalk data packet consists of a domain header and AppleTalk
 data.  Figure 2-13 shows the format of an AppleTalk data packet
 forwarded across an IP tunnel.
 <<Figure 2-13  AppleTalk data packet forwarded across an IP tunnel>>
 Point-to-Point Tunneling
 In point-to-point tunneling, two remote AppleTalk local area networks
 (LANs) connected to half-routers communicate with one another over a
 point-to-point link. A point-to-point link may consist of modems
 communicating over a standard telephone line or a leased line, such
 as a T1 line. Figure 2-14 shows an example of point-to-point
 tunneling.
               <<Figure 2-14  Point-to-point tunneling>>
 Generally, exterior routers use null domain identifiers on point-to-
 point links, because there is no IP address to be administrated and
 the opposite end of the tunnel is already uniquely identified.
 However, an exterior router may use other domain-identifier formats.
 Point-to-Point Protocol
 The Point-to-Point Protocol (PPP) is a data-link-layer protocol that
 provides a standard method of encapsulating and decapsulating

Oppenheimer [Page 17] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 network-layer protocol information, and transmitting that information
 over point-to-point links. PPP includes an extensible Link Control
 Protocol (LCP) and a suite of Network Control Protocols (NCPs) that
 configure, enable, and disable various network-layer protocols.
 The AppleTalk Control Protocol (ATCP) is a PPP NCP for AppleTalk
 protocols. ATCP configures, enables, and disables the AppleTalk
 network-layer protocol DDP on the half-router at each end of a
 point-to-point link. ATCP also specifies the protocol that a half-
 router uses to propagate routing information-for example, AURP.  When
 using AURP for routing-information propagation, a half-router uses a
 specific PPP protocol type to identify AURP routing-information
 packets-that is, packets preceded by a domain header. PPP provides
 separate channels for AppleTalk data packets and AppleTalk routing-
 information packets. Thus, a half-router can use DDP encapsulation to
 send AppleTalk data packets without including their domain headers.
 When using AURP, a half-router should accept both AppleTalk data
 packets that are preceded by domain headers and DDP-encapsulated
 packets.
 NOTE:  The Request for Comments (RFC) 1378, "The PPP AppleTalk
 Control Protocol (ATCP)," provides a detailed specification of ATCP,
 as well as information about using PPP to send AppleTalk data.

3. PROPAGATING ROUTING INFORMATION WITH THE APPLETALK UPDATE-BASED

  ROUTING PROTOCOL
 This chapter describes the required elements of AURP. It provides
 detailed information about using the AppleTalk Update-based Routing
 Protocol (AURP) to propagate routing information between AppleTalk
 exterior routers connected through a foreign network or over a
 point-to-point link, and includes information about
    the AURP architectural model
    one-way connections
    exchanging routing information
    updating routing information
    notifying other exterior routers that an exterior router is going
    down
    obtaining zone information
    packet formats

Oppenheimer [Page 18] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    error codes
 AURP Architectural Model
 AURP provides the functionality of the Routing Table Maintenance
 Protocol (RTMP) and the Zone Information Protocol (ZIP) while
 eliminating most of the routing traffic generated by these protocols.
 Figure 3-1 shows the architectural model for AURP.
               <<Figure 3-1  AURP architectural model>>
 Generally, an AppleTalk router uses RTMP and ZIP to maintain routing
 information, and sends RTMP data packets, ZIP Queries, and ZIP
 Replies out its ports. However, if one of the router's ports is
 connected to an AppleTalk tunnel, the architectural model for the
 router's central routing module becomes more complex. Logically, the
 central routing module in an exterior router communicates RTMP and
 ZIP information to an RTMP/ZIP-to-AURP conversion module, which sends
 AURP data packets out the tunneling port.
 RTMP/ZIP-to-AURP Conversion Module
 The RTMP/ZIP-to-AURP conversion module maintains split-horizoned
 routing-table information and network number-to-zone name mappings
 for each exterior router on the tunnel-that is, a copy of the routing
 information for each exterior router's local internet. Figure 3-2
 shows the architectural components of the RTMP/ZIP-to-AURP conversion
 module.
    <<Figure 3-2  RTMP/ZIP-to-AURP conversion module architecture>>
 The AURP module of the conversion module obtains routing information
 from the other exterior routers on the tunnel, then periodically
 updates the routing-table information and the mappings in the
 conversion module.  The RTMP module passes this routing-table
 information to the exterior router's central routing module.
 Logically, the RTMP module generates an RTMP data packet for each
 exterior router on the tunnel every ten seconds-the RTMP
 retransmission time-then passes the packet to the central routing
 module.
 The RTMP/ZIP-to-AURP conversion module also maintains a split-
 horizoned copy of the routing information maintained by the exterior
 router in which it resides. Logically, the conversion module obtains
 the routing information from RTMP data packets and ZIP Replies sent
 by the exterior router's central routing module, then updates the
 routing information in the conversion module.

Oppenheimer [Page 19] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 The AURP module exports routing information about its local AppleTalk
 internet to other exterior routers on the tunnel.
 AURP Transport Layering
 AURP can propagate routing information between exterior routers using
    a simple, reliable transport based on an underlying datagram
    service-such as the default transport-layer service for AURP,
    AURP-Tr. See the section "AURP-Tr," later in this chapter,
    for more information.
    a more complex transport-layer service-such as TCP
 Figure 3-3 shows the AURP transport-layering model.
             <<Figure 3-3  AURP transport-layering model>>
 Maintaining Current Routing Information With AURP
 AURP allows exterior routers to maintain current routing information
 for other exterior routers on a tunnel by supporting
    the reliable, initial exchange of split-horizoned routing
    information - that is, the routing information for an exterior
    router's local internet
    reliable updates to that information whenever it changes
 If an internet topology does not change, AURP generates significantly
 less routing traffic than RTMP and ZIP. Thus, an administrator can
 connect very large AppleTalk internets through a tunnel, and the
 resulting internet generates little or no routing traffic on the
 tunnel.
 When an exterior router discovers another exterior router on the
 tunnel-that is, a peer exterior router-it can request that exterior
 router to send its routing information. In a reliable, initial
 exchange of split-horizoned routing information, the peer exterior
 router returns its network-number list. The peer exterior router also
 returns each connected network's zone information in an unsequenced
 series of zone-information packets. If the exterior router requesting
 the routing information does not receive complete zone information
 for a network, it must retransmit requests for zone information until
 it receives the information.
 Once an exterior router requesting routing information from a peer
 exterior router has received that exterior router's network-number

Oppenheimer [Page 20] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 list and complete zone information, it typically requests the peer
 exterior router to notify it of any changes to that routing
 information. The peer exterior router then provides the requesting
 exterior router with reliable updates to its routing information-
 however, it sends no other routing information.
 Notifying Other Exterior Routers of Events
 If an exterior router has requested notification of changes in
 another exterior router's split-horizoned routing information, that
 exterior router must notify the requesting exterior router of any
 event that changes its routing information. Thus, an exterior router
 must send updated routing information to the requesting exterior
 router whenever any of the following events occur:
    the addition of a new, exported network-that is, a network that is
    not hidden-to the exterior router's local internet and,
    consequently, to its routing table
    a change in the path to an exported network that causes the
    exterior router to access that network through its local internet
    rather than through a tunneling port
    the removal of an exported network from the exterior router's
    routing table because a network in the exterior router's local
    internet has gone down
    a change in the path to an exported network that causes the
    exterior router to access that network through a tunneling port
    rather than through its local internet
    a change in the distance to an exported network
    a change to a zone name in the zone list of an exported network-
    an event not currently supported by ZIP or the current version of
    AURP
    the exterior router goes down or is shut down
 Routing-information updates allow an exterior router to maintain
 accurate, split-horizoned routing information for a peer exterior
 router on a tunnel.
 AURP-Tr
 AURP-Tr, the default transport-layer service for AURP, provides a
 simple, reliable transport that is based on an underlying datagram
 service. When using AURP-Tr, only one sequenced transaction can be

Oppenheimer [Page 21] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 outstanding, or unacknowledged, at a time-greatly simplifying the
 implementation of AURP, without limiting its functionality.
 One-Way Connections
 A one-way connection is an asymmetrical link between a data sender
 and a data receiver that are using AURP-Tr, in which an exterior
 router functioning as a data sender sends a sequenced, reliable,
 unidirectional data stream to an exterior router functioning as a
 data receiver.  An exterior router can send routing information over
 a one-way connection as
    sequenced data
    transaction data
 Sequenced data is data sent in sequence by the data sender and
 delivered reliably to the data receiver. Typically, the sending of
 sequenced data is unprovoked-that is, it is not requested by a data
 receiver. However, a data receiver can request sequenced data. Figure
 3-4 shows sequenced data being sent across a one-way connection.
        <<Figure 3-4  Sequenced data on a one-way connection>>
 Transaction data-also referred to as out-of-band data-is data sent
 unsequenced by the data sender through a linked request/response
 transaction that is initiated by the data receiver.
 The data receiver can use a one-way connection to request transaction
 data from the data sender. If the data receiver does not receive a
 response, it must retransmit its request. Figure 3-5 shows a one-way
 connection on which the data receiver requests transaction data from
 the data sender.
 <<Figure 3-5  Request for transaction data on a one-way connection>>
 Generally, communication between two exterior routers is
 bidirectional-that is, two one-way connections exist between the
 exterior routers, with each exterior router acting as the data sender
 on one connection and the data receiver on the other. Thus, each
 exterior router can send its routing information to the other.
 Initial Information Exchange
 When an AppleTalk exterior router discovers another exterior router
 on the tunnel, it uses the underlying transport-layer service to open
 a connection with that exterior router. When using AURP-Tr, an
 exterior router opens this connection as a one-way connection.

Oppenheimer [Page 22] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 Open Request Packet
 Once the data receiver opens a connection using the underlying
 transport, the data receiver sends an Open Request packet, or Open-
 Req, to the data sender. An Open-Req packet includes the following
 information:
 Send update information flags:  The states of the four send update
 information (SUI) flags indicate whether the data sender should send
 various types of update information over the connection. Typically,
 the four SUI flags are set to 1.
 Version number:  The version number field indicates the version of
 AURP used by the data receiver. The current version number of AURP is
 1.
 Data field:  The optional data field allows exterior routers with
 capabilities beyond those described in this document to notify other
 exterior routers about such options, by initiating option
 negotiation.  An exterior router that has similar capabilities
 indicates that it accepts the options, completing option negotiation.
 An exterior router that lacks such options ignores the information in
 the data field.
 Open Response Packet
 When an exterior router receives an Open-Req, it becomes the data
 sender and responds with an Open Response packet, or Open-Rsp, as
 follows:
    If the exterior router accepts the connection, it returns
    information about its setup in the Open-Rsp. An Open-Rsp also
    contains an optional data field. This data field indicates whether
    the exterior router accepts the options in the data field of the
    Open-Req to which it is responding.
    If the exterior router cannot accept the connection-for example,
    because the Open-Req does not contain the correct version number-it
    returns an error in the Open-Rsp and closes the transport-layer
    connection.
 Figure 3-6 shows a connection-opening dialog between a data sender
 and a data receiver.
               <<Figure 3-6  Connection-opening dialog>>

Oppenheimer [Page 23] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 Routing Information Request Packet
 Under AURP, once two exterior routers establish a connection, the
 data receiver can request the data sender to send its routing
 information by sending it a Routing Information Request packet, or
 RI-Req.
 Routing Information Response Packets
 When the data sender receives an RI-Req, it reliably sends a sequence
 of Routing Information Response packets, or RI-Rsp, to the exterior
 router requesting the information.
 The RI-Rsp packets provide a list of exported networks on the data
 sender's local internet and the distance of each network from the
 data sender. The data sender must finish sending RI-Rsp packets to
 the exterior router requesting routing information before it can send
 any other sequenced data over the connection. Figure 3-7 shows a
 routing-information request/response dialog between a data sender and
 a data receiver.
      <<Figure 3-7  Routing-information request/response dialog>>
 Zone Information Request Packet
 The data receiver can obtain zone information for known networks on
 the data sender's local internet at any time, by sending it a Zone
 Information Request packet, or ZI-Req. A ZI-Req lists the numbers of
 networks for which the data receiver is requesting zone information.
 IMPORTANT: To prevent other exterior routers on a tunnel from sending
 endless streams of ZI-Req packets across the tunnel-causing what is
 referred to as a ZIP storm-an exterior router must not export
 information about a network until it has a complete zone list for
 that network.
 Zone Information Response Packets
 When the data sender receives a ZI-Req, it responds by sending
 unsequenced Zone Information Response packets, or ZI-Rsp, to the data
 receiver. Zone information is transaction data-thus, its reliable
 delivery is not guaranteed. Figure 3-8 shows a zone-information
 request/response dialog between a data sender and a data receiver.
       <<Figure 3-8  Zone-information request/response dialog>>

Oppenheimer [Page 24] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 Recovering Lost Zone Information
 A data receiver enters a network-to-zone list association in its
 routing table for each network for which it receives a ZI-Rsp packet.
 If a data receiver that requested zone information for a network does
 not receive a complete zone list for that network, it must retransmit
 ZI-Req packets, requesting zone information for that network, until
 it receives that network's complete zone information.
 To determine if any ZI-Rsp packets were lost, the data receiver
 periodically scans its routing table for networks for which the
 associated zone lists are incomplete-that is, for zone lists that do
 not include all zones associated with the networks. The data receiver
 sends a ZI-Req to each data sender from which it received incomplete
 zone information, listing the numbers of networks for which it has
 incomplete zone lists. The data sender responds to zone information
 requests by sending ZI-Rsp packets containing the requested
 information to the data receiver.
 Using AURP-Tr for Initial Information Exchange
 The following sections describe the use of AURP-Tr-the default
 transport-layer service for AURP-for initial information exchange.
 OPEN REQUEST PACKET: An exterior router sends an Open-Req packet to
    request that an AURP-Tr one-way connection with another exterior
    router be established
    specify the connection ID for that connection
    pass the AURP version number, SUI flags, and optional data to the
    other exterior router
 If the exterior router does not receive an Open-Rsp from the exterior
 router to which it sent an Open-Req, it must retransmit the Open-Req.
 OPEN RESPONSE PACKET: When using AURP-Tr, an exterior router sends an
 Open-Rsp to
    acknowledge that a one-way connection has been established
    reject a connection
    return information about its environment, as well as any optional
    data, to the exterior router from which it received an Open-Req

Oppenheimer [Page 25] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 If an exterior router receives an Open-Req on a one-way connection
 that is already open-that is, if it receives an Open-Req with the
 same connection ID as an open one-way connection-an Open-Rsp sent
 previously may have been lost. The exterior router receiving the
 duplicate Open-Req should send a duplicate Open-Rsp to the sending
 exterior router, unless it has already received some other packet on
 the connection-such as an RI-Req-indicating the existence of a fully
 established connection.
 ROUTING INFORMATION RESPONSE PACKETS: When responding to a request
 for routing information using AURP-Tr, an exterior router sends a
 sequence of RI-Rsp packets to the exterior router requesting the
 information.  However, an exterior router's complete list of network
 numbers often fits in a single RI-Rsp packet. Each RI-Rsp packet
 contains the following information:
 Connection ID:  The connection ID identifies the specific one-way
 connection to which a packet belongs.
 Sequence number:  The sequence number identifies an individual packet
 on a connection. Packets on a connection are numbered starting with
 the number 1.
 The data sender sending routing information must wait for the data
 receiver to acknowledge that it has received each RI-Rsp packet in
 the sequence-by sending an RI-Ack packet-before sending the next RI-
 Rsp packet. Each RI-Rsp contains a flag that indicates whether it is
 the last packet in the sequence. In the last RI-Rsp in the sequence,
 this flag is set to 1. If the data sender receives no acknowledgment
 of an RI-Rsp from the data receiver within a specified period of
 time, it must retransmit the RI-Rsp.
 ROUTING INFORMATION RESPONSE PACKETS: When an exterior router
 receives an RI-Rsp, it verifies the packet's connection ID and
 sequence number.  The connection ID must be the same as that in the
 Open-Req. 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-Rsp the next number in the sequence, indicating that this
    RI-Rsp contains new routing information
 If the connection ID or sequence number is invalid, the data receiver
 discards the packet. Figure 3-9 shows a dialog between a data sender
 and a data receiver in which the data receiver requests routing
 information, the data sender responds by sending its routing
 information, and the data receiver acknowledges the data sender's
 response. If the data sender receives no acknowledgment, it sends

Oppenheimer [Page 26] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 duplicate RI-Rsp packets until the data receiver responds with an
 acknowledgment.
   <<Figure 3-9 Routing-information request/response/acknowledgment
                               dialog>>
 Once the data receiver has verified the information in the RI-Rsp, it
 responds with 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-Rsp
 packet.
 Sequence number:  The sequence number is the same as that in the RI-
 Rsp packet.
 Send zone information flag:  The state of the send zone information
 (SZI) flag in an RI-Ack packet indicates whether the RI-Ack packet
 doubles as a ZI-Req packet. If the SZI flag is set to 1, the data
 receiver sends the zone information associated with the networks
 about which it sent routing information in the previous RI-Rsp.
 Figure 3-10 shows a data receiver sending zone information to a data
 sender in response to a ZI-Req and in response to an RI-Ack, which
 optimizes the data flow.
 When the data sender receives an RI-Ack, it verifies that the RI-Ack
 corresponds to the outstanding RI-Rsp-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-Rsp in the sequence, if any.
 <<Figure 3-10  Nonoptimized and optimized flows of zone information>>
 ZONE INFORMATION RESPONSE PACKETS: If the data sender receives an
 RI-Ack with its SZI flag set to 1, it responds by sending ZI-Rsp
 packets that contain the zone information associated with the
 networks about which it sent routing information in the RI-Rsp being
 acknowledged-just as it would if it received a ZI-Req for those
 networks.
 The data sender sends RI-Rsp and ZI-Rsp packets as independent data
 streams. It sends RI-Rsp packets as sequenced data and ZI-Rsp packets
 as transaction data. If the data sender receives an RI-Ack with its
 SZI flag set to 1, it sends an unsequenced series of ZI-Rsp packets
 that contain the following information:
 Connection ID:  The connection ID is the same as that in the

Oppenheimer [Page 27] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 associated RI-Req.
 Network number and zone list tuples: The exterior router sends the
 zone information associated with each network number in the
 corresponding RI-Rsp.
 Reobtaining Routing Information
 An exterior router can reobtain another exterior router's complete
 routing information at any time, by sending an RI-Req packet. An
 exterior router might need to reobtain complete routing information
 for a one-way connection on which it is the data receiver under the
 following circumstances:
    During the initial routing-information exchange, the exterior
    router set the SUI flags in the Open-Req to disable updates. The
    exterior router can subsequently poll the other exterior router on
    the connection by sending an RI-Req to that exterior router to
    determine whether any of its routing information has changed.
    The exterior router set the SUI flags to request updates, but
    suspects that the routing information for the other exterior router
    on the connection is incorrect or obsolete. The exterior router
    should send an RI-Req to the other exterior router to obtain its
    complete, updated routing information.
 Whenever an exterior router receives an RI-Req from an exterior
 router requesting updated routing information, it responds by sending
 RI-Rsp packets, just as it does when it first receives an RI-Req. The
 data sender also resets the SUI flags for that one-way connection, so
 they correspond to those in the RI-Req.
 If the data sender is sending other sequenced update information when
 it receives an RI-Req, it cannot respond to the RI-Req until the data
 receiver acknowledges the last outstanding packet in the sequence.
 If AURP uses an underlying transport-layer service that does not
 provide reliable delivery, such as AURP-Tr, it may be necessary for
 the data receiver to retransmit an RI-Req.
 Updating Routing Information
 Once an exterior router receives the routing and zone information for
 another exterior router's local internet, if the receiving exterior
 router has set the SUI flags in the Open-Req to request updates, the
 data sender notifies the data receiver of any subsequent changes to
 that information.

Oppenheimer [Page 28] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 Informed-Routers List
 An exterior router maintains an informed-routers list containing the
 network address of each exterior router that has requested dynamic
 updating of routing information. Once an exterior router has sent
 routing information for its local internet to other exterior routers
 on the tunnel, it must reliably send updated routing information to
 all accessible exterior routers in its informed-routers list whenever
 its routing information changes.
 Sending Routing Information Update Packets
 An exterior router communicates changes in its routing information by
 sending Routing Information Update, or RI-Upd, packets to another
 exterior router. When the routing information for an exterior
 router's local internet changes, the exterior router need not send an
 RI-Upd immediately. Generally, an exterior router buffers the update
 information, then sends updates periodically. The exterior router
 must wait at least an update interval between sending updates. The
 value of this update interval
    cannot be less than ten seconds
    should be specifiable by a network administrator
 It is possible that more than one update event for a particular
 network might occur within one update interval. One of these events
 might supercede another-for example, a Network Added event followed
 by a Network Deleted event for the same network. In this case, the
 exterior router can represent the two events logically as one event.
 Under AURP, an exterior router can have only one event pending for a
 given network.  An exterior router can combine any series of events
 for a network into a single pending event. In Figure 3-11, a state
 diagram shows the update event that an exterior router should have
 pending for a network, based on the other events that have occurred
 during the update interval.
    <<Figure 3-11  A state diagram showing pending update events>>
 Four of the states correspond to four pending update events. Two
 states indicate that no update event is pending:
    Net Up-indicates that no update event is pending for a network
    in the exterior router's local internet
    Net Down-indicates that no update event is pending for a network in
    another exterior router's local internet or the network does not
    exist

Oppenheimer [Page 29] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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:

Oppenheimer [Page 30] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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.

Oppenheimer [Page 31] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 32] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 33] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 "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

Oppenheimer [Page 34] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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,

Oppenheimer [Page 35] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

       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.

Oppenheimer [Page 36] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 37] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 38] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    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

Oppenheimer [Page 39] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 40] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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.

Oppenheimer [Page 41] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

   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

Oppenheimer [Page 42] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 43] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    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

Oppenheimer [Page 44] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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.

Oppenheimer [Page 45] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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:

Oppenheimer [Page 46] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

                       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.

Oppenheimer [Page 47] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

            <<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

Oppenheimer [Page 48] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    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

Oppenheimer [Page 49] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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.

Oppenheimer [Page 50] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    <<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.

Oppenheimer [Page 51] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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>>

Oppenheimer [Page 52] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 53] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 54] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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. 1 Normal connection close
  2. 2 Routing loop detected
  3. 3 Connection out of sync

Oppenheimer [Page 55] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

  1. 4 Option-negotiation error
  2. 5 Invalid version number
  3. 6 Insufficient resources for connection
  4. 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

Oppenheimer [Page 56] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    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

Oppenheimer [Page 57] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 58] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 59] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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.

Oppenheimer [Page 60] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    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.

Oppenheimer [Page 61] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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.

Oppenheimer [Page 62] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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.

Oppenheimer [Page 63] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 64] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 65] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 66] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 67] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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,

Oppenheimer [Page 68] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

    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

Oppenheimer [Page 69] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 70] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 71] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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.

Oppenheimer [Page 72] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 73] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 74] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

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.

Oppenheimer [Page 75] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 76] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 77] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 78] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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

Oppenheimer [Page 79] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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;

Oppenheimer [Page 80] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

 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;

Oppenheimer [Page 81] RFC 1504 Appletalk Update-Based Routing Protocol August 1993

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.

Oppenheimer [Page 82]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1504.txt · Last modified: 1993/08/25 20:29 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki