RFC 2490

A Simulation Model for IP Multicast with RSVP

📅 published January 1999, from ietf

RFC 2490: A Simulation Model for IP Multicast with RSVP 🦋

Okay bestie, so this RFC is from January 1999 and it's an Informational doc, which means it's sharing info and isn't a standard 💅. The authors are M. Pullen (George Mason University), R. Malghan (Hitachi Data Systems), L. Lavu (Bay Networks), G. Duan (Oracle), J. Ma (NewBridge), and H. Nah (George Mason University) 👑. The header doesn't list any Obsoletes or Updates lines, so it isn't replacing or changing any other RFC 🎀.

Status of this Memo ✨

This memo gives information to the Internet community. It is not a standard of any kind, and anyone can distribute it freely 🌸.

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

Abstract 📄

So the big idea is this: the doc describes a super detailed model of IPv4 multicast with RSVP, built in the OPNET simulation package [4], with the protocol procedures written in C 🧚. It was made to dig into performance limits on routing, but it's giving "useful for lots of people in the multicast and resource reservation world" 🌈. And the authors are sharing it publicly so folks can run more studies on resource-reserved multicasting. Iconic, honestly 🔥.

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
           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 🌷

IP multicasting [1] works, and it's on the Mbone, so real-time multimedia apps keep blowing up 📈. The thing is, the Internet has always been best-effort, so people really want a way to reserve resources in networks running the Internet protocol suite. That way video, voice, and distributed simulation can hold steady at the levels they need 🎥🎙️. The RSVP protocol [2] was built for exactly this and people are still actively implementing it 🛠️. The RSVP developers did simulate stuff during design, but nobody had a generally available simulation of IPmc with RSVP to analyze performance or predict behavior 😭. This model fills that gap, and it's meant to be shared with the IETF community 🫶.

2. The OPNET Simulation Environment 🧪

OPNET (Optimized Network Engineering Tools) is a commercial product from MIL3 in Arlington, VA 🏢. It uses Discrete Event Simulation, which handles tons of closely spaced events in a big network accurately and efficiently 🚀. In OPNET, networks are made of components connected by perfect links that you can degrade whenever you like 🔗. Each component's behavior is a state-transition diagram, and the code that runs in each state is written in C 💻. The authors think this makes OPNET-based models pretty easy to port to other simulation environments 🦋. This model family works with OPNET 3.5 ✨. The sections that follow cover the state-transition models and process code for the IPmc and RSVP models built in OPNET. Heads up: an OPNET layer isn't necessarily the same as a layer in a network stack. What they share is that both are highly modular software pieces with well-defined interfaces 🧩.

3. IP Multicast Model 💜

Each subsection below walks through a layer in the host and the router, starting from the physical layer. Each one explains how it can be simulated using the matching OPNET network layer, node layer, or process layer 🌈.

3.1 Address format 🏷️

OPNET's IP model has just one addressing type, written as "X.Y". X is 24 bits and Y is 8 bits, which matches an IPv4 Class C network 📦. X is the source or destination network number, and Y is the source or destination node number. In this model, X = 500 is reserved for multicast traffic 🎀. For multicast, Y tells you which group the packet belongs to 👯.

3.2 Network Layer 🗺️

Figure 1 shows an example topology built with the OPNET network editor 🧭. The network has two backbone routers (BBR1 and BBR2), three area border routers (ABR1, ABR2, and ABR3), and six subnets (F1 through F6). OPNET doesn't have a full-duplex link model, so each link is modeled as two simplex links, which gives you bidirectional traffic 🔁.

                 [Figure 1: Network Layer of Debug Model]

3.2.1 Attributes 📋

The attributes for the network layer elements 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 used in a subnet 💍. Each subnet has one router and one or more hosts. The subnet router routes traffic between the FDDI ring or Ethernet in that subnet and the external network 🌐. On one end it connects to the Ethernet or FDDI ring, and it usually also connects to an area border router on another interface (area border routers can connect to more than one backbone router). On Ethernet, all the hosts hang off the bus. On FDDI, the hosts are connected in a ring, like in Figure 2 🔄.

                    [Figure 2: FDDI Ring Subnet Layer]

FDDI is general-purpose networking at 100 Mb/sec for lots of stations in a ring topology 💨. Ring bandwidth is managed with a timed token rotation protocol, so stations have to get a token and meet timing and priority criteria before they can send frames ⏱️. For apps where response time is critical, FDDI guarantees ring bandwidth with a synchronous transmission service 🎯. Asynchronous frame requests share whatever bandwidth is left over 🫧.

Ethernet is a bus-based LAN technology 🚌. The media access protocol (MAC) follows IEEE 802.3, which gives you Carrier Sense Multiple Access with Collision Detection (CSMA/CD) on the LAN channel 📡.

3.3 Node layer 🧩

This section looks at the inside of hosts and routers, using node-level diagrams built in the OPNET Node editor 🔍.

3.3.1 Basic OPNET elements 🧱

The basic parts of a node-level diagram are:

a. Processor nodes: These process incoming packets and generate packets in a specified packet format 🧠.

b. Queue node: Queue nodes are a superset of processor nodes. On top of what processor nodes can do, queue nodes can also store packets in one or more queues 📚.

c. Transmitter and Receiver nodes: Transmitters simulate the link effect of sending a packet, and Receivers simulate the effect of receiving one 📤📥. The transmission rate is an attribute of the transmitter, and the receiving rate is an attribute of the receiver. Together, those two values decide the transmission delay of a packet ⏳.

d. Packet streams: Packet streams connect the nodes described above 🔗.

e. Statistic streams: Statistic streams carry information between the Processor, Queue, Transmitter, and Receiver nodes 📊.

3.3.2 Host description 💻

Okay, next up is the host description, and it's where things get extra good 🔥. Part 2 is coming, so hang tight 🫶.

The host model is built in layers, and ya gotta see how they stack 💅 Unlike the OPNET layers (Network, Node and Process), which describe the network at different levels, the protocol stack bits live inside OPNET nodes 🧚. Figure 3 shows the node level structure of an FDDI host.

[Figure 3: Node Level of Host] 🎀

a. MAC queue node 🦋: The MAC talks to the physical layer on one side through the transmitter (phy_tx) and receiver (phy_rx), and it also serves the IP layer on the other. Ring bandwidth is controlled by a timed token rotation protocol, so hosts gotta receive a token and meet a bunch of timing and priority criteria before they can transmit frames. It's giving strict bouncer energy 🚪 When a frame shows up at the MAC node, one of these things happens:

  1. If the owner of the frame is this MAC, the MAC layer destroys the frame, since it's finished circulating through the FDDI ring 🗑️
  2. If the frame is destined for this host, the MAC layer makes a copy of it, decapsulates it, and sends the decapsulated frame (packet) up to the IP layer. The original frame gets transmitted to the next host in the FDDI ring 🔁
  3. If the owner of the frame is some other host and the frame isn't destined for this host, the frame gets forwarded to the adjacent host 💌

b. ADDR_TRANS processor node 🌸: Right above the MAC is the addr_trans processor node. This layer serves the IP layer by translating an IP address into a physical interface address. It accepts packets from the IP layer along with the next node information, maps that next node information to a physical address, and forwards the packet for transmission. This service is only needed in one direction, from the IP layer down to the MAC layer. Since no queuing happens at this level, a processor node handles the address translation from IP to MAC address (ARP) 🔍

c. IP queue node 👑: This is where network routing and forwarding in the hierarchy happens. The IP layer serves the higher level protocols above it by using the services the MAC layer provides. For packets arriving from the MAC layer, the IP layer decapsulates the packet and passes it up to an upper layer protocol based on the value of the protocol ID in the IP header. For packets arriving from upper layer protocols, the IP layer gets the destination address, calculates the next node address from the routing table, wraps it in an IP header, and forwards the packet to the addr_trans node along with the next node information 🎁

The IP node is a queue node, and this is where packets incur delay. That delay simulates how capable the host is at processing and the queueing for the outgoing link 😤 A packet arriving at the IP layer gets queued and experiences delay when it finds another packet already being transmitted, plus maybe other packets waiting in line for transmission. Packets arriving at the IP layer are queued and handled with a first-in first-out (FIFO) discipline 🙌 The queue size and the service rate of the IP layer are both promoted attributes, specified at the simulation run level by the environment file ⚙️

d. IGMP processor node 🫶: The models described so far are standard components in the OPNET libraries. On top of those, we added the host multicast protocol model IGMP_host, the router multicast model IGMP_gwy, and the unicast best-effort protocol model UBE 🌈

The IGMP_host node (Figure 4) is a process node, and packets are not queued in this layer. IGMP_host provides unique group management services for the multicast applications that use the services the IP layer provides. It maintains a single table of group membership information for the applications above the IGMP layer. What IGMP_host does depends on the type of packet it receives and where that packet came from 🧠

[Figure 4: IGMP process on hosts] 🖼️

The IGMP_host layer expects certain types of packets from the application layer and from the network:

  1. Accept join group requests from the application layer (which can be one or more applications): IGMP_host keeps a table with the membership information for each group. When an application sends a join request, it's asking to join a specific group N. The membership information gets updated. That new group membership information has to be shared with the nearest router and with the MAC layer. If IGMP_host is already a member of this group (meaning another application above IGMP_host is already in group N), IGMP_host doesn't have to send a message to the router or tell the MAC layer anything, so no extra drama 🙅‍♀️ If IGMP_host isn't a member yet, it generates a join request for group N (this is called a "response" in RFC 1112) and forwards it to the IP layer to be sent to the nearest router 📨 IGMP_host also passes this membership information to the MAC layer, which connects to the physical layer through the OPNET "statistic wire" running from IGMP_host to the MAC layer. That way the MAC layer knows the membership info right away and starts accepting frames destined for group N 🎯 (An OPNET statistic wire is a virtual path for sending information between OPNET models.)
  2. Accept queries arriving from the nearest router, and send responses based on the membership information in the multicast table at the IGMP_host layer: A query is a message from a router asking each host on the router's interface about its group membership. When IGMP_host gets a query, it checks the multicast group membership table to see whether any of the host's applications are registered for any group 👀 If any registration exists, IGMP_host schedules an event to generate a response after a random amount of time for each active group. The Ethernet example in Figure 5 and the description in the following section walk through the scenario 🎬
                   ---------------------------------------
                        |        |         |         |
                        |        |         |         |
                      +---+    +---+     +---+     +---+
                      | H1|    | H2|     | H3|     | R |
                      +---+    +---+     +---+     +---+

           Figure 5: An Ethernet example of IGMP response schedule

The router R connects to the subnet on one interface, I1, and reaches the hosts that way. Let's say hosts H1 and H3 are members of group N1 and H2 is a member of group N2 🌷 When the router sends a query, all the hosts receive it at the same time, t0. IGMP_host in H1 schedules an event to generate a response at a randomly generated time t1 (t1 >= t0), which will indicate that H1 is a member of group N1. Similarly, H2 schedules an event to generate a response at t2 (t2 >= t0) to indicate membership in group N2, and H3 schedules one at t3 (t3 >= t0) to indicate membership in group N3. When the responses are generated, they're sent with the destination address set to the multicast group address. So all member hosts of a group receive the responses sent by the other hosts on the subnet who belong to the same group 💕

In the example above, if t1 < t3, IGMP_host in H1 generates a response to update the membership in group N1 before H3 does, and H3 receives this response in addition to the router. When IGMP_host in H3 receives the response from H1, it cancels the event it scheduled at time t3, since a response for that group has already been sent to the router 🙅‍♀️✨ To make this work, the events for responding to queries are scheduled randomly, and the interval for scheduling these events is forced to be less than the interval at which the router sends queries ⏱️

  1. Accept responses sent by other hosts on the subnet, if any application layer is a member of the group the packet is destined for 🤝
  2. Accept terminate group requests from the application layer. The application layer generates these when an application decides to leave a group. IGMP_host updates the group information table and then won't send any response for this group, unless another application is still a member of it 🚪👋 When a router doesn't receive any response for a group within a certain amount of time on a specific interface, membership of that interface in that group gets canceled 💀

e. Unicast best-effort (UBE) processor node 🍓: This node generates best-effort traffic on the Internet based on the User Datagram Protocol (UDP). Its goal is to model background traffic in a network. This traffic does not use the services provided by RSVP 😌 The UBE node is meant to recreate the behaviour seen in a network where one type of application uses RSVP services to get specific levels of QoS, alongside best-effort traffic that only uses the services of the underlying IP, so it's giving realistic mix vibes 🌈

The UBE node generates traffic to a randomly generated IP address, which models competing traffic on the network from applications such as FTP. The packets go to the IP layer, which routes them based on the information in the routing table. The attributes of the UBE node are:

  1. Session InterArrival Time (IAT): the variable used to schedule an event that begins a session. The UBE node generates an exponentially distributed random variable with mean Session IAT, and starts generating data traffic at that time ⏰
  2. Data IAT: When the UBE generates data traffic, the interarrival times between data packets are the Data IAT. Decreasing the value of Data IAT increases the severity of congestion in the network 📈🔥
  3. Session-min and Session-max: When the UBE node starts generating data traffic, it stays in that session for a random period that's uniformly distributed between Session-min and Session-max 🎲

f. Multicast Application processor node 🧚‍♀️: The application layer is made up of one or more application nodes, which are process nodes. These nodes use the services of the lower layer protocols IGMP, RSVP and IP. The application layer models the requests and traffic generated by application layer programs. The attributes of the application layer are:

Okay bestie, picking up right where the host stuff left off 💅 these four knobs are basically the session party planner 🎀

  1. Session IAT 🦋 is the variable that schedules when a session kicks off. The Application node generates an exponentially distributed random variable with mean Session IAT, and at that moment it starts generating information for one specific group and also starts accepting packets belonging to that group ✨
  2. Data IAT 💜 is what sets the inter-arrival time between packets whenever the Application node is generating data traffic. The distribution can be any of the distribution functions available in OPNET 🌈
  3. Session-min and Session-max 🍓 bound how long an application stays in a session once it joins. A uniformly distributed random variable between Session-min and Session-max gets generated for this. At any given time, each node has zero or one flow(s) of data, so no multitasking, periodt 🙈
  4. NGRPS 🧚 bounds the group an application asks IGMP to join. The group gets picked at random from the range [0,NGRPS-1] 🔥

[Figure 6: Node Level of Gateway]

3.3.3 Router description 👑

Okay so there are two types of routers in this model: a router serving a subnet, and a backbone router. A subnet router has all the functions of a backbone router, and on top of that it has an interface to the underlying subnet, which can be either an FDDI network or an Ethernet subnet. We're gonna go deep on the subnet router in the next bit ✨

Figure 6 shows the node level model of a subnet router 🎀

a. The queueing technique in the router is a combo of input and output queueing 💅 The nodes rx1 to rx10 are the receivers connected to incoming links. The router in Figure 6 has a physical interface to the FDDI ring or Ethernet, made up of the queue node MAC, the transmitter phy_tx, and the receiver phy_rx. Backbone routers do not have a MAC layer 🫶 The services and functions of the MAC layer are the same as the MAC layer in the host we talked about above.

There's one major difference between the MAC node in a subnet router and the one in a host 👀 The MAC node in a subnet router accepts all arriving multicast packets, whereas the MAC in a host only accepts multicast packets for groups the host is a member of. Because of this, the statistic wire from the IGMP to the MAC layer doesn't exist in a router, and that's also because a subnet router doesn't have an application layer 😭

b. Addr_trans: The link layer in the router hierarchy is the addr_trans processor node, which translates IP addresses into physical addresses. The addr_trans node was described above under the host model 🧚

c. IP layer: The router IP layer provides services to the upper layer transport protocols and also performs routing based on the information in the routing table. The IP layer maintains two routing tables and one group membership table 🌸

The tables used by the router model are:

  1. Unicast routing table: This table is a single array of one dimension, used to route packets generated by the UDP process node in the hosts. If no route is known for a particular IP address, the corresponding entry is set to a default route 💖
  2. Multicast routing table: This table is an N by I array, where N is the maximum number of multicast groups in the model and I is the number of interfaces in the router. It's used to route multicast packets. The routing table in a router is set by an upper layer routing protocol (see section 4 below). When the IP layer receives a multicast packet with a session_id corresponding to a session that is utilizing the MOSFP, it looks up the multicast routing table to get the next hop 🦋
  3. Group membership table: This table maintains group membership information for all the interfaces of the router. It's also an N by I array, and it's set by the IGMP layer protocol. The routing protocols use the information in the group membership table to calculate and set the routes in the multicast routing table 🎀

Sub-queues: The IP node has three subqueues that implement queuing based on the priority of arriving packets from neighboring routers or the underlying subnet. The queue with index 0 has the highest priority 🔥 When a packet arrives at the IP node, it gets inserted into the appropriate sub-queue based on the priority of its traffic category: control traffic, resource-reserved traffic, or best effort traffic. Servicing uses a non-preemptive priority. After servicing, packets get sent to one of the output queues or the MAC, and they keep moving through these queues until the transmitter becomes available ✨

Attributes of the IP node are:

  1. Unique IP address for each interface (a set of transmitter and receiver constitute an interface) 💜
  2. Service rate: the rate at which packets are serviced at the router 💅
  3. Queue size: the size of each of the sub-queues used to store incoming packets based on priority can be specified individually 🌈

d. Output queues: The output queues do the job of queueing packets the IP layer receives when the transmitter is busy. A significant amount of queuing happens in the output queues only if the throughput of the IP node approaches the transmission capacity of the links 🍓 The only attribute of the queue node is:

Queue size: the size of the queue in each queue node. If the queue is full when a packet is received, that packet is dropped 💀

e. IGMP Node: The router also models IGMP for implementing multicasting, the routing protocol, and RSVP for providing specific QoS setup 🧚

The IGMP node implements the IGMP protocol as defined in RFC 1112. The IGMP node at a router (Figure 7) is different from the one at a host. The functions of the IGMP node at a router are:

  1. The IGMP node at a router sends queries at regular intervals on all its interfaces 🫶
  2. When IGMP receives a response to the queries it sent, it updates the multicast Group membership table in the IP node and triggers an MOSPF LSA update 🔥
  3. Every time the IGMP sends a query, it also updates the multicast group membership table in the IP node if no response has been received for the group on any interface, indicating that an interface is no longer a member of that group. This update is only done on entries that show an active membership for a group on an interface where the router hasn't received a response for the last query sent 😭
  4. The routing protocol (see ection 4 below) uses the information in the group membership table to calculate the routes and update the multicast routing table 👑
  5. When the IGMP receives a query (an IGMP at a router can receive a query from a directly connected neighboring router), the IGMP node creates a response for each of the groups it is a member of, on all the interfaces except the one the query was received through 🦋
  6. The IGMP node on a backbone router is disabled, because IGMP is only used when a router has hosts on its subnet 🙈

[Figure 7: IGMP process on routers]

4. RSVP model 🌈

Okay so the current version of the RSVP model supports only the fixed-filter reservation style 💅 The following processing happens in the indicated modules. The model is current with [2].

4.1 RSVP APPLICATION ✨

4.1.1 Init

This state initializes all variables and loads the distribution functions for Multicast Group IDs, Data, and termination of the session. It transits to the Idle state after completing all the initializations 🎀

4.1.2 Idle

This state has transitions to two states, Join and Data_Send. It transits to the Join state at the time the application is scheduled to join a session or terminate the current session, and it transits to the Data_Send state when the application is going to send data 🦋

4.1.3 Join

The Application sends a session call to the local RSVP daemon. In response, it receives the session Id from the local daemon. This makes a sender or receiver call. The multicast group id is selected randomly from a uniform distribution. While doing a sender call, the application writes all its sender information in a global session directory 💖

If the application is acting as a receiver, it checks the sender information in the session directory for the multicast group it wants to join, and then makes a receive call to the local RSVP daemon. Along with the session and receive calls, it makes an IGMP join call 🧚

If the application chooses to terminate the session it was registered to, it sends a release call to the local RSVP daemon and a terminate call to the IGMP daemon. After completing these functions, it returns to the Idle state 😭

[Figure 8: RSVP process on routers]

4.1.4 Data_Send

This state creates a data packet and sends it to a multicast destination that it selects. It updates a counter to keep track of how many packets it has sent. By default, this state returns to the Idle state 🫶

4.2 RSVP on Routers 🔥

Figure 8 shows the process model of RSVP on routers 💜

4.2.1 Init

This state calls a function called RouterInitialize, which initializes all the router variables. This state goes to the Idle state after completing these functions 🌸

4.2.2 Idle

Idle state transits to the Arr state upon receiving a packet 👀

4.2.3 Arr 💅

okay so Arr is the sorting-hat state 🎩✨ it checks what type of packet just showed up and then calls the right function for that message type. bestie, every message has its own handler, so let's go through them 🫶

  • a. PathMsgPro 🛣️: Arr calls this when a Path message comes in. Before it runs, OSPF routing gets recomputed so the router has the freshest routing table for forwarding that Path Message.
    1. First it looks for a Path state block (PSB) with a matching destination address. If the sender port, sender address, or destination port doesn't match the Session object of that PSB, it sends a path error message and returns. (Right now the application doesn't send any error messages, so we just print this one to the console 🙈)
    2. If it finds a PSB whose Session Object and Sender Template Object both match the incoming Path message, that PSB becomes the forwarding PSB 🎯
    3. Next it searches for a PSB whose session and sender template match the objects in the Path message and whose incoming interface matches the IncInterface. If it finds one, and the Previous Hop Address, Next Hop Address, or SenderTspec Object don't match the Path message, the Path message values get copied into that PSB and the Path Refresh Needed flag gets turned on. If the Previous Hop Address or Next Hop Address of the PSB differs from the Path message, the Resv Refresh Needed flag also gets turned on, and the Current PSB is set equal to this PSB 🔄
    4. If no matching PSB exists, a brand new PSB is created, the Path Refresh Needed flag gets turned on, and the Current PSB is set equal to it 🆕
    5. If the Path Refresh Needed flag is on, the Current PSB is copied into the forwarding PSB and the Path Refresh sequence runs. That sequence is handled by a function called PathRefresh. The Path Refresh message goes out to every interface in the outgoing interfaces list of the forwarding PSB 📤
    6. Next it searches for a Reservation State Block (RSB) whose filter spec object matches the Sender Template Object of the forwarding PSB, and whose Outgoing Interface matches one of the entries in the forwarding PSB's outgoing interface list. If it finds one, it sends a Resv Refresh message to the Previous Hop Address in the forwarding PSB and runs the Update Traffic Control sequence 🎀
  • b. PathRefresh 🔁: This one gets called from PathMsgPro. It builds the Path message and sends it out through the outgoing interface that PathMsgPro specified.
  • c. ResvMsgPro 🍓: Arr calls this when a Resv message arrives.
    1. It figures out the outgoing interface and checks for the PSB whose Source Address and Session Objects match the ones in the Resv message 👀
    2. If no such PSB exists, it's supposed to send a ResvErr message saying No Path Information is available. (We haven't implemented that message yet, so we just print an error to the console 💀)
    3. It checks for incompatible styles and then processes the flow descriptor list to make reservations, looking through the PSB list for sender info. If there's no sender info in the PSB list, it's supposed to send an Error message saying No Sender information. For every matching PSB it finds, if the Refresh PHOP list doesn't already have that PSB's Previous Hop Address, it adds it 📝
    4. It searches for a matching Reservation State Block (RSB) whose Session and Filter Spec Objects match the Resv message. If there isn't one, it creates a new RSB from the Resv message, sets the NeworMod flag On, and calls this RSB the activeRSB. It also turns on the Resv Refresh Needed flag 🆕
    5. If it does find a matching RSB, that RSB becomes the activeRSB. If its FlowSpec and Scope objects differ from the Resv message's, the Resv message's Flowspec and Scope objects get copied into the ActiveRSB and the NeworMod flag gets turned On 🔀
    6. It calls the Update Traffic Control sequence, which is done by calling the function UpdateTrafficControl 🚦
    7. If the Resv Refresh Needed flag is On, it sends a ResvRefresh message for each Previous Hop in the Refresh PHOP List. That's done by calling the ResvRefresh function once for every Previous Hop in that list 💌
  • d. ResvRefresh 💫: Both PathMsgPro and ResvMsgPro call this one, with an RSB and a Previous Hop as input. It builds the Resv message from the RSB and sends it to the Previous Hop.
  • e. PathTearPro 💔: Arr calls this when a PathTear message arrives.
    1. It searches for a PSB whose Session Object and Sender Template Object match the arrived PathTear message 🔍
    2. If no such PSB exists, it does nothing and returns 🙃
    3. If it finds a matching PSB, a PathTear message goes out to every outgoing interface listed in that PSB's Outgoing Interface list 📤
    4. It searches for all RSBs whose Filter Spec Object matches the Sender Template Object of the PSB. If the Outgoing Interface of an RSB is listed in the PSB's outgoing interface list, that RSB gets deleted 🗑️
    5. It deletes the PSB and returns 👋
  • f. ResvTearPro 🥀: Arr calls this when a ResvTear message arrives.
    1. It determines the Outgoing Interface 🧭
    2. It processes the flow descriptor list of the arrived ResvTear message 📋
    3. It checks for an RSB whose Session Object and Filter Spec Object match the ResvTear message. If there isn't one, it returns 🙅
    4. If it finds a matching RSB and the Resv Refresh Needed flag is on, it sends a ResvTear message to all the Previous Hops in the Refresh PHOP List 📨
    5. Finally, it deletes the RSB 🧹
  • g. ResvConfPro ✅: Arr calls this when a ResvConf message arrives. The Resv Confirm gets forwarded to the IP address stored in the Resv Confirm Object of the received ResvConf message.
  • h. UpdateTrafficControl 🎛️: PathMsgPro and ResvMsgPro both call this one, and its input is an RSB.
    1. It searches the RSB list for a matching RSB, one that matches the input RSB's Session Object and Filter Spec Object 🔎
    2. It computes the Effective Kernel TC_Flowspec for all of these RSBs 🧮
    3. If the Filter Spec Object of the RSB doesn't match the Filter Spec Object in the TC Filter Spec List, the Filter Spec Object gets added to the TC Filter Spec List ➕
    4. If the FlowSpec Object of the input RSB is greater than the TC_Flowspec, the Is_Biggest flag gets turned on 📈
    5. It searches for a matching Traffic Control State Block (TCSB) whose Session Object, Outgoing Interface, and Filter Spec Object match the input RSB 🕵️
    6. If no such TCSB is found, a new TCSB gets created 🆕
    7. If a matching TCSB is found, the reservations get modified ✏️
    8. If the Is_Biggest flag is on, the Resv Refresh Needed flag gets turned on. Otherwise, a ResvConf message gets sent to the IP address in the ResvConfirm Object of the input RSB 💌

4.2.4 pathmsg 🛤️

The jobs for this state all happen through the PathMsgPro function call we covered above 🫶

4.2.5 resvmsg 📩

The jobs for this state all happen through the ResvMsgPro function call we covered above ✨

4.2.6 ptearmsg 💔

The jobs for this state all happen through the PathTearPro function call we covered above 🥀

4.2.7 rtearmsg 🌷

The jobs for this state all happen through the ResvTearPro function call we covered above 🎀

4.2.8 rconfmsg ✅

The jobs for this state all happen through the ResvConfPro function call we covered above 💅

4.3 RSVP on Hosts 🖥️

Figure 9 shows the process of RSVP on hosts 🦋

                 [Figure 9: RSVP process on hosts]

4.3.1 Init 🌱

This state initializes all the variables and then transitions to the idle state by default ✨

4.3.2 idle 😴

This state transitions to the Arr state when a packet arrives 📬

4.3.3 Arr 🧚

This state calls the right function for the type of message received. It transitions to the idle state by default 💫

  • a. MakeSessionCall 🎬: Arr calls this whenever the local application makes a Session call.
    1. It searches for the Session Information 🔍
    2. If it finds it, it returns the corresponding Session Id 🆔
    3. If the session information isn't found, it assigns a new session Id to the corresponding session 🆕
    4. It makes an UpCall to the local application with this Session Id 📞
  • b. MakeSenderCall 📤: Arr calls this whenever the local application makes a Sender call.
    1. It gets the information for the Session Id and creates a Path message for this session 🛣️
    2. A copy of the packet is buffered, and the host uses it to send the PATH message periodically 🔁
    3. The packet goes down to the IP layer 🌐
  • c. MakeReserveCall 🎀: Arr calls this whenever the local application makes a Reserve call. This function creates and sends a Resv message. The packet is also buffered for later use 💾
  • d. MakeReleaseCall 👋: Arr calls this whenever the local application makes a Release call. This function generates a PathTear message if the local application is the sender, or a ResvTear message if the local application is the receiver 🫠

4.3.4 Session 🎞️

This state's job is done by the MakeSessionCall function 🎬

4.3.5 Sender 📣

This state's job is handled by the MakeSenderCall function 🙌

4.3.6 Reserve 🛎️

This state's job is done by the MakeReserveCall function 💖

4.3.7 Release 🕊️

This state's job is done by the MakeReleaseCall function 🌈

5. Multicast Routing Model Interface 🌐

Okay bestie, this section is the important one for anyone plugging a routing protocol into these models 👑

This set of models was built mainly so people could evaluate various multicast routing protocols through simulation. That's why this section pays extra attention to the steps needed to hook a routing protocol model up to the other models 🔥 We have implementations of DVMRP and OSPF available, and we'll describe them below. Instructions for running these models are in a separate User's Guide for the models 📖🫶

5.1 Creation of multicast routing processor node ✨

Okay so, to hook a multicast routing protocol up to the OPNET Simulation package, you have to make a brand-new routing processor node in the node editor and then link it up with packet streams 🦋. Packet streams are unidirectional links, which means one direction only. They connect processor nodes, queue nodes, transmitters and receiver nodes together. If you want a duplex connection between two nodes, you use two unidirectional links, one going each way 💖.

The multicast routing processor node gets linked (duplex, so both ways) to every processor that talks to it, which is the IGMP processor node and the IP processor node 🫶. To make a processor node, you click the processor creation button (the plain gray node on the node editor control panel), then click wherever you want it to go in the node editor 🌸. Once it's placed, you right click to bring up the attribute box and type in its name ✏️. For the links, you pick the packet stream button (it looks like two gray nodes joined by a solid green arrow on the control panel). Then you left click to choose the link's source and right click to mark where it ends 💅.

5.2 Interfacing processor nodes 🎀

The multicast routing processor node has a duplex connection to the IP processor node and another to the IGMP processor node 💜. A duplex connection here is two unidirectional links between the same nodes, so information or interrupts can flow both ways, as shown in Figure 6 ✨.

The IP processor node sits in the subnet router, and it's the hub of everything. It talks to the multicast routing processor node, the unicast routing processor node, the Resource Reservation processor node (RSVP), the ARP processor node (only on subnet routers and hosts), the IGMP processor node, and the MAC processor node (also only on subnet routers and hosts) 🧚. Every one of those is a duplex connection, except for ARP and MAC, which are the exceptions 🙈.

5.2.1 Interfacing ARP and MAC processor nodes 🍓

The ARP node only needs to serve traffic going from the IP layer down to the MAC layer, so you only need a unidirectional link from the IP processor node to the ARP processor node 🫶.

The MAC processor node on a subnet router is special: it receives multicast packets for all multicast groups in the subnet 👑. The MAC node on subnet hosts is different, since it only receives multicast packets addressed to its own multicast group 💅. Either way, the MAC node connects to the IP processor node with a single unidirectional link pointing from the MAC node to the IP node 🌈.

5.2.2 Interfacing IGMP, IP, and multicast routing processor nodes ⭐

The IGMP processor node talks to the multicast routing processor node, the unicast routing processor node, and the IP processor node 💖. Since IGMP is linked to the IP node, it can update the group membership table inside the IP node 😭. In this model, that group membership table is represented by the local interface (interface 0) of the multicast routing table data structure 🔥.

When IGMP updates that table, it sends a signal to the multicast routing processor node, which then re-checks the multicast routing table in the IP node 🦋. If the change in group membership means the multicast routing table needs to change, the multicast routing processor node works with the IP node to update the table so it matches the new group membership information IGMP just gave it ✨.

5.2.2.1 Modification of group membership table 🌸

Group membership changes when a host decides to join or leave a multicast group 🙈. The IGMP process on the gateway regularly sends queries to the IGMP processes on the hosts in its subnet 💜. The point is to figure out which hosts are actually receiving packets for particular groups 🧚.

If the gateway's IGMP doesn't get a response to a pending IGMP host query for a specific group, it concludes that no host in the subnet belongs to that group anymore 💀. That happens when the very last member of a multicast group in the subnet leaves 😭. When that happens, the IGMP processor node updates the group membership table and alerts the multicast routing processor node, which kicks off a change to the multicast routing table 🔥. A prune message for that group gets started and sent upward, which sets up a prune state for the interface leading to this subnet. That effectively removes the subnet from the group-specific multicast spanning tree 🌈. The prune message can keep going up the tree, potentially pruning more edges of the spanning tree as it travels higher ✨.

Joining a group is handled by the IGMP process too. It updates the group membership table, which may also lead to a change in the multicast routing table 🎀.

5.2.2.2 Dependency on unicast routing protocol 👑

The multicast routing protocol depends on a unicast routing protocol (RIP or OSPF) to handle multicast routing 💅. The next hop interface toward the source of a received packet, which is the upstream interface, is found using the unicast routing protocol. It traces the reverse path back to the packet's source 🦋.

If the packet arrived on this upstream interface, it can be forwarded downstream through the downstream interfaces, skipping the interface it came in on 🫶. If it didn't arrive on the upstream interface, the packet is treated as a duplicate and dropped, which stops it from going any further downstream 🙈. Doing this reverse path checking and broadcasting over and over is what eventually builds the spanning tree for routing multicast packets 🌳✨.

To find the reverse path forward interface for a multicast packet that was passed up from the IP layer, the multicast routing processor node grabs a copy of the unicast routing table from the IP processor node 💖. It then uses that copy to recalculate the multicast routing table in the IP processor node 🧚.

5.3 Interrupt Generation 💜

With the OPNET tools, interrupts to the multicast routing processor node can come from a few different places 🔥. The first is when a multicast packet arrives over a packet stream at the multicast routing processor node. The MAC node receives the packet and passes it up to the IP node, where the IP header gets discarded and it's decided which upper layer protocol the packet goes to 🌈.

The second kind is a remote interrupt from the IGMP process, which tells the multicast routing process that the group membership table has been updated ✨. The third happens when the specific source/group (S,G) entry for a multicast packet received at the IP node isn't in the current multicast routing table yet and needs to be created. In that case, the IP node sends an interrupt to the multicast routing processor node so it can create a new source/group entry in the multicast routing table 🎀.

5.3.1 Types of interrupts 🦋

Interrupts generated in the OPNET model get handled by specifying the interrupt type and the conditions for that interrupt 🫶. The condition is set with an interrupt code, which is just an integer that stands for a specific condition 🍓. Conditions are set on the interrupt stream that links the state generating the interrupt to the state it leads to 💅.

For self-interrupts (interrupts between states inside the same process), the type is OPC_INTRPT_SELF 🌸. For remote interrupts (interprocess interrupts), the conditions are set from the idle state to the state the interrupt leads to, inside the remote process 🧚.

Remote interrupts are of type OPC_INTRPT_REMOTE 💖. There's also a third type, OPC_INTRPT_STRM, which fires when packets arrive over a packet stream to signal that arrival 🙌. Its condition is set from the idle state to the resulting state, using an interrupt condition stream defined with a unique interrupt code 🔥. For all of these, the interrupt code lives in the header block (written in C) of the process being interrupted 👑. Once the condition for an interrupt becomes true, the process moves to the resulting state set on the interrupt stream ✨.

5.3.2 Conditions for interrupts 💀

The present OPNET Simulation Model has several interrupt connections that link the IGMP processor node, the IP processor node, and the multicast routing processor node together 🫶. The IP processor node also talks to the unicast routing protocol, which in turn talks to the IGMP processor node 🌈.

An OPC_INTRPT_STRM interrupt fires when a multicast packet comes over a packet stream from the IP processor node to the multicast routing processor node 🦋. An OPC_INTRPT_REMOTE interrupt goes from the IGMP process to the IP process whenever a group member leaves a group or a new member joins one 💅. The IGMP process then records that new membership in the group membership table in the IP node, and it sends a remote interrupt to the multicast routing protocol process as well. That causes the multicast routing table in the IP module to be recalculated 🎀.

5.4 Modifications of modules in the process model 🌸

Changes to routing protocol modules (really, to all the modules in the process model) get made transparently across the whole network using the OPNET Simulation tools 🧚. So any addition or modification to a routing module in one subnet shows up in all the subnets 💖.

6. OSPF and MOSPF Models 👑

OSPF and MOSPF models [5] are implemented in the OSPF model, which has fourteen states 💜. They only exist on routers 🙈. Figure 10 shows the process model, and the processing below happens in the modules indicated 🔥.

6.1 init 🌱

This state initializes all of the router variables 💅. The default transition goes to the idle state ✨.

6.2 idle 🫶

This state has several transitions 🦋. If a packet arrives, it moves to the arr state 🎀. Depending on which interrupts it receives, it moves to the BCOspfLsa, BCMospfLsa, or hello_pks state 🌈. In future versions, links coming up or going down will also cause a transition 🔮.

6.3 BCOspfLsa 🍓

The transition to this state from the idle state happens whenever the condition send_ospf_lsa is true. That happens when the network is being initialized, and when ospf_lsa_refresh_timout occurs ⏰. This state creates Router, Network, and Summary Link State Advertisements, then packs all of them into a Link State Update packet 🧚. That Link State Update packet is sent to the IP layer with a destination address of AllSPFRouters 💖.

           [Figure 10: OSPF and MOSPF process model on routers]

6.4 BCMospfLsa 💜

The transition to this state from the idle state happens whenever the condition send_mospf_lsa is true 🌸. This state creates Group Membership Link State Advertisements and packs them into an Mospf Link State Update packet 🫶. That Mospf Link State Update packet is sent to the IP layer with a destination address of AllSPFRouters 🦋.

6.5 arr 📬

okay so the arr state is the bouncer 💅 It checks what kind of packet just showed up and picks a function based on the protocol Id of that packet.

  • a. OspfPkPro: depending on which type of OSPF/MOSPF packet came in, it calls one of these:
    • 1. HelloPk_pro: runs whenever a hello packet arrives. It updates the router's neighbor information, which gets used later when the different LSAs are sent 🤝
    • 2. OspfLsUpdatePk_pro: runs when an OSPF LSA update packet shows up (router LSA, network LSA, or summary LSA) 📦 If the Router is an Area Border Router, or the LSA belongs to the Area whose Area Id is the Router's Area Id, it searches the Link State database to see if this LSA already exists. If it does, and the existing LSA's LS Sequence Number is less than the received LSA's LS Sequence Number, the existing LSA gets replaced with the received one. The Network LSA only gets processed if the router is a designated router or an Area Border Router. The Summary LSA only gets processed if the router is an Area Border Router. This function also turns on the trigger ospfspfcalc, which is the condition for moving from arr to ospfspfcalc 🔥
    • 3. MospfLsUpdatePk_pro: runs when a MOSPF LSA update packet arrives, and it updates the router's group membership link state database 💜

6.6 hello_pks 🌸

Hello packets get created and sent with the destination address of AllSPFRouters. Then it's the default transition to idle state, so the router just chills 😌

6.7 mospfspfcalc 🧮

This is where the shortest path tree and routing table get calculated, and it's giving math era ✨ This state transits to upstr_node when the detupstrnode condition is met.

  • a. CandListInit: depending on the SourceNet of the datagram, the candidate lists get initialized.
  • b. MospfCandAddPro: the vertex link gets examined. If the other end of the link is not a stub network and isn't already in the candidate list, it gets added after its cost to that vertex is calculated. If the other end is already on the shortest path tree and the calculated cost is less than what shows in the shortest path tree entry, the shortest path tree gets updated to show the calculated cost 📈
  • c. MospfSPFTreeCalc: the vertex closest to the root that's sitting in the candidate list gets added to the shortest path tree, and its link is considered for possible inclusion in the candidate list 🌳
  • d. MCRoutetableCalc: the multicast routing table gets calculated using the information from the MOSPF shortest path tree 🦋

6.8 ospfspfcalc 🌈

Same vibe here: this state calculates the shortest path tree, and then uses that info to build the routing table. It transitions to ospfspfcalc on the ospfcalc condition, and that condition gets set back to one after all the functions in the state are processed. Main character energy, literally 👑

  • a. OspfCandidateAddPro: this one initializes the candidate list by looking at the link state advertisement of the Router. For each link in that advertisement, if the other end is a router or transit network and it's not already in the shortest-path tree, the distance between these vertices gets calculated. If the other end isn't already on the candidate list, or the calculated distance is less than the value that appears for that other end, the other end gets added to the candidate list 🧩
  • b. OspfSPTreeBuild: pulls each vertex from the candidate list that's closest to the root and adds it to the shortest path tree. It deletes that vertex from the candidate list while it's at it, and keeps going until the candidate list is empty 🔁
  • c. OspfStubLinkPro: the stub networks get added to the shortest path tree in this procedure 🏝️
  • d. OspfSummaryLinkPro: if the router is an Area Border Router, it examines the summary links it has received. Then it looks up the route to the Area border router that advertised the summary LSA in the routing table. If that route is found, the routing table gets updated by adding the route to the network named in the summary LSA. The cost to that route is the sum of two things: the cost to the Area border router advertising it, and the cost to reach this network from that Area border router 💖
  • e. RoutingTableCalc: updates the routing table by examining the shortest path tree data structure 🎀

6.9 upstr_node 🫧

This state doesn't do anything in the present model. It just transitions to DABRA state, no drama 🙈

6.10 DABRA 📣

If the router is an Area Border Router and the area is the source area, a DABRA message gets constructed and sent to all the downstream areas. Default transition to idle state after that ✨

7. DVMRP Model 🦋

The DVMRP model is implemented based on reference [6], DVMRP version 3. There are nine states, and the DVMRP process only exists on Routers. Figure 11 shows the states of the DVMRP process 🗺️

7.1 Init 🌱

Initialize all variables, the routing table, and the forwarding table, and load the simulation parameters. It will transit to the Idle state after completing all the initializations.

7.2 Idle 😴

The simulation waits for the next scheduled event or remotely invoked event in the Idle State, and transits to the state that matches. In the DVMRP model, the Idle State has transitions to Probe_Send, Report_Send, Prune_Send, Graft_Send, Arr_Pkt, Route_Calc, and Timer states.

                [Figure 11. DVMRP process on routers]

7.3 Probe_Send State 👋

A DVMRP router sends Probe messages periodically to tell the other DVMRP routers that it's operational 💅 It lists all of its known neighbors' addresses in the Probe message and sends it to the All-DVMRP-Routers address. The routers won't process any message that comes from an unknown neighbor 🚫

7.4 Report_Send 📝

To avoid every DVMRP router sending a Report at the exact same moment (no thank you 🙅‍♀️), the interval between two Report messages is uniformly distributed with an average of 60 seconds. The router lists the source router's address, the upstream router's address, and the metric of all sources in the Report message, then sends it to the All-DVMRP-Routers address 📮

7.5 Prune_Send ✂️

The transition to this state is triggered by the local IGMP process. When a host on the subnetwork drops from a group, the IGMP process asks DVMRP to see if the branch should be pruned.

The router gets the group number from IGMP and checks the IP Multicast membership table to find out if there's any group member still in the group. If the router determines that the last host has resigned, it goes through the entire forwarding table to locate all sources for that group. It sends a Prune message, containing the source address, group address, and prune lifetime, separately for each (source, group) pair, and records the row as pruned in the forwarding table 🥀

7.6 Graft_Send 🌿

The transition to this state is triggered by the local IGMP process. Once a multicast delivery has been pruned, Graft messages are necessary when a host in the local subnetwork joins the group. A Graft message sent to the upstream router should be acknowledged hop by hop to the root of the tree, which is how end-to-end delivery gets guaranteed 🤝

The router gets the group number from IGMP and goes through the forwarding table to locate all traffic sources for that group. A Graft message gets sent to the upstream router with the source address and group address for each (source, group) pair. The router also sets up a timer for each Graft message waiting for an acknowledgement ⏰

7.7 Arr_Pkt 📥

All DVMRP control messages get sent up to the DVMRP layer by IP. What the DVMRP layer does depends on the type of message it receives 🧠

  • a. Probe message: the router checks the neighbors' list in the Probe message and updates their status to indicate the availability of its neighbors 🟢
  • b. Report message: by exchanging Report messages, the routers can build the Multicast delivery tree rooted at each source 🌲 A function called ReportPkPro handles all the possible situations when a Report message comes in. If the message is a poison reverse report and it's not coming from one of the dependent downstreams, the incoming interface should be added to the router's downstream list. If the message is not a poison reverse report but it came from one of the downstreams, that interface should be deleted from the downstreams list. After that, the router compares the metric it got from the message with the metric of the current upstream. If the new metric is less than the older one, the router's upstream interface should be updated 🔄
  • c. Prune message: the router extracts the source address, group address, and prune lifetime, then marks the incoming interface as pruned in the dependent downstream list of the (source, group) pair. If all downstream interfaces have been pruned, the router sends a Prune message to its upstream 🚪
  • d. Graft message: the router extracts the source and group address, then activates the incoming interface in the dependent downstream list of the (source, group) pair. If the (source, group) pair has been pruned, the router reconnects the branch by sending a Graft message to its upstream interface 🔗
  • e. Graft Acknowledge message: the router extracts the source and group address, then clears the Graft message timer of the (source, group) pair in the forwarding table ✅

7.8 Route_Calc 🛣️

The transition to this state is triggered by the local IP process. Once IP receives a packet, it fires a remote interrupt to DVMRP and asks DVMRP to prepare the outgoing interfaces for the packet 💌 The DVMRP process gets the packet's source address and group address from IP, then checks the (source, group) pairs in the forwarding table to decide which branches have group members on the Multicast delivery tree. The Group Membership Table on IP gets updated based on this knowledge 📋

7.9 Timer ⏱️

This state is activated once every second. It checks the forwarding table. If the Graft message acknowledgment timer has expired, the router retransmits the Graft message to the upstream. If the prune state lifetime timer has expired, the router grafts this interface so the downstream router can receive packets for the group again 🌊 The router also checks whether the (source, group) pair is pruned by the upstream router, and if so, it sends a Graft message to the upstream interface 🫶

8. Simulation performance 🏎️

Our simulations of three network models with MOSPF routing showed good scalability of the protocol, and honestly it slayed 💖 The running platform we used is an SGI Octane Station with 512 MB main memory and a MIPS R10000 CPU, Rev 2.7. Here's the real running time of each model, along with its major elements and the packet inter-arrival times for the streams generated in the hosts 📊

Simulated      Debug Model       Intermediate Model      Large Model
  time         11 Routers           42 routers           86 routers
                12 Hosts             48 hosts             96 hosts

              Reserve Data         Reserve Data         Reserve Data
                 0.01s                0.02s                 0.02s
           Best-effort Data      Best-effort Data      Best-effort Data
                 0.01s                0.025s               0.025s

  100 s        3 hours               14 hours             30 hours
  200 s        7 hours               30 hours               - - -

9. Future work ✨

okay so the authors are basically saying "we hope the IPmc/RSVP dev crowd here at the IETF helps us check and polish this model" 🫶 they think it could become a genuinely useful tool for predicting how RSVP-capable systems will behave 🔮 the main character energy of a model is being useful to other people 💅

10. Security Considerations 🔐

bestie, this one is short and sweet 🍓 this RFC raises no security considerations 💀 no threats, no drama, just a modelling doc 🌸

11. References 📚

  • [1] Deering, S., "Host Requirements for IP Multicasting", STD 5, RFC 1112, August 1989.
  • [2] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
  • [3] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
  • [4] MIL3 Inc., "OPNET Modeler Tutorial Version 3", Washington, DC, 1997
  • [5] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
  • [6] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress.

Authors' Addresses 🎀

J. Mark Pullen
C3I Center/Computer Science
Mail Stop 4A5
George Mason University
Fairfax, VA 22032

EMail: mpullen@gmu.edu


Ravi Malghan
3141 Fairview Park Drive, Suite 700
Falls Church VA 22042

EMail: rmalghan@bacon.gmu.edu


Lava K. Lavu
Bay Networks
600 Technology Park Dr.
Billerica, MA 01821

EMail: llavu@bacon.gmu.edu


Gang Duan
Oracle Co.
Redwood Shores, CA 94065

EMail: gduan@us.oracle.com


Jiemei Ma
Newbridge Networks Inc.
593 Herndon Parkway
Herndon, VA 20170

EMail: jma@newbridge.com


Hoon Nah
C3I Center
Mail Stop 4B5
George Mason University
Fairfax, VA 22030

EMail: hnah@bacon.gmu.edu

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💖

📦 where this page comes from