RFC relevance of requirements

As per Relevance of the word requirements, we have this rfc below:

Network Working Group R.
Request for Comments: 1458 S.

May 1993

Requirements for Multicast

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited

Multicast protocols have been developed over the past several
to address issues of group communication. Experience
demonstrated that current protocols do not address all of
requirements of multicast applications. This memo discusses some
these unresolved issues, and provides a high-level design for a
multicast transport protocol, group address and membership authority
and modifications to existing routing protocols

Table of

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
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.

Multicast protocols have been developed to support
communications. These protocols use a one-to-many paradigm
transmission, typically using class D Internet Protocol (IP
addresses to specify specific multicast groups. While
network services for reliable transmission of very large imagery
part of the DARPA-sponsored ImNet program, we have reviewed
multicast protocols and have determined that none meet all of
requirements of image communications [3]. This RFC reviews
current state of multicast protocols, highlights the
features, and motivates the design and development of an
multicast protocol

First, the requirements for network services and underlying
related to image communications are presented. Existing
are then reviewed, and an analysis of each protocol against
requirements is presented. The analyses identify the need for a
multicast protocol. Finally, the features of an ideal
multicast protocol that adapts to network congestion in
transmission of large data volumes are presented. Additional
components needed to fully support the new protocol, including
Multicast Group Authority and modifications to existing
protocols, are also introduced

2. The Image Communications

2.1

Image management and communications systems are evolving from film
based systems toward an all-digital environment where imagery
acquired, transmitted, analyzed, and stored using digital
and communications technologies. The throughput required
communicating large numbers of very large images is extremely large
consisting of thousands of terabytes of imagery per day.
requirements for capture and dissemination of single images
stringent, ranging from seconds to at most several minutes.
will be viewed by hundreds of geographically distributed users
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
can have tens of thousands of pixels on a side. Multiplying the
volume associated with remotely sensed images by even a small
of users clearly motivates moving beyond the current suite
reliable protocols

Basic image communication applications involve distribution
individual images to multiple users for both individual
collaborative analyses, and network efficiency requires the use
multicast protocols. Areas where multicasting offers
advantages include real-time image acquisition and dissemination
distribution of annotated image-based reports, and
conferencing. Images are viewed on a heterogeneous set
workstations with differing processing and display capabilities
traveling over a heterogeneous network with bandwidths varying by
to six orders of magnitude between the initial down link and
slowest end user

2.2

Multicast protocols used for image communications must
several requirements. Setting up a multicast group first
assigning a multicast group address. All multicast traffic is
delivered to this address, which implies that all members of
group must be listening for traffic with this address

Within an image communications architecture such as that used for
ImNet program, diversity and adaptability can be accommodated
trading quality of service (i.e., image quality) with speed
transmission. Multicast support for quality-speed trades can
realized either through the use of different multicast groups,
each group receives a different image quality, or through the use
a single hierarchical stream with routers (or users)
relevant portions

Due to the current inability of routers to support
transmission of partial streams, a multiple stream approach is
used within ImNet. Efficient operation using a multiple
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
switching between multicast groups switching is essential

Inevitably, network congestion or buffer overruns result in
loss. A full range of transport reliability is required within
image communications framework. For some applications such as
conferencing, packet loss does not present a problem as dropped

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
analysis, transport must be completely reliable, where any
packets must be retransmitted by the sender. Additionally,
hierarchical image compression methods can provide useful,
degraded, imagery using a semi-reliable service, where higher
data is transmitted reliably and the lower level data is
unreliably

In support of reliable transport, image communications services
also support adaptation to network congestion using flow
mechanisms. Flow control regulates the quantity of data placed
the network per unit time interval, thereby increasing
efficiency by reducing the number of dropped packets and avoiding
need for large numbers of retransmissions

3. Review of Existing Multicast

Several existing protocols provide varying levels of support
multicasting, including IP/Multicast [5], the Xpress
Protocol (XTP) [11], and Experimental Internet Stream
Version 2 (ST-II) [10]. While the Versatile Message
Protocol (VMTP) [4] also supports multicast, it has been designed
support the transfer of small packets, and so is not appropriate
large image communications. Additionally, a specification exists
the Multicast Transport Protocol (MTP) [2].

The image communication requirements for a multicast protocol
multicast group address assignment, group set-up,
maintenance (i.e., join, drop, and switch membership), group tear
down, error recovery, and flow control, as presented above.
remainder of this section discusses how well each of the
protocols meets these requirements

3.1 IP/

IP/Multicast is an extension to the standard IP network-
protocol that supports multicast traffic. IP/Multicast has
address allocation mechanism, with addresses assigned either by
outside authority or by each application. This has the potential
address contention among multiple applications, which would result
the traffic from the different groups becoming commingled

There is no true set-up processing for IP/Multicast; once an
is determined, the sender simply transmits packets to that
with routers determining the path(s) taken by the data. The
side is only slightly more complex, as an application must issue
add membership request for IP to listen to traffic destined to

Braudes & Zabele [Page 4]

RFC 1458 Requirements for Multicast Protocols May 1993

desired address. If this is the first member of a group,
multicasts the request to routers on the local network using
Internet Group Multicast Protocol (IGMP) for inclusion in
tables. Multicast packets are then routed like all other IP packets
with receivers accepting traffic addressed to joined groups
addition to the normal host address

A major problem with the IP/Multicast set-up approach is
hosts of multicast group addresses. If addresses are
allocated, then a mechanism must be established for
receivers which addresses have been assigned to which groups.
requires a minimum of one round trip time, with an address
from a server and then returned to the receiver

Dropping membership in a group involves issuing a request to
local IP, which decrements the count of members in the IP tables
However, no special action is taken when group membership goes
zero. Instead, a heartbeat mechanism is used in which hosts
periodically polled for active groups, and routers stop
group traffic to a network only after several polls receive
activity requests for that group to ensure that a membership
is not lost or corrupted in transit. This causes the problem
unneeded traffic being transmitted, due to a long periodicity for
heartbeat (minimum of one minute between polls); consequently
is no method for quickly dropping a group over a given path,
attempts to react to network congestion in real-time

Finally, there is no transport level protocol compatible
IP/Multicast that is both reliable and implements a flow
mechanism

3.2

XTP is a combined network and transport level protocol that
significant support for multicast transfers. As with IP/Multicast
XTP offers no inherent address management scheme, so that an
authority is required

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

In contrast to IP/Multicast, XTP does require explicit

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
out of groups, and the only mechanism for a sender to know if
are any receivers is the polling scheme used for error control
recovery. This causes the same problems with sending traffic
groups without members discussed under IP/Multicast

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

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

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

3.3 ST-

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

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

Braudes & Zabele [Page 6]

RFC 1458 Requirements for Multicast Protocols May 1993

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

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

While the resource guarantee system imposed by ST-II tries to
network congestion from occurring, there are situations
priority traffic must be introduced into the network. ST-II
this very expensive, as the resource requirements for
connections must be adjusted, which can only be accomplished by
origin of each stream. This must be completed prior to
connection set-up for the priority stream, introducing a large
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
allocated over that path are released. When all receivers have
removed, the sender in informed and has the option of either adding
new receiver or tearing down the group

3.4

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

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

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

Braudes & Zabele [Page 7]

RFC 1458 Requirements for Multicast Protocols May 1993

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

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

One of the major features in MTP is the ordering of received data
The master distributes transmit tokens to data producers in
group, which allow data to be provided at a specified rate.
control provides flow control within the protocol, with members
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
the master, and to be able to retransmit this data when requested
members of the group. These retransmissions are multicast to
entire group, requiring receivers to be able to cope with
packets. If a retransmission request arrives after the data has
released, the sender must NAK the request

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

3.5

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

Braudes & Zabele [Page 8]

RFC 1458 Requirements for Multicast Protocols May 1993

4. Protocol Suite for Reliable, Adaptive

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

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

4.1 The Multicast Group

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

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

4.1.1 Address

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

Figure 1 can be used to show what happens when an
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
the request to node 1. Node 1 passes this request to the root,
issues a block of, say, 30 class D addresses. Of these 30, 10
returned to node 1.1, with the remaining 20 reserved for
from node 1's other children. Similarly, node 1.1 passes 3

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,
the remaining 2 addresses for future use

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

Figure 1. Sample MGA

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

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

4.1.2 Service Registration, Requests, Release, and Group

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

Braudes & Zabele [Page 10]

RFC 1458 Requirements for Multicast Protocols May 1993

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

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

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

Requests for termination of group membership are also sent to
MGA. If the request originates at a client, the MGA notifies
routing function and reservation protocol of the termination in
the route should be released [section 4.3.2]. If termination
in a given QOS no longer having any recipients, the service
is notified that the QOS is no longer required and should not
transmitted. Server-directed group terminations follow a
procedure, with all clients of the group notified, and the
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
multicast service on top of a network protocol such as IP/Multicast
with unreliable transport also available. RAMP is build on
premise that applications can request one quality of service (
our extended definition), but only require reliable transmission at
lower level of quality. For example, consider the transmission
hierarchical image data, in which a base spatial resolution
transmitted, followed by higher resolution data. An application
require the base data to be sent reliably, but can tolerate

Braudes & Zabele [Page 11]

RFC 1458 Requirements for Multicast Protocols May 1993

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

4.2.1 Quality of Service

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

When a data packet is transmitted, a header field indicates the
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
each applicable QOS, although this is incompatible with RFC 1349 [1].
If a packet is required for multiple QOS, then multiple values
encoded in the field. The RAMP host receiver protocol only
those packets addressed to a group in which an application
requested membership and that has a QOS value which is in the set
values requested by the receivers

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

4.2.2 Error

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

Applications exist that do not require in-order delivery of data;
example, some image servers include position
information in each packet. To enhance the efficiency of
schemes, RAMP includes an option to allow out-or-order delivery
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
minimize the protocol overhead associated with ACK-based schemes
When a receiver notices that one or more packets have not
received, and the transmission is reliable, a request is sent to
sender for the span of packets which are missing

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

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

4.2.3 Flow

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

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

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

Braudes & Zabele [Page 13]

RFC 1458 Requirements for Multicast Protocols May 1993

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

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

4.3 Routing

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

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

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

4.3.1 Path Set-

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

4.3.2 Path Tear-

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

Braudes & Zabele [Page 14]

RFC 1458 Requirements for Multicast Protocols May 1993

4.3.3 Multicast Routing Based on Quality of

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

4.3.4 Quality of Service Based Packet

Network congestion causes router queues to overflow, and as a
packet loss occurs. The QOS and priority indications in the
headers can be used to prioritize the order in which packets
dropped. First, packets with the priority field set in the
are dropped last. Within packets of equal priority, packets
dropped in order of QOS, with the highest QOS packets dropped first
The rationale is that other packets with lower QOS may be usable
receivers, while packets with high QOS may not be usable without
lower QOS data

5. Interactions Among the Components: An

The MGA, RAMP, and routing support functions all cooperate in
multicast process. As an example, assume that a network exists
a single server (S), three routers (R1, R2, and R3), and two
(C1 and C2). The path between S and C1 goes through R1 and R2,
the path between S and C2 goes through R1, R2, and R3. The
is shown in figure 2.

S ------- R1 -------- R2 -------- R
| |
C1 C

Figure 2. Sample Network

Service

When S is initiated, it registers a service with the MGA node
the local workstation, offering reliable service at two
of service, Q1 and Q2. As this is the first multicast offering
the workstation, the local MGA requests a block of
addresses from the hierarchy, and assigns an address and
identifier to S. If the RSVP reservation protocol is in operation
the local MGA node in S notifies RSVP to send a
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
characteristics are propagated throughout the MGA hierarchy
ultimately reaching the MGA nodes resident on C1 and C2.
service is now available throughout the network

Service Request and Path Set-

The client C1 requests reliable service from S at QOS Q1,
issuing a request to the MGA node in C1. If a reservation
is in use, then it is used to reserve bandwidth and establish
path between the sender and receiver, going through R1 and R2;
otherwise, the path is established through R1 and R2 by the
protocol. R1 now forwards all packets from S with QOS Q1 along
path to R2, which routes them to C1. In concert with the
set-up, the add membership request is propagated through MGA to
server workstation. The local MGA tables are checked and it
noted that the service is not currently being offered, so
server is notified to begin reliable distribution of the service
Q1.

Initial

The server now begins transmitting Q1 data which is observed by R1.
R1 inspects the header and notes that the packet has QOS Q1.
routing tables specify that QOS Q1 for this address are
forwarded along the interface leading to R2, and R1
accordingly. Similarly, R2 routes the packet to C1. When the
arrives at C1, the RAMP node inspects the QOS and
address fields in the header, accepts the packet, and forwards
to the C1 client process

Error

During transmission, if the RAMP node in C1 realizes that
have been dropped, a retransmission request is returned to
server identifying spans of the missing packets. The RAMP
accepts the packet, builds the retransmission packets, and sets
retransmission hold timer. When the timer expires, the number
retransmission requests for each missing packet is compared
the threshold, and the packets are either unicast directly to
requesters or multicast to the entire group. As in this case
is only requester, the threshold is not exceeded and the
are retransmitted to C1Us unicast address

Group Membership

Client C2 now joins the group, requesting reliable transmission
QOS Q2. Following the process used for C1, the request

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
QOS Q1 and Q2 to R2, while R2 forwards QOS Q1 packets to C1 and Q
packets to R3; client C1 only accepts packets marked as Q1 while C
only accepts Q2 packets. The server is notified that it now
clients for Q2, and begins serving that QOS in addition to Q1.

QOS Based

First, assume that QOS Q1 data is independent of QOS Q2 data.
the server sends a packet with Q1 marked in the header, the
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,
server delivers a packet for Q2. R1 receives the packet and
it to R2, which forwards it to R3 but not to C1. R3 accepts
packet, and forwards it to C2.

Now, assume that either Q2 is a subset of Q1, or that receivers
Q1 data also require Q2 data as in conditional compression schemes
Therefore, all Q2 packets are marked for both Q1 and Q2, while
remaining Q1 packets only have Q1 set in the header. Q1-
packets are routed as before, following the path S -> R1 -> R2 ->
C1. However, Q2 packets are now routed from S to R1 to R2,
which point R2 duplicates the packets and sends them to both C1
R3, with R3 forwarding them to C2. At C1, these packets have Q
marked, and so are accepted, while at C2 the packet is accepted
the Q2 bit is verified

Group Membership

When C1 issues a drop membership request, the MGA on the
workstation is notified, and the request is propagated through
MGA hierarchy back to the server MGA node. In parallel,
routers are notified to close the path, as it is no
required, possibly through the reservation protocol. As this
the last client for the Q1 QOS, the server is informed to
transmitting Q1 data, with Q2 data unaffected. A similar
occurs when C2 drops membership from the group, leaving the
idle. At this point, the server has the option of shutting
and returning the group address to the MGA, or to continue in
idle state until another client requests service

This research was supported in part by the Defense
Projects Agency (DARPA) under contract number F19618-91-C-0086.

Braudes & Zabele [Page 17]

RFC 1458 Requirements for Multicast Protocols May 1993

[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
Protocol", RFC 1301, Xerox, Apple, Cornell University,
1992.

[3] Braudes, R., and S. Zabele, "A Reliable, Adaptive
Service for High-Bandwidth Image Dissemination", submitted to
SIGCOMM '93.

[4] Cheriton, D., "VMTP: Versatile Message Transaction Protocol",
1045, Stanford University, February 1988.

[5] Deering, S., "Host Extensions for IP Multicasting", STD 5,
1112, Stanford University, August 1989.

[6] Mayer, E., "An Evaluation Framework for Multicast
Protocols", Proceedings ACM SIGCOMM '92, Baltimore, Maryland, pp
177-187.

[7] Mockapetris, P., "Domain Names - Concepts and Facilities,"
13, RFC 1034, USC/Information Sciences Institute, November 1987.

[8] Postel, J., "Internet Control Message Protocol - DARPA
Program Protocol Specification", STD 5, RFC 792, USC/
Sciences Institute, September 1981.

[9] Strayer, W., Dempsey, B., and A. Weaver, "XTP: The
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
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

Security issues are not discussed in this memo

Authors'

Bob

55 Walkers Brook
Reading, MA 01867

Phone: (617) 942-2000
EMail: rebraudes@tasc.

Steve

55 Walkers Brook
Reading, MA 01867

Phone: (617) 942-2000
EMail: gszabele@tasc.

Braudes & Zabele [Page 19]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX