Project 3: Router Design

Introduction

The student groups are suggested to design a routing protocol which is used specially to deliver messages which contain up to 3 recipient addresses, reliably.

Suppose there is a network which contains end-nodes and routers. The end-nodes are only responsible for sending and receiving the messages. The routers are used to forward the messages, as show in Figure 1.

Figure 1. A network has 4 routers and 6 end-nodes

There are no direct links between end-nodes. Also, each end-node only link to one router.

The links connecting nodes are not reliable. It loses packets with a probability p in both directions.

Message to be transferred is a text message which contains a header and payload. In the header the sender’s address and up to 3 receiver’s address (all of them must be of end-nodes) are included.

Draft Slides

G1, G2, G4, G5, G7, G8, G9

Design Requirements

For the address, all end-nodes in the network share a same application layer address space. A simple numeric ID must be used for this address, as show in Figure 1.  IP address shall not be used for this purpose. The router identification may be designed arbitrary. It may only be regarded as a bunch of ports labeled by the address of ports. Or it can have a unique identifier. This is one of the issues we have to discuss in the standard meeting.

The same routing protocol must run on every router. Each router can have 2-4 ports. Each end-node has only 1 port. Each port must bind to an “Addresss” which is defined as in previous projects. Each port must be able to both send and receive.

Any routing means (flooding, tree-based routing, shortest-path unicast, multicast, etc) can be used for this project. But the network performance (delay, throughput) needs to be considered in the design and manifested in the design document.

The routing table of the router, if used, cannot be of pre-configured data. The table entries must be filled on-the-fly. (During the development, you might use pre-configured routing tables. But for final submission and demo, this is not allowed)

What to submit

• Router program ( Source code  + Makefile)
• Sender and receiver program to test (Source code + Makefile)
• Manual: How to run your program
• Document for Protocol Design, Implementation and Performance Evaluation could contain following , but not limited to, topics:
  • Signaling definition
  • Routing/Discovery procedure
  • Interfaces of router-router and router-terminal(end-node)
  • Performance estimation/test

Demo

In addition, the student groups must show the TA a demo to transfer end to end messages for variable addresses. The demo shall proceed as following:

• The student group use one or more connected computers running Linux.
• The demo network shall contain at least 4 end-nodes and at least 3 routers. The group members need to show TA a network diagram in a sheet which depicts
  •  Each nodes’ ID and “Address”
  •  Each port of each router’s “Address”.
• Start each router program in different console on one or more computers. Make necessary configurations (should not configure routing table manually).
• If there is some proactive routing/discovery signaling exchanged, indicate the procedure on the console output.
• Start end-nodes with different IDs. Configure the end-nodes (make each of them link to a router). Let them discovered by router.
• When you think routers are ready for supporting end-to-end traffic, the user types the text message and desired receiver ID(s) in a console of one end-node. Then commands to send it.
• In the consoles of router which route this message, the router shall ‘display” the reception of this message and what action it takes to forward this message.
• In the console of receiver(s), the messages reception must be shown.

Project Plan

Each group must submit and show the demo for this project before Final Exam . 

For helping groups proceed smoothly with the project development, I set-up several additional submissions before the final submission

1. Phase 1: The protocol standard meeting is scheduled on the class. Before this date, every group has to submit a draft design document of the protocol to TA and circulate this document in the COMNET2 mailing list. During the meeting, each group would give a presentation on its design. Then we are going to discuss the multicast protocol design. If the groups does not reach an agreement about those issues in this meeting, another meeting will be scheduled.
   
2. Phase 2: After the standard is agreed by all groups, each group shall implement the standard. Each group is required to submit their new "design specification".. 

The major purpose of the above arrangements is to ensure each student group work in a good pace, and not lag behind schedule. Those submissions are not extra burdens. It is obvious that most of the documents you write will be easily integrated as part of your final submission.

Grading:

Standard Meeting (4%), Design Document (4%), Demo (12%) 　

Tips

This project is not a typical IP routing scenario. IP subnets are not applied here. Because you may need to simulate all your end-nodes and routers in one single computer., then all the ports you used are of same hostname(IP address).  Therefore, IP address cannot be used for routing directly. Either you can introduce additional layer 3 naming/addressing scheme which is above the current “Address” of the “Port”, or use the application layer address given to the end-nodes directly, which is not like a hierarchy IP address.

It’s a good habit to design and write document/diagrams before coding. Each group is recommended to begin with some parallel working phases. One is to design the draft protocol. At the same time,  it is worthwhile to spend some effort to build/program some basic blocks/components which do not rely on the design entirely. After the standard discussion meeting, the design could be finalized and several interfacing functions could be added/modified. Then all codes shall be assembled into working products.