idnits 2.17.1 draft-ietf-lsma-limitations-03.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 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 an Authors' Addresses Section. ** 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 (14 September 1998) is 9356 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 439, 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: 12 errors (**), 0 flaws (~~), 4 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 14 September 1998 9 Limitations of Internet Protocol Suite for Distributed Simulation 10 in the Large Multicast Environment 12 draft-ietf-lsma-limitations-03 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 sustain 169 host group join requiring 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.) 198 3.1 Large-scale resource reservation in shared networks 200 The Resource reSerVation Protocol (RSVP) is aimed at providing setup 201 and flow-based information for managing information flows at pre- 202 committed performance levels. This capability is generally seen as 203 needed in real-time systems such as the HLA RTI. Concerns have been 204 raised about the scalability of RSVP, and also about its ability to 205 support highly dynamic flow control changes. In terms of existing 206 RTI capabilities, the requirement in LSMA is for rapid change of 207 group membership, not for rapid change of group reservations. This 208 is because in existing RTIs the aggregate requirement for all groups 209 in a large scale distributed simulation is static. However the 210 current RSVP draft standard for LSMA does not support aggregation of 211 reservation resources for groups of flows and therefore does not meet 212 the needs of existing RTIs. Moreover, there is at least one RTI 213 development underway that intends to use individual, dynamic 214 reservations for large numbers of groups, and therefore will require 215 a dynamic resource reservation capability that scales to thousands 216 of multicast groups. 218 Further, RSVP provides support only for communicating specifications 219 of the required information flows between simulators and the network, 220 and within the network. Distributing routing information among the 221 routers within the network is a different function altogether, 222 performed by routing protocols such as Multicast Open Shortest Path 223 First (MOSPF). In order to provide effective resource reservation in 224 a large shared network function, it may be necessary to have a 225 routing protocol that determines paths through the network within the 226 context of a quality of service requirement. An example is the 227 proposed Quality Of Service Path First (QOSPF) routing protocol 228 [ZSSC97]. Unfortunately the requirement for resource-sensitive 229 routing will be difficult to define before LSMA networks are deployed 230 with RSVP. 232 3.2 IP multicast that is capable of taking advantage of all common 233 link layer protocols (in particular, ATM) 235 Multicast takes advantage of the efficiency obtained when the network 236 can recognize and replicate information packets that are destined to 237 a group of locations. Under these circumstances, the network can take 238 on the job of providing duplicate copies to all destinations, thereby 239 greatly reducing the amount of information flowing into and through 240 the network. 242 When IP multicast operates over Ethernet, IP multicast packets are 243 transmitted once and received by all receivers using Ethernet-layer 244 multicast addressing, avoiding replication of packets. 245 However, with wide-area technology Asynchronous Transfer Mode (ATM), 246 the ability to take advantage of data link layer multicast capability 247 is not yet available beyond a single Logical IP Subnet (LIS). This 248 appears to be due to the fact that (1) the switching models of IP and 249 ATM are sufficiently different that this capability will require a 250 rather complex solution, and (2) there has been no clear application 251 requirement for IP multicast over ATM multicast that provides for 252 packet replication across multiple LIS. Distributed simulation is an 253 application with such a requirement. 255 3.3 Hybrid transmission of best-effort and reliable multicast 257 In general the Internet protocol suite uses the Transmission Control 258 Protocol (TCP) for reliable end-to-end transport, and the User 259 Datagram Protocol (UDP) for best-effort end-to-end transport, 260 including all multicast transport services. The design of TCP is 261 only capable of unicast transmission. 263 Recently the IETF has seen proposals for several reliable multicast 264 transport protocols (see [Mont97] for a summary). A general issue 265 with reliable transport for multicast is the congestion problem 266 associated with delivery acknowledgments, which has made real-time 267 reliable multicast transport infeasible to date. Of the roughly 15 268 attempts to develop a reliable multicast transport, all have shown to 269 have some problem relating to positive receipt acknowledgments (ACK) 270 or negative acknowledgments (NAK). In any event, its seems clear that 271 there is not likely to be a single solution for reliable multicast, 272 but rather a number of solutions tailored to different application 273 domains. Approaches involving distributed logging seem to hold 274 particular promise for the distributed simulation application. 276 In the DIS/HLA environment, five different transmission needs can be 277 identified: 278 (1) best-effort low-latency multicast of object attributes that often 279 change continuously, for example position of mobile objects; 280 (2) low-latency reliable multicast of object attributes that do not 281 change continuously but may change at arbitrary times during the 282 simulation, for example object appearance (An important 283 characteristic of this category is that only the latest value of 284 any attribute is needed by the receiver.); 285 (3) low-latency, reliable unicast of occasional data among arbitrary 286 members of the multicast group (This form of transmission was 287 specified for DIS "collisions"; it is not in the current HLA 288 specification but might profitably be included there. The 289 requirement is for occasional transaction-like exchange of data 290 between two arbitrary hosts in the multicast group, with a low 291 latency that makes TCP connection impractical.); 292 (4) reliable but not necessarily real-time multicast distribution of 293 supporting bulk data such as terrain databases and object 294 enumerations; and 295 (5) reliable unicast of control information between individual RTI 296 components (this requirement is met by TCP). 298 All of these transmissions take place within the same large-scale 299 multicasting environment. The value of integrating categories (1) and 300 (2) into a single selectively reliable protocol was proposed by Cohen 301 [Cohe94]. Pullen and Laviano implemented this concept [PuLa95] and 302 demonstrated it within the HLA framework [PLM97] as the Selectively 303 Reliable Transmission Protocol (SRTP) for categories (1) through (3). 304 Category (4) could be supported by a reliable multicast protocol such 305 as the commercial multicast FTP offering from Starburst [MRTW97], 306 however adequate congestion control has not been demonstrated in any 307 such protocol. There has been some discussion of using the Real-Time 308 Streaming Protocol, RTSP, for this purpose, however as the databases 309 must be transmitted reliably and RTSP uses a best-effort model, it 310 does not appear to be applicable. 312 In summary, it is clear that a hybrid of best-effort and reliable 313 multicast (not necessarily all in the same protocol) is needed to 314 support DIS and HLA, and that the low-latency, reliable part of this 315 hybrid is not available in the Internet protocol suite. 317 3.4 Network management for distributed simulation systems 319 Coordinated, integrated network management is one of the more 320 difficult aspects of a large distributed simulation exercise. The 321 network management techniques that have been used successfully to 322 support the growth of the Internet for the past several years could 323 be expanded to fill this need. The technique is based on a primitive 324 called aManagement Information Base (MIB) being polled periodically 325 at very low data rates. The receiver of the poll is called an Agent 326 and is collocated with the remote process being monitored. The agent 327 is simple so as to not absorb very many resources. The requesting 328 process is called a Manager, and is typically located elsewhere on a 329 separate workstation. The Manager communicates to all of the agents 330 in a given domain using the Simple Network Management Protocol (SNMP). 331 It appears that SNMP is well adapted to the purpose of distributed 332 simulation management, in addition to managing the underlying 333 simulation network resources. Creating a standard distributed 334 simulation MIB format would make it possible for the simulation 335 community to make use of the collection of powerful, off-the-shelf 336 network management tools that have been created around SNMP. 338 3.5 A session protocol to start, pause, and stop a distributed 339 simulation exercise 341 Coordinating start, stop, and pause of large distributed exercises is 342 a complex and difficult task. The Session Initiation Protocol (SIP) 343 recently proposed by the Multiparty Multimedia Session Control 344 (MMUSIC) working group serves a similar purpose for managing large 345 scalemultimedia conferences. As proposed, SIP appears to offer 346 sufficient extensibility to be used for exercise session control, if 347 standardized by the IETF. 349 3.6 An integrated security architecture 351 It appears that this requirement will be met by IPv6 deployment. A 352 shortcoming of the current Internet Protocol (IPv4) implementation is 353 the lack of integrated security. The new IPv6 protocol requires 354 implementers to follow an integrated security architecture that 355 provides the required integrity, authenticity, and confidentiality 356 for use of the Internet by communities with stringent security 357 demands, such as the financial community. The possibility that the 358 IPv6 security architecture may meet military needs, when combined 359 either with military cryptography or government-certified commercial 361 cryptography, merits further study. 363 3.7 Low-latency multicast naming service 365 Name-to-address mapping in the Internet is performed by the Domain 366 Name Service (DNS). DNS has a distributed architecture tuned to the 367 needs of unicast networking with reliable transmission (TCP) that is 368 not considered problematic if its latency is on the order of a second 369 or more. The requirement of distributed simulation for agile movement 370 among multicast groups implies a need for name-to-multicast-address 371 mapping with latency of under one second for the name resolution and 372 group join combined. This problem has been circumvented in military 373 simulations by using group IP addresses rather than names. While 374 military simulations may be satisfied to communicate using a known 375 mapping from grid squares to multicast groups, growth of distributed 376 simulation into commercial entertainment cannot be based on such a 377 simple capability. The players in distributed entertainment 378 simulations will want to be organized symbolically by virtual world 379 and role. A low-latency multicast naming service will be required. 381 3.8 Inter-Domain Multicast Routing for LSMA 383 While military LSMAs typically take place within a single 384 administrative domain, future entertainment LSMAs can be expected to 385 involve heavy inter-domain multicast traffic so that players can be 386 supported by multiple service providers. Standardized protocols able 387 to support large numbers of multicast flows across domain boundaries 388 will be needed for this purpose. Current work to create a Border 389 Gateway Multicast Protocol (BGMP) shows promise of meeting this need. 391 4. References 393 [CSTH95] Calvin, J., J. Seeger, G. Troxel and D. Van Hook, "STOW 394 Realtime Information Transfer and Networking Architecture," 395 12th DIS Workshop on Standards for the Interoperability 396 Distributed Simulations, March 1995 398 [Cohe94] Cohen, D., "Back to Basics," Proceedings of the 11th Workshop 399 on Standards for Distributed Interactive Simulation, Orlando, 400 FL, September 1994 402 [DIS94] DIS Steering Committee, "The DIS Vision," Institute for 403 Simulation and Training, University of Central Florida, 404 May 1994 405 [DMSO96] Defense Modeling and Simulation Office, High Level 406 Architecture Rules Version 1.0, U.S. Department of Defense, 407 August 1996 409 [IEEE95a] IEEE 1278.1-1995, Standard for Distributed Interactive 410 Simulation - Application Protocols 412 [IEEE95b] IEEE 1278.2-1995, Standard for Distributed Interactive 413 Simulation - Communication services and Profiles 415 [MRTW97] Miller, K, K. Robertson, A. Tweedly, and M. White, "StarBurst 416 Multicast File Transfer Protocol (MFTP) Specification," IETF 417 draft-miller-mftp-spec-02.txt, work in progress, January 1997 419 [Mont97] Montgomery, T., Reliable Multicast Links webpage, 420 http://research.ivv.nasa.gov/RMP/links.html 422 [PuLa95] Pullen, J. and V. Laviano, "A Selectively Reliable Transport 423 Protocol for Distributed Interactive Simulation", Proceedings 424 of the 13th Workshop on Standards for Distributed Interactive 425 Simulation, Orlando, FL, September 1995 427 [PuWh95] Pullen, J.M. and E. White, "Dual-Mode Multicast: A New 428 Multicasting Architecture for Distributed Interactive 429 Simulation," 12th DIS Workshop on Standards for the 430 Interoperability of Distributed Simulations, Orlando, FL, 431 March 1995 433 [PLM97] Pullen, J., V. Laviano and M. Moreau, "Creating A Light- 434 Weight RTI As An Evolution Of Dual-Mode Multicast Using 435 Selectively Reliable Transmission," Proceedings of the Second 436 Simulation Interoperability Workshop, Orlando, FL, 437 September 1997 439 [SPW94] Symington, S., J.M.Pullen and D. Wood, "Modeling and 440 Simulation Requirements for IPng," IETF RFC1667, August 1994 442 [SSM96] Seidensticker, S., W. Smith and M. Myjak, "Scenarios and 443 Appropriate Protocols for Distributed Interactive 444 Simulation," IETF draft-ietf-lsma-scenarios-00.txt, work in 445 progress 13 June 1996 (companion Internet Draft) 447 [ZSSC97] Zhang, Z., C. Sanchez, W. Salkewicz, and E. Crawley, "Quality 448 of Service Path First Routing Protocol," IETF draft-zhang- 449 qos-ospf-01.txt, work in progress September 1997 450 5. Authors' Addresses 452 J. Mark Pullen 453 mpullen@gmu.edu 454 Computer Science/C3I Center 455 MS 4A5 456 George Mason University 457 Fairfax, VA 22032 459 Michael Myjak 460 mmyjak@mail.imtinc.com 461 The Virtual Workshop 462 P.O. Box 98 463 Titusville, FL 32781 465 Christina Bouwens 466 christina.bouwens@cpmx.mail.saic.com 467 ASSET Group, SAIC Inc. 468 Orlando FL 470 Expiration: 14 March 1999