rfc2022.txt

RFC 的详细文档！

   message format is:

      Data:
       mar$afn      16 bits  Address Family (0x000F).
       mar$pro      56 bits  Protocol Identification.
       mar$hdrrsv   24 bits  Reserved. Unused by MARS control protocol.
       mar$chksum   16 bits  Checksum across entire MARS message.
       mar$extoff   16 bits  Extensions Offset.
       mar$op       16 bits  Operation code (MARS_MULTI = 2).
       mar$shtl      8 bits  Type & length of source ATM number. (r)
       mar$sstl      8 bits  Type & length of source ATM subaddress. (q)
       mar$spln      8 bits  Length of source protocol address (s)
       mar$thtl      8 bits  Type & length of target ATM number (x)
       mar$tstl      8 bits  Type & length of target ATM subaddress (y)
       mar$tpln      8 bits  Length of target group address (z)
       mar$tnum     16 bits  Number of target ATM addresses returned (N)
       mar$seqxy    16 bits  Boolean flag x and sequence number y.
       mar$msn      32 bits  MARS Sequence Number.
       mar$sha      roctets  source ATM number
       mar$ssa      qoctets  source ATM subaddress
       mar$spa      soctets  source protocol address
       mar$tpa      zoctets  target multicast group address



Armitage                    Standards Track                    [Page 21]

RFC 2022          Multicast over UNI 3.0/3.1 based ATM     November 1996


       mar$tha.1    xoctets  target ATM number 1
       mar$tsa.1    yoctets  target ATM subaddress 1
       mar$tha.2    xoctets  target ATM number 2
       mar$tsa.2    yoctets  target ATM subaddress 2
                 [.......]
       mar$tha.N    xoctets  target ATM number N
       mar$tsa.N    yoctets  target ATM subaddress N

   The source protocol and ATM address fields are copied directly from
   the MARS_REQUEST that this MARS_MULTI is in response to (not the MARS
   itself).

   mar$seqxy is coded with flag x in the leading bit, and sequence
   number y coded as an unsigned integer in the remaining 15 bits.

          |  1st octet    |   2nd octet   |
           7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |x|                 y           |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   mar$tnum is an unsigned integer indicating how many pairs of
   {mar$tha,mar$tsa} (i.e. how many group member's ATM addresses) are
   present in the message. mar$msn is an unsigned 32 bit number filled
   in by the MARS before transmitting each MARS_MULTI. Its use is
   described further in section 5.1.4.

   As an example, assume we have a multicast cluster using 4 byte
   protocol addresses, 20 byte ATM numbers, and 0 byte ATM subaddresses.
   For n group members in a single MARS_MULTI we require a (60 + 20n)
   byte message. If we assume the default MTU of 9180 bytes, we can
   return a maximum of 456 group member's addresses in a single
   MARS_MULTI.

5.1.3   Establishing the outgoing multipoint VC.

   Following the completion of the MARS_MULTI reply the endpoint may
   establish a new point to multipoint VC, or reuse an existing one.

   If establishing a new VC, an L_MULTI_RQ is issued for ATM.1, followed
   by an L_MULTI_ADD for every member of the set {ATM.2, ....ATM.n}
   (assuming the set is non-null). The packet is then transmitted over
   the newly created VC just as it would be for a unicast VC.

   After transmitting the packet, the local interface holds the VC open
   and marks it as the active path out of the host for any subsequent IP
   packets being sent to that Class D address.




Armitage                    Standards Track                    [Page 22]

RFC 2022          Multicast over UNI 3.0/3.1 based ATM     November 1996


   When establishing a new multicast VC it is possible that one or more
   L_MULTI_RQ or L_MULTI_ADD may fail.  The UNI 3.0/3.1 failure cause
   must be returned in the ERR_L_RQFAILED signal from the local
   signalling entity to the AAL User. If the failure cause is not 49
   (Quality of Service unavailable), 51 (user cell rate not available -
   UNI 3.0), 37 (user cell rate not available - UNI 3.1), or 41
   (Temporary failure), the endpoint's ATM address is dropped from the
   set {ATM.1, ATM.2, ..., ATM.n} returned by the MARS.  Otherwise, the
   L_MULTI_RQ or L_MULTI_ADD should be reissued after a random delay of
   5 to 10 seconds.  If the request fails again, another request should
   be issued after twice the previous delay has elapsed.  This process
   should be continued until the call succeeds or the multipoint VC gets
   released.

   If the initial L_MULTI_RQ fails for ATM.1, and n is greater than 1
   (i.e. the returned set of ATM addresses contains 2 or more addresses)
   a new L_MULTI_RQ should be immediately issued for the next ATM
   address in the set. This procedure is repeated until an L_MULTI_RQ
   succeeds, as no L_MULTI_ADDs may be issued until an initial outgoing
   VC is established.

   Each ATM address for which an L_MULTI_RQ failed with cause 49, 51,
   37, or 41 MUST be tagged rather than deleted. An L_MULTI_ADD is
   issued for these tagged addresses using the random delay procedure
   outlined above.

   The VC MAY be considered 'up' before failed L_MULTI_ADDs have been
   successfully re-issued. An endpoint MAY implement a concurrent
   mechanism that allows data to start flowing out the new VC even while
   failed L_MULTI_ADDs are being re-tried. (The alternative of waiting
   for each leaf node to accept the connection could lead to significant
   delays in transmitting the first packet.)

   Each VC MUST have a configurable inactivity timer associated with it.
   If the timer expires, an L_RELEASE is issued for that VC, and the
   Class D address is no longer considered to have an active path out of
   the local host. The timer SHOULD be no less than 1 minute, and a
   default of 20 minutes is RECOMMENDED. Choice of specific timer
   periods is beyond the scope of this document.

   VC consumption may also be reduced by endpoints noting when a new
   group's set of {ATM.1, ....ATM.n} matches that of a pre-existing VC
   out to another group. With careful local management, and assuming the
   QoS of the existing VC is sufficient for both groups, a new pt to mpt
   VC may not be necessary.  Under certain circumstances endpoints may
   decide that it is sufficient to re-use an existing VC whose set of
   leaf nodes is a superset of the new group's membership (in which case
   some endpoints will receive multicast traffic for a layer 3 group



Armitage                    Standards Track                    [Page 23]

RFC 2022          Multicast over UNI 3.0/3.1 based ATM     November 1996


   they haven't joined, and must filter them above the ATM interface).
   Algorithms for performing this type of optimization are not discussed
   here, and are not required for conformance with this document.

5.1.4   Tracking subsequent group updates.

   Once a new VC has been established, the transmit side of the cluster
   member's interface needs to monitor subsequent group changes - adding
   or dropping leaf nodes as appropriate. This is achieved by watching
   for MARS_JOIN and MARS_LEAVE messages from the MARS itself. These
   messages are described in detail in section 5.2 - at this point it is
   sufficient to note that they carry:

      - The ATM address of a node joining or leaving a group.
      - The layer 3 address of the group(s) being joined or left.
      - A Cluster Sequence Number (CSN) from the MARS.

   MARS_JOIN and MARS_LEAVE messages arrive at each cluster member
   across ClusterControlVC. MARS_JOIN or MARS_LEAVE messages that simply
   confirm information already held by the cluster member are used to
   track the Cluster Sequence Number, but are otherwise ignored.

5.1.4.1   Updating the active VCs.

   If a MARS_JOIN is seen that refers to (or encompasses) a group for
   which the transmit side already has a VC open, the new member's ATM
   address is extracted and an L_MULTI_ADD issued locally. This ensures
   that endpoints already sending to a given group will immediately add
   the new member to their list of recipients.

   If a MARS_LEAVE is seen that refers to (or encompasses) a group for
   which the transmit side already has a VC open, the old member's ATM
   address is extracted and an L_MULTI_DROP issued locally. This ensures
   that endpoints already sending to a given group will immediately drop
   the old member from their list of recipients. When the last leaf of a
   VC is dropped, the VC is closed completely and the affected group no
   longer has a path out of the local endpoint (the next outbound packet
   to that group's address will trigger the creation of a new VC, as
   described in sections 5.1.1 to 5.1.3).

   The transmit side of the interface MUST NOT shut down an active VC to
   a group for which the receive side has just executed a
   LeaveLocalGroup.  (This behaviour is consistent with the model of
   hosts transmitting to groups regardless of their own membership
   status.)

   If a MARS_JOIN or MARS_LEAVE arrives with mar$pnum == 0 it carries no
   <min,max> pairs, and is only used for tracking the CSN.



Armitage                    Standards Track                    [Page 24]

RFC 2022          Multicast over UNI 3.0/3.1 based ATM     November 1996


5.1.4.2   Tracking the Cluster Sequence Number.

   It is important that endpoints do not miss group membership updates
   issued by the MARS over ClusterControlVC. However, this will happen
   from time to time. The Cluster Sequence Number is carried as an
   unsigned 32 bit value in the mar$msn field of many MARS messages
   (except for MARS_REQUEST and MARS_NAK).  It increments once for every
   transmission the MARS makes on ClusterControlVC, regardless of
   whether the transmission represents a change in the MARS database or
   not. By tracking this counter, cluster members can determine whether
   they have missed a previous message on ClusterControlVC, and possibly
   a membership change. This is then used to trigger revalidation
   (described in section 5.1.5).

   The current CSN is copied into the mar$msn field of MARS messages
   being sent to cluster members, whether out ClusterControlVC or on a
   point to point VC.

   Calculations on the sequence numbers MUST be performed as unsigned 32
   bit arithmetic.

   Every cluster member keeps its own 32 bit Host Sequence Number (HSN)
   to track the MARS's sequence number. Whenever a message is received
   that carries an mar$msn field the following processing is performed:

         Seq.diff = mar$msn - HSN

         mar$msn -> HSN
         {...process MARS message as appropriate...}

         if ((Seq.diff != 1) && (Seq.diff != 0))
            then {...revalidate group membership information...}

   The basic result is that the cluster member attempts to keep locked
   in step with membership changes noted by the MARS. If it ever detects
   that a membership change occurred (in any group) without it noticing,
   it re-validates the membership of all groups it currently has
   multicast VCs open to.

   The mar$msn value in an individual MARS_MULTI is not used to update
   the HSN until all parts of the MARS_MULTI (if more than 1) have
   arrived. (If the mar$msn changes the MARS_MULTI is discarded, as
   described in section 5.1.1.)

   The MARS is free to choose an initial value of CSN. When a new
   cluster member starts up it should initialise HSN to zero. When the
   cluster member sends the MARS_JOIN to register (described later), the
   HSN will be correctly updated to the current CSN value when the



Armitage                    Standards Track                    [Page 25]

RFC 2022          Multicast over UNI 3.0/3.1 based ATM     November 1996


   endpoint receives the copy of its MARS_JOIN back from the MARS.

5.1.5   Revalidating a VC's leaf nodes.

   Certain events may inform a cluster member that it has incorrect
   information about the sets of leaf nodes it should be sending to.  If
   an error occurs on a VC associated with a particular group, the
   cluster member initiates revalidation procedures for that specific
   group. If a jump is detected in the Cluster Sequence Number, this
   initiates revalidation of all groups to which the cluster member
   currently has open point to multipoint VCs.

   Each open and active multipoint VC has a flag associated with it
   called 'VC_revalidate'. This flag is checked everytime a packet is
   queued for transmission on that VC. If the flag is false, the packet
   is transmitted and no further action is required.

   However, if the VC_revalidate flag is true then the packet is
   transmitted and a new sequence of events is started locally.

   Revalidation begins with re-issuing a MARS_REQUEST for the group
   being revalidated.  The returned set of members {NewATM.1, NewATM.2,
   .... NewATM.n} is compared with the set already held locally.
   L_MULTI_DROPs are issued on the group's VC for each node that appears
   in the original set of members but not in the revalidated set of
   members. L_MULTI_ADDs are issued on the group's VC for each node that
   appears in the revalidated set of members but not in the original set
   of members. The VC_revalidate flag is reset when revalidation
   concludes for the given group. Implementation specific mechanisms
   will be needed to flag the 'revalidation in progress' state.

   The key difference between constructing a VC (section 5.1.3) and
   revalidating a VC is that packet transmission continues on t