Familiarize yourself with these instructions. Return a screen capture, that shows the communication traffic between the client and the server and the filtered packet capture of the traffic OR the source codes you have modified if your implementation does not work.

1. (4p) Implement sending of RTSP messages to the client.
2. (4p) Implement making of the RTP packet.
3. (2p) Capture loopback traffic, that shows all possible RTSP messages (that your client can generate) and the RTP traffic.

Multacast client used for this course is TIEA322MulticastChat.jar. Start an instance or few of the client, join a multicast group and send some text

1. (1p) Capture the traffic and return a filtered capture
2. (1p) What are the IP and MAC addresses of the sender (source) and the receiver (destination) of the IGMP packet?
3. (1p) Where are the Multicast destination IP and MAC addresses defined?
4. (1p) How is the MAC address of the Multicast packet's destination defined?
5. (3p) Based on the captured packets, present the frame structure of the MulticastChat Protocol (used by the client, 'designed' by the lecturer)
6. (3p) Present also the possible values of the fields of the frame and the operations/meaning of each value.

Implement your own client that is able to join and leave the multicast chat group and send and receive messages using the MulticastChat protocol discovered earlier

Evaluation is based on the following (return your code)

1. (4p) your code must be properly commented
2. (4p) your application is able to receive packets and interpret them correctly and print on screen messages from other clients
3. (4p) your application is able to send messages with correct frame structure and meaningful/correct values in the fields
4. (4p) "Simultaneous" sending and receiving (either by using threads or e.g. with socket timeouts)
5. (4p) Return a filtered packet capture of the traffic that is generated when your application communicates with the lecturer's application.

The goal of this assignment is to learn IP subnetting and the role of static and default routes in packet forwarding.For the assignment PSimulator2 network simulator (emulator) is used. Take a look also at this page for hints to using the program. Return all the saved Yourname*.xml files, according to the instructions below.

1. (1p) Run java -jar psimulator2_frontend.jar and create a network like in this topology.

2. (3p) The circled devices must be in their own (sub)networks. i.e. define an IP address and subnet mask to each device (3p only if other than /24 masks are also used). Save the topology as YournameTopology.xml file
3. (3p) Run the Backend server: java -jar psimulator2_backend.jar YournameTopology.xml (NOTE: seems Backend does not work in Java 8). Frontend: change to simulation and connect to the backend server. Make a telnet connection to the Cisco router and start up the interfaces and add static routes to the subnets you defined. Hint: enable -> configure terminal -> interface FastEthernet 0/x -> no shutdown -> (end/exit) -> ip route x.x.x.x (network) z.z.z.z (mask) y.y.y.y (next hop address). Note: enable IP forwarding on Linux routers # editor /proc/sys/net/ipv4/ip_forward and change the 0 to 1.
4. (1p) Start the packet capture of the simulation and from the router ping some PC or Notebook (ping pc.pc.pc.pc). Stop the capture and save events to file named YournameEvents1.xml, return the file.
5. (1p) Run the events (play button) and examine what device drops the packet. Add to that device's routing table a (working) default routeand try the ping again. The ping should work now.
6. (2p) Make a telnet connection to the Linux router that is on the opposite side of the Cisco router than the PC/Notebook you pinged earlier. From the Linux router try to ping (ping pc.pc.pc.pc -c 4) the same PC/Notebook than before, and it should fail. Add a default route to the Linux router that routes packets to the Cisco router.
7. (1p) Clear previous events and start packet capture. Try the above ping again. Save the events to a file named YournameEvents2.xml, return the file.
8. (1p) Examine the capture by running it again with the play button and find the device which drops the packets. Modify that device's routing table so that the ping will work.
9. (1p) When the ping is working make similar changes to all the remaining devices so that ping will work between any two devices.
10. (1p) Choose a PC or Notebook and ping all other PCs/Notebooks. Send only one ping packet to each destination (ping pc.pc.pc.pc -c 1). Capture all ping messages. Save the events to a file named YournameEvents3.xml, return the file.

The goal of this assignment is to learn the meaning of collision domain in Ethernet networks, forwarding of bridges/switches and about routing protocols. Install NetKit following the instructions. The tasks are based on NetKit official labs. Below the emphasized name means the equivalent official lab and do the tasks means to go through the instructions of the lab in question and do the tasks in the instructions. First go through Introduction slides. Return screen captures you make and/or (filtered) packet captures as instructed below.

1. (1p) Single host, do the tasks and take a screen capture that shows route print
2. (1p) Two hosts, do the tasks and take a screen capture that shows ping, return also the packet capture
3. (1p) Static routes, do the tasks and take a screen capture that shows last printings of all devices
4. (1p) Modifying the previous task, change it so that the PCs use static routes and the routers use default routes, take a screen capture that shows last printings of all devices.
5. (1p) ARP, do the tasks and return packet capture of the ARP traffic in each collision domain
6. (1p) Zebra/Quagga, familiarize the instructions and take a screen capture after you have printed to screen the RIP routing table from the vtysh shell.
7. (1p) RIP, do the tasks and return packet capture of the RIP messages that are triggered by the interface down command.
8. (1p) Bridging, do the tasks and take a screen capture (or packet capture) of the situation where the traffic to pc1 is filtered and situation where it is not filtered. STP can be set off to reduce unnecessary traffic or filter that traffic out after capture with e.g. Wireshark.
9. STP Spanning Tree Protocol, do the tasks and return the screen captures or the packet captures
   • (1p) lab1: root bridge election, take a screen capture that shows a packet capture displaying Spanning Tree Protocol fields and their values (i.e. the equivalent information as presented in the instruction slides).
   • (1p) lab2: topology change, Return the packet capture that is generated by the lab, except you should filter out all other traffic than topology change messages and its acknowledgements
   • (1p) lab3: remote topology change Return the two packet captures that are generated by the lab, except you should filter out all other traffic than topology change messages and its acknowledgements
   • (1p) lab4: a more complex scenario Return a screen capture, that shows the showstp print of all the bridges.
10. (3p) Create a network like in the PSimulator2 assignment (one PC per subnetwork is enough, no switches needed, but all routers must be implemented). As help you can use the previous tasks and e.g. their .conf and .startup files. Return a screen capture showing the equivalent ping outputs as in the last task of the PSimulator2 assignment.

The goal of the assignment is to get hands on experience with real routers. This assignment needs to be done at the Telecommunication lab. This assignment is done using static routes.

1. Configure the routers so that ping command travels successfully through several (sub)networks.
2. Return a screen capture showing routing tables of all routers and the working ping (and the response to it).

1. (1p) Download and install ns-3 on your won computer (At Telecommunication lab first make a new user on Xubuntu 14.04).
   • Follow the instructions in the tutorial http://www.nsnam.org/docs/tutorial/html/getting-started.html.
   • See also instructions on page http://www.nsnam.org/wiki/Installation about installing to different operating systems and e.g. Ubuntu/Debian minimum requirements (install gcc, g++ and python)

     apt-get install gcc g++ python

   • Minimal install can be done http://www.nsnam.org/docs/tutorial/html/getting-started.html following the chapters listed below
     • Downloading ns-3 Using a Tarball
     • Building with build.py
     • Testing ns-3
     • Running a Script
   • Finally run Hello Simulator and take a screen capture (Xubuntu: e.g. Applications -> Accessories -> Screenshot).
   • Example screen capture.
   
2. (1p) Continue according to the instructions on page http://www.nsnam.org/docs/tutorial/html/conceptual-overview.html and run your first ns-3 script, but change at least three parameter values of the example (e.g. network, subnet mask, port number, delay, transmission rate, max packet count, packet size, ...). Take a screen capture.
3. (1p) Next go through the instructions on tutorial page http://www.nsnam.org/docs/tutorial/html/tweaking.html. According to the instruction, implement to the script the possibility to give parameters from command line. Finally run the script as in the instructions

   
   	$ ./waf --run "scratch/myfirst
   	  --ns3::PointToPointNetDevice::DataRate=5Mbps
   	  --ns3::PointToPointChannel::Delay=24ms
   	  --ns3::UdpEchoClient::MaxPackets=11"
   	

   but change some values. The Delay should be the day (DD) of your birth date, MaxPackets should be the month (MM) of your birth date. Above you see example values of the lecturer. Remember to comment out the lines for which you give parameters on command line. If necessary increase the duration of the simulation (or decrease packet interval) so that all MM packets are echoed during the simulation. Take a screen capture which shows as much as possible of the simulation output.
4. (1p) Add ASCII and PCAP tracing to the script. Run the script again (with the same parameters) and return the ASCII and PCAP output files of the simulation. The file names should contain your first and last name.
5. (1p) Also return a screen capture where you have printed the PCAP file contents to screen with tcpdump program.
6. (The next part is not directly in the tutorial but can be done based on it) Add a third node the the previous simulation following the instructions below
   General picture

   	      node 0                node 1                node 2
   	+----------------+    +----------------+    +----------------+
   	| Echo client *2 |    |   Echo Server  |    |   Echo Server  |
   	+----------------+    +----------------+    +----------------+
   	|  IP address    |    | IP address * 2 |    |  IP address    |
   	+----------------+    +----------------+    +----------------+
   	| point-to-point |    |point-to-point*2|    | point-to-point |
   	+----------------+    +----------------+    +----------------+
   	        |                    | |                    |
   	        +--------------------+ +--------------------+
   	            MM Mbps, DD ms         MM Mbps, DD ms
   

   • node 0 device has two echo clients,
   • node 1 and 2 devices each has an echo server.
   • traffic from node 0 device to node 2 device passes through node 1 device
   • MM and DD values you can be set in the code or give as command line parameters
   Tasks in more detail
   • (1p) Create the third node (node 2) add NetDevices to the PointToPoint
   • (1p) Add Internet protocol stack (InternetStack)
   • (1p) Add IP addresses to the new link (must be on its own subnet, node 1 acts as a "router")
   • (1p) Add the new applications to nodes 0 and 2
   • In this task we can implement a 'routing helper'

     Ipv4GlobalRoutingHelper::PopulateRoutingTables();
     

     Add the line above before the line

     Simulator::Run() 
     

   • (1p) Define different names to trace files than previously, but so that your name is still part of the file name.
   • Return
     1. If your simulation is functioning without errors: screen capture which shows the ASCII and PCAP output files and the command line output of the simulation. See e.g. this screen capture.
     2. If your script is not functioning, then return your modified script for evaluation
   

If there are parameters whose values are not defined you can choose them freely (so that the simulation still is reasonable and functioning).

1. (1p) See page http://www.nsnam.org/docs/tutorial/html/building-topologies.html and implement a simulation based on script second.cc (i.e. no wireless network), so that there is an arbitrary number of nodes in the csma bus, i.e. run the command

   $ ./waf --run "scratch/mysecond --nCsma=100"
   

   where the value 100 is placed by a number of your choosing. Also change the default IP addresses used by the script to something different of your choice. Return a screen capture where you have printed on screen the pcap file contents with tcpdump similarly as in the tutorial (change 100 and 101 according to your number)

   tcpdump -nn -tt -r second-100-0.pcap
   

   tcpdump -nn -tt -r second-101-0.pcap
   

2. (2p) Next add two new csma bus to the topology (each having at least 5 nodes), one csma bus is connected to node 0 and the other is connected to an arbitrary device on the original csma bus. Move the UdpEchoClient of the original topology to either of the new csma bus and UdpEchoServer to the other new bus. Run the script as previously and return a screen capture which shows printed on screen the promiscuous mode tcpdump outputs of each bus.
3. (1p) Draw a picture of the topology you created. As starting point you can use the ascii pictures of the example scripts and for drawing e.g. http://asciiflow.com/ application. Return a link to the picture, screen capture, a scanned picture, a photo, or equivalent. So you can draw it with any program or by hand as long as it is returned so that it can be linked or placed on your www page.
4. (2p) Examine the outputs of the previous task and draw a sequence diagram of the data transfer. Return a link to the picture, screen capture, a scanned picture, a photo, or equivalent. So you can draw it with any program or by hand as long as it is returned so that it can be linked or placed on your www page.
5. (2p) Next, add to either of the new csma bus on an arbitrary device a PacketSink application (see PacketSinkHelper) which is used to receive UDP packets. Start the PacketSink application at simulation time 0. Set for the PacketSink LOG_LEVEL_ALL. Change the simulation so that EchoClient sends packets to the PacketSink (not the echo server). run the script. Return a screen capture of the script output printed on screen or the modified xxx.cc file if your script has errors that you cannot fix.
6. (2p) Now, add to the other new csma bus (i.e. not the one that has the PacketSink application) to an arbitrary node an OnOffApplication (see OnOffHelper), that sends UDP data packets to the PacketSink application. Start the OnOffApplication two seconds after start of simulation. If you wish, you can now remove EchoClient and EchoServer and also you can set PacketSink not to print events on screen. Add PCAP tracer to an arbitrary device on either of the new bus that captures packets in promiscuous mode. Return the pcap file or the modified script xxx.cc file if your script has errors that you cannot fix.

In this assignment we examine the behaviour of TCP:n congestion window (cwnd). We us the topology we build in the previous assignment as a building block and add TCP traffic to the simulation. On the tutorial page http://www.nsnam.org/docs/tutorial/html/tracing.html are examples with TCP and it is advisable to go through that before this assignment, even though the assignment does not follow the tutorial. Lets start defining the parameters and values for the simulation. Simulation length should be 30 seconds.

1. (1p) Set PointToPoint link delay to value 200 ms and transmission rate to value 5Mbps.
2. (1p) The UDP traffic source (OnOffApplication) starts transmitting at time 10 seconds and stops at time 15 seconds. Set the transmission rate to value 5 Mbps and packet size to value 1480 bytes (the values must be set before the application is installed to the node).
3. (1p) The TCP traffic destination (TCP PacketSink) is placed in the same network (bus) with the UDP PacketSink application
4. (1p) The TCP and UDP traffic receivers are started at time 1 second and stopped at time 30 seconds.
5. (1p) The TCP traffic source is placed is placed in the same network (bus) with the UDP OnOffApplication.
6. (1p) As the TCP traffic source we use MyApp class, that you can "borrow" from the tutorial fifth.cc script. For the application you must create a TCP socket

   Ptr<Socket> ns3TcpSocket = Socket::CreateSocket (xxx.Get(n), TcpSocketFactory::GetTypeId ());

   where n is the nth device on the csma bus xxx, i.e. the device where you installed the TCP source.
7. (1p) The application is created with

Ptr<MyApp> app = CreateObject<MyApp> ();

8. (1p) and its setup function is run

app->Setup (ns3TcpSocket, sinkAddress, 1440, 100000, DataRate ("10Mbps"));

9. (1p) sinkAddress Is the address of the TCP destination (including the IP address and the port number)

   Address sinkAddress (InetSocketAddress(yyy.GetAddress (m), sinkPort));

   where m is the mth device on the csma bus yyy, i.e. the device where you installed the TCP destination.
10. (1p) and setup

xxx.Get(n)->AddApplication (app);

11. (1p) The application is started at time 2 seconds and stopped at time 29 seconds.
12. (1p) The changes of the congestion window are saved to a trace file similarly as in the fifth.cc script example by adding the line

    ns3TcpSocket->TraceConnectWithoutContext ("CongestionWindow", MakeCallback (&CwndChange));

    right after the line where the TCP socket is created and setting the output to a file > cwnd.dat 2>&1.
13. (1p) Next some default values are set for TCP.
    • Set the Maximum Segment Size (MSS) to value 1440:
    Config::SetDefault ("ns3::TcpSocket::SegmentSize", UintegerValue(1440));
    • Set the congestion control algorithm used by TCP
    Config::SetDefault("ns3::TcpL4Protocol::SocketType",TypeIdValue(TypeId::LookupByName("ns3::TcpTahoe")));
    • These affect only objects which are created after setting these values so place the lines somewhere at the start of your code.
14. (1p) The simulation might print on screen information that is not needed. You can comment out the unnecessary LogComponentEnable lines and PCAP traces (not mentioned in the instructions of this assignment).
15. (1p) Run the script and open cwnd.dat file and remove the waf build related lines from the start of the file. If your script has errors and is not functioning (or you are unable to make the figures asked below, see examples here) then return the non-functioning .cc script file, which is evaluated based on how much of the above tasks are implemented correctly. If your script runs okay then you only need to return the figures described below (and do the verbal evaluation).
16. (1p) Install gnuplot if needed and make a YourNameTahoe.png file which shows the behaviour of the congestion window. Also set your name as the title of the figure. Return the picture.
17. (1p) Do the same simulation but change the algorithm to TCP Reno and return YourNameReno.png
18. (3p) In your own words, describe what happens in the figures and compare the differences TCP Tahoe and TCP Reno.