Extended- vs. nonextended-net net range aging
Kai Getrost
I'm implementing Phase II AppleTalk on a 386 using packet drivers,
and I've come across a minor but confusing inconsistency in the
protocol spec. A little background info first (to be sure I have
things straight):
A node determines the net number (net range for extended nets) of
the local link it is on by listening to RTMP Data/Response packets and
copying the sender's net (range) number(s), and the sender's node
(net:node) as the ID of a router to use. Inside AppleTalk calls these
values THIS-NET and A-ROUTER, respectively. A-ROUTER is updated every
time an RTMP Data packet is received, so its value may change
continually (since any router will do).
The problem:
Inside AppleTalk (2nd ed.) gives slightly different algorithms for
expiring THIS-NET on extended vs. nonextended nets.
On nonextended nets, it says (p. 5-18/19) that the value of
A-ROUTER and THIS-NET are gleaned from every RTMP Data packet
received. If no RTMP packets are received for 50 seconds, A-ROUTER
should be expired (set to 0), but *not* THIS-NET.
On extended nets, however, it says that *both* A-ROUTER and THIS-NET
should be reset when the aging timer expires.
In other words, nodes on nonextended nets will save their link's net
number if all routers go down, but nodes on extended nets are supposed
to reset theirs (and set them again once RTMP packets are received
again, possibly to a new value). Why do these algorithms differ?
The benefit of expiring the net range on extended nets could be
that you can reconfigure the net range by taking down just the routers
for some minimum time, and then bring them up with a new value that
all nodes will (hopefully) adopt. But this will affect any current
connections non-router nodes have, as they change to the new net range
and adopt new net:node IDs, and Inside AppleTalk is nebulous as to
when and how these connections should be reset (since it's a rare
occurence and difficult to deal with effectively).
And why not have nonextended-net nodes expire their net #'s as
well, so their link's net # can be changed in the same way? It's a
minor point, and I may be reading too much into it, but I'm curious as
to why this inconsistency exists.
--
"...adventures into the esoteric | Kai Getrost
periphery of the C shell may reveal | ---
unexpected quirks." | k...@pyrite.som.cwru.edu
-- SunOS 4.1 csh(1) | k...@b62624.student.cwru.edu
David Stine
>[...]
>
>The problem:
>
> Inside AppleTalk (2nd ed.) gives slightly different algorithms for
>expiring THIS-NET on extended vs. nonextended nets.
>
> On nonextended nets, it says (p. 5-18/19) that the value of
>A-ROUTER and THIS-NET are gleaned from every RTMP Data packet
>received. If no RTMP packets are received for 50 seconds, A-ROUTER
>should be expired (set to 0), but *not* THIS-NET.
> On extended nets, however, it says that *both* A-ROUTER and THIS-NET
>should be reset when the aging timer expires.
>
> In other words, nodes on nonextended nets will save their link's net
>number if all routers go down, but nodes on extended nets are supposed
>to reset theirs (and set them again once RTMP packets are received
>again, possibly to a new value). Why do these algorithms differ?
Remember that on extended cables, you can have a _range_ of network numbers.
The router could come back on the net with a different network number in its
address.
Example: let's say that you have an extended AppleTalk Ethernet with a
cable-range of, oh, 10-20.[footnote 1] Let's say that the router's current
net.node address is 10.240. Now, let's say that there is a hiccup in the power
and when the router comes back on-line, all non-reserved node numbers in
network 10 have been taken. The router, while AARP'ing for an open address,
must choose a node in network number 11. Say 11.20.
If it were the _only_ router on the cable, the nodes which were holding an
A-ROUTER value and not timing it out would still be sitting on the wire, deaf
to the world, since they are waiting for the router to re-appear on network
10.
The analgous scenario occurring on a non-extended cable means that the nodes
will have to re-AARP for new node addresses, since the cable configuration has
changed. On an extended net, the nodes' current address is still valid and the
cable configuration hasn't changed; simply the address of the router has
changed.
> The benefit of expiring the net range on extended nets could be
>that you can reconfigure the net range by taking down just the routers
>for some minimum time, and then bring them up with a new value that
>all nodes will (hopefully) adopt. But this will affect any current
>connections non-router nodes have, as they change to the new net range
>and adopt new net:node IDs, and Inside AppleTalk is nebulous as to
>when and how these connections should be reset (since it's a rare
>occurence and difficult to deal with effectively).
Yes, this is one of many instances where "Inside AppleTalk" is rather, well,
vague. Perhaps wishy-washy. A tad economical with the facts, even.
In addition to reading Inside AppleTalk on this issue, you should also be
reading the document from APDA called:
"AppleTalk Phase 2 Protocol Specification, C0144LL/A"
which will set you back $20. I don't have my copy here right now (I'm at home)
but this document contains the details on router disappearance and
re-appearance that are missing from "Inside AppleTalk." If you are
implementing an AppleTalk node or router, you must have this document. Simple
as that.
No, I'm not connected or getting a kick-back from APDA in any way. ;-)
dsa
[Footnote 1]
There is a heap of misconception out there as to cable-range configurations on
Phase II routers. I frequently see people with a cable-range 10 to 100 wide
when they have an Ethernet segment with only 100 nodes _max_.
Apple forgot to stress the point that a "wide" cable range (ie, a cable range
which would be 10-11, rather than 10-10) is required _only_ when you will have
more than 253 nodes on that particular cable/media segment. This usually only
occurs in large bridged LAN's. If there are note going to be more than 253
AppleTalk nodes on said cable segment, there isn't any point in configuring a
wide cable range.
Kai Getrost
> Remember that on extended cables, you can have a _range_ of network numbers.
> The router could come back on the net with a different network number in its
> address.
Yes, I understand how and why a node's idea of who its router is
should be expired, for exactly that reason. I was curious about the
expiration of *THIS-NET*: the network number of the link the node is
on. For nodes on extended nets THIS-NET is a range of numbers (and
A-ROUTER is a net:node pair; I was unclear about this in my original
post, sorry). I also understand why this value should be expired;
what I wanted to know was why THIS-NET is *not* expired on
non-extended nets (according to Inside AppleTalk) when all routers go
down.
> Example: let's say that you have an extended AppleTalk Ethernet with a
> cable-range of, oh, 10-20.[footnote 1] Let's say that the router's
> current net.node address is 10.240. Now, let's say that there is a
> hiccup in the power and when the router comes back on-line, all
> non-reserved node numbers in network 10 have been taken. The router,
> while AARP'ing for an open address, must choose a node in network
> number 11. Say 11.20.
[after a router has gone down and come back up:]
> On an extended net, the nodes' current address is still valid and the
>cable configuration hasn't changed; simply the address of the router has
>changed.
But the data link's net range remains the same. If *all* routers
go down on that link, and then all come up with a new net range, all
nodes (nonrouters included) must not only look for the new router
node(s), but adopt a new value of THIS-NET (the new net range) and AARP
for new node addresses themselves within this range.
On a nonextended net, Inside AppleTalk says that nodes *don't*
expire THIS-NET (the net # for their link), though they do copy it
from every RTMP Data packet they see (so nodes' idea of THIS-NET will
also change if all routers go down and come up advertising a new net
#).
This is what I was curious about; why nonextended nets don't revert
to net 0 the way extended nets revert to net range 0-$FFFE when all
routers go down, according to Inside AppleTalk (pp. 5-19 - 5-20).
> In addition to reading Inside AppleTalk on this issue, you should also be
> reading the document from APDA called:
>
> "AppleTalk Phase 2 Protocol Specification, C0144LL/A"
Ok, I'll have to get it; thanks.
-Kai
--
"`Meltdown' -- it's one of those annoying | Kai Getrost
buzzwords. We prefer to call it an | ---
`unrequested fission surplus.'" | k...@pyrite.som.cwru.edu
-- Mr. Burns, _The_Simpsons_ | k...@b62624.student.cwru.edu
Andrew Klossner
"A node determines the net number (net range for extended nets)
of the local link it is on by listening to RTMP Data/Response
packets ..."
Actually, the recommended way for a node on an extended net to get this
info is to broadcast a ZIP GetNetInfo. See page 5-19, IA#2. It's not
wrong to use RTMP, but ZIP GNI gets you the info right away and also
tells you whether your zone name is valid.
(On a non-extended net, you can start operations before you know your
network number, so waiting until the next RTMP isn't an inconvenience.
On an extended net, you can't start operations until you know your
network number range or have established that there is no router.)
"A-ROUTER is updated every time an RTMP Data packet is received
..."
Consider implementing the optional "best router" algorithm, page 4-20.
It's a major win on big networks. We have a big network, and the major
cause of packet loss is router congestion.
"nodes on nonextended nets will save their link's net number if
all routers go down, but nodes on extended nets are supposed to
reset theirs (and set them again once RTMP packets are received
again, possibly to a new value). Why do these algorithms
differ?"
On an extended net, you cannot accept a packet from a node on your
network if the source network number falls outside THIS-NET-RANGE.
(Because you can't reply to it, because your transmit algorithm would
try to route the reply to another network.) If the last router
disappears and then a non-router node comes up, it could choose any
network number (depending on what net it was on when it powered down).
Once you set THIS-NET-RANGE to [0..FFFE], you can accept packets from
that node.
On a non-extended net, if the last router disappears and then a
non-router node comes up, it will use network number 0. You accept
packets from network 0 regardless of the value of THIS-NET, so it's not
necessary to reset THIS-NET. More important is the fact that this is
how things were defined before anybody thought about extended networks,
and this is how the LaserWriter ROMs behaved. The cardinal rule in
defining extensions to AppleTalk is: don't invalidate the LaserWriter
ROMs.
-=- Andrew Klossner (and...@frip.wv.tek.com)
(uunet!tektronix!frip.WV.TEK!andrew)