rfc966.txt

RFC 相关的技术文档

   elegant way of implementing existing Internet applications.

   We are currently implementing a prototype host group facility as an
   extension of IP.  For practical reasons, this prototype implements
   all group management functions and multicast routing outside of the
   Internet gateways, in special hosts called multicast agents, which
   are similar to the broadcast repeaters of Lebowitz and Mankins.  The
   collection of multicast agents in effect provides a second gateway
   system on top of the existing Internet, for multicast purposes.  The
   major costs of this separation are redundancy of routing tables
   between gateways and multicast agents and the increased delay and
   unreliability of extra hops in the delivery path.  Much of the
   routing information in the multicast agents must be "wired-in"
   because they do not have access to the gateways' routing tables.
   However, this rudimentary implementation provides an environment for
   evaluating the interface to the multicast service and for
   investigating group management and multicast routing protocols for
   eventual use in the gateways.  It also serves as a testbed for
   porting multicast-based distributed applications to the Internet.

   For now, we are restricting group membership to local networks that
   already have a broadcast or multicast capability, such as the


Deering & Cheriton                                             [Page 14]



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


   Ethernet. We feel that, in the future, any network that is to support
   hosts other than just gateways must have a multicast addressing mode.
   Efficient implementation of multicast within point-to-point or
   virtual circuit networks deserves investigation.

   A significant issue raised by the host group model is authentication
   and access control in the Internet.  Gateways must control which
   hosts can create and join host groups, presumably making their
   decision based on the identity of the requestor (thus requiring
   authentication) and permissions (access control lists).  This issue
   does not arise in conventional internetwork architectures because
   host addresses are administratively assigned with no notion of
   dynamic assignment and binding as provided by host groups.  We
   believe that access control should be recognized as a proper and
   necessary function of gateways so as to protect the hosts of local
   networks from general internetwork activity.  Thus, group access
   control can be subsumed as part of this more general mechanism,
   although more investigation of the general issue is called for.

   On a philosophical point, there has been considerable reluctance to
   make open use of multicast on local networks because it was
   network-specific and not provided across the Internet.  We were
   originally of that school.  However, we recognized that our "hidden"
   uses of multicast in the V distributed system were essential unless
   we resorted to dramatically poorer solutions - wired-in addresses.
   We also recognized, as described in this paper, that an adequate
   multicast facility for the Internet was feasible.  As a consequence,
   we now argue that multicast is an important and basic facility to
   provide in local networks and internetworks.  Higher levels of
   communication, including applications, should feel free to make use
   of this powerful facility. Networks and internetworks lacking
   multicast should be regarded as deficient relative to the future (and
   present) requirements of sophisticated distributed applications and
   communication systems.















Deering & Cheriton                                             [Page 15]



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


Appendix I. Internet Group Management Protocol (IGMP)

   The Internet Group Management Protocol (IGMP) is used between IP
   hosts and their immediate neighbour multicast agents to support the
   allocation of temporary group addresses and the addition and deletion
   of members of a group.

   Like ICMP, IGMP is a required part of all IP implementations.  IGMP
   messages are encapsulated in IP datagrams, with an IP protocol number
   of 2.  IGMP messages are formatted similarly to ICMP messages and the
   different IGMP message types are given values distinct from ICMP
   message types, so that both protocols may share common implementation
   modules or, perhaps, be merged into a single protocol.

   IGMP interactions take the form of request-response transactions.  A
   request message is sent by hosts to the permanent group of all
   immediate neighbour multicast agents.  Multicast agents reply to the
   IP source address of a request.  If no reply is received within a
   (currently unspecified) timeout interval, a host retransmits its
   request, up to some (currently unspecified) maximum number of times.
   IGMP transactions are considered idempotent, so that multicast agents
   need not recognize and filter out duplicate requests nor buffer
   replies <4>.

   The IGMP message formats and procedures are defined below, in the
   style used in the ICMP specification.























Deering & Cheriton                                             [Page 16]



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


   Create Group Request or Create 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                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         Access Key                            +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IP Fields:

      Addresses

         A Create 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 Create Group Reply is sent with those two
         addresses reversed.

      IGMP Fields:

      Type

         101 for Create Group Request
         102 for Create Group Reply

      Code

         For a Create Group Request message, the Code field indicates if
         the group is to be restricted:

            0 = unrestricted
            1 = restricted

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

            0 = request approved
            1 = request denied, no resources


Deering & Cheriton                                             [Page 17]



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


      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.

      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 Create Group Request message, a value of 0.

         For a Create Group Reply message, either a newly allocated
         group address (if the request is approved) or a value of 0 (if
         denied).

      Access Key

         For a Create Group Request message, a value of 0.

         For a Create Group Reply message, either a pseudo-random 64-bit
         number (if the request for a restricted group is approved) or
         0.

      Description

         A Create Group Request message is sent to the the group of
         local multicast agents by a host wishing to allocate a new
         temporary 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
         lack of resources (e.g. no table space in gateways or all
         temporary addresses in use).



Deering & Cheriton                                             [Page 18]



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


         If the request is approved, the requesting host is considered
         to be the first and only current member of the new host group.

         The Identifier and Sequence Number fields are used to match the
         Reply to the corresponding Request.  The multicast agents may
         choose to use these values to minimize the chance of allocating
         more than one new group for a single request, for example when
         a Reply is lost and a

         Request is retransmitted.  However, the multicast agents must
         be prepared to recover temporary group addresses without
         requiring explicit Leave Group Requests from all members; they
         may choose simply to allocate a new address for every
         retransmission and recover unused ones when needed <5>.



































Deering & Cheriton                                             [Page 19]



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


   Join Group Request or Join 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                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         Access Key                            +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IP Fields:

      Addresses

         A Join 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 Join Group Reply is sent with those two
         addresses reversed.

      IGMP Fields:

      Type

         103 for Join Group Request
         104 for Join Group Reply

      Code

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

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

            0 = request approved
            1 = request denied, no resources
            2 = request denied, invalid group address
            3 = request denied, invalid access key




Deering & Cheriton                                             [Page 20]



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


      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.

      Identifier

         An identifier to aid in matching Request and Reply messages.