rfc1458.txt

RFC 的详细文档！

   When the root exhausts the address space, a request is made to the
   children for reclamation of unused addresses.  This request
   propagates down the tree, with unused addresses passed back through
   the hierarchy and returned to the address pool.  If the entire
   address space is in use, then requests for additional addresses are
   not honored.

   When an application no longer requires an address, it is returned to
   the local MGA node, which keeps it until either it is requested by
   another application, it is requested by its parent, or the node is
   terminated.  At node termination, all available addresses are
   returned to the parent.  Parents periodically send heartbeat requests
   to their children to ensure connectivity, and local nodes similarly
   poll applications, with addresses recalled if the queries are not
   answered.

4.1.2 Service Registration, Requests, Release, and Group Membership
      Maintenance

   The MGA maintains the state of all registered multicast services and
   receivers.  State information includes the number of members
   associated with each group by requested QOS reliability, which is
   updated as services are offered or rescinded and as members join or



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


   leave a group.  The state information is used to ensure that there is
   at least one group member listening to each multicast transfer.

   Servers register the availability of service, specifying whether
   reliable service is available [section 4.2.2] and optionally the
   number of qualities of service offered [section 4.2.1].  A multicast
   group address is allocated from the address pool and the service is
   assigned an identifier as required.  If a reservation protocol that
   requires information from the server (such as RSVP) is in use, then
   the MGA notifies the reservation system of the service with any
   required parameters.  The service registration is propagated through
   the MGA, so that potential clients can discover service availability.
   However, servers do not begin data transfers until directed to do so
   by the MGA.

   Client requests for service are also processed through the MGA.
   Service requests specify a service, a desired quality of service, and
   a reliability indication.  If the request is for a service that has
   been registered, then the routing support is directed to add a route
   for the new user [section 4.3.1].  If necessary, the MGA also
   notifies the reservation protocol.  If either the requested QOS is
   not being provided or it is provided unreliably and the request is
   for reliable transport, then the service provider is also notified.
   If the service has not yet been registered, an identifier for the
   service is assigned and the request is queued for when the service is
   registered.  In either case, a response is sent to the requester.

   Requests for termination of group membership are also sent to the
   MGA.  If the request originates at a client, the MGA notifies the
   routing function and reservation protocol of the termination in case
   the route should be released [section 4.3.2].  If termination results
   in a given QOS no longer having any recipients, the service provider
   is notified that the QOS is no longer required and should not be
   transmitted.  Server-directed group terminations follow a similar
   procedure, with all clients of the group notified, and the service
   offering is removed from the MGA state tables.

4.2 The Reliable Adaptive Multicast Protocol (RAMP)

   RAMP is a transport-level protocol designed to provide reliable
   multicast service on top of a network protocol such as IP/Multicast,
   with unreliable transport also available.  RAMP is build on the
   premise that applications can request one quality of service (using
   our extended definition), but only require reliable transmission at a
   lower level of quality.  For example, consider the transmission of
   hierarchical image data, in which a base spatial resolution is
   transmitted, followed by higher resolution data.  An application may
   require the base data to be sent reliably, but can tolerate dropped



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


   packets for the higher resolution by using interpolation or pixel
   replication from the base level to approximate the missing data.
   Similar methods can be applied to other data types, such as audio or
   video.

4.2.1 Quality of Service Levels

   RAMP allows a multicast service to be provided at multiple qualities
   of service, with all or some of these levels transmitted reliably.
   These QOS can be distributed across different groups using different
   class D addresses, or in the simplest case be transmitted in
   individual groups.  Single packets can be used for either a single
   QOS, or may be applicable to multiple qualities of service.

   When a data packet is transmitted, a header field indicates the QOS
   level(s) associated with that packet.  In the old IP implementations,
   the Type of Service field can be used as a bit field with one bit for
   each applicable QOS, although this is incompatible with RFC 1349 [1].
   If a packet is required for multiple QOS, then multiple values are
   encoded in the field.  The RAMP host receiver protocol only accepts
   those packets addressed to a group in which an application has
   requested membership and that has a QOS value which is in the set of
   values requested by the receivers.

   The quality of service requested within a flow can be modified during
   the life of the flow.  QOS modification requests are forwarded to the
   MGA, which reduces the number of receivers in the original QOS group
   and increments the count for the requested QOS.  These changes are
   propagated through the MGA hierarchy, with the server notified if
   either the original QOS has no remaining receivers or if the new QOS
   is not currently being served; similarly, the routers are notified if
   routing changes are required.

4.2.2 Error Recovery

   Sequence numbers are used in RAMP to determine the ordering of
   packets within a multicast group.  Mechanisms for ordering packets
   transmitted from different senders is a current research topic [2,
   6], and an appropriate sequencing algorithm will be incorporated
   within the protocol.

   Applications exist that do not require in-order delivery of data; for
   example, some image servers include position identification
   information in each packet.  To enhance the efficiency of such
   schemes, RAMP includes an option to allow out-or-order delivery of
   packets to a receiver.





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


   A NAK-based selective retransmission scheme is used in RAMP to
   minimize the protocol overhead associated with ACK-based schemes.
   When a receiver notices that one or more packets have not been
   received, and the transmission is reliable, a request is sent to the
   sender for the span of packets which are missing.

   RAMP at the sender aggregates retransmission requests for the time
   specified by the retransmission hold timer [section 4.2.3].  After
   this time, the requests are evaluated to determine if sufficient
   receivers dropped a given packet to make multicasting the
   retransmission worthwhile by comparing it to a threshold value.  All
   packets that have received a number of retransmission requests
   greater than the threshold are multicast to the group address, with
   other packets unicast to the individual requesters.  The proposed
   retransmission scheme is a compromise between the extremes of
   multicasting and unicasting all retransmissions.  The rationale is
   that multicasting a request issued by a single sender unnecessarily
   floods networks which had no packet loss, while unicasting to a large
   number of receivers floods the entire network.  The optimal approach,
   dynamically constructing a new multicast group for each dropped
   packet, is currently too costly in terms of group set-up time.

   For those cases where the service provider is unable to retransmit
   the data due to released or overwritten buffers, the protocol
   delivers NAK responses using either multicast or unicast based on the
   number of retransmission requests received.

4.2.3 Flow Control

   RAMP utilizes a rate-based flow control mechanism that derives rate
   reductions from requests for retransmission or router back-off
   requests (i.e., ICMP source quench messages), and derives rate
   increases from the number of packets transmitted without
   retransmission requests.  When a retransmission request is received,
   the protocol uses the number of packets requested to compute a rate
   reduction factor.  Similarly, a different reduction factor is
   computed upon receipt of a router-generated squelch request.  The
   rate reduction factors are then used to compute a reduced rate of
   transmission.

   When a given number of packets have been transmitted without packet
   loss, the rate of transmission is incrementally increased. The size
   of the increase will always be smaller than the size of the smallest
   rate decrease, in order to minimize throttling.

   The retransmission hold timer is modified according to both
   application requests and network state.  As the number of
   retransmission requests rises, the hold timer is incremented to



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


   minimize the number of duplicate retransmissions.  Similarly, the
   timer is decremented as the number of retransmission requests drops.

   RAMP allows for priority traffic, which is marked in the packet
   header.  The protocol transmits a variable number of packets from
   each sending process in proportion to the priority of the flow.

4.3 Routing Support

   The protocol suite requires routing support for four functions: path
   set-up, path tear-down, forwarding based on QOS values, and
   prioritized packet loss due to congestion.  The support must be
   integrated into routers and network-level protocols in a similar
   fashion to IGMP [8].

   Partial support comes as a direct consequence of using reservation
   protocols such as RSVP.  This RFC does not mandate the means of
   implementing the required functions, and the specified protocols are
   compatible with known reservation protocols.

   The routers state tables must maintain both the multicast group
   address and the QOS level(s) requested for each group on each
   outbound interface in order to make appropriate routing decisions
   [section 4.3.3].  Therefore, the router state tables are updated
   whenever group membership changes, including QOS changes.

4.3.1 Path Set-up

   Routers receive path set-up requests from the MGA as required when
   new members join a multicast group, which specifies the incoming and
   outgoing interfaces, the group address, and the QOS associated with
   the request.  When the message is received, the router establishes a
   path between the server and the receiver, and subsequently updates
   the multicast group state table.  The mechanism used to discern the
   network interfaces is not specified, but may take advantage of other
   protocols such as the RSVP path and reservation mechanism.

4.3.2 Path Tear-down

   Path tear-down requests are also propagated through the routers by
   the MGA when group membership changes or QOS changes no longer
   require data to be sent over a given route.  These are used to inform
   routers of both deletions of QOS for a given path and deletions of
   entire paths.  The purpose of the message is to explicitly remove
   route table entries in order to minimize the time required to stop
   forwarding multicast data across networks once the path is no longer
   required.




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


4.3.3 Multicast Routing Based on Quality of Service

   Traditional multicast routing formulates route/don't route decisions
   based on the destination address in the packet header, with packets
   duplicated as necessary to reach all destinations.  In the proposed
   new protocol suite, routers also consult the QOS field for each
   packet as different paths may have requested different qualities of
   service.  Packets are only forwarded if the group address has been
   requested and the quality of service specified in the header is
   requested in the state table entry for a given interface.