diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc1504.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc1504.txt')
| -rw-r--r-- | doc/rfc/rfc1504.txt | 4595 |
1 files changed, 4595 insertions, 0 deletions
diff --git a/doc/rfc/rfc1504.txt b/doc/rfc/rfc1504.txt new file mode 100644 index 0000000..3c7c98b --- /dev/null +++ b/doc/rfc/rfc1504.txt @@ -0,0 +1,4595 @@ + + + + + + +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 Normal connection close + -2 Routing loop detected + -3 Connection out of sync + + + +Oppenheimer [Page 55] + +RFC 1504 Appletalk Update-Based Routing Protocol August 1993 + + + -4 Option-negotiation error + -5 Invalid version number + -6 Insufficient resources for connection + -7 Authentication error + +4. REPRESENTING WIDE AREA NETWORK INFORMATION + + This chapter describes optional features of AURP-some of which can + also be implemented on routers that use RTMP rather than AURP for + routing-information propagation. It provides detailed information + about the presentation of wide area network information by exterior + routers to nodes on their local internets or to other exterior + routers, including: + + basic security-both network hiding and device hiding + + remapping of remote network numbers + + internet clustering + + loop detection + + hop-count reduction + + hop-count weighting + + backup paths + + network management + + Network Hiding + + An exterior router can hide networks by importing or exporting + routing information only about specific networks. + + Importing Routing Information About Specific Networks + + A network administrator can configure a tunneling port on an exterior + router to import only a subset of the routing information that it + receives through the tunnel. To do so, the administrator hides + specific networks connected to other exterior routers on the tunnel + from the exterior router's local internet. For example, an exterior + router can import only that routing information received from + specific exterior routers, or routing information for networks in a + specific network range or zone. By importing routing information only + about specific networks, an exterior router can greatly reduce + + + + + +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] +
\ No newline at end of file |