Zone Name Change Prototype

["Kuang, Fidelia" <[e-mail]>]

A couple weeks ago, a couple of us here at Apple set out to come up with a
proposal for zone name changing and to implement a prototype.  We now have a
working prototype.  The method that we chose was, as indicated earlier, a
"timed suicide" approach, or as Tom Evans has suggested more appropriately, a
"timed reset and recover" approach.  It involves replacing the old zone list
with a new zone list.
 
Warning: this message is rather long -- the proposal and MIB definition follow.
 
The MIB definitions we have come up with could go in the AppleTalk MIB+ or
could go in a separate MIB.  I strongly suggest that, at a minimum, the
"onHold" atPortStatus be put back in the AT MIB to indicate that a port is on
hold.  With the MIB deadline quickly approaching, I realize we need to decide
this soon.  Comments?
 
I recognize that our proposal is not an ideal solution.  We believe, however,
that it is a practical solution that addresses a longtime need.  I expect that
we will be discussing this more in detail at the ANF.  If you are interested in
working with our prototype under a standard nondisclosure agreement, please
contact our evangelist, Garry Hornbuckle, at [e-mail]
after April 27th.
 
Fidelia Kuang
 
------
Zone Name Changing
 
Goals:
 
1) to be able to change a zone list for a given network in an internet without
having to manually bring down large portions of the internet
2) to make sure that the solution is Phase 2 compatible.
3) to minimize the effect of changing zones on the rest of the internet.  For
example, to avoid partitioning the network.
4) to have a relatively simple and implementable solution.
5) to make sure the end nodes on the affected network become aware of the
change as necessary.
6) to allow for secure ways of changing the zone list.
7) to provide the ability for a network manager to cancel the zone name change
request.
 
There are actually two main problems to solve: changing a zone list and
notifying the end nodes.  The following proposal outlines a "timed-suicide" or
as Tom Evans has suggested, a "timed reset and recover" approach.  Many thanks
to others who have posted their ideas, particularly Tom Evans and John Norstad.
Note that this proposal recommends, but does not require, an atPortStatus value
of "onHold " (or "onHoldNoAge" and "onHoldNoAdvertise" as Tom Evans has
suggested).
 
The Zone Name Changing MIB
The placement of the groups is not final.  Two good questions are: 1) Where
does the Zone List Change Group belong? and 2)  Does the Neighboring Routers
list belong in the zone list change group or elsewhere?
A note about the New Zone table:  The zone name could be used as an index
instead of the zone index.  Is this the right thing to do?
 
   -- The ZoneListChange Group
 
   zoneListChangeTable OBJECT-TYPE
   SYNTAX SEQUENCE OF ZoneListChangeEntry
   ACCESS not-accessible
   STATUS mandatory
   DESCRIPTION
   "The list of zone list changes that are currently scheduled or in process."
   ::= { zoneListChange 1 }
 
   zoneListChangeEntry OBJECT-TYPE
   SYNTAX ZoneListChangeEntry
   ACCESS not-accessible
   STATUS mandatory
   DESCRIPTION
   "The description of one of the scheduled or current zone list change
processes."
   INDEX { zoneListChangePortIndex }
   ::= { zoneListChangeTable 1 }
 
   ZoneListChangeEntry ::= SEQUENCE {
   zoneListChangePortIndex INTEGER,
   zoneListChangeState INTEGER,
   zoneListChangeDefaultZone   ATName,
   zoneListChangeDelayTime INTEGER,
   zoneListChangeHoldTime  INTEGER,
   }
 
   zoneListChangePortIndex OBJECT-TYPE
                  SYNTAX INTEGER
                  ACCESS read-write
                  STATUS mandatory
                  DESCRIPTION
                   "The AppleTalk port associated with this zone list change."
                  ::= { zoneListChangeEntry 1 }
 
   -- The possible states of the zone list change are defined as
   -- follows:
   --
   -- initiated(1) - The zone list change has started.  The delay
   -- time and hold time can be used to determine how far along
   -- the zone list change is.
   --
   -- notInitiated(2) - The zone list change has not yet been
   -- started.
   --
   -- invalid(3) - Setting the state to invalid deletes the zone
   -- list change entry if possible.
 
   zoneListChangeState OBJECT-TYPE
   SYNTAX INTEGER {
   initiated(1),
   notInitiated(2),
   invalid(3)
   }
   ACCESS read-write
   STATUS mandatory
   DESCRIPTION
   "The current state of the zone list change process."
   ::= { zoneListChangeEntry 2 }
 
   -- Does this belong here?  If not, then where?
   zoneListChangeDefaultZone OBJECT-TYPE
   SYNTAX ATName
   ACCESS read-write
   STATUS mandatory
   DESCRIPTION
   "The new default zone of the network involved."
   ::= { zoneListChangeEntry 3 }
 
   zoneListChangeDelayTime OBJECT-TYPE
   SYNTAX INTEGER  -- should this be a counter?
   ACCESS read-write
   STATUS mandatory
   DESCRIPTION
   "The amount of time (in seconds) starting from the time the
zoneListChangeState was set to initiated(1) before beginning the zone list
change process."
   ::= { zoneListChangeEntry 4 }
 
   zoneListChangeHoldTime OBJECT-TYPE
   SYNTAX INTEGER  -- should this be a counter?
   ACCESS read-write
   STATUS mandatory
   DESCRIPTION
   "The amount of time (in seconds) a port is waiting to assure the network bei
changed has aged out of the internet."
   ::= { zoneListChangeEntry 5 }
 
 
   newZoneTable OBJECT-TYPE
   SYNTAX SEQUENCE OF NewZoneEntry
   ACCESS not-accessible
   STATUS mandatory
   DESCRIPTION
   "The list of new zone names that will be used for a given scheduled zone lis
change."
   ::= { zoneListChange 2 }
 
   newZoneEntry OBJECT-TYPE
   SYNTAX NewZoneEntry
   ACCESS not-accessible
   STATUS mandatory
   DESCRIPTION
   "The description of one of the new zone names for one of the scheduled zone
list changes."
   INDEX { newZonePortIndex, newZoneIndex }
   ::= { newZoneTable 1 }
 
   NewZoneEntry ::= SEQUENCE {
   newZonePortIndexINTEGER,
   newZoneIndexINTEGER,
   newZoneName AtName
   }
 
   newZonePortIndex OBJECT-TYPE
                  SYNTAX INTEGER
                  ACCESS read-write
                  STATUS mandatory
                  DESCRIPTION
                   "The AppleTalk port associated with this zone name.
Identifies the zone list change this zone is to be used for."
                  ::= { newZoneEntry 1 }
 
   newZoneIndex OBJECT-TYPE
   SYNTAX INTEGER
   ACCESS read-write
   STATUS mandatory
   DESCRIPTION
   "A unique value for each new zone list on a given port."
   ::= { newZoneEntry 2 }
 
   newZoneName OBJECT-TYPE
   SYNTAX AtName
   ACCESS read-write
   STATUS mandatory
   DESCRIPTION
   "A new zone name."
   ::= { newZoneEntry 3 }
 
   neighboringRouterTable OBJECT-TYPE
   SYNTAX SEQUENCE OF NeighboringRouterEntry
   ACCESS not-accessible
   STATUS optional
   DESCRIPTION
   "The list of routers that are directly attached to a given network."
   ::= { zoneListChange 3 }
 
   neighboringRouterEntry OBJECT-TYPE
   SYNTAX NeighboringRouterEntry
   ACCESS not-accessible
   STATUS mandatory
   DESCRIPTION
   "The description of one of the routers directly attached to a given network.
   INDEX { neighboringRouterPortIndex, neighboringRouterNetAddess}
   ::= { neighboringRouterTable 1 }
 
   NeighboringRouterEntry ::= SEQUENCE {
   neighboringRouterPortIndex  INTEGER,
   neighboringRouterNetAddess  DdpNodeAddress
   }
 
   neighboringRouterPortIndex OBJECT-TYPE
                  SYNTAX INTEGER
                  ACCESS read-only
                  STATUS mandatory
                  DESCRIPTION
                   "The AppleTalk port associated with this neighboring
router's network."
                  ::= { neighboringRouterEntry 1 }
 
   neighboringRouterNetAddess OBJECT-TYPE
   SYNTAX DdpNodeAddress
   ACCESS read-write
   STATUS mandatory
   DESCRIPTION
   "The DDP network address (network and node number) of the router ."
   ::= { neighboringRouterEntry 2 }
 
 
Changing the zone list
 
A network management station would go through the following steps.
Step 1:  Find all routers that are directly connected (hopcount distance of 0)
to a network N.  The management station must be able to find one SNMP-speaking
router on that network, and then query that router to get the Neighboring
Routers list.
 
Step 2: Create a zone list change entry for each router in the list including
the router that was queried to get the list.  The rows should be created with
zoneListChangeState= notInitiated.  Note that the holdTime must be sufficient
time to allow the network to age out of the internet.
 
Step 3: If any of the routers are unable to set the desired variables (e.g. a
router does not support SNMP or the zone name changing MIB), delete all rows
created (zoneListChangeState = invalid) and abort the zone name change.
 
Step 4: Create the New Zone List table for each router.  These tables should be
identical for each with the exception of portIndex.
 
Step 5: Set the zone list change entries on each router to zoneListChangeState=
initiated.
 
Step 6: Unless the network management station cancels the request, the zone
name change will occur at initiatedTime+delayTime, where the initiatedTime is
the time at which the change was initiated.  No further action is required from
the management station.  As a result, even a net management station on Network
N itself can issue the zone-change request.  To cancel the request before the
delayTime has been exhausted, delete the zone list change entry for the given
port in each router.  Note that the management station can cancel the request
only when all routers can be canceled (enough time remaining before delayTime
exhausted).  (QUESTION: Do we want to allow canceling to occur while the port
is onHold? Do we want to allow modifying of the parameters such as the zone
list while the port is onHold?)
 
A router receiving a zone name change command would do the following.
Step 1: Save off the network information, the zone information, and the various
time intervals.  Set a timer to go off when delayTime has elapsed.
 
Step 2: When the timer goes off, set the router port state to onHold.  OnHold
means: do not broadcast the existence of the network N over RTMP for the
holdTime.  (AURP routers should send an ND event for the network N.)  The
router should send Notify Neighbors to allow the network to age out faster.
The network should disappear from the rest of the internet.  Nodes on the
network itself will temporarily lose internet access because their network is
unknown.  The rest of the internet should not be affected.  In addition, to
facilitate notification of end nodes,  the router should refrain from sending
any RTMP packets out the port.  To prevent partitioning of the network, the
router should not age networks learned through that port since it won't be
receiving RTMP packets either.
 
Step 3: After the holdTime has elapsed, if it is a seed router, the router
should adopt the new zone list for the network N in its configuration and write
the zone list to its long term storage.  Then, regardless of its seed router
status, the router may restart the port immediately.  Restarting the port
allows the router to go through its startup sequence for detecting zone name
conflicts or seed/non-seed conflicts.  The state of the port should change from
onHold to routing.  (Non-seed routers need not adopt the new zone list since
they may learn from the seed routers.)
 
Notifying the End-Nodes
 
To make the workstations think that their router has gone away, the router
stops sending any RTMP packets out the port connected to the network N while on
hold.  This allows workstations to sense that the router has gone.  When the
workstations decide the router is gone, they prepare to hear new network and
zone information.  After the router starts up again, the workstations will look
at the zone information for the network.  If a zone in the zone list is the
same as the workstation's zone, the workstation will remain in its current
zone.  If there is no match, the workstation will be placed in the default
zone.  Note that ZIPNotify is not used in this scheme.
 
Some SNMP Specifics
The following behaviors are specified in the interest of implementation
consistency:
o  Setting zoneListChangeState to notInitiated will cancel the zone name change
but will not delete the entry.  Setting the state to invalid will delete the
entry along with the corresponding new zone list entries.  QUESTION:  Is there
a reason not to do this (that is, is it an SNMP faux pas) and if so, do we need
a state in new zone list table?
o  A zone name change can only be canceled (zoneListChangeState = initiated to
zoneListChangeState = notInitiated or invalid) if the delay time has not
expired.
o  Other variables in the zone list change table can only be changed if the
state is not initiated.  The same is true for the new zone list table.
(QUESTION: is it better to enforce this in the agent or the MS given they are
separate tables? Or is it worth the added complexity to allow changing of
variables even when the state is initiated?)
o  Once the zone name change is initiated, subsequent gets of the zone list
change table will show the delay time counting down to 0, then the hold time
counting down to 0.  QUESTION: Is it valuable to also return the initial time
values?
o  Once the zone name change is complete, the entry should be automatically
deleted along with the corresponding new zone list entries.
o  If the zone name change is canceled, the delay time should freeze (as oppose
to being reset to the original delay time or to 0).
o  The neighboring routers list does NOT contain the router reporting the list.