rfc1458.txt

中、英文RFC文档大全打包下载完全版 .

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:  [phone]
   EMail:  [e-mail]


   Steve Zabele
   TASC
   55 Walkers Brook Drive
   Reading, MA 01867

   Phone:  [phone]
   EMail: [e-mail]





























Braudes & Zabele                                               [Page 19]