rfc2022.txt

RFC 的详细文档！

   senders increases).

   Finally, as noted above, MCSs introduce a 'reflected packet' problem,
   which requires additional per-AAL_SDU information to be carried in
   order for layer 3 sources to detect their own AAL_SDUs coming back.

   The MARS architecture allows system administrators to utilize either
   approach on a group by group basis.

3.4 Interaction with local UNI 3.0/3.1 signalling entity.

   The following generic signalling functions are presumed to be
   available to local AAL Users:

   L_CALL_RQ     - Establish a unicast VC to a specific endpoint.
   L_MULTI_RQ    - Establish multicast VC to a specific endpoint.
   L_MULTI_ADD   - Add new leaf node to previously established VC.
   L_MULTI_DROP  - Remove specific leaf node from established VC.
   L_RELEASE     - Release unicast VC, or all Leaves of a multicast VC.

   The signalling exchanges and local information passed between AAL
   User and UNI 3.0/3.1 signalling entity with these functions are
   outside the scope of this document.

   The following indications are assumed to be available to AAL Users,
   generated by the local UNI 3.0/3.1 signalling entity:

   L_ACK          - Succesful completion of a local request.
   L_REMOTE_CALL  - A new VC has been established to the AAL User.
   ERR_L_RQFAILED - A remote ATM endpoint rejected an L_CALL_RQ,
                    L_MULTI_RQ, or L_MULTI_ADD.
   ERR_L_DROP     - A remote ATM endpoint dropped off an existing VC.
   ERR_L_RELEASE  - An existing VC was terminated.

   The signalling exchanges and local information passed between AAL
   User and UNI 3.0/3.1 signalling entity with these functions are
   outside the scope of this document.




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


4.  Overview of the MARS.

   The MARS may reside within any ATM endpoint that is directly
   addressable by the endpoints it is serving. Endpoints wishing to join
   a multicast cluster must be configured with the ATM address of the
   node on which the cluster's MARS resides.  (Section 5.4 describes how
   backup MARSs may be added to support the activities of a cluster.
   References to 'the MARS' in following sections will be assumed to
   mean the acting MARS for the cluster.)

4.1  Architecture.

   Architecturally the MARS is an evolution of the RFC 1577 ARP Server.
   Whilst the ARP Server keeps a table of {IP,ATM} address pairs for all
   IP endpoints in an LIS, the MARS keeps extended tables of {layer 3
   address, ATM.1, ATM.2, ..... ATM.n} mappings. It can either be
   configured with certain mappings, or dynamically 'learn' mappings.
   The format of the {layer 3 address} field is generally not
   interpreted by the MARS.

   A single ATM node may support multiple logical MARSs, each of which
   support a separate cluster. The restriction is that each MARS has a
   unique ATM address (e.g. a different SEL field in the NSAP address of
   the node on which the multiple MARSs reside).  By definition a single
   instance of a MARS may not support more than one cluster.

   The MARS distributes group membership update information to cluster
   members over a point to multipoint VC known as the ClusterControlVC.
   Additionally, when Multicast Servers (MCSs) are being used it also
   establishes a separate point to multipoint VC out to registered MCSs,
   known as the ServerControlVC.  All cluster members are leaf nodes of
   ClusterControlVC. All registered multicast servers are leaf nodes of
   ServerControlVC (described further in section 6).

   The MARS does NOT take part in the actual multicasting of layer 3
   data packets.

4.2  Control message format.

   By default all MARS control messages MUST be LLC/SNAP encapsulated
   using the following codepoints:

      [0xAA-AA-03][0x00-00-5E][0x00-03][MARS control message]
          (LLC)       (OUI)     (PID)

   (This is a PID from the IANA OUI.)





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


   MARS control messages are made up of 4 major components:

      [Fixed header][Mandatory fields][Addresses][Supplementary TLVs]

   [Fixed header] contains fields indicating the operation being
   performed and the layer 3 protocol being referred to (e.g IPv4, IPv6,
   AppleTalk, etc). The fixed header also carries checksum information,
   and hooks to allow this basic control message structure to be re-used
   by other query/response protocols.

   The [Mandatory fields] section carries fixed width parameters that
   depend on the operation type indicated in [Fixed header].

   The following [Addresses] area carries variable length fields for
   source and target addresses - both hardware (e.g. ATM) and layer 3
   (e.g. IPv4). These provide the fundamental information that the
   registrations, queries, and updates use and operate on. For the MARS
   protocol fields in [Fixed header] indicate how to interpret the
   contents of [Addresses].

   [Supplementary TLVs] represents an optional list of TLV (type,
   length, value) encoded information elements that may be appended to
   provide supplementary information.  This feature is described in
   further detail in section 10.

   MARS messages contain variable length address fields. In all cases
   null addresses SHALL be encoded as zero length, and have no space
   allocated in the message.

   (Unique LLC/SNAP encapsulation of MARS control messages means MARS
   and ARP Server functionality may be implemented within a common
   entity, and share a client-server VC, if the implementor so chooses.
   Note that the LLC/SNAP codepoint for MARS is different to the
   codepoint used for ATMARP.)

4.3  Fixed header fields in MARS control messages.

   The [Fixed header] has the following format:

      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.
       mar$shtl      8 bits  Type & length of source ATM number. (r)
       mar$sstl      8 bits  Type & length of source ATM subaddress. (q)



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


   mar$shtl and mar$sstl provide information regarding the source's
   hardware (ATM) address. In the MARS protocol these fields are always
   present, as every MARS message carries a non-null source ATM address.
   In all cases the source ATM address is the first variable length
   field in the [Addresses] section.

   The other fields in [Fixed header] are described in the following
   subsections.

4.3.1  Hardware type.

   mar$afn defines the type of link layer addresses being carried. The
   value of 0x000F SHALL be used by MARS messages generated in
   accordance with this document. The encoding of ATM addresses and
   subaddresses when mar$afn = 0x000F is described in section 5.1.2.
   Encodings when mar$afn != 0x000F are outside the scope of this
   document.

4.3.2  Protocol type.

   The mar$pro field is made up of two subfields:

      mar$pro.type 16 bits  Protocol type.
      mar$pro.snap 40 bits  Optional SNAP extension to protocol type.

   The mar$pro.type field is a 16 bit unsigned integer representing the
   following number space:

      0x0000 to 0x00FF  Protocols defined by the equivalent NLPIDs.
      0x0100 to 0x03FF  Reserved for future use by the IETF.
      0x0400 to 0x04FF  Allocated for use by the ATM Forum.
      0x0500 to 0x05FF  Experimental/Local use.
      0x0600 to 0xFFFF  Protocols defined by the equivalent Ethertypes.

   (based on the observations that valid Ethertypes are never smaller
   than 0x600, and NLPIDs never larger than 0xFF.)

   The NLPID value of 0x80 is used to indicate a SNAP encoded extension
   is being used to encode the protocol type. When mar$pro.type == 0x80
   the SNAP extension is encoded in the mar$pro.snap field.  This is
   termed the 'long form' protocol ID.

   If mar$pro.type != 0x80 then the mar$pro.snap field MUST be zero on
   transmit and ignored on receive. The mar$pro.type field itself
   identifies the protocol being referred to. This is termed the 'short
   form' protocol ID.





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


   In all cases, where a protocol has an assigned number in the
   mar$pro.type space (excluding 0x80) the short form MUST be used when
   transmitting MARS messages. Additionally, where a protocol has valid
   short and long forms of identification, receivers MAY choose to
   recognise the long form.

   mar$pro.type values other than 0x80 MAY have 'long forms' defined in
   future documents.

   For the remainder of this document references to mar$pro SHALL be
   interpreted to mean mar$pro.type, or mar$pro.type in combination with
   mar$pro.snap as appropriate.

   The use of different protocol types is described further in section
   9.

4.3.3 Checksum.

   The mar$chksum field carries a standard IP checksum calculated across
   the entire MARS control message (excluding the LLC/SNAP header). The
   field is set to zero before performing the checksum calculation.

   As the entire LLC/SNAP encapsulated MARS message is protected by the
   32 bit CRC of the AAL5 transport, implementors MAY choose to ignore
   the checksum facility. If no checksum is calculated these bits MUST
   be reset before transmission. If no checksum is performed on
   reception, this field MUST be ignored. If a receiver is capable of
   validating a checksum it MUST only perform the validation when the
   received mar$chksum field is non-zero. Messages arriving with
   mar$chksum of 0 are always considered valid.

4.3.4 Extensions Offset.

   The mar$extoff field identifies the existence and location of an
   optional supplementary parameters list. Its use is described in
   section 10.















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


4.3.5 Operation code.

   The mar$op field is further subdivided into two 8 bit fields -
   mar$op.version (leading octet) and mar$op.type (trailing octet).
   Together they indicate the nature of the control message, and the
   context within which its [Mandatory fields], [Addresses], and
   [Supplementary TLVs] should be interpreted.

      mar$op.version
         0               MARS protocol defined in this document.
         0x01 - 0xEF     Reserved for future use by the IETF.
         0xF0 - 0xFE     Allocated for use by the ATM Forum.
         0xFF            Experimental/Local use.

      mar$op.type
         Value indicates operation being performed, within context of
         the control protocol version indicated by mar$op.version.