home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / protocol / appletal / 3986 < prev    next >
Encoding:
Internet Message Format  |  1992-11-22  |  2.9 KB
  1. Path: sparky!uunet!think.com!spool.mu.edu!agate!usenet.ins.cwru.edu!pyrite!kai
  2. From: kai@pyrite.SOM.CWRU.edu (Kai Getrost)
  3. Newsgroups: comp.protocols.appletalk
  4. Subject: Extended- vs. nonextended-net net range aging
  5. Date: 22 Nov 92 23:43:34
  6. Organization: WSOM CSG, CWRU, Cleve. Ohio
  7. Lines: 55
  8. Distribution: comp
  9. Message-ID: <KAI.92Nov22234334@pyrite.SOM.CWRU.Edu>
  10. NNTP-Posting-Host: pyrite.som.cwru.edu
  11.  
  12.  
  13.    I'm implementing Phase II AppleTalk on a 386 using packet drivers,
  14. and I've come across a minor but confusing inconsistency in the
  15. protocol spec.  A little background info first (to be sure I have
  16. things straight):
  17.  
  18.    A node determines the net number (net range for extended nets) of
  19. the local link it is on by listening to RTMP Data/Response packets and
  20. copying the sender's net (range) number(s), and the sender's node
  21. (net:node) as the ID of a router to use.  Inside AppleTalk calls these
  22. values THIS-NET and A-ROUTER, respectively.  A-ROUTER is updated every
  23. time an RTMP Data packet is received, so its value may change
  24. continually (since any router will do).
  25.  
  26. The problem: 
  27.  
  28.    Inside AppleTalk (2nd ed.) gives slightly different algorithms for
  29. expiring THIS-NET on extended vs. nonextended nets.
  30.  
  31.    On nonextended nets, it says (p. 5-18/19) that the value of
  32. A-ROUTER and THIS-NET are gleaned from every RTMP Data packet
  33. received.  If no RTMP packets are received for 50 seconds, A-ROUTER
  34. should be expired (set to 0), but *not* THIS-NET.
  35.   On extended nets, however, it says that *both* A-ROUTER and THIS-NET
  36. should be reset when the aging timer expires.
  37.  
  38.   In other words, nodes on nonextended nets will save their link's net
  39. number if all routers go down, but nodes on extended nets are supposed
  40. to reset theirs (and set them again once RTMP packets are received
  41. again, possibly to a new value).  Why do these algorithms differ?
  42.    The benefit of expiring the net range on extended nets could be
  43. that you can reconfigure the net range by taking down just the routers
  44. for some minimum time, and then bring them up with a new value that
  45. all nodes will (hopefully) adopt.  But this will affect any current
  46. connections non-router nodes have, as they change to the new net range
  47. and adopt new net:node IDs, and Inside AppleTalk is nebulous as to
  48. when and how these connections should be reset (since it's a rare
  49. occurence and difficult to deal with effectively).  
  50.    And why not have nonextended-net nodes expire their net #'s as
  51. well, so their link's net # can be changed in the same way?  It's a
  52. minor point, and I may be reading too much into it, but I'm curious as
  53. to why this inconsistency exists.
  54.  
  55.  
  56. -Kai
  57. kai@pyrite.som.cwru.edu
  58.  
  59.  
  60.  
  61.  
  62. --
  63. "...adventures into the esoteric              |        Kai Getrost
  64.  periphery of the C shell may reveal          |            ---
  65.  unexpected quirks."                          | kai@pyrite.som.cwru.edu
  66.                  -- SunOS 4.1 csh(1)          | kai@b62624.student.cwru.edu
  67.