Editing: AURP

// template for new/empty pages
((header))
title:AppleTalk Routing Protocol
author:DrJosh9000
((content))

**DRAFT**
An overview of  AURP (the AppleTalk Update-based Routing Protocol), used by Apple Internet Router to send AppleTalk across The Internet for people who don't care to be bamboozled by [https://gitea.drjosh.dev/josh/jrouter/src/branch/main/docs/AURP_Enhanced_ATalk_Routing.pdf]{Apple's documentation}.

**First, a bit about AppleTalk**
AppleTalk is a packet-based networking system that is designed to be ~~routed~~ - you can join multiple distinct AppleTalk networks together with routers.
AppleTalk routers advertise routes using RTMP. With RTMP, routes are periodically (every 10 seconds) broadcast to the local network. This lets computers on the network know two things:
1. that there is a router on the network
2. that the remote networks are available via that router.
Routers also answer queries from computers on the network about zones using ZIP, and have a special role when resolving names to addresses using NBP.

**Why AURP**
For better or worse, AppleTalk is ~~not~~ the protocol of the internet - that would be Internetworking Protocol (IP) version 4, and its successor, IPv6. You can't send AppleTalk packets to your ISP and expect them to go anywhere useful.
To go on the internet, AppleTalk packets need to be ~~encapsulated~~ within an IP packet. AURP handles this encapsulation.
Similarly, AppleTalk routers that use the internet to talk to one another need a way to share routing information. While Apple's networking folks could have phoned it in and said "yeah so we just do encapsulated RTMP broadcasts but instead of being IP broadcasts they send directly to each router in a configured list", for whatever reason they wanted a more robust and efficient protocol for distributing routing information. The bulk of AURP's complexity is in the route and zone information side.

**Demystifying AURP**
Like many networking protocols, AURP  handles packets according to layers. 
AURP sits on top of UDP, and uses UDP port 387 to communicate. UDP sits on top of IP. Those are the layers below.
Within AURP, there are layers too. The first AURP layer is the "domain header". For some reason AURP replicates the source and destination IP address here. The main functional purpose of the domain header is to separate the two main AURP packet types: AppleTalk (i.e. encapsulated packets) and Routing (information about routes, zones, and other AURP specific stuff).
For encapuslated AppleTalk packets, that's it. All the layers within encapsulated AppleTalk are the standard AppleTalk packet layers (DDP/NBP/ATP/etc).
For the other main kind of packet, routing information packets, there are two more layers:
* The AURP-Tr header has a ~~connection ID~~ and a ~~sequence number~~. 
* The AURP header has the ~~command code~~ and ~~flags~~.

The thing with connection ID and sequence number is: there are actually **TWO** connections between each pair of AURP routers. So you will see some packets with one connection ID, and some packets with a different connection ID.
Say we have two routers, A and B, that are connected. Then 
* one connection will be for A to send its routing information to B
* the other connection will be for B to send its routing information to A.
The AURP doc talks about "data sender" and "data receiver". These map to the roles within one of the two connections, ~~not who is sending or receiving a packet~~. The data ~~receiver~~ needs to ~~send~~ acknowldgement packets back to the data ~~sender~~. Making sense? If I were writing up the AURP spec today I would probably have chosen "producer" and "consumer", or some other words, to talk about the two roles within a connection.

The thing with sequence numbers is... they're irrelevant and set to 0 for most packet types, ~~except the important ones~~.
The data sender (routing information producer) streams ~~updates~~ to the data receiver (consumer). Each update has an increasing sequence number so that the receiver (consumer) knows whether it has missed any, and so that the sender (producer) can similarly tell if it should keep re-trying the previous update or send the new one. If the expected sequence number is too far out (and that in practice means anything other than the current expected number or the previous one) the connection should be restarted from scratch.

Why didn't they use TCP to provide a reliable transport for routing information, instead of hand-rolling their own? Dunno. The doc calls it out as a possibility, but AIR doesn't implement it. It would have been the early 90s, so maybe TCP/IP wasn't as performant as they wanted on the Macs of the day.

**AURP routing commands**
There are several command codes in use. They have terse names:

* Open-Req / Open-Rsp - These create a connection. The data receiver (consumer) sends the Open-Req and chooses its own connection ID. The data sender (producer) replies with Open-Rsp which could either accept the connection or reject it.
* RI-Req / RI-Rsp / RI-Ack / RI-Upd - These are how Routing Information (specifically, AppleTalk network ranges) is transmitted. The data receiver (consumer) sends RI-Req, then the sender (producer) sends one or more RI-Rsps with the routes, then the data receiver (consumer) acknowledges by sending RI-Ack. ~~After that~~, the data sender (producer) sends RI-Upd whenever something about its routes changes, and the data receiver (consumer) acknowledges with an RI-Ack.
* ZI-Req / ZI-Rsp - These are how Zone Information is transmitted. The data receiver (consumer) sends ZI-Req and the data sender (producer) sends one or more ZI-Rsps with the mapping between zone names and networks.
* RD - lets the data receiver (consumer) know that the data sender (producer) is going offline. It's supposed to be acknowledged with an RI-Ack.
* Tickle / Tickle-Ack - a way of testing the connection is still up. Some routers don't see a lot of churn in network information, so every 15 seconds or so the routers tickle one another.
* some other ones that usually aren't implemented

Why don't you often see ZI-Req packets? Because in an effort to optimise the protocol, they made it so RI-Ack packets could be flagged with "SZI" (Send Zone Information). If that flag is present the data sender (producer) is supposed to directly send a ZI-Rsp with the zones for the networks it just sent info about in the RI-Rsp or RI-Upd that the data receiver (consumer) is ack-ing.

Publish Password:

Cancel Changes