rfc1458.txt

RFC 的详细文档！

   XTP is also similar to IP/Multicast as there is no explicit set-up
   processing between the sender and the receivers prior to the
   establishment of group communications.  While there is implicit
   processing in key management, an external mechanism is required for
   passing the multicast group address to the receivers.  The receivers
   must have established "filters" for the address prior to transmission
   in order to receive the data, and suffers the same problems as
   IP/Multicast.

   In contrast to IP/Multicast, XTP does require explicit handshaking



Braudes & Zabele                                                [Page 5]

RFC 1458          Requirements for Multicast Protocols          May 1993


   between the sender and receivers that wish to join an existing group;
   however, there is no parallel communication for receivers dropping
   out of groups, and the only mechanism for a sender to know if there
   are any receivers is the polling scheme used for error control and
   recovery.  This causes the same problems with sending traffic to
   groups without members discussed under IP/Multicast.

   The XTP specification does not address how routers distribute a
   multicast stream among different connected networks; however it does
   include a discussion of the optional bucket, damping, slotting, and
   cloning algorithms to reduce duplicate multicast traffic within a
   local network.

   The specification allows the user to determine whether multicast
   transfers are unreliable or semi-reliable, where semi-reliable
   transfers are defined to provide a "high-probability of success [9]"
   of delivery to all receivers.  Reliability cannot be guaranteed due
   to the fact that XTP does not maintain the cardinality of the
   receiver set, and so cannot know that the data has been received by
   all hosts.

   XTP recovers from errors using a go-back-n approach (assuming that
   the bucket algorithm has been implemented) by retransmitting dropped
   packets to all members of the multicast group, as group members are
   unknown.  This has the potential of flooding the network if only a
   single receiver dropped a packet. If all dropped packets belong to a
   single network on an internet, with traffic generated over the entire
   connected network.

3.3 ST-II

   ST-II is another network protocol that provides support for multicast
   communications.  Similar to IP/Multicast and XTP, ST-II requires a
   separate application-specific protocol for assigning and
   communicating multicast group addresses.

   While ST-II is a network level protocol, it guarantees end-to-end
   bandwidth and delay, and so obviates the need for many of the
   functions of a transport protocol.  The guarantee is provided by
   requiring bandwidth reservations for all connections, which are made
   at set-up time, and ensuring that the requested bandwidth is
   available throughout the lifetime of the connection.  The enforcement
   policy ensures that the same path is followed for all transmissions,
   and prohibits new connections over the network unless there is
   sufficient bandwidth to accommodate the expected traffic.  This is
   accomplished by maintaining the state of all connections in the
   network routers, trading the overhead of this connection set-up for
   the performance guarantees.



Braudes & Zabele                                                [Page 6]

RFC 1458          Requirements for Multicast Protocols          May 1993


   Connection set-up involves negotiation of the bandwidth and delay
   parameters and path between the sender, intermediate routers, and
   receivers. If the requested resources cannot be made available, the
   sender is given the option of either accepting what is available or
   canceling the connection request.

   To add a new user to an existing group, the new receiver must first
   communicate directly with the sender using a different protocol to
   exchange relevant information such as the group address.  The sender
   then requests ST-II to add the new receiver, with the basic
   connection set-up processing invoked as before with the new
   connection completed only if there is sufficient bandwidth to process
   the user.

   While the resource guarantee system imposed by ST-II tries to prevent
   network congestion from occurring, there are situations where
   priority traffic must be introduced into the network.  ST-II makes
   this very expensive, as the resource requirements for existing
   connections must be adjusted, which can only be accomplished by the
   origin of each stream.  This must be completed prior to the
   connection set-up for the priority stream, introducing a large delay
   before the important data can be transmitted.

   ST-II connections can be closed by either the sender or the receiver.
   When the last receiver along a path has been removed, the resources
   allocated over that path are released.  When all receivers have been
   removed, the sender in informed and has the option of either adding a
   new receiver or tearing down the group.

3.4 MTP

   MTP is a transport level protocol designed to support efficient,
   reliable multicast transmissions on top of existing network protocols
   such as IP/Multicast.  It is based on the notion of a multicast
   "master" which controls all aspects of group communications.

   Allocation of a specific group address, or network service access
   point, is not considered part of MTP, and as with the other multicast
   protocols requires the use of an outside addressing authority.  The
   MTP specification does require the master to make a "robust effort
   [2]" to ensure the address selected is not already in use by trying
   to join an existing group at that address, but the problems described
   above remain.

   Once the address is established, receivers issue a request to join
   the existing group using a unique connection identifier that is pre-
   assigned.  The MTP specification addresses neither how the identifier
   is allocated nor how the receivers learn its value, but is assumed to



Braudes & Zabele                                                [Page 7]

RFC 1458          Requirements for Multicast Protocols          May 1993


   be handled through an external protocol.  The join request specifies
   whether the receiver wishes to be a producer of information or only a
   receiver, whether the connection should be reliable or best effort,
   whether the receiver is able to accept multiple senders of
   information, the minimum throughput desired, and the maximum data
   packet size.  If the request can be granted, then the master replies
   with an ACK with a multicast connection identifier; otherwise a NAK
   is returned.

   Dropping membership in a group is coordinated through the master.
   The specification does not address what action the master should take
   when the group is reduced to a single member, but a logical action
   would be to stop distributing transmit tokens if there are no active
   receivers.

   One of the major features in MTP is the ordering of received data.
   The master distributes transmit tokens to data producers in the
   group, which allow data to be provided at a specified rate.  Rate
   control provides flow control within the protocol, with members that
   cannot maintain a minimum flow requested to leave the group.

   Error recovery utilizes a NAK-based selective retransmission scheme.
   Senders are required to maintain data for a time period specified by
   the master, and to be able to retransmit this data when requested by
   members of the group.  These retransmissions are multicast to the
   entire group, requiring receivers to be able to cope with duplicate
   packets.  If a retransmission request arrives after the data has been
   released, the sender must NAK the request.

   A potential problem with MTP is the significant amount of overhead
   associated with the protocol, with virtually all control traffic
   flowing through the master.  The extra delay and congestion makes MTP
   inappropriate for the image dissemination applications.

3.5 Summary

   Our analysis has determined that there are significant problems with
   all of the major multicast protocols for the reliable, adaptive
   multicast transport of large data items.  The problems include
   inadequate address management, excessive processing of control
   information, poor response to network congestion, inability to handle
   high priority traffic, and suboptimal error recovery and
   retransmission procedures.  We have developed a high-level notion of
   the requirements for a service that addresses these issues, which we
   now discuss.






Braudes & Zabele                                                [Page 8]

RFC 1458          Requirements for Multicast Protocols          May 1993


4.  Protocol Suite for Reliable, Adaptive Multicast

   We present an integrated set of three basic components required to
   provide a reliable multicast service: the Multicast Group Authority
   (MGA); the Reliable, Adaptive Multicast Protocol (RAMP); and modified
   routing algorithms.  These components are designed to be compatible
   with, and take full advantage of, reservation systems such as RSVP
   [12].

   In this discussion, we have broadened the definition of the term
   "Quality of Service (QOS)."  There are many applications where the
   information content of the underlying data can be reduced through
   data compression techniques.  For example, a 1,024 x 1,024 pixel
   image can be sub-sampled down to 512 x 512 pixels.  This degradation
   results in a lower quality of service for the end user, while
   reducing the traditional network QOS requirements for the transfer.

4.1 The Multicast Group Authority

   The Multicast Group Authority (MGA) provides services related to
   managing the multicast address space and high-level management
   support to existing multicast groups.  The MGA has three primary
   responsibilities: address management, service registration, and group
   membership maintenance.

   The MGA is hierarchical in nature, similar to the Internet Domain
   Name System (DNS) [7].  Requests for service are directed to an MGA
   agent on the local workstation, which are propagated upwards as
   required.

4.1.1 Address Management

   The MGA is responsible for the allocation and deallocation of
   addresses within the Internet Class D address space.  Address
   requests received from application processes or other MGA nodes
   result in a block of addresses being assigned to the requesting MGA
   node.  The size of the address block allocated is dependent on the
   position of the requester in the MGA hierarchy, to reduce the number
   of address requests propagated through the MGA tree.

   Figure 1 can be used to show what happens when an application
   requests a multicast address from the authority at node 1.1.1.
   Assuming that this is the first request from this branch of the MGA,
   node 1.1.1 issues a request to its parent, node 1.1, which propagates
   the request to node 1.  Node 1 passes this request to the root, which
   issues a block of, say, 30 class D addresses.  Of these 30, 10 are
   returned to node 1.1, with the remaining 20 reserved for requests
   from node 1's other children. Similarly, node 1.1 passes 3 addresses



Braudes & Zabele                                                [Page 9]

RFC 1458          Requirements for Multicast Protocols          May 1993


   to node 1.1.1, reserving the other 7 for future requests.  Finally,
   node 1.1.1 answers the applications request for an address, keeping
   the remaining 2 addresses for future use.

                         --------
                         | root |
                         --------
                          /  |  \
                         /   |   \
                  --------       --------
                  |   1  |  ...  |   n  |
                  --------       --------
                   /  |  \
                  /   |   \
           --------       --------
           |  1.1 |  ...  |  1.n |
           --------       --------
            /  |  \
           /   |   \
        --------       --------
        |1.1.1 |  ...  |1.1.n |
        --------       --------

                    Figure 1.  Sample MGA Hierarchy