rfc2776.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,516 行 · 第 1/5 页

6.1.  Internal entities listening to MZAP messages

   Any host or application may join the [MZAP-LOCAL-GROUP] to listen for
   Zone Announcement Messages to build up a list of the scope zones that
   are relevant locally, and for Not-Inside Messages if it wishes to
   learn nesting information.  However, listening to such messages is
   not the recommended method for regular applications to discover this
   information.  These applications will normally query a local
   Multicast Address Allocation Server (MAAS) [3], which in turn listens
   to Zone Announcement Messages and Not-Inside Messages to maintain
   scope information, and can be queried by clients via MADCAP messages.

   An entity (including a MAAS) lacking any such information can only
   assume that it is within the Global Scope, and the Local Scope, both
   of which have well-known address ranges defined in [1].

   An internal entity (e.g., an MAAS) receiving a ZAM will parse the
   information that is relevant to it, such as the address range, and
   the names.  An address allocator receiving such information MUST also
   use the "B" bit to determine whether it can add the address range to
   the set of ranges from which it may allocate addresses (specifically,
   it may add them only if the bit is zero).  Even if the bit is zero,
   an MAAS SHOULD still store the range information so that clients who
   use relative- addresses can still obtain the ranges by requesting
   them from the MAAS.

   An internal entity (e.g., an MAAS) should assume that X nests within
   Y if:

   a) it first heard ZAMs for both X and Y at least [NIM-HOLDTIME]
      seconds ago, AND

   b) it has not heard a NIM indicating that "X not inside Y" for at
      least [NIM-HOLDTIME] seconds.







Handley, et al.             Standards Track                    [Page 17]

RFC 2776                          MZAP                     February 2000


6.2.  Sending ZAMs

   Each ZBR should send a Zone Announcement Message for each scope zone
   for which it is a boundary every [ZAM-INTERVAL] seconds, +/- 30% of
   [ZAM-INTERVAL] each time to avoid message synchronisation.

   The ZAM packet also contains a Zones Traveled Limit (ZTL).  If the
   number of Local Zone IDs in the ZAM path becomes equal to the Zones
   Traveled Limit, the packet will be dropped.  The ZTL field is set
   when the packet is first sent, and defaults to 32, but can be set to
   a lower value if a network administrator knows the expected size of
   the zone.

6.3.  Receiving ZAMs

   When a ZBR receives a ZAM for some scope zone X, it uses the
   following rules.

   If the local ZBR does NOT have any configuration for scope X:

   (1) Check to see if the included start and end addresses overlap
       with, but are not identical to, the start and end addresses of
       any locally-configured scope Y, and if so, signal an address
       range conflict to a local administrator.

   (2) Create a local "X not inside" state entry, if such an entry does
       not already exist.  The ZBR then restarts the entry's timer at
       [ZAM-HOLDTIME].  Existence of this state indicates that the ZBR
       knows that X does not nest inside any scope for which it is a
       boundary.  If the entry's timer expires (because no more ZAMs for
       X are heard for [ZAM-HOLDTIME]), the entry is deleted.

   If the local ZBR does have configuration for scope X:

   (1) If the ZAM originated from OUTSIDE the scope (i.e., received over
       a boundary interface for scope X):

      a) If the Scope Zone ID in the ZAM matches the ZBR's own Scope
         Zone ID, then signal a leaky scope misconfiguration.

      b) Drop the ZAM (perform no further processing below).  For
         example, router G in Figure 2 will not forward the ZAM.  This
         rule is primarily a safety measure, since the placement of G in
         Figure 2 is not a recommended configuration, as discussed
         earlier.






Handley, et al.             Standards Track                    [Page 18]

RFC 2776                          MZAP                     February 2000


   2) If the ZAM originated from INSIDE the scope:

      a) If the next-hop interface (according to the multicast RIB)
         towards the Origin is outside the scope zone, then signal a
         non- convexity problem.

      b) If the Origin's Scope Zone ID in the ZAM does not match the
         Scope Zone ID kept by the local ZBR, and this mismatch
         continues to occur, then signal a possible leaky scope warning.

      c) For each textual name in the ZAM, see if a name for the same
         scope and language is locally-configured; if so, but the scope
         names do not match, signal a scope name conflict to a local
         administrator.

      d) If the ZAM was received on an interface which is NOT a Local
         Scope boundary, and the last Local Zone ID Address in the path
         list is 0, the ZBR fills in the Local Zone ID Address of the
         local zone from which the ZAM was received.

   If a ZAM for the same scope (as identified by the origin Zone ID and
   first multicast address) was received in the last [ZAM-DUP-TIME]
   seconds, the ZAM is then discarded.  Otherwise, the ZAM is cached for
   at least [ZAM-DUP-TIME] seconds.  For example, when router C in
   Figure 2 receives the ZAM via B, it will not be forwarded, since it
   has just forwarded the ZAM from E.

   The Zones Travelled count in the message is then incremented, and if
   the updated count is equal to or greater than the ZTL field, schedule
   a ZLE to be sent as described in the next subsection and perform no
   further processing below.

   If the Zone ID of the Local Scope zone in which the ZBR resides is
   not already in the ZAM's path list, then the ZAM is immediately re-
   originated within the Local Scope zone.  It adds its own address and
   the Zone ID of the Local Scope zone into which the message is being
   forwarded to the ZAM path list before doing so.  A ZBR receiving a
   ZAM with a non-null path list MUST NOT forward that ZAM back into a
   Local Scope zone that is contained in the path list.  For example, in
   Figure 2, router F, which did not get the ZAM via A due to packet
   loss, will not forward the ZAM from B back into Zone 2 since the path
   list has { (E,1), (A,2), (B,3) } and hence Zone 2 already appears.

   In addition, the ZBR re-originates the ZAM out each interface with a
   Local Scope boundary (except that it is not sent back out the
   interface over which it was received, nor is it sent into any local
   scope zone whose ID is known and appears in the path list).  In each
   such ZAM re-originated, the ZBR adds its own IP address to the path



Handley, et al.             Standards Track                    [Page 19]

RFC 2776                          MZAP                     February 2000


   list, as well as the Zone ID Address of the Local Scope Zone into
   which the ZAM is being sent, or 0 if the ID is unknown.  (For
   example, if the other end of a point-to-point link also has a
   boundary on the interface, then the link has no Local Scope Zone ID.)

6.4.  Sending ZLEs

   This packet is sent by a local-zone boundary router that would have
   exceeded the Zone Traveled Limit if it had forwarded a ZAM packet.
   To avoid ZLE implosion, ZLEs are multicast with a random delay and
   suppressed by other ZLEs.  It is only scheduled if at least [ZLE-
   MIN-INTERVAL] seconds have elapsed since it previously sent a ZLE to
   any destination.  To schedule a ZLE, the router sets a random delay
   timer within the interval [ZLE-SUPPRESSION-INTERVAL], and listens to
   the [MZAP-RELATIVE-GROUP] within the included scope for other ZLEs.
   If any are received before the random delay timer expires, the timer
   is cleared and the ZLE is not sent.  If the timer expires, the router
   sends a ZLE to the [MZAP-RELATIVE-GROUP] within the indicated scope.

   The method used to choose a random delay (T) is as follows:

     Choose a random value X from the uniform random interval [0:1]
     Let C = 256
     Set T = [ZLE-SUPPRESSION-INTERVAL] log( C*X + 1) / log(C)

   This equation results in an exponential random distribution which
   ensures that close to one ZBR will respond.  Using a purely uniform
   distribution would begin to exhibit scaling problems as the number of
   ZBRs rose.  Since ZLEs are only suppressed if a duplicate ZLE arrives
   before the time chosen, two routers choosing delays which differ by
   an amount less than the propagation delay between them will both send
   messages, consuming excess bandwidth.  Hence it is desirable to
   minimize the number of routers choosing a delay close to the lowest
   delay chosen, and an exponential distribution is suitable for this
   purpose.

   A router SHOULD NOT send more than one Zone Limit Exceeded message
   every [ZLE-MIN-INTERVAL] regardless of destination.

6.5.  Receiving ZLEs

   When a router receives a ZLE, it performs the following actions:

   (1) If the router has a duplicate ZLE message scheduled to be sent,
       it unschedules its own message so another one will not be sent.

   (2) If the ZLE contains the router's own address in the Origin field,
       it signals a leaky scope misconfiguration.



Handley, et al.             Standards Track                    [Page 20]

RFC 2776                          MZAP                     February 2000


6.6.  Sending ZCMs

   Each ZBR should send a Zone Convexity Message (ZCM) for each scope
   zone for which it is a boundary every [ZCM-INTERVAL] seconds, +/- 30%
   of [ZCM-INTERVAL] each time to avoid message synchronisation.

   ZCMs are sent to the [ZCM-RELATIVE-GROUP] in the scoped range itself.
   (For example, if the scope range is 239.1.0.0 to 239.1.0.255, then
   these messages should be sent to 239.1.0.252.)  As these are not
   Locally-Scoped packets, they are simply multicast across the scope
   zone itself, and require no path to be built up, nor any special
   processing by intermediate Local Scope ZBRs.

6.7.  Receiving ZCMs

   When a ZCM is received for a given scope X, on an interface which is
   inside the scope, it follows the rules below:

   (1) The Origin is added to the local list of ZBRs (including itself)
       for that scope, and the Zone ID is updated to be the lowest IP
       address in the list.  The new entry is scheduled to be timed out
       after [ZCM-HOLDTIME] if no further messages are received from
       that ZBR, so that the Zone ID will converge to the lowest address
       of any active ZBR for the scope.

   (2) If a ZBR is listed in ZCMs received, but the next-hop interface
       (according to the multicast RIB) towards that ZBR is outside the
       scope zone, or if no ZCM is received from that ZBR for [ZCM-
       HOLDTIME] seconds, as in the example in Figure 4, then signal a
       non-convexity problem.

   (3) For each textual name in the ZCM, see if a name for the same
       scope and language is locally-configured; if so, but the scope
       names do not match, signal a scope name conflict to a local
       administrator.

6.8.  Sending NIMs

   Periodically, for each scope zone Y for which it is a boundary, a
   router originates a Not-Inside Message (NIM) for each "X not inside"
   entry it has created when receiving ZAMs.  Like a ZAM, this message
   is multicast to the address [MZAP-LOCAL-GROUP] from one of its
   interfaces inside Y.

   Each ZBR should send such a Not-Inside Message every [NIM-INTERVAL]
   seconds, +/- 30% of [NIM-INTERVAL] to avoid message synchronization.





Handley, et al.             Standards Track                    [Page 21]

RFC 2776                          MZAP                     February 2000


6.9.  Receiving NIMs

   When a ZBR receives a NIM saying that "X is not inside Y", it is
   forwarded, unmodified, in a manner similar to ZAMs:

   (1) If the NIM was received on an interface with a boundary for
       either X or Y, the NIM is discarded.

   (2) Unlike ZAMs, if the NIM was not received on the interface towards
       the message origin (according to the Multicast RIB), the NIM is
       discarded.

   (3) If a NIM for the same X and Y (where each is identified by its
       first multicast address) was received in the last [ZAM-DUP-TIME]
       seconds, the NIM is not forwarded.

   (4) Otherwise, the NIM is cached for at least [ZAM-DUP-TIME] seconds.

   (5) The ZBR then re-originates the NIM (i.e., with the original UDP
       payload) into each local scope zone in which it has interfaces,
       except that it is not sent back into the local scope zone from
       which the message was received, nor is it sent out any interface
       with a boundary for either X or Y.

7.  Constants

   [MZAP-PORT]:  The well-known UDP port to which all MZAP messages are
   sent.  Value: 2106.

   [MZAP-LOCAL-GROUP]:  The well-known group in the Local Scope to which
   ZAMs are sent.  All Multicast Address Allocation servers and Zone
   Boundary Routers listen to this group.  Value: 239.255.255.252 for
   IPv4.