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