RFC 2729 (rfc2729) - Page 2 of 27

Taxonomy of Communication Requirements for Large-scale Multicast Applications

RFC 2729         Taxonomy of Communication Requirements    December 1999


Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
   2. Definitions of Sessions. . . . . . . . . . . . . . . . . 3
   3. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.1. Summary of Communications Parameters . . . . . . . . 4
     3.2. Definitions, types and strictest requirements. . . . 5
       3.2.1. Types  . . . . . . . . . . . . . . . . . . . . . 6
       3.2.2. Reliability  . . . . . . . . . . . . . . . . . . 7
         3.2.2.1. Packet Loss  . . . . . . . . . . . . . . . . 7
         3.2.2.2. Component Reliability  . . . . . . . . . . . 8
       3.2.3. Ordering . . . . . . . . . . . . . . . . . . . . 9
       3.2.4. Timeliness . . . . . . . . . . . . . . . . . . . 9
       3.2.5. Session Control  . . . . . . . . . . . . . . . .13
       3.2.6. Session Topology . . . . . . . . . . . . . . . .16
       3.2.7. Directory  . . . . . . . . . . . . . . . . . . .17
       3.2.8. Security . . . . . . . . . . . . . . . . . . . .17
         3.2.8.1. Security Dynamics  . . . . . . . . . . . . .23
       3.2.9. Payment & Charging . . . . . . . . . . . . . . .24
   4. Security Considerations  . . . . . . . . . . . . . . . .25
   5. References   . . . . . . . . . . . . . . . . . . . . . .25
   6. Authors' Addresses . . . . . . . . . . . . . . . . . . .26
   7. Full Copyright Statement . . . . . . . . . . . . . . . .27

1. Introduction

   This taxonomy consists of a large number of parameters that are
   considered useful for describing the communication requirements of
   LSMAs. To describe a particular application, each parameter would be
   assigned a value. Typical ranges of values are given wherever
   possible.  Failing this, the type of any possible values is given.
   The parameters are collected into ten or so higher level categories,
   but this is purely for convenience.

   The parameters are pitched at a level considered meaningful to
   application programmers. However, they describe communications not
   applications - the terms '3D virtual world', or 'shared TV' might
   imply communications requirements, but they don't accurately describe
   them.  Assumptions about the likely mechanism to achieve each
   requirement are avoided where possible.

   While the parameters describe communications, it will be noticed that
   few requirements concerning routing etc. are apparent. This is
   because applications have few direct requirements on these second
   order aspects of communications. Requirements in these areas will
   have to be inferred from application requirements (e.g. latency).





Bagnall, et al.              Informational