Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1504

Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing

Pages: 82
Informational
Part 1 of 3 – Pages 1 to 29
None   None   Next

Top   ToC   RFC1504 - Page 1
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
Top   ToC   RFC1504 - Page 2
      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:
Top   ToC   RFC1504 - Page 3
      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.
Top   ToC   RFC1504 - Page 4
   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.
Top   ToC   RFC1504 - Page 5
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
Top   ToC   RFC1504 - Page 6
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
Top   ToC   RFC1504 - Page 7
      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.
Top   ToC   RFC1504 - Page 8
   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
Top   ToC   RFC1504 - Page 9
   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
Top   ToC   RFC1504 - Page 10
   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
Top   ToC   RFC1504 - Page 11
   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.
Top   ToC   RFC1504 - Page 12
      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.
Top   ToC   RFC1504 - Page 13
   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
Top   ToC   RFC1504 - Page 14
   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.
Top   ToC   RFC1504 - Page 15
   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
Top   ToC   RFC1504 - Page 16
   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
Top   ToC   RFC1504 - Page 17
   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
Top   ToC   RFC1504 - Page 18
   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
Top   ToC   RFC1504 - Page 19
      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.
Top   ToC   RFC1504 - Page 20
   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
Top   ToC   RFC1504 - Page 21
   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
Top   ToC   RFC1504 - Page 22
   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.
Top   ToC   RFC1504 - Page 23
   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>>
Top   ToC   RFC1504 - Page 24
   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>>
Top   ToC   RFC1504 - Page 25
   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
Top   ToC   RFC1504 - Page 26
   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
Top   ToC   RFC1504 - Page 27
   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
Top   ToC   RFC1504 - Page 28
   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.
Top   ToC   RFC1504 - Page 29
   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


(next page on part 2)

Next Section