home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-pullen-lame-00.txt < prev    next >
Text File  |  1996-09-23  |  13KB  |  297 lines
  1. INTERNET DRAFT                                  J.M.Pullen
  2.                                                   George Mason U.
  3.                                                 M.Myjak
  4.                                                   U.of Central Florida
  5.                                                 C.Bouwens
  6.                                                   SAIC, Inc.
  7.                                                 20 September 1996
  8.                                                 Expire in six months
  9.  
  10.  
  11.     Limitations of Internet Protocol Suite for Distributed Simulation
  12.                in the Large Multicast Environment
  13.                    <draft-pullen-lame-00.txt>
  14.  
  15. Status of this Memo
  16.  
  17.      This document is an Internet-Draft.  Internet-Drafts are working
  18.      documents of the Internet Engineering Task Force (IETF), its
  19.      areas, and its working groups.  Note that other groups may also
  20.      distribute working documents as Internet-Drafts.
  21.  
  22.      Internet-Drafts are draft documents valid for a maximum of six
  23.      months and may be updated, replaced, or obsoleted by other
  24.      documents at any time.  It is inappropriate to use Internet-
  25.      Drafts as reference material or to cite them other than as
  26.      ``work in progress''
  27.  
  28.      To learn the current status of any Internet-Draft, please check
  29.      the ``1id-abstracts.txt'' listing contained in the Internet-
  30.      Drafts Shadow Directories on ftp.is.co.za (Africa),
  31.      nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  32.      ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  33.  
  34.  
  35. Abstract
  36.  
  37.      The characteristics of distributed simulation in the Large 
  38.      Multicast Environment are described.  Mechanics and rates
  39.      of data exchange are elaborated.  Required network
  40.      characteristics are described.  Using this information,
  41.      additional capabilities needed to use the Internet Protocol 
  42.      Suite for support of large-scale distributed simulation
  43.      are enumerated.
  44.  
  45.  
  46.  
  47.  
  48.  
  49. 1.  The Large Multicast Environment
  50.  
  51.      The Large Multicast User's Group (LAMUG) was formed to create a 
  52.      consensus-based requirement for Internet Protocols to support
  53.      Distributed Interactive Simulation (DIS), its successor the High 
  54.      Level Architecture for simulation (HLA), and related applications.  
  55.      The applications are characterized by the need to distribute a 
  56.      real-time application over a shared wide-area network in a 
  57.      scalable manner such that numbers of hosts from a few to tens of 
  58.      thousands are able to interchange state data with sufficient
  59.      reliability and timeliness to sustain a three-dimensional virtual, 
  60.      visual environment containing large numbers of moving objects.  
  61.      Each such host may simulate a number of battlefield entities
  62.      that may be as few as one or an many as thousands.  The network 
  63.      supporting such a system necessarily will be capable of multicast.
  64.  
  65.      Distributed Interactive Simulation is the name of a family of 
  66.      protocols used to exchange information about a virtual 
  67.      environment among hosts in a distributed system that are 
  68.      simulating the behavior of objects in that environment.  The 
  69.      objects are capable of physical interactions and can sense each 
  70.      other by visual and other means (infrared, etc.).  DIS was 
  71.      developed by the U.S. Department of Defense (DoD) to implement 
  72.      system for military training, rehearsal, and other purposes.
  73.      DIS standards are used for the same purposes by defense and other 
  74.      organizations in other countries as well.  More information on DIS 
  75.      can be found in the references.
  76.  
  77.      The feature of DIS that drives network requirements is that it 
  78.      is intended to work with output to and input from humans across 
  79.      distributed simulators at both local and distant locations in real 
  80.      time.  This places tight limits on latency between hosts.  It also 
  81.      means that any practical network will require multicasting to 
  82.      implement the required distribution of large amounts of data to all 
  83.      participating simulators.  Large DIS configurations are expected to 
  84.      place hosts in multicast groups based on sharing the same sensor 
  85.      inputs in the virtual environment.  This can mean a need for 
  86.      hundreds of multicast groups where objects may move between groups 
  87.      in large numbers at high rates.
  88.  
  89.      DIS real time flow consists of packets of length around 2000 
  90.      bits at rates from .2 per second per simulator to 15 per second 
  91.      per simulator.  This information is intentionally redundant and
  92.      normally is transmitted with a best-effort transport protocol 
  93.      (UDP), and in some cases also is compressed.  Required accuracy 
  94.      both of latency and of physical simulation varies with the 
  95.      intended purpose but generally must be at least sufficient to 
  96.      satisfy human perception, for example in tightly coupled
  97.  
  98.  
  99.  
  100.  
  101.      simulations such as high performance aircraft maximum acceptable 
  102.      latency between applications end-to-end is 100 milliseconds between 
  103.      any two hosts.  At relatively rare intervals events (e.g. 
  104.      collisions between battlefield entities) may occur which require 
  105.      reliable transmission of some data on a unicast basis, to any other 
  106.      host in the system.  Other protocols supporting the DIS environment 
  107.      (e.g. Network Time and Simulation Management) may require 
  108.      information transport in addition to the flow of DIS entity-state 
  109.      data.
  110.  
  111.      DoD has a goal to build DIS systems with up to 100,000 simulated 
  112.      objects, many of them computer-generated forces that run with 
  113.      minimal human intervention, acting as opposing force or simulating 
  114.      friendly forces that are not available to participate.  DoD would 
  115.      like to carry out such simulations using a shared WAN.  Beyond 
  116.      DoD many people see a likelihood that DIS-like capabilities may 
  117.      be commercialized as entertainment.  The scope of such an 
  118.      entertainment system is hard to predict but conceivably could be 
  119.      larger than the DoD goal of 100,000.
  120.  
  121.      The High Level Architecture (HLA) is a development beyond DIS 
  122.      that aims at bringing DIS and other forms of distributed 
  123.      simulation into a unifying system paradigm.  Thus HLA has 
  124.      networking requirements at least as demanding as DIS.  HLA is 
  125.      still under development, therefore this document will focus on 
  126.      the requirements of DIS.
  127.  
  128.  
  129. 2.  DIS network requirements.
  130.  
  131.      a.  real-time packet delivery, with a small fraction (less than 
  132.      two percent), of packets exceed an established latency, in no case 
  133.      more than a few hundred milliseconds, in a shared network
  134.  
  135.      b.  multicasting with thousands of multicast groups that can 
  136.      sustain join/leave in less than one second at rates of hundreds 
  137.      of join/leaves per second
  138.  
  139.      c.  support for secure networking, needed for classified military 
  140.      simulations
  141.  
  142.      d.  A high degree of flexibility in constructing networks depending
  143.      on the working environment, such as leased lines, ISDN, ATM, and/or 
  144.      mobile links on instrumented ranges.
  145.  
  146.  
  147.  
  148.  
  149.  
  150. 3.  Internet Protocol Suite facilities needed and not yet available for 
  151. large-scale DIS in shared networks.  
  152.  
  153.      These derive from the need for real-time multicast with established 
  154.      quality of service:
  155.  
  156.      a.  Requirement: resource reservation available in production 
  157.      systems.  Work needed: RSVP seems to be on a path to achieving 
  158.      this, however a mechanism is needed to group streams such that 
  159.      multiple multicast groups can share the same network capacity.
  160.      The RSVP Working Group recognizes a need for this and is 
  161.      planning to consider it after they complete a draft standard
  162.      based on their current work (experimental RSVP version 12). 
  163.  
  164.      Note: Some current DIS networks allow for quality of service in 
  165.      terms of reserved/prioritized bandwidth and/or minimal delay 
  166.      (ST-2 or RSVP) or private dial-up links with bandwidth on 
  167.      demand and compression (ISDN), but no commercial, production
  168.      system using open standards is available to meet the performance
  169.      requirements projected above.
  170.  
  171.  
  172.      b.  Requirement: resource-sensitive routing to be used with the 
  173.      resource reservation mechanism.  Work needed: a routing protocol
  174.      for IP multicast, derived from the current versions (DVMRP or 
  175.      MOSPF) but sensitive to resource requirements.  A new protocol
  176.      called Quality of Service Open Shortest Path First (QOSPF) has
  177.      been proposed and a working group is being formed to investigate 
  178.      its potential.  QOSPF will work with RSVP.  It is likely to 
  179.      require at least two years to develop such a protocol. 
  180.  
  181.      c.  Requirement: IP multicast that is capable of taking advantage 
  182.      of link-layer multicast (such as ATM) for packet replication across 
  183.      multiple logical IP subnets (LIS). Work needed: Extend or replace 
  184.      the current standards-track IP multicast over ATM multicast, which
  185.      uses a Multicast Address Resolution Server (MARS) to resolve the
  186.      fact that ATM provides no mechanism to distribute IP multicast
  187.      group information.  It only works within an LIS and hence will not
  188.      support high-performance, wide-area, shared-use IP/ATM networks
  189.      in multicast mode.  An approach to solving this problem has been
  190.      developed in the DARPA Real time Information Transport Network 
  191.      (RITN) program and was briefed to the IETF in December, 1995 but
  192.      no working group is pursuing it.
  193.  
  194.      d.  Requirement: a hybrid transport protocol that can support best-
  195.      effort multicast of most data, lightweight reliable multicast of 
  196.      critical reference data, and reliable unicast of occasional data.
  197.      Without such a protocol the application must become responsible
  198.      for reliability of transport in the real time multicast 
  199.      environment. Work needed:  A Selectively Reliable Transport 
  200.      Protocol (SRTP) has been proposed by the Distributed Interactive 
  201.      Simulation Communications and Security (DIS-CAS) working group.  
  202.      This work needs to be brought into the IETF and pursued there.  A 
  203.      new IETF working group on multicast transport has been proposed.  
  204.      Such a group would provide a logical home for SRTP development.
  205.  
  206.  
  207.  
  208.  
  209.      e.  Requirement: network management for DIS systems.  Work needed: 
  210.      Create a DIS/HLA Management Information Base (MIB) for use with the 
  211.      Internet standard Simple Network Management Protocol (SNMP).  This
  212.      could be undertaken by the LAMUG.
  213.  
  214.      f.  Requirement: a session protocol to start, pause, and stop a DIS 
  215.      exercise over an IP network.  Work needed: a new subgroup of the 
  216.      Multiparty Multimedia Session Control working group to investigate 
  217.      use of that session protocol for DIS/HLA.
  218.  
  219.      g.  Requirement: an integrated security architecture. Work needed:
  220.      Investigate use of the IPv6 security architecture to meet this  
  221.      need.
  222.  
  223.  
  224. 4.  References
  225.  
  226.    [1] Symington et. al, "Modeling and Simulation Requirements for IPng", 
  227.        RFC 1667, August 1994
  228.  
  229.    [2] DIS Steering Committee, "The DIS Vision", Institute for 
  230.        Simulation and Training, University of Central Florida, May 1994
  231.  
  232.    [3] IEEE 1278.1-1995, Standard for Distributed Interactive Simulation 
  233.        Application Protocols 
  234.  
  235.    [4] IEEE 1278.2-1995, Standard for Distributed Interactive Simulation 
  236.        Communication services and Profiles
  237.  
  238.    [5] Deering, "Host Requirements for IP Multicasting", RFC 1112, 
  239.        August 1989
  240.  
  241.    [6] Case et. al., "Simple Network Management Protocol", RFC 1067, 
  242.        May 1990 
  243.  
  244.    [7] Moy, "MOSPF: Analysis and Experience", RFC1585, March 1994
  245.  
  246.    [8] Estrin et. al., "Protocol Independent Multicast-Sparse Mode",
  247.        work in progress (draft-ietf-idmr-pim-sm-spec-06), September 1996
  248.  
  249.    [9] Pusateri, "Distance Vector Multicast Routing Protocol",
  250.        work in progress (draft-ietf-idmr-dvmrp-v3-03), September 1996
  251.  
  252.    [10] Atkinson, "IPv6 Security Architecture", work in progress
  253.         (draft-ietf-ipngwg-sec-00), March 1996
  254.  
  255.    [11] Braden et. al., "Resource Reservation Protocol Version 1 Functional 
  256.         Specification", work in progress (draft-ietf-rsvp-policy-arch-12)
  257.  
  258.    [12] Zhang et. al., "Quality of Service Extensions to OSPF", work in 
  259.         progress (Internet Draft) June, 1996
  260.  
  261.    [13] Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM
  262.         Networks", work in progress (draft-ietf-ipatm-ipmc-12), 
  263.         February 1996
  264.  
  265.  
  266.  
  267.  
  268.    [14] Bormann et. al., "Simple Conference Control Protocol", work in 
  269.         progress (draft-ietf-mmusic-sccp-00), June 1996
  270.  
  271.    [15] Pullen et. al. "Implementation of A Selectively Reliable Transport 
  272.         Protocol for DIS", Proceedings of the 14th Distributed Interactive 
  273.         Simulation Workshop, March 1996
  274.  
  275. 5.  Authors' Addresses
  276.  
  277.   J. Mark Pullen
  278.   Computer Science/4A5
  279.   George Mason University
  280.   Fairfax, VA 22032
  281.   mpullen@gmu.edu
  282.  
  283.   Michael Myjak
  284.   Institute for Simulation and Training
  285.   University of Central Florida
  286.   3800 Progress Drive
  287.   Orlando, FL  32826
  288.   mmyjak@ist.ucf.edu
  289.  
  290.   Christina Bouwens
  291.   SAIC Inc.
  292.   Orlando FL
  293.   chris_bouwens@cpqm.saic.com
  294.  
  295.  
  296.  
  297.