Zero-config option for MSTP dynamic addressing
After receiving direction to work on a “zero-config” option for the dynamic addressing proposal in Salt Lake City , I have begun thinking about this some, and looking over the “Dynamic Configuration of IPv4 Link-Local Addresses” paper (RFC 3927). It looks like the basic scheme is to send an ARP packet with your hw address and your desired ip address, and listen for replies from someone else with that ip address. If you don’t see any replies, you send an announcement, which is the same, but this time you fill in your desired ip address as your actual ip address.
One difficulty in mapping this approach to MS/TP is that it assumes a node is free to send a packet at any time, which is NOT the case for MS/TP. Here are my thoughts so far on this:
- Since the token passes rapidly between nodes, and we must assume that the zero-config process may occur in the presence of statically configured nodes executing the current 135-2004 or earlier state machine, the only real opportunity to inject packet comes during the Poll For Master sequence.
- Assume the node has listened to the token passing for a while and selected an address at random from the list of addresses that appear to be available (this would probably be in the range 0 to the empirically observed Max_Master).
- Simply sending a Reply To Poll For Master would not be good, because there would be no way to distinguish nodes through their UIDs, nor to distinguish a dynamically addressed node from a statically configured node that happened to come online at that time.
- So some new frame (possibly the address request frame reused) should be sent by a node wishing to claim an address (analogous to the ARP Request in the IPv4 ZC case). This will cause the node that issued the PFM to drop the token via the ReceivedUnexpectedFrame transition.
- So the node requesting the address must at least pass the token back to the PFM-ing node so the token passing can pick back up where it was.
- Could we place the constraint that zero-config MS/TP may only be done on a trunk composed entirely of devices that understand the new state machine defined in the proposal? If so, then we could have the freedom to explore other options. This doesn’t sound so bad to me, because if you have nodes that are statically configured, then you should be able to make one of them be a statically configured auto-address master who can hand out addresses.
I haven’t yet started on the multiple address master resolution.
I would greatly appreciate any thoughts on this.