Development Plan
Phase I
Fig 2: Phase 1 Topology
In phase 1, our goal is to implement our QoS in a network which has the Topology of (Fig2). This topology consists of a prioritized node who has subscribed to the service, two unprioritized nodes, an openflow switch (OFS), a QoS edge router (QER), a set-back router (SBR) and an FTP server (FS). There are no core routers or cross traffic in this topology. The purpose of this initial phase is to make sure that the essential parts of our service function correctly. Our topology from the proposal has changed and the design has changed some as well. In the proposal, we were considering implementing QoS for all TCP packets which would actually have been much more simpler than implementing it for specifically FTP as we are doing now. The reason for this change is so that we could show a file being transferred during the demonstration to provide a more concrete reference as to the results of the QoS.
-
The purpose of this is topology is to ensure that:
-
-
Gateway can differentiate between subscribers and normal users
-
QoS edge router can recognize which source the packet came in through and can accordingly assign the correct TOS bits to mark the priority.
-
QoS Edge router is able to forward packets to the set-back router
-
Set-back router is able to recognize prioritized packets
-
Set-back router is able to set the TOS bits back to 0x0008
-
Acknowledgements are received for both the subscribers and standard users
-
Ensure that a flow of prioritized packets reaches the destination node before a flow of unprioritized packets on average when they are being transmitted in parallel. This should be the case once prioritized packets enter the band 0 transmission queue and when unprioritized packets go to band 1.
-
-
Tasks:
-
-
Create a GENI network for Phase 1 Topology
-
Write hook for QoS edge router which will differentiate between packets based on its incoming source IP.
-
Write hook for QoS edge router which will appropriately set the TOS bits and recompute the checksum.
-
Write hook for set-back router to recognize prioritized packets
-
Write hook for set-back router to set the TOS bits back to 0x0008 and recompute the checksum.
-
Write a debugging module to view the values of certain fields in the IP header of the packets at certain points in the packet’s path through the network
-
Phase II
In phase 2, our goal is to implement our QoS in a network which has the topology of (Fig3). This topology introduces a single core router (CR 1). All other components are kept the same.
-
Purpose of this is topology is to ensure that:
-
-
Core routers prioritize packets correctly based on the TOS bits
-
Packets are able to be forwarded from the source to the destination when a core router is added.
-
The core router doesn’t change the TOS bits on its own
-
-
Tasks:
-
-
Create a GENI network for Phase 2 Topology
-
Load the hooks on the QoS edge router
-
Load the hooks on the set-back router
-
Load debugging modules at useful points in the network and make sure that:
-
TOS bits stay the correct value throughout the transmission
-
Packets are forwarded correctly
-
Packets are prioritized correctly
-
-
Fig 3: Phase 2 Topology
Phase III
Fig 4: Topology 3A
In phase 3, our goal is to implement our QoS in a network which has topology of Fig 4 & Fig 5 . This topology introduces another core router (CR 2), cross nodes (XN 1 and XN 2) and an iPerf server (IS). These are the final topologies for the QoS implementation simulation. We had plans to create a much larger topology with 4 OFS switches (which would involve 4 QoS edge routers) which were fed traffic from a mixture of prioritized and non-prioritized users. Our planned topology also included about 10 core routers and 4 extra non-prioritized source nodes to create cross traffic on those core routers. They would have been sending to destination nodes across the network which had the sole purpose of contributing to cross traffic. We are not able to use this topology however because even after multiple tries, GENI does not seem to support anywhere near this number of nodes as we see it struggle to give us the resources we need when we approach a 10 node network. Lots of the time, nodes may be created but are not able to connect to the internet among other things. So unfortunately, this much smaller network is the extent of what the limitations from GENI will allow us to implement. If there is some solution to this, we would desire to create the larger network that we had previously planned.
-
Purpose of these topologies is to:
-
-
Introduce cross traffic into the network
-
Show the effects of varying levels of cross traffic
-
Ensure that packets are still able to reach their destinations with an extra core router
-
The hook installed at core router 1 in 3B Topology & at QoS Edge in 3A Topology makes sure all the packets received from the paid user through OVS switch(s) are marked with new tos bits.
-
This topology differentiates paid users from unpaid based on the source IP address they come from.
-
-
Tasks:
-
-
Create a GENI network for these topologies
-
Load the hooks on the QoS edge router
-
Load the hooks on the set-back router
-
Send streams of packets from the cross nodes to the iPerf server using iPerf while files are being sent through FTP
-
Load debugging modules at useful points in the network and make sure that:
-
TOS bits stay the correct value throughout the transmission
-
Packets are forwarded correctly
-
Packets are prioritized correctly
-
-
We first tested all the kernel modules, with files of different sizes, with different flows of iPerf cross traffic and then moved on to topology presented in Phase 3B to induce dynamic configurability.
Fig 5: Topology 3B