idnits 2.17.1 draft-pullen-qospf-model-00.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 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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 400 has weird spacing: '...e Links conne...' -- 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 (25 November 1996) is 10014 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '3' is defined on line 491, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 499, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-rsvp-spec-14 -- No information found for draft-zhang-qos-qospf - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' ** Obsolete normative reference: RFC 1131 (ref. '4') (Obsoleted by RFC 1247) ** Downref: Normative reference to an Informational RFC: RFC 1585 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT J.M.Pullen 2 Expiration: 25 April 1997 George Mason U. 3 Lava K. Lavu 4 George Mason U. 5 Hai Nguyen 6 ESystems Falls Church 7 Eric Crawley 8 Baynetworks 9 25 November 1996 11 A Simulation of QOSFP Multicasting for a Large Area 12 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), nic.nordu.net 30 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 31 Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 This document describes a detailed simulation model of a sizable 36 IPmc/RSVP network using the Quality of Service Extensions to OSPF 37 and the performance predictions produced by the model. The model 38 was developed using the OPNET simulation package with procedures 39 defined in the C language. The model was developed to allow 40 investigation of scaling characteristics of QoS routing by the 41 Internet multicast/resource reservation community. We are making 42 our model publicly available for this purpose. 44 1. Background 46 The purpose of this document is to describe a simulation model 47 designed to help in understanding the scaling characteristics 48 of the QOSPF protocol in networks of significant size. 50 The successful deployment of IP multicasting [1] and its 51 availability in the Mbone has led to continuing increase in real- 52 time multimedia Internet applications. Because the Internet has 53 traditionally supported only a best-effort quality of service, 54 there is considerable interest to create mechanisms that will 55 allow adequate resources to be reserve in networks using the 56 Internet protocol suite, such that the quality of real-time 57 traffic such as video and voice can be sustained at specified 58 levels. The RSVP protocol [2] has been developed for this 59 purpose and is the subject of considerable ongoing implementation 60 efforts. 62 RSVP is does not provide routing, but relies on routing protocols 63 to be available in its working environment. One school of 64 thought argues that, to be effective, this routing must be aware 65 of quality of service (QOS) capabilities of network components 66 through which the RSVP paths and reservations are to be routed. 67 A proposal has been put forward for QOS-sensitive routing (QOSPF) 68 based on the well-known OSPF routing protocol [4] and its 69 multicast derivative, MOSPF [5]. However, serious questions have 70 been raised about the scalability of such a protocol. The 71 simulation described in this document is intended to provide a 72 tool to examine the behavior of a sizable QOSPF-routed network 73 with Ipmc and RSVP, handling large numbers of resource-reserved, 74 real-time multicast applications. A companion paper describes 75 the simulation models for IPmc and RSVP that support the QOSPF 76 simulation. Each of these models is available for use of the 77 IETF comunity. 79 2. The OPNET Simulation Environment 81 The Optimized Network Engineering Tools (OPNET) is a commercial 82 simulation product of the MIL3 Company, Arlington, VA. It 83 employs a Discrete Event Simulation approach that allows large 84 numbers of closely-spaced events in a sizable network to be 85 represented accurately and efficiently. OPNET uses a modeling 86 approach where networks are built of components interconnected by 87 perfect links (which can be degraded at will). Each component's 88 behavior is modeled as a state-transition diagram. The process 89 that takes place in each state is described by a program in the C 90 language. We believe this makes the OPNET-based models 91 relatively easy to port to other modeling environments. Perhaps 92 more importantly, given the widespread availability of OPNET, 93 it makes them sufficiently efficient that an extended period of 94 network behavior can be simulated in considerable detail, even for 95 large networks. 97 The following sections describe the state-transition models and 98 process code for the QOSPF model we have created using OPNET. 100 3. QOSPF Model 102 The state-transition diagrams for the QOSPF model can be found at 103 http://bacon.gmu.edu/qosip/qospf/rtr-states.html. 105 The following processing takes place in the indicated modules. 107 3.1 init 109 This state initializes all the router variables. Default 110 transition to idle state. 112 3.2 idle 114 This state has several transitions. If a packet arrives it 115 transits to arr state. Depending on interrupts received it will 116 transit to BCOspfLsa, BCQospfLsa, BCMospfLsa, hello_pks state. 117 In future versions, links coming up or down will also cause a 118 transition. 120 3.3 BCOspfLsa 122 Transition to this state from idle state is executed whenever the 123 condition send_ospf_lsa is true, which happens when the network is 124 being initialized, and when ospf_lsa_refresh_timout occurs. This 125 state will create Router, Network, Summary Link State 126 Advertisements and pack all of them into an Link State Update 127 packet. The Link State Update Packet is sent to the IP layer with a 128 destination address of AllSPFRouters. 130 3.4 BCQospfLsa 132 Transition to this state from the idle state is executed whenever 133 the condition send_qospf_lsa is true. This state will create Link 134 Resource Advertisement and Resource Reservation Advertisement and 135 pack them into a Qospf Link State Update Packet. This Qospf Link 136 State Update Packet is sent to IP layer with a destination 137 address of AllSPFRouters. 139 3.5 BCMospfLsa 141 Transition to this state from idle state is executed whenever the 142 condition send_mospf_lsa is true. This state will create Group 143 Membership Link State Advertisement and pack them into Mospf Link 144 State Update Packet. This Mospf Link State Update Packet is sent 145 to IP layer with a destination address of AllSPFRouters. 147 3.6 arr 149 The arr state checks the type of packet that is received upon a 150 packet arrival. It calls the following functions depending on the 151 protocol Id of the packet received. 153 a. QospfPkPro: Depending on the type of QOSPF/OSPF/MOSPF packet 154 received the function calls the following functions. 155 1. HelloPk_pro: This function is called whenever a hello packet is 156 received. This function updates the router's neighbor information, 157 which is later used while sending the different LSAs. 158 2. OspfLsUpdatePk_pro: This function is called when a OSPF LSA update 159 packet is received (router LSA, network LSA, or summary LSA). If 160 the Router is an Area Border Router or if the LSA belongs to the 161 Area whose Area Id is the Routers Area Id, then it is searched to 162 determine whether this LSA already exists in the Link State 163 database. If it exists and if the existing LSA's LS Sequence 164 Number is less than the received LSA's LS Sequence Number the 165 existing LSA was replaced with the received one. The function 166 processes the Network LSA only if it is a designated router or 167 Area Border Router. It processes the Summary LSA only if the 168 router is a Area Border Router. The function also turns on the 169 trigger ospfspfcalc which is the condition for the transition from 170 arr state to ospfspfcalc. 171 3. MospfLsUpdatePk_pro: This function is called when a MOSPF LSA 172 update packet is received. It updates the group membership link 173 state database of the router. The function also turns on the 174 trigger mospfspfcalc which is the condition for the transition 175 from arr state to mospfspfcalc. In future versions, network 176 topology changes will also trigger this state. 177 4. QospfLsUpdatePk_pro: This function is called when a QOSPF LSA 178 update packet is received. It updates the resource link state 179 database of the router. It turns on the trigger qospfcalc which is 180 used as a transition condition from arr state to qospfspfcalc 181 state. 182 b. RsvpPkPro: This function is invoked whenever a packet is received 183 by the arr state from the RSVP daemon. RSVP will send a packet to 184 QOSPF daemon whenever the RSVP daemon receives an initial path 185 message, or a reservation for a source is successful. This function 186 calls one of the following two functions depending on the type of 187 packet received by the QOSPF arr state. 188 1. Path_Msg_pro: This function gets the source and destination 189 information, sender transmission specs and sets the trigger 190 qospfcalc on. 191 2. Resv_Msg_Pro: This function gets the resources reserved 192 information from the TCSB of the RSVP daemon and makes the trigger 193 send_rralsa true, which will in turn turn on the send_qospf_lsa 194 trigger on. send_qospf_lsa is used to send the send the Qospf LSA 195 update packets, thereby sending the Resource Reservation 196 Advertisement with the new information. 197 3. IgmpPkPro: This function will make the trigger send_grpmbrlsa true 198 which in turn activates the send_mospf_lsa trigger. send_mospf_lsa 199 is used to send the MOSPF LSA update packets. This is a trigger 200 from IGMP so that QOSPF examines all new group joins. 202 3.7 qospfspfcalc 204 This function is used to calculate the QOSPF routing table. 205 Resource LSA's are used to discover the neighbors and RRA's are 206 used to check for the available resources on the link. This state 207 transit to upstr_node on detupstrnode condition. Only topology 208 changes (indicated by router LSA, network LSA, resource LSA)) will 209 trigger recalculation of all flows, other changes (summary LSA, 210 group change, amd RRA/DABRA) only cause recalculation of affected 211 entries. 213 a. QospfCandidateAddPro: Each vertex's neighbors are checked for 214 inclusion into the candidate list by examining the Resource-LSA. If 215 the existing reservation for the flow (for this source destination 216 pair) or the available bandwidth on this link meets the QOS 217 requirements of the flow then the other end of the link is considered 218 for inclusion in the candidate list. The delay from the source to 219 this vertex(the other end of the link) is calculated and if this 220 vertex is not on the candidate list it is added to the candidate 221 list. Route pinning is used. When adding the vertex if the 222 parent of vertex has a reservation for the flow it is marked 223 reserved. 225 b. QospfSPFTreeCalc: While the candidate list is not empty the 226 candidate that is closest to the root is deleted and added to the 227 shortest path tree, and the Resource-LSA of this candidate is used to 228 check for possible inclusion of the other end of the links into the 229 candidate list. A vertex marked reserved is chosen first in 230 building the Shortest Path Tree. 232 c. QospfRouteTableCalc: Using the shortest path tree information 233 obtained from the shortest path tree database route table is 234 calculated. The IP layer uses this information to route the QOS 235 flows. 237 3.8 hello_pks 239 Hello packets are created and sent with destination address of 240 AllSPFRouters. Default transition to idle state. 242 3.9 mospfspfcalc 244 The following functions are used to calculate the shortest path 245 tree and routing table. This state transit to upstr_node upon 246 detupstrnode condition. 248 a. CandListInit: Depending upon the SourceNet of the datagram the 249 candidate lists are initialized.A 251 b. MospfCandAddPro: The vertex link is examined and if the other end 252 of the link is not a stub networks and is not already in the 253 candidate list it is added to the candidate list after calculating 254 the cost to that vertex. If this other end of the link is already on 255 the shortest path tree and the calculated cost is less than the one 256 that shows in the shortest path tree entry update the shortest path 257 tree to show the calculated cost. 259 c. MospfSPFTreeCalc: The vertex that is closest to the root that is 260 in the candidate list is added to the shortest path tree and its link 261 is considered for possible inclusions in the candidate list. 263 d. MCRoutetableCalc: Multicast routing table is calculated using the 264 information of the MOSPF shortest Path tree. 266 3.10 ospfspfcalc 268 The following functions are used in this state to calculate the 269 shortest path tree and using this information the routing table. 270 Transition to qospfspfcalc state on qospfcalc condition. This was 271 set to one after processing all functions in the state. 273 a. OspfCandidateAddPro: This function initializes the candidate list 274 by examining the link state advertisement of the the Router. For each 275 link in this advertisement, if the other end of the link is a router 276 or transit network and if it is not already in the shortest-path 277 tree then calculate the distance between these vertices. If the 278 other end of this link is not already on the candidate list or if 279 the distance calculated is less than the value that appears for 280 this other end add the other end of the link to candidate list. 282 b. OspfSPTreeBuild: This function pulls each vertex from the 283 candidate list that is closest to the root and adds it to the 284 shortest path tree. In doing so it deletes the vertex from the 285 candidate list. This function continues to do this till the candidate 286 list is empty. 288 c. OspfStubLinkPro: In this procedure the stub networks are added to 289 shortest path tree. 291 d. OspfSummaryLinkPro: If the router is an Area Border Router the 292 summary links that it has received is examined. The route to the Area 293 border router advertising this summary LSA is examined in the routing 294 table. If one is found a routing table update is done by adding the 295 route to the network specified in the summary LSA and the cost to 296 this route is sum of the cost to area border router advertising this 297 and the cost to reach this network from that area border router. 299 e. RoutingTableCalc: This function updates the routing table by 300 examining the shortest path tree data structure. 302 3.11 upstr_node 304 This state does not do anything in the present model. It transitions 305 to DABRA state. 307 3.12 DABRA 309 If the router is an Area Border Router and the area is the source 310 area then a DABRA message is constructed and send to all the 311 downstream areas. Default transition to idle state. 313 4. Performance Predictions 315 The purpose for generating the model was to use it to predict 316 performance of a large IPmc-RSVP systems using QOSPF routing. 317 We describe results of the simulation below. 319 4.1 small-scale test network and model calibration 321 A 5-router test Network has been created in a lab environment to 322 study the behavior of the Quality-of-Service Open Shortest Path First 323 (QOSPF) routing protocol. The test network is made up of Bay 324 Networks Backbone Link Node-2 (BLN-2) routers, Silicon Graphics Inc. 325 (SGI) workstations, and Audio Host Processors. Routers are 326 interconnected via Crossover cables that perform as T1 links. 327 Workstations and Hosts are nodes on Fiber Distributed Data Interface 328 (FDDI) Local Area Networks (LANs). A diagram of the test network is 329 shown in: 331 http://bacon.gmu.edu/qosip/qospf/ss-cal-net.html 333 4.1.1 Hardware and Software Configuration 335 a. Backbone Link Node-2 Routers: The routers are running BayNetworks 336 Image 11.0 Release with the addition of QOSPF, IGMP v2.0, and a 337 subset of RSVP based on Internet Draft (ID) 8.0. For RSVP, fixed 338 filter reservation style using raw RSVP I/O is supported. The ADspec 339 object is not supported. Router alert IP option is used. Integrated 340 services Controlled-Load is supported (as specified in the draft- 341 ietf-intserv-ctrl-load-svc-03.txt). In addition, a protocol 342 prioritization mechanism is used to control the queuing delay and 343 dropping of QOSPF and RSVP messages. 345 b. Silicon Graphics Inc. Workstations: These are Indy Workstations 346 with Sysconnect FDDI card (12501) running IRIX v5.1 operating system. 347 Custom UDP Test traffic generator (both Unicast and Multicast) is 348 included. 350 c. Audio Host Processors: These are E-Systems proprietary 6U VMEbus 351 boxes consisting of Motorola 68040 processor (MVME167-033B), Cyclone 352 i960 processors (CVM964), and Rockwell FDDI interface card (125010). 353 Each Host has an internal Ethernet network for processor to processor 354 communication. The units are running ISI pSOS+ v1.3 real time 355 operating system. Audio applications use Xpress Transfer Protocol 356 (XTP) v4.0 as its Transport layer. IGMP v2.0, RIP v1.0 and a subset 357 of RSVP based on ID 8.0 are also supported. 359 4.1.2 Test Network Description 361 The BLN-2 Routers are connected via serial synchronous links acting 362 as T1 links. Each link has a line bandwidth of 1.25 Mbits/sec. 363 This is the clock speed closest to the 1.544 Mbits/sec T1 rate that 364 the routers can source. For each link, the Reservable bandwidth is 365 set at 1.075 Mbits/sec, and the Best Effort (BE) bandwidth is set at 366 175 Kbits/sec. 368 a. Reserved Flows Characteristics: Audio flows are provided with a 369 Controlled-Load service. The RSVP Tspec has a burst of 5,120 bytes 370 (10 datagrams) and a rate of 77 Kbytes/sec. Audio data packet size 371 is 512 bytes. IP datagram packet size is 584 bytes (includes data, 372 XTP header, IP header and a second encapsulating IP header). Based 373 on the configured reservable bandwidth of 1.075 Mbits/sec, a maximum 374 of 13 audio flows can be allocated per link. This does include a 7% 375 inflation factor. 377 b. BE Traffic Characteristics: Data packet size is 500 bytes. UDP 378 IP datagram size is 528 bytes. 380 4.1.3 Test Scenarios 382 4.1.3.1 Test Case 1 - Reserved Flows with BE Traffic 384 a. Test Scenario: Host1 is the source for Audio multicast group 385 #1-13. Host2 is the source for Audio multicast group #14-26. Host3 386 joins and starts receiving Audio multicast group #1-26. There are 90 387 Kbits/sec of BE UDP traffic from Workstation2 to Workstation3. 389 b. Observation: All Reserved flows and BE traffic from R2-R5-R3 are 390 contained within a single link. Similarly, only one link is utilized 391 from R1-R4-R3. Host3 receives all datagrams from Audio multicast 392 group #1-26. Workstation3 receives 90 Kbit/sec of UDP traffic from 393 Workstation2 via R2-R5-R3. No packets are clipped, since the link 394 bandwidth is greater than that consumed by both the Reserved flows 395 and BE traffic. 397 4.1.3.2 Test Case 2 - Reserved Flows with BE Traffic and Links break 399 a. Test Scenario: Same as Test Case 1. Both Reserved flows and BE 400 traffic are flowing from R1-R4-R3 and R2-R5-R3. The Links connecting 401 R2 and R5 are disconnected. 403 b. Observation: Host3 is receiving all Reserved flows from Host1 via 404 R1-R4-R3, and Host2 via R2-R5-R3. Workstation3 is receiving all BE 405 UDP traffic from Workstation 2 via R2-R5-R3. After the links between 406 R2 and R5 are removed, the Reserved flows from Host2 and BE traffic 407 from Workstation2 are re-routed to OSPF area 3 via R2-R1-R4-R3. The 408 rerouted traffic, originating from OSPF area2, now utilizes the 409 second link between R1&R4 and R4&R3. 411 4.1.3.3 Test Case 3 - Reserved Flows with Heavy BE Traffic 413 a. Test Scenario: Same as Test Case 1, except that the BE UDP 414 traffic from Workstation2 to Workstation3 is increased from 90 415 Kbits/sec to 902.4 Kbits/sec, causing link overload. Note that on 416 this scenario the BE traffic are exceeding the BE available 417 bandwidth. 419 b. Observation: Host3 is receiving all of the Reserved flows from 420 Host1 via R1-R4-R3, and Host2 via R2-R5-R3. Workstation3 is 421 receiving in the average 257.15 Kbits/sec of BE UDP traffic from 422 Workstation 2 via R2-R5-R3. In the average 71.6 packets/sec of BE UDP 423 packets are clipped at R2 since the available BE bandwidth is much 424 less than the actual BE traffic. The Reserved flows are not effected 425 by the heavy BE traffic on the same links. 427 4.1.4 Calibration 429 Calibration of the small-scale network simulation against the 430 behavior or the physical model is ongoing. 432 4.2 Behavior of the scaled-up QOSPF network 434 The major purpose for this simulation effort was to examine in 435 detail the projected performance of a large QOSPF-based autonomous 436 system. Accordingly we have generated a system of 84 routers 437 that we believe is representative of the sort of environment where 438 QOSPF would be used. 440 4.2.1 Nature of the scaled-up network 442 The scaled-up network can be seen at: 444 http://bacon.gmu.edu/qosip/network_model/future_model 446 The network consist of four areas, each constructed from four 447 copies of the small-scale network. The areas are cross-linked 448 such that each small-scale network is connected to two area 449 routers. Further, the area routers are connected to backbone 450 routers and cross-linked for redundancy. The intention is to 451 represent a corporate network with high performance and reliability 452 requirements, where each of the small-scale networks might 453 represent a department and each area router a geographic area. 455 4.2.2 Simulation results from the scaled-up network. 457 We are still early in the process of understanding just what is 458 happening inside our complex target environment. In particular we 459 have been grappling with a series of problems associated with 460 scaling up the protocols, which appear to be working in the 461 small-scale network. We are running session generators at moderate 462 levels (at most one new session per router per second) and working 463 to verify the validity of the simulation results. Thus far we 464 have found the target environment is fully able to break any naive 465 simulation we try, either by demanding amounts of memory beyond 466 the virtual memory space of Unix, or by running so slowly that 467 hundreds of hours of wall-clock time would be required to represent 468 one hour of simulated time. We are making good progress and expect 469 to have validated simulation statistics within a month. Meanwhile we 470 are releasing this interim report to the Internet community with the 471 expectation that this will result in a thorough review and 472 theoretical validation, or indication where further work is needed, 473 for the model elements described here. 475 5. Future Work 477 We expect to perform further simulations of the QOSPF protocol 478 to allow it to be defined in such as way as to be most effective. 479 We welcome participation in this process by the Internet 480 community. 482 6. References 484 [1] Deering, "Host Requirements for IP Multicasting", RFC 1112, 485 August 1989 487 [2] Braden et. al., "Resource Reservation Protocol Version 1 488 Functional Specification", work in progress (draft-ietf-rsvp- 489 spec-14), November 1996 491 [3] Zhang et. al., "Quality of Service Extensions to OSPF or 492 Quality of Service First Path Routing (QOSPF)", work in progress 493 (draft-zhang-qos-qospf-00.txt), June 1996 495 [4] Moy, "OSPF Specification", RFC 1131, October 1989 497 [5] Moy, "MOSPF: Analysis and Experience", RFC 1585, March 1994 499 [6] MIL3 Inc., OPNET: Optimized Network Engineering Tools, 500 Simulation Kernel Manual, November 1991 501 Authors' Addresses 503 J. Mark Pullen 504 Computer Science/4A5 505 George Mason University 506 Fairfax, VA 22032 507 mpullen@gmu.edu 509 Lava K. Lavu 510 C3I Center/4B5 511 George Mason University 512 Fairfax, VA 22030 513 llavu@bacon.gmu.edu 515 Hai H. Nguyen 516 Raytheon E-Systems, Falls Church Division 517 7700 Arlington Blvd, N201 518 Falls Church, VA 22046 519 hai_nguyen@fallschurch.esys.com 521 Eric Crawley 522 BayNetworks Milstop 3FS-1302 523 3 Federal St. 524 Billerica, MA 01821 525 esc@baynetworks.com 527 Expiration: 25 April 1997