15-441 Computer Networks – Project 2Routing Protocols

Lead TA: Jeff Pang (jeffpang+441@cs.cmu.edu)

Assigned: Tuesday, February 18, 2004Due date: Friday, March 19, 2004 (11:59:59PM EST)

(NOTE: This is atwo person project)

1 Administrivia and Logistics

1. You must find one partner for this assignment. The only reason you should not have a partner is if there are anodd number of people in the class and you are left out (in which case contact us).

2. Once you have found a partner, email Jeff (jeffpang+441@cs.cmu.edu) your group’s names and andrew loginsso we can assign a group number to you. Use “15441 GROUP” as the subject line. Please try to be sure youknow who you will work with for the full duration of the project so we can avoid the hassle of people switchinglater.

3. The tar file for this project can be retrieved from:

http://www.cs.cmu.edu/˜srini/15-441/S04/assignments/project2/project2.tar.gz

4. This project requires building on project 1. You may use either your implementation or your partner’s. If youare unhappy with both your implementations, you can use our sample implementation of project 1, which canbe retrieved from:

http://www.cs.cmu.edu/˜srini/15-441/S04/assignments/project2/sircd.tar.gz

2 Introduction

In this assignment you will implement two different routing protocols and exploring the costs and benefits of each. Inaddition, you will extend the IRC server you constructed for project 1 to use routing protocols so that chat messagescan be exchanged between a network of IRC servers.

The system is composed of a set of nodes interconnected byvirtual links in an arbitrary topology. Each node runs aprocess that we will call a routing daemon. Each routing daemon maintains a list of IRC users available to the system.Figure1 shows a sample IRC network composed of 5 nodes. The solid lines represent virtual links between the nodes.Each node publishes a set of users (i.e., thenick s of the IRC clients connected to it) to the system. The dotted linesconnect the nodes to their user sets.

The usage model is the following: Ifbob wants to contactalice, the IRC server on the left first must find therouteor path from it to the node on the right. Then, it must forwardbob’s message to each node along the path (the dashedline in the figure) until it reaches the IRC server atalice’s node which can then send the message to the clientalice.

In essence, each node in the system performs functions similar to the ones performed in the network layer, namelyforwarding androuting. Forwarding is the action performed by each node to guide a packet toward its destination.Routing refers to the action of building the data structures necessary to reach particular destinations. For this project,adestinationis a username (i.e.,nick ).

You will explore two different routing protocols:

1

Routing Protocol

IRC Server

Routing Daemon

bob

tcp

IRC Client Protocol

tcp

udp

IRC Server

Routing Daemon

alice

tcp

IRC Client Protocol

tcp

udp

IRC Clients

tcp tcp

Forwarding Protocol

Figure 1: Sample IRC network.

1. Distance Vector Routing: in this scheme, each node in the network periodically exchanges information withits neighbors so that everyone in the network (eventually) knows the best path to take to reach each destination.This is similar to some protocols used in Internet routers.

2. Dynamic Source Routing: in this scheme, nodes in the network do not know how to reach any destination untilthey want to send a message to that destination. In order to find out how to get to a destination, a node initiatesabroadcast searchto find a path to that destination (e.g., it asks its neighbors, which in turn ask their neighbors,etc.). This is similar to how Gnutella file searches works.

Your task is to write arouting daemonwhich implements these two routing algorithms and to extend the simpleIRC server you implemented in project 1 to forwardPRIVMSGcommands to users on different IRC servers.

3 Overview

The routing daemon will be a separate program from your IRC server. Its purpose is to maintain the routing state ofthe network (e.g., build the routing tables or discover the routes to destinations). When the IRC server wants to senda message to a remote user, it will ask the routing daemon how to get there and then send the message itself. In otherwords, the routing daemon does theroutingand the IRC server does theforwarding.1

In your implementation, the routing daemon will communicate with other routing daemons (on other nodes) overa UDP socket to exchange routing state. It will talk to the IRC server that is on the same node as it via a local TCPsocket. The IRC server will talk to other IRC servers via the TCP socket you defined in project 1 that it also uses tocommunicate with clients. It will simply use special server commands. This high level design is shown in the twolarge IRC server nodes in Figure1.

In order to find out about the network topology, each routing daemon will receive a list of neighboring nodes whenit starts. In this project, you can assume that the no new nodes or links will ever be added to the topology after starting,but nodes and links canfail (i.e., crash or go down) during operation (and may recover after failing).

3.1 Definitions

Before we get into the gory details, let’s define some terminology we will use often. You may find this useful as areference while reading through this document.

nodeOne (IRC server, routing daemon) pair running together that is part of the larger network. In the real world, a

1In actual routers, and even overlay networks like peer-to-peer file sharing networks, the notion of the separate routing daemon is atypical —however, since we want to support both DSR and DVR protocols, we keep it separate for modularity. Normally, the forwarding program shouldkeep the forwarding table, not query the route daemon for each route lookup.

2

node would refer to a single computer, but we can run multiple “virtual” nodes on the same computer since theycan each run on different ports. Each node is identified by its nodeID.

nodeIDA unique identifier that identifies a node. This is an unsigned 32bit integer that is assigned to each node whenits IRC server and routing daemon start up.

neighborNode 1 is a neighbor of node 2 if there is a virtual link between 1 and 2. Each node obtains a list of its neighbors’nodeIDs and their routing and forwarding ports at startup.

destinationA destination is an IRC username ornick as a null-terminated character string. As per the IRC RFC, destina-tions will be at most 9 characters long and can not contain spaces.

IRC portThe TCP port on the IRC server that talks to clients and other IRC servers.

forwarding portThe same as theIRC port .

routing portThe UDP port on the routing daemon used to exchange routing information with other routing daemons.

local portThe TCP port on the routing daemon that is used to exchange information between it and the local IRC server.For example, when the IRC server wants to find out the route to a remote user, it queries the routing daemon onthis port. The socket open for listening will be on the routing daemon. The IRC server will connect to it.

DVRPDistance Vector Routing Protocol that you will implement.

routing tableThe data structure used to store the “next hops” that a packet should take used in DVR. See your textbook [10]pp. 274-280 for a description.

DSRPDynamic Source Routing Protocol that you will implement.

path cacheThe data structure used to store routes that packets should take in DSR. The route is just an ordered list ofnodeIDs that indicates the path to the destination. See Section5 for a description.

3.2 The Rest of this Document. . .

Here is how the remainder of this document is organized:

• Section4 will describe the DVR protocol that you will implement in your routing daemon.

• Section5 will describe the DSR protocol that you will implement in your routing daemon.

• Section6 will describe the mini-protocol you will implement for your IRC server to talk to your routing daemon.

• Section7 will describe the extensions you need to make to your IRC server.

• Section8 will outline some of the implementation details and programming guidelines you must follow.

• Section9 asks you to compare the two routing protocols.

• Section10will suggest how to get started.

• Section11will describe the grade breakdown and what you should turn in.

3

4 Distance Vector Routing Protocol

You will implement a distance vector routing protocol similar to RIPv2, which is described in your text book [10] onpp. 274-282 and in more detail in the RIPv2 RFC [9]. You can read those references to get familiar with distancevector routing.

4.1 Basic Operation

As described in the references, DVR works by having each routing daemon periodically exchange routing updateswith its neighbors. Each routing update contains the node’s entirerouting table. Upon receiving a routing update,a node updates its routing table with the “best” routes to each destination. In addition, each routing daemon mustremove entries from its routing table when they have not been updated for a long time. The routing daemon will havea loop that looks similar the following:

while (1) {/∗ each i t e r a t i o n o f t h i s l oo p i s a ‘ ‘ c y c l e ’ ’ ∗ /wait_for_event(event);if (event == INCOMING_ADVERTISEMENT) {

process_incoming_advertisements_from_neighbor();} else if (event == IT_IS_TIME_TO_ADVERTISE_ROUTES) {

advertise_all_routes_to_all_neighbors();check_for_down_neighbors();set_hop_counts_to_infinity_for_all_routes_through_down_neighbor();expire_old_routes();delete_very_old_routes();

}}

Let’s walk through each step. First, our routing daemon waits for an event. If the event is an incoming adver-tisement, it receives the advertisement and updates its routing table if any advertised route is new, or better than thecurrent route based on hop counts. In the event of a tie in hop counts for a given destination it always chooses theroute where the nodeID of next hop has the lowest numerical value.

If the event indicates that a predefined period of time has elapsed and it is time to advertise the routes, then therouting module advertises all of its routes to all of its direct neighbors.

If our routing daemon does not received any advertisements from a certain neighbor for a number of advertisementcycles it is time to consider a neighbor to bedown. It considers communication with the neighbor to be broken andsets all routes through that neighbor to have a hop count of infinity. The routing daemon propagates this informationthe next time it advertises its routes.

Next, if a route has not been updated in a long time, then we “expire” it by marking it invalid and setting itsdistance to infinity. However, we keep advertising it to our neighbors (as infinity). Note that the routing daemon willnever expire the routes to the users on its own node.

Finally, if a route has been expired (had infinity distance) for many advertisement cycles already, then you candelete the route permanently from its routing table. The reason we wait before deleting this information is because wewant to be able to tell everyone else that the route is down (by advertising routes with infinite distance).

In addition to this basic operation, you should handle thecount-to-infinityproblem by usingSplit Horizon withPoisoned ReverseandTriggered Updatesas described in the RIP RFC [9] and the class textbook [10]. If you implementthis correctly, routing should re-converge if communication with a node in the network is lost (e.g., a node goes downor a link goes down) or if communication with a node is reestablished (e.g., a node comes back up).

4.2 Protocol Specification

Figure2 shows the routing update message format, with the size of each field in bytes in parenthesis.

• Type - For DVR this should be the value 1 (to distinguish this packet type from the DSR packets).

• Sender nodeID- The nodeID of the sender of the packet, so the receiver knows which neighbor it came from.

4

RT Entries (variable)

type (4)

num entries (4)destination (16)

distance (4)

One RT Entrysender nodeID (4)

Figure 2: DVR Packet Format.

• Num entries - the number of routing table entries in the message.

• RT entries - the routing table entries exchanged. Described below.

The format of the each table entry inRT Entries is:

• destination - The name of the destination user as a null terminated string. Since the IRC RFC indicates that thisname should be at most 9 characters, it should definitely fit within 16 (the unused bytes will be ignored).

• Distance- The hop-count to get to that destination. (The hop count is 0 if the user is on the current node)

All multi-byte integer fields should be in network byte order.

4.3 Requirements

Your implementation of DVR should have the following features:

1. Full routing table updates should be exchanged between neighboring nodes every advertisement cycle.

2. Given a particular network configuration, the routing tables at all nodes should converge so that forwarding willtake place on the paths with shortest length.

3. In the event of a tie for shortest path, the next hop in the routing table should always point to the nodeID withthe lowest numerical value. Note that this implies there should be a unique solution to the routing tables in anygiven network.

4. Set all routes in the routing table through a neighbor to the infinity value if it hasn’t given any updates for someperiod of time.

5. Set routes in the routing table to the infinity value if they have not been updated for some period of time (“expire”them).

6. Delete routes from the routing table that have been set to infinity for some period of time (“garbage collect”them).

7. You should implementSplit Horizon with Poisoned Reverse.

8. You should implementTriggered Updates, both when routes change and when users join and leave a server.

9. If a node or link goes down (e.g., routing daemon crashes, or link between them no longer works and dropsall messages), your routing tables in the network should re-converge to reflect the new network graph. Youshouldn’t have to do anything more to make sure this happens, as the above protocol already ensures it.

You donot have to implement the following:

• You do not have to provide authentication or security for your routing protocol messages.

• You only need to store the single best route to a given user.

• You do not have to “jitter” your timer with randomized times.

5

5 Dynamic Source Routing

The second protocol you will implement is a dynamic source routing protocol similar to route discovery in the DSRprotocol for Mobile Ad Hoc Networks [8], and file search in the Gnutella protocol, which is referenced in your textbook [10] on pp. 691-692. You can read section 1-3.1 in the DSR IETF draft and your text book to get an idea of howsource based route discovery works. We give you the specification to follow in this handout.

In this protocol, nodes do not exchange routing information periodically; instead, a node tries to find a route to adestination only when a request for that destination is initiated by a client. Of course, after a route to a destination isdiscovered, each node remembers the route so that it does not have to discover it again (though it will discard routesthat are stale and routes that no longer work).

Initially, the routing daemon only knows the nodeIDs and routing ports of its immediate neighbors. Everythingelse is learned using route discovery. The basic data structure you will use to store this information is called thepathcache. Basically, this cache contains the entire path (sequence of nodeIDs) to get to any destination. So when the nodewants to send a packet somewhere, all it has to do is put the path to the destination (i.e.,nick ) inside the packet andeveryone along the path will know who to forward the packet to next without needing a routing table, like in DVR.

5.1 Basic Operation

When a the IRC server asks the routing daemon how to find a remote user, if it has a path to the destination in itspath cache, it should tell the IRC server the path it has. However, if it does not have a path to that destination, it mustinitiate aroute discoveryfor that destination.

The basic idea is to “flood” the entire network with a route discovery packet. When a node receives the packet, itappends it’s nodeID to the packet. Hence, when the packet reaches the destination, it will contain the entire path (i.e.,route) to that destination.

Here are the steps in a little more detail:

1. The originating routing daemon first sends a route discovery packet (with itself in the path field) to all itsneighbors on the routing port.

2. When a node receives a route discovery packet, it first checks to see if it’s node ID is already in the packet’s pathfield; if it is, then it discard the packet.2

3. If not, then it appends it’s own node ID to the packet’s path field.

4. It then decrements the packet’s TTL and sends the packet to all its neighbors (except the neighbor that it receivedthe packet from) which apply the same process starting from (2) (if the TTL reaches 0, then it discards thepacket). If it doesn’t have anyone else to send it to, it discards it.

5. At some point it will reach the node which has the user we are searching for, which will finish the path andsend a reply to the source (always on the routing UDP port). This node shouldnot continue flooding the routediscovery.

How does the reply get back to the source? The route discovery packet contains the path from the source until thedestination, so we can simply reverse the route and send it that way. Once the source gets the reply, it can add the pathto its path cache and forward the original packet.

Note that a route discovery packet could elicit multiple replies if the route discovery packet reaches the destinationmore than one way (or if the same user nick is logged onto more than one IRC server). In this case you may simplyuse the first reply that is returned and discard the rest (or, as an optimization, you can use the one with the shortestroute returned). Also note that a route discovery might getno reply, if the destination does not exist anywhere in thesystem. Hence, the source should eventually time out the discovery after a specified timeout.

Finally, nodes should expire and remove paths from their cache after a specified timeout, which starts immediatelyafter a path is added or changed in the path cache.

6

destination (16)

sequence number (4)

TTL (4)

path (variable)

path size (4)

type (4)

last hop nodeID (4)

Figure 3: DSR Packet Format.

5.2 Protocol Specification

Figure3 shows the DSR route discovery and reply message format, with the size of each field in bytes in parenthesis.

• Type: this field specifies the packet type, which is either ROUTEDISCOVERY (2), ROUTEREPLY (4).

• Last hop nodeID - The nodeID of the last hop of the packet (not the original sender; the node that sent thepacket last), so the receiver knows which neighbor it came from.

• Destination: In a both a ROUTEDISCOVERY and a ROUTEREPLY packet, the name of the destination nickthat is being searched for.

• Sequence number: this field contains a unique sequence number. The sequence number is assigned bythe packet’s source node if it is a ROUTEDISCOVERY packet that uniquely identifies the request. In aROUTE REPLY, the sequence number should match that of the ROUTEREQUEST. The source should as-sign sequence numbers so that there is a low probability of collision with another packet that may be on thenetwork. We recommend assigning a random integer (but make sure you seed the random number generator ateach node in your network with a a different number!).

• TTL : this field specifies the “time to live” of the packet. The node that originates the packet should set this to16.

• Path size: number (not the byte count) of nodeID entries in thepath field (each of which is an unsigned 32bitinteger). This is incremented each time a new nodeID is appended to the path field.

• Path: This field contains the actual nodeIDs that have been discovered along the path, in order from theoriginating source to the destination (or the entire path up to this point). Each entry should be a unsigned32bit integer.3 Note that in a ROUTEREPLY, the path should remain in the same order as it was in in theROUTE DISCOVERY. You should not reverse it.

All multi-byte integer fields should be in network byte order.

5.3 Requirements

Your implementation of DSR should have the following features:

2Think about why it should do this.3How does a node along the path find out the actualipaddress:port to forward a message to if we only know nodeIDs? Each node will

have a mapping between neighbor’s nodeIDs andipaddress:port addresses, so if the path is valid, it will know the next hop’s address.

7

1. When the routing daemon is asked for a route to a destination which is not in its path cache, it should do a“broadcast” route discovery for a path to the route.

2. A route discovery packet should not traverse the same path more than once (i.e., should not go in a loop).

3. If there exists at least one path to the destination, the route discovery should find it.

4. A reply to a route discovery should be returned along the reverse path that was discovered.

5. You should be able to handle multiple replies to a route discovery.

6. You should timeout a route discovery if no replies are received after a specified timeout.

7. When asked for a route to a destination that is in the path cache, you should return the cached path.

8. You should delete routes from the path cache after a staleness timeout.

9. Node and link failures during route discovery should not change anything. In other words, if there is still a pathto the destination after the failure, you should still find it. (If the failure occurs when the reply is being sentback, it may be dropped.)

10. You can assume that any path is at most 16 hops long.

You donot have to implement:

• Caching of routes at any place except at the node that initiated the route discovery.

• A send buffer or any sort of exponential back-off.

6 Local Port Mini-Protocol

This section describes the mini-protocol that an IRC Server uses to talk to the local routing daemon on the same node.It is important that you follow these specifications carefully because we will test your routing daemon independentlyof your IRC server.

The routing daemon listens on the local port when it starts up to service route lookup requests. When the IRCserver on the same node starts up, it connects to the local port of the routing daemon. Since the local port is onlysupposed to service local client programs (like the IRC server) on the same machine that it trusts, you can assume thatwe won’t do anything intentionally malicious to try to break it. However, you may find it useful to make it robust toinvalid input, since you may make typos when testing it. Specifically, you can assume:

1. We will only use the protocol as defined below. We will not send invalid requests.

2. Only a single IRC server will connect to the routing daemon.

3. Your IRC server may block while waiting for a response from the routing daemon. (i.e., you can treat it as afunction call)

This is a line-based protocol like the IRC-protocol you implemented in project 1. Each request looks like this:

command arguments...

Wherecommandis the name of the request andarguments... is a space separated list of arguments to the com-mand. Each response looks like this:

results...

Whereresults...is a space separated list of results returned. All requests and responses are terminated with a newlinecharacter (\n) and are case sensitive, but some responses have multiple lines.

8

You should implement the following request/response pairs in your routing daemon:

Request:ADDDESTnickResponse:OKDescription: This request is issued when a new user is registered with the IRC server. The user’s nick is added tothe routing daemon’s list of local destinations so that other nodes can find the user. This should trigger an immediateupdate for that nick.Examples:

req: ADDDEST bobresp: OKreq: ADDDEST aliceresp: OK

Request:REMOVEDESTnickResponse:OKDescription: This request is issued when a local user leaves the IRC server. The user’s nick is removed from therouting daemon’s list of local destinations so that other nodes will know that it they can no longer reach the user there.This should trigger an immediate update for that nick.Examples:

req: REMOVEDEST bobresp: OKreq: REMOVEDEST baduserresp: OK

Request:NEXTHOPnickResponse:OKnodeIDResponse:NONEDescription: This request is used to find nodeID of the next hop to use if we want to forward a message to the usernick. It should return OK if the routing table has a valid next hop for thenick and NONE otherwise (e.g., if thedestination’s distance is infinity or it is not known). This request will only be used when DVR is enabled.Examples:

req: NEXTHOP bobresp: OK 2req: NEXTHOP aliceresp: OK 3req: NEXTHOP baduserresp: NONE

Request:ROUTINGTABLEResponse:OKsizeDescription: If this request is issued, the routing daemon should respond with OK, thesizeor number of entries inthe routing table, and then a multi-line response with its entire routing table in the following format:

destination next-hop distancedestination next-hop distancedestination next-hop distance...

wheredestinationis the nick,next-hopis the nodeID of the next hop, anddistanceis the current distance value forthat destination. You should not include local destinations in this list. The order of entries does not matter. Your IRCServer will probably not need to use this command. We will use this to test your routing daemon. This request willonly be used when DVR is enabled.Examples:

9

req: ROUTINGTABLEresp: OK 5

bob 2 2alice 3 1jim 3 2joe 3 3jill 2 1

Request:PATHnickResponse:OKpath len nodeID1 nodeID2 nodeID3. . .Response:NONEDescription: This request is used to find the entire path we should use to forward a message tonick. It should returnOK if the path cache has a valid path for thenick. If the path cache does not, then it should initiate a route discoveryfor the nick. If the route discovery does not find the nick (it should time out eventually), return NONE.path len is thenumber of nodeIDs in the path. The first nodeID in the list should be the current node and the last nodeID should bethe destination. Note that the response to this request might not return immediately since the routing daemon mighthave to do route discovery; thus, it is undesirable for your IRC server to block waiting for a response (since it mayhave to wait until the timeout), but making the call non-blocking is not a requirement (you can earn some extra creditif you do make it non-blocking — see Section11.3). This request will only be used when DSR is enabled.Examples:

req: PATH bobresp: OK 3 1 2 4req: PATH aliceresp: OK 2 1 3req: PATH baduserresp: NONE

Request:REMOVEPATHnick pathlen nodeID1 nodeID2 nodeID3. . .Response:OKDescription: This request is used to remove a path from the path cache tonick. path len is the number of nodeIDsin the path and the remainder of the arguments is the path itself. The path should be removed if found in the pathcache. The IRC server issues this request to the routing daemon when it discovers that a path no longer works (this canhappen if the it is stored in the path cache, but the remote user leaves, or a node or link goes down; see Section7.2).This request will only be used when DSR is enabled.Examples:

req: REMOVEPATH bob 3 1 2 4resp: OKreq: REMOVEPATH baduser 10 1 2 3 4 5 6 7 8 9 11resp: OK

Request:PATHCACHEResponse:OKsizeDescription: If this request is issued, the routing daemon should response with OK, thesizeor number of entries inthe path cache, and then a multi-line response with its entire path cache in the following format:

destination path_len nodeID1 nodeID2 nodeID3...destination path_len nodeID1 nodeID2 nodeID3...destination path_len nodeID1 nodeID2 nodeID3......

wheredestinationis the nick,path len is the number of nodeIDs in the path, andnodeID1. . . is the path to reachthat destination (beginning with the current node and ending with the destination). You should not include localdestinations in this list. The order of entries does not matter. Your IRC Server will probably not need to use thiscommand. We will use this to test your routing daemon. This request will only be used when DSR is enabled.Examples:

10

req: PATHCACHEresp: OK 3

bob 3 1 2 4alice 2 1 3jim 3 1 3 5

7 IRC Server Extensions

In addition to the routing daemon, you will extend your IRC Server from project 1 to use the routing daemon to sendmessages to users on remote IRC Servers.

In project 1, you did not have to implement PRIVMSG commands that were sent to individual users (only tochannels). Now you will extend PRIVMSG so that when thetarget is a nickname, the IRC Server will first see if itcan send the message it to a local user with that nick name. If not, then it should try to locate the user on a remote IRCServer (using the routing daemon) and, if found, forward the message to that IRC Server which will then send it to thetarget. If the target is not found, then you should send the user a ERRNOSUCHNICK error.

7.1 Requirements

Your extensions to the IRC server should have the following features:

1. Connect to the routing daemon’s local port when it starts up. The routing daemon will be started first.

2. When a new user is registered with the IRC server, it should add the user’snick to the routing daemon’s list ofdestinations using theADDDESTrequest.

3. When a user leaves the IRC server, it should remove the user’snick from the routing daemon’s list of destina-tions using theREMOVEDESTrequest.

4. If a user changes his or her nickname, remove the oldnick and add the new one to the routing daemon.

5. When a PRIVMSG is sent to a nick that we don’t know locally, the IRC Server should ask the routing daemonto find it, if possible, and forward the message to that user. The remote IRC server receiving the message shouldsend it to the target user the same way it would send any other PRIVMSG to him or her.

6. If the target is not found, then you should send the user a ERRNOSUCHNICK error as defined in section 4.4.1of the IRC RFC.

7. The PRIVMSG command should still support multiple targets; i.e., the PRIVMSG command may have a commaseparated list of target users or channels that should all be sent the message.

8. If the routing daemon dies or you can not communicate with it, your IRC server may exit.

You donot have to implement the following:

• Forwarding messages to remote channels. (But see Section11.3if you would like to try for extra credit.)

• Forwarding messages to target servers, host masks, or anything mentioned in the IRC RFC that is not mentionedin this document.

• Forwarding any other type of message besides PRIVMSG.

• Use both DVR and DSR at the same time. (The IRC server will be told which to use when it starts up)

11

7.2 Message Forwarding

Once the IRC Server has found the next hop or route to a remote nickname, it must forward the message to the remoteIRC Server. You are responsible for designing a protocol to be used between your IRC Servers for forwarding thesemessages so that they will reach the destination.

Here are a couple things to keep in mind when designing your protocol:

1. When using DVR, you can only obtain the next hop from the routing daemon. Hence, each IRC Server alongthe path will have to query its routing daemon to figure out where to send the packet next.

2. When using DVR, while forwarding, a node or virtual link may go down (or the target user may leave). In thiscircumstance, you can just drop the message. You do not have to inform the user that sent the message that itwas dropped.

3. When using DSR, you obtain the entire path to the destination when you query the routing daemon. So youhave to include this information along with the message you forward so that the nodes in the path know whereto send the message next.

4. When using DSR, it may turn out that the path used to forward the message is not valid. In this case, you candrop the message but you should send a message back to the source IRC server so that it can remove the invalidpath from its path cache.4 (Hint: you can exploit the fact that the reverse path leads back to the source) You donot have to inform the user that sent the message that it was dropped.

5. When using DSR, it may turn out that the path used to forward the message is illegal (e.g., it may have a loop init). In this case, you should drop the message.

6. If a the same nick is logged on to more than one IRC Server in the network, both routing protocols should findthe route to exactly one of them. In DVR, this should be the “closest” one. In DSR, it could be an arbitrary one.Your forwarding protocol only needs to forward the message to one of them.

7. IRC Servers and virtual links may go down and come back up. If you detect that your neighbor is down (i.e.,the socket is closed), you should check to see if they have come back up at least once every 3 seconds. In fact,when the network first starts up, since only one server will come up at a time, all its neighbors will appear to bedown at first.

8. You shouldnot have IRC Servers communicate if they are not neighbors.

9. Your forwarding protocol shouldnot be “flood every message to every IRC Server on the network.” That is notefficient and doesn’t require the routing layer at all.

10. You shouldnot rely on any special extensions to the local port mini-protocol. We may test your IRC Server onour own routing daemon.

8 Implementation Details

This section describes details you must implement in your routing daemon and IRC Server.

8.1 Programming Guidelines

Your programs must be written in the C or C++ programming language. You are not allowed to use any custom socketclasses or libraries, only the standard libsocket and the provided library functions. You may use thepthread libraryand STL, but you are responsible for learning how to use them correctly yourself if you choose to. If you wish to useother libraries, please contact us.You responsible for making sure your code compiles and runs correctly on theAndrew x86 machines running Linux (i.e., linux.andrew.cmu.edu).

4Of course, this message may fail to get there if a failure occurs along the reverse path.

12

8.1.1 Compiling

We recommend usinggcc to compile your program andgdb to debug it. You should also use the-Wall flag whencompiling to generate full warnings and to help debug. For this project, you will also be responsible for turning in aGNU Make (gmake) compatible Makefile. See the GNU make manual [4] for details. When we invoke the command:

gmake

we should end up with the routing daemon which you should callsrouted and the extended IRC Server whichis still calledsircd .

8.1.2 Command Line Arguments

Your routing daemon must take the following command line arguments in any order. We will provide you some frame-work code that will read in these arguments.

usage:./srouted {-V | -S } -i nodeID -c config file [options]

-VEnable DVR. When this option is present, your routing daemon will use DVR andnot DSR. This option ismutually exclusive with-S .

-SEnable DSR. When this option is present, your routing daemon will use DSR andnot DVR. This option ismutually exclusive with-V .

-i integerNodeID. Sets the nodeID for this process.

-c filenameConfig file. Specifies the name of the configuration file that contains the information about the neighbor nodes.Section8.1.3describes the format of this file.

-G stringGrading. You can ignore this parameter. It will be used when grading.

If running the DVR protocol, it should also recognize:

-y integerInfinity . The maximum distance value that is used for infinity. Defaults to 16.

-a secondsAdvertisement cycle time. The length of time between each advertisement cycle. Defaults to 30.

-n secondsNeighbor timeout. The elapsed time after which we declare a neighbor to be down if we have not receivedupdates from it. You may assume that this value is a multiple ofadvertisement cycle time. Defaults to 120.

-r secondsRoute timeout. The elapsed time after which we expire a route if we have not received updates for it. You mayassume that this value is a multiple ofadvertisement cycle time. Defaults to 120.

-g secondsGarbage collect timeout. The elapsed time starting from when a route has expired (been set to infinite distance)after which you may delete the route permanently from the routing table. You may assume that this value is amultiple ofadvertisement cycle time. Defaults to 120.

If running the DSR protocol, it should also recognize:

13

-d secondsRoute discovery timeout. The amount of time after which a source should timeout a route discovery andassume the destination does not exist. Defaults to 5.

-s secondsStale route timeout. The amount of time before you consider an entry in the path cache to be stale and discardit. Defaults to 120.

Your IRC server will always have three arguments:

usage:./sircd nodeID config file {DVR | DSR}

nodeIDThe nodeID of the node.

config fileThe configuration file name.

DVR | DSRString indicating which protocol to use.

8.1.3 Configuration File Format

1

2

3 4

5

Figure 4: Sample network.

This file describes theneighborhoodof a node. The neighborhood of a node1 is composed by node1 itself andall the nodesn that are directly connected to1. For example, in Figure4, the neighborhood of node1 is {1, 2, 3}. Theformat of the configuration file very simple, and we will supply you with code to parse it. The file contains a series ofentries, one entry per line. Each line has the following format:

nodeID hostname routing-port local-port IRC-port

nodeIDAssigns an identifier to each node.

hostnameThe name or IP address of the machine where the neighbor node is running.

local-portThe TCP port on which the routing daemon should listen for the local IRC server.

routing-portThe port where the neighbor node listens for routing messages. Similarly, theforward-port specifies theport the neighbor node uses to receive and forward regular packets.

IRC-portThe TCP port on which the IRC server listens for clients and messages forwarded by other IRC servers.

14

Node 2 Node 52 localhost 20203 20204 20205 3 unix3.andrew.cmu.edu 20206 20207 202081 unix1.andrew.cmu.edu 20200 20201 20202 5 localhost 20209 20210 202113 unix3.andrew.cmu.edu 20206 20207 20208

Figure 5: Sample configuration files for node2 and5.

How does a node find out which ports it should use as routing, IRC, and local ports? When reading the config-uration file if an entry’snodeID matches the node’s nodeID of the node (passed in on the command line), then thenode uses the specified port numbers to route and forward packets. Figure5 contains a sample configuration filescorresponding to node2 and node5 for the network in Figure4. Notice that the file for node2 contains informationabout node2 itself. Node2 uses this information to configure itself.

We have provided you with a simple script calledgenconfig.pl that will auto-generate all the configurationfiles for a specified network graph, which you can find in the./util subdirectory of the handout. Read the text atthe top of the script for documentation.

8.1.4 Invocation

This is how we will start your IRC network.

1. First, we start each routing daemon with the commands:./srouted -i 0 -c node0.conf ... &./srouted -i 1 -c node1.conf ... &./srouted -i 2 -c node2.conf ... &. . .Each routing daemon will be started with its own configuration file to find out about its neighbors, which wedescribe below, and its nodeID. In addition, we will pass it certain arguments to tell it to use DVR or DSR andhow to set the timer values, which we also describe below.

2. Next, we will start each IRC server at each node:./sircd 0 node0.conf DVR &./sircd 1 node1.conf DVR &./sircd 2 node2.conf DVR &. . .or:./sircd 0 node0.conf DSR &./sircd 1 node1.conf DSR &./sircd 2 node2.conf DSR &. . .Each IRC Server will be passed its nodeID and the configuration file to find out about its neighbors and whatports it should use/talk to. In addition, it will be passedDVRif it should talk to the routing daemon using DVRcommands andDSRotherwise.

3. Now we will wait enough time such that the routing state should have converged and test your system. (We mayalso bring down nodes and restart them to test how resilient your system is to faults)

8.2 Framework Code

We have provided you with some framework code to simplify some tasks for you, like reading in the command linearguments and parsing the configuration file. You do not have to use any of this code if you do not want to. This codeis documented inrtlib.h and implemented inrtlib.c . Feel free to modify this code also.

However, youmust use the following three routines, which are declared inrtgrading.h and implemented inrtgrading.c , and mustnot modify them:

15

• rt init(...) : You must call this function when your routing daemon starts with theargc andargv passedto your program.

• rt sendto(...) : Wrapper function for thesendto() system call. The parameters and semantics are thesame as in the system call. You should use this function to send UDP packets in your routing daemon.

• rt recvfrom(...) : Wrapper function for therecvfrom() system call. The parameters and semanticsare the same as in the system call. You should use this function to receive UDP packets in your routing daemon.

We will replacertgrading.c with implementations which we will use for grading so you should not modify it.

DISCLAIMER: We reserve the right to change the support code as the project progresses to fix bugs and to intro-duce new features that will help you debug your code. You are responsible for reading the b-boards to stay up-to-dateon these changes. We will assume that all students in the class will read and be aware of any information posted tob-boards.

8.3 Testing

To facilitate the development, you can run all your routing engines in the same machine using different ports. In orderto avoid “port collisions” among routing engines from different groups, use port numbers in the range:

[20000 + group number × 100, 20000 + group number × 100 + 99]

For example, if your group number is 23, then you should choose the port numbers from the following range[22300, 22399].If you are testing a configuration with 3 nodes, then the node addresses could be the following:

Node Id IP address Routing Port Local Port IRC Port1 127.0.0.1 22300 22301 223022 127.0.0.1 22303 22304 223053 127.0.0.1 22306 22307 22308

See Section8.1.4for an example of how to start up your IRC network. The utility scripts we provide do this portassignment for you.

How can you test your programs?

1. You cantelnet to the local port on your routing daemons to inject destinations and check routing tables andpath caches.

2. To test if your system can handle node faults, kill some of your routing daemons and IRC servers.

3. To test if your system can handle link faults, try blocking off a pair of UDP ports between two routing daemons.(You can do this artificially in your code by dropping packets that go between them)

9 Routing Protocol Evaluation

DVR and DSR are designed for different kinds of environments. Given different “workloads,” or usage patterns (likeusers joining, leaving, and messaging remote users on IRC servers), we expect each protocol to perform differently.Suppose we are interested in the “communication cost” of a routing protocol — that is, the total number of routingpackets that it sends during a given workload.

As the final part of the assignment, you should answer the following questions:

Under what types of workloads would you expect DVR to have a lower communication cost than DSR? Un-der what workloads would you expect DSR to have a lower communication cost?

Things you might think about are the number of different people that users talk to, how frequently they talk to them,how spread out they are in the network, and how often people change IRC servers (i.e., are “mobile”).

For extra credit, you can evaluate your hypothesis with real workloads (see Section11.3).

16

10 Getting Started

Here are some steps we suggest you use to get started:

1. Read through this entire document to get a general idea of what you will need to do.

2. Decide how you will split up the work between you and your partner. May parts of this project can be done inparallel — for example, one of you can implement DVR and the other could implement DSR. But you shouldcoordinate since they both have to put be in the same program. Both of you should understand everythingimplemented for this project.

3. Get familiar with UDP socket programming, which is almost identical to TCP socket programming, but notquite. There are some references to help you at the end of this document.

4. Write up a design of each part of the routing daemon and decide what data structures you will need. Decidewhether you will be using multiple threads,select() , or a combination of both.

5. Before you start implementing message forwarding in your IRC Server, carefully design a protocol. You willhave to design one for use with DVR and one for use with DSR.

6. It may be useful to learn the basics of a scripting language to make some repeatable “regression tests.” You canalso use the providedrtworkload.pl script (see the end of Section11.3for more information on this script)and write your own workloads to test with.

Here are some suggested milestones:

√Date Milestone

2/26 Routing daemon implementation complete2/28 Routing daemon tested thoroughly3/16 IRC server extensions complete3/18 IRC server extensions tested thoroughly3/19 Answer questions proposed in Section93/19 Due date

Start early!

11 Grading and Evaluation

When we grade your submission, we will rungmake to build your programs and then run a combination of tests andgrading scripts to evaluate your submission. If your project generates compiler warnings during compilation, you willlose credit; if your server dumps core during our testing, you will lose substantial credit. Remember to compile withthe-Wall flag, otherwise you will lose points if this is not in yourMakefile .

Poor design, documentation, or code structure will probably reduce your grade by making it hard for you toproduce a working program, and making it hard for us to understand it. Egregious failures in these areas will causeyour grade to be lowered even if your implementation performs adequately. Putting all of your code in one modulecounts as an egregious design failure. It is better to have partial functionality working solidly than lots of code thatdoesn’t actually do anything correctly.

11.1 Grade breakdown

The following is a list of the different parts of the assignment and how much of the total project grade they are worth.You get a maximum of 6 extra credit points.

17

√Description (%)

Distance Vector RoutingConverge to stable routing state (no failures)25Handle communication failures 5Dynamic Source RoutingRoute discovery 25IRC Server ExtensionsUsers added and removed from network 4Forwarding with DVR 18Forwarding with DSR 18Routing Protocol Evaluation 5Extra Credit +6

11.2 Hand In

Below is a listing of all of the files you should submit. The hand-in directory is/afs/andrew/course/15/441/grpNN ,whereNNis your group number.

• GNU compatibleMakefile . Make sure all the variables and paths are set correctly such that your programcompiles in the hand-in directory. TheMakefile should build two executable namedsrouted andsircd .

• All of your source code (files ending with.c , .cpp , .h , etc. only, no.o files and no executables)

• readme.txt : File containing a brief description of your design of your routing daemon, a complete descrip-tion of the protocols you used for forwarding IRC messages, and your answers to the questions proposed inSection9.

• tests.txt : File containing documentation of your test cases and any known issues you have.

• extra.txt : Description of extra credit features, if implemented.

11.3 Extra Credit

Here are some ideas for extra credit features you can implement. This is by no means an exclusive list — if you havean idea feel free to contact us. You should make your extra credit features disabled by default, but have a way to enablethem (e.g., a command line argument).

• Non-blocking Mini-Protocol, 3 points: An undesirable property of our routing daemon is that the IRC Servermust block while waiting for a response from it. Make your IRC Server not block while waiting for a response.Furthermore, allow your IRC Server to submit multiple requests to the routing daemon at the same time; forexample, so that it can initiate multiple route discoveries at the same time.

• Multiple Logins, 5 points: A user may be logged on with the same nick at multiple IRC Servers. In our currentdesign, messages will only be routed to one of those IRC Servers since we assume there is a single path to anydestination. Design and implement a minimal extension to one of the routing protocols and your IRC forwardingscheme so that messages can be efficiently routed to all the locations where a user is logged on (i.e., somethingother than always broadcast every message to every server).

• Distributed Channels, 6 points: In this project, you only forwarded messages directed at individual users.Design and implement a way for your IRC Servers to route PRIVMSGs to channels to all the users in thatchannel (in addition to the other IRC commands that affect channels if you wish). You may extend the routingprotocol, or use it as is. (Hint : If you can handle multiple user logins, then solving this problem should be atrivial extension)

• DSR Extensions, 6 points: The DSR for Mobile Adhoc Networks draft specification [8] describes several waysthat nodes other than the source can cache paths during route discovery. Implement some of these suggestions.What types of workloads your caching extensions would help? When it would be wasteful? Create exampleworkloads and evaluate your hypotheses.

18

• Workload Evaluation, 6 points: Section9 asked you which situations you would use DVR for and whichones you would use DSR for. Evaluate your hypothesis with real workloads. We have provided you with someworkloads and a script to run them. The workloads consist of users joining and leaving IRC servers in thenetwork and sending messages to other users. Run each workload using both DVR and DSR and count thenumber of routing packets seen in your network. Then you should explain why there are large differences (orwhy there are not). In particular, you should answer:

1. Why does the number of messages differ for DVR and DSR given a particular workload?

2. Why does the number of routing messages differ for DVR when using different workloads? Why does itdiffer for DSR? (Hint: the number of chat messages sent is exactly the same in each workload.)

In order to answer these questions, you should instrument your code so that each routing daemon keeps track ofthe number of packets it sends, and you can extract this information after some period of time.

3

5

4

2

0 1

Figure 6: Network used in the evaluation.

Running the Workloads: The two scripts you need for generating and running the workloads are in the./workload subdirectory of the handout. To generate the workloads, run the script:

./genworkload.pl grp num hostname

wheregrp numis your group number andhostname is the host that you will run your test on. This will gener-ate the four workloads:committed.workload , chatty.workload , promiscuous.workload , andmobile.workload . The script will also generate 6*.conf files which are the configuration files you shoulduse to start your network. Read the text at the top of the script for further documentation.

To run a workload, first start up your network with the 6*.conf files generated. These files describe thenetwork shown in Figure6. Use the default arguments for both DVR and DSR. Wait a couple seconds for thenetwork to connect up. Then run the script:

./rtworkload.pl workload file

whereworkload file is one of the workload files generated bygenworkload.pl .

References

[1] 15-441: Computer networks web site.http://www.cs.cmu.edu/˜prs/15-441/ .

This is the class’s website, it contains information about the courses, including syllabus, lecture notes,project handouts, homework handouts, etc.

19

[2] BSD sockets programming.http://world.std.com/˜jimf/papers/sockets/sockets.html .

Gives some code examples for creating sockets and writing to them.

[3] The class bulletin board.news:cyrus.academic.cs.15-441 .

We fully encourage you to read and post questions to the class bboard. The TAs will be readingthe bboard daily, and this is the best place to get quick answers to short questions. If your questioninvolves a lot of code, or if it will take more one minute to answer, please come to our office hoursinstead.

[4] GNU make manual.http://www.gnu.org/manual/make/html_mono/make.html .

Everything you need to know (and much much more) aboutgmake can be found here. The Makefilefor this assignment should be very simple.

[5] Google groups.http://groups.google.com .

This is Google’s archive of USENET postings. If you have a programming question (i.e. how do I doin C?), or if you can’t figure out what a certain function does, this is a great place to find answers.

[6] Sockets FAQ.http://www.developerweb.net/sock-faq/ .

Huge FAQ providing many questions and answers to socket programming. Search here if you havespecific socket programming problems.

[7] UDP socket programming.http://www.cs.rpi.edu/courses/netprog/lectures/ppthtml/udp_sockets_programming/ .

Slides from a UDP socket programming tutorial similar to the tutorial Geoff gave for TCP socketsearlier in the semester.

[8] D. B. Johnson, D. A. Maltz, and Y.C. Hu. The dynamic source routing protocol for mobile ad hoc networks.IETF DRAFT 09, http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-09.txt , April 2003.

This IETF Draft describes the proposed DSR protocol.

[9] G. Malkin. RIP version 2. RFC 2453,http://www.rfc-editor.org/rfc/rfc2453.txt , Nov 1998.

This RFC describes version 2 of the RIP protocol, which is backwards compatible with version 1.

[10] L. L. Peterson and B. S. Davie.Computer Networks: A Systems Approach. Morgan Kaufman, 3nd edition, 2003.

This is the class textbook. You can find a tutorial on distance vector routing and RIP on pp. 274-282.You can find information on Gnutella’s file search protocol on pp. 691-692, which is similar to ourdynamic source routing protocol.

20