rfc2729.txt

RFC 的详细文档！

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
      heterogeneity is going to be most marked

   4. It is a step towards standardization of the way LSMAs define their
      communications requirements. This could lead to standard APIs
      between applications and protocol adaptation middleware

   5. Identification of limitations in current Internet technology for
      LSMAs to be added to the LSMA limitations memo [limitations]

   6. Identification of gaps in Internet Engineering Task Force (IETF)
      working group coverage

   This approach is intended to complement that used where application
   scenarios for Distributed Interactive Simulation (DIS) are proposed
   in order to generate network design metrics (values of communications
   parameters). Instead of creating the communications parameters from
   the applications, we try to imagine applications that might be
   enabled by stretching communications parameters.

2. Definition of Sessions

   The following terms have no agreed definition, so they will be
   defined for this document.

   Session
      a happening or gathering consisting of flows of information
      related by a common description that persists for a non-trivial
      time (more than a few seconds) such that the participants (be they
      humans or applications) are involved and interested at
      intermediate times.  A session may be defined recursively as a
      super-set of other sessions.

   Secure session
      a session with restricted access




Bagnall, et al.              Informational                      [Page 3]

RFC 2729         Taxonomy of Communication Requirements    December 1999


   A session or secure session may be a sub and/or super set of a
   multicast group. A session can simultaneously be both a sub and a
   super-set of a multicast group by spanning a number of groups while
   time-sharing each group with other sessions.

3. Taxonomy

3.1 Summary of Communications Parameters

   Before the communications parameters are defined, typed and given
   worst-case values, they are simply listed for convenience. Also for
   convenience they are collected under classification headings.

      Reliability  . . . . . . . . . . . . . . . . . . . . . . 3.2.1
         Packet loss . . . . . . . . . . . . . . . . . . . . 3.2.1.1
            Transactional
            Guaranteed
            Tolerated loss
            Semantic loss
         Component reliability . . . . . . . . . . . . . . . 3.2.1.2
            Setup fail-over time
            Mean time between failures
            Fail over time during a stream
      Ordering . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2
         Ordering type
      Timeliness . . . . . . . . . . . . . . . . . . . . . . . 3.2.3
         Hard Realtime
         Synchronicity
         Burstiness
         Jitter
         Expiry
         Latency
         Optimum bandwidth
         Tolerable bandwidth
         Required by time and tolerance
         Host performance
         Fair delay
         Frame size
         Content size
      Session Control  . . . . . . . . . . . . . . . . . . . . 3.2.4
         Initiation
         Start time
         End time
         Duration
         Active time
         Session Burstiness
         Atomic join
         Late join allowed ?



Bagnall, et al.              Informational                      [Page 4]

RFC 2729         Taxonomy of Communication Requirements    December 1999


         Temporary leave allowed ?
         Late join with catch-up allowed ?
         Potential streams per session
         Active streams per sessions
      Session Topology . . . . . . . . . . . . . . . . . . . . 3.2.5
         Number of senders
         Number of receivers
      Directory  . . . . . . . . . . . . . . . . . . . . . . . 3.2.6
         Fail-over time-out (see Reliability: fail-over time)
         Mobility
      Security . . . . . . . . . . . . . . . . . . . . . . . . 3.2.7
         Authentication strength
         Tamper-proofing
         Non-repudiation strength
         Denial of service
         Action restriction
         Privacy
         Confidentiality
         Retransmit prevention strength
         Membership criteria
         Membership principals
         Collusion prevention
         Fairness
         Action on compromise
      Security dynamics  . . . . . . . . . . . . . . . . . . . 3.2.8
         Mean time between compromises
         Compromise detection time limit
         compromise recovery time limit
      Payment & Charging . . . . . . . . . . . . . . . . . . . 3.2.9
         Total Cost
         Cost per time
         Cost per Mb

3.2 Definitions, types and strictest requirements

   The terms used in the above table are now defined for the context of
   this document. Under each definition, the type of their value is
   given and where possible worst-case values and example applications
   that would exhibit this requirement.

   There is no mention of whether a communication is a stream or a
   discrete interaction. An attempt to use this distinction as a way of
   characterizing communications proved to be remarkably unhelpful and
   was dropped.







Bagnall, et al.              Informational                      [Page 5]

RFC 2729         Taxonomy of Communication Requirements    December 1999


3.2.1 Types

   Each requirement has a type. The following is a list of all the types
   used in the following definitions.

   Application Benchmark

      This is some measure of the processor load of an application, in
      some architecture neutral unit. This is non-trivial since the
      processing an application requires may change radically with
      different hardware, for example, a video client with and without
      hardware support.

   Bandwidth Measured in bits per second, or a multiple of.

   Boolean

   Abstract Currency
      An abstract currency is one which is adjusted to take inflation
      into account. The simplest way of doing this is to use the value
      of a real currency on a specific date. It is effectively a way of
      assessing the cost of something in "real terms". An example might
      be 1970 US$. Another measure might be "average man hours".

   Currency - current local

   Data Size

   Date (time since epoch)

   Enumeration

   Fraction

   Identifiers
      A label used to distinguish different parts of a communication

   Integer

   Membership list/rule

   Macro
      A small piece of executable code used to describe policies

   Time






Bagnall, et al.              Informational                      [Page 6]

RFC 2729         Taxonomy of Communication Requirements    December 1999


3.2.2 Reliability

3.2.2.1 Packet Loss

   Transactional

      When multiple operations must occur atomically, transactional
      communications guarantee that either all occur or none occur and a
      failure is flagged.

      Type:                  Boolean
      Meaning:               Transactional or Not transaction
      Strictest Requirement: Transactional
      Scope:                 per stream
      Example Application:   Bank credit transfer, debit and credit must
                             be atomic.
      NB:                    Transactions are potentially much more
                             complex, but it is believed this is
                             an application layer problem.

   Guaranteed

      Guarantees communications will succeed under certain conditions.

      Type:                  Enumerated
      Meaning:               Deferrable - if communication fails it will
                             be deferred until a time when it will be
                             successful.
                             Guaranteed - the communication will succeed
                             so long as all necessary components are
                             working.
                             No guarantee - failure will not be
                             reported.
      Strictest Requirement: Deferrable
      Example Application:   Stock quote feed - Guaranteed
      Scope:                 per stream
      NB:                    The application will need to set parameters