Community Research and Development Information Service - CORDIS

Packet flow architecture

The LAP has connections to Residential Devices (via their Residential Gateways) and to several networks. In general, packets enter the LAP, pass through the firewall, are handled by the proxy, pass out through the firewall, and finally leave the LAP.

Packets belonging to services barred by the user-preferences of their originating Residential Device are rejected before they get to the proxy. Outbound and inbound packets pass through the firewall and proxy, and go into an outbound and inbound queue respectively.

To look at the interactions between the SRM components, consider the first outbound packet of a service, and the first inbound response packet. Assume that the packet is from a RD behind RG1, whose user preferences require this service to use network1 with priority 3. It is then possible to identify 14 detailed stages (see diagram) as shown in deliverable D3.4.

The diagram in D3.4 hows an initial IPv4 proof-of-concept implementation. The IPv4 + IPv6 implementation used for the final demonstration used “netfilter” connection marking for client <--> proxy microflows. Applying the connection marking via “netfilter” protocol helper routines gives a system with enhanced scalability that also ensures that the change of user-preferences does not impact existing microflows for that user. Some code was also needed to overcome limitations in iproute2 code for IPv6

Future developments would also use connection marking for proxy <--> server microflows between proxy and server. These can be applied by “netfilter” protocol handler routines, that communicate with the proxy via a virtual file in the ”/proc” routine library.

More information on the Torrent project can be found at:

Reported by

Queen Mary University of London
Mile End Road
E1 4NS London
United Kingdom
See on map
Follow us on: RSS Facebook Twitter YouTube Managed by the EU Publications Office Top