Transcript ECE544prj3_2008Mar12

ECE 544 Group Project :
Routing
KC Huang
Objective




Application: message multicast. A
message is sent from one sender to
1~3 recipients.
Reach a protocol standard used for this
application.
Implement the protocol
Inter-operation Test
Application



Message Delivery
Each message contains header and payload
The header contains multiple recipient
addresses (names).
a,b,c
hello
Network Elements

End Nodes (User):



Routers



Has 1 port linking to a
router
No direct link between end
nodes.
Connect to other routers or
end-nodes
Has 2~4 ports.
Links


not reliable.
lose packets with probability
p in both directions
Requirement 1: Address

User Address


All end nodes share a same naming
scheme
Open Issues:


Routers name and address
Fix or dynamic address assignment
Requirement 2: Routing




The routing protocol can route traffic among
any end nodes.
No static routing
The same routing protocol must run on every
router.
Open Issues:

Routing algorithm



flooding, tree-based routing, etc.
Metrics
Signaling design
Requirement 3: Reliability


Message delivery must be guaranteed.
Design Issue:

ARQ


Hop-by-hop ARQ
End-to-End ARQ
Project Plan
Draft protocol
document is due
before 1st Std.
Meeting (Mar. 26)
start
3-4 people to
form a group


Formal
Design Doc. Final
standard Apr. 11~17 Submission
document
& Demo
Standard
Meeting
2nd Std.
Meeting
Mar. 28
Apr. 4~10
end
May. 7?
Standards & Documents
Coding, Integration/Test, Demo preparation
What is in Protocol Draft?


How to fulfill the requirements?
Issues:









Address
Packet Formats
Node and Router discovery
Message delivery
Routing/Forwarding schemes
Interface between Routers
Interface between End-Node and Router
Layering
……
Software Design Issues



recommend to reuse your current
design of ports, links, addresses…
Shall support duplex communication
Not constrained by the current
architecture. (common.cpp common.h)
Standard Meeting

Each group gives a 15-20 minutes talk about
the design


Discuss




Other groups can challenge…
What shall be in the standard? what shall not?
What’s the best way to do a certain task?
Vote if not reach a consensus
Select members for a protocol-writing team.


2nd Meeting to settle down final details.
Distribute the final document to all groups
Demo



The student group uses one or more connected
computers running Linux to show the demo.
The demo network shall contain at least 4 end-nodes
and at least 3 routers.
Network Start


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.
Demo Cntd.

Start application to verify the message delivery




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, the messages reception must be
shown.
Final Submission




Router program ( Source code + Makefile)
Sender and receiver program to test (Source code +
Makefile)
Guide: How to run your program
Document for Protocol implementation and
Performance Evaluation. It could contain, but not
limited to, following topics:




Signaling definition
Routing/Discovery procedure
Interfaces of router-router and router-terminal (end-node)
Performance estimation/evaluation
Have Fun!