rfc966.txt

RFC 的详细文档！

      Sequence Number

         A sequence number to aid in matching Request and Reply
         messages.

      Group Address

         For a Join Group Request message, a host group address.

         For a Join Group Reply message, the same group address as in
         the corresponding request.

      Access Key

         For a Join Group Request message, the access key allocated when
         the group was created (0 for unrestricted groups).

         For a Join Group Reply message, the same access key as in the
         corresponding request.

      Description

         A Join Group Request message is sent to the the group of local
         multicast agents by a host wishing to join a specified,
         existing group.  If no Reply message is received within t
         seconds, the Request is retransmitted.  If no reply is received
         after n transmissions, the request is deemed to have failed.

         The first Reply message to arrive, if any, specifies the
         outcome of the request.  The request may be denied because of
         an invalid access key, an invalid specified group address (e.g.
         non-existent group) or lack of resources (e.g. no table space
         in gateways).

         The Identifier and Sequence Number fields are used to match the
         Reply to the corresponding Request.  If a multicast agent


Deering & Cheriton                                             [Page 21]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


         receives a request from a host to join a group to which it
         already belongs, the agent approves the request, under the
         assumption that the request was a retransmission for a lost
         Reply.













































Deering & Cheriton                                             [Page 22]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


   Leave Group Request or Leave Group Reply Message

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Group Address                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IP Fields:

      Addresses

         A Leave Group Request message is sent with an individual IP
         address of the sending host as its source, and the well-known
         group address of the multicast agents as its destination.

         The corresponding Leave Group Reply is sent with those two
         addresses reversed.

      IGMP Fields:

      Type

         105 for Leave Group Request
         106 for Leave Group Reply

      Code

         For a Leave Group Request message, the Code field contains 0.

         For  Leave Group Reply message, the Code field specifies the
         outcome of the request:

            0 = request approved
            2 = request denied, invalid group address

      Checksum

         The checksum is the 16-bit one's complement of the one's
         complement sum of the IGMP message starting with the IGMP Type.
         For computing the checksum, the checksum field should be zero.
         This checksum may be replaced in the future.



Deering & Cheriton                                             [Page 23]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


      Identifier

         An identifier to aid in matching Request and Reply messages.

      Sequence Number

         A sequence number to aid in matching Request and Reply
         messages.

      Group Address

         For a Leave Group Request message, a host group address.

         For a Leave Group Reply message, the same group address as in
         the corresponding request.

      Description

         A Leave Group Request message is sent to the the group of local
         multicast agents by a host wishing to leave a specified,
         existing group.  If no Reply message is received within t
         seconds, the Request is retransmitted.  If no reply is received
         after n transmissions, the request is deemed to have succeeded.

         The first Reply message to arrive, if any, specifies the
         outcome of the request.  The request may be denied only if the
         specified group address is invalid (e.g. an individual rather
         than a group address.)

         The Identifier and Sequence Number fields are used to match the
         Reply to the corresponding Request, as with other ICMP
         transactions. If a multicast agent receives a request from a
         host to leave a group to which it does not belong, the agent
         approves the request, under the assumption that the request was
         a retransmission for a lost Reply.














Deering & Cheriton                                             [Page 24]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


Notes:

   <1>  In reality, Internet addresses (individual or group) are bound
        to network interfaces or network attachment points, not the host
        machines per se.

   <2>  In this procedure call notation, the arguments for an operation
        are listed in parentheses after the operation name, and the
        returned values, if any, are listed after a --> symbol.

   <3>  One unicast transmission from sender to gateway and one
        multicast transmission from gateway to local group members

   <4>  This protocol may eventually be replaced by a more general
        reliable transaction protocol designed for this type of
        client/server interaction, as suggested in RFC-955 [5].

   <5>  Multicast agents can use an ICMP Echo message to determine if a
        group has any current members.  The Echo message should be
        transmitted several times before deciding the group address is
        no longer in use.




























Deering & Cheriton                                             [Page 25]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


References

   [1]   L. Aguilar. Datagram Routing for Internet Multicasting. In ACM
         SIGCOMM '84 Communications Architectures and Protocols, pages
         58-63. ACM, June, 1984.

   [2]   E. J. Berglund and D. R. Cheriton. Amaze: A distributed
         multi-player game program using the distributed V kernel. In
         Proceedings of the Fourth International Conference on
         Distributed Systems. IEEE, May, 1984.

   [3]   A. D. Birrell et al. Grapevine: an exercise in distributed
         computing. Communications of the ACM 25(4):260-274, April,
         1982.

   [4]   D. R. Boggs. Internet Broadcasting. PhD thesis, Stanford
         University, January, 1982.

   [5]   R. Braden. Towards a Transport Service for Transaction
         Processing Applications. Technical Report RFC-919, SRI Network
         Information Center, September, 1985.

   [6]   J-M. Chang. Simplifying Distributed Database Design by Using a
         Broadcast Network. In SIGMOD '84. ACM, June, 1984.

   [7]   D. R. Cheriton and S. E. Deering. Host Groups: A Multicast
         Extension for Datagram Internetworks. In Proceedings of the
         Ninth Data Communications Symposium. ACM/IEEE, September, 1985.

   [8]   D. R. Cheriton and W. Zwaenepoel. Distributed Process Groups in
         the V Kernel. ACM Transactions on Computer Systems 3(3), May,
         1985.

   [9]   F. Cristian et al. Atomic Broadcast: from simple message
         diffusion to Byzantine agreement. In 15th International
         Conference on Fault Tolerant Computing. , Ann Arbor, Michigan,
         June, 1985.

   [10]  Y. K. Dalal and R. M. Metcalfe. Reverse Path Forwarding of
         Broadcast Packets. Communications of the ACM 21(2):1040-1047,
         December, 1978.

   [11]  H. Forsdick. MMCF: A Multi-Media Conferencing Facility.
         personal communication.





Deering & Cheriton                                             [Page 26]



RFC 966                                                    December 1985
Host Groups: A Multicast Extension to the Internet Protocol


   [12]  K. Lebowitz and D. Mankins. Multi-network Broadcasting within
         the Internet.Technical Report RFC-947, SRI Network Information
         Center, June, 1985.

   [13]  J. Mogul. Broadcasting Internet Datagrams. Technical Report
         RFC-919, SRI Network Information Center, October, 1984.

   [14]  J. Postel. Internet Protocol. Technical Report RFC-791, SRI
         Network Information Center, September, 1981.

   [15]  J. Postel. Internet Control Message Protocol. Technical Report
         RFC-792, SRI Network Information Center, September, 1981.

   [16]  D. W, Wall. Mechanisms for Broadcast and Selective Broadcast.
         Technical Report 190, Computer Systems Laboratory, Stanford
         University, June, 1980.

   [17]  J. K. Reynolds and J. Postel. Assigned Numbers. Technical
         Report RFC-960, SRI Network Information Center, September,
         1981.





























Deering & Cheriton                                             [Page 27]