Internet RFC/STD/FYI/BCP Archives
Powered By Arogo.Net Web Hosting
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
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:
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.
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.
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
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
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.
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
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
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
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.
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.
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
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.
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
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
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
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
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.
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
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
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.
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>>
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>>
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
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
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
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.
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
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:
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.
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
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
"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
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,
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.
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
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
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
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
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.
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
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
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
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.
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:
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.
<<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
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
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.
<<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.
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>>
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
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
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 contain