5.2 Routers Local Site RON routers implement the router virtual interface, which UDP)(ivert Socket)(Raw socket has only a single function call, lookup(pkt *mypkt). The RON library provides a trivial static router, and a dynamic router Emit that routes based upon different metric optimizations. The dynamic CMP router is extensible by linking it with a different set of metric de- iptions. Metric descriptions provide an ev score of a link. and a list of metrics that the routin table needs to generate and propagate. The implementation'srout- le creation ific to which also is local? Type Ites the need for the flow cache the multi-level routing table at the bottom of Figure 7 Route ookup AAKEROUTING TABLE(POLICIES, METRICS, PEERS) foreach p in policies foreach M in MEtRics Routing Pref Demux foreach Dest in peers foreach Hop in PEERS Dst N AND P permits( Hop, Dest)f default c=M eval(me, Hop, Dest); if sc> best-score i best _score= sc Hop, Figure 7: The resilient IP forwarder. Packets enter the sys tem through FreeBSD's divert sockets. They are handed to the table[PI[m[Dest]=nertJiop RON forwarder, which looks up the next hop. When the packet We have implemented the clique classifier discussed in local raw socket, where it re-enters IP processing tion 4.3, and are implementing a general policy classifier provide classifiers for the resilient IP forwarder 5.3 Monitoring virtual links would restrict its application-specific fo lities. The on core services run without speci Node a Node B privileges. The conduit at the entry no gatewav the ron, and classifies every packet. This classification is client- ID 5: time 33 pecific; it labels the packet with information that decides what ID5 metric is later used to route the packet. As an example sponse 2 a ron Ip forwarder conduit might label dns and Http traffic ID 5: time 39- as"latency-sensitive"and FTP traffic as"throughput-intensive, th rtts which would cause the downstream ron forwarders to use the Record"success" with rtt6 appropriate routing metric for each packet type. Non-entry RON nodes route the packet based only on the attached label and desti- nation of the packet. Figure 8: The active probers probing mechanism. with three This design ensures that all client- and application-specific rout- packets, both participants get an RTT sample without requir ing functions occur only at the entry and exit conduits, and that for- ng synchronized clocks. warding inside the ron is independent of client-specific logic. In addition to reducing the per-packet overhead at intermediate nodes. Each ron node in an N-node ron monitors its n-1 packet. This means, for example, that a ron node implementing prober component maintains a copy of a peers table w. it also localizes the client-specific computation required on each irtual links using randomized periodic probes IP forwarder may also participate in an overlay with a confer- encing application, and help improve the reliability of data delivery prober sends a small UDP probe packet to the remote peer. Each e conrerence lement the application-specific methods that label packets to tell the IP for- robe packet has a random 64-bit ID. The process used by the warder which routing metrics to use for conference packets rober is shown in Figure 8. When a node receives an initial probe request from a peer, it sends response I to that peer, and resets its probe timer for that peer. When the originating node sees response 5.1 The lP Forwarder 1, it sends response 2 back to the peer, so that both sides get reach- We implemented the resilient IP forwarder using FreeBSD's di- ability and rTT information from 3 packets vert sockets to automatically send Ip traffic over the ron, and emit The probing protocol is implemented as a ron client, which it at the other end. The resilient IP forwarder provides classifica- communicates with performance database(implemented as a stand- tion, encapsulation, and decapsulation of IP packets through a spe- alone application running on the Berkeley DB3 backend)using cial conduit called the ip_conduit(top of Figure 7)Divert Socket Routing Pref Demux Latency Loss B/W Hop Dst Next UDP Type Demux Yes Local Data Protocols and Conduits No send() recv() Policy Demux vBNS Router default Route Lookup flags policy Yes Conduit Must_Fragment? Classify Encapsulate is_local? Forwarder Raw Socket ICMP Emit Outbound FreeBSD Networking IP To RON nodes To/From Local Site Figure 7: The resilient IP forwarder. Packets enter the sys￾tem through FreeBSD’s divert sockets. They are handed to the RON forwarder, which looks up the next hop. When the packet arrives at its destination, the conduit writes the packet out on a local raw socket, where it re-enters IP processing. would restrict its application-specific forwarding capabilities. The RON core services run without special kernel support or elevated privileges. The conduit at the entry node is the client’s gateway to the RON, and classifies every packet. This classification is client￾specific; it labels the packet with information that decides what routing metric is later used to route the packet. As an example, a RON IP forwarder conduit might label DNS and HTTP traffic as “latency-sensitive” and FTP traffic as “throughput-intensive,” which would cause the downstream RON forwarders to use the appropriate routing metric for each packet type. Non-entry RON nodes route the packet based only on the attached label and desti￾nation of the packet. This design ensures that all client- and application-specific rout￾ing functions occur only at the entry and exit conduits, and that for￾warding inside the RON is independent of client-specific logic. In addition to reducing the per-packet overhead at intermediate nodes, it also localizes the client-specific computation required on each packet. This means, for example, that a RON node implementing an IP forwarder may also participate in an overlay with a confer￾encing application, and help improve the reliability of data delivery for the conference. The conference node conduits implement the application-specific methods that label packets to tell the IP for￾warder which routing metrics to use for conference packets. 5.1 The IP Forwarder We implemented the resilient IP forwarder using FreeBSD’s di￾vert sockets to automatically send IP traffic over the RON, and emit it at the other end. The resilient IP forwarder provides classifica￾tion, encapsulation, and decapsulation of IP packets through a spe￾cial conduit called the ip conduit (top of Figure 7). 5.2 Routers RON routers implement the router virtual interface, which has only a single function call, lookup(pkt *mypkt). The RON library provides a trivial static router, and a dynamic router that routes based upon different metric optimizations. The dynamic router is extensible by linking it with a different set of metric de￾scriptions. Metric descriptions provide an evaluation function that returns the “score” of a link, and a list of metrics that the routing table needs to generate and propagate. The implementation’s rout￾ing table creation is specific to single-hop indirection, which also eliminates the need for the flow cache. The following algorithm fills in the multi-level routing table at the bottom of Figure 7: MAKEROUTINGTABLE(POLICIES, METRICS, PEERS) foreach P in POLICIES foreach M in METRICS foreach Dest in PEERS foreach Hop in PEERS if P .permits(me; Hop) AND P .permits(Hop; Dest) f sc = M.eval(me; Hop; Dest); if sc > best score f best score = sc; next hop = Hop; g g table[P ][M][Dest] = next hop; We have implemented the clique classifier discussed in Sec￾tion 4.3, and are implementing a general policy classifier. Both provide classifiers for the resilient IP forwarder. 5.3 Monitoring Virtual Links Record "success" with RTT 6 Node A Node B Initial Ping Response 1 Response 2 ID 5: time 10 ID 5: time 15 ID 5: time 33 ID 5: time 39 Record "success" with RTT 5 Figure 8: The active prober’s probing mechanism. With three packets, both participants get an RTT sample without requir￾ing synchronized clocks. Each RON node in an N-node RON monitors its N ￾ 1 virtual links using randomized periodic probes. The active prober component maintains a copy of a peers table with a next probe time field per peer. When this field expires, the prober sends a small UDP probe packet to the remote peer. Each probe packet has a random 64-bit ID. The process used by the prober is shown in Figure 8. When a node receives an initial probe request from a peer, it sends response 1 to that peer, and resets its probe timer for that peer. When the originating node sees response 1, it sends response 2 back to the peer, so that both sides get reach￾ability and RTT information from 3 packets. The probing protocol is implemented as a RON client, which communicates with performance database (implemented as a stand￾alone application running on the Berkeley DB3 backend) using a simple UDP-based protocol