idnits 2.17.1 draft-ietf-lsma-limitations-04.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-26) 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 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 494 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 4 instances of lines with control characters in the document. 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 (11 November 1998) is 9298 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) == Unused Reference: 'SPW94' is defined on line 444, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CSTH95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cohe94' -- Possible downref: Non-RFC (?) normative reference: ref. 'DIS94' -- Possible downref: Non-RFC (?) normative reference: ref. 'DMSO96' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE95a' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE95b' == Outdated reference: A later version (-03) exists of draft-miller-mftp-spec-02 -- Possible downref: Normative reference to a draft: ref. 'MRTW97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Mont97' -- Possible downref: Non-RFC (?) normative reference: ref. 'PuLa95' -- Possible downref: Non-RFC (?) normative reference: ref. 'PuWh95' -- Possible downref: Non-RFC (?) normative reference: ref. 'PLM97' ** Downref: Normative reference to an Informational RFC: RFC 1667 (ref. 'SPW94') == Outdated reference: A later version (-03) exists of draft-ietf-lsma-scenarios-00 -- Possible downref: Normative reference to a draft: ref. 'SSM96' -- Possible downref: Normative reference to a draft: ref. 'ZSSC97' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT J.M.Pullen 2 Expiration in six months George Mason U. 3 M.Myjak 4 The Virtual Workshop 5 C.Bouwens 6 SAIC 7 11 November 1998 9 Limitations of Internet Protocol Suite for Distributed Simulation 10 in the Large Multicast Environment 12 draft-ietf-lsma-limitations-04 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 areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 The Large-Scale Multicast Applications (LSMA) working group was 35 chartered to produce Internet-Drafts aimed at a consensus-based 36 development of the Internet protocols to support large scale 37 multicast applications including real-time distributed simulation. 38 This draft defines services that LSMA has found to be required, and 39 aspects of the Internet protocols that LSMA has found to need further 40 development in order to meet these requirements. 42 1. The Large Multicast Environment 44 The Large-Scale Multicast Applications working group (LSMA) was 45 formed to create a consensus-based requirement for Internet Protocols 46 to support Distributed Interactive Simulation (DIS) [DIS94], its 47 successor the High Level Architecture for simulation (HLA) [DMSO96], 48 and related applications. The applications are characterized by the 49 need to distribute a real-time applications over a shared wide-area 50 network in a scalable manner such that numbers of hosts from a few to 51 tens of thousands are able to interchange state data with sufficient 52 reliability and timeliness to sustain a three-dimensional virtual, 53 visual environment containing large numbers of moving objects. The 54 network supporting such an system necessarily will be capable of 55 multicast [IEEE95a,IEEE95b]. 57 Distributed Interactive Simulation is the name of a family of 58 protocols used to exchange information about a virtual environment 59 among hosts in a distributed system that are simulating the behavior 60 of objects in that environment. The objects are capable of physical 61 interactions and can sense each other by visual and other means 62 (infrared, etc.). DIS was developed by the U.S. Department of 63 Defense (DoD) to implement systems for military training, rehearsal, 64 and other purposes. More information on DIS can be found in [SSM96]. 66 The feature of distributed simulation that drives network 67 requirements is that it is intended to work with output to and input 68 from humans across distributed simulators in real time. This places 69 tight limits on latency between hosts. It also means that any 70 practical network will require multicasting to implement the required 71 distribution of all data to all participating simulators. Large 72 distributed simulation configurations are expected to group hosts on 73 multicast groups based on sharing the same sensor inputs in the 74 virtual environment. This can mean a need for thousands of multicast 75 groups where objects may move between groups in large numbers at high 76 rates. Because the number of simulators is known in advance and 77 their maximum output rate in packets per second and bits per second 78 is specified, the overall total data rate (the sum of all multicast 79 groups) is bounded. However the required data rate in any particular 80 group cannot be predicted, and may change quite rapidly during the 81 simulation. 83 DIS real time flow consists of packets of length around 2000 bits at 84 rates from .2 packets per second per simulator to 15 packets per 85 second per simulator. This information is intentionally redundant and 86 is normally transmitted with a best-effort transport protocol (UDP). 87 In some cases it also is compressed. Required accuracy both of 88 latency and of physical simulation varies with the intended purpose 89 but generally must be at least sufficient to satisfy human 90 perception. For example in tightly coupled simulations such as high 91 performance aircraft maximum acceptable latency is 100 milliseconds 92 between any two hosts. At relatively rare intervals events (e.g. 93 collisions) may occur which require reliable transmission of some 94 data, on a unicast basis, to any other host in the system. 96 The U.S. DoD has a goal to build distributed simulation systems with 97 up to 100,000 simulated objects, many of them computer-generated 98 forces that run with minimal human intervention, acting as opposing 99 force or simulating friendly forces that are not available to 100 participate. DoD would like to carry out such simulations using a 101 shared WAN. Beyond DoD many people see a likelihood that distributed 102 simulation capabilities may be commercialized as entertainment. The 103 scope of such an entertainment system is hard to predict but 104 conceivably could be larger than the DoD goal of 100,000. 106 The High Level Architecture (HLA) is a DoD development beyond DIS 107 that aims at bringing DIS and other forms of distributed simulation 108 into a unifying system paradigm. From a distributed systems 109 standpoint HLA is considerably more sophisticated than DIS. For 110 example attributes of distributed objects may be controlled by 111 different simulators. From the standpoint of the supporting network 112 the primary difference between HLA and DIS is that HLA does not call 113 for redundant transmission of object attributes; instead it specifies 114 a "Run Time Infrastructure" (RTI) that is responsible to transmit 115 data reliably, and may choose to do so by various means including 116 redundant transmission using best-effort protocols. It is reasonable 117 to say that any network that can meet the needs of DIS can support 118 HLA by DIS-like redundant transmission, however this approach ignores 119 the possibility that under HLA some mixture of redundant and reliable 120 transmission can make significantly better use of network resources 121 than is possible using DIS. While HLA, like DIS, does not specify 122 use of a multicasting network, it has similar requirements for 123 many-to-many transmission of object attributes at rates in excess of 124 one update per object per second that cannot be met without 125 multicasting. Further, HLA calls for transmission of semantically 126 organized data (for example, groups of objects with similar 127 capabilities such as tanks or aircraft) in this many-to-many context. 129 One solution that has been employed to deal with these challenges is 130 to aggregate the contents of many multicast groups into a single 131 multicast transmission [PuWh95, CSTH95]. Termed "dual-mode" or 132 "bi-level" multicast, this approach takes advantage of the fact that 133 although the amount of traffic in any particular multicast group can 134 vary greatly, the aggregate of all transmissions is bounded. If the 135 traffic is all aggregated into one large flow, an underlying ATM 136 network can create multicast SVCs with acceptable QoS to support the 137 requirement. It also bounds the network control problem of group 138 joins, in that the joins take place among dedicated collections of 139 routers and across the dedicated SVCs, rather than contending with 140 other LSMAs that may be sharing the same network. But it does this at 141 the cost of adding to the network a new, nonstandard aggregation 142 element that is a hybrid of the Internet and ATM protocols. We 143 address below the requirement to achieve such a result using a purely 144 IP network with aggregated reservation via RSVP. 146 The defense distributed simulation community has created a number of 147 multicast-capable networks for various simulated exercises, ranging 148 from tens to hundreds of simulated objects distributed across numbers 149 of sites ranging from two to twenty. As the number of objects has 150 increased they have found that building multicasting networks 151 potentially supporting thousands of simultaneous multicast groups 152 with large group change rates is a hard problem. This defense problem 153 is the precursor of similar problems that can be expected in 154 commercial networks. Therefore the following sections describe the 155 services required and the shortcomings that have been found in using 156 today's Internet protocols in providing these services, with the 157 intention of informing the IETF to enable it to produce protocols 158 that meet the needs in these areas. 160 2. Distributed Simulation (DIS and HLA) network service requirements. 162 a. real-time packet delivery, with low packet loss (less than 2%), 163 predictable latency on the order of a few hundred milliseconds, after 164 buffering to account for jitter (variation of latency) such that less 165 than 2% of packets fail to arrive within the specified latency, in a 166 shared network 168 b. multicasting with thousands of multicast groups that can support 169 join latencies of less than one second, at rates of hundreds 170 of joins per second 172 c. multicasting using a many-to-many paradigm in which 90% or more of 173 the group members act as receivers and senders within any given 174 multicast group 176 d. support for resource reservation; because of the impracticality of 177 over-provisioning the WAN and the LAN for large distributed 178 simulations, it is important to be able to reserve an overall 179 capacity that can be dynamically allocated among the multicast groups 181 e. support for a mixture of best-effort and reliable low-latency 182 multicast transport, where best-effort predominates in the mixture, 183 and the participants in the reliable multicast may be distributed 184 across any portion of the network 186 f. support for secure networking, in the form of per-packet 187 encryption and authentication needed for classified military 188 simulations 190 3. Internet Protocol Suite facilities needed and not yet available for 191 large-scale distributed simulation in shared networks: These derive 192 from the need for real-time multicast with established quality of 193 service in a shared network. (Implementation questions are not 194 included in this discussion. For example, it is not clear that 195 implementations of IP multicast exist that will support the required 196 scale of multicast group changes for LSMA, but that appears to be a 197 question of implementation, not a limitation of IP multicast.) 199 3.1 Large-scale resource reservation in shared networks 201 The Resource reSerVation Protocol (RSVP) is aimed at providing setup 202 and flow-based information for managing information flows at pre- 203 committed performance levels. This capability is generally seen as 204 needed in real-time systems such as the HLA RTI. Concerns have been 205 raised about the scalability of RSVP, and also about its ability to 206 support highly dynamic flow control changes. In terms of existing 207 RTI capabilities, the requirement in LSMA is for rapid change of 208 group membership, not for rapid change of group reservations. This 209 is because in existing RTIs the aggregate requirement for all groups 210 in a large scale distributed simulation is static. However the 211 current RSVP draft standard for LSMA does not support aggregation of 212 reservation resources for groups of flows and therefore does not meet 213 the needs of existing RTIs. Moreover, there is at least one RTI 214 development underway that intends to use individual, dynamic 215 reservations for large numbers of groups, and therefore will require 216 a dynamic resource reservation capability that scales to thousands 217 of multicast groups. 219 Further, RSVP provides support only for communicating specifications 220 of the required information flows between simulators and the network, 221 and within the network. Distributing routing information among the 222 routers within the network is a different function altogether, 223 performed by routing protocols such as Multicast Open Shortest Path 224 First (MOSPF). In order to provide effective resource reservation in 225 a large shared network function, it may be necessary to have a 226 routing protocol that determines paths through the network within the 227 context of a quality of service requirement. An example is the 228 proposed Quality Of Service Path First (QOSPF) routing protocol 229 [ZSSC97]. Unfortunately the requirement for resource-sensitive 230 routing will be difficult to define before LSMA networks are deployed 231 with RSVP. 233 3.2 IP multicast that is capable of taking advantage of all common 234 link layer protocols (in particular, ATM) 236 Multicast takes advantage of the efficiency obtained when the network 237 can recognize and replicate information packets that are destined to 238 a group of locations. Under these circumstances, the network can take 239 on the job of providing duplicate copies to all destinations, thereby 240 greatly reducing the amount of information flowing into and through 241 the network. 243 When IP multicast operates over Ethernet, IP multicast packets are 244 transmitted once and received by all receivers using Ethernet-layer 245 multicast addressing, avoiding replication of packets. 246 However, with wide-area Asynchronous Transfer Mode (ATM), 247 the ability to take advantage of data link layer multicast capability 248 is not yet available beyond a single Logical IP Subnet (LIS). This 249 appears to be due to the fact that (1) the switching models of IP and 250 ATM are sufficiently different that this capability will require a 251 rather complex solution, and (2) there has been no clear application 253 requirement for IP multicast over ATM multicast that provides for 254 packet replication across multiple LIS. Distributed simulation is an 255 application with such a requirement. 257 3.3 Hybrid transmission of best-effort and reliable multicast 259 In general the Internet protocol suite uses the Transmission Control 260 Protocol (TCP) for reliable end-to-end transport, and the User 261 Datagram Protocol (UDP) for best-effort end-to-end transport, 262 including all multicast transport services. The design of TCP is 263 only capable of unicast transmission. 265 Recently the IETF has seen proposals for several reliable multicast 266 transport protocols (see [Mont97] for a summary). A general issue 267 with reliable transport for multicast is the congestion problem 268 associated with delivery acknowledgments, which has made real-time 269 reliable multicast transport infeasible to date. Of the roughly 15 270 attempts to develop a reliable multicast transport, all have shown to 271 have some problem relating to positive receipt acknowledgments (ACK) 272 or negative acknowledgments (NAK). In any event, its seems clear that 273 there is not likely to be a single solution for reliable multicast, 274 but rather a number of solutions tailored to different application 275 domains. Approaches involving distributed logging seem to hold 276 particular promise for the distributed simulation application. 278 In the DIS/HLA environment, five different transmission needs can be 279 identified: 280 (1) best-effort low-latency multicast of object attributes that often 281 change continuously, for example position of mobile objects; 282 (2) low-latency reliable multicast of object attributes that do not 283 change continuously but may change at arbitrary times during the 284 simulation, for example object appearance (An important 285 characteristic of this category is that only the latest value of 286 any attribute is needed by the receiver.); 287 (3) low-latency, reliable unicast of occasional data among arbitrary 288 members of the multicast group (This form of transmission was 289 specified for DIS "collisions"; it is not in the current HLA 290 specification but might profitably be included there. The 291 requirement is for occasional transaction-like exchange of data 292 between two arbitrary hosts in the multicast group, with a low 293 latency that makes TCP connection impractical.); 294 (4) reliable but not necessarily real-time multicast distribution of 295 supporting bulk data such as terrain databases and object 296 enumerations; and 297 (5) reliable unicast of control information between individual RTI 298 components (this requirement is met by TCP). 300 All of these transmissions take place within the same large-scale 301 multicasting environment. The value of integrating categories (1) and 302 (2) into a single selectively reliable protocol was proposed by Cohen 303 [Cohe94]. Pullen and Laviano implemented this concept [PuLa95] and 304 demonstrated it within the HLA framework [PLM97] as the Selectively 306 Reliable Transmission Protocol (SRTP) for categories (1) through (3). 307 Category (4) could be supported by a reliable multicast protocol such 308 as the commercial multicast FTP offering from Starburst [MRTW97], 309 however adequate congestion control has not been demonstrated in any 310 such protocol. There has been some discussion of using the Real-Time 311 Streaming Protocol, RTSP, for this purpose, however as the databases 312 must be transmitted reliably and RTSP uses a best-effort model, it 313 does not appear to be applicable. 315 In summary, it is clear that a hybrid of best-effort and reliable 316 multicast (not necessarily all in the same protocol) is needed to 317 support DIS and HLA, and that the low-latency, reliable part of this 318 hybrid is not available in the Internet protocol suite. 320 3.4 Network management for distributed simulation systems 322 Coordinated, integrated network management is one of the more 323 difficult aspects of a large distributed simulation exercise. The 324 network management techniques that have been used successfully to 325 support the growth of the Internet for the past several years could 326 be expanded to fill this need. The technique is based on a primitive 327 called a Management Information Base (MIB) being polled periodically 328 at very low data rates. The receiver of the poll is called an Agent 329 and is collocated with the remote process being monitored. The agent 330 is simple so as to not absorb very many resources. The requesting 331 process is called a Manager, and is typically located elsewhere on a 332 separate workstation. The Manager communicates to all of the agents 333 in a given domain using the Simple Network Management Protocol (SNMP). 334 It appears that SNMP is well adapted to the purpose of distributed 335 simulation management, in addition to managing the underlying 336 simulation network resources. Creating a standard distributed 337 simulation MIB format would make it possible for the simulation 338 community to make use of the collection of powerful, off-the-shelf 339 network management tools that have been created around SNMP. 341 3.5 A session protocol to start, pause, and stop a distributed 342 simulation exercise 344 Coordinating start, stop, and pause of large distributed exercises is 345 a complex and difficult task. The Session Initiation Protocol (SIP) 346 recently proposed by the Multiparty Multimedia Session Control 347 (MMUSIC) working group serves a similar purpose for managing large 348 scale multimedia conferences. As proposed, SIP appears to offer 349 sufficient extensibility to be used for exercise session control, if 350 standardized by the IETF. 352 3.6 An integrated security architecture 354 It appears that this requirement will be met by IPv6 deployment. A 355 shortcoming of the current Internet Protocol (IPv4) implementation is 356 the lack of integrated security. The new IPv6 protocol requires 357 implementers to follow an integrated security architecture that 359 provides the required integrity, authenticity, and confidentiality 360 for use of the Internet by communities with stringent security 361 demands, such as the financial community. The possibility that the 362 IPv6 security architecture may meet military needs, when combined 363 either with military cryptography or government-certified commercial 365 cryptography, merits further study. 367 3.7 Low-latency multicast naming service 369 Name-to-address mapping in the Internet is performed by the Domain 370 Name Service (DNS). DNS has a distributed architecture tuned to the 371 needs of unicast networking with reliable transmission (TCP) that is 372 not considered problematic if its latency is on the order of a second 373 or more. The requirement of distributed simulation for agile movement 374 among multicast groups implies a need for name-to-multicast-address 375 mapping with latency of under one second for the name resolution and 376 group join combined. This problem has been circumvented in military 377 simulations by using group IP addresses rather than names. While 378 military simulations may be satisfied to communicate using a known 379 mapping from grid squares to multicast groups, growth of distributed 380 simulation into commercial entertainment cannot be based on such a 381 simple capability. The players in distributed entertainment 382 simulations will want to be organized symbolically by virtual world 383 and role. A low-latency multicast naming service will be required. 385 3.8 Inter-Domain Multicast Routing for LSMA 387 While military LSMAs typically take place within a single 388 administrative domain, future entertainment LSMAs can be expected to 389 involve heavy inter-domain multicast traffic so that players can be 390 supported by multiple service providers. Standardized protocols able 391 to support large numbers of multicast flows across domain boundaries 392 will be needed for this purpose. Current work to create a Border 393 Gateway Multicast Protocol (BGMP) shows promise of meeting this need. 395 4. References 397 [CSTH95] Calvin, J., J. Seeger, G. Troxel and D. Van Hook, "STOW 398 Realtime Information Transfer and Networking Architecture," 399 12th DIS Workshop on Standards for the Interoperability 400 Distributed Simulations, March 1995 402 [Cohe94] Cohen, D., "Back to Basics," Proceedings of the 11th Workshop 403 on Standards for Distributed Interactive Simulation, Orlando, 404 FL, September 1994 406 [DIS94] DIS Steering Committee, "The DIS Vision," Institute for 407 Simulation and Training, University of Central Florida, 408 May 1994 410 [DMSO96] Defense Modeling and Simulation Office, High Level 411 Architecture Rules Version 1.0, U.S. Department of Defense, 412 August 1996 414 [IEEE95a] IEEE 1278.1-1995, Standard for Distributed Interactive 415 Simulation - Application Protocols 417 [IEEE95b] IEEE 1278.2-1995, Standard for Distributed Interactive 418 Simulation - Communication services and Profiles 420 [MRTW97] Miller, K, K. Robertson, A. Tweedly, and M. White, "StarBurst 421 Multicast File Transfer Protocol (MFTP) Specification," IETF 422 draft-miller-mftp-spec-02.txt, work in progress, January 1997 424 [Mont97] Montgomery, T., Reliable Multicast Links webpage, 425 http://research.ivv.nasa.gov/RMP/links.html 427 [PuLa95] Pullen, J. and V. Laviano, "A Selectively Reliable Transport 428 Protocol for Distributed Interactive Simulation", Proceedings 429 of the 13th Workshop on Standards for Distributed Interactive 430 Simulation, Orlando, FL, September 1995 432 [PuWh95] Pullen, J.M. and E. White, "Dual-Mode Multicast: A New 433 Multicasting Architecture for Distributed Interactive 434 Simulation," 12th DIS Workshop on Standards for the 435 Interoperability of Distributed Simulations, Orlando, FL, 436 March 1995 438 [PLM97] Pullen, J., V. Laviano and M. Moreau, "Creating A Light- 439 Weight RTI As An Evolution Of Dual-Mode Multicast Using 440 Selectively Reliable Transmission," Proceedings of the Second 441 Simulation Interoperability Workshop, Orlando, FL, 442 September 1997 444 [SPW94] Symington, S., J.M.Pullen and D. Wood, "Modeling and 445 Simulation Requirements for IPng," IETF RFC1667, August 1994 447 [SSM96] Seidensticker, S., W. Smith and M. Myjak, "Scenarios and 448 Appropriate Protocols for Distributed Interactive 449 Simulation," IETF draft-ietf-lsma-scenarios-00.txt, work in 450 progress 13 June 1996 (companion Internet Draft) 452 [ZSSC97] Zhang, Z., C. Sanchez, W. Salkewicz, and E. Crawley, "Quality 453 of Service Path First Routing Protocol," IETF draft-zhang- 454 qos-ospf-01.txt, work in progress September 1997 456 5. Authors' Addresses 458 J. Mark Pullen 459 mpullen@gmu.edu 460 Computer Science/C3I Center 461 MS 4A5 462 George Mason University 463 Fairfax, VA 22032 465 Michael Myjak 466 mmyjak@virtualworkshop.com 467 The Virtual Workshop 468 P.O. Box 98 469 Titusville, FL 32781 471 Christina Bouwens 472 christina.bouwens@cpmx.mail.saic.com 473 ASSET Group, SAIC Inc. 474 Orlando FL 476 Expiration: 11 May 1999