summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1458.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1458.txt')
-rw-r--r--doc/rfc/rfc1458.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc1458.txt b/doc/rfc/rfc1458.txt
new file mode 100644
index 0000000..f45d0ad
--- /dev/null
+++ b/doc/rfc/rfc1458.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group R. Braudes
+Request for Comments: 1458 S. Zabele
+ TASC
+ May 1993
+
+
+ Requirements for Multicast Protocols
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard. Distribution of this memo is
+ unlimited.
+
+Summary
+
+ Multicast protocols have been developed over the past several years
+ to address issues of group communication. Experience has
+ demonstrated that current protocols do not address all of the
+ requirements of multicast applications. This memo discusses some of
+ these unresolved issues, and provides a high-level design for a new
+ multicast transport protocol, group address and membership authority,
+ and modifications to existing routing protocols.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. The Image Communication Problem . . . . . . . . . . . . . 2
+ 2.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Review of Existing Multicast Protocols . . . . . . . . . . 4
+ 3.1 IP/Multicast . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.2 XTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.3 ST-II . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.4 MTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4. Reliable Adaptive Multicast Service . . . . . . . . . . . 9
+ 4.1 The Multicast Group Authority . . . . . . . . . . . . . . 9
+ 4.1.1 Address Management . . . . . . . . . . . . . . . . . . . . 9
+ 4.1.2 Service Registration, Requests, Release, and Group
+ Membership Maintenance . . . . . . . . . . . . . . . . . . 10
+ 4.2 The Reliable Adaptive Multicast Protocol (RAMP) . . . . . 11
+ 4.2.1 Quality of Service Levels . . . . . . . . . . . . . . . . 12
+ 4.2.2 Error Recovery . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.2.3 Flow Control . . . . . . . . . . . . . . . . . . . . . . . 13
+ 4.3 Routing Support . . . . . . . . . . . . . . . . . . . . . 14
+ 4.3.1 Path Set-up . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.3.2 Path Tear-down . . . . . . . . . . . . . . . . . . . . . . 15
+
+
+
+Braudes & Zabele [Page 1]
+
+RFC 1458 Requirements for Multicast Protocols May 1993
+
+
+ 4.3.3 Multicast Routing Based on Quality of Service . . . . . . 15
+ 4.3.4 Quality of Service Based Packet Loss . . . . . . . . . . . 15
+ 5. Interactions Among the Components: An Example . . . . . . 15
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ Security Considerations . . . . . . . . . . . . . . . . . . . . 19
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
+
+1. Introduction
+
+ Multicast protocols have been developed to support group
+ communications. These protocols use a one-to-many paradigm for
+ transmission, typically using class D Internet Protocol (IP)
+ addresses to specify specific multicast groups. While designing
+ network services for reliable transmission of very large imagery as
+ part of the DARPA-sponsored ImNet program, we have reviewed existing
+ multicast protocols and have determined that none meet all of the
+ requirements of image communications [3]. This RFC reviews the
+ current state of multicast protocols, highlights the missing
+ features, and motivates the design and development of an enhanced
+ multicast protocol.
+
+ First, the requirements for network services and underlying protocols
+ related to image communications are presented. Existing protocols
+ are then reviewed, and an analysis of each protocol against the
+ requirements is presented. The analyses identify the need for a new
+ multicast protocol. Finally, the features of an ideal reliable
+ multicast protocol that adapts to network congestion in the
+ transmission of large data volumes are presented. Additional network
+ components needed to fully support the new protocol, including a
+ Multicast Group Authority and modifications to existing routing
+ protocols, are also introduced.
+
+2. The Image Communications Problem
+
+2.1 Scope
+
+ Image management and communications systems are evolving from film-
+ based systems toward an all-digital environment where imagery is
+ acquired, transmitted, analyzed, and stored using digital computer
+ and communications technologies. The throughput required for
+ communicating large numbers of very large images is extremely large,
+ consisting of thousands of terabytes of imagery per day. Temporal
+ requirements for capture and dissemination of single images are
+ stringent, ranging from seconds to at most several minutes. Imagery
+ will be viewed by hundreds of geographically distributed users who
+ will require on-demand, interactive access to the data.
+
+
+
+
+Braudes & Zabele [Page 2]
+
+RFC 1458 Requirements for Multicast Protocols May 1993
+
+
+ Traditional imaging applications involve images on the order of 512
+ by 512 pixels. In contrast, a single image used for remote sensing
+ can have tens of thousands of pixels on a side. Multiplying the data
+ volume associated with remotely sensed images by even a small number
+ of users clearly motivates moving beyond the current suite of
+ reliable protocols.
+
+ Basic image communication applications involve distribution of
+ individual images to multiple users for both individual and
+ collaborative analyses, and network efficiency requires the use of
+ multicast protocols. Areas where multicasting offers significant
+ advantages include real-time image acquisition and dissemination,
+ distribution of annotated image-based reports, and image
+ conferencing. Images are viewed on a heterogeneous set of
+ workstations with differing processing and display capabilities,
+ traveling over a heterogeneous network with bandwidths varying by up
+ to six orders of magnitude between the initial down link and the
+ slowest end user.
+
+2.2 Requirements
+
+ Multicast protocols used for image communications must address
+ several requirements. Setting up a multicast group first requires
+ assigning a multicast group address. All multicast traffic is then
+ delivered to this address, which implies that all members of the
+ group must be listening for traffic with this address.
+
+ Within an image communications architecture such as that used for the
+ ImNet program, diversity and adaptability can be accommodated by
+ trading quality of service (i.e., image quality) with speed of
+ transmission. Multicast support for quality-speed trades can be
+ realized either through the use of different multicast groups, where
+ each group receives a different image quality, or through the use of
+ a single hierarchical stream with routers (or users) extracting
+ relevant portions.
+
+ Due to the current inability of routers to support selective
+ transmission of partial streams, a multiple stream approach is being
+ used within ImNet. Efficient operation using a multiple stream
+ approach requires that users be able to switch streams very quickly,
+ and that streams with no listeners not be disseminated.
+ Consequently, rapid configuration of multicast groups and rapid
+ switching between multicast groups switching is essential.
+
+ Inevitably, network congestion or buffer overruns result in packet
+ loss. A full range of transport reliability is required within an
+ image communications framework. For some applications such as image
+ conferencing, packet loss does not present a problem as dropped mouse
+
+
+
+Braudes & Zabele [Page 3]
+
+RFC 1458 Requirements for Multicast Protocols May 1993
+
+
+ movements can be discarded with no meaningful degradation in utility.
+ However, for functions such as image archiving or detailed image
+ analysis, transport must be completely reliable, where any dropped
+ packets must be retransmitted by the sender. Additionally, several
+ hierarchical image compression methods can provide useful, albeit
+ degraded, imagery using a semi-reliable service, where higher level
+ data is transmitted reliably and the lower level data is transmitted
+ unreliably.
+
+ In support of reliable transport, image communications services must
+ also support adaptation to network congestion using flow control
+ mechanisms. Flow control regulates the quantity of data placed on
+ the network per unit time interval, thereby increasing network
+ efficiency by reducing the number of dropped packets and avoiding the
+ need for large numbers of retransmissions.
+
+3. Review of Existing Multicast Protocols
+
+ Several existing protocols provide varying levels of support for
+ multicasting, including IP/Multicast [5], the Xpress Transfer
+ Protocol (XTP) [11], and Experimental Internet Stream Protocol
+ Version 2 (ST-II) [10]. While the Versatile Message Transaction
+ Protocol (VMTP) [4] also supports multicast, it has been designed to
+ support the transfer of small packets, and so is not appropriate for
+ large image communications. Additionally, a specification exists for
+ the Multicast Transport Protocol (MTP) [2].
+
+ The image communication requirements for a multicast protocol include
+ multicast group address assignment, group set-up, membership
+ maintenance (i.e., join, drop, and switch membership), group tear-
+ down, error recovery, and flow control, as presented above. The
+ remainder of this section discusses how well each of the existing
+ protocols meets these requirements.
+
+3.1 IP/Multicast
+
+ IP/Multicast is an extension to the standard IP network-level
+ protocol that supports multicast traffic. IP/Multicast has no
+ address allocation mechanism, with addresses assigned either by an
+ outside authority or by each application. This has the potential for
+ address contention among multiple applications, which would result in
+ the traffic from the different groups becoming commingled.
+
+ There is no true set-up processing for IP/Multicast; once an address
+ is determined, the sender simply transmits packets to that address
+ with routers determining the path(s) taken by the data. The receiver
+ side is only slightly more complex, as an application must issue an
+ add membership request for IP to listen to traffic destined to the
+
+
+
+Braudes & Zabele [Page 4]
+
+RFC 1458 Requirements for Multicast Protocols May 1993
+
+
+ desired address. If this is the first member of a group, IP
+ multicasts the request to routers on the local network using the
+ Internet Group Multicast Protocol (IGMP) for inclusion in routing
+ tables. Multicast packets are then routed like all other IP packets,
+ with receivers accepting traffic addressed to joined groups in
+ addition to the normal host address.
+
+ A major problem with the IP/Multicast set-up approach is informing
+ hosts of multicast group addresses. If addresses are dynamically
+ allocated, then a mechanism must be established for informing
+ receivers which addresses have been assigned to which groups. This
+ requires a minimum of one round trip time, with an address requested
+ from a server and then returned to the receiver.
+
+ Dropping membership in a group involves issuing a request to the
+ local IP, which decrements the count of members in the IP tables.
+ However, no special action is taken when group membership goes to
+ zero. Instead, a heartbeat mechanism is used in which hosts are
+ periodically polled for active groups, and routers stop forwarding
+ group traffic to a network only after several polls receive no
+ activity requests for that group to ensure that a membership report
+ is not lost or corrupted in transit. This causes the problem of
+ unneeded traffic being transmitted, due to a long periodicity for the
+ heartbeat (minimum of one minute between polls); consequently there
+ is no method for quickly dropping a group over a given path, impeding
+ attempts to react to network congestion in real-time.
+
+ Finally, there is no transport level protocol compatible with
+ IP/Multicast that is both reliable and implements a flow control
+ mechanism.
+
+3.2 XTP
+
+ XTP is a combined network and transport level protocol that offers
+ significant support for multicast transfers. As with IP/Multicast,
+ XTP offers no inherent address management scheme, so that an outside
+ authority is required.
+
+ 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
+
+ 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.
+
+4.3.4 Quality of Service Based Packet Loss
+
+ Network congestion causes router queues to overflow, and as a result
+ packet loss occurs. The QOS and priority indications in the packet
+ headers can be used to prioritize the order in which packets are
+ dropped. First, packets with the priority field set in the header
+ are dropped last. Within packets of equal priority, packets are
+ dropped in order of QOS, with the highest QOS packets dropped first.
+ The rationale is that other packets with lower QOS may be usable by
+ receivers, while packets with high QOS may not be usable without the
+ lower QOS data.
+
+5. Interactions Among the Components: An Example
+
+ The MGA, RAMP, and routing support functions all cooperate in the
+ multicast process. As an example, assume that a network exists with
+ a single server (S), three routers (R1, R2, and R3), and two clients
+ (C1 and C2). The path between S and C1 goes through R1 and R2, while
+ the path between S and C2 goes through R1, R2, and R3. The network
+ is shown in figure 2.
+
+ S ------- R1 -------- R2 -------- R3
+ | |
+ C1 C2
+
+ Figure 2. Sample Network Configuration
+
+ Service Registration
+
+ When S is initiated, it registers a service with the MGA node in
+ the local workstation, offering reliable service at two qualities
+ of service, Q1 and Q2. As this is the first multicast offering on
+ the workstation, the local MGA requests a block of multicast
+ addresses from the hierarchy, and assigns an address and service
+ identifier to S. If the RSVP reservation protocol is in operation,
+ the local MGA node in S notifies RSVP to send a RpathS
+ message out for the service, which goes through R1, R2, and R3,
+
+
+
+Braudes & Zabele [Page 15]
+
+RFC 1458 Requirements for Multicast Protocols May 1993
+
+
+ reaching the RSVP nodes on C1 and C2. The service and its
+ characteristics are propagated throughout the MGA hierarchy,
+ ultimately reaching the MGA nodes resident on C1 and C2. The
+ service is now available throughout the network.
+
+ Service Request and Path Set-up
+
+ The client C1 requests reliable service from S at QOS Q1, by
+ issuing a request to the MGA node in C1. If a reservation protocol
+ is in use, then it is used to reserve bandwidth and establish a
+ path between the sender and receiver, going through R1 and R2;
+ otherwise, the path is established through R1 and R2 by the routing
+ protocol. R1 now forwards all packets from S with QOS Q1 along the
+ path to R2, which routes them to C1. In concert with the path
+ set-up, the add membership request is propagated through MGA to the
+ server workstation. The local MGA tables are checked and it is
+ noted that the service is not currently being offered, so the
+ server is notified to begin reliable distribution of the service at
+ Q1.
+
+ Initial Delivery
+
+ The server now begins transmitting Q1 data which is observed by R1.
+ R1 inspects the header and notes that the packet has QOS Q1. The
+ routing tables specify that QOS Q1 for this address are only
+ forwarded along the interface leading to R2, and R1 acts
+ accordingly. Similarly, R2 routes the packet to C1. When the data
+ arrives at C1, the RAMP node inspects the QOS and destination
+ address fields in the header, accepts the packet, and forwards it
+ to the C1 client process.
+
+ Error Recovery
+
+ During transmission, if the RAMP node in C1 realizes that packets
+ have been dropped, a retransmission request is returned to the
+ server identifying spans of the missing packets. The RAMP node
+ accepts the packet, builds the retransmission packets, and sets the
+ retransmission hold timer. When the timer expires, the number of
+ retransmission requests for each missing packet is compared against
+ the threshold, and the packets are either unicast directly to the
+ requesters or multicast to the entire group. As in this case there
+ is only requester, the threshold is not exceeded and the packets
+ are retransmitted to C1Us unicast address.
+
+ Group Membership Addition
+
+ Client C2 now joins the group, requesting reliable transmission at
+ QOS Q2. Following the process used for C1, the request propagates
+
+
+
+Braudes & Zabele [Page 16]
+
+RFC 1458 Requirements for Multicast Protocols May 1993
+
+
+ through the MGA (and potentially reservation protocol) hierarchy.
+ Upon completion of the request processing, R1 routes packets for
+ QOS Q1 and Q2 to R2, while R2 forwards QOS Q1 packets to C1 and Q2
+ packets to R3; client C1 only accepts packets marked as Q1 while C2
+ only accepts Q2 packets. The server is notified that it now has
+ clients for Q2, and begins serving that QOS in addition to Q1.
+
+ QOS Based Routing
+
+ First, assume that QOS Q1 data is independent of QOS Q2 data. When
+ the server sends a packet with Q1 marked in the header, the packet
+ is received by R1 and is forwarded to R2. R2 receives the packet,
+ and sends it out the interface to C1, but not to R3. Next, the
+ server delivers a packet for Q2. R1 receives the packet and sends
+ it to R2, which forwards it to R3 but not to C1. R3 accepts the
+ packet, and forwards it to C2.
+
+ Now, assume that either Q2 is a subset of Q1, or that receivers of
+ Q1 data also require Q2 data as in conditional compression schemes.
+ Therefore, all Q2 packets are marked for both Q1 and Q2, while the
+ remaining Q1 packets only have Q1 set in the header. Q1-only
+ packets are routed as before, following the path S -> R1 -> R2 ->
+ C1. However, Q2 packets are now routed from S to R1 to R2, at
+ which point R2 duplicates the packets and sends them to both C1 and
+ R3, with R3 forwarding them to C2. At C1, these packets have Q1
+ marked, and so are accepted, while at C2 the packet is accepted as
+ the Q2 bit is verified.
+
+ Group Membership Deletion
+
+ When C1 issues a drop membership request, the MGA on the client
+ workstation is notified, and the request is propagated through the
+ MGA hierarchy back to the server MGA node. In parallel, the
+ routers are notified to close the path, as it is no longer
+ required, possibly through the reservation protocol. As this is
+ the last client for the Q1 QOS, the server is informed to stop
+ transmitting Q1 data, with Q2 data unaffected. A similar process
+ occurs when C2 drops membership from the group, leaving the server
+ idle. At this point, the server has the option of shutting down
+ and returning the group address to the MGA, or to continue in an
+ idle state until another client requests service.
+
+Acknowledgements
+
+ This research was supported in part by the Defense Research
+ Projects Agency (DARPA) under contract number F19618-91-C-0086.
+
+
+
+
+
+Braudes & Zabele [Page 17]
+
+RFC 1458 Requirements for Multicast Protocols May 1993
+
+
+References
+
+ [1] Almquist, P., "Type of Service in the Internet Protocol Suite",
+ RFC 1349, Consultant, July 1992.
+
+ [2] Armstrong, S., Freier, A., and K. Marzullo, "Multicast Transport
+ Protocol", RFC 1301, Xerox, Apple, Cornell University, February
+ 1992.
+
+ [3] Braudes, R., and S. Zabele, "A Reliable, Adaptive Multicast
+ Service for High-Bandwidth Image Dissemination", submitted to ACM
+ SIGCOMM '93.
+
+ [4] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC
+ 1045, Stanford University, February 1988.
+
+ [5] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
+ 1112, Stanford University, August 1989.
+
+ [6] Mayer, E., "An Evaluation Framework for Multicast Ordering
+ Protocols", Proceedings ACM SIGCOMM '92, Baltimore, Maryland, pp.
+ 177-187.
+
+ [7] Mockapetris, P., "Domain Names - Concepts and Facilities," STD
+ 13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+ [8] Postel, J., "Internet Control Message Protocol - DARPA Internet
+ Program Protocol Specification", STD 5, RFC 792, USC/Information
+ Sciences Institute, September 1981.
+
+ [9] Strayer, W., Dempsey, B., and A. Weaver, "XTP: The Xpress
+ Transfer Protocol", Addison-Wesley Publishing Co., Reading, MA,
+ 1992.
+
+ [10] Topolcic, C., Editor, "Experimental Internet Stream Protocol,
+ Version 2 (ST- II)", RFC 1190, CIP Working Group, October 1990.
+
+ [11] "XTP Protocol Definition Revision 3.6", Protocol Engines
+ Incorporated, PEI 92-10, Mountain View, CA, 11 January 1992.
+
+ [12] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala,
+ "RSVP: A New Resource ReSerVation Protocol", Work in Progress,
+ March 1993.
+
+
+
+
+
+
+
+
+Braudes & Zabele [Page 18]
+
+RFC 1458 Requirements for Multicast Protocols May 1993
+
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Authors' Addresses
+
+ Bob Braudes
+ TASC
+ 55 Walkers Brook Drive
+ Reading, MA 01867
+
+ Phone: (617) 942-2000
+ EMail: rebraudes@tasc.com
+
+
+ Steve Zabele
+ TASC
+ 55 Walkers Brook Drive
+ Reading, MA 01867
+
+ Phone: (617) 942-2000
+ EMail: gszabele@tasc.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Braudes & Zabele [Page 19]
+ \ No newline at end of file