rfc2022.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        G. Armitage
Request for Comments: 2022                                      Bellcore
Category: Standards Track                                  November 1996


       Support for Multicast over UNI 3.0/3.1 based ATM Networks.

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited

Abstract

   Mapping the connectionless IP multicast service over the connection
   oriented ATM services provided by UNI 3.0/3.1 is a non-trivial task.
   This memo describes a mechanism to support the multicast needs of
   Layer 3 protocols in general, and describes its application to IP
   multicasting in particular.

   ATM based IP hosts and routers use a Multicast Address Resolution
   Server (MARS) to support RFC 1112 style Level 2 IP multicast over the
   ATM Forum's UNI 3.0/3.1 point to multipoint connection service.
   Clusters of endpoints share a MARS and use it to track and
   disseminate information identifying the nodes listed as receivers for
   given multicast groups. This allows endpoints to establish and manage
   point to multipoint VCs when transmitting to the group.

   The MARS behaviour allows Layer 3 multicasting to be supported using
   either meshes of VCs or ATM level multicast servers. This choice may
   be made on a per-group basis, and is transparent to the endpoints.

















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


Table of Contents

   1. Introduction.................................................   4
    1.1 The Multicast Address Resolution Server (MARS).............   5
    1.2 The ATM level multicast Cluster............................   5
    1.3 Document overview..........................................   6
    1.4 Conventions................................................   7
   2. The IP multicast service model...............................   7
   3. UNI 3.0/3.1 support for intra-cluster multicasting...........   8
    3.1 VC meshes..................................................   9
    3.2 Multicast Servers..........................................   9
    3.3 Tradeoffs..................................................  10
    3.4 Interaction with local UNI 3.0/3.1 signalling entity.......  11
   4. Overview of the MARS.........................................  12
    4.1 Architecture...............................................  12
    4.2 Control message format.....................................  12
    4.3 Fixed header fields in MARS control messages...............  13
      4.3.1 Hardware type..........................................  14
      4.3.2 Protocol type..........................................  14
      4.3.3 Checksum...............................................  15
      4.3.4 Extensions Offset......................................  15
      4.3.5 Operation code.........................................  16
      4.3.6 Reserved...............................................  16
   5. Endpoint (MARS client) interface behaviour...................  16
    5.1 Transmit side behaviour....................................  17
      5.1.1 Retrieving Group Membership from the MARS..............  18
      5.1.2 MARS_REQUEST, MARS_MULTI, and MARS_NAK messages........  20
      5.1.3 Establishing the outgoing multipoint VC................  22
      5.1.4 Monitoring updates on ClusterControlVC.................  24
        5.1.4.1 Updating the active VCs............................  24
        5.1.4.2 Tracking the Cluster Sequence Number...............  25
      5.1.5 Revalidating a VC's leaf nodes.........................  26
        5.1.5.1 When leaf node drops itself........................  27
        5.1.5.2 When a jump is detected in the CSN.................  27
      5.1.6 'Migrating' the outgoing multipoint VC.................  27
    5.2. Receive side behaviour....................................  29
      5.2.1 Format of the MARS_JOIN and MARS_LEAVE Messages........  30
        5.2.1.1 Important IPv4 default values......................  32
      5.2.2 Retransmission of MARS_JOIN and MARS_LEAVE messages....  33
      5.2.3 Cluster member registration and deregistration.........  34
    5.3 Support for Layer 3 group management.......................  34
    5.4 Support for redundant/backup MARS entities.................  36
      5.4.1 First response to MARS problems........................  36
      5.4.2 Connecting to a backup MARS............................  37
      5.4.3 Dynamic backup lists, and soft redirects...............  37
    5.5 Data path LLC/SNAP encapsulations..........................  40
      5.5.1 Type #1 encapsulation..................................  40
      5.5.2 Type #2 encapsulation..................................  41



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


      5.5.3 A Type #1 example......................................  42
   6. The MARS in greater detail...................................  42
    6.1 Basic interface to Cluster members.........................  43
      6.1.1 Response to MARS_REQUEST...............................  43
      6.1.2 Response to MARS_JOIN and MARS_LEAVE...................  43
      6.1.3 Generating MARS_REDIRECT_MAP...........................  45
      6.1.4 Cluster Sequence Numbers...............................  45
    6.2 MARS interface to Multicast Servers (MCSs).................  46
      6.2.1 MARS_REQUESTs for MCS supported groups.................  47
      6.2.2 MARS_MSERV and MARS_UNSERV messages....................  47
      6.2.3 Registering a Multicast Server (MCS)...................  49
      6.2.4 Modified response to MARS_JOIN and MARS_LEAVE..........  49
      6.2.5 Sequence numbers for ServerControlVC traffic...........  51
    6.3 Why global sequence numbers?...............................  52
    6.4 Redundant/Backup MARS Architectures........................  52
   7. How an MCS utilises a MARS...................................  53
    7.1 Association with a particular Layer 3 group................  53
    7.2 Termination of incoming VCs................................  54
    7.3 Management of outgoing VC..................................  54
    7.4 Use of a backup MARS.......................................  54
   8. Support for IP multicast routers.............................  54
    8.1 Forwarding into a Cluster..................................  55
    8.2 Joining in 'promiscuous' mode..............................  55
    8.3 Forwarding across the cluster..............................  56
    8.4 Joining in 'semi-promiscous' mode..........................  56
    8.5 An alternative to IGMP Queries.............................  57
    8.6 CMIs across multiple interfaces............................  58
   9. Multiprotocol applications of the MARS and MARS clients......  59
   10. Supplementary parameter processing..........................  60
    10.1 Interpreting the mar$extoff field.........................  60
    10.2 The format of TLVs........................................  60
    10.3 Processing MARS messages with TLVs........................  62
    10.4 Initial set of TLV elements...............................  62
   11. Key Decisions and open issues...............................  62
   Security Considerations.........................................  65
   Acknowledgments.................................................  65
   Author's Address................................................  65
   References......................................................  66
   Appendix A. Hole punching algorithms............................  67
   Appendix B. Minimising the impact of IGMP in IPv4 environments..  69
   Appendix C. Further comments on 'Clusters'......................  71
   Appendix D. TLV list parsing algorithm..........................  72
   Appendix E. Summary of timer values.............................  73
   Appendix F. Pseudo code for MARS operation......................  74







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


1.  Introduction.

   Multicasting is the process whereby a source host or protocol entity
   sends a packet to multiple destinations simultaneously using a
   single, local 'transmit' operation. The more familiar cases of
   Unicasting and Broadcasting may be considered to be special cases of
   Multicasting (with the packet delivered to one destination, or 'all'
   destinations, respectively).

   Most network layer models, like the one described in RFC 1112 [1] for
   IP multicasting, assume sources may send their packets to abstract
   'multicast group addresses'.  Link layer support for such an
   abstraction is assumed to exist, and is provided by technologies such
   as Ethernet.

   ATM is being utilized as a new link layer technology to support a
   variety of protocols, including IP. With RFC 1483 [2] the IETF
   defined a multiprotocol mechanism for encapsulating and transmitting
   packets using AAL5 over ATM Virtual Channels (VCs). However, the ATM
   Forum's currently published signalling specifications (UNI 3.0 [8]
   and UNI 3.1 [4]) does not provide the multicast address abstraction.
   Unicast connections are supported by point to point, bidirectional
   VCs. Multicasting is supported through point to multipoint
   unidirectional VCs. The key limitation is that the sender must have
   prior knowledge of each intended recipient, and explicitly establish
   a VC with itself as the root node and the recipients as the leaf
   nodes.

   This document has two broad goals:

      Define a group address registration and membership distribution
      mechanism that allows UNI 3.0/3.1 based networks to support the
      multicast service of protocols such as IP.

      Define specific endpoint behaviours for managing point to
      multipoint VCs to achieve multicasting of layer 3 packets.

   As the IETF is currently in the forefront of using wide area
   multicasting this document's descriptions will often focus on IP
   service model of RFC 1112.  A final chapter will note the
   multiprotocol application of the architecture.

   This document avoids discussion of one highly non-trivial aspect of
   using ATM - the specification of QoS for VCs being established in
   response to higher layer needs. Research in this area is still very
   formative [7], and so it is assumed that future documents will
   clarify the mapping of QoS requirements to VC establishment. The
   default at this time is that VCs are established with a request for



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


   Unspecified Bit Rate (UBR) service, as typified by the IETF's use of
   VCs for unicast IP, described in RFC 1755 [6].

1.1  The Multicast Address Resolution Server (MARS).

   The Multicast Address Resolution Server (MARS) is an extended analog
   of the ATM ARP Server introduced in RFC 1577 [3].  It acts as a
   registry, associating layer 3 multicast group identifiers with the
   ATM interfaces representing the group's members.  MARS messages
   support the distribution of multicast group membership information
   between MARS and endpoints (hosts or routers).  Endpoint address
   resolution entities query the MARS when a layer 3 address needs to be
   resolved to the set of ATM endpoints making up the group at any one
   time. Endpoints keep the MARS informed when they need to join or
   leave particular layer 3 groups.  To provide for asynchronous
   notification of group membership changes the MARS manages a point to
   multipoint VC out to all endpoints desiring multicast support

   Valid arguments can be made for two different approaches to ATM level
   multicasting of layer 3 packets - through meshes of point to
   multipoint VCs, or ATM level multicast servers (MCS). The MARS
   architecture allows either VC meshes or MCSs to be used on a per-
   group basis.

1.2  The ATM level multicast Cluster.

   Each MARS manages a 'cluster' of ATM-attached endpoints. A Cluster is
   defined as

      The set of ATM interfaces choosing to participate in direct ATM
      connections to achieve multicasting of AAL_SDUs between
      themselves.

   In practice, a Cluster is the set of endpoints that choose to use the
   same MARS to register their memberships and receive their updates
   from.

   By implication of this definition, traffic between interfaces
   belonging to different Clusters passes through an inter-cluster
   device. (In the IP world an inter-cluster device would be an IP
   multicast router with logical interfaces into each Cluster.) This
   document explicitly avoids specifying the nature of inter-cluster
   (layer 3) routing protocols.

   The mapping of clusters to other constrained sets of endpoints (such
   as unicast Logical IP Subnets) is left to each network administrator.
   However, for the purposes of conformance with this document network
   administrators MUST ensure that each Logical IP Subnet (LIS) is



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


   served by a separate MARS, creating a one-to-one mapping between
   cluster and unicast LIS.  IP multicast routers then interconnect each
   LIS as they do with conventional subnets. (Relaxation of this
   restriction MAY only occur after future research on the interaction
   between existing layer 3 multicast routing protocols and unicast
   subnet boundaries.)

   The term 'Cluster Member' will be used in this document to refer to
   an endpoint that is currently using a MARS for multicast support.
   Thus potential scope of a cluster may be the entire membership of a