rfc2490.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,411 行 · 第 1/5 页

Network Working Group                                         M. Pullen
Request for Comments: 2490                      George Mason University
Category: Informational                                      R. Malghan
                                                   Hitachi Data Systems
                                                                L. Lavu
                                                           Bay Networks
                                                                G. Duan
                                                                 Oracle
                                                                  J. Ma
                                                              NewBridge
                                                                 H. Nah
                                                George Mason University
                                                           January 1999


             A Simulation Model for IP Multicast with RSVP

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document describes a detailed model of IPv4 multicast with RSVP
   that has been developed using the OPNET simulation package [4], with
   protocol procedures defined in the C language.  The model was
   developed to allow investigation of performance constraints on
   routing but should have wide applicability in the Internet
   multicast/resource reservation community.  We are making this model
   publicly available with the intention that it can be used to provide
   expanded studies of resource-reserved multicasting.

Table of Contents

   1. Background                                                  2
   2. The OPNET Simulation Environment                            3
   3. IP Multicast Model                                          3
           3.1 Address Format                                     3
           3.2 Network Layer                                      4
           3.3 Node layer                                         5
   4. RSVP Model                                                 13
           4.1 RSVP Application                                  13



Pullen, et. al.              Informational                      [Page 1]

RFC 2490                 IP Multicast with RSVP             January 1999


           4.2 RSVP on Routers                                   14
           4.3 RSVP on Hosts                                     17
   5. Multicast Routing Model Interface                          19
           5.1 Creation of multicast routing processor node      19
           5.2 Interfacing processor nodes                       19
           5.3 Interrupt Generation                              21
           5.4 Modifications of modules in the process model     22
   6. OSPF and MOSPF Models                                      23
           6.1 Init                                              23
           6.2 Idle                                              23
           6.3 BCOspfLsa                                         23
           6.4 BCMospfLsa                                        23
           6.5 Arr                                               23
           6.6 Hello_pks                                         24
           6.7 Mospfspfcalc                                      24
           6.8 Ospfspfcalc                                       25
           6.9 UpstrNode                                         25
           6.10 DABRA                                            25
   7. DVMRP Model                                                26
           7.1 Init                                              26
           7.2 Idle                                              26
           7.3 Probe_Send State                                  26
           7.4 Report_Send                                       26
           7.5 Prune _Send                                       26
           7.6 Graft_send                                        27
           7.7 Arr_Pkt                                           27
           7.8 Route_Calc                                        28
           7.9 Timer                                             28
   8. Simulation performance                                     28
   9. Future Work                                                29
   10. Security Considerations                                   29
   11. References                                                29
   Authors' Addresses                                            30
   Full Copyright Statement                                      31

1. Background

   The successful deployment of IP multicasting [1] and its availability
   in the Mbone has led to continuing increase in real-time multimedia
   Internet applications.  Because the Internet has traditionally
   supported only a best-effort quality of service, there is
   considerable interest to create mechanisms that will allow adequate
   resources to be reserved in networks using the Internet protocol
   suite, such that the quality of real-time traffic such as video,
   voice, and distributed simulation can be sustained at specified
   levels.  The RSVP protocol [2] has been developed for this purpose
   and is the subject of ongoing implementation efforts. Although the
   developers of RSVP have used simulation in their design process, no



Pullen, et. al.              Informational                      [Page 2]

RFC 2490                 IP Multicast with RSVP             January 1999


   simulation of IPmc with RSVP has been generally available for
   analysis of the performance and prediction of the behavior of these
   protocols.  The simulation model described here was developed to fill
   this gap, and is explicitly intended to be made available to the IETF
   community.

2.  The OPNET Simulation Environment

   The Optimized Network Engineering Tools (OPNET) is a commercial
   simulation product of the MIL3 company of Arlington, VA.  It employs
   a Discrete Event Simulation approach that allows large numbers of
   closely-spaced events in a sizable network to be represented
   accurately and efficiently. OPNET uses a modeling approach where
   networks are built of components interconnected by perfect links that
   can be degraded at will.  Each component's behavior is modeled as a
   state-transition diagram.  The process that takes place in each state
   is described by a program in the C language. We believe this makes
   the OPNET-based models relatively easy to port to other modeling
   environments. This family of models is compatible with OPNET 3.5.
   The following sections describe the state-transition models and
   process code for the IPmc and RSVP models we have created using
   OPNET. Please note that an OPNET layer is not necessarily equivalent
   to a layer in a network stack, but shares with a stack layer the
   property that it is a highly modular software element with well
   defined interfaces.

3.  IP Multicast Model

   The following processing takes place in the indicated modules. Each
   subsection below describes in detail a layer in the host and the
   router that can be simulated with the help of the corresponding OPNET
   network layer or node layer or the process layer, starting from
   physical layer.

3.1 Address format

   The OPNET IP model has only one type of addressing denoted by "X.Y"
   where X is 24 bits long and Y is 8 bits long, corresponding to an
   IPv4 Class C network.  The X indicates the destination or the source
   network number and Y indicates the destination or the source node
   number.  In our model X = 500 is reserved for multicast traffic.  For
   multicast traffic the value of Y indicates the group to which the
   packet belongs.








Pullen, et. al.              Informational                      [Page 3]

RFC 2490                 IP Multicast with RSVP             January 1999


3.2 Network Layer

   Figure 1 describes an example network topology built using the OPNET
   network editor.  This network consists of two backbone routers BBR1,
   BBR2, three area border routers ABR1, ABR2,  ABR3 and six subnets F1,
   through F6.  As OPNET has no full duplex link model, each connecting
   link is modeled as two simplex links enabling bidirectional traffic.

                 [Figure 1: Network Layer of Debug Model]

3.2.1 Attributes

   The attributes of the elements of the network layer are:

   a. Area Border Routers and Backbone Routers

     1. IP address of each active interface of each router
        (network_id.node_id)
     2. Service rate of the IP layer (packets/sec)
     3. Transmission speeds of each active interface (bits/sec)

   b. Subnets

     1. IP address of each active interface of the router in the subnet
     2. IP address of the hosts in each of the subnet.
     3. Service rate of the IP layer in the subnet router and the hosts.

   c. Simplex links

     1. Propagation delay in the links
     2. The process model to be used for simulating the simplex links
        (this means whether animation is included or not).

3.2.2 LAN Subnets

   Figure 2 shows the FDDI ring as used in a subnet. The subnet will
   have one router and one or more hosts.  The router in the subnet is
   included to route the traffic between the FDDI ring or Ethernet in
   the corresponding subnet and the external network.  The subnet router
   is connected on one end to Ethernet or FDDI ring and normally also is
   connected to an area border router on another interface (the area
   border routers may be connected to more than one backbone router). In
   the Ethernet all the hosts are connected to the bus, while in FDDI
   the hosts are interconnected in a ring as illustrated in Figure 2.

                    [Figure 2: FDDI Ring Subnet Layer]





Pullen, et. al.              Informational                      [Page 4]

RFC 2490                 IP Multicast with RSVP             January 1999


   FDDI provides general purpose networking at 100 Mb/sec transmission
   rates for large numbers of communicating stations configured in a
   ring topology.  Use of ring bandwidth is controlled through a timed
   token rotation protocol, wherein stations must receive a token and
   meet with a set of timing and priority criteria before transmitting
   frames.  In order to accommodate network applications in which
   response times are critical,  FDDI provides for deterministic
   availability of ring bandwidth by defining a synchronous transmission
   service. Asynchronous frame transmission requests dynamically share
   the remaining ring bandwidth.

   Ethernet is a bus-based local area network (LAN) technology.  The
   operation of the LAN is managed by a media access protocol (MAC)
   following the IEEE 802.3 standard, providing Carrier Sense Multiple
   Access with Collision Detection (CSMA/CD) for the LAN channel.

3.3 Node layer

   This section discusses the internal structure of hosts and routers
   with the help of node level illustrations built using the Node editor
   of OPNET.

3.3.1 Basic OPNET elements

   The basic elements of a node level illustration are

   a. Processor nodes: Processor nodes are used for processing incoming
   packets and generating packets with a specified packet format.

   b. Queue node: Queue nodes are a superset of processor nodes. In
   addition to the capabilities of processor nodes,  queue nodes also
   have capability to store packets in one or more queues.

   c. Transmitter and Receiver nodes: Transmitters simulate the link
   behavior effect of packet transmission and Receivers simulate the
   receiving effects of packet reception.  The transmission rate is an
   attribute of the transmitter and receiving rate is an attribute of
   the receiver. These values together decide the transmission delay of
   a packet.

   d. Packet streams: Packet streams are used to interconnect the above
   described nodes.

   e. Statistic streams:  Statistic streams are used to convey
   information between the different nodes: Processor, Queue,
   Transmitters and Receivers nodes respectively.





Pullen, et. al.              Informational                      [Page 5]