学习了解数据包转发的策略以及存储转发策略网络设备的信息，设计转发机制，减少转发网络中的处理流量。
Introduction
The focus of this assignment is to learn about decisions to forward flows of packets and the information that is kept at network devices that make forwarding decisions. The design of forwarding mechanisms aims to reduce the processing required by network elements that forward traffic while providing scalability and flexibility.
Protocol Details
Your are given the task to develop a replacement for IPv4 or IPv6 by designing a protocol that forwards payloads based on a collection of strings that identify the source and destination of traffic. The forwarding information will be kept in forwarding tables located at the individual network elements and the content of these tables will be controlled by a central controller.
The initial implementation of the forwarding mechanism will use a UDP service bound to port 51510 at every network element. Someone in future may use the same information that is currently transferred using UDP and send it, using Ethernet frames as a complete replacement to current IP protocols, as shown in figure 2 b) (see also the use of faces in NDN).
An application using your protocol will create a header you design, attach the payload to be transmitted,and send it as payload to a service you develop, bound to port 51510 on the local host, such as shown in figure 2 a). The service will examine the header and decide where to forward the information to based on the header information and a forwarding table. The forwarding table will indicate instances of the serviceon other network elements.
An application that intends to receive traffic will send a datagram to the forwarding service on its local host, indicating that it intends to receive traffic for a given string. The forwarding service will need to record the port number of that the application used and the string. Whenever datagrams arrive for the given string, it should deliver these datagrams to the port number that is associated with the string.
The header information should be encoded as type-length-value (TLV) format. Figure /refTLVExample shows an example where the first number of the encoding gives the type of the information that follows, the second number gives the length of the information and the third item of the field provides the value of the information itself. The first example shows a field that could represent a network ID, the network has the length of 7 characters and the value ‘trinity’. The second example combines two network IDs by introducing a type combination that can hold any combination of further TLVs, in this case two network IDs. This example allows for construction of hierarchical networkIDs such as ‘trinity.scss’.
So, the basic functionality that a forwarding service has to provide is to accept incoming packets, inspect the header information, consult the forwarding table and forward the header and payload information to the destination. In the first place, if a destination is not known, a forwarding service would drop an incoming packet; once a controller has been implemented, the forwarding service needs to contact the controller to enquire about a forwarding information to the unknown destination and if it receives forwarding information,integrate this into its forwarding table.
In general, the network elements should be controlled by a central controller that initializes the flow tables of the network elements and would inform them about routes to destinations as the network changes. In a first step though, in order to reduce complexity, the flow tables of the individual network elements should be hardcoded. The implementation of the controller element should only be pursued once the implementation of the forwarding functionality of the network elements is stable and allows for basic communication betweentwo endpoints. The Named Data Networking (NDN) protocol and the OpenFlow protocol are examples of similar protocols that you could look at for functionalities that may be interesting for you to include in your protocol.In the end, it is up to you what functionalities you implement in your protocol. In the deliverables, you need to describe these functionalities and justify why you included them in your protocol.
The following flow diagrams, figures 5 is an examples of visualizations of network traffic between network elements. It shows a sequence of messages exchanged between the elements. Please use Flow Diagrams like these to document the communication between components of your implementation in your videos and in your final report.
The protocol can be implemented in a programming language of your choosing. One of the conditions is that the communication between the processes is realized using UDP sockets and Datagrams. Please avoid Python 2.7 because the implementation of Datagram sockets in the obsolete versions is based the transferof strings instead of binary arrays.
The easiest way to start with the development of your solution is possibly to connect your components through the localhost interface of a machine; however, at the end, you will need to be able to demonstrate that your protocol can connect components located at a number of hosts.
There are a number of platforms that support the simulation of topologies or provide virtual infrastructures e.g. Docker, Mininet, Kubernetes, etc. For someone starting with socket programming and networking, I would suggest to use a platform such as Docker or Mininet; for someone already familiar with these concepts, I would suggest to implement their solution using Kubernetes. However, these are only suggestion and you need to make the decision how to implement your solution.
Deliverables & Submission Details
The deliverables for this assignment are split into 3 parts: 2 videos, a report describing your solution and the files making up the implementation of your solution. The deadline for the submission of these deliverables are given in Blackboard.
One component of the deliverables at every step is the submission of captures of network traffic.
These captures should be in the form of PCAP files. Programs such as Wireshark, tshark, etc offer functionalityto capture network traffic from interfaces
Part 1: Video & PCAP file
The video of part 1 should demonstrate the initial design of your solution and a capture of network traffic between the components of your solution and the files of your traffic capture in pcap format.
In the video, you should explain the setup of the topology that you are using and the information that makes up theheader information in your traffic captures.
The submission process for this part consists of two steps: 1) Submitting the PCAP file or files that you captured from your network traffic, and 2) submitting the video for this step.
The video is to be no longer than 4 minutes; content past the 4 minute-mark will be ignored during marking. Videos with voice-over using text-to-speech (TTS) will not be accepted and marked with 0.
Part 2: Video & PCAP file
The video of part 2 should demonstrate the current state of your solution, the functionality that you have implemented so far, and a capture of network traffic between the components of your solution and the files of your traffic capture in pcap format. In the video, you should explain the basic implementation fo your protocol and the information that is being exchanged between the components of your solution.
The submission process for this part consists of two steps: 1) Submitting the PCAP file or files that you captured from your network traffic, and 2) submitting the video for this step.
Videos with voice-over using text-to-speech (TTS) will not be accepted and marked with 0. The video is to be no longer than 4 minutes; content past the 4 minutemark will be ignored during marking.
Final Deliverable
The final deliverable should include a report that describes the components of your solution and their functionality, the protocol that you implemented and the communication between the components of your solution, the topology that you used to run you solution and how your solution was executed.
The submission process for this part consists of three steps: 1) Submitting the PCAP file or files that you captured from your network traffic, 2) submitting the source code and any files that may be necessary to execute your solution, and 3) submitting the report about your solution.
The files that contain the implementation and the report should be submitted through Blackboard. Every file should contain the name of the author and the student number. The source files of the implementation should be submitted as an archived file e.g. “.zip” or “.tar.gz”. The report should be submitted as either word- or pdf-document. The deadline for the submission is given in Blackboard.
The report may be submitted to services such as TurnItIn for plagiarism checks.
Marking Scheme
The contribution of the assignment to the overall mark for the module is 30% or 30 points. The submission for part 1 and 2 will be each marked out of 5 points and the submission for the final part will be marked out of 20 points. The mark for the final deliverable will be split into 50% for the functionality of your solutionand 50% for the documentation through the report.