rfc988.txt

RFC 相关的技术文档

         2       = request denied,  invalid code
         3       = request denied,  invalid group address
         4       = request denied,  invalid access key
         5 - 255 = request pending, retry in this many seconds

   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.

   Identifier

      In a Confirm Group Request message, the identifier field contains
      zero.

      In all other Request messages, the identifier field contains a
      value to distinguish the request from other requests by the same
      host.

      In a Reply message, the identifier field contains the same value
      as in the corresponding Request message.












Deering                                                        [Page 14]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


   Group Address

      In a Create Group Request message, the group address field
      contains zero.

      In all other Request messages, the group address field contains a
      host group address.

      In a Create Group Reply message, the group address field contains
      either a newly allocated host group address (if the request is
      granted) or zero (if denied).

      In all other Reply messages, the group address field contains the
      same host group address as in the corresponding Request message.

   Access Key

      In a Create Group Request message, the access key field contains
      zero.

      In all other Request messages, the access key field contains the
      access key assigned to the host group identified in the Group
      Address field (zero for public groups).

      In a Create Group Reply message, the access key field contains
      either a non-zero 64-bit number (if the request for a private
      group is granted) or zero.

      In all other Reply messages, the access key field contains the
      same access key as in the corresponding Request.



















Deering                                                        [Page 15]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


   Protocol Rules

      Request messages are sent only by hosts.  Reply messages are sent
      only by multicast agents.  If a host receives an IGMP message of a
      type other than the four Reply types specified above, the message
      is discarded.

      A Request message is sent with its IP destination field containing
      the well-known address of the Multicast Agent Group.  The IP
      time-to-live field is initialized by the sender to 1, in order to
      limit the scope of the request to immediate neighbor multicast
      agents only.  The IP source address field contains the individual
      IP address of the sending host.

      A Reply message is sent only in response to a Request message.
      Its IP destination address field contains the individual address
      of the host that sent the corresponding Request.  (A Confirm Group
      Reply may also be sent to the host group address specified in its
      corresponding Confirm Group Request.)  The IP source address field
      contains the individual IP address of the replying multicast
      agent.

      When a host sends a new Create Group, Join Group, or Leave Group
      Request message, it supplies an arbitrary identifier that it has
      not used within the last T0 seconds.  (It is usually sufficient
      just to increment the identifier for each new request.)  The host
      initializes a timer to T1 seconds and a retransmission counter to
      zero.  If a Reply message with a matching identifier is not
      received before the timer expires, it is reset to T1 seconds and
      the retransmission counter is incremented.  If the counter is less
      than N1, the host retransmits the Request message with the same
      identifier.  If the counter equals N1, the host gives up; if the
      request was to create or join a group, it is deemed to have
      failed; if the request was to leave a group, it is deemed to have
      succeeded.

      If a "request pending" code is received in a matching reply to a
      Create Group, Join Group, or Leave Group Request, the timer is
      reset to the number of seconds specified by the code and the
      retransmission counter is reset to zero.  The new timer value
      applies to one timeout interval only -- if the timer expires, it
      is reset to T1 seconds, the counter is incremented, and the
      request is retransmitted.

      The first matching Reply to a Create Group, Join Group, or Leave
      Group Request containing a "request granted" or "request denied"
      code determines the outcome of the request.  Any subsequent or


Deering                                                        [Page 16]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


      non-matching Replies are discarded by the host.  However, if a
      host receives an affirmative Create Group Reply or Join Group
      Reply that neither matches an outstanding Request nor contains the
      address of a group to which the host belongs, the host should
      immediately send a Leave Group Request for the unexpected group
      address.

      A "request granted" reply to a Create Group Request implies that,
      as well as the group being created, the requesting host is granted
      membership in the group, i.e. there is no need to send a separate
      Join Group Request.

      Confirm Group Request messages must be sent periodically by hosts
      to inform the neighboring multicast agent(s) of the hosts'
      continuing membership in the specified groups.  If an agent does
      not receive a Confirm Group Request message for a particular group
      within an agent-defined interval, it stops delivering datagrams
      destined to that group.

      For each group to which it belongs, a host maintains a
      confirmation timer and a variable t.  The variable t is
      initialized to T2 seconds. Whenever the host's request to create
      or join a group is granted, and whenever the host either sends a
      Confirm Group Request or receives a Confirm Group Reply with a
      "request granted" code for the group, the host sets the group's
      timer to a random number uniformly distributed between t and t +
      T3 seconds.  If the host receives a a Confirm Group Reply with a
      "request pending" code, t is changed to the value of the code and
      the timer is reset to a random number between the new t and t +
      T3.  The variable t retains its value until another "request
      pending" code is received.  Whenever the timer expires, the host
      sends a Confirm Group Request.

      Even if a host fails to receive Confirm Group Replies to its
      Requests, it continues to consider itself a member of the group,
      because it may still be able to receive multicast datagrams from
      other hosts on the same local network.  Only if a host receives a
      "request denied" code in a Confirm Group Reply does it stop
      sending Confirm Group Requests and consider its membership to be
      revoked.

      Multicast agents respond to Confirm Group Request messages by
      sending Confirm Group Reply messages either to the individual
      sender of the Request or to the host group address specified in
      the Request.  By sending back a Confirm Group Reply to all
      neighboring members of a group, a multicast agent is able to reset
      every member's timer with a single packet.  The randomization of


Deering                                                        [Page 17]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


      the timers is intended to cause only the one member whose timer
      expires first to send a Confirm Group Request, stimulating a Reply
      to reset all the timers.  The use of the "request pending" codes
      allows the multicast agent to control the rate at which it
      receives Confirm Group Requests.

   Protocol Timing Constants

      The following timing constants are specified for IGMP.  They are
      subject to change as a result of operational experience.

      T0 = 300 seconds  minimum recycle time for identifiers

      T1 = 2 seconds    retrans. interval for Create/Join/Leave Requests

      N1 = 5 tries      retrans. limit for Create/Join/Leave Requests

      T2 = 15 seconds   initial value for Confirm Request variable t

      T3 = 15 seconds   random range for Confirm Request variable t





























Deering                                                        [Page 18]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


APPENDIX II.  HOST GROUP ADDRESS ISSUES

   This appendix is not part of the IP multicasting specification, but
   provides background discussion of several issues related to IP host
   group addresses.

   Group Address Binding

      The binding of IP host group addresses to physical hosts may be
      considered a generalization of the binding of IP unicast
      addresses.  An IP unicast address is statically bound to a single
      local network interface on a single IP network.  An IP host group
      address is dynamically bound to a set of local network interfaces
      on a set of IP networks.

      It is important to understand that an IP host group address is NOT
      bound to a set of IP unicast addresses.  The multicast agents do
      not need to maintain a list of individual members of each host
      group.  For example, a multicast agent attached to an Ethernet
      need associate only a single Ethernet multicast address with each
      host group having local members, rather than a list of the
      members' individual IP or Ethernet addresses.

   Group Addresses as Logical Addresses

      Host group addresses have been defined specifically for use in the
      destination address field of multicast IP datagrams.  However, the
      fact that group addresses are location-independent (they are not
      statically bound to a single network interface) suggests possible
      uses as more general "logical addresses", both in the source as
      well as the destination address field of datagrams.  For example,
      a mobile IP host might have a host group address as its only
      identity, used as the source of datagrams it sends.  Whenever the
      mobile host moved from one network to another, it would join its
      own group on the new network and depart from the group on the old
      network.  Other hosts communicating with the mobile one would deal
      only with the group address and would be unaware of, and
      unaffected by, the changing network location of the mobile host.

      Host group addresses cannot, however, be used to solve all
      problems of internetwork logical addressing, such as delivery to
      the "nearest" or the "least loaded" network interface of a
      multi-homed host. Furthermore, there are hazards in using group
      addresses in the source address field of datagrams when the group
      actually contains more than one host.  For instance, the IP
      datagram reassembly algorithm relies on every host using a
      different source address.  Also, errors in a datagram sent with a


Deering                                                        [Page 19]



RFC 988                                                        July 1986
Host Extensions for IP Multicasting


      group source address may result in error reports being returned to
      all members of the group, not just the sender.  In view of these
      hazards, this memo specifies the use of host group addresses only
      as destinations of datagrams, either in the destination address
      field or as the last element of a source routing option.  However,
      it is recommended that datagrams with a group source address be
      accepted without complaint, thereby allowing other implementations
      to experiment with logical addressing applications of host group
      addresses.

   Recycling of Transient Host Group Addresses

      Since host group addresses are of fixed, relatively small size,
      transient group addresses must be recycled to satisfy continuing
      requests for creation of new groups.  The multicast agents make an
      effort to ensure that a group has no members anywhere in the
      internet before allocating its address to a new group.  However,
      under certain conditions of internetwork partitioning and
      membership migration, it is impossible to guarantee unique
      allocation of an address without seriously compromising the
      availability and robustness of host groups. Furthermore, hosts
      that are unaware that a particular group has ceased to exist may
      send datagrams to it long after its address has been assigned to a
      new group.  Therefore, hosts should be prepared for the
      possibility of misdelivery of multicast IP datagrams to unintended
      hosts, even in private groups.  Such misdelivery can only be
      detected at a level above IP, using higher-level identifiers or
      authentication tokens.  (The access key of a private group might
      be used in some applications as such an identifier.)  Of course,
      there are other threats to privacy of communication in the
      internet, besides group address collision, such as untrustworthy
      gateways or unsecured networks. End-to-end encryption is an
      effective defense against such threats.
















Deering                                                        [Page 20]