TMP E65 D

Understanding IP Model Internals and Interfaces
Session 1510 Lab Manual
1510 Understanding IP Model Internals and Interfaces
1510: Understanding IP Model Internals and Interfaces Lab 1: Building IP Lite

Overview
Your job is to implement a simple version of IP that will perform basic packet forwarding. Only router nodes will use this code. The requirement is to handle packets coming from higher layer and lower layer, perform a routing table lookup, and send the packet on its way. The flowchart for the packet processing is given in the presentation.
Objectives
In the course of this lab, you will learn to use various IP packages and get a closer look at the basic packet forwarding mechanism of IP. 1. Read IP header from incoming IP datagram using kernel procedures 2. Use the route table API to perform a routing table lookup 3. Use the interface API to obtain information about an interface, such as name etc. 4. Use the IP address API to check if an address belongs to an interface, etc. 5. Verify correct operation by running a simulation
Description
The simple mode IP does not support a number of advanced IP features, but is very efficient with respect to execution time. The ip_rte_central_cpu process model will be customized to optionally run in a simple mode. Users can enable the Simple IP mode by modifying a global attribute. This global attribute has been defined in the ip_rte_central_cpu process model present in the C:\op_models directory.
Instructions
NOTE: If you do not want to do the steps but just want to follow along, please open the process model named ip_rte_central_cpu_ref, and save it as ip_rte_central_cpu in the same folder. You can then follow the same instructions.
CONFIDENTIAL RESTRICTED ACCESS: This information may not be disclosed, copied, or transmitted in any format without the prior written consent of OPNET Technologies, Inc. 2007 OPNET Technologies, Inc.
Page 1 of 42
Inspect the Definition of the Global Attribute 1. Start OPNET Modeler. 2. Open the process model ip_rte_central_cpu present in the C:\op_models directory. 3. Examine the global attribute Simple IP. a. In the process model, click on Interfaces / Global Attributes.
b. Note that it is a toggle (Boolean) attribute that can either be Enabled or Disabled. c. Close the attribute dialog box. Examine the Process Architecture 4. Note that control can pass to one of two states from the init state. If the value of the variable simple_ip is TRUE and the node is a gateway node (router), then control passes to the simple ip state. Otherwise, it goes to the ip_central_cpu state. The simple ip state is a new state that has been added for this lab.
Page 2 of 42
5. Open the Enter Execs of the init state. a. Double-click on the top portion of the init state.
6. Code has already been added to read the global attribute to determine which IP mode must be used in the simulation.
7. The global attribute need not be read using op_ima_sim_attr_get () by each node. Its value can be read once and used by all the nodes. To facilitate this, the variable simple_ip has been defined in the header block as a static variable, so that the same value is seen by all instances of the process. a. Open the header block of the process (Code Blocks / Header Block or button). Observe the definition of simple_ip and first_time at the bottom of the text box.
b. Close the open text boxes. 8. Open the Exit Execs of the simple ip state. To open, double-click on the bottom portion of the simple ip state. This is the state that handles incoming IP datagrams. The code that is present here is the simple IP code. In the interest of time, parts of this block have already been written. You will fill in the gaps.
Page 3 of 42
Add Code to Process Packets 9. The first task is to obtain the packet from the stream. This has already been done. Observe the calls to op_intrpt_strm () and op_pk_get (). 10. Obtain the IP header from the packet. a. Under the banner that says ACCESS THE HEADER FIELDS, add the following line
11. Next task is to perform the routing table lookup. Under the banner ROUTE TABLE LOOKUP, add the following code.
12. Notice how the packets are discarded if the route table lookup fails. The function ip_rte_dgram_discard () is used to drop packets that cannot be routed. 13. Next, we have to determine the outgoing interface and the associated packet stream. To obtain the interface structure, we need the port_info obtained from the route lookup. Under the banner, OBTAIN OUTGOING INTERFACE AND STREAM, add the following code.
14. The rest of the code is all-complete and no additions are necessary. You will only examine the remaining steps. 15. For packets that are coming in from the lower layer, we have to determine if they should be accepted by this node and sent to the higher layer. a. The function inet_rte_intf_has_local_address () is used to check if the destination of the packet is an address on the interface. b. The function inet_address_is_broadcast_for_interface () is used to check if the destination address of the packet is a broadcast address and hence must be accepted. 16. For packets coming from the higher layer (i.e., generated by this node), the source address field of the packet may not be set. The address of the outgoing interface is set as the source address. This address is obtained using the function inet_rte_intf_addr_get ().
Page 4 of 42
17. Next, we have a section that will display the outcome of this function. This code can be conditionally executed from the OPNET Debugger (ODB). Observe the various elements of this block. No code additions are required. a. The function inet_address_print () can be used to get the string version of an address. b. The function ip_rte_intf_name_get () returns the name of an interface. 18. Finally, the packet is sent out. If the packet must be forwarded to another node, the kernel procedure op_pk_send () is used. If the packet is destined for this node, the function ip_rte_central_cpu_higher_layer_forward_simple () is used to send the packet to the higher layer. This function is defined in the function block. We cannot do a simple op_pk_send () to send data to the higher layer because the higher layer expects more information inside an ICI. 19. Close the function block and save the changes in the process model. a. Use File / Save to close the Exit Execs of the simple ip state. b. Use File / Save to save the process model. c. Use Compile / Compile Code to compile the process model. Verify the Correct Operation of the Packet Forwarding Code in a Simulation 20. Open the project 1510_Lab_1. a. Use File / Open (Project) / 1510_Lab_1. b. The project is present in the C:\op_models directory. c. The project should open in the scenario scenario1.
Page 5 of 42
Scenario description: There are three hosts and seven routers. Six ping demands have been configured among the three hosts. To make it easy to follow the sequence of events, the ping start times are staggered. This can be verified by right-clicking on any one of the ping demands and clicking on Edit Similar Demands.
You can close the dialog box when done.
Page 6 of 42
21. Click on the Configure / Run Discrete Event Simulation action button. 22. Configure the simulation to use the Simple IP mode of operation. In the tree view on the left panel, go to Inputs > Global Attributes and set Simple IP to Enabled.
23. OPNET Debugger has already been enabled. Click the Run button.
Page 7 of 42
24. You will see a single Simulation Execution window open. Inside this window, three tabs are defined: the Console tab provides an interface for the ODB commands and output, the Progress tab displays information about the overall simulation progress, and the Model tab allows the user an interactive view of the network where nodes can easily be selected for graphical debugging. Select the Console tab so further debugging can be accomplished on this scenario.
25. We have already seen that the first ping packet is sent out at 100 seconds. Advance the simulation till that time. a. In the ODB console (the ODB> box), enter the following commands: 1. tstop 100 (and then Enter) 2. cont (and then Enter)
Page 8 of 42
26. The simulation now stops at t = 100 seconds. Activate the trace label ip_rte and run it for one second. a. In the ODB console (the ODB> box), enter the following commands: 1. ltrace ip_rte (and then Enter) 2. tstop +1 (and then Enter) 3. cont (and then Enter) 27. You will see the trace statements that show the successful operation of simple IP. The simple IP code in invoked only on router nodes, as can be seen by the Simple IP tag in the trace statements.
28. Enter the command cont to finish the simulation. Close the open simulation window when the simulation completes.
Page 9 of 42
Extra CreditPerformance Evaluation One of the main advantages of the Simple IP mode of operation is its efficiency. In this segment, we will run a set of simulations to test the performance of this mode. The standard IP model already has an efficiency mode. A simulation will be run in all three modesdefault, IP processing efficiency mode, and the simple IP mode implemented in this lab, and the time taken to complete the simulation will be compared. The network to use for this study is present in scenario2. It is the same as the one in scenario1. The only difference is that the IP ping demands are replaced with IP traffic flows. Each of these flows generates 1000 packets per second, each of size 1000 bytes. 29. Switch to scenario2. First run will be with default configuration. Run the simulation and note the time taken to complete the simulation. 30. Next, duplicate the scenario (Scenarios / Duplicate Scenario) and name it ip_efficiency. Configure all nodes to use the standard model IP efficiency mode. a. Select all objects using CTRL+A. b. Right-click on one of the routers or hosts and select Edit Attributes. c. Set the attribute IP / IP Processing Information / Datagram Forwarding Rate to Efficiency Mode. d. Check the Apply Changes to Selected Objects checkbox at the bottom right corner and click OK. Click Yes if a warning box appears asking if you want to continue. e. Run simulation (Configure / Run Discrete Event Simulation) and note the time taken to complete it. 31. Next, duplicate the scenario2 scenario again and name it simple_ip. Configure the simulation to run in the Simple IP mode. a. Click the Configure / Run Discrete Event Simulation action button. b. Set the global attribute Simple IP to Enabled. c. Run simulation and note the time taken to complete it. 32. Questions: a. How do the three modes of operation compare with each other? b. How about the results? Are the demand statistics identical in all cases? If not, what could be the reason?
Page 10 of 42
Conclusion
In this lab, you learned to use IP API functions to perform various tasks 1. Obtain IP header from datagram 2. Route table lookup 3. Interface API to obtain interface information and perform address checks 4. IP address API to print addresses
END of LAB 1
Page 11 of 42
Lab 2: Interfacing a Custom Lower Layer to IP

Overview
The OPNET IP model has an open API that allows any custom MAC layer to interface with IP. In this lab you will interface a simple MAC layer to IP. Any lower layer interfacing with IP must perform the following four steps. Address assignment Process Registry Handle packets coming from IP Handle packets coming in from the network
Objectives
1. Interface the simple_mac MAC model to IP 2. Use a test network to verify proper operation
Instructions
The simple_mac Process The simple_mac process provides a custom lower layer which can be interfaced with the IP layer. This process will be used throughout this lab. 1. Open the process model simple_mac present in the C:\op_models directory.
Page 12 of 42
Initialization: Address Assignment Each MAC process in the network must have a unique integer address. This address may be manually assigned via an attribute or programmatically generated. The simple_mac process uses the OPNET auto-addressing package called oms_aa to assign addresses. This package is capable of assigning unique integer addresses to all or some of the nodes in the network. More information about this package is available in the session material of 1528Accelerating Model Development with OPNETs Model Support Libraries. The address must be assigned before proceeding to the next step (process registry). Initialization: Process Registry In this step, the MAC process must publish its address in the model-wide process registry so that the ARP module in each node can learn the MAC address. This information is later used to translate IP addresses to MAC addresses. The MAC process must set the following two attributes: Attribute Name protocol address Attribute Type OMSC_PR_STRING OMSC_PR_NUMBER (double) Attribute Value mac MAC address
The MAC process must publish these attributes by the third interrupt, because the ARP process performs discovery in the fourth interrupt.
Page 13 of 42
In the simple_mac process, this registry is occurring in the function simple_mac_oms_process_register (), which is called from the exit execs of the Register state. You can look at the function block (Code Blocks / Function Block or the process to see the call to oms_pr_process_register (). button) of
Handling a Packet from IP Handling a packet from IP involves the following steps: Identify an IP packet Determine the destination MAC address to which the packet needs to be sent Encapsulate the IP datagram in a MAC packet with the appropriate header Send the MAC packet to the transmitter
Page 14 of 42
Identifying an IP Packet
When the simple_mac process model receives a stream interrupt, it needs to decide whether the packet is from the ARP layer or from the receiver. This is done based on the input stream index. Refer to the transition macros PACKET_FROM_IP and PACKET_FROM_NTWK defined in the Header block (Code Blocks / Header Block or reproduced below. button) of the process model. The relevant lines are
/***** Transition Macros ******/ #define PACKET_FROM_IP (in_strm == SMC_IN_STRM_INDEX_FROM_ARP) #define PACKET_FROM_NTWK (in_strm == SMC_IN_STRM_INDEX_FROM_RCV) /* Macro corresponding to stream indices */ #define SMC_OUT_STRM_INDEX_TO_ARP 0 #define SMC_OUT_STRM_INDEX_TO_XMT 1 #define SMC_IN_STRM_INDEX_FROM_ARP 0 #define SMC_IN_STRM_INDEX_FROM_RCV 1
Note: The stream indices do not have to be hard-coded like this. Instead the MAC process can perform a graph walk at initialization and determine these values and store them as state variables. This approach was not used for this lab for the sake of simplicity.
Determining the Destination MAC Address
Every packet from the ARP layer will have an ICI of type ip_mac_req associated with the stream interrupt. The destination address of the packet will be specified in the dest_addr field of the ICI. Note: Since the ARP module reuses the ICI, the MAC layer SHOULD NOT destroy the ICI after handling the packet. For broadcast packets, the dest_addr field will be set to IPC_PHYS_ADDR_BROADCAST.
Page 15 of 42
Coding Changes
Make the Necessary Coding Changes to Handle a Packet from IP 2. Open the function block (Code Blocks / Function Block or process model. 4. Edit the function as follows. (Lines to be added are in bold). FIN (simple_mac_packet_from_ip_handle (ip_pkptr)); /* Get the ici associated with the interrupt. The /* destination address of the packet will be specified /* in the ici. arp_ici_ptr = op_intrpt_ici (); */ */ */ button) of the simple_mac
3. Scroll down to the simple_mac_packet_from_ip_handle function (line 105).
/* Get the destination address from the ici. */ op_ici_attr_get_int32 (arp_ici_ptr, "dest_addr", &dest_addr); /* Print a trace Message */ if (SMC_LTRACE_ACTIVE) { sprintf (msg, "Destination Address: %d", dest_addr); op_prg_odb_print_major ("Received a Packet from IP", msg, OPC_NIL); } /* Create the MAC Packet. mac_pkptr = op_pk_create_fmt ("simple_mac"); */
/* Set the source and dest addresses in the packet */ op_pk_nfd_set_int32 (mac_pkptr, "source address", my_address); op_pk_nfd_set_int32 (mac_pkptr, "dest address", dest_addr); /* Encapsulate the IP Datagram in the MAC Packet op_pk_nfd_set_pkt (mac_pkptr, "data", ip_pkptr); /* Send the packet out to the transmitter. op_pk_send (mac_pkptr, SMC_OUT_STRM_INDEX_TO_XMT); FOUT; */
*/
Page 16 of 42
Sending a Packet to IP The MAC process receives a packet from the network, it decapsulates the IP packet from the MAC packet and sends it to the ARP module. No ICIs are involved here. In the simple_mac process model this is performed in the function simple_mac_packet_from_ntwk_handle (no need to make any coding changes): FIN (simple_mac_packet_from_ntwk_handle (mac_pkptr)); /* Decapsulate the IP datagram from the packet. op_pk_nfd_get (mac_pkptr, "data", &ip_pkptr); /* Print a trace Message if (SMC_LTRACE_ACTIVE) { /* Get the source address from the packet op_pk_nfd_get (mac_pkptr, "source address", &source_address); */
*/
*/
sprintf (msg, "Source Address: %d", source_address); op_prg_odb_print_major ("Received a Packet from the Network", msg, OPC_NIL); } /* Send the packet to the higher layer. op_pk_send (ip_pkptr, SMC_OUT_STRM_INDEX_TO_ARP); /* Destroy the MAC packet. op_pk_destroy (mac_pkptr); FOUT;
Save and Compile the Process Model
*/
*/
5. Save and compile the process model. If you are having problems in compilation, you may: Close the simple_mac process model Open the simple_mac_ref process model Save it as simple_mac Recompile
Page 17 of 42
Test the Network

Open the Test Project
We will now use a simple network to verify that the MAC layer is working correctly. 6. Open the project 1510_Lab_2. If you did not make the coding changes to the simple_mac process model, you may use the 1510_Lab_2_Ref project. The project should open in the scenario named simple_ping_network.
Network Description
The network consists of two nodes of type simple_mac_wkstn connected to each other. A ping demand has also been configured from wkstn_1 to wkstn_2. The MAC and the IP addresses on both the nodes are set to Auto Assigned. The simulation IP auto-addressing package works with custom wireline MAC layers also. Shown below are the attributes for the wkstn_1 and wkstn_2 nodes which effect IP addressing. These attributes can be accessed by right-clicking on the node and selecting Edit Attributes.
Page 18 of 42
Run the Simulation in ODB 7. Click the Configure / Run Discrete Event Simulation action button. 8. In the treeview on the left, select Execution / OPNET Debugger. 9. Check the Use OPNET Simulation Debugger (ODB) checkbox in the right panel. 10. Click Run. When the simulation starts you will see a single Simulation Execution window open. Inside this window, three tabs are defined: the Console tab provides an interface for the ODB commands and output, the Progress tab displays information about the overall simulation progress, and the Model tab allows the user an interactive view of the network where nodes can easily be selected for graphical debugging. Select the Console tab so further debugging can be accomplished on this scenario.
Inspect Trace Messages We will run the simulation with a trace on the label simple_mac so that we can see the debug messages printed out by the simple_mac process model. 11. In the ODB console (the ODB> box), enter the following commands: c. tstop 105 (and then Enter). This command sets a breakpoint for 105 seconds. Our ping traffic starts at 100 seconds, so this is a good place to stop.
Page 19 of 42
d. ltrace simple_mac (and then Enter). This command enables trace for the label simple_mac. e. cont (and then Enter). This command executes the simulation until a breakpoint. Examine the trace messages. 12. Complete the simulation. a. cont (and then Enter).
13. Close the simulation window after the simulation completes.

Ping Results
The record route option was enabled for the ping demand. An output table entry is created corresponding to each successful ping demand. Verify that there is an entry corresponding to the ping demand. Verify Ping Results 14. Click the View Results action button (or right-click in the project workspace and select View Results) to open up the view results dialog box. 15. In the window that opens, click the DES Run (1) Table tab. 16. Select the Ping Report from the left treeview and click Show. Note that the ping demand was successful.
Page 20 of 42
Larger Network Scenario
The project also contains a second scenario named Larger_Network that consists of several simple_mac and ppp_wkstns connected using routers. Ping demands have been configured between many nodes.
Page 21 of 42
Switch to the Scenario Named Larger_Network 17. Choose Scenarios / Switch to Scenario / Larger_Network.
Run the Simulation 18. Select DES / Run Discrete Event Simulation. 19. After the simulation completes, click Close.
Page 22 of 42
Verify Ping Results 20. Click the View Results action button to open up the view result dialog box.
21. Click the DES Run (1) Table tab. Note that there are Ping Reports corresponding to all the ping demands in the network. This shows that IP can route between different interface types.
END OF LAB 2
Page 23 of 42
Lab 3 Interfacing a Custom Higher Layer to IP

Overview
The OPNET IP model has an open API that allows any custom higher layer to interface with IP. In this lab we will interface a simple traffic generator to IP. All higher layers interfacing with IP must perform the following tasks: Register with IP as a higher layer protocol Register with the process registry Send packets to IP Handle packets coming from IP
Objectives
1. Interface the simplified_rpg_dispatcher model to IP 2. Use a test network to verify proper operation
Instructions
The simple_mac Process The simplified_rpg_dispatcher process provides a custom higher layer which can be interfaced with the IP layer. This process will be used throughout this lab. 1. Open the process model simplified_rpg_dispatcher present in the C:\op_models directory.
Initialization: Register with IP as a Higher-Layer Protocol This step is required to inform IP of the new higher-layer protocol. If the higher layer does not specify a specific value, then IP generates a unique protocol number. The protocol value is used in the IP header. IP associates the protocol number with this higher layer, so the higher layer does not need to store the protocol number returned by IP.
Page 24 of 42
The function Ip_Higher_Layer_Protocol_Register () (declared in ip_higher_layer_proto_reg_sup.h) is used for this purpose. In this lab, the process simplified_rpg_dispatcher performs this step in the function rpg_dispatcher_register_self () which can be found inside the function block for this process (Code Blocks / Function Block or button).
Initialization: Register with the Process Registry This step is necessary for the ip_encap_v4 process to discover this higher layer process. A string attribute called protocol must be published and its value must be set to the same value as the one used in the previous step. Also, this step must be completed in the first event (before reaching the first unforced (red) state), because ip_encap performs the discovery in the second round of events. In this lab, the process simplified_rpg_dispatcher performs this task also in the function rpg_dispatch_register_self (). Note that it uses the same string rpg for registering with IP and with the process registry.
Page 25 of 42
Sending a Packet to IP Each higher layer packet sent to ip_encap must be accompanied by an ICI of format ip_encap_req_v4 [See figure below]. The destination address of the packet must be specified in the dest_addr field of the ICI. All other fields are optional. If you want your higher layer to support both IPv4 and IPv6, use the inet_encap_req ICI and set a pointer to an InetT_Address in the destination address field.
Note that the ip_encap process will not destroy the ICI after handling the packet. This means the higher layer process must retain a handle to the ICI, say by storing it as a state variable, and re-use it for subsequent packets. In the simple_rpg_dispatcher process model, the ICI is created and stored as a state variable in the rpg_dispatcher_sv_init function.
Page 26 of 42
Steps Involved The steps involved in sending a packet to IP are listed below: Set the destination address in the ICI. Install the ICI. Send the packet. Uninstall the ICI.
Note: Since we are reusing the ICI, we should use op_pk_send_forced () rather than op_pk_send () to send the packet to IP. Otherwise, if two packets are generated at exactly the same time, the second packet might overwrite the ICI before ip_encap can handle the first packet. We can also set the TOS value in the ICI. This will be used in the IP datagram.
Coding Changes
We will now make the necessary changes to the rpg_generate_packet() function so that it sends packets to IP correctly. 2. Open the function block of the simplified_rpg_dispatcher process model and go to line #116. Change the function as shown below. (Lines to be added are shown in bold.) /* Print out a trace message. */ if (LTRACE_RPG_ACTIVE) { ip_address_print (dest_address_str, rpg_flow_info_array[row_num].dest_address); op_prg_odb_print_major ("Sending a packet to the address", dest_address_str, OPC_NIL); } /* Set the destination address in the ici. */ op_ici_attr_set (ip_encap_req_ici_ptr, "dest_addr", rpg_flow_info_array[row_num].dest_address); /* Install the ici op_ici_install (ip_encap_req_ici_ptr); /* /* /* /* Send the packet. Since we are should use op_pk_send_forced. generate a packet at the same generation will overwrite the */
reusing the ici we */ Otherwise if two flows */ time, the second packet*/ ici before the first */
Page 27 of 42
/* packet is processed by ip_encap. op_pk_send_forced (pkt_ptr, 0); /* Uninstall the ici. op_ici_install (OPC_NIL); FOUT; Receiving a Packet from IP
*/
*/
When IP sends a packet to the higher layer, the stream interrupt will have an ICI of format ip_encap_ind_v4 associated with it. This ICI contains information related to the packet such as the source IP address, the interface on which the packet was received etc. Since the ip_encap process creates a new ICI for each packet it sends to the higher layer, this ICI must be destroyed after handling the packet. In the simple_rpg_dispatcher process model a packet from IP is handled in the function rpg_packet_destroy (). This function does the following: Gets the packet and the associated ICI. Prints out a trace message. Destroys the packet and the ICI.
An excerpt from this function is shown below. No coding changes are required in this function. /* Get the ip_encap_ind_v4 accompanying the packet ip_encap_ind_ici_ptr = op_intrpt_ici (); */
/* Print a trace message */ if (LTRACE_RPG_ACTIVE) { /* Get the source address from the ici. */ op_ici_attr_get (ip_encap_ind_ici_ptr, "src_addr", &src_address); ip_address_print (src_address_str, src_address); op_prg_odb_print_major ("Received a packet from", src_address_str, OPC_NIL); } /* Destroy the ici. op_ici_destroy (ip_encap_ind_ici_ptr); /* Get the packet and destroy it packet_ptr = op_pk_get (0); op_pk_destroy (packet_ptr); */
*/
Page 28 of 42
Compile the Process Model 3. Save and compile the process model. If you are having problems in compilation, you may: a. Close the simplified_rpg_dispatcher process model. b. Open the simplified_rpg_dispatcher_ref process model. c. Save it as simplified_rpg_dispatcher. d. Recompile.
Using the Test Network

Open the Test Project
We will now use a simple network to verify that the packet generator is working correctly. 4. Open the project 1510_Lab_3. If you did not make the coding changes to the simplified_rpg_dispatcher process model, use the 1510_Lab_3_Ref project. The project should open with the scenario named example_network.
Network Description
The network consists of four ppp_simplified_rpg workstations connected using routers. Wkstn A is sending 10 pkts/sec of traffic to the each of the other three workstations.
Page 29 of 42
Run the Simulation 5. Select DES / Run Discrete Event Simulation to run the simulation. 6. Click Close in the simulation sequence window after the simulation completes. Verify that Traffic is Flowing Across the Network 7. Click the Hide/Show Graph Panels action button to open the stored templates.
8. Select DES / Panel Operations / Panel Templates / Load With Latest Results.
Page 30 of 42
9. As expected, there is 30 pkts/sec of traffic from wkstn A to Router A and 10 pkts/sec from Router A to each of the other routers.
If you are not seeing the same results as the figures above when using the panel templates, you can manually check each Throughput (packets/sec) link statistic by right-clicking on either the wkstn A <-> Router A, Router A <-> Router B, Router A <-> Router C, and Router A <-> Router D link and selecting View Results. This will allow you to see the statistics for each link and should provide the same results as above. Repeat the process for each link to see all of the statistics.
Page 31 of 42
END OF LAB 3
Page 32 of 42
Appendix Appendix 1: Creating Node Models with Custom Lower and Higher Layers
Topology / Create Custom Device Model The Create Custom Device Model utility under the Topology menu allows users to create custom node models. Node model types that can be created include routers, switches, and multi-homed clients and servers. The number of interfaces/ports of each type in the node model is configurable.
Page 33 of 42
Node Models with Custom Process Models One of the limitations of device creator is that it cannot be used to create node models with custom process models. This section describes a few things to keep in mind while creating nodes with your own models. The first section lists some general tips to keep in mind when creating any node model. The subsequent sections talk about node models with custom higher and lower layers respectively. General Tips 1. Changing the model of a node in a project can lead to errors. For this reason, you should always create node models with more interfaces than you actually need. The IP model will ignore any unused interfaces. 2. Never add/remove interfaces from an IP node model. The attribute changes required for this are too many. 3. Do not make any changes to a standard node model directly. Save it in your op_models directory under a different name first.
Page 34 of 42
4. Do not save any custom models under the opnet installation directory. They might get overwritten if the software is re-installed. Use your op_models directory for this purpose. Node Model with a Custom Higher Layer Adding a custom higher layer to a node model is relatively simple because a node typically has only one instance of the higher layer. 1. Start with an appropriate standard or Device Creator node model (Refer to tips #1 and #3 under General tips). 2. Add the modules corresponding to your custom higher layer to the node model. 3. Do not remove any of the existing modules even if they will not be used in your network. Node Model with Custom Lower Layers Creating node models with custom lower layers is slightly more difficult because a multi-homed node can have several interfaces and each of these interfaces will need to be modified individually. 1. Use Device Creator to create a node model that has enough interfaces. 2. Use an appropriate standard interface type instead of the custom MAC layer. For example, if the custom MAC layer interface structure is similar to that of Ethernet, use Ethernet interfaces instead of the custom MAC layer interfaces. 3. Open the node model in the node editor and change each interface manually. Remember, do not add/remove interfaces. 4. Update the default value of the MTU under IP Routing Parameters Interface Information MTU for each custom interface if necessary. To identify the row corresponding to a particular interface, check the value of the ip addr index attribute on the streams connecting it to the ip module. The value of this attribute is the row number. (Note that row numbers start at 0.) 5. If you follow the interfacing procedure described in this session and use the standard ARP layer for interfacing, there is nothing more to be done. 6. If you have to remove the arp module, here are a few additional things to keep in mind. The packet streams connecting the ip module to an interface have an extended integer attribute named ip addr index. The value of this attribute will be unique for each interface. Note the value of this attribute on the streams that are being removed and add this attribute with the same value to the new streams that are used to connect the MAC layer to the IP module.
Page 35 of 42
Appendix 2: Interfacing to the IPv6 Model

During the session, we saw how lower and higher layers can be interfaced to the OPNET IP model. But the session discussed models that use IPv4 only. This section describes interfacing custom higher and lower layers to handle IPv6 packets. Interfacing a Custom Lower Layer to IPv6 Since ARP performs the translation between IP and MAC addresses, the MAC layer does not need to deal with IP addresses directly. So any custom MAC layer that is interfaced to IP using the steps described in lab 2 will also be able to handle IPv6 packets without any changes. InetT_Address Structure Before discussing interfacing of higher layers to IPv6, it is necessary to familiarize ourselves with a new structure, named InetT_Address that was introduced in the IP model. InetT_Address is a data structure that can represent either an IPv4 address or an IPv6 address. Most of the API functions that were available with the older IpT_Address structure are available for InetT_Address also. Some of the most commonly used functions are listed below. For a more comprehensive list, refer to the header file ip_addr_v4.h. The corresponding function definitions are in ip_addr_v4.ex.c: inet_address_create inet_address_copy inet_address_print inet_address_destroy
Note that unlike the IpT_Address structure, which is typedefed to an unsigned int, InetT_Address is an actual structure with internal pointers. This means that functions like inet_address_copy and inet_address_destroy should be used correctly to avoid memory errors and leaks. Interfacing a Custom Higher Layer to IPv6 The steps involved in interfacing a custom higher layer to IPv6 are similar to those for interfacing to IPv4. The high-level steps are reproduced here for your reference. 1. Register with IP and the oms process registry. 2. The destination address of packets sent to IP must be specified in an ICI. 3. Packets from IP will have an associated ICI containing additional information. The main differences in these steps from the one described in Lab 3 are given below. Note that since the InetT_Address structure can support both IPv4 and IPv6, this approach will work for both IPv4
Page 36 of 42
and IPv6. So even if your higher layer model has to handle both IPv4 and IPv6 packets, the steps listed below alone are adequate.
Registration
The function that needs to be used to register with IP is Inet_Higher_Layer_Protocol_Register (). The arguments to this function are the same as those of Ip_Higher_Layer_Protocol_Register (). Registration in the oms_process_registry as described in Lab 3 is still required.
Sending a Packet to IP
The ICI format to be used is inet_encap_req. The fields in this ICI are similar to that of ip_encap_req_v4 except for the fact that the address fields should be set to pointers to InetT_Address. The note about the reusing of ICI and the need to use op_pk_send_forced still apply. The higher layer is also responsible for managing the memory allocated to the InetT_Address structures. Ip_encap does not free this memory after handling the packet. Refer to the Enter Execs of the SEND state in the rip_udp_v3 process model for an example.
Page 37 of 42
Handling a Packet from IP
If a higher layer registered with IP using Inet_Higher_Layer_Protocol_Register, packets sent to that higher layer from IP will have an ICI of type inet_encap_ind associated with the stream interrupt. The fields in this structure are similar to that of inet_encap_ind_v4 except for the fact that the address fields (src_addr, interface_received and dest_addr) are now pointers to InetT_Address structures. The higher layer is responsible for freeing the memory associated with the InetT_Address structures and the ICI itself. Note that this is true even for fields that are not actually used by the higher layer. Refer to the Enter Execs of the ARRIVE state in the rip_udp_v3 process model for an example.
Page 38 of 42
Appendix 3: Interfacing Wireless MAC Layers to IP

Lab 2 described the interfacing of any custom MAC layer to the IP model. This section describes some additional things to keep in mind when interfacing a wireless MAC layer. Use of Radio Transceivers There are two main approaches that model developers use to model a wireless link. 1. Use radio transceivers and thus use the OPNET radio module. 2. Use op_pk_deliver to send packets between nodes. If you use approach #1, you can ignore this section and move on the section titled Auto Addressing. But if you are using approach #2, note that IP expects every interface to have a transmitter and a receiver associated with it. So you should connect a radio transmitter and receiver to the MAC layer to make sure that IP recognizes it to be an interface. Since no packets will ever be sent to these transmitters, they will not affect your simulations in any way. Auto Addressing The simulation IP auto addressing code cannot handle custom wireless interfaces. This section describes some of the coding changes required to make the IP auto addressing code work with your custom wireless MAC layer. The simulation IP auto-addressing package depends on the ability to group connected IP interfaces into subnets. Since IP cannot group custom wireless interfaces into IP subnets, it assumes that all of them are part of the same IP subnet and assigns them IP addresses accordingly. In the case of standard wireless interface types like wireless LAN (802.11) and UMTS, additional code has been added to the IP auto addressing package to look at attributes like BSS ID (in the case of wireless LAN) and Domain ID (in the case of UMTS) of the wireless interface to group them into subnets. The coding changes described in this section would essentially make the IP auto-addressing package do the same for your custom MAC layer. Note 1: IP groups all custom wireless MAC layers into a single IP subnet. So coding changes are required only if your network will have more than one IP subnet containing custom wireless MAC layers. Note 2: The coding changes that are described in this section are complex. So try this approach only if you feel that none of the alternative approaches described in the section titled Alternative Approaches are adequate in your case. Note 3: The OMS auto addressing package for assigning MAC addresses, described in Lab #2, is not related to the IP auto-addressing package. OMS auto addressing will work fine for wireless MAC layers also.
Page 39 of 42
The high-level steps to be followed for adding this functionality are listed below. 1. Pick a criterion that can be used to group the wireless interfaces into IP subnets. The attribute used for this purpose should be published in the OMS process registry as domain_id. Possibilities include: Some kind of MAC attribute. All interfaces that are in the same IP subnet should have the same value for this attribute. One problem with this approach is that it might be necessary to manually configure this attribute on each node. OPNET subnet ID. If you construct your network in such a way that all wireless interfaces that belong to an IP subnet are in the same OPNET subnet, you can use the subnet ID as a criterion for grouping interfaces. This approach will fail if you have a multihomed node with interfaces in more than one wireless IP subnet.
2. While registering in the OMS process registry, the attribute mac_type should be set to an appropriate value to distinguish these interfaces from other types of interfaces. 3. If multiple custom MAC layer interfaces on a node are to be supported, the object ID of the wireless transmitter connected to the MAC layer should be published as an attribute named ratx_objid in the OMS process registry. 4. Modify the function named ip_radio_address_resolve in ip_auto_addr_sup_v4.ex.c to handle your custom MAC layer. Alternative Approaches The coding changes required to make IP auto addressing work over a custom wireless MAC layer are complex. This section describes some alternative approaches through which you can avoid them. 1. Use manual addressing: If the network that you are modeling is not large, manually assigning addresses to each node might be the best option. 2. Use XML export/import. OPNET has a feature by which all the nodes in a network and the attributes on each of them can be exported to an XML file. So another way of assigning addresses would be to use a script to set the addresses in the XML file and then re-import the network from the XML file. Exporting of a network to an XML file can be done by selecting Topology / Export Topology / To XML Importing a network from an XML file can be done by selecting Topology / Import Topology / From XML
Page 40 of 42
Appendix 4: Tips on Debugging

IP provides several traces, reports, statistics etc. that can be used to isolate errors that are occurring in the network. This section describes some of them that you might find useful in debugging any problems that could occur in a network containing IP. These tips are not listed in any particular order. So the only way to use this document is to read through it completely once, understand the functionalities available, and refer back to this document for details if you need a specific feature. IP Traces IP model has several traces that can be used to diagnose its functions. These traces may be enabled on per process, per module or globally depending on what you are trying to debug. Use the odb command lmap ip for a more complete list of available ip traces. ip_addresses: This trace can be used to troubleshoot problems with the simulation auto addressing package. A trace message is printed out every time an interface is assigned an address. Once addressing is complete, a table containing all addresses is also printed out. ip_cmn_rte_table: A trace message will be printed out corresponding to any changes to the IP common route table if a trace on this label is enabled. Note that if this trace is being enabled either globally or on the dynamic routing protocol module/process that is actually inserting the entry. ip_cmn_rte_table_lookup: Every time a lookup for a destination address is performed in the IP common route table, a trace message can be printed out enabling the trace on this label. ip_rte: If the trace on ip_rte is enabled, IP will print out a trace message every time it handles the packet. The trace message printed out will include the destination address of the packet, the interface on which the packet was received, the next hop to which the packet is being forwarded and the output interface. ip_frag: This trace can be used to generate a trace message every time a packet is fragmented/reassembled at the IP layer.
Diagnostic Block Traces A lot of useful information can be obtained by executing the diagnostic block of the ip_dispatch process model with traces on specific labels enabled. The various labels available and their purposes are given below. ip_interfaces: A table containing the list of connected interfaces and the addresses assigned to each interface will be printed out. ip_rte_table: The IP forwarding table of the node will be printed out. A more user-friendly way to access this information is to look at the ip route table reports. This is covered in the section titled Reports.
Page 41 of 42
ip_table: Print out the contents of the global table used by ARP to map between IP and MAC addresses. This can be very useful to debug problems arising during the interfacing of a custom lower layer to IP. ip_frag: Prints out the list of incomplete IP fragments at a node. If a packet had to be fragmented at the IP layer, the destination node will forward it to the higher layer only after it receives all the fragments.
Reports The IP module can be configured to generate several useful reports in the output table. To access these reports, click on the View Results action button and select the Discrete Event Tables tab. IP Forwarding table report: A node can be configured to export its IP routing table at specified times during the simulation. This configuration is done under the Reports IP Forwarding Table attribute. Ping record route report: If the Record route option is enabled in the ping parameters configuration, a report containing the route chosen by the ping demand will be generated. Use Protocols / IP / Demands / Configure Ping traffic on selected nodes to configure ping demands easily.
Other Useful Tools Reachability Analysis: If a node in a network does not have a route to a particular destination as expected, it will be useful to know which all nodes in the network do have a route to that destination. Reachability analysis makes it easy to obtain this information. Reachability Analysis is described in greater detail in the IP model user guide. Record route for traffic demands: The record route feature of traffic demands can be used to determine the route chosen by traffic between a pair of nodes in the network. The main advantage of this approach over the ping record route approach is that an option is available to visualize the routes using path objects. This feature also displays the route chosen by the traffic through lower layer networks. Use Traffic / Create IP Traffic Flows to create traffic demands. The record route feature for the demand is enabled by default. Use Protocols / IP / Demands / Display routes for configured demands to visualize the route chosen by each demand. Interface table export: Enabling the export option in the simulation attribute IP Interface Addressing Mode would make the simulation generate a gdf file titled <project>-<scenario>ip_addresses.gdf. This can be very useful to make sure that IP does not mistakenly think that an interface is not connected.
Page 42 of 42

TMP E65 D

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TMP E65 D

Transféré par

Droits d'auteur :

Formats disponibles

Understanding IP Model Internals and Interfaces

Session 1510 Lab Manual

1510 Understanding IP Model Internals and Interfaces

1510: Understanding IP Model Internals and Interfaces Lab 1: Building IP Lite

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

You can close the dialog box when done.

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

Lab 2: Interfacing a Custom Lower Layer to IP

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

3. Scroll down to the simple_mac_packet_from_ip_handle function (line 105).

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

Test the Network

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

13. Close the simulation window after the simulation completes.

1510 Understanding IP Model Internals and Interfaces

Larger Network Scenario

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

Lab 3 Interfacing a Custom Higher Layer to IP

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

Using the Test Network

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

Appendix 2: Interfacing to the IPv6 Model

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

Handling a Packet from IP

1510 Understanding IP Model Internals and Interfaces

Appendix 3: Interfacing Wireless MAC Layers to IP

1510 Understanding IP Model Internals and Interfaces

1510 Understanding IP Model Internals and Interfaces

Appendix 4: Tips on Debugging

1510 Understanding IP Model Internals and Interfaces

Vous aimerez peut-être aussi