tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2022

 
 
 

Support for Multicast over UNI 3.0/3.1 based ATM Networks

Part 2 of 4, p. 16 to 42
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 16 
5.  Endpoint (MARS client) interface behaviour.

   An endpoint is best thought of as a 'shim' or 'convergence' layer,
   sitting between a layer 3 protocol's link layer interface and the
   underlying UNI 3.0/3.1 service. An endpoint in this context can exist
   in a host or a router - any entity that requires a generic 'layer 3
   over ATM' interface to support layer 3 multicast.  It is broken into
   two key subsections - one for the transmit side, and one for the
   receive side.

   Multiple logical ATM interfaces may be supported by a single physical
   ATM interface (for example, using different SEL values in the NSAP
   formatted address assigned to the physical ATM interface). Therefore
   implementors MUST allow for multiple independent 'layer 3 over ATM'
   interfaces too, each with its own configured MARS (or table of MARSs,
   as discussed in section 5.4), and ability to be attached to the same
   or different clusters.

Top      Up      ToC       Page 17 
   The initial signalling path between a MARS client (managing an
   endpoint) and its associated MARS is a transient point to point,
   bidirectional VC.  This VC is established by the MARS client, and is
   used to send queries to, and receive replies from, the MARS. It has
   an associated idle timer, and is dismantled if not used for a
   configurable period of time. The minimum suggested value for this
   time is 1 minute, and the RECOMMENDED default is 20 minutes.  (Where
   the MARS and ARP Server are co-resident, this VC may be used for both
   ATM ARP traffic and MARS control traffic.)

   The remaining signalling path is ClusterControlVC, to which the MARS
   client is added as a leaf node when it registers (described in
   section 5.2.3).

   The majority of this document covers the distribution of information
   allowing endpoints to establish and manage outgoing point to
   multipoint VCs - the forwarding paths for multicast traffic to
   particular multicast groups. The actual format of the AAL_SDUs sent
   on these VCs is almost completely outside the scope of this
   specification.  However, endpoints are not expected to know whether
   their forwarding path leads directly to a multicast group's members
   or to an MCS (described in section 3). This requires additional per-
   packet encapsulation (described in section 5.5) to aid in the the
   detection of reflected AAL_SDUs.

5.1  Transmit side behaviour.

   The following description will often be in terms of an IPv4/ATM
   interface that is capable of transmitting packets to a Class D
   address at any time, without prior warning. It should be trivial for
   an implementor to generalise this behaviour to the requirements of
   another layer 3 data protocol.

   When a local Layer 3 entity passes down a packet for transmission,
   the endpoint first ascertains whether an outbound path to the
   destination multicast group already exists. If it does not, the MARS
   is queried for a set of ATM endpoints that represent an appropriate
   forwarding path. (The ATM endpoints may represent the actual group
   members within the cluster, or a set of one or more MCSs. The
   endpoint does not distinguish between either case. Section 6.2
   describes the MARS behaviour that leads to MCSs being supplied as the
   forwarding path for a multicast group.)

Top      Up      ToC       Page 18 
   The query is executed by issuing a MARS_REQUEST.  The reply from the
   MARS may take one of two forms:

      MARS_MULTI - Sequence of MARS_MULTI messages returning the set of
                   ATM endpoints that are to be leaf nodes of an
                   outgoing point to multipoint VC (the forwarding
                   path).

      MARS_NAK - No mapping found, group is empty.

   The formats of these messages are described in section 5.1.2.

   Outgoing VCs are established with a request for Unspecified Bit Rate
   (UBR) service, as typified by the IETF's use of VCs for unicast IP,
   described in RFC 1755 [6].  Future documents may vary this approach
   and allow the specification of different ATM traffic parameters from
   locally configured information or parameters obtained through some
   external means.

5.1.1   Retrieving Group Membership from the MARS.

   If the MARS had no mapping for the desired Class D address a MARS_NAK
   will be returned. In this case the IP packet MUST be discarded
   silently. If a match is found in the MARS's tables it proceeds to
   return addresses ATM.1 through ATM.n in a sequence of one or more
   MARS_MULTIs.  A simple mechanism is used to detect and recover from
   loss of MARS_MULTI messages.

   (If the client learns that there is no other group member in the
   cluster - the MARS returns a MARS_NAK or returns a MARS_MULTI with
   the client as the only member - it MUST delay sending out a new
   MARS_REQUEST for that group for a period no less than 5 seconds and
   no more than 10 seconds.)

   Each MARS_MULTI carries a boolean field x, and a 15 bit integer field
   y - expressed as MARS_MULTI(x,y). Field y acts as a sequence number,
   starting at 1 and incrementing for each MARS_MULTI sent.  Field x
   acts as an 'end of reply' marker. When x == 1 the MARS response is
   considered complete.

   In addition, each MARS_MULTI may carry multiple ATM addresses from
   the set {ATM.1, ATM.2, .... ATM.n}. A MARS MUST minimise the number
   of MARS_MULTIs transmitted by placing as many group members'
   addresses in a single MARS_MULTI as possible. The limit on the length
   of an individual MARS_MULTI message MUST be the MTU of the underlying
   VC.

Top      Up      ToC       Page 19 
   For example, assume n ATM addresses must be returned, each MARS_MULTI
   is limited to only p ATM addresses, and p << n. This would require a
   sequence of k MARS_MULTI messages (where k = (n/p)+1, using integer
   arithmetic), transmitted as follows:

      MARS_MULTI(0,1) carries back {ATM.1 ... ATM.p}
      MARS_MULTI(0,2) carries back {ATM.(p+1) ... ATM.(2p)}
            [.......]
      MARS_MULTI(1,k) carries back { ... ATM.n}

   If k == 1 then only MARS_MULTI(1,1) is sent.

   Typical failure mode will be losing one or more of MARS_MULTI(0,1)
   through MARS_MULTI(0,k-1). This is detected when y jumps by more than
   one between consecutive MARS_MULTI's. An alternative failure mode is
   losing MARS_MULTI(1,k).  A timer MUST be implemented to flag the
   failure of the last MARS_MULTI to arrive. A default value of 10
   seconds is RECOMMENDED.

   If a 'sequence jump' is detected, the host MUST wait for the
   MARS_MULTI(1,k), discard all results, and repeat the MARS_REQUEST.

   If a timeout occurs, the host MUST discard all results, and repeat
   the MARS_REQUEST.

   A final failure mode involves the MARS Sequence Number (described in
   section 5.1.4.2 and carried in each part of a multi-part MARS_MULTI).
   If its value changes during the reception of a multi-part MARS_MULTI
   the host MUST wait for the MARS_MULTI(1,k), discard all results, and
   repeat the MARS_REQUEST.

   (Corruption of cell contents will lead to loss of a MARS_MULTI
   through AAL5 CPCS_PDU reassembly failure, which will be detected
   through the mechanisms described above.)

   If the MARS is managing a cluster of endpoints spread across
   different but directly accessible ATM networks it will not be able to
   return all the group members in a single MARS_MULTI. The MARS_MULTI
   message format allows for either E.164, ISO NSAP, or (E.164 + NSAP)
   to be returned as ATM addresses. However, each MARS_MULTI message may
   only return ATM addresses of the same type and length. The returned
   addresses MUST be grouped according to type (E.164, ISO NSAP, or
   both) and returned in a sequence of separate MARS_MULTI parts.

Top      Up      ToC       Page 20 
5.1.2   MARS_REQUEST, MARS_MULTI, and MARS_NAK messages.

   MARS_REQUEST is shown below. It is indicated by an 'operation type
   value' (mar$op) of 1.

   The multicast address being resolved is placed into the the target
   protocol address field (mar$tpa), and the target hardware address is
   set to null (mar$thtl and mar$tstl both zero).

   In IPv4 environments the protocol type (mar$pro) is 0x800 and the
   target protocol address length (mar$tpln) MUST be set to 4. The
   source fields MUST contain the ATM number and subaddress of the
   client issuing the MARS_REQUEST (the subaddress MAY be null).

      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_REQUEST = 1)
       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$pad      64 bits  Padding (aligns mar$sha with MARS_MULTI).
       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
       mar$tha      xoctets  target ATM number
       mar$tsa      yoctets  target ATM subaddress

   Following the RFC1577 approach, the mar$shtl, mar$sstl, mar$thtl and
   mar$tstl fields are coded as follows:

                7 6 5 4 3 2 1 0
               +-+-+-+-+-+-+-+-+
               |0|x|  length   |
               +-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 21 
   The most significant bit is reserved and MUST be set to zero.  The
   second most significant bit (x) is a flag indicating whether the ATM
   address being referred to is in:

      - ATM Forum NSAPA format (x = 0).
      - Native E.164 format (x = 1).

   The bottom 6 bits is an unsigned integer value indicating the length
   of the associated ATM address in octets. If this value is zero the
   flag x is ignored.

   The mar$spln and mar$tpln fields are unsigned 8 bit integers, giving
   the length in octets of the source and target protocol address fields
   respectively.

   MARS packets use true variable length fields. A null (non-existant)
   address MUST be coded as zero length, and no space allocated for it
   in the message body.

   MARS_NAK is the MARS_REQUEST returned with operation type value of 6.
   All other fields are left unchanged from the MARS_REQUEST (e.g. do
   not transpose the source and target information. In all cases MARS
   clients use the source address fields to identify their own messages
   coming back).

   The MARS_MULTI message is identified by an mar$op value of 2. The
   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

Top      Up      ToC       Page 22 
       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.

Top      Up      ToC       Page 23 
   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

Top      Up      ToC       Page 24 
   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.

Top      Up      ToC       Page 25 
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

Top      Up      ToC       Page 26 
   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 the open
   VC while it is being revalidated. This minimises the disruption to
   existing traffic.

   The algorithm for initiating revalidation is:

      - When a packet arrives for transmission on a given group,
        the groups membership is revalidated if VC_revalidate == TRUE.
        Revalidation resets VC_revalidate.
      - When an event occurs that demands revalidation, every
        group has its VC_revalidate flag set TRUE at a random time
        between 1 and 10 seconds.

   Benefit: Revalidation of active groups occurs quickly, and
   essentially idle groups are revalidated as needed. Randomly
   distributed setting of VC_revalidate flag improves chances of

Top      Up      ToC       Page 27 
   staggered revalidation requests from senders when a sequence number
   jump is detected.

5.1.5.1   When leaf node drops itself.

   During the life of a multipoint VC an ERR_L_DROP may be received
   indicating that a leaf node has terminated its participation at the
   ATM level. The ATM endpoint associated with the ERR_L_DROP MUST be
   removed from the locally held set {ATM.1, ATM.2, .... ATM.n}
   associated with the VC.

   After a random period of time between 1 and 10 seconds the
   VC_revalidate flag associated with that VC MUST be set true.

   If an ERR_L_RELEASE is received then the entire set {ATM.1, ATM.2,
   .... ATM.n} is cleared and the VC is considered to be completely shut
   down. Further packet transmission to the group served by this VC will
   result in a new VC being established as described in section 5.1.3.

5.1.5.2   When a jump is detected in the CSN.

   Section 5.1.4.2 describes how a CSN jump is detected. If a CSN jump
   is detected upon receipt of a MARS_JOIN or a MARS_LEAVE then every
   outgoing multicast VC MUST have its VC_revalidate flag set true at
   some random interval between 1 and 10 seconds from when the CSN jump
   was detected.

   The only exception to this rule is if a sequence number jump is
   detected during the establishment of a new group's VC (i.e. a
   MARS_MULTI reply was correctly received, but its mar$msn indicated
   that some previous MARS traffic had been missed on ClusterControlVC).
   In this case every open VC, EXCEPT the one just established, MUST
   have its VC_revalidate flag set true at some random interval between
   1 and 10 seconds from when the CSN jump was detected.  (The VC being
   established at the time is considered already validated.)

5.1.6  'Migrating' the outgoing multipoint VC

   In addition to the group tracking described in section 5.1.4, the
   transmit side of a cluster member must respond to 'migration'
   requests by the MARS. This is triggered by the reception of a
   MARS_MIGRATE message from ClusterControlVC. The MARS_MIGRATE message
   is shown below, with an mar$op code of 13.

      Data:
       mar$afn      16 bits  Address Family (0x000F).
       mar$pro      56 bits  Protocol Identification.
       mar$hdrrsv   24 bits  Reserved. Unused by MARS control protocol.

Top      Up      ToC       Page 28 
       mar$chksum   16 bits  Checksum across entire MARS message.
       mar$extoff   16 bits  Extensions Offset.
       mar$op       16 bits  Operation code (MARS_MIGRATE = 13).
       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$resv     16 bits  Reserved.
       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
       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

   A migration is requested when the MARS determines that it no longer
   wants cluster members forwarding their packets directly to the ATM
   addresses it had previously specified (through MARS_REQUESTs or
   MARS_JOINs). When a MARS_MIGRATE is received each cluster member MUST
   perform the following steps:

      Close down any existing outgoing VC associated with the group
      carried in the mar$tpa field (L_RELEASE), or dissociate the group
      from any outgoing VC it may have been sharing (as described in
      section 5.1.3).

      Establish a new outgoing VC for the specified group, using the
      algorithm described in section 5.1.3 and taking the set of ATM
      addresses supplied in the MARS_MIGRATE as the group's new set of
      members {ATM.1, .... ATM.n}.

   The MARS_MIGRATE carries the new set of members {ATM.1, .... ATM.n}
   in a single message, in similar manner to a single part MARS_MULTI.
   As with other messages from the MARS, the Cluster Sequence Number
   carried in mar$msn is checked as described in section 5.1.4.2.

Top      Up      ToC       Page 29 
5.2.   Receive side behaviour.

   A cluster member is a 'group member' (in the sense that it receives
   packets directed at a given multicast group) when its ATM address
   appears in the MARS's table entry for the group's multicast address.
   A key function within each cluster is the distribution of group
   membership information from the MARS to cluster members.

   An endpoint may wish to 'join a group' in response to a local, higher
   level request for membership of a group, or because the endpoint
   supports a layer 3 multicast forwarding engine that requires the
   ability to 'see' intra-cluster traffic in order to forward it.

   Two messages support these requirements - MARS_JOIN and MARS_LEAVE.
   These are sent to the MARS by endpoints when the local layer 3/ATM
   interface is requested to join or leave a multicast group. The MARS
   propagates these messages back out over ClusterControlVC, to ensure
   the knowledge of the group's membership change is distributed in a
   timely fashion to other cluster members.

   Certain models of layer 3 endpoints (e.g. IP multicast routers)
   expect to be able to receive packet traffic 'promiscuously' across
   all groups.  This functionality may be emulated by allowing routers
   to request that the MARS returns them as 'wild card' members of all
   Class D addresses.  However, a problem inherent in the current ATM
   model is that a completely promiscuous router may exhaust the local
   reassembly resources in its ATM interface. MARS_JOIN supports a
   generalisation to the notion of 'wild card' entries, enabling routers
   to limit themselves to 'blocks' of the Class D address space. Use of
   this facility is described in greater detail in Section 8.

   A block can be as small as 1 (a single group) or as large as the
   entire multicast address space (e.g. default IPv4 'promiscuous'
   behaviour).  A block is defined as all addresses between, and
   inclusive of, a <min,max> address pair. A MARS_JOIN or MARS_LEAVE may
   carry multiple <min,max> pairs.

   Cluster members MUST provide ONLY a single <min,max> pair in each
   JOIN/LEAVE message they issue. However, they MUST be able to process
   multiple <min,max> pairs in JOIN/LEAVE messages when performing VC
   management as described in section 5.1.4 (the interpretation being
   that the join/leave operation applies to all addresses in the range
   from <min> to <max> inclusive, for every <min,max> pair).

   In RFC1112 environments a MARS_JOIN for a single group is triggered
   by a JoinLocalGroup signal from the IP layer. A MARS_LEAVE for a
   single group is triggered by a LeaveLocalGroup signal from the IP
   layer.

Top      Up      ToC       Page 30 
   Cluster members with special requirements (e.g. multicast routers)
   may issue MARS_JOINs and MARS_LEAVEs specifying a single block of 2
   or more multicast group addresses. However, a cluster member SHALL
   NOT issue such a multi-group block join for an address range fully or
   partially overlapped by multi-group block join(s) that the cluster
   member has previously issued and not yet retracted. A cluster member
   MAY issue combinations of single group MARS_JOINs that overlap with a
   multi-group block MARS_JOIN.

   An endpoint MUST register with a MARS in order to become a member of
   a cluster and be added as a leaf to ClusterControlVC.  Registration
   is covered in section 5.2.3.

   Finally, the endpoint MUST be capable of terminating unidirectional
   VCs (i.e. act as a leaf node of a UNI 3.0/3.1 point to multipoint VC,
   with zero bandwidth assigned on the return path). RFC 1755 describes
   the signalling information required to terminate VCs carrying
   LLC/SNAP encapsulated traffic (discussed further in section 5.5).

5.2.1 Format of the MARS_JOIN and MARS_LEAVE Messages.

   The MARS_JOIN message is indicated by an operation type value of 4.
   MARS_LEAVE has the same format and operation type value of 5. The
   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_JOIN or MARS_LEAVE).
       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$tpln      8 bits  Length of group address (z)
       mar$pnum     16 bits  Number of group address pairs (N)
       mar$flags    16 bits  layer3grp, copy, and register flags.
       mar$cmi      16 bits  Cluster Member ID
       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$min.1    zoctets  Minimum multicast group address - pair.1
       mar$max.1    zoctets  Maximum multicast group address - pair.1
                 [.......]
       mar$min.N    zoctets  Minimum multicast group address - pair.N
       mar$max.N    zoctets  Maximum multicast group address - pair.N

Top      Up      ToC       Page 31 
   mar$spln indicates the number of bytes in the source endpoint's
   protocol address, and is interpreted in the context of the protocol
   indicated by the mar$pro field. (e.g. in IPv4 environments mar$pro
   will be 0x800, mar$spln is 4, and mar$tpln is 4.)

   The mar$flags field contains three flags:

      Bit 15  - mar$flags.layer3grp.
      Bit 14  - mar$flags.copy.
      Bit 13  - mar$flags.register.
      Bit 12  - mar$flags.punched.
      Bit 0-7 - mar$flags.sequence.

   Bits 8 to 11 are reserved and MUST be zero.

   mar$flags.sequence is set by cluster members, and MUST always be
   passed on unmodified by the MARS when retransmitting MARS_JOIN or
   MARS_LEAVE messages. It is source specific, and MUST be ignored by
   other cluster members. Its use is described in section 5.2.2.

   mar$flags.punched MUST be zero when the MARS_JOIN or MARS_LEAVE is
   transmitted to the MARS. Its use is described in section 5.2.2 and
   section 6.2.4.

   mar$flags.copy MUST be set to 0 when the message is being sent from a
   MARS client, and MUST be set to 1 when the message is being sent from
   a MARS. (This flag is intended to support integrating the MARS
   function with one of the MARS clients in your cluster. The
   destination of an incoming MARS_JOIN can be determined from its
   value.)

   mar$flags.layer3grp allows the MARS to provide the group membership
   information described further in section 5.3. The rules for its use
   are:

      mar$flags.layer3grp MUST be set when the cluster member is issuing
      the MARS_JOIN as the result of a layer 3 multicast group being
      explicitly joined. (e.g. as a result of a JoinHostGroup operation
      in an RFC1112 compliant host).

      mar$flags.layer3grp MUST be reset in each MARS_JOIN if the
      MARS_JOIN is simply the local ip/atm interface registering to
      receive traffic on that group for its own reasons.

      mar$flags.layer3grp is ignored and MUST be treated as reset by the
      MARS for any MARS_JOIN that specifies a block covering more than a
      single group (e.g. a block join from a router ensuring their
      forwarding engines 'see' all traffic).

Top      Up      ToC       Page 32 
   mar$flags.register indicates whether the MARS_JOIN or MARS_LEAVE is
   being used to register or deregister a cluster member (described in
   section 5.2.3). When used to join or leave specific groups the
   mar$register flag MUST be zero.

   mar$pnum indicates how many <min,max> pairs are included in the
   message. This field MUST be 1 when the message is sent from a cluster
   member. A MARS MAY return a MARS_JOIN or MARS_LEAVE with any mar$pnum
   value, including zero.  This will be explained futher in section
   6.2.4.

   The mar$cmi field MUST be zeroed by cluster members, and is used by
   the MARS during cluster member registration, described in section
   5.2.3.

   mar$msn MUST be zero when transmitted by an endpoint. It is set to
   the current value of the Cluster Sequence Number by the MARS when the
   MARS_JOIN or MARS_LEAVE is retransmitted. Its use has been described
   in section 5.1.4.

   To simplify construction and parsing of MARS_JOIN and MARS_LEAVE
   messages, the following restrictions are imposed on the <min,max>
   pairs:

      Assume max(N) is the <max> field from the Nth <min,max> pair.
      Assume min(N) is the <min> field from the Nth <min,max> pair.
      Assume a join/leave message arrives with K <min,max> pairs.
      The following must hold:
         max(N) < min(N+1) for 1 <= N < K
         max(N) >= min(N) for 1 <= N <= K

   In plain language, the set must specify an ascending sequence of
   address blocks. The definition of "greater" or "less than" may be
   protocol specific. In IPv4 environments the addresses are treated as
   32 bit, unsigned binary values (most significant byte first).

5.2.1.1 Important IPv4 default values.

   The JoinLocalGroup and LeaveLocalGroup operations are only valid for
   a single group. For any arbitrary group address X the associated
   MARS_JOIN or MARS_LEAVE MUST specify a single pair <X, X>.
   mar$flags.layer3grp MUST be set under these circumstances.

   A router choosing to behave strictly in accordance with RFC1112 MUST
   specify the entire Class D space. The associated MARS_JOIN or
   MARS_LEAVE MUST specify a single pair <224.0.0.0, 239.255.255.255>.
   Whenever a router issues a MARS_JOIN only in order to forward IP
   traffic it MUST reset mar$flags.layer3grp.

Top      Up      ToC       Page 33 
   The use of alternative <min, max> values by multicast routers is
   discussed in Section 8.

5.2.2   Retransmission of MARS_JOIN and MARS_LEAVE messages.

   Transient problems may result in the loss of messages between the
   MARS and cluster members

   A simple algorithm is used to solve this problem. Cluster members
   retransmit each MARS_JOIN and MARS_LEAVE message at regular intervals
   until they receive a copy back again, either on ClusterControlVC or
   the VC on which they are sending the message.  At this point the
   local endpoint can be certain that the MARS received and processed
   it.

   The interval should be no shorter than 5 seconds, and a default value
   of 10 seconds is recommended. After 5 retransmissions the attempt
   should be flagged locally as a failure. This MUST be considered as a
   MARS failure, and triggers the MARS reconnection described in section
   5.4.

   A 'copy' is defined as a received message with the following fields
   matching a previously transmitted MARS_JOIN/LEAVE:

      - mar$op
      - mar$flags.register
      - mar$flags.sequence
      - mar$pnum
      - Source ATM address
      - First <min,max> pair

   In addition, a valid copy MUST have the following field values:

      - mar$flags.punched = 0
      - mar$flags.copy = 1

   The mar$flags.sequence field is never modified or checked by a MARS.
   Implementors MAY choose to utilize locally significant sequence
   number schemes, which MAY differ from one cluster member to the next.
   In the absence of such schemes the default value for
   mar$flags.sequence MUST be zero.

   Careful implementations MAY have more than one unacknowledged
   MARS_JOIN/LEAVE outstanding at a time.

Top      Up      ToC       Page 34 
5.2.3   Cluster member registration and deregistration.

   To become a cluster member an endpoint must register with the MARS.
   This achieves two things - the endpoint is added as a leaf node of
   ClusterControlVC, and the endpoint is assigned a 16 bit Cluster
   Member Identifier (CMI). The CMI uniquely identifies each endpoint
   that is attached to the cluster.

   Registration with the MARS occurs when an endpoint issues a MARS_JOIN
   with the mar$flags.register flag set to one (bit 13 of the mar$flags
   field).

   The cluster member MUST include its source ATM address, and MAY
   choose to specify a null source protocol address when registering.

   No protocol specific group addresses are included in a registration
   MARS_JOIN.

   The cluster member retransmits this MARS_JOIN in accordance with
   section 5.2.2 until it confirms that the MARS has received it.

   When the registration MARS_JOIN is returned it contains a non-zero
   value in mar$cmi. This value MUST be noted by the cluster member, and
   used whenever circumstances require the cluster member's CMI.

   An endpoint may also choose to de-register, using a MARS_LEAVE with
   mar$flags.register set. This would result in the MARS dropping the
   endpoint from ClusterControlVC, removing all references to the member
   in the mapping database, and freeing up its CMI.

   As for registration, a deregistration request MUST include the
   correct source ATM address for the cluster member, but MAY choose to
   specify a null source protocol address.

   The cluster member retransmits this MARS_LEAVE in accordance with
   section 5.2.2 until it confirms that the MARS has received it.

5.3   Support for Layer 3 group management.

   Whilst the intention of this specification is to be independent of
   layer 3 issues, an attempt is being made to assist the operation of
   layer 3 multicast routing protocols that need to ascertain if any
   groups have members within a cluster.

   One example is IP, where IGMP is used (as described in section 2)
   simply to determine whether any other cluster members are listening
   to a group because they have higher layer applications that want to
   receive a group's traffic.

Top      Up      ToC       Page 35 
   Routers may choose to query the MARS for this information, rather
   than multicasting IGMP queries to 224.0.0.1 and incurring the
   associated cost of setting up a VC to all systems in the cluster.

   The query is issued by sending a MARS_GROUPLIST_REQUEST to the MARS.
   MARS_GROUPLIST_REQUEST is built from a MARS_JOIN, but it has an
   operation code of 10. The first <min,max> pair will be used by the
   MARS to identify the range of groups in which the querying cluster
   member is interested. Any additional <min,max> pairs will be ignored.
   A request with mar$pnum = 0 will be ignored.

   The response from the MARS is a MARS_GROUPLIST_REPLY, carrying a list
   of the multicast groups within the specified <min,max> block that
   have Layer 3 members.  A group is noted in this list if one or more
   of the MARS_JOINs that generated its mapping entry in the MARS
   contained a set mar$flags.layer3grp flag.

   MARS_GROUPLIST_REPLYs are transmitted back to the querying cluster
   member on the VC used to send the MARS_GROUPLIST_REQUEST.

   MARS_GROUPLIST_REPLY is derived from the MARS_MULTI but with mar$op =
   11. It may have multiple parts if needed, and is received in a
   similar manner to a MARS_MULTI.

      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_GROUPLIST_REPLY).
       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  Unused - set to zero.
       mar$tstl      8 bits  Unused - set to zero.
       mar$tpln      8 bits  Length of target group address (z)
       mar$tnum     16 bits  Number of group 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$mgrp.1   zoctets  Group address 1
                 [.......]
       mar$mgrp.N   zoctets  Group address N

   mar$seqxy is coded as for the MARS_MULTI - multiple

Top      Up      ToC       Page 36 
   MARS_GROUPLIST_REPLY components are transmitted and received using
   the same algorithm as described in section 5.1.1 for MARS_MULTI. The
   only difference is that protocol addresses are being returned rather
   than ATM addresses.

   As for MARS_MULTIs, if an error occurs in the reception of a multi
   part MARS_GROUPLIST_REPLY the whole thing MUST be discarded and the
   MARS_GROUPLIST_REQUEST re-issued. (This includes the mar$msn value
   being constant.)

   Note that the ability to generate MARS_GROUPLIST_REQUEST messages,
   and receive MARS_GROUPLIST_REPLY messages, is not required for
   general host interface implementations. It is optional for interfaces
   being implemented to support layer 3 multicast forwarding engines.
   However, this functionality MUST be supported by the MARS.

5.4   Support for redundant/backup MARS entities.

   Endpoints are assumed to have been configured with the ATM address of
   at least one MARS. Endpoints MAY choose to maintain a table of ATM
   addresses, representing alternative MARSs that will be contacted in
   the event that normal operation with the original MARS is deemed to
   have failed. It is assumed that this table orders the ATM addresses
   in descending order of preference.

   An endpoint will typically decide there are problems with the MARS
   when:

      - It fails to establish a point to point VC to the MARS.
      - MARS_REQUESTs fail (section 5.1.1).
      - MARS_JOIN/MARS_LEAVEs fail (section 5.2.2).
      - It has not received a MARS_REDIRECT_MAP in the last 4 minutes
      (section 5.4.3).

   (If it is able to discern which connection represents
   ClusterControlVC, it may also use connection failures on this VC to
   indicate problems with the MARS).

5.4.1   First response to MARS problems.

   The first response is to assume a transient problem with the MARS
   being used at the time. The cluster member should wait a random
   period of time between 1 and 10 seconds before attempting to re-
   connect and re-register with the MARS. If the registration MARS_JOIN
   is successful then:

        The cluster member MUST then proceed to rejoin every group that
        its local higher layer protocol(s) have joined. It is

Top      Up      ToC       Page 37 
        recommended that a random delay between 1 and 10 seconds be
        inserted before attempting each MARS_JOIN.

        The cluster member MUST initiate the revalidation of every
        multicast group it was sending to (as though a sequence number
        jump had been detected, section 5.1.5).

        The rejoin and revalidation procedure must not disrupt the
        cluster member's use of multipoint VCs that were already open at
        the time of the MARS failure.

   If re-registration with the current MARS fails, and there are no
   backup MARS addresses configured, the cluster member MUST wait for at
   least 1 minute before repeating the re-registration procedure. It is
   RECOMMENDED that the cluster member signals an error condition in
   some locally significant fashion.

   This procedure may repeat until network administrators manually
   intervene or the current MARS returns to normal operation.

5.4.2   Connecting to a backup MARS.

   If the re-registration with the current MARS fails, and other MARS
   addresses have been configured, the next MARS address on the list is
   chosen to be the current MARS, and the cluster member immediately
   restarts the re-registration procedure described in section 5.4.1. If
   this is succesful the cluster member will resume normal operation
   using the new MARS. It is RECOMMENDED that the cluster member signals
   a warning of this condition in some locally significant fashion.

   If the attempt at re-registration with the new MARS fails, the
   cluster member MUST wait for at least 1 minute before choosing the
   next MARS address in the table and repeating the procedure. If the
   end of the table has been reached, the cluster member starts again at
   the top of the table (which should be the original MARS that the
   cluster member started with).

   In the worst case scenario this will result in cluster members
   looping through their table of possible MARS addresses until network
   administrators manually intervene.

5.4.3   Dynamic backup lists, and soft redirects.

   To support some level of autoconfiguration, a MARS message is defined
   that allows the current MARS to broadcast on ClusterControlVC a table
   of backup MARS addresses. When this message is received, cluster
   members that maintain a list of backup MARS addresses MUST insert
   this information at the top of their locally held list (i.e. the

Top      Up      ToC       Page 38 
   information provided by the MARS has a higher preference than
   addresses that may have been manually configured into the cluster
   member).

   The message is MARS_REDIRECT_MAP. It is based on the MARS_MULTI
   message, with the following changes:

      - mar$tpln field replaced by mar$redirf.
      - mar$spln field reserved.
      - mar$tpa and mar$spa eliminated.

   MARS_REDIRECT_MAP has an operation type code of 12 decimal.

      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_REDIRECT_MAP).
       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$redirf    8 bits  Flag controlling client redirect behaviour.
       mar$tnum     16 bits  Number of MARS 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$tha.1    xoctets  ATM number for MARS 1
       mar$tsa.1    yoctets  ATM subaddress for MARS 1
       mar$tha.2    xoctets  ATM number for MARS 2
       mar$tsa.2    yoctets  ATM subaddress for MARS 2
                 [.......]
       mar$tha.N    xoctets  ATM number for MARS N
       mar$tsa.N    yoctets  ATM subaddress for MARS N

   The source ATM address field(s) MUST identify the originating MARS.
   A multi-part MARS_REDIRECT_MAP may be transmitted and reassembled
   using the mar$seqxy field in the same manner as a multi-part
   MARS_MULTI (section 5.1.1). If a failure occurs during the reassembly
   of a multi-part MARS_REDIRECT_MAP (a part lost, reassembly timeout,
   or illegal MARS Sequence Number jump) the entire message MUST be
   discarded.

Top      Up      ToC       Page 39 
   This message is transmitted regularly by the MARS (it MUST be
   transmitted at least every 2 minutes, it is RECOMMENDED that it is
   transmitted every 1 minute).

   The MARS_REDIRECT_MAP is also used to force cluster members to shift
   from one MARS to another. If the ATM address of the first MARS
   contained in a MARS_REDIRECT_MAP table is not the address of cluster
   member's current MARS the client MUST 'redirect' to the new MARS. The
   mar$redirf field controls how the redirection occurs.

   mar$redirf has the following format:

                7 6 5 4 3 2 1 0
               +-+-+-+-+-+-+-+-+
               |x|             |
               +-+-+-+-+-+-+-+-+

   If Bit 7 (the most significant bit) of mar$redirf is 1 then the
   cluster member MUST perform a 'hard' redirect. Having installed the
   new table of MARS addresses carried by the MARS_REDIRECT_MAP, the
   cluster member re-registers with the MARS now at the top of the table
   using the mechanism described in sections 5.4.1 and 5.4.2.

   If Bit 7 of mar$redirf is 0 then the cluster member MUST perform a
   'soft' redirect, beginning with the following actions:

      - open a point to point VC to the first ATM address.
      - attempt a registration (section 5.2.3).

   If the registration succeeds, the cluster member shuts down its point
   to point VC to the current MARS (if it had one open), and then
   proceeds to use the newly opened point to point VC as its connection
   to the 'current MARS'. The cluster member does NOT attempt to rejoin
   the groups it is a member of, or revalidate groups it is currently
   sending to.

   This is termed a 'soft redirect' because it avoids the extra
   rejoining and revalidation processing that occurs when a MARS failure
   is being recovered from. It assumes some external synchronisation
   mechanisms exist between the old and new MARS - mechanisms that are
   outside the scope of this specification.

   Some level of trust is required before initiating a soft redirect. A
   cluster member MUST check that the calling party at the other end of
   the VC on which the MARS_REDIRECT_MAP arrived (supposedly
   ClusterControlVC) is in fact the node it trusts as the current MARS.

   Additional applications of this function are for further study.

Top      Up      ToC       Page 40 
5.5  Data path LLC/SNAP encapsulations.

   An extended encapsulation scheme is required to support the filtering
   of possible reflected packets (section 3.3).

   Two LLC/SNAP codepoints are allocated from the IANA OUI space. These
   support two different mechanisms for detecting reflected packets.
   They are called Type #1 and Type #2 multicast encapsulations.

   Type #1

      [0xAA-AA-03][0x00-00-5E][0x00-01][Type #1 Extended Layer 3 packet]
          LLC         OUI        PID

   Type #2

      [0xAA-AA-03][0x00-00-5E][0x00-04][Type #2 Extended Layer 3 packet]
          LLC         OUI        PID

   For conformance with this document MARS clients:

      MUST transmit data using Type #1 encapsulation.

      MUST be able to correctly receive traffic using Type #1 OR Type #2
      encapsulation.

      MUST NOT transmit using Type #2 encapsulation.

5.5.1 Type #1 encapsulation.

   The Type #1 Extended layer 3 packet carries within it a copy of the
   source's Cluster Member ID (CMI) and either the 'short form' or 'long
   form' of the protocol type as appropriate (section 4.3).

   When carrying packets belonging to protocols with valid short form
   representations the [Type #1 Extended Layer 3 packet] is encoded as:

      [pkt$cmi][pkt$pro][Original Layer 3 packet]
        2octet   2octet        N octet

   The first 2 octets (pkt$cmi) carry the CMI assigned when an endpoint
   registers with the MARS (section 5.2.3). The second 2 octets
   (pkt$pro) indicate the protocol type of the packet carried in the
   remainder of the payload. This is copied from the mar$pro field used
   in the MARS control messages.

   When carrying packets belonging to protocols that only have a long
   form representation (pkt$pro = 0x80) the overhead SHALL be further

Top      Up      ToC       Page 41 
   extended to carry the 5 byte mar$pro.snap field (with padding for 32
   bit alignment). The encoded form SHALL be:

      [pkt$cmi][0x00-80][mar$pro.snap][padding][Original Layer 3 packet]
        2octet   2octet   5 octets   3 octets        N octet


   The CMI is copied into the pkt$cmi field of every outgoing Type #1
   packet.  When an endpoint interface receives an AAL_SDU with the
   LLC/SNAP codepoint indicating Type #1 encapsulation it compares the
   CMI field with its own Cluster Member ID for the indicated protocol.
   The packet is discarded silently if they match. Otherwise the packet
   is accepted for processing by the local protocol entity identified by
   the pkt$pro (and possibly SNAP) field(s).

   Where a protocol has valid short and long forms of identification,
   receivers MAY choose to additionally recognise the long form.

5.5.2 Type #2 encapsulation.

   Future developments may enable direct multicasting of AAL_SDUs beyond
   cluster boundaries. Expanding the set of possible sources in this way
   may cause the CMI to become an inadequate parameter with which to
   detect reflected packets.  A larger source identification field may
   be required.

   The Type #2 Extended layer 3 packet carries within it an 8 octet
   source ID field and either the 'short form' or 'long form' of the
   protocol type as appropriate (section 4.3).  The form and content of
   the source ID field is currently unspecified, and is not relevant to
   any MARS client built in conformance with this document. Received
   Type #2 encapsulated packets MUST always be accepted and passed up to
   the higher layer indicated by the protocol identifier.

   When carrying packets belonging to protocols with valid short form
   representations the [Type #2 Extended Layer 3 packet] is encoded as:

      [8 octet sourceID][mar$pro.type][Null pad][Original Layer 3
      packet]
                           2octets     2octets

   When carrying packets belonging to protocols that only have a long
   form representation (pkt$pro = 0x80) the overhead SHALL be further
   extended to carry the 5 byte mar$pro.snap field (with padding for 32
   bit alignment). The encoded form SHALL be:

      [8 octet sourceID][mar$pro.type][mar$pro.snap][Null pad][Layer 3
      packet]

Top      Up      ToC       Page 42 
                           2octets      5octets      1octet

   (Note that in this case the padding after the SNAP field is 1 octet
   rather than the 3 octets used in Type #1.)

   Where a protocol has valid short and long forms of identification,
   receivers MAY choose to additionally recognise the long form.

   (Future documents may specify the contents of the source ID field.
   This will only be relevant to implementations sending Type #2
   encapsulated packets, as they are the only entities that need to be
   concerned about detecting reflected Type #2 packets.)

5.5.3 A Type #1 example.

   An IPv4 packet (fully identified by an Ethertype of 0x800, therefore
   requiring 'short form' protocol type encoding) would be transmitted
   as:

      [0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x800][IPv4 packet]

      The different LLC/SNAP codepoints for unicast and multicast packet
      transmission allows a single IPv4/ATM interface to support both by
      demuxing on the LLC/SNAP header.



(page 42 continued on part 3)

Next RFC Part