RFCs in HTML Format


RFC 1504

                Appletalk Update-Based Routing Protocol:
                       Enhanced Appletalk Routing

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



Back to RFC index

 

Associates:

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""