rfc2022.txt

RFC 的详细文档！

   For the rest of this document references to the mar$op value SHALL be
   taken to mean mar$op.type, with mar$op.version = 0x00. The values
   used in this document are summarised in section 11.

   (Note this number space is independent of the ATMARP operation code
   number space.)

4.3.6 Reserved.

   mar$hdrrsv may be subdivided and assigned specific meanings for other
   control protocols indicated by mar$op.version != 0.

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.




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


   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.)









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


   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.





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


   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.








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


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   |
               +-+-+-+-+-+-+-+-+









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


   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