idnits 2.17.1 draft-ietf-lsma-limitations-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 16 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 March 1997) is 9887 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT J.M.Pullen 2 Expiration: 25 September 1997 George Mason U. 3 M.Myjak 4 U.of Central Florida 5 C.Bouwens 6 SAIC, Inc. 7 24 March 1997 9 Limitations of Internet Protocol Suite for Distributed Simulation 10 in the Large Multicast Environment 12 draft-ietf-lsma-limitations-01.txt 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check 28 the ``1id-abstracts.txt'' listing contained in the Internet- 29 Drafts Shadow Directories on ftp.is.co.za (Africa), 30 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 31 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 The Large-Scale Multicast Applications (LSMA) working group was chartered to 36 produce two Internet-Drafts aimed at a consensus-based development of the 37 Internet protocols to support large scale, real-time distributed simulation. 38 This draft defines aspects of the Internet protocols that LSMA has found may 39 need further development in order to meet that goal. 41 1. The Large Multicast Environment 43 The Large-Scale Multicast Applications working group (LSMA) was formed 44 to create a consensus-based requirement for Internet Protocols to support 45 Distributed Interactive Simulation (DIS), its successor the High Level 46 Architecture for simulation (HLA), and related applications. The 47 applications are characterized by the need to distribute a real-time 48 application over a shared wide-area network in a scalable manner such that 49 numbers of hosts from a few to tens of thousands are able to interchange 50 state data with sufficient reliability and timeliness to sustain a three- 51 dimensional virtual, visual environment containing large numbers of moving 52 objects. The network supporting such an system necessarily will be capable 53 of multicast. 55 Distributed Interactive Simulation is the name of a family of protocols 56 used to exchange information about a virtual environment among 57 hosts in a distributed system that are simulating the behavior of objects 58 in that environment. The objects are capable of physical interactions 59 and can sense each other by visual and other means (infrared, etc.). 60 DIS was developed by the U.S. Department of Defense (DoD) to 61 implement system for military training, rehearsal, and other purposes. 62 More information on DIS can be found in the references. 64 The feature of DIS that drives network requirements is that it is 65 intended to work with output to and input from humans across 66 distributed simulators in real time. This places tight limits on latency 67 between hosts. It also means that any practical network will require 68 multicasting to implement the required distribution of all data to all 69 participating simulators. Large DIS configurations are expected to 70 group hosts on multicast groups based on sharing the same sensor 71 inputs in the virtual environment. This can mean a need for hundreds 72 of multicast groups where objects may move between groups in large 73 numbers at high rates. The overall total data rate (the sum of all 74 multicast groups) is bounded, but the required data rate in any particular 75 group cannot be predicted, and may change quite rapidly during the 76 simulation. 78 DIS real time flow consists of packets of length around 2000 bits at 79 rates from .2 per second per simulator to 15 per second per simulator. 80 This information is intentionally redundant and is normally 81 transmitted with a best-effort transport protocol (UDP), and in some 82 cases also is compressed. Required accuracy both of latency and of 83 physical simulation varies with the intended purpose but generally 84 must be at least sufficient to satisfy human perception, for example in 85 tightly coupled simulations such as high performance aircraft 86 maximum acceptable latency is 100 milliseconds between any two 87 hosts. At relatively rare intervals events (e.g. collisions) may occur 88 which require reliable transmission of some data on a unicast basis, to 89 any other host in the system. 91 DoD has a goal to build DIS systems with up to 100,000 simulated 92 objects, many of them computer-generated forces that run with 93 minimal human intervention, acting as opposing force or simulating 94 friendly forces that are not available to participate. DoD would like to 95 carry out such simulations using a shared WAN. Beyond DoD many 96 people see a likelihood that DIS-like capabilities may be 97 commercialized as entertainment. The scope of such an entertainment 98 system is hard to predict but conceivably could be larger than the DoD 99 goal of 100,000. 101 The High Level Architecture (HLA) is a development beyond DIS that aims 102 at bringing DIS and other forms of distributed simulation into a unifying 103 system paradigm. Thus HLA has network requirements at least as 104 demanding as DIS. HLA is still under development, however it is clear that 105 its network requirements will be similar to those of DIS because it must 106 achieve the same functions as DIS. 108 2. DIS network requirements. 110 a. real-time packet delivery, with low packet loss (less than 2%), 111 predictable latency on the order of a few hundred milliseconds, after 112 buffering to account for jitter (variation of latency) such that less 113 than 2% of packets fail to arrive within the specified latency, in 114 a shared network 116 b. multicasting with thousands of multicast groups that can sustain 117 join/leave in less than one second at rates of hundreds of join/leaves 118 per second 120 c. multicasting using a many-to-many paradigm in which 90% or more 121 of the group members act as receivers and senders within any given 122 multicast group 124 d. support for resource reservation because of the impracticality 125 of over-provisioning the WAN and the LAN; it is important to be able 126 to reserve an overall capacity that can be dynamically allocated among 127 the multicast groups 129 e. support for secure networking, needed for classified military 130 simulations 132 3. Internet Protocol Suite facilities needed and not yet available 133 for large-scale DIS in shared networks. These derive from the need 134 for real-time multicast with established quality of service in a 135 shared network. 137 3.1 Resource reservation available in production systems 139 The standardized portion of the Internet protocol suite has featured 140 only best effort protocols, which do not entail a commitment on the 141 part of the network to perform particular quality of service. It is 142 likely that simulation exercises using the Internet protocols would 143 need to reserve a maximum overall networking capacity that would 144 could be dynamically shared among various groups of information 145 flows. Information flows will need to be dynamically grouped in 146 relation to multicast groups, regions of interest, or some possibly 147 some other paradigm as the exercise evolves. 149 The Resource reSerVation Protocol (RSVP) is aimed at providing setup 150 and flow-based information for managing information flows at pre- 151 committed performance levels. This capability is generally seen as 152 needed in real-time systems such as the HLA Run Time Infrastructure 153 (RTI). However, RSVP is not fully available in production routers, 154 nor has the current experimental version been approved as a Proposed 155 Standard protocol within the IETF. The current experimental version of 156 RSVP that is available in some routers does not support aggregation 157 of reservation resources for groups of flows, nor does it support 158 highly dynamic flow control changes. 160 3.2 Resource-sensitive multicast routing 162 RSVP provides support only for communicating specifications of the 163 required information flows between simulators and the network, and 164 within the network. Distributing routing information among the 165 routers within the network is a different function altogether, 166 performed by routing protocols such as Multicast Open Shortest 167 Path First (MOSPF). In order to make the overall network function, 168 it may be necessary to have a routing protocol that determines paths 169 through the network within the context of a quality of service 170 requirement. An example is the proposed Quality Of Service Path 171 First (QOSPF) routing protocol. 173 3.3 IP multicast that is capable of taking advantage of all 174 multicast-capable data link protocols 176 Multicast takes advantage of the efficiency obtained when the network 177 can recognize and replicate information packets that are destined to a 178 group of locations. Under these circumstances, the network can take on 179 the job of providing duplicate copies to all destinations, thereby 180 greatly reducing the amount of information flowing into and through 181 the network. 183 When IP multicast operates over Ethernet in a LAN and all subnets are 184 interconnected using the Internet Group Management Protocol (IGMP), 185 this is exactly what happens. However, with the new high performance 186 wide-area technology Asynchronous Transfer Mode (ATM), the ability to 187 take advantage of data link layer multicast capability is not yet 188 available beyond a single LIS. This appears to be due to the fact 189 that (1) the switching models of IP and ATM are sufficiently different 190 that this capability will require a rather complex solution, and (2) 191 there has been no clear application requirement for IP multicast over 192 ATM multicast that provides for packet replication across multiple Logical 193 IP Subnets (LIS). 195 3.4 A hybrid transmission protocol 197 In general the Internet protocol suite uses the Transmission Control 198 Protocol (TCP) for reliable end-to-end transport, and the User 199 Datagram Protocol (UDP) for best-effort end-to-end transport, 200 including all multicast transport services. The design of TCP 201 is only capable of unicast use. 203 In the HLA environment, three different transport needs have 204 been identified: best-effort multicast of most data, lightweight 205 reliable multicast of critical reference data, and low-latency, 206 reliable unicast of occasional data among arbitrary members of 207 the multicast group. All this takes place with in the same 208 large-scale multicasting environment. Cohen has shown the need 209 for these capabilities, while Pullen and Laviano have showed 210 the value of integrating these three transport types into a 211 single Selectively Reliable Transmission Protocol (SRTP) for 212 DIS multicast. Recently the IETF has seen proposals for several 213 reliable multicast transport protocols. A general issue with 214 reliable transport for multicast is the congestion problem 215 associated with delivery acknowledgments, which has made 216 real-time reliable multicast transport infeasible to date. 217 Of the roughly 15 attempts to develop a reliable multicast 218 transport, all have shown to have some problem relating to 219 datagram receipt acknowledgments (ACK), or requesting datagram 220 retransmissions through the selected use of negative acknowledgments 221 (NAK). Approaches involving distributed logging seem to hold 222 promise for the distributed simulation application. In any 223 event, its seems clear that there is not likely to be a single 224 solution for reliable multicast, but rather a number of solutions 225 tailored to different application domains. 227 3.5 Network management for distributed systems 229 Coordinated, integrated network management is one of the more 230 difficult aspects of a large distributed simulation exercise. The 231 Internet network management techniques have been used successfully to 232 support the growth of the Internet for the past several years. The 233 technique is based on a primitive called a Management Information Base 234 (MIB) being periodically polled at very low data rates. The receiver 235 of the poll is called an Agent and is collocated with the remote 236 process being monitored. The agent is simple so as to not absorb 237 very many resources. The requesting process is called a Manager, 238 and is typically located elsewhere on a separate workstation. The 239 Manager communicates to all of the agents in a given domain using 240 the Simple Network Management Protocol (SNMP). It appears that SNMP 241 is well adapted to the purpose of distributed simulation management, 242 in addition to managing the underlying simulation network resources. 243 Creating a standard distributed simulation MIB format would make it 244 possible for the simulation community to make use of the collection 245 of powerful, off-the-shelf network management tools that have been 246 created around SNMP. 248 3.6 A session protocol to start, pause, and stop a distributed 249 simulation exercise in an IP network 251 Coordinating start, stop, and pause of large distributed exercises 252 is a complex and difficult task. The IETF has developed the 253 Multiparty MUltimedia Session Control (MMUSIC) protocol which 254 serves a similar purpose for managing large scale multimedia 255 conferences. It is possible that MMUSIC's work could be adapted 256 to distributed simulation, although it was designed around a 257 multicast environment which requires principally a one-to-many 258 transport service. If MMUSIC adaptation does not prove possible, 259 surely the lessons learned in developing MMUSIC could help to 260 develop a similar protocol for distributed simulation exercises. 262 3.7 An integrated security architecture 264 A shortcoming of the current Internet Protocol (IPv4) implementation 265 is the lack of integrated security. The new IPv6 protocol requires 266 implementers to follow an integrated security architecture that 267 provides the required integrity, authenticity, and confidentiality 268 for use of the Internet by communities with stringent security 269 demands, such as the financial community. The possibility 270 that the IPv6 security architecture may meet military needs, 271 when combined either with military cryptography or government- 272 certified commercial cryptography, merits further study. 274 4. References 276 Cohen, D., "Back to Basics", Proceedings of the 11th Workshop on 277 Standards for Distributed Interactive Simulation, 1994 279 DIS Steering Committee, "The DIS Vision", Institute for Simulation 280 and Training, University of Central Florida, May 1994 282 IEEE 1278.1-1995, Standard for Distributed Interactive Simulation - 283 Application Protocols 285 IEEE 1278.2-1995, Standard for Distributed Interactive Simulation - 286 Communication services and Profiles 288 Pullen, J. and V. Laviano, "A Selectively Reliable Transport 289 Protocol for Distributed Interactive Simulation" Proceedings 290 of the 13th Workshop on Standards for Distributed Interactive 291 Simulation, 1995 293 RFC1667, "Modeling and Simulation Requirements for IPng" 294 August 1994 296 Seidensticker, S., W. Smith and M. Myjak, 297 draft-ietf-lsma-scenarios-00.txt, "Scenarios and Appropriate 298 Protocols for Distributed Interactive Simulation", work in progress 299 (companion Internet Draft) 301 Zhang, Z., C. Sanchez, W. Salkecicz, and E. Crawley, 302 draft-zhang-qos-ospf-00.txt, "Quality of Service Path 303 First Routing Protocol", work in progress 305 5. Authors' Addresses 307 J. Mark Pullen 308 Computer Science/4A5 309 George Mason University 310 Fairfax, VA 22032 312 Michael Myjak 313 Institute for Simulation and Training 314 University of Central Florida 315 Orlando, FL 317 Christina Bouwens 318 ASSET Group, SAIC Inc. 319 Orlando FL 321 Expiration: 25 September 1997