📄 rfc2490.txt
字号:
Network Working Group M. PullenRequest for Comments: 2490 George Mason UniversityCategory: 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 RSVPStatus 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 13Pullen, 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 311. 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, noPullen, 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 19993.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]RFC 2490 IP Multicast with RSVP January 19993.3.2 Host description The host model built using OPNET has a layered structure. Different from the OPNET layers (Network, Node and Process layer) that describe
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -