Taxonomy of Communication Requirements for Large-scale Multicast Applications
RFC 2729

Document Type RFC - Informational (December 1999; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2729 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          P. Bagnall
Request for Comments: 2729                                     R. Briscoe
Category: Informational                                        A. Poppitt
                                                                       BT
                                                            December 1999

                 Taxonomy of Communication Requirements
                 for Large-scale Multicast Applications

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   The intention of this memo is to define a classification system for
   the communication requirements of any large-scale multicast
   application (LSMA). It is very unlikely one protocol can achieve a
   compromise between the diverse requirements of all the parties
   involved in any LSMA. It is therefore necessary to understand the
   worst-case scenarios in order to minimize the range of protocols
   needed. Dynamic protocol adaptation is likely to be necessary which
   will require logic to map particular combinations of requirements to
   particular mechanisms.  Standardizing the way that applications
   define their requirements is a necessary step towards this.
   Classification is a first step towards standardization.

Bagnall, et al.              Informational                      [Page 1]
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                      [Page 2]
RFC 2729         Taxonomy of Communication Requirements    December 1999

   The taxonomy is likely to be useful in a number of ways:

   1. Most simply, it can be used as a checklist to create a
      requirements statement for a particular LSMA. Example applications
      will be classified [bagnall98] using the taxonomy in order to
      exercise (and improve) it

   2. Because strictest requirement have been defined for many
      parameters, it will be possible to identify worst case scenarios
      for the design of protocols

   3. Because the scope of each parameter has been defined (per session,
      per receiver etc.), it will be possible to highlight where
Show full document text