Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse
Ontwerp en ontwikkeling van een transparante DSL bonding proxy door David Biot
Promotoren: Prof. Dr. Ir. P. Demeester en Dr. Ir. B. Vermeulen Scriptiebegeleider: Ir. J. Deleu
Scriptie ingediend tot het behalen van de academische graad van Licentiaat Informatica: optie Informatie- en Communicatietechnologie
Academiejaar 2006–2007
Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse
Ontwerp en ontwikkeling van een transparante DSL bonding proxy door David Biot
Promotoren: Prof. Dr. Ir. P. Demeester en Dr. Ir. B. Vermeulen Scriptiebegeleider: Ir. J. Deleu
Scriptie ingediend tot het behalen van de academische graad van Licentiaat Informatica: optie Informatie- en Communicatietechnologie
Academiejaar 2006–2007
Woord vooraf
Het eindwerk is de climax van de academische studie. Het is een werk waarin een laatstejaarsstudent, na jaren van aanleren van vaardigheden en verwerken van kennis, kan bewijzen dat hij in staat is om op zijn eigen benen te staan en zelf aan wetenschappelijk onderzoek kan doen. In onze samenleving maken we steeds meer gebruik van het Internet en netwerken in het algemeen. Ik heb netwerken steeds fascinerend gevonden. Het met elkaar laten communiceren van computers opent een hele nieuwe wereld waarbij kennis wordt gedeeld, entertainment wordt aangeboden en sociale contacten worden gemaakt. Het is dan ook met het grootste plezier dat ik de uitdaging heb aangenomen om een eindwerk bij het IBCN te verwezenlijken. Na het maandenlange zwoegen om een bijdrage te kunnen leveren aan de kennis over het bundelen van breedbandlijnen, gebiedt het mij de mensen te bedanken die een al dan niet directe bijdrage hebben geleverd tot het tot stand komen van dit eindwerk. Zo gaat mijn dank naar mijn promotoren Piet Demeester en Brecht Vermeulen, voor de geboden kans om dit eindwerk te verwezenlijken. Graag zou ik mijn begeleider Johannes Deleu willen bedanken voor de vele tijd en energie die hij in dit eindwerk ge¨ınvesteerd heeft. Een speciale vermelding gaat naar mijn ouders, zonder wie ik deze studies nooit gestart noch be¨eindigd zou hebben. Dank u wel voor de continue steun, de extra moed op de moeilijkere dagen, en om steeds in mijn capaciteiten geloofd te hebben. Dank u wel Aur´elie, voor het steeds klaar te staan in de moeilijke, maar ook in de minder moeilijke dagen. Jij bent een bron van inspiratie geweest. Tot slot wens ik nog mijn vrienden en familie te bedanken, die vaak als welkome uitlaatklep dienden, en zonder wie ik nooit de persoon zou geworden zijn die ik nu ben.
David Biot, augustus 2007
Toelating tot bruikleen
“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”
David Biot, augustus 2007
Ontwerp en ontwikkeling van een transparante DSL bonding proxy door David Biot Scriptie ingediend tot het behalen van de academische graad van Licentiaat Informatica: optie Informatie- en Communicatietechnologie Academiejaar 2006–2007 Promotoren: Prof. Dr. Ir. P. Demeester, Dr. Ir. B. Vermeulen Scriptiebegeleider Ir. J. Deleu Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse
Samenvatting Sinds de introductie voor het grote publiek eind jaren ’80, is het internet sterk gegroeid en heeft het een hele resem nieuwe toepassingen voortgebracht. Nieuwe toepassingen vragen steeds meer bandbreedte, waardoor de noodzaak zich biedt om steeds snellere internettoegang aan de eindgebruiker te verlenen. Snellere internettoegang vraagt vaak dure investeringen in nieuwe infrastructuur. In deze scriptie wordt een alternatief geboden dat gebruik maakt van de reeds bestaande netwerkinfrastructuur. Via het bundelen van meerdere goedkope klassieke DSL lijnen wordt de bandbreedte naar aanzienlijk verhoogd. Na een analyse van de doelstellingen worden meerdere transparante DSL bonding proxies ontworpen en ontwikkeld op basis van de Click modular router. Door het gebruik van meerdere lijnen komen pakketten vaak in de verkeerde volgorde aan aan hun bestemming. De meeste aandacht wordt dan ook besteed aan het ontwerpen van Click elementen die de aangekomen netwerkpakketten herordenen. Uit de resultaten blijkt de verwezenlijking van een transparante DSL bonding proxy die de bandbreedte van verschillende DSL-lijnen op een robuuste en effici¨ente manier weet te gebruiken, zonder pakketten in verkeerde volgorde door te sturen.
Trefwoorden breedband, bonding, tunnel, DSL, proxy
Design and implementation of a transparent DSL bonding proxy David Biot Supervisor(s): Piet Demeester, Brecht Vermeulen, Johannes Deleu Abstract—The internet is constantly evolving, with new on-line applications creating ever-increasing bandwith-needs. While internet backbones manage to cope with the larger demands, broadband connections to the costumer premises often lag behind and are unable to offer adequate performance when used in combination with on-line storage or remote backup. Though faster connections exist, they are often too expensive for households or smaller companies to acquire. This study offers a cost-friendly alternative by bonding the bandwith of multiple inexpensive DSL connections. The pitfalls of bonding are described, and solutions are proposed. A DSL bonding proxy is than implemented in the Click modular router architecture[1] and put to the test. Keywords—broadband, bonding, tunnel, DSL, proxy
I. I NTRODUCTION
B
ONDING DSL lines means routing network traffic over parallel network paths to increase end-to-end bandwith. Two quite different situations have to be considered, each with their own goals and solutions. Bonding can be used in an environment where a lot of clientserver connections are simultaneously active. Maximising the throughput for one client-server connection is less important than finding the highest average utilisation of all the DSL lines. Several bonding solutions for this situation allready exist, like policy routing or Equal Cost Multipath Routing (ECMP)[2]. Each of these solutions have their own shortcomings. Both solutions rely on classification of client-server connections. This classification will decide how the connections will be distributed among the different DSL lines. A client-server connection will constantly use the same DSL-line during the time its alive. This means that the existing solutions are de facto suboptimal, as it is not possible to predict how much one client-server connection will be used. These solutions cannot react well on sudden big changes in client-server connection usage. The maximum bandwith for one client-server connection will aways be the maximum bandwith a single DSL-line can provide. On the other hand, both solutions provide bonding-possibilities that do not require a lot of processing power. Another situation is when one client-server connection wants to take advantage of the combined bandwith from all the available DSL lines. This means that the network packets of this connection have to be distributed over the different DSL lines. As normal client-server connections are not designed to be routed over different paths at the same moment, a lot of care has to go into trying to make this bonding as transparent as possible. Packets that are routed over different network paths will always encounter different delays before arriving at their destination. This means that with DSL bonding, packets will arrive in a different order than the one they were sent in. To maintain the integrity of a connection, the packets have to be reordered to their initial order. This reordering is the most crucial part of bond-
ing. When not done correctly, this can have serious impacts on throughput of a TCP connection, which relies on packets arriving in the right order. As this reordering of packets requires buffering of packets while waiting for a slower packet, the implementation has to make sure the packets aren’t being held back too long, as this would hurt end-to-end latencies. Existing solutions are also available for this type of bonding, like Linux bonding and True Link Equaliser (TEQL)[2]. Both solutions have problems when up-scaling the number of DSL lines. Notably the reordering of packets is problematic when used with a lot of DSL lines. In this study, three different transparent proxy servers have been designed to provide DSL bonding on packet-level, thus ensuring a single connection can take advantage of all the available bandwith. This solution is also useable in an environment where a lot of client-server connections are alive at the same moment. The transparent DSL bonding proxies have been designed using the Click modular router architecture[1]. The solutions aim to bring a high-performance bonding solution, while eliminating the shortcomings of the existing bonding solutions. II. D ESIGN AND IMPLEMENTATION OF A TRANSPARENT DSL BONDING PROXY
Fig. 1. Representation of the networkconfiguration.
Three different methods for DSL bonding are proposed. While the the first and second method each have rather big shortcomings, the third one offers a robust method for DSL bonding. All methods use two transparent proxy servers to construct a tunnel between client and server, as illustrated in Fig. 1. One of the proxy servers needs to be located near the DSL modems, while the other proxy can be located either at the ISP or the server. When located at the ISP, the client can benefit from an increased bandwith from every possible server, eliminating the need to install special equipment at the server-site. A. NAT A first implementation minimizes the need to design own Click elements. The whole router-configuration can be built using existing Click elements[3]. To minimise overhead, the approach tries to use all the existing network-headers to perform DSL bonding. Using Network Address Translation (NAT),
the source-IP and destination-IP addresses are altered to enable routing between the two transparent proxies. When arriving at the proxy server at the server-side, the original IP header is reconstructed. Because this type of bonding uses NAT on both transparent proxies, all the routing-information needs to be known by the proxies. Thus, only one client-server connection is possible for every Click router configuration. Because of this setback, along with the lack of reordering, this method proves to be not useable for DSL bonding. A.1 Timestamp A second approach tries not to alter the original packets, to maintain the integrity of the packet stream. This means that all the extra information needed to perform DSL bonding has to be added to each network packet. To perform the routing between both transparent proxies, an IP tunnel is created (see II-A.2). To perform reordering, a timestamp is added to every packet (see II-A.3). A.2 IP tunnel The IP header of the original packet contains the basic routing information between client and server. In our approach, the packets need to be handled by two transparent proxies: one on the client-side and one on the server-side. To ensure every packet travels past both proxies, an extra IP header containing the routing information between both proxies is added in front of each packet. The source- and destination IP address contains the IP addresses of the Click routers. The protocol-type of the new IP header is 4, meaning that IP-in-IP encapsulation is used. When a transparent proxy receives a packet with two IP headers, the external IP header is removed and the packet processed. The proxy server near the modems has one external IP address for every modem that is connected to it, so every IP-stream travelling through different modems has different source- or destination addresses, depending on whether the packets are travelling from client to server or from server to client. A.3 Reordering Making use of existing Click elements, we decided for this approach to append a timestamp to every packet’s data. Altough Click elements allready exist for storing and handling a timestamp, no element exists to read a timestamp out of the data of a network packet. An own Click element was designed for this purpose. The Click modular router architecture has an element called TimesortedSched[3]. This element probes all its inputlines and sends the packet with the lowest timestamp. While this approach offers basic packet reordering, it is far from perfect. Packet injection with low timestamps can block network traffic passing the transparent proxy. The reordering also isn’t perfect. The router cannot know if a packet is delayed. It just probes all its inputs and sends the packet with the lowest timestamp. B. Sequence This approach is quite similar to the one used in II-A.2. The packets are also sent through an IP tunnel, but instead of appending a timestamp, a sequencenumber is added to every packet.
Fig. 2. network packet after encapsulation and addition of sequence number
B.1 Reordering This sequencenumber provides perfect traceability for missing or delayed packets. When the last packet that the receiving transparent proxy forwarded had a sequencenumber of n, it knows that it has to wait until packet n + 1 has arrived, if that the packet hasn’t been dropped on the network path. As no standard Click element can handle sequencenumbers in data packets, several Click elements have been designed to append a sequencenumber, to extract it from a packet, and to reorder the incoming packets. The reordering-element uses an internal buffer for packets that have to wait to be forwarded until delayed packets arrive. The biggest challenge for this type of DSL bonding, is to design robust rules that can decide whether a packet has been dropped or is just late. Several rules have been implemented. A timeout is generated when: • a packet is delayed longer than a certain amount of time. • the internal ringbuffer of the reordering element has an occupation of 90% • a certain amount of packets has been arriving on every inputline while waiting for the packet. The result is a DSL bonding solution that offers robust reordering while being transparent to the applications that send data over the multiple DSL lines. III. P ERFORMANCE Tests have been done with Iperf using ADSL2+ modems that used G.992.5. The modems were all synced at 22Mbps down / 1Mbps up rates. The modems were connected to the transparent proxy near the client via VLANs over a 100Mbps UTP cable. Using five modems, a TCP-payload bandwith of 80 Mbps and a UDP-payload bandwith of 81 Mbps have been attained. When sending UDP packets at a faster rate, the Click router is unable to send more than 81 Mbps to the client, even when using 6 modems. It is possible that Click can’t achieve higher speeds over UDP when no polling drivers are used. IV. C ONCLUSIONS We showed that it is possible to have very fast broadband access when bundling several DSL-lines. The biggest challenge is reordering the packets and defining good timeout rules. To achieve this, configurations and custom elements have been designed for the Click modular router. R EFERENCES [1] E. Kohler, R. Morris, C. Benjie, J. Jannotti, and M. F. Kaashoek, “The Click modular router,” ACM Transactions on Computer Systems, vol. 18, no. 3, pp. 263–297, 2000. [2] W. Heylen, “Experimentele evaluatie en karakterisatie van de efficintie van verschillende types DSL bonding,” M.S. thesis, Departement PIH, Hogeschool West-Vlaanderen, 2005. [3] “Click Elements,” http://www.read.cs.ucla.edu/click/ elements.
INHOUDSOPGAVE
vi
Inhoudsopgave 1 Inleiding
1
2 Situering
3
2.1
DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Proxy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.1
Klassieke Proxy server . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.2
Transparante Proxy server . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.3
Performance Enhancing Proxies . . . . . . . . . . . . . . . . . . . . . . . .
7
DSL bundeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.1
Meerdere clients, meerdere servers . . . . . . . . . . . . . . . . . . . . . .
8
2.3.2
E´en client, ´e´en server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Click Modular Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.4.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.4.2
Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Protocollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.5.1
Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.5.2
VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.5.3
PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.5.4
ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.5.5
IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.5.6
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.5.7
UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.5.8
TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3
2.4
2.5
INHOUDSOPGAVE
vii
3 Ontwerp en ontwikkeling van een transparante DSL bonding proxy
25
3.1
Doel van eigen ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2
Ontwikkeling van een proxy server . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.1
Eerste versie: NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.2
Tweede versie: timestamp . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2.3
Derde versie: sequentie
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2.4
Opmerkingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
Ontworpen Click elementen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.3.1
AddVlanTag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.3.2
ExtractSequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.3.3
ExtractTimestamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.3.4
RemoveVlanTag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.3.5
SequenceSortedSched
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.3.6
SetSequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.3.7
StoreSequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
Studie theoretisch haalbare bandbreedte . . . . . . . . . . . . . . . . . . . . . . .
52
3.4.1
100Mbps UTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.4.2
ADSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
3.3
3.4
4 Resultaten 4.1
4.2
4.3
4.4
58
RoundRobinSched . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.1.1
Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.1.2
Upload
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
TimeSortedSched . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.2.1
Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.2.2
Upload
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
SequenceSortedSched . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.3.1
Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.3.2
Upload
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.3.3
Zonder modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
INHOUDSOPGAVE
viii
5 Besluit
70
A Installatie en Configuratie
73
A.1 Gebruikte opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
A.2 Installatie & Configuratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
A.2.1 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
A.2.2 Artemis3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
A.2.3 Artemis12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
A.2.4 Artemis7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
A.2.5 Artemis6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
A.2.6 modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
B Schema’s van Click configuraties
78
Referenties
83
LIJST VAN FIGUREN
ix
Lijst van figuren 2.1
Het frequentieplan voor ADSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Overzicht van een typische DSL-verbinding. . . . . . . . . . . . . . . . . . . . . .
4
2.3
Netwerk protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4
Een mogelijke configuratie die gebruik maakt van connectie load balancing. . . .
8
2.5
Deze configuratie maakt gebruik van pakket load balancing. . . . . . . . . . . . .
10
2.6
Push en Pull control in Click. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.7
Een voorbeeld van een Click configuratie. . . . . . . . . . . . . . . . . . . . . . .
14
2.8
Een voorbeeldimplementatie van een Click element. . . . . . . . . . . . . . . . . .
15
2.9
Performantiemeting Click. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.10 Samenstelling van een ethernet datagram . . . . . . . . . . . . . . . . . . . . . .
17
2.11 Samenstelling van een ATM cel . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.12 Samenstelling van een IP pakket . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.13 Samenstelling van een UDP pakket . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.14 Samenstelling van een TCP pakket . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.1
Verschillende mogelijkheden om de Click-routers te plaatsen. . . . . . . . . . . .
28
3.2
De werking van de eerste versie van de DSL bonding proxy. . . . . . . . . . . . .
29
3.3
Samenstelling IP pakket bij de tweede versie van de bonding DSL router . . . . .
30
3.4
Packetflow bij de tweede versie van de transparante DSL bonding proxy . . . . .
32
3.5
Evolutie externe IP header bij IPinIP verkeer DSL bonding proxy bij gebruik van NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.6
Samenstelling IP pakket bij de derde versie van de bonding DSL router . . . . .
36
3.7
Packetflow bij de derde versie van de transparante DSL bonding proxy . . . . . .
36
3.8
Een illustratie van de werking van SequenceSortedSched. . . . . . . . . . . . . . .
44
LIJST VAN FIGUREN
3.9
x
De beslissingsboom bij een push bij SequenceSortedSched. . . . . . . . . . . . . .
49
3.10 De beslissingsboom bij een pull bij SequenceSortedSched. . . . . . . . . . . . . .
50
3.11 De werking van StoreSequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.12 Illustratie van de IFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.1
RoundRobin Downstream UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.2
RoundRobin Downstream TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.3
RoundRobin Upstream UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.4
RoundRobin Upstream TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.5
TimeStamp Downstream UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.6
TCP bandbreedte TimeSortedSched . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.7
TimeStamp Upstream UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.8
UDP bandbreedte downstream SequenceSortedSched. . . . . . . . . . . . . . . .
66
4.9
TCP bandbreedte downstream SequenceSortedSched. . . . . . . . . . . . . . . . .
67
4.10 UDP bandbreedte upstream SequenceSortedSched. . . . . . . . . . . . . . . . . .
67
4.11 TCP bandbreedte upstream SequenceSortedSched. . . . . . . . . . . . . . . . . .
68
A.1 De opstelling op het testlab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
B.1 Schema click-config tweede versie DSL bonding proxy aan client-zijde
. . . . . .
79
B.2 Schema click-config tweede versie DSL bonding proxy aan server-zijde . . . . . .
80
B.3 Schema click-config derde versie DSL bonding proxy aan client-zijde . . . . . . .
81
B.4 Schema click-config derde versie DSL bonding proxy aan server-zijde . . . . . . .
82
LIJST VAN TABELLEN
xi
Lijst van tabellen 2.1
DSL technologie¨en . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Overhead ge¨ıntroduceerd door het Ethernet protocol . . . . . . . . . . . . . . . .
18
2.3
Overhead ge¨ıntroduceerd door de IP-header . . . . . . . . . . . . . . . . . . . . .
20
2.4
Overhead ge¨ıntroduceerd door de UDP-header . . . . . . . . . . . . . . . . . . .
22
2.5
Overhead ge¨ıntroduceerd door de TCP-header . . . . . . . . . . . . . . . . . . . .
24
3.1
De protocollen die gebruikt worden bij het verbinden over een UTP kabel, en hun overhead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Uiteindelijke tabel met de protocollen die gebruikt worden bij het verbinden over een UTP kabel, en hun overhead. . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.3
De protocollen die gebruikt worden bij PPPoE. . . . . . . . . . . . . . . . . . . .
56
4.1
UDP RoundRobinSwitch Down . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.2
TCP bandbreedte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.3
UDP RoundRobinSwitch Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.4
TCP bandbreedte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.5
UDP TimesortedSched down . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.6
UDP TimesortedSched up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.7
UDP bandbreedte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.8
TCP bandbreedte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.9
UDP bandbreedte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.10 TCP bandbreedte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
4.11 UTP bandbreedte SequenceSortedSched . . . . . . . . . . . . . . . . . . . . . . .
69
A.1 Kernel-versies en IP’s van het gebruikte materiaal. . . . . . . . . . . . . . . . . .
74
3.2
Gebruikte Afkortingen ADSL
Asymmetric Digital Subscriber Line
ATM
Asynchronous Transfer Mode
BRAS
Broadband Remote Access Server
CLP
Cell Loss Priority
CRC
Cyclic Redundency Check
CSMA/CD
Carrier Sense Multiple Access with Collision Detection
DSL
Digital Subscriber Line
DSLAM
Digital subscriber line access multiplexer
ECMP
Equal Cost Multipath Routing
FCS
Frame Check Sequence
GRE
Generic Routing Encapsulation
GFC
Generic Flow Control
HEC
Header Error Correction
HTTP
HypertText Transfer Protocol
ICMP
Internet Control Message Protocol
IETF
The Internet Engineering Task Force
IFG
Inter Frame Gap
ITU
International Telecommunication Union
IP
Internet Protocol
IPsec
Internet Protocol Security
ISP
Internet Service Provider
kbps
Kilobit per seconde = 1 000 bits per seconde
LAN
Local Area Network
MAC
Media Access Control
Mbps
Megabit per seconde = 1 000 000 bits per seconde
MTU
Maximum Transmission Unit
NAT
Network Address Translation
PEP
Performance Enhancing Proxy
POTS
Plain Old Telephone Service
PPP
Point-to-Point Protocol
PSTN
Public switched telephone network
PT
Payload Type
QoS
Quality of Service
RTT
Round Trip Time
SHDSL
Symmetric High-Bitrate DSL
SNR
Signal-to-Noise Ratio
SOF
Start Of Frame
TCP
Transmission Control Protocol
TEQL
True Link Equalizer
TTL
Time-To-Live
UDP
User Datagram Protocol
UTP
Unshielded Twisted Pair
VCI
Virtual Channel Identifier
VDSL
Very-high-data-rate DSL
VLAN
Virtual Local Area Network
VPI
Virtual Path Identifier
WAN
Wide Area Network
INLEIDING
1
Hoofdstuk 1
Inleiding Sinds de introductie voor het grote publiek eind jaren ’80, is het internet sterk gegroeid en heeft het een hele resem nieuwe toepassingen voortgebracht, waaronder: surfen, e-mail, nieuwsgroepen, peer-to-peer, voice-over-IP, online storage en vele andere. Binnen de IT-wereld zijn toepassingen vaak enkel gelimiteerd door de verbeelding van de ontwikkelaar, de commerci¨ele mogelijkheden en de capaciteit van de onderliggende infrastructuur. Zo ook voor het internet. De laatste jaren kenden een grote toevloed aan nieuwe toepassingen die de capaciteit van het internet op de proef stelden. Daar waar de capaciteit van de backbones van het internet evolueerde met de noden van de nieuwe toepassingen, was dat minder het geval voor de ”last mile”, het laatste stukje netwerkinfrastructuur tussen de ISP en de eindgebruiker. Wanneer breedband via ADSL in Belgi¨e in 1999 ge¨ıntroduceerd werd, leverde het een standaardsnelheid van 1Mbps down/128kbps up[30]. 8 jaar later biedt een standaard ADSL-abonnement 4Mbps down/256kbps up. De uploadsnelheid is de laatste jaren amper ge¨evolueerd, hetgeen een echte rem betekent voor nieuwe toepassingen zoals online storage, online backup of meer specifiek een KMO die bedrijfskritieke data wil back-uppen bij een extern datacenter. Aangezien de kostprijs voor het aanleggen van snellere verbindingen, zoals bijvoorbeeld glasvezel, voor een KMO te hoog is, dienen er goedkopere alternatieven onderzocht te worden. Een alternatief is het bundelen van meerdere breedbandlijnen om zo een grotere bandbreedte te bekomen. In dit eindwerk gebeurt een verdere karakterisatie van bestaande mogelijkheden tot bundeling van breedbandlijnen, en meer specifiek DSL-lijnen, zoals reeds besproken in het eindwerk van Wilfried Heylen[15]. Na een bespreking van de voor- en nadelen van de bestaande systemen wordt een eigen oplossing ontworpen, ontwikkeld en getest aan de hand van de click! modular
INLEIDING
2
router. Er wordt gefocust op het routeren van IP-verkeer over verschillende DSL-lijnen met het oog op het verhogen van de snelheid tussen 2 eindpunten binnen het internet, met beperkte negatieve gevolgen voor de eindgebruiker. Er wordt getracht het oorspronkelijk verkeer ongewijzigd van het ene eindpunt naar het andere te verzenden, meer bepaald zonder de volgorde waarin de pakketten verstuurd werden te be¨ınvloeden. Hoofdstuk 2 bevat algemene informatie die van belang is om de verdere hoofdstukken goed te begrijpen. Zo wordt er gesproken over DSL(2.1), proxy-servers(2.2), DSL-bundeling(2.3), de Click modular router(2.4) en de gebruikte protocollen(2.5). Hoofdstuk 3 bevat het werk dat tijdens het eindwerk voltooid werd. Zo wordt het doel van eindwerk uitgelegd(3.1) en wordt de gebruikte opstelling beschreven(A.1). Hierna volgt de beschrijving van de drie zelf ontwikkelde transparante DSL bonding proxies. Deze drie proxies zijn ontwikkeld rond het gebruik van NAT(3.2.1), timestamps(3.2.2) of sequentienummers(3.2.3). Het hoofdstuk besluit met de beschrijving van de zelf ontwikkelde Click elementen(3.3) en een theoretische studie van de maximaal haalbare bandbreedte over UTP(3.4.1) en ADSL(3.4.2). Het belangrijkste zelf ontworpen element is SequenceSortedSched. Van dit element zijn meerdere versies gemaakt. De verschillende versies worden besproken. Een uitgebreide analyse van gemaakte performantietesten volgt in Hoofdstuk 4. Hoofdstuk 5 geeft het algemeen besluit van dit eindwerk. In Bijlage A wordt de installatie en configuratie van de transparante DSL bonding proxies uitgelegd, bij gebruik van drie modems Bijlage B bevat schema’s van de click-configuraties van de transparante DSL bonding proxies. Op de CD-ROM staat de implementatie van de verschillende Click elementen, alsook de gebruikte Click configuraties.
SITUERING
3
Hoofdstuk 2
Situering 2.1
DSL
DSL (Digital Subscriber Line) of xDSL staat voor een familie van technologie¨en die gebruikt worden voor digitale transmissie van data over de koperdraad van de klassieke telefoonlijn (POTS). Tabel 2.1 [29] geeft een overzicht van enkele DSL-technologie¨en en hun maximale theoretische transmissiesnelheden. Tabel 2.1: DSL technologie¨en
Family
ITU
Name
Ratified
Maximum Speed capabilities
ADSL
G.992.1
G.dmt
1999
7Mbps down, 800kbps up
ADSL2
G.992.3
G.dmt.bis
2002
8Mbps down, 1Mbps up
ADSL2plus
G.992.5
ADSL2plus
2003
24Mbps down, 1Mbps up
ADSL2-RE
G.992.3
Reach Extended
2003
8Mbps down, 1Mbps up
SHDSL
G.991.2
G.SHDSL
2001
5.6Mbps up/down
VDSL
G.993.1
Very-high-data-rate DSL
2004
55Mbps down, 15Mbps up
VDSL2
G.993.2
Very-high-data-rate DSL 2
2005
100Mbps up/down
ADSL gebruikt twee frequentiebanden voor de transmissie van data, een upstream band en een downstream band. De downstream band wordt gebruikt voor de transmissie van data van de Telephone Exchange naar de eindgebruiker. De upstream band wordt gebruikt voor data die in de tegengestelde richting verstuurd wordt. Figuur 2.1 geeft een overzicht van de gebruikte frequenties op een klassieke analoge telefoonlijn (POTS).
2.1 DSL
4
Figuur 2.1: Het frequentieplan voor ADSL. Het frequentiegebied 0-4kHz wordt gebruikt voor analoge telefonie (PSTN). Het frequentiegebied 25.875-138kHz wordt gebruikt voor de upstream van ADSL, 1381104kHz voor de downstream.
Deze frequentiebanden zijn verder onderverdeeld in frequentiekanalen van elk 4.3125 kHz. De afstand tot de Telephone Exchange, de kwaliteit van de koperdraad en interferentie van radiogolven op de AM-band kunnen elk een invloed hebben op de ruis op deze frequentiekanalen. Door de kanalen klein te houden heeft een hoge ruis op een bepaalde frequentie geen invloed op naburige frequentiekanalen. Bij de initi¨ele training test de modem welke frequentiekanalen een acceptabele signal-to-noise ratio (SNR) bezitten. Deze kanalen worden vervolgens gekozen voor datatransmissie. De ongebruikte frequentiekanalen hebben, behalve een verlaging van de algemene bandbreedte, verder geen invloed op de ADSL-verbinding.[6, 19]
Figuur 2.2: Overzicht van een typische DSL-verbinding.
Zoals te zien op figuur 2.1 worden de signalen voor de analoge telefonie op dezelfde koperdraad doorgestuurd als de ADSL-signalen, enkel het frequentiegebied is verschillend. Dit heeft als
2.2 Proxy server
5
voordeel dat er simultaan data en telefonie-verkeer op hetzelfde moment over de koperdraad gestuurd kan worden. Analoge telefonie wordt meestal in de telefooncentrale gedigitaliseerd tot een 64 kbps datastroom in de vorm van een 8 bit signaal met een sampling rate van 8 000 Hz. Het Nyquist theorema zegt ons dat alle signalen boven de 4 000 Hz in de telefooncentrale afgekapt worden. Het heeft dan ook weinig zin om analoge telefoonsignalen door te sturen met een frequentie hoger dan 4 000 Hz. Om de interferentie tussen de analoge-telefoonsignalen en de ADSL-signalen tot een minimum te beperken worden er filters/splitters gebruikt. Aan de Telephone Exchange wordt er weer een splitter gebruikt om het telefoon-signaal af te splitsen van het ADSL-signaal, zoals ge¨ıllustreerd in fig. 2.2. Vervolgens wordt het ADSL-signaal via een ongedeelde lijn doorgestuurd naar een DSLAM. De DSLAM interpreteert het DSL-signaal en vormt het om tot een Ethernet- (zie 2.5.1) of een ATM-signaal (zie 2.5.4), dat vervolgens over een gedeelde backbone naar de ISP wordt doorgestuurd.[20] Wanneer de ISP gebruik maakt van PPP (zie 2.5.3) voor het connecteren van de modems, zal de data komende van de DSLAM vervolgens naar een BRAS-server gerouteerd worden. De BRASserver zit aan de core van het ISP-netwerk en staat in voor het beheren van de PPP-sessies en het routeren van het verkeer naar het core-netwerk van de ISP.
2.2
Proxy server
Een proxy server is een server die zich in het netwerkpad tussen een client en een andere server bevindt. De proxy server analyseert de aanvragen van deze client, en kan vervolgens deze aanvragen al dan niet gewijzigd doorsturen naar de andere server. Eventueel kan de proxy server beslissen om zelf op deze aanvragen te antwoorden. Er bestaan verschillende toepassingen voor proxy servers die voor het grootste deel in 2 verschillende categorie¨en kunnen ingedeeld worden: het verbeteren van de performantie en het filteren van aanvragen van clients. Een klassieke toepassing is het gebruiken van een proxy server voor caching van aanvragen van clients. Wanneer een client een webpagina opvraagt die zich nog in de cache van de proxy server bevindt, dan kan die beslissen om de gecachte versie terug te sturen naar de client, in plaats van de aanvraag door te sturen naar de server die de pagina host. Hieruit volgend kunnen proxy servers ingedeeld worden in 2 categorie¨en: klassieke en
2.2 Proxy server
6
transparante proxy servers.[12] Wanneer een proxy server dient ter verbetering van de TCPperformantie (zie 2.5.8) spreekt men van een Performance Enhancing Proxy [10]. De bedoeling van dit eindwerk is om een transparante Performance Enhancing proxy server te ontwikkelen die aan DSL-bundeling doet.
2.2.1
Klassieke Proxy server
Een klassieke proxy server bevat meestal een client- en een server-zijde. De aanwezigheid van de proxy server in het netwerkpad tussen client en server is gekend door de client (maar meestal niet door de server). De stappen die een klassieke proxy server onderneemt ingeval een client met een server wil communiceren zijn vaak de volgende: Accepteer sessies van een client. Doe alsof je de gevraagde server bent voor de client. Ontvang de naam en het adres van de server waarmee een verbinding moet gevormd
worden. Start een sessie met de server waarmee een verbinding moet gevormd worden. Doe alsof
je de client bent. Stuur vragen, antwoorden en data tussen de client en server door. Analyseer de data en voer de functie uit waarvoor de proxy server ontworpen is (bijvoor-
beeld caching proxy server, anonymizing proxy server, web proxy, ...)
Het grootste nadeel van een klassieke proxy server is, dat elke client-applicatie moet weten dat er zich een proxy server in het netwerkpad bevindt, alsook de locatie (bijvoorbeeld IP adres, zie 2.5.5) van die proxy server. De applicatie moet immers het verkeer, dat hij door de proxy server behandeld wil zien, naar de proxy server sturen op een manier dat de proxy server kan interpreteren.
2.2.2
Transparante Proxy server
In een client-server verbinding ziet een transparante proxy server er als een pakketfilter uit voor de client, en als een klassieke proxy voor de server. Client-applicaties dienen niet van het bestaan van de proxy server af te weten, vandaar de naam transparant. Een transparante proxy server
2.2 Proxy server
7
kan elke taak uitvoeren die een klassieke proxy server kan doen. Andere mogelijke functies zijn geavanceerde routing, firewalling, pakketfiltering etc... Een nadeel verbonden aan transparante proxies is dat de client niet meer kan kiezen om de proxyserver niet te gebruiken, aangezien elk netwerkverkeer langs de proxy server gaat. Dit kan voor problemen zorgen wanneer de proxy niet compatibel is met een client-applicatie.
2.2.3
Performance Enhancing Proxies
Een Performance Enhancing Proxy (PEP) wordt vooral gebruikt daar waar de TCP-performantie (zie 2.5.8) door het type verbinding gedegradeerd is. Dit is onder andere van toepassing bij wireless LAN-/WAN- en satellietverbindingen, maar ook bij bundeling van meerdere netwerklijnen. PEPs kunnen opereren op de toepassings-, transport- of netwerklaag (zie figuur 2.3) en hebben steeds als bedoeling de performantie van TCP op te krikken. Vaak werken PEPs als transparante proxy en worden ze aan beide eindpunten van de client-server verbinding geplaatst. De werking van een PEP hangt sterk af van de omstandigheden waarin hij gebruikt wordt. Zo kan een PEP lokaal aan TCP retransmissie doen, TCP ACK manipulatie om TCP slowstart te versnellen, tunneling van dataverkeer, compressie van data, reordering van pakketten, QoS aanbieden via prioriteitsregels toe te passen op de data die verstuurd wordt, etc... Extra aandacht moet besteed worden aan security aangezien de end-to-end verbinding kan afgebroken worden door de PEP. Zo kan het gebruik van een PEP IPsec onwerkbaar maken. Packet injection kan de ACK-manipulatie van de PEP in de war sturen en er moet op gelet worden dat bij het tunnelen van netwerkverkeer de firewall niet gebypassed wordt. Toepassingslaag
HTTP/FTP/...
Transportlaag
TCP/UDP/...
Netwerklaag
IP/...
Datalinklaag
Ethernet/ATM/...
Fysieke laag
UTP/ADSL/...
(a)
(b)
Figuur 2.3: (a) Netwerk protocol stack (b) Mogelijke toepassingen
2.3 DSL bundeling
2.3
8
DSL bundeling
Bij het gebruiken van een enkele DSL-lijn met de bijhorende modem is men beperkt in bandbreedte tot de bandbreedte die de modem levert op deze DSL-lijn. Deze bandbreedte wordt bepaald door de provider, de kwaliteit van de lijn, de afstand tot de telefooncentrale en de theoretische beperkingen van de gebruikte technologie. Bij het bundelen van DSL-lijnen is het de bedoeling om netwerkverkeer te verdelen over meerdere DSL-lijnen, om zo de totaal bekomen bandbreedte te verhogen. Het introduceren van extra lijnen introduceert ook failover en de mogelijkheid om meerdere providers te gebruiken. Zo zal het uitvallen van ´e´en lijn of het uitvallen van alle lijnen van ´e´en bepaalde provider niet meer voor een totale uitval van de netwerkverbinding zorgen. Bij het bundelen van DSL-lijnen zijn er twee scenario’s die beschouwd dienen te worden:
1. Meerdere clients die gegevens uitwisselen met meerdere servers. 2. Een client die ´e´en verbinding maakt met een server.
2.3.1
Meerdere clients, meerdere servers
Figuur 2.4: Een mogelijke configuratie die gebruik maakt van connectie load balancing.
Dit is een situatie waar bijvoorbeeld verschillende PC’s in een bedrijf gelijktijdig verbindingen aangaan met externe servers, zoals bijvoorbeeld web browsing, e-mail, downloaden van bestanden, chatten, ... Hierbij kan de bonding beperkt worden tot het load balancen van de verschillende verbindingen over de verschillende DSL lijnen. De verbindingen kunnen geclassificeerd worden aan de hand van uiteenlopende karakteristieken. Men kan kiezen om bijvoorbeeld al het HTTP-verkeer over modem1 te laten gaan, al het mail-verkeer over modem 2, al het UDP-verkeer
2.3 DSL bundeling
9
over modem 3 en het resterende verkeer over modem 4. Men kan echter ook opteren om verbindingen afwisselend over verschillende modems te verdelen. Zo kan de eerste TCP-verbinding over modem 1 gaan, de tweede TCP-verbinding over modem 2, de derde TCP-verbinding weer over modem 1, etc... Aangezien het onmogelijk is om te voorspellen hoe zwaar een bepaalde verbinding gebruikt gaat worden, blijkt het een grote uitdaging om het verkeer zo gelijkmatig mogelijk over de verschillende modems te verdelen. Het komt dan ook vaak voor dat de totale bandbreedte niet effici¨ent verdeeld wordt over de verschillende DSL-lijnen. Profilering van het dataverkeer van het bedrijf kan helpen om een gefundeerde keuze te maken in het opstellen van de karakterisatieen toewijzingsregels. Bestaande oplossingen die dit type van load balancing implementeren zijn: Policy Routing en Equal Cost Multipath Routing (ECMP). Een bespreking, samen met performantietesten is te vinden in het eindwerk van Wilfried Heylen[15]. Enkele voordelen van beide oplossingen: Eenvoudig te implementeren. Vraagt een niet te krachtige router. Het netwerkverkeer wordt niet gewijzigd. Failover in beperkte mate mogelijk.
Enkele nadelen: Er wordt niet optimaal gebruik gemaakt van de beschikbare bandbreedte. Niet aangepast aan wisselende intensiteit van verschillende klassen trafiek. De snelheid van ´e´en verbinding is gelimiteerd door de snelheid van de lijn waarover de
verbinding gaat. Elke verbinding moet in een opzoektabel geplaatst worden. De entries in deze tabel mogen
er niet te snel uit verwijderd worden om te vermijden dat slapende verbindingen plots afgebroken worden.
2.3 DSL bundeling
10
Figuur 2.5: Deze configuratie maakt gebruik van pakket load balancing.
2.3.2
E´ en client, ´ e´ en server
Mogelijke situaties waarbij ´e´en client met ´e´en server over meerdere DSL-lijnen wil verbinden, zijn bijvoorbeeld het downloaden van een groot bestand van het internet of het remote backuppen van bedrijfskritieke data. Om dit te verwezenlijken dienen de pakketten van de client/serververbindingen individueel verdeeld te worden over de beschikbare DSL-lijnen. Aangezien een TCP- of UDP-verbinding normaal enkel over ´e´en specifieke lijn tegelijk gaat, dient er hier speciaal op gelet te worden dat de werking van TCP en UDP niet in de war gestuurd wordt. In het bijzonder moet de volgorde van de pakketten gegarandeerd blijven. Bestaande oplossingen die dit type van load balancing implementeren zijn: Bonding en True Link Equalizer (TEQL). Een bespreking, samen met performantietesten is te vinden in het eindwerk van Wilfried Heylen[15]. Enkele voordelen van beide oplossingen: Een connectie kan de bandbreedte van al de modems gebruiken. Optimaal gebruik van de bandbreedte van al de modems bij meerdere verbindingen. Mogelijkheid tot failover.
Enkele nadelen: Deze manier van load balancen vraagt een krachtige router Er is een groot risico dat op pakketten in verkeerde volgorde toekomen. Meestal moet zowel aan client- als aan server-zijde een eigen router ge¨ınstalleerd worden
die dit type van load balancen ondersteunt.
2.4 Click Modular Router
2.4 2.4.1
11
Click Modular Router Inleiding
De Click modular router[5] is een project dat zijn oorsprong vond bij onderzoekers van de Massachusetts Institute of Technology. Het is een nieuwe software-architectuur die ontworpen is voor het bouwen van flexibele en configureerbare routers. Een Click router bestaat uit elementen, dit zijn modules die netwerkpakketten verwerken. Individuele elementen implementeren simpele router-functies zoals pakket-classificatie, -queueing, -scheduling en -interactie met netwerkadapters. Bij een router configuratie bevinden de Click-elementen zich op de knopen van een gerichte graaf. De pakketten volgen een pad door die gerichte graaf. Click configuraties zijn modulair en makkelijk uit te breiden. Een Click IP router die aan de standaarden voldoet voor IPv4 routers [9] heeft zestien elementen in zijn forwarding-pad. Enkele van deze elementen zijn ook bruikbaar in Ethernet switches (zie 2.5.1) en IP tunneling configuraties. Voor het uitbreiding van de router voor ondersteuning van dropping policies, flow fairness of andere functies volstaat het om enkele elementen op de juiste plaats toe te voegen. Op conventionele PC hardware1 bereikt de Click IP router een maximale verliesvrije forwarding rate van 333.000 64-byte pakketten per seconden. Dit toont aan dat Click een modulaire en flexibele architectuur is met degelijke prestaties. Een complete lijst van de standaard-elementen is samen met hun beschrijving te vinden op de Click website[2]. In 3.3 worden de zelf ontwikkelde elementen besproken.
2.4.2 2.4.2.1
Architectuur Algemeen
Een Click element stelt een router processing-unit voor. Een element voert hoofdzakelijk eenvoudige bewerkingen uit zoals het decrementeren van de TTL van een pakket en niet complexe taken zoals IP routing. Een verbinding op de gerichte graaf die een click-configuratie voorstelt, betekent een mogelijk pad voor de transfer van een pakket. Elke actie die ondernomen wordt door Click gebeurt op een pakket. De gebruiker bepaalt wat de Click router moet doen door het kiezen van de nodige elementen. Binnen een werkende router is elk een element voorgesteld 1
Een intel PentiumIII-700 met 8 actieve DEC Tulip fast Ethernet kaarten.
2.4 Click Modular Router
12
door een C++ object dat private toestanden kan bevatten. Verbindingen zijn voorgesteld door pointers naar element-objecten. Het doorgeven van een pakket betekent eigenlijk het oproepen van een enkele virtuele functie call. De belangrijkste eigenschappen van een element zijn: Element-klasse. Elk element behoort tot ´e´en element-klasse. Dit bepaalt welke code
uitgevoerd dient te worden wanneer het element een pakket verwerkt, de initialisatie van de procedure van het element en de data layout. Poorten. Een element kan gelijk welke configuratie aan input- en uitputpoorten bezitten.
Elke poort wordt met juist ´e´en poort op een ander element verbonden. Verschillende poorten kunnen een verschillende betekenis hebben. Configuratie-string. De optionele configuratiestring kan parameters doorgeven aan een
element die gebruikt kunnen worden bij diens initialisatie. Methode interfaces. Elk element ondersteunt verschillende standaard methode interfaces,
zoals transfer van pakketten. Elementen kunnen echter ook extra methodes bezitten, bijvoorbeeld voor het tellen van het aantal pakketten dat door het element gaat.
2.4.2.2
Push en Pull verbindingen
Click ondersteunt 2 verschillende verbindingen tussen elementen: push en pull. Bij een pushverbinding stuurt het bron-element het pakket naar het doel-element. Het doel-element begint met het pakket te verwerken wanneer het binnenkomt. Op deze manier werken de meeste routers. Bij een pull-verbinding start het doel-element de transfer van het pakket. Het doel-element gaat eerst vragen aan het bron-element of er een element beschikbaar is. Het bron-element antwoordt met het sturen van ofwel een null om aan te duiden dat er geen pakket is, ofwel een stuurt het bron-element een beschikbaar element door. Een pakket wordt verwerkt bij het binnenkomen van het doel-element. Elke poort is ofwel push ofwel pull. Een push-poort kan enkel verbonden worden met een andere push-poort. Zo kan een pull-poort ook enkel verbonden worden met een andere pull-poort. Het type poort wordt bepaald bij de initialisatie. Bij elementen die agnostische poorten bezitten, zullen de agnostische poorten die verbonden zijn met een pull-poort als pull functioneren, en de agnostische poorten die met een push-poort verbonden zijn zullen als push functioneren.
2.4 Click Modular Router
13
Push wordt gebruikt wanneer ongevraagd pakketten binnenkomen in een element, bijvoorbeeld bij het binnenkomen van elementen uit een netwerkinterface. Pull wordt gebruikt wanneer Click de timing van het verwerken van pakketten moet bepalen. Zo kan Click bepalen om enkel een pakket te versturen wanneer een netwerkinterface er klaar voor is. Figuur 2.6[17] toont de werking van push en pull.
Figuur 2.6: Push en pull control flow. Het diagram toont die functies die opgeroepen worden wanneer een pakket zich door een simpele router verplaatst. De tijd loopt van boven naar beneden. Het centrale element is een Queue. Tijdens een push gaat de control flow voorwaarts door een element graaf, startend bij het ontvangend element. Bij een pull gaat de control flow achterwaards door de graaf, startend bij het sturend element. Het pakket p beweegt steeds voorwaarts door de graaf.
2.4.2.3
Opslag van pakketten
Click zorgt zelf niet voor de opslag of buffering van pakketten. Pakket-buffers, Queues genaamd, zijn Click elementen die de gebruiker zelf moet plaatsen binnen de routerconfiguratie. Dit geeft de vrijheid aan de gebruiker om zelf te bepalen waar er pakketten opgeslagen worden. Een Queue-element heeft een push-ingangspoort en een pull-uitgangspoort.
2.4.2.4
CPU Scheduling
Click maakt een task queue aan voor de CPU van de router. De router is een lus die elke task in de task queue ´e´en per ´e´en verwerkt. Een task is gewoon een element dat CPU-tijd vraagt. Elk element in Click is specifiek single-threaded. Elementen dienen dus niet thread-safe gemaakt te worden. De router zal een pakket laten verwerken door elk element op zijn pad, totdat het gedropt wordt of in een Queue geplaatst wordt. Het strategisch plaatsen van Queues heeft dus een invloed op de CPU scheduling.
2.4 Click Modular Router
2.4.2.5
14
Taal
De taal om click-configuraties te schrijven is vrij eenvoudig. De taal bestaat uit twee delen: declaraties die elementen aanmaken en connecties die vertellen hoe de elementen verbonden dienen te worden. De taal is makkelijk te leren aan de hand van voorbeelden. Een voorbeeld is te vinden in figuur 2.7. FromDevice(eth0) -> Print(ok) -> Queue -> ToDevice(eth1);
Figuur 2.7: Dit voorbeeld neemt pakketten aan op device eth0, print de inhoud van de binnenkomende pakketten af en steekt ze vervolgens in een Queue. ToDevice haalt de pakketten uit de Queue en stuurt ze ongewijzigd door via de interface eth1.
2.4.2.6
Installatie
Er bestaan twee drivers om de Click router op Linux te draaien: een Linux-kernel-driver en een user-level driver die communiceert met het netwerk via Berkeley pakket filters of een gelijkaardig socket mechanisme. De user-level driver is handig voor profilering en debuggen. De kernel-driver is echter een stuk performanter en goed voor productie-omgevingen. Installatie van Click als kernel-driver vereist het toepassen van een meegeleverde patch voor de Linux kernel. Het is belangrijk te controleren of je kernel door Click ondersteund wordt. Een router ontstaat door het inladen van een configuratiebestand in de kernel-driver. De kerneldriver verwerkt dit configuratiebestand en laadt de benodigde elementen gefaseerd in. Op deze manier wordt een vorige configuratie onbruikbaar gemaakt. Indien gewenst kan een configuratie ook ge-hotswapped worden. Indien de nieuwe configuratie fouten bevat, blijft de oude configuratie in het kernel-driver. Bij een succesvolle initialisatie worden al de pakketten die zich in queues voor de oude configuratie bevinden automatisch doorgestuurd naar de nieuwe configuratie. Op deze manier gaan er zo weinig mogelijk pakketten verloren. Het is mogelijk om via handlers parameters van individuele elementen aan te passen terwijl de configuratie zich in de kernel-driver bevindt.
2.4 Click Modular Router
2.4.2.7
15
Implementatie van elementen
Een Click element klasse is een subklasse van de C++ klasse Element. Deze klasse bevat 20 virtuele methodes. Vaak is het voldoende om enkel een zestal methodes te implementeren. Tijdens de werking van de router worden enkel de methoden push, pull en run scheduled (gebruikt door de task scheduler) uitgevoerd. De andere methoden dienen voor identificatie, initialisatie, statistieken en push en pull specificatie. De implementatie voor het Null-element wordt weergegeven in figuur 2.8. class NullElement: public Element { public: NullElement()
{ add_input(); add_output(); }
const char *class_name() const
{ return "Null"; }
NullElement *clone() const
{ return new NullElement; }
const char *processing() const
{ return AGNOSTIC; }
void push(int port, Packet *p)
{ output(0).push(p); }
Packet *pull(int port)
{ return input(0).pull(); }
};
Figuur 2.8: De complete implementatie van een element dat niets doet. Het Null-element stuurt de pakketten die het via zijn enige input-poort ontvangt ongewijzigd door naar zijn output-poort.
2.4.2.8
Performantie
We karakteriseren de performantie door testen te doen met pakketten die een pakketgrootte van 64 bytes hebben. Pakketten van deze minimumgrootte zijn het meest belastend voor een router. De belasting van de CPU en andere bottleneck componenten is vooral afhankelijk van het aantal pakketten en minder van de grootte van de pakketten. Figuur 2.9 vergelijkt de performantie van Click met die van Linux met en zonder polling drivers. De configuratie is een implementatie van een IP router met 161 elementen en 8 interfaces. Zonder polling drivers is Linux gelimiteerd tot 84.000 pakketten/s, met polling drivers is de performantie 284.000 pakketten/s. Click heeft een performantie van 333.000 pakketten/s met polling drivers. Gewone drivers werken via interrupts. Wanneer een pakket ontvangen wordt, genereert de netwerkkaart een interrupt die de CPU onderbreekt. De CPU verwerkt de interrupt en vervolgens
2.5 Protocollen
16
Figuur 2.9: Forward rate in functie van de input rate voor een Click en Linux IP router bij pakketten van 64 bytes.
het pakket dat op de netwerkkaart toegekomen is. Deze manier van werken is slecht voor de performantie van een router waar veel verkeer gegenereerd wordt. Uiteindelijk spendeert de CPU te veel tijd aan het verwerken van de interrupts en te weinig tijd aan het verwerken van de pakketten. Bij polling drivers gaat de CPU zelf controleren of een netwerkkaart een pakket binnengekregen heeft. Het voordeel is dat een CPU nieuwe pakketten kan aanvaarden met idle cycles en geen tijd meer verliest met het verwerken van interrupts.
2.5
Protocollen
Een protocol is een conventie of een standaard die definieert hoe computereindpunten netwerkverbindingen met elkaar aangaan, en hoe ze data over dat netwerk kunnen uitwisselen. De regels, syntax en semantiek zijn te vinden in de protocol-definitie. Hieronder volgt een beknopte bespreking van protocollen die een zeker belang genieten binnen deze scriptie.
2.5.1
Ethernet
Een protocol is een conventie of standaard die het mogelijk maakt om tussen computer eindpunten verbindingen te maken en gegevens uit te wisselen. De manier waarop dit gebeurt staat beschreven in regels in de protocol-definitie. Hieronder volgt een beschrijving van protocollen die interessant zijn voor dit eindwerk.
2.5 Protocollen
17
Figuur 2.10: Samenstelling van een ethernet datagram. De cijfers bovenaan geven het aantal bytes weer dat een bepaald veld in beslag neemt.
Ethernet is een connectieloos protocol dat zich bevindt op de Datalinklaag in de netwerkstack (zie figuur 2.3). Dit betekent dat ethernet-pakketten direct op de netwerkhardware wordt verstuurd. Ethernet werd ontworpen in de tijdperken van netwerken die over gedeelde coaxiale kabels liepen. Het ethernet protocol heeft dan ook veel gelijkenissen met een broadcast protocol. Bij ethernet spreken we van datagrammen met een maximale payload of MTU van 1500 bytes die over een netwerkmedium verstuurd worden zoals UTP, Wifi, ADSL, ... Adressering op ethernet-niveau gebeurt aan de hand van een 48-bits MAC-adres. Elke netwerkkaart heeft een uniek ingebakken MAC-adres. Dit adres wordt gebruikt om lokaal datagrammen te routeren binnen hetzelfde subnetwerk. Ethernet heeft de mogelijkheid om collision van datagrammen te detecteren en indien nodig op te lossen aan de hand van een CSMA/CD algoritme.[26] Figuur 2.10 stelt de samenstelling van een ethernet datagram voor. Aan het begin van een ethernet datagram bevindt zich een Preamble van 7 bytes die dient ter synchronisering van de klok van de zender en ontvanger. Hierna volgt een Start Of Frame (SOF)-byte die het begin van een datagram aanduidt. Hierna komen de Destination- en Source- adressen. Deze bevatten het MAC-adres van de ontvanger en van de verzender van het datagram. Indien het ethernet-pakket in een VLAN (zie 2.5.2) gebruikt wordt, volgen nu 4 bytes met het ID van de VLAN. De twee volgende bytes duiden het type van de data aan. Deze data bevindt zich op het niveau van de netwerklaag(zie figuur 2.3). De data mag minimum 46 en maximum 1500 bytes lang zijn. Na de data volgt de Frame Check Sequence (FCS), een 32-bits CRC-code die berekend wordt op basis van het destination- en source-adres, het type en de data. Aan de hand van die FCS kan de ontvanger controleren of het pakket bij verzenden niet beschadigd is geraakt. De preamble, SOF en FCS behoren tot het CSMA/CD algoritme van ethernet. Per datagram moet men dus rekening houden met overhead gegenereerd door de ethernet-header. In totaal worden er per datagram, zonder VLAN, 26 bytes extra verstuurd (7 bytes preamble +
2.5 Protocollen
18
1 byte SOF + 12 bytes adressering + 2 bytes Type + 4 bytes FCS = 26 bytes). Met VLAN is dit 30 bytes. Tabel 2.2 geeft een overzicht van de minima en maxima aan overhead die het Ethernetniveau introduceert. We merken direct op dat het zinvol is grote pakketten te gebruiken om de overhead te beperken. De invloed van het al dan niet gebruiken van VLAN is beperkt voor de overhead. Tabel 2.2: Overhead ge¨ıntroduceerd door het Ethernet protocol
2.5.2
Hoeveelheid data
Geen VLAN
Wel VLAN
46 bytes data
26/72 = 36,1%
30/76 = 39,5%
1500 bytes data
26/1526 = 1,7%
30/1530 = 2%
VLAN
Virtual Local Area Network (VLAN) of het protocol 802.1Q werkt op de Datalinklaag (zie figuur 2.3) en geeft de mogelijkheid om verschillende onafhankelijke logische netwerken te cre¨eren binnen ´e´en fysisch netwerk. Een VLAN kan ver uitstrekken en verschillende fysieke netwerken bestrijken. Elk logisch netwerk bevat een 12-bit identifier of tag. Al de datagrammen die eenzelfde tag bevatten, behoren tot eenzelfde netwerk. Een tagged datagram is een datagram dat binnen zijn ethernet header als type protocol 0x8100 heeft. Het type wordt gevolgd door 3 prioriteitsbits, een Canonical format indicator bit en het 12-bit VLAN ID. Deze bits worden gevolgd door de 2 bytes die het type van het originele datagram bevatten. Een untagged datagram is een ethernet datagram zonder VLAN tag.[7]
2.5.3
PPP
Het Point-to-Point Protocol bevindt zich op de Datalinklaag (zie figuur 2.3) en wordt voornamelijk gebruikt om een directe verbinding te maken tussen twee nodes. Het PPP protocol wordt op vele interfaces gebruikt, waarvan waarschijnlijk de meest gekende Ethernet en ADSL zijn. Vaak wordt PPP gebruikt in combinatie met het Password authentication protocol om authenticatie aan de hand van een username en paswoord mogelijk te maken. PPP introduceert een header van 2 bytes. Wanneer de LCP optie “Protocol Field Compression” gebruikt wordt, kan de header tot 1 byte gereduceerd worden. Wanneer gebruik gemaakt wordt van PPPoE, moet men rekening houden met een extra header van 6 bytes. [27]
2.5 Protocollen
2.5.4
19
ATM
Figuur 2.11: Samenstelling van een ATM cel. De cijfers bovenaan geven het aantal bits weer dat een bepaald veld in beslag neemt.
Het ATM protocol bevindt zich op de Datalinklaag (zie figuur 2.3) en wordt vaak gebruikt bij DSL. ATM is een packet-switching protocol dat cellen gebruikt van een vaste lengte van 53 bytes, waarvan de eerste 5 bytes als header dienen. De payload kan bestaan uit verschillende soorten data en kan zelf protocolheaders bevatten. De samenstelling van een UNI ATM cel is weergegeven in figuur 2.11. De cellen zijn bewust klein om een kleinere delay en verwerkingstijd te verwerkrijgen. Een ATM-verbinding wordt ge¨ıdentificeerd door zijn Virtual Channel Identifier(VPI) en zijn Virtual Path Identifier (VPI).[13] Elke ATM-cel is exact 53 bytes lang, waarvan 5 bytes gebruikt worden als header. Wanneer een cel niet helemaal gevuld is, wordt hij verder aangevuld met padding bytes. [11]
2.5.5
IP
Figuur 2.12: Samenstelling van een IP pakket. De cijfers bovenaan geven het aantal bits weer dat een bepaald veld in beslag neemt.
Het Internet Protocol (IP) is een connectieloos protocol dat zich bevindt op de netwerklaag
2.5 Protocollen
20
(zie figuur 2.3). Het IP wordt vooral in twee versies gebruikt: IPv4 en IPv6. Wij gaan ons beperken tot de bespreking van IPv4. Bij IPv4 krijgt elke netwerkkaart een adres van 32 bits toegewezen. Dit adres wordt gebruikt bij de routering van de pakketten. Aan de hand van een IP adres en een bijhorende 32-bits subnet-mask kan bepaald worden welke IP-adressen behoren tot eenzelfde subnetwerk, waarmee direct gecommuniceerd kan worden. De identificatie tussen een MAC-adres op de transportlaag en een IP-adres op de netwerklaag gebeurt aan de hand van het ARP-protocol. Wanneer een pakket gezonden moet worden waarbij enkel het IP-adres gekend is, wordt er met behulp van een ARP pakket gevraagd welk MAC-adres overeenkomt met dat IP-adres. De netwerkkaart die het gevraagde IP-adres bezit zal antwoorden met de vermelding van zijn MAC-adres. Het ARP-protocol werkt binnen een subnetwerk.[24] Figuur 2.12 toont de header van een IP-pakket. De eerste 4 bits stellen de versie van het gebruikte protocol voor. De volgende 4 bits geven de lengte van de IP-header in woorden van 32 bits. De minimumwaarde is 5. De volgende 8 bits geven de type of service aan, bits die vooral gebruikt worden bij Quality of Service (QoS). De volgende 16 bits worden gebruikt voor het aanduiden van de totale lengte van het datagram. Hierna komen 16 bits ter identificatie van het pakket, 3 IP flags, een 15-bits Fragment Offset en de 1 byte Time To Live (TTL) van het pakket. De TTL wordt steeds met 1 verminderd, elke keer dat het pakket langs een router of gateway langskomt. Wanneer de TTL op 0 komt te staan, wordt het pakket verwijderd en wordt er een ICMP-errorbericht (zie 2.5.6) teruggestuurd. Na de TTL zijn er 8 bits die het protocol aanduiden, gevolgd door een 16-bits checksum van de header. Hierna komen het Source- en het Destination-adres, elk 32 bits land. Het IP biedt de mogelijkheid om opties zoals een timestamp op te slaan in de IP header. Een IP header introduceert dus minimaal 20 bytes overhead. Tabel 2.3 geeft een overzicht van de overhead die ge¨ıntroduceerd wordt door de IP-header, bij pakketten van 46 en 1500 bytes, de minimum- en maximum pakketgrootte bij IP over Ethernet. In de berekening wordt er geen rekening gehouden met mogelijke opties in de IP-headers. De grenzen dienen dus gezien te worden als ondergrenzen voor de overhead.
Tabel 2.3: Overhead ge¨ıntroduceerd door de IP-header
Pakketgrootte
Overhead
46 bytes
20/46 = 43,5%
1500 bytes
20/1500 = 1,3%
2.5 Protocollen
2.5.6
21
ICMP
Het Internet Control Message Protocol bevindt zich op de netwerklaag (zie figuur 2.3) en wordt vooral gebruikt voor foutrapportering. Enkele gekende ICMP-berichten zijn: echo Request, echo Reply, Destination Unreachable, Redirect Message... [23]
2.5.7
UDP
Figuur 2.13: Samenstelling van een UDP pakket
Het User Datagram Protocol is een stateless protocol dat zich op de Transportlaag bevindt (zie figuur 2.3). Stateless betekent dat er geen gegarandeerde aflevering is van de data, dat er geen congestion controle is en dat de zender geen feedback krijgt van de ontvanger over de verstuurde toegekomen gegevens. In principe is de volgorde waarin de UDP pakketten toekomen ook onbelangrijk, alhoewel de toepassingen die de data uit de UDP-pakketten halen wel gevoelig kunnen zijn voor te veel out-of-order pakketten. Een UDP-stroom van pakketten wordt ook niet opgestart of be¨eindigd via een handshake. Een UDP-stroom wordt ge¨ıdentificeerd aan de hand van de koppels (source-IP adres, source-poort) en (destination-IP adres, destination-poort). Deze koppels worden gebruikt om de data naar de juist toepassing in de toepassingslaag te geven. Een overzicht van een UDP-header wordt gegeven in figuur 2.13[22]. Een UDP-pakket heeft steeds een header van 8 bytes. Tabel 2.4 illustreert de overhead die door de header van het UDP-protocol ge¨ıntroduceerd wordt. De pakketgroottes zijn ge¨ınspireerd op de minimum en maximum pakketgrootte wanneer UDP in combinatie met IP en Ethernet gebruikt wordt.
2.5 Protocollen
22
Tabel 2.4: Overhead ge¨ıntroduceerd door de UDP-header
Pakketgrootte
Overhead
26 bytes
8/26 = 30,8%
1480 bytes
8/1480 = 0,5%
Figuur 2.14: Samenstelling van een TCP pakket. De cijfers bovenaan geven het aantal bits weer dat een bepaald veld in beslag neemt.
2.5.8 2.5.8.1
TCP Algemeen
Het Transmission Control Protocol bevindt zich op de Transportlaag (zie figuur 2.3). Het is een connectie-geori¨enteerd protocol dat garandeert dat de verstuurde gegevens ongewijzigd toekomen, in dezelfde volgorde als dewelke waarin ze verstuurd werden. Figuur 2.14 geeft de samenstelling van een TCP pakket weer. TCP werkt aan de hand van verbindingen tussen een client en server. Een verbinding wordt ge¨ıdentificeerd aan de hand van de twee koppels (sourceIP address, source-port) en (destination-IP address, destination-port). Elke verbinding wordt gestart met een three-way handshake en verbroken met een four-way handshake. Gegevens die via binnenkomen bij de client worden doorgegeven naar de toepassingslaag. Aan de hand van de 2 koppels waarmee een TCP verbinding ge¨ıdentificeerd wordt, worden de verstuurde gegevens aan de juiste toepassing doorgegeven. [25]
2.5.8.2
Congestion en flow control
TCP biedt een mechanisme aan de ontvanger om de hoeveelheid data die de zender verstuurt te controleren aan de hand van een receive window. Zoals te zien in figuur 2.14 wordt die window in
2.5 Protocollen
23
elk pakket doorgegeven. Deze window geeft het aantal bytes die de ontvanger nog kan ontvangen voordat zijn ontvangstbuffer overloopt. Wanneer de zender merkt dat de ontvangstbuffer kan overlopen, zal hij het verzenden onderbreken. Vandaar dat het belangrijk is om een TCP windowsize te kiezen die groot genoeg is zodat de zender niet ophoudt met verzenden. De berekening van de TCP window size gebeurt via formule 2.1.
T CP windowsize = RT T ∗ bandbreedte
(2.1)
In Linux zit er vanaf kernel 2.6.17 TCP autotuning ingebakken. Linux zal de window size automatisch aanpassen naar goede waarden. TCP autotuning wordt ook door de netwerkstack van Windows Vista gebruikt. TCP doet aan end-end congestion control. Er is dus geen expliciete feedback van het netwerk. Congestion kijkt naar het aantal verloren TCP pakketten en de delay van de TCP pakketten. Hiervoor maakt TCP gebruik van een send window die gelijk is aan minimum(receive window, congestion window) - het aantal bytes die reeds verzonden zijn maar nog niet acknowledged zijn. Een pakket mag verzonden worden wanneer deze send window groter is dan 0. De congestion detectie gebeurt door de verzender. Congestion control bestaat uit slow start, congestion avoidance, fast retransmit en fast recovery. Slow start en congestion avoidance werken hand in hand. Een TCP verbinding begint met slow start, waarbij het aantal na elkaar verzonden TCP pakketten elke RTT verdubbelt. Eens dit aantal groter is dan de slow start treshold, wordt congestion avoidance gebruikt. Nu wordt het aantal pakketten dat na elkaar verstuurd wordt vermeerderd met 1 in plaats van verdubbeld. Het aantal te verzenden pakketten wordt aangepast door de grootte van de congestion window aan te passen. Bij het ontvangen van 3 duplicate ACK-berichten gaat TCP ervan uit dat er een pakket verloren is gegaan. Nu treedt fast retransmit in. De congestion window wordt gehalveerd en vermeerderd met 3*MSG. De slow start treshold wordt gehalveerd. Het pakket dat niet is toegekomen wordt nu verstuurd. De slow start treshold wordt gelijk aan de vorige congestion window / 2. Vermeerder de congestion window met 1 voor elk ontvangen duplicate ACK. Eens een ACK ontvangen wordt voor data waarvoor nog geen ACK ontvangen was, zet TCP de congestion window op de waarde van de slow start treshold. Bij het ontvangen Bij een time-out wordt de congestion window ingesteld op 1MSG en wordt de slow start fase weer begonnen. Ook nu wordt
2.5 Protocollen
24
de slow start treshold gelijk gezet aan de vorige congestion window / 2. Voor optimaal gebruik van een TCP verbinding is het dan ook erg belangrijk om het aantal verloren en out-of-order pakketten te beperken.[8]
2.5.8.3
Performantie
De gemiddelde doorvoersnelheid van een TCP verbinding kan wiskundig gemodelleerd worden aan de hand van de formule 2.2[18].
gemiddelde doorvoersnelheid =
1, 22 ∗ M SS √ RT T ∗ L
(2.2)
RTT is de Round Trip Time, L de verliessnelheid en MSS de Maximum Segment Size (=MTU IP header - TCP header). Wanneer we naar de overhead kijken binnen een TCP-pakket, dienen we te kijken naar de header-grootte. Die bedraagt, als er geen TCP options worden gebruikt, 20 bytes. Tabel 2.5 illustreert de overhead die door de header van het TCP-protocol ge¨ıntroduceerd wordt. De pakketgroottes zijn ge¨ınspireerd op de minimum en maximum pakketgrootte wanneer TCP in combinatie met IP en Ethernet gebruikt wordt. Aangezien geen TCP- of IP-options worden beschouwd, dienen de waarden als minima ge¨ınterpreteerd te worden voor de minimale en maximale pakketgrootte.
Tabel 2.5: Overhead ge¨ıntroduceerd door de TCP-header
Pakketgrootte
Overhead
26 bytes
20/26 = 76,9%
1480 bytes
20/1480 = 1,4%
ONTWERP EN ONTWIKKELING VAN EEN TRANSPARANTE DSL BONDING PROXY
25
Hoofdstuk 3
Ontwerp en ontwikkeling van een transparante DSL bonding proxy 3.1
Doel van eigen ontwerp
Zoals aangetoond in het eindwerk van Wilfried Heylen[15] hebben bestaande oplossingen voor DSL-bundeling meerdere tekortkomingen, waaronder het niet kunnen benutten van de totale bandbreedte door ´e´en TCP-verbinding, en het moeilijk meeschalen bij het gebruik van meerdere DSL-modems. In dit hoofdstuk wordt er getracht een oplossing te bieden voor deze problemen door een eigen DSL-bonding proxy server te ontwikkelen via de Click modular router architectuur (zie 2.4). Om ervaring op te doen in Linux, de netwerkmogelijkheden van Linux en bestaande oplossingen voor het bundelen van meerdere DSL-lijnen, werden in een eerste fase de types DSL bonding die besproken worden in het eindwerk van Wilfried Heylen, geconfigureerd en geanalyseerd. Voor de configuratie en analyse van deze types DSL bonding dient best het eindwerk van Wilfried Heylen geconsulteerd te worden[15]. In een tweede fase werd gestart met het ontwerp en ontwikkeling van een eigen DSL bonding proxy. Zoals reeds uitgelegd in 2.3 bestaan er twee situaties waarbij DSL-bonding gebruikt kan worden: een situatie waarbij men de verbindingen gaat load-balancen over de verschillende lijnen (zie 2.3.1), en een situatie waarbij men de netwerkpakketten zelf gaat load-balancen (zie 2.3.2). In deze laatste situatie kan men een TCP-verbinding optimaal laten gebruik maken van al de beschikbare DSL-lijnen. Deze situatie is ook bruikbaar in een situatie met veel client-server
3.1 Doel van eigen ontwerp
26
verbindingen. Bij het ontwikkelen van de eigen DSL bonding proxy werd dan ook geopteerd voor de pakket-load-balancing. Enkele zaken waarop gelet dient te worden zijn: Het load-balancen van de individuele pakketten heeft als nadeel dat ze, wegens kleine
snelheids- en delayverschillen tussen de verschillende DSL-lijnen, niet steeds in dezelfde volgorde toekomen als dewelke waarin ze verzonden zijn. Het is dan ook belangrijk om de pakketten bij aankomst te herordenen. Indien er bij de ontvanger een pakket in de verkeerde volgorde toekomt, zal de performantie van TCP eronder lijden (zie 2.5.8.2). Het herordenen van de pakketten mag niet te veel rekenkracht vereisen. De DSL-bundeling dient transparant te gebeuren. De applicaties dienen niet te weten dat
er zich een DSL-bundeling proxy op het netwerkpad bevindt. Een verschil in snelheid en delay tussen de verschillende DSL modems dient opgevangen
te kunnen worden. Bij het load balancen van de pakketten is het vereisen het opstellen van een tunnel tussen
twee transparante proxies. Er dient gekeken te worden waar deze proxy servers zich kunnen bevinden. De proxy server dient goed op te kunnen schalen met het aantal gebruikte modems. Er dient zo weinig mogelijk extra delay ge¨ıntroduceert te worden door de proxy server. Indien mogelijk dient er gezorgd te worden voor failover.
In totaal zijn er drie verschillende opstellingen ontwikkeld. E´en opstelling maakt gebruik van Network Address Translation (NAT) (zie 3.2.1), de twee andere maken gebruik van IPinIP tunnels. Deze twee versies onderscheiden zich door de gegevens die ze gebruiken voor het herordenen van de pakketten: de ene versie gebruikt timestamps (zie 3.2.2), de andere sequentienummers (zie 3.2.3). Er zijn verschillende Click elementen ontwikkeld om deze opstellingen mogelijk te maken. Deze elementen worden besproken in 3.3. Het belangrijkste element daaruit is SequenceSortedSched (zie 3.3.5), die pakketten uit verschillende netwerklijnen sorteert op basis van hun sequentienummer. Er zijn meerdere versies daarvan ge¨ımplementeerd, elk met een verschillende aanpak. Drie van deze versies worden besproken.
3.2 Ontwikkeling van een proxy server
3.2
27
Ontwikkeling van een proxy server
In totaal zijn er drie verschillende transparante DSL bonding proxies ontwikkeld, waarvan de derde de best werkende is. De drie versies hebben als gemeenschappelijke kenmerken dat ze elk de Click modular router gebruiken, en dat er voor de werking in totaal twee Click routers nodig zijn, ´e´en aan de client-zijde en ´e´en aan de server-zijde van een client-server verbinding. Wanneer zowel de client als de server een publiek IP-adres bezitten, is het bij de tweede en de derde versie van de proxy zelf mogelijk om de Click-router die zich aan de serverkant bevindt, bij de ISP te plaatsen. Een ISP kan zo een eigen systeem gebruiken om de bandbreedte tussen een klant en het internet te verhogen. Op deze manier kan de klant een verhoogde bandbreedte genieten naar het internet, zonder dat de servers waarmee gecommuniceerd wordt enige aanpassing moeten doorvoeren. In het geval dat de ISP geen ondersteuning voor de transparante DSL bonding proxy biedt, dient er ´e´en van de Click routers geplaatst te worden bij de server waarmee gecommuniceerd wordt. Figuur 3.1 (a), (b) en (c) geven de verschillende mogelijke plaatsingen van de Click-routers.Zoals (b) aantoont, is het mogelijk om meerdere ISPs te gebruiken wanneer de Click-router bij de server geplaatst wordt.
3.2.1 3.2.1.1
Eerste versie: NAT Situering
In eerste instantie werd een DSL bonding router ontwikkeld die enkel bestaande Click elementen gebruikt[2]. Dit gaf de mogelijkheid om ervaring op te doen met de Click Modular router Architectuur. Bij deze router ligt de nadruk op het verdelen van de netwerkpakketten over de verschillende DSL lijnen, en ze vervolgens weer samen te brengen tot ´e´en stroom van netwerkpakketten. Er wordt nog niet aan herordening van de pakketten gedaan. De bruikbaarheid van de router is dan ook vrij beperkt, aangezien de pakketten in een vrij willekeurige volgorde bij de ontvanger toekomen. De opstelling vereist een Click-router aan zowel de client- als de serverkant van de verbinding.
3.2 Ontwikkeling van een proxy server
28
(a) De Click-router wordt bij de Server geplaatst.
(b) De Click-router wordt bij de Server geplaatst. De client is verbonden met 2 ISPs.
(c) De Click-router wordt bij de ISP geplaatst. Figuur 3.1: Verschillende mogelijkheden om de Click-routers te plaatsen.
3.2.1.2
Werking
De router maakt gebruik van Network Address Translation (NAT) om de netwerkpakketten over de verschillende modems te verdelen. NAT wordt in Click verwezenlijkt door het element IPRewriter. Zoals te zien is in figuur 3.2, vervangt de Click-router die zich aan de kant van de modems bevindt het source-adres van elk netwerkpakket dat naar buiten gestuurd wordt door het extern IP-adres van de modem waarlangs het pakket gerouteerd zal worden. Het destination-adres blijft achter ongewijzigd. De Click-router die zich aan de andere kant van de
3.2 Ontwikkeling van een proxy server
29
Figuur 3.2: Deze figuur toont de werking van de eerste versie DSL bonding proxy. Bovenaan wordt de evolutie getoond van de source- en destination- IP-adressen, voor pakketten die van client naar server gaan. Onderaan wordt het verloop getoond van een pakket dat de omgekeerde weg volgt.
netwerkverbinding bevindt zal het source-adres weer vervangen door het oorspronkelijke sourceadres, en doorsturen naar de volgende hop binnen het netwerkpad. Bij een netwerkpakket dat het netwerkpad in omgekeerde richting doorloopt, wordt het destination-adres vervangen door het extern adres van een modem. De Click-router die zich achter de modem bevindt zal het destination-adres weer vervangen door het originele destination adres.
3.2.1.3
Bespreking voor- en nadelen
Deze DSL bonding proxy bleek al snel niet te voldoen aan de verschillende eisen die we in het begin van dit hoofdstuk gesteld hebben(zie 3.1), waardoor de ontwikkeling vrij snel werd gestaakt: Er wordt niet aan reordering gedaan, waardoor er nooit een deftige TCP-bandbreedte
gehaald kan worden. Alhoewel UDP niet vereist dat de pakketten in juiste volgorde toekomen, zullen de applicaties die de gegevens uit de UDP pakketten nodig hebben hoogstwaarschijnlijk hinder ondervinden van de willekeurige volgorde waarin de gegevens binnenkomen. De proxy is niet transparant genoeg. Er kan geen verbinding aan de server-kant opge-
start worden. Elke verbinding dient eerst opgestart te worden aan de client-zijde om de IPRewriter elementen van de nodige gegevens te voorzien. Het gebruik van NAT aan beide kanten heeft als gevolg dat de routers de oorspronkelijke
IP-gegevens niet uit de netwerkpakketten kunnen halen. Er kunnen dus enkel verbindingen gemaakt worden tussen twee vaste eindpunten.
3.2 Ontwikkeling van een proxy server
30
De oorspronkelijke pakketten worden veranderd. Dit bemoeilijkt zowel de traceability van
de netwerkpakketten, als het debuggen van het netwerkverkeer. Het veranderen van de oorspronkelijke pakketten gaat dan ook in tegen de filosofie van een transparante proxy.
3.2.2 3.2.2.1
Tweede versie: timestamp Situering
De tweede versie van de DSL bonding proxy tracht een antwoord te bieden op de tekortkomingen van de eerste versie. Er is gekozen voor een geheel verschillende aanpak. Een van de belangrijkste ontwerpkeuzes, is het volledig ongewijzigd laten van de oorspronkelijke IP-pakketten die van client naar server gaan, en omgekeerd. Om dit te verwezenlijken werd inspiratie gehaald bij netwerktunnels zoals het door Cisco ontwikkelde Generic Routing Encapsulation (GRE)[14]. Elk netwerkpakket krijgt een extra IP header vooraan. Deze extra IP-header krijgt 4 als waarde in het protocolveld, wat betekent dat het IP pakket aan IP-in-IP encapsulatie doet[21]. Deze vorm van encapsulatie zorgt voor een scheiding van de routeringsdata tussen de client en server enerzijds, en de Click-routers anderzijds. Wanneer de DSL bonding proxy in opstelling (a) van figuur 3.1 gebruikt wordt, geeft dit zelfs de mogelijkheid om de client en server binnen eenzelfde virtueel LAN te brengen, over het internet heen. De client en server kunnen een IP-adres binnen hetzelfde subnetwerk bezitten. Deze IP-adressen moeten geen publieke adressen zijn. De sourceen destination IP adressen uit de buitenste IP header, dienen voor de routering tussen de twee Click routers.
Figuur 3.3: Samenstelling van een IP pakket bij het gebruik van de tweede versie van de bonding DSL router.
3.2 Ontwikkeling van een proxy server
3.2.2.2
31
Werking
De IP in IP encapsulatie heeft reeds vele problemen uit de eerste versie van de proxy opgelost. Zo worden de originele IP pakketten niet aangepast, kan het systeem door vele clients en servers tegelijkertijd gebruikt worden, en kan een server ook een verbinding opstarten met een client. De volgende stap is het herordenen van de binnenkomende netwerkpakketten. Om dit te verwezenlijken werd opnieuw gekeken naar de reeds bestaande Click elementen[2]. De Click modular router biedt zelf de elementen SetTimestamp, StoreTimestamp en TimeSortedSched. De functie van deze elementen is respectievelijk het toekennen van een timestamp in de annotation space van een pakket, het opslaan van deze timestamp in een pakket, en het sorteren van binnenkomende pakketten volgens timestamp-annotatie. Ze kunnen dus gebruikt worden om een timestamp in een pakket op te slaan, en die timestamp te gebruiken voor het ordenen van pakketten. Aangezien er wel Click elementen bestaan voor het opslaan van een timestamp, maar niet voor het uitlezen/verwijderen van een timestamp uit de data van een pakket, werd het element ExtractTimestamp ontwikkeld (zie 3.3.3). De samenstelling van een geencapsuleerd IP pakket samen met zijn timestamp, wordt weergegeven in figuur 3.3. Uit de figuur lezen we ook direct de maximumgrootte van de IP payload, namelijk 1452 bytes. De maximale IP payload bij gebruik van ethernet is 1500 bytes. De twee IP headers nemen elk minimaal 20 bytes in beslag, de timestamp neemt 8 bytes in beslag. We bekomen dus: 1500 bytes - 20 bytes - 20 bytes - 8 bytes = 1452 bytes. Figuur 3.4 geeft de packetflow weer bij gebruik van de tweede versie van de transparante DSL bonding proxy. IP pakketten die aan de LAN-kant van een Click-router binnenkomen, krijgen een timestamp opgeslagen in hun pakketdata. Vervolgens worden de pakketten in meerdere flows opgesplitst. Het aantal flows stemt overeen met het aantal modems dat bij de DSL bundeling gebruikt wordt. Bij elk van deze flows wordt een extra IP header toegevoegd. Deze extra header wordt nu pas toegevoegd, aangezien ze per flow verschillend is. Aan de client-zijde krijgen de pakketten een verschillend source-IP per flow. Aan de server-zijde krijgen ze een verschillend destination-IP. Figuur 3.5 geeft de evolutie van de source- en destination- adressen binnen de externe IP header. In de figuur maken de modems gebruik van NAT. De modems dienen zo geconfigureerd worden, dat ze al het IPinIP-verkeer naar de Click-router doorsturen. De Clickrouter aan client-zijde heeft evenveel externe IPs als het aantal gebruikte modems. De Clickrouter aan client-zijde stuurt vervolgens de pakketten door naar de modems. De Click-router aan server-zijde stuurt de pakketten verder over het internet.
3.2 Ontwikkeling van een proxy server
32
Figuur 3.4: Schema van de packetflow bij de tweede versie van de transparante DSL bonding proxy. Elke blokpijl geeft een pad van een netwerkpakket weer. Rechts van het pad wordt de evolutie van een netwerkpakket weergegeven, zowel voor client-server verkeer, als voor server-client verkeer. De Click Client IP is het extern IP adres van de Click-router aan client-zijde, waarmee de Click-router met een modem communiceert. De Click-router heeft evenveel externe IP adressen als het aantal modems.
De verdeling van de netwerkpakketten over de verschillende flows kan op verschillende manieren. Wanneer elke gebruikte DSL-lijn ongeveer dezelfde bandbreedte levert, is het aangeraden om de pakketten in gelijke mate over de verschillende flows te verdelen. Dit kan verwezenlijkt worden met het standaard Click element RoundRobinSwitch. Indien de DSL lijnen verschillende bandbreedtes bieden, dan kunnen de pakketten verdeeld worden door middel van het StrideSwitch element. Bij de configuratie van dit element is het mogelijk om tickets uit te delen aan uitgangen. Wanneer uitgang 2 twee keer zoveel tickets als uitgang 1 heeft, worden er twee keer zoveel pakketten gestuurd langs output 2, dan langs output 1. Bij het aankomen van netwerkpakketten aan de WAN-zijde van de Click-routers, worden de pakketten eerst opgesplitst in de oorspronkelijke flows. Hun buitenste IP-header wordt verwijderd. De timestamp wordt door middel van het eigen ontwikkelde element ExtractTimestamp (zie 3.3.3) in de annotaties van het pakket geplaatst en vervolgens uit de data verwijderd. De timestamp wordt gebruikt door het element TimeSortedSched om te trachten de netwerkpakketten weer in de oorspronkelijke volgorde te plaatsen. De pakketten worden vervolgens aan de hand van de IP-gegevens uit de binnenste IP-header verder gerouteerd aan de LAN-zijde van de Click-router.
3.2 Ontwikkeling van een proxy server
33
Figuur 3.5: De evolutie van het source- en destination- adres van de buitenste IP header bij het IPinIP verkeer bij het gebruik van de DSL bonding proxy. De modems maken gebruik van NAT.
In bijlage B staan schema’s van de client- en server- click configuraties bij gebruik van 2 modems. Figuur B.1 toont de client-configuratie. Figuur B.2 toont de server-configuratie.
3.2.2.3
Bespreking voor- en nadelen
Deze router biedt een oplossing voor de problemen die in de eerste versie van de DSL bonding proxy opdoken. Vooral de praktische problemen, zoals het niet kunnen opstarten van een verbinding vanuit de server-kant, het veranderen van de pakketten en dat er maar ´e´en client en server op hetzelfde moment kunnen verbinden, hebben een elegante oplossing gekregen. Er zijn echter verschillende nadelen verbinden aan deze router, en dan vooral op performantiegebied. Via een extra IP header en een timestamp introduceert deze router 28 bytes aan extra overhead per pakket. Dit betekent dat er per pakket 28 bytes minder aan data kan vervoerd worden. Het grootste performantie-probleem situeert zich echter ter hoogte van de gebruikte scheduler,
3.2 Ontwikkeling van een proxy server
34
TimeSortedSched. Bij elke pull-operatie zal TimeSortedSched al zijn inputlijnen aflopen, en het element met de vroegste timestamp doorsturen. Wanneer een inputlijn geen pakket kan aanleveren, dan wordt het bij deze pull-operatie genegeerd. De scheduler kan ook maar ´e´en pakket per inputlijn beschouwen. Pakketten die op eenzelfde lijn in de verkeerde volgorde toekomen zullen niet geordend kunnen worden. De scheduler houdt ook niet bij welke pakketten hij reeds doorgestuurd heeft. Hij kan dus onmogelijk beslissen of een toekomend pakket te laat is, en dus gedropt moet worden. De scheduler is ook makkelijk te misleiden door middel van packet injection. Wanneer op ´e´en inputlijn steeds pakketten met een erg lage timestamp gestuurd worden, dan zal deze lijn ook steeds voorrang krijgen op de andere lijnen. Een groot deel van deze problemen zijn te wijten aan het gebruik van timestamps. De scheduler kan nooit voorspellen of er pakketten vertraagd zijn en nog moeten binnenkomen. Wanneer een pakket binnenkomt met timestamp m, kan de scheduler nooit weten of er voor dat tijdstip m ook pakketten verstuurd zijn die nog moeten binnenkomen. Deze router biedt een zekere vorm van herordening van pakketten. Deze herordening is echter onvoldoende. Er kunnen nog steeds pakketten in verkeerde volgorde doorgestuurd worden, hetgeen nefast is voor de performantie bij gebruik van het TCP-protocol op de transportlaag (zie 2.3).
3.2.3 3.2.3.1
Derde versie: sequentie Situering
De tweede versie van de transparant DSL bonding proxy wist komaf te maken met vele problemen uit de eerste versie, maar kent nog steeds vele tekortkomingen. Met name de performantie is niet wat het moet zijn door de gebrekkige herordening van de pakketten. Het grootste probleem is dat een Click-router bij het ontvangen van een pakket onmogelijk kan weten of het dit pakket reeds mag doorsturen, of nog moet wachten op een trager pakket. Dit is echter wel mogelijk wanneer we in plaats van een timestamp, een sequentienummer voor elk pakket beschouwen. Om performantieredenen is het alleen doenbaar om al het IP-verkeer in zijn geheel te sorteren, en niet per IP-stroom. Indien er per IP-stroom gesorteerd zou worden, zou dit vereisen dat er bij het herordenen een aparte buffer per IP-stroom gealloceerd wordt. Bij het be¨eindigen van een IP-verbinding zou de buffer weer gedealloceerd moeten worden. Het regelmatig alloceren en dealloceren van substanti¨ele hoeveelheden geheugen, gecombineerd met het feit dat het niet makkelijk is om de be¨eindiging van een IP-verbinding te detecteren, maakt dat deze manier
3.2 Ontwikkeling van een proxy server
35
van herordening niet erg performant kan zijn. In een situatie van veel slapende IP-verbindingen zou het trouwens tot een gigantisch geheugenverbruik leiden. De enige performante manier van herordening is dan ook het herordenen van al het verkeer tezamen. Elk netwerkpakket dient duseen uniek sequentienummer te hebben. In eerste instantie werd gezocht naar een bruikbaar sequentienummer in de headers van de netwerkpakketten. Aangezien de proxy op IP-niveau werkt, zijn enkel de gegevens uit IP-headers bruikbaar. 2.5.5 leert ons dat een IP header een Identification nummer bevat. Aangezien de router IPinIP verkeer gebruikt, zijn er twee IP headers beschikbaar, elk met hun eigen Identification. Aangezien de proxy in situaties van veel gelijktijdige verbindingen kan gebruikt worden, is het sequentienummer van de binnenste IP-header onbruikbaar. Er zijn meerdere redenen waarom het moeilijk is om de Identification uit de buitenste header te gebruiken. Elke modem verwerkt een aparte IP-stroom, waarvan de buitenste IP-header verschillende koppels source- of destination-adressen hebben. Aangezien het niet geweten is hoeveel pakketten er per modem verzonden worden, zouden we ervoor moeten zorgen dat al de pakketten, ongeacht de lijn waarover ze verzonden worden, een verschillend Identification zouden moeten hebben. Bij analyse van het verkeer van 1 IP-stroom zou het lijken alsof er structureel pakketten zouden ontbreken, wat het debuggen van netwerkverkeer bemoeilijkt voor mensen die niet weten dat er aan bonding via transparante proxies gedaan wordt. Zoals 3.2.4.9 ons leert, kan de Identification echter beter voor iets anders gebruikt worden, indien hij niet gemanipuleerd wordt. Daarom is geopteerd om een sequentie achteraan de data van elk pakket te plakken. De derde versie verschilt qua click-configuratie dan ook weinig met de tweede versie van de DSL bonding proxy. Aangezien Click standaard geen elementen heeft voor het gebruik van sequentienummers, zijn al de benodigde elementen zelf ontwikkeld. SetSequence, StoreSequence, ExtractSequence en SequenceSortedSched vertonen gelijkenissen met respectievelijk SetTimestamp, StoreTimestamp, ExtractTimestamp en TimeSortedSched. SetSequence plaatst een sequentienummer in de annotatie van een netwerkpakket (zie 3.3.6), StoreSequence slaat de sequentie op achter de data van het pakket (zie 3.3.7), ExtractSequence haalt de sequentie uit de data van een pakket (zie 3.3.2) en SequenceSortedSched herordent de pakketten op basis van hun sequentienummer (zie 3.3.5).
3.2 Ontwikkeling van een proxy server
36
Figuur 3.6: Samenstelling van een IP pakket bij het gebruik van de derde versie van de bonding DSL router.
Figuur 3.7: Schema van de packetflow bij de derde versie van de transparante DSL bonding proxy. De werking is gelijkaardig aan die van de tweede versie van de DSL bonding proxy.
3.2.3.2
Werking
De werking is gelijkaardig aan de werking van de tweede versie van de transparante DSL bundeling proxy. Ook nu wordt er gemaakt van IPinIP tunnels. Figuur 3.6 geeft de samenstelling van een pakket weer, nadat een extra IP-header en een sequentienummer werd bijgevoegd. Figuur 3.7 geeft dan weer de packet flow weer. Deze packetflow is dezelfde als degene bij de tweede versie van de proxy, en werd reeds besproken in 3.2.2.2. De evolutie van het source- en destination IP-adres is te vinden in figuur 3.5. De grootste innovatie is het gebruik van sequentienummers. Elk pakket dat aan de LAN-kant van een Click-router komt, zal na fragmentatie en vermindering van de TTL een sequentie krijgen. Het is belangrijk om de sequentie na de fragmentatie toe te kennen, zodat pakketten die niet fragmenteerbaar zijn of een te hoge TTL hebben, geen sequentienummer krijgen en dus niet
3.2 Ontwikkeling van een proxy server
37
voor onnodige timeouts kunnen zorgen. Zoals bij de tweede versie van de proxy server, worden de pakketten via een RoundRobinSwitch of StrideSwitch over verschillende flows verdeeld. Elk pakket krijgt een extra IP header en wordt vervolgens doorgestuurd. Bij aankomst van pakketten over het internet, wordt eerst de extra IP header verwijderd, het sequentienummer uit de data naar een annotatie gekopieerd en vervolgens dit sequentienummer uit de data gehaald. Aan de hand van het sequentienummer kan SequenceSortedSched de pakketten weer ordenen volgens hun oorspronkelijke volgorde. De werking van SequenceSortedSched wordt uitgebreid besproken in 3.3.5. Aangezien de sequentienummers van opeenvolgende pakketten elkaar ook opvolgen, weet de scheduler wanneer hij op een pakket dient te wachten en wanneer niet. In bijlage B staan schema’s van de client- en server- click configuraties bij gebruik van 2 modems. Figuur B.3 toont de client-configuratie. Figuur B.4 toont de server-configuratie.
3.2.3.3
Bespreking voor- en nadelen
Het werken met sequentienummers in plaats van met timestamps biedt vele voordelen. Het gebruikte sequentienummer is slechts 4 bytes groot. Hierdoor valt de extra overhead terug naar 24 bytes (1 extra IP header + het sequentienummer). De IP payload is dus ook 4 bytes groter: 1500 bytes - 20 bytes - 4 bytes = 1456 bytes. Het belangrijkste voordeel is echter, dat de scheduler na het doorsturen van een pakket steeds weet welk volgend pakket hij zal moeten doorsturen. De grootste moeilijkheid blijkt nu het te weten komen of een pakket ofwel vertraging heeft, ofwel onderweg verloren gegaan is. Bij een goede implementatie van de scheduler bekomt men een volwaardige transparante DSL bonding proxy, die de pakketten in de juiste volgorde bij zijn bestemming aflevert. De transparantie wordt gegarandeerd door de IPinIP encapsulatie, terwijl de ordening door de sequentienummers gegarandeerd wordt.
3.2.4 3.2.4.1
Opmerkingen MTU
Er zijn een paar nadelen verbonden aan deze manier van DSL bonding die gebruikt wordt in de tweede en derde versie van de DSL bonding proxy. Door de toevoeging van een extra overhead vermindert ook de MSS. Programma’s die niet aan Path MTU discovery doen zullen hier geen rekening mee houden en proberen te grote pakketten te sturen. De Click router gaat
3.2 Ontwikkeling van een proxy server
38
een te grote pakket opsplitsen in ´e´en groot en ´e´en klein pakket. Bij gebruik van een gewone RoundRobinSwitch en een even aantal DSL lijnen, zullen de lijnen niet optimaal belast worden. E´en op twee lijnen zal volledig benut worden, terwijl de andere lijnen enkel kleine pakketten moeten verwerken. De totale bandbreedte zakt hierdoor terug tot iets meer dan de helft van de theoretisch haalbare banbreedte. Een mogelijke oplossing is het versturen van pakketten in bursts van een even aantal pakketten. Op deze manier zal een betere verdeling van de pakketten verkregen kunnen worden. Een andere mogelijke oplossing, is een eigen Switch-element schrijven die het aantal verstuurde bytes per lijn probeert gelijk te houden.
3.2.4.2
NAT
De modems die aan Network Address Translation (NAT) doen moeten configureerbaar zijn, zodat ze al het IPinIP-verkeer direct doorsturen naar de Click-router. Indien modems gebruikt worden die deze mogelijkheden niet bezitten, is het raadzaam om de Click-routers regelmatig bogus pakketten naar elkaar te sturen, zodat de NAT-entry voor trafiek tussen beide Clickrouters niet verloopt.
3.2.4.3
Out-of-order pakketten
De transparante DSL bonding proxy doet aan herordening van binnenkomende pakketten, maar doet niets om herordening te voorkomen. De herordening zal misschien niet te veel rekenkracht vereisen bij relatief weinig en relatief trage DSL lijnen, maar kan een probleem vormen bij veel hogere bandbreedtes en en een groter aantal modems. Door steeds een burst van pakketten over elke lijn te sturen, zullen de pakketten individueel elkaar bij aankomst beter opvolgen. Het aantal timeouts dat gegenereerd wordt zal hierdoor gemiddeld verminderen. De grootte van de bursts dient uiteraard beperkt te worden om een gelijke belasting van alle lijnen te garanderen. Een andere mogelijkheid om herordening te verminderen, is het gefaseerd versturen van pakketten. Door pakketten op snellere lijnen iets later te versturen, zullen de pakketten in een homogenere stroom toekomen, en zal er bij aankomst gemiddeld gezien minder lang moeten gewacht worden op een vertraagd pakket. De vertraging moet uiteraard goed gekozen worden, anders kan men een averechts effect cre¨eren, waarbij pakketten die langs tragere lijnen gaan veel vroeger toekomen dan de pakketten die langs snellere lijnen gaan.
3.2 Ontwikkeling van een proxy server
3.2.4.4
39
Bonding
Alhoewel er gezocht is naar een oplossing voor DSL bonding, zijn de Click routers vrij generiek en inzetbaar bij een grote diversiteit aan netwerkverbindingen. Deze netwerkverbinding dienen zelf niet gelijkaardig zijn. Het is perfect mogelijk om kabel- ethernet- en DSL-lijnen samen te bundelen. Er dient bij de configuratie van het systeem uiteraard rekening gehouden te worden met de verschillende types verbindingen. Om optimaal gebruik te maken van de bandbreedte zal het wenselijk zijn om Strideswitch in plaats van RoundRobinSwitch te gebruiken. Op deze manier is het aantal pakketten dat per lijn verdeeld wordt instelbaar.
3.2.4.5
Polling drivers
De Click modular router architectuur is geoptimaliseerd voor gebruik met polling drivers voor de netwerkkaarten. Naast de kleinere delay bij het verwerken van netwerkkaarten, en het vermijden van een lockup wegens te veel interrupts, werken polling drivers ook beter samen met de Click modular router. Aangezien deze polling drivers niet beschikbaar waren voor onze gebruikte opstelling, is er in deze thesis geen gebruik van gemaakt.
3.2.4.6
Expensive push & expensive pull
Click alloceert geheugen voor elk pakket, en voorziet dat geheugen van een zekere head- en tailroom. Wanneer er gegevens vooraan of achteraan een pakket geplaatst worden, worden deze head- en tailroom hiervoor gebruikt. Aangezien er bij onze configuratie zowel vooraan als achteraan de pakketten data wordt bijgeplaatst, vereist het dat de head- en tailroom groot genoeg is. Bij gewone drivers dient hiervoor de kernel van Linux aangepast te worden. Bij polling drivers is het voldoende om het bestand polldevice.cc van de Click modular router aan te passen. Op lijn 230 dient het eerste argument van skbmgr allocate skbs aangepast te worden om meer headroom te alloceren. In de setup van deze scriptie zijn er geen aanpassingen hiervoor gebeurd. Indien de aanpassingen niet gedaan worden, moet elk pakket een extra keer gekopieerd te worden naar een nieuwe, grotere buffer.
3.2 Ontwikkeling van een proxy server
3.2.4.7
40
Security
Er dient extra aandacht besteed te worden aan de security. Aangezien de netwerkpakketten niet door de firewall van de modems behandeld worden, dient ervoor gezorgd te worden dat ze, na door de click-router verwerkt te zijn, door een firewall gerouteerd worden. Er dient ook extra aandacht besteed te worden aan het risico van packet injection. Bij de tweede versie van de proxy server, kan voorrang aan eigen netwerktrafiek afgedwongen worden door een extra lage timestamp in de pakketten te plaatsen. De derde versie van de proxy is hier minder gevoelig voor, aangezien de router weet op welke pakketten hij moet wachten, en wanneer een pakket niet in de interne buffer past, het pakket gedropped wordt.
3.2.4.8
Failover
Een groot probleem bij DSL bonding via een transparante proxy, is dat de proxy niet aan diagnostische gegevens van een modem kan. Zo is het onmogelijk om de interne buffers van de gebruikte modems uit te lezen. Er kan dus ook geen gepaste actie ondernomen worden wanneer de interne buffers va een modem dreigen vol te raken, of wanneer een modem uitvalt. Om effectief aan automatische failover te kunnen doen, zouden beide Click-routers uit de opstelling met elkaar moeten kunnen communiceren. De ontvangende Click-router zou de andere Click-router kunnen verwittigen wanneer er abnormaal weinig pakketten over ´e´en inputlijn binnenkomen. De verzendende router zou vervolgens de verdeling van de pakketten over de verschillende lijnen anders kunnen configureren. Deze manier van werken vereist het schrijven van Click-elementen die speciale pakketjes naar elkaar sturen met diagnostische gegevens. Deze elementen zouden vervolgens de instellingen van StrideSwitch via diens handlers kunnen wijzigen.
3.2.4.9
Identification
Bij het herordenen kan gebruik gemaakt worden van een extra gegeven: De netwerkpakketten worden per lijn geencapsuleerd in IPinIP-pakketten. De buitenste IP-header bevat een Identification nummer. De Identification nummers volgen elkaar per lijn op. De scheduler kan deze Identification nummers per lijn bijhouden en hierdoor sneller pakketverlies op een lijn ontdekken.
3.3 Ontworpen Click elementen
3.3
41
Ontworpen Click elementen
De Click Modular router wordt standaard geleverd met een uitgebreid repertoire aan elementen die verschillende basistaken op het gebied van routering op zich nemen. Bij het ontwerpen van de Click configuraties voor een transparante DSL bonding router, rees meermaals de noodzaak om zelf elementen te ontwikkelen die functies vervullen die door geen enkel bestaand Click element vervuld worden. De modulaire opbouw van Click biedt de mogelijkheid om zelf elementen te ontwikkelen in C++. Er dient wel rekening gehouden te worden met enkele beperkingen, aangezien de ontwikkelde elementen in kernel-mode moeten kunnen draaien. Zo kan er enkel gerekend worden in gehele getallen, kan er geen gebruik gemaakt worden van try-catch constructies en kan er maar beperkt gebruik worden bestaande libraries. Click levert een eigen compatibele implementatie van een groot deel van de standaard library. Hieronder volgt een bespreking van de zelf ontwikkelde elementen. De implementatie van deze elementen is te vinden op de meegeleverde CD-ROM.
3.3.1
AddVlanTag
Naam:
AddVlanTag
Configuratie-opties:
unsigned int VLAN-tag
Input poorten:
1, agnostic
Output poorten:
1, agnostic
Verwachte input:
ethernet datagrammen
Output:
ethernet datagrammen met VLAN-tag
De gebruikte opstelling (zie figuur A.1) maakt gebruik van VLANs (zie 2.5.2). Om een zo effici¨ent mogelijke Click router te bouwen, is het wenselijk de VLAN afhandeling door Click te laten gebeuren. Dit element neemt de toe te voegen VLAN-tag als argument in de vorm van een unsigned integer. Eerst worden 4 extra bytes ruimte aan het begin van het datagram toegevoegd. Vervolgens worden de eerste 12 bytes die het source- en destination MAC-adres bevatten 4 bytes naar voor verplaatst. Hierachter wordt het VLAN protocol-type (0x8100) in 2 bytes in big endian opgeslagen. In de twee volgende bytes wordt de VLAN-tag in big endian opgeslagen. Al de nieuw gecre¨eerde ruimte is nu opgevuld. De VLAN-tag wordt dus gevolgd door het ethernet-type. Op deze manier worden VLAN-datagrammen gecre¨eerd, conform aan de 802.1Q-specificaties[7]. Het element is agnostisch en kan dus zowel als een pull- of als een
3.3 Ontworpen Click elementen
42
push-element gebruikt worden.
3.3.2
ExtractSequence
Naam:
ExtractSequence
Configuratie-opties:
boolean removeSequenceFromPacket
Input poorten:
1, agnostic
Output poorten:
1, agnostic
Verwachte input:
netwerkpakketten waarvan de laatste 4 bytes een sequentie bevatten
Output:
dezelfde netwerkpakketten die via de input binnenkomen, al dan niet zonder de sequentie
Binnen een Click-router krijgt elk pakket extra geheugen toegewezen waarin annotaties opgeslagen kunnen worden. Deze annotaties bieden een snelle gegevenstoegang zonder steeds het pakket opnieuw te moeten analyseren om gegevens zoals het destination-address uit te lezen. ExtractSequence haalt het sequentienummer uit de data van een pakket. Het sequentienummer is steeds een unsigned integer van 32 bits of 4 bytes dat in big endian opgeslagen is op het einde van het pakket. Dat sequentienummer wordt vervolgens op bytes 8 tot 11 van de user annotation space geplaatst. De boolean die als argument opgegeven wordt, geeft aan of het sequentienummer al dan niet uit het element verwijderd dient te worden. ExtractSequence is een agnostisch element.
3.3.3
ExtractTimestamp
Naam:
ExtractTimestamp
Configuratie-opties:
boolean removeTimeStampFromPacket
Input poorten:
1, agnostic
Output poorten:
1, agnostic
Verwachte input:
netwerkpakketten waarvan de laatste 8 bytes een timestamp bevatten
Output:
dezelfde netwerkpakketten die via de input binnenkomen, al dan niet zonder de timestamp
Er bestaat een Click element die een timestamp in een annotatie kan plaatsen (SetTimestamp)[2]. Een ander bestaand element, StoreTimestamp, kan deze timestamp-annotatie vervolgens in de data van het pakket opslaan. Er bestaat geen element die bij aankomst van een pakket de
3.3 Ontworpen Click elementen
43
timestamp uit de pakketdata kan halen om die vervolgens weer in een annotatie te plaatsen. Daarom werd een eigen element ontwikkeld die een timestamp uit een pakket kan uitlezen, wanneer deze zich in de laatste 8 bytes van de data van dat pakket bevindt. De implementatie is gelijkaardig aan die voor het element ExtractSequence (zie 3.3.2). De configuratie-optie, die een boolean is, bepaalt of de timestamp al dan niet uit de pakketdata verwijderd dient te worden. ExtractTimestamp is een agnostisch element.
3.3.4
RemoveVlanTag
Naam:
RemoveVlanTag
Configuratie-opties:
geen
Input poorten:
1, agnostic
Output poorten:
1, agnostic
Verwachte input:
ethernet datagrammen met VLAN-tag
Output:
ethernet datagrammen
Dit element doet het omgekeerde van AddVlanTag (zie 3.3.1). Het haalt de 4 bytes die verantwoordelijk zijn voor het VLAN-protocol weg uit de ethernet-header, en verplaatst de 12 eerste bytes 4 bytes naar rechts. Vervolgens worden de 4 lege bytes vooraan het pakket verwijderd. RemoveVlanTag is een agnostisch element.
3.3.5
SequenceSortedSched
Naam:
SequenceSortedSched
Configuratie-opties:
TIMEOUT: unsigned integer die de timeout in milliseconden geeft N: unsigned integer die de grootte van de ringbuffer geeft PACKETSBEFOREDROP: unsigned integer die het aantal pakketten geeft die op elke lijn mogen binnenkomen voordat een pakket als timeout gezien wordt
Input poorten:
0 tot oneindig, push
Output poorten:
1, pull
Verwachte input:
IP pakketten die een sequentie-annotatie bevatten
Output:
dezelfde IP pakketten, geordend per sequentienummer
Opmerking:
Timestamp annotation wordt overschreven
3.3 Ontworpen Click elementen
3.3.5.1
44
Functie
SequenceSortedSched is, net zoals RoundRobinSched en TimeSortedSched[2], een scheduler. In de Click modular router architectuur werkt een scheduler als een multiplexer die pakketten uit verschillende inputs aanvaardt, er eventueel een bewerking op uitvoert, en ze vervolgens volgens ingebakken prioriteitsregels via ´e´en output weer laat vertrekken. In de context van DSL bundeling wordt een scheduler gebruikt om de verschillende binnenkomende stromen netwerkpakketten weer samen te voegen tot ´e´en stroom pakketten. SequenceSortedSched werd ontworpen met als doel de binnenkomende pakketten te sorteren volgens de sequenties die zich op bytes 8 tot 11 van de user annotation space van de binnenkomende pakketten bevindt. Het tracht op een performante manier aan packet reordering te doen. Figuur 3.8 is een illustratie van de werking van SequenceSortedSched.
Figuur 3.8: Een illustratie van de werking van SequenceSortedSched.
Het element wordt gebruikt in een transparante proxy server, en dient dus een minimale impact te hebben op de performantie van de netwerkverbindingen. Het is dan ook belangrijk dat pakketten geen te grote delay oplopen wanneer ze de scheduler doorlopen. Bij een client-server verbinding kunnen er steeds netwerkpakketten verloren gaan. Wanneer de scheduler aan het wachten is op een binnenkomend pakket met een bepaald sequentienummer, is het belangrijk dat de scheduler goed kan inschatten of een pakket verloren is of gewoon vertraging opgelopen heeft. Een verkeerde inschatting kan verregaande gevolgen hebben. Wanneer de scheduler te lang op een verloren pakket wacht, worden de overige netwerkpakketten te lang opgehouden, hetgeen kan leiden tot te hoge en inconsistente delays voor de netwerkverbindingen waartoe deze pakketten
3.3 Ontworpen Click elementen
45
behoren. Interne buffers binnen de Click router kunnen door het te lange wachten vol raken en zelf voor pakketverlies zorgen. Niet lang genoeg wachten op een vertraagd pakket kan ook erg negatieve gevolgen hebben. Pakketten die nog moeten binnenkomen kunnen, afhankelijk van de implementatie van de router, ofwel verloren gaan, ofwel out-of-order doorgestuurd worden. Beide gevallen hebben een verregaande impact op de doorvoersnelheid van TCP-verbindingen (zie 2.5.8). De grootste complexiteit van deze scheduler bevindt zich dan ook in deze beslissingsregels. Om het wachten op late pakketten mogelijk te maken, bevat de scheduler een interne circulaire buffer. In totaal zijn er meerdere versies van SequenceSortedSched ontwikkeld. Elke versie had een verschillende aanpak om een timeout te bepalen. De noodzaak om nieuwe versies te ontwikkelen werd vaak duidelijk bij de netwerktesten. Zo viel bij sommige schedulers de performantie in elkaar in situaties van veel packet loss op de DSL-lijnen, werden er soms toch pakketten in verkeerde volgorde gestuurd, was de doorlooptijd van pakketten door de scheduler inconsistent, of liep de interne ringbuffer traag leeg op het einde van een verbinding die veel packet loss genereerde. Drie belangrijke versies worden hier besproken. De derde en laatste versie bleek uiteindelijk een adequate performantie de bieden.
1. De eerste versie wou ervoor zorgen dat elk pakket dat de scheduler binnenkomt, ook daadwerkelijk wordt verstuurd. De staart van de interne ringbuffer was steeds voorbehouden voor het volgende element waarvan de scheduler dacht dat het zou verzonden moeten worden. Bij het binnenkomen van een laat pakket, werd er extra ruimte gealloceerd om dit nieuwe pakket te laten passen in de buffer. Vervolgens werd dit laatste pakket verstuurd. De aanpak was meer gericht op het versturen van alle pakketten, dan om goede timeoutregels te implementeren. Het resultaat was dan ook dat er regelmatig pakketten in verkeerde volgorde verstuurd werden, of gewoonweg gedropt. Deze scheduler werd dan ook achterwege gelaten. 2. De tweede versie was vooral gericht op de ontwikkeling van de timeoutregels. De scheduler laat ook geen out-of-order pakketten meer door. De staart van de interne ringbuffer is steeds het pakket in de buffer met de laagste sequentie. De timeoutregels zijn vooral gericht op het wachten van een laat pakket. Wanneer dit pakket een zekere tijd op zich laat wachten, dan wordt een timeout gegenereerd, en het volgende element verstuurd. Timeouts worden ook gegenereerd wanneer er, bij het wachten op pakketten, een zekere
3.3 Ontworpen Click elementen
46
hoeveelheid nieuwe pakketten binnengekomen zijn op elke lijn. Eens de bezetting van de buffer te groot wordt, wordt de buffer ook geledigd. Deze versie biedt een goede performantie. 3. De derde versie verschilt niet veel van de tweede. In plaats van een timeout te genereren tijdens het wachten op een pakket, wordt een timeout per pakket berekend. Bij het binnenkomen van een pakket in de scheduler, wordt een timestamp aan diens annotatie toegevoegd. Wanneer het gezochte element zich niet in de buffer bevindt, wordt er gekeken naar de tijd die het pakket in de staart van de buffer reeds in die buffer zit. Indien het pakket zich er te lang bevindt, wordt een timeout gegenereerd. Zoals in de tweede versie wordt ook hier een timeout gegenereerd bij een volle buffer of wanneer er bij het wachten op een pakket, een bepaalde hoeveelheid pakketten per lijn zijn binnengekomen.
Hieronder komt een uitvoerige bespreking van de derde scheduler: De SequenceSortedSched bevat verschillende optionele parameters die gebruikt kunnen worden bij het aanpassen van de SequenceSortedSched aan de specifieke situaties waar hij ingezet kan worden. N unsigned integer stelt de grootte van de interne ringbuffer in. Deze staat standaard ingesteld op 1024 pakketten. In deze buffer slaat de scheduler pakketten op terwijl hij staat te wachten op een volgend pakket dat moet binnenkomen. TIMEOUT integer stelt de tijd in milliseconden voor, dat een pakket zich maximaal in de buffer mag bevinden. Wanneer het volgend te versturen pakket zich niet in de buffer bevindt, maar de staart reeds langer dan TIMEOUT in de buffer zit, dan zal het pakket bij de staart verstuurd worden. De timeout staat standaard ingesteld op 100 milliseconden. PACKETSBEFOREDROP unsigned integer is een parameter waar rekening mee gehouden wordt wanneer er op een pakket gewacht wordt. Het aantal dat door PACKETSBEFOREDROP gedefinieerd wordt, is het maximaal aantal pakketten dat op elke lijn mag binnenkomen, voordat het pakket waarop gewacht wordt als verloren wordt aanzien. Deze parameter gaat ervan uit dat pakketten op ´e´en lijn zelden of nooit out-of-order zullen toekomen. PACKETSBEFOREDROP wordt standaard op waarde 3 ge¨ınitialiseerd.
3.3.5.2
Ringbuffer
De implementatie van de SequenceSortedSched steunt op het gebruik van een grote geavanceerde ringbuffer. Deze buffer houdt pakketten bij die wachten om door de scheduler verder gestuurd
3.3 Ontworpen Click elementen
47
te worden. De scheduler tracht al de pakketten in de juiste volgorde te sturen, en zal dan ook op vertraagde pakketten wachten. Er is voor ´e´en centrale ringbuffer gekozen om snelheidsverschillen tussen verschillende binnenkomende lijnen beter op te kunnen vangen, de herordening gemakkelijker te laten verlopen, en om pakketten die op eenzelfde binnenkomende verbinding in verkeerde volgorde toekomen, ook te kunnen herordenen. Vandaar dat er gekozen is voor een configuratie met push-ingangen en pull-uitgangen. Wanneer er pakketten beschikbaar zijn bij de input-lijnen van de SequenceSortedSched, worden ze opgeslagen in de ringbuffer. Omgekeerd worden de pakketten doorgestuurd wanneer een ander element komt pollen aan de uitgangspoort van de SequenceSortedSched. Bij een poll-gebeurtenis beslist de SequenceSortedSched of hij al dan niet een pakket doorstuurt. Dit hangt af van de beschikbaarheid van pakketten binnen de ringbuffer, en of er al dan niet een timeout-gebeurtenis opgetreden is. De herordening van de pakketten gebeurt direct bij het opslaan van de pakketten in de ringbuffer. Dit gebeurt op basis van hun sequentienummer, dat uitgelezen wordt uit de bytes 8 tot 11 van de user annotation space. Het pakket met het chronologisch laagste sequentienummer dat zich in de buffer bevindt, is de staart van de ringbuffer. De kop van de ringbuffer wordt bekomen door de index van het pakket met het chronologisch hoogste sequentienummer met ´e´en te vermeerderen en vervolgens de rest te nemen na deling door de capaciteit van de ringbuffer. We spreken over chronologisch gerangschikte sequentienummers, aangezien een sequentienummer een unsigned 32-bits int is. Elke 4, 29 ∗ 109 pakketten begint het tellen weer bij nul. In het SequenceSortedSched element worden sequentienummers dan ook vergeleken door ze van elkaar af te trekken. Stel dat het pakket met sequentienummer n de staart van de ringbuffer is. Wanneer pakket n+m zich aanmeldt bij ´e´en van de inputpoorten, dan zal het in de ringbuffer opgeslagen worden op index (indexstaart + m) modulo de capaciteit van de ringbuffer. De ringbuffer controleert het sequentienummer wel eerst op geldigheid. Wanneer het in vergelijk met de reeds aanwezige sequentienummers te klein of te groot is, dan wordt het pakket gedropt. Deze manier van werken heeft als voordeel dat het sorteren van de pakketten volgens sequentienummer erg weinig rekenkracht vereist. Het controleren van de aanwezigheid van bepaalde pakketten gaat ook erg snel, aangezien het gewoon een kwestie is van rekenen met pointers. De ringbuffer wordt echter niet optimaal gebruikt en zal vrij groot moeten zijn. Bij een situatie waar er veel packetloss voorkomt zal de buffer zeer ijl gevuld zijn, waardoor die buffer gemakkelijk kan overlopen. In 3.3.5.3 worden regels uitgelegd waarmee getracht wordt te verhinderen dat de buffer overloopt. In het geval dat een pakket toekomt met eenzelfde sequentienummer als
3.3 Ontworpen Click elementen
48
een ander reeds aanwezig pakket, dan zal het reeds aanwezige pakket bewaard worden en het recent binnengekomen pakket zal gedropt worden. Bij het ontwerp van de router dient dan ook zorgvuldig op gelet te worden dat twee pakketten niet zomaar eenzelfde sequentienummer krijgen. Wanneer een pakket een chronologisch lager sequentienummer heeft dan het laatst doorgestuurd pakket, dan wordt het pakket als te laat beschouwd en gedropt. Hierdoor zal er nooit een pakket out-of-order doorgestuurd worden.
3.3.5.3
Timeout regels
Zoals reeds eerder besproken in 3.3.5.1, ligt de grootste moeilijkheid in het juist inschatten van de mogelijke vertraging van een pakket. Een pakket waarop gewacht wordt kan immers ofwel vertraging hebben, ofwel onderweg verloren geraakt zijn. Meerdere regels helpen de scheduler om een zo gefundeerd mogelijke beslissing te nemen. Een eerste regel werd reeds besproken in 3.3.5.1. De scheduler houdt per pakket de tijd bij waarop het in de buffer werd toegevoegd. Wanneer er gewacht wordt op een pakket, en de staart van de ringbuffer reeds langer in die buffer zit dan de TIMEOUT-parameter, dan wordt het pakket doorgestuurd. Het pakket waarop gewacht werd wordt als verloren beschouwd. Men gaat er immers van uit dat wanneer een pakket out-of-order toekomt, dat er steeds binnen een zeker delay is. Deze maatregel geeft ook een bovengrens aan de extra delay die door de scheduler aan een pakket wordt toegevoegd. De oorzaak van het in verkeerde volgorde toekomen van netwerkpakketten is meestal te wijten aan de verschillend paden die de individuele pakketten gevolgd hebben. Op eenzelfde lijn komen pakketten zelden in verkeerde volgordetoe. De SequenceSortedSched wenst dit gegeven dan ook te gebruiken bij de detectie van verloren gegane pakketten. Het is voor de SequenceSortedSched niet mogelijk om te voorspellen langs welke ingang een bepaald pakket zal binnenkomen. Vanaf het moment waarop de scheduler moet wachten op een vertraagd pakket, zal hij tellen hoeveel pakketten er op elke ingangslijn binnenkomen. Wanneer op elke ingangslijnen minstens PACKETSBEFOREDROP pakketten binnengekomen zijn, beslist de scheduler dat het pakket verloren gegaan is, en zal het het eerstvolgend aanwezige pakket verzenden. Deze parameter is instelbaar, zodat de scheduler ook bruikbaar is in netwerkomgevingen waar pakketten wel in verkeerde volgorde kunnen toekomen. De scheduler zal ook deze pakketten in gode volgorde plaatsen.
3.3 Ontworpen Click elementen
49
Een extra timeoutregel kijkt naar de bezettingsgraad van de buffer. Wanneer de index van (head - tail + capaciteit) modulo capaciteit groter is dan een gedefinieerde bezettingsgraad, dan verkiest de scheduler van pakketten door te sturen, dan te wachten totdat de buffer volledig gevuld raakt en er pakketten gedropt dienen te worden omdat ze niet in de buffer passen. Deze regel is vooral van beland bij verbindingen die meer pakketten sturen dan de netwerkinfrastructuur kan doorsturen. Dit zijn situaties waarin veel packetloss op een structurele en repetitieve manier optreedt. Het wachten op normale timeouts duurt vaak te lang. Deze regel zorgt ervoor dat, eens de buffer een bepaalde bezettingsgraad gehaald heeft, er toch steeds een zekere hoeveelheid netwerkpakketten doorgestuurd worden. Deze hoeveelheid zal gemiddeld even groot zijn als de het aantal pakketten dat de buffer binnenkomt. Op deze manier zal de buffer nooit overlopen, en wordt er steeds een zekere stroom aan netwerkpakketten gegarandeerd. Het is belangrijk om bij de configuratie van een Click router die een SequenceSortedSched gebruikt, de parameters goed te kiezen.
Figuur 3.9: De beslissingsboom bij een push bij SequenceSortedSched.
3.3.5.4
Extra implementaties
De scheduler bezit meerdere handlers die gemakkelijk via Click uitgelezen kunnen worden. Zo zijn er handlers die de maximale bezetting van de buffer bijhouden (highwater), de huidige
3.3 Ontworpen Click elementen
50
Figuur 3.10: De beslissingsboom bij een pull bij SequenceSortedSched.
bezetting (packets), de capaciteit (capacity), het aantal drops (drops), de ingestelde timeout (timeout), het aantal keer dat de click-router merkt dat de click-router aan de andere kant van de client-server verbinding hestart of veranderd is geworden (resets), het aantal timeouts dat door de scheduler waargenomen werd (timeouts), en het aantal keer dat er een pakket nog binnenkomt, nadat er reeds een timeout voor dat pakket gegenereerd werd (latePackets). Figuren 3.9 en 3.10 geven een vereenvoudigde beslissingsboom voor de verwerking van een push en een pull door SequenceSortedSched. SequenceSortedSched houdt ook rekening met de situatie waarbij de click-router aan de andere kant van de tunnel gereset wordt, waardoor de sequentienummers plots in een geheel andere range liggen dan het laatst verstuurde pakket.
3.3 Ontworpen Click elementen
3.3.6
51
SetSequence
Naam:
SetSequence
Configuratie-opties:
geen
Input poorten:
1, agnostic
Output poorten:
1, agnostic
Verwachte input:
IP pakketten
Output:
IP pakketten met een sequentie annotatie
SetSequence is een agnostisch element dat sequenties genereert. Een sequentie bestaat uit een 32 bits unsigned integer. Voor ieder pakket dat door het element gaat, wordt een sequentie gegenereerd en in op bytes 8 toot 11 van diens user annotation space geplaatst. Het eerste pakket krijgt het sequentienummer 0, het tweede pakket krijgt het sequentienummer 1, enzovoort... Aangezien het sequentienummer een unsigned integer is van 32 bits, bestaan er 4, 29 ∗ 109 verschillende sequentienummers. Dit geeft voldoende ruimte om een groot aantal verschillende pakketten van elkaar te onderscheiden. Aangezien een sequentienummer door een unsigned integer voorgesteld wordt, is er geen risico bij overflow. Eens dat er 4, 29 ∗ 109 pakketten door het element gegaan zijn, zal er immers weer vanaf nul geteld worden. Bij het verwerken van de sequentienummers dient er hier wel rekening gehouden te worden. Het heeft weinig zin om de volgorde tussen pakketten te baseren op het feit dat het sequentienummer van het ene pakket groter is dan het sequentienummer van het andere pakket. In plaats daarvan dient het verschil tussen twee sequentienummers gebruikt worden te om pakketten onderling te kunnen vergelijken. Het element SetSequence bezit een handler sequencenr die het sequentienummer weergeeft dat aan het volgend pakket toegewezen gaat worden.
3.3.7
StoreSequence
Naam:
StoreSequence
Configuratie-opties:
geen
Input poorten:
1, agnostic
Output poorten:
1, agnostic
Verwachte input:
IP pakketten met een sequentie annotatie
Output:
IP pakketten met een 4 bytes lang sequentienummer op het einde van de data
3.4 Studie theoretisch haalbare bandbreedte
52
StoreSequence is een agnostisch element dat sequentienummers opslaat in de data van pakketten. De werkwijze is gelijkaardig aan die van StoreTimestamp. Het element verwacht dat er zich een sequentienummer bevindt op bytes 8 tot 11 van de user annotation space. Eerst wordt er ruimte gecre¨eerd door 4 extra bytes geheugen te alloceren, juist na de laatste byte van het pakket. In deze 4 extra bytes wordt het sequentienummer uit de user annotation space in big endian gekopieerd. Figuur 3.11 geeft een voorstelling van de werking van StoreSequence.
Figuur 3.11: De werking van StoreSequence.
3.4
Studie theoretisch haalbare bandbreedte
Een studie van de theoretisch haalbare bandbreedte zal een bovengrens voor de haalbare bandbreedte geven. De gevonden waarden kunnen bij het benchmarken gebruikt worden om de effici¨entie van de ontworpen systemen te berekenen. De modems zijn via VLANs over ´e´en 100Mbps UTP-kabel met de Click-router verbonden, het is dus interessant om de maximaal haalbare performantie te beschouwen over ´e´en 100Mbps UTP-verbinding. Vervolgens wordt de maximale bandbreedte over 1 ADSL-modem berekend. Hieruit kan gemakkelijk de maximale bandbreedte voor meerdere modems berekend worden. De bandbreedte waarin wij ge¨ınteresseerd zijn is het aantal bits/seconde aan TCP- of UDP-payload. Zowel bij de berekening van de maximale bandbreedte bij UTP als bij ADSL, wordt er van uitgegaan dat de derde versie van de DSL bonding proxy gebruikt wordt (zie 3.2.3). Een extra IP-header en een sequentienummer van 4 bytes zijn extra overhead die ook beschouwd moeten worden.
3.4.1
100Mbps UTP
Om de theoretisch haalbare bandbreedte op de Toepassingslaag (zie figuur 2.3 op pagina 7) te bekomen, dient er gekeken te worden naar de overhead die door al de gebruikte protocollen ge¨ıntroduceerd wordt, alsook de fysieke beperkingen van het medium. De gebruikte protocollen,
3.4 Studie theoretisch haalbare bandbreedte
53
alsook het standaard aantal bytes overhead die hun headers, CRC of preamble introduceren worden ge¨ıllustreerd in tabel 3.1.
Tabel 3.1: De protocollen die gebruikt worden bij het verbinden over een UTP kabel, en hun overhead.
Protocollaag
Protocol
Bytes overhead
Transportlaag
TCP of UDP
20 of 8 bytes(zie 2.5.8 en 2.5.7)
Netwerklaag
IP
20 bytes (zie 2.5.5)
Datalinklaag
Ethernet
14 bytes (zie 2.5.1)
Fysieke laag
CSMA/CD
12 bytes (zie 2.5.1)
Figuur 3.12: Illustratie van de Inter Frame Gap (IFG)
We dienen enkele aanpassingen te maken aan deze tabel om tegemoet te komen aan de specifieke eisen van onze DSL bonding proxy: De DSL-bonding proxy die we willen ontwerpen maakt gebruik van VLAN, waardoor 4 extra bytes overhead op het ethernet-niveau ge¨ıntroduceerd worden. Bij het testen van onze opstelling maken we gebruik van iperf[4]. Iperf maakt gebruik van de TCP-optie timestamp die een extra 12 bytes (10 bytes voor de timestamp en 2 bytes voor padding) in beslag neemt in de TCP header. Op de fysieke laag moet rekening gehouden worden met een Inter Frame Gap (IFG) van 96 bittijden. De IFG is de minimale afstand die zich tussen de laatste bit van de FCS (zie 2.5.1) van het laatste ethernet-datagram en de eerste bit van de preamble van het volgende ethernet-datagram moet bevinden. Indien ethernet-datagrammen een kleinere onderlinge afstand bezitten, worden ze genegeerd. Figuur 3.12 geeft een illustratie van de IFG. We introduceren ook de tweede IP-header en het sequentienummer, de overhead die door onze transparante proxy ge¨ıntroduceerd wordt. Tabel 3.2 geeft een overzicht van de uiteindelijke overhead-waarden. We beschouwen nu de verschillende gevallen voor TCP en UDP apart.
3.4 Studie theoretisch haalbare bandbreedte
54
Tabel 3.2: Uiteindelijke tabel met de protocollen die gebruikt worden bij het verbinden over een UTP kabel, en hun overhead.
3.4.1.1
Protocollaag
Protocol
Bytes overhead
Transportlaag
TCP of UDP
32 of 8 bytes
Netwerklaag
IP1
20 bytes
Netwerklaag
IP2
20 bytes
Netwerklaag
Sequentie
4 bytes
Datalinklaag
Ethernet
14 bytes
Datalinklaag
VLAN
4 bytes
Fysieke laag
CSMA/CD
12 bytes
Fysieke laag
UTP
12 bytetijden (IFG)
UDP
UDP is een stateless protocol (zie 2.5.7). Het protocol vraagt en krijgt nooit een confirmatie van de ontvangst van de verstuurde gegevens. Om de beste performantie te bekomen beschouwen we IP pakketten van 1500 bytes, de maximale grootte van IP-pakketten binnen ethernetdatagrammen. Een IP-pakket van 1500 bytes heeft 1448 bytes aan UDP-payload. Dit pakket vraagt in totaal: 1448 + 8 + 20 + 20 + 4 + 14 + 4 + 12 + 12 = 1542
(3.1)
bytes aan bandbreedte op een UTP-netwerk, een effici¨entie van: 1448 = 93, 9% 1542
(3.2)
UDP-verkeer over een 100Mbps UTP-kabel kan dus een maximale bandbreedte halen van 93,9Mbps.
3.4.1.2
TCP
Het TCP-protocol vraagt een bevestiging voor de ontvangst van verstuurde gegevens (zie 2.5.8). We beschouwen een TCP-verbinding met receive en congestion windows die groot genoeg zijn om de nodige snelheden ononderbroken te behalen. Ook hier beschouwen we IP pakketten van 1500 bytes groot. Een IP-pakket van 1500 bytes heeft 1424 bytes aan TCP-payload. Dit pakket vraagt in totaal: 1424 + 32 + 20 + 20 + 4 + 14 + 4 + 12 + 12 = 1542
(3.3)
3.4 Studie theoretisch haalbare bandbreedte
55
bytes aan bandbreedte op een UTP-netwerk, een effici¨entie van: 1424 = 92, 3% 1542
(3.4)
TCP-verkeer over een 100Mbps UTP-kabel kan dus een maximale bandbreedte hebben van 92,3Mbps. Formule 2.2 op pagina 24 geeft ons de maximale verliesrate die we mogen hebben, opdat een TCP verbinding deze bandbreedte gemiddeld kan halen. Wanneer we rekening houden met een RTT van 8ms, dan bekomen we: 92300000 =
1, 22 ∗ 1424 √ 0, 008 ∗ L
√ L = 0, 00235 L = 5, 54 ∗ 10−6 Dit betekent dat, opdat een TCP verbinding 92,3 Mbps zou halen, er gemiddeld gezien per 100 000 000 verzonden pakketten minder dan 554 pakketten verloren gegaan mogen worden.
3.4.2
ADSL
Ook hier zijn we ge¨ınteresseerd in de bandbreedte op de Toepassingslaag (zie figuur 2.3). De ADSL-standaard die in de opstelling gebruikt wordt, is G.992.3 of ADSL2plus (zie tabel 2.1 op pagina 3). De modem synchroniseert met een bandbreedte van 22Mbps down/1Mbps up. De modem is verbonden via een PPPoE-verbinding. Dit vraagt encapsulatie van de data door middel van verschillende protocollen op de Datalinklaag. Deze protocollen, alsook de protocollen van de netwerk- en transportlaag en hun overhead, zijn ge¨ıllustreerd in tabel 3.3[28]. De extra IP header en sequentie zijn hier ook toegevoegd. CSMA/CD (Preamble, SOF, FCS) wordt bij ADSL niet gebruikt, waardoor de overhead voor ethernet beperkt blijft tot 14 bytes. Hier dient ook geen rekening gehouden te worden met VLAN. In de opstelling wordt er enkel VLAN gebruikt om de Click-router aan client-zijde via de switch met de modems te verbinden. De protocol-overhead hangt duidelijk af van de grootte van het IP-pakket. Het is belangrijk om te trachten de AAL5-padding zo laag mogelijk te houden. Het zal dus niet noodzakelijk zo zijn dat de grootste pakketgroottes tot de grootst mogelijke performantie leiden. De AAL5padding zorgt ervoor dat ATM-cellen (zie 2.5.4) steeds volledig gevuld zijn. De maximale IP pakketgrootte is bij PPPoE gelimiteerd tot 1492 bytes. Er gaan 8 bytes verloren aan de PPPen PPPoE-header. We beschouwen de verschillende gevallen voor TCP en UDP apart.
3.4 Studie theoretisch haalbare bandbreedte
56
Tabel 3.3: De protocollen die gebruikt worden bij PPPoE.
3.4.2.1
Protocol
Overhead
TCP
32 bytes
UDP
8 bytes
IP1
20 bytes
IP2
20 bytes
Sequentie
4 bytes
PPP
2 bytes
PPPoE
6 bytes
Ethernet
14 bytes
RFC1483B of LLC/SNAP
10 bytes
AAL5
8 bytes + 0..47 bytes padding
ATM
5 bytes
UDP
Bij UDP heeft men zonder AAL5-padding en zonder ATM-header in totaal 8 + 20 + 20 + 4 + 2 + 6 + 14 + 10 + 8 = 92
(3.5)
bytes overhead per pakket. Een MTU van 1492 betekent een MSS van 1440 bytes. Dit geeft als totale pakketgrootte: 1440 + 8 + 20 + 20 + 4 + 2 + 6 + 14 + 10 + 8 = 1532
(3.6)
bytes. Dit geeft, samen met 4 bytes AAL5-padding 1536/48 = 32
(3.7)
ATM-cellen. Een MSS van 1440 bytes vraagt dus 32 ∗ 53 = 1696
(3.8)
bytes aan bandbreedte. Dit geeft een effici¨entie van: 1440/1696 = 84, 9%
(3.9)
3.4 Studie theoretisch haalbare bandbreedte
57
Ofwel: 18,7Mbps down/ 849kbps up. Wanneer we de MSS met 44 verminderen naar 1396 elimineren we de padding en past de data in 31 ATM-cellen. Dit geeft een effici¨entie van 1396/1643 = 85, 0%
(3.10)
Dit resulteert in een bandbreedte van 18,7Mbps down/ 850kbps up.
3.4.2.2
TCP
Voor TCP kunnen we dezelfde werkwijze volgen als voor UDP, met als verschil dat we nu rekening dienen te houden met een grotere header op de Transportlaag, alsook een verminderde MSS. Aangezien de TCP-header 24 bytes extra bezit, is de MSS nu slechts 1416 bytes. De totale datagram-grootte zonder padding is
1416 + 32 + 20 + 20 + 4 + 2 + 6 + 14 + 10 + 8 = 1532
(3.11)
bytes. Dit geeft, samen met 4 bytes AAL5-padding 1536/48 = 32
(3.12)
1416/(32 ∗ 53) = 83, 5%
(3.13)
ATM-cellen. Dit geeft een effici¨entie van
Ofwel: 18,4Mbps down/ 835kbps up. Wanneer we de MSS met 44 verminderen naar 1372, elimineren we padding en bekomen we een effici¨entie van 1372/1643 = 83, 5% Dit resulteert in een bandbreedte van 18,4Mbps down/ 835kbps up.
(3.14)
RESULTATEN
58
Hoofdstuk 4
Resultaten Al de UDP testen hebben een duurtijd van 30 seconden. Al de TCP testen hebben een duurtijd van 120 seconden. In eerste instantie gaan we de opstelling van transparante DSL bonding uitproberen zonder aan herordening van de pakketten te doen. Hiervoor vervangen we de eigen geschreven scheduler door een RoundRobinSched. Eerst testen we met UDP, omdat we daar makkelijk kunnen meten hoeveel pakketten er verloren gaan en hoeveel pakketten er in verkeerde volgorde toekomen. Hierna kijken we welke TCP-bandbreedte er te halen valt. Vervolgens bekijken we tweede versie transparante DSL bonding proxy, die gebaseerd is het sorteren van pakketten door middel van een timestamp. Uiteindelijk testen we onze eigen ontwikkelde oplossing op basis van sequentienummers. Zoals reeds eerder berekend in 3.4.2, is de MSS voor UDP 1440 en voor TCP 1416, behalve bij TimeSortedSched. Aangezien de timestamp 8 bytes in beslag neemt, 4 meer als een sequence, is de MSS daar 1436 voor UDP en 1412 voor TCP. Al deze testen zijn gemaakt met behulp van het programma Iperf.
4.1
RoundRobinSched
We gaan nu de Click-configuratie testen die te vinden zijn in B.4 en B.3, maar waarbij de eigen geschreven scheduler vervangen is door een RoundRobinSched. In deze configuratie worden de pakketten dus niet herordend.
4.1 RoundRobinSched
4.1.1
59
Download
4.1.1.1
UDP
Tabel 4.1: UDP RoundRobinSwitch Down
1 Modem
3 Modems
6 Modems
Verstuurd
Ontvangen
Out-of-
Ontvangen
Out-of-
Ontvangen
Out-of-
(Mbps)
(Mbps)
order
(Mbps)
order
(Mbps)
order
pakketten
pakketten
pakketten
10
10
5
10
37
10
35
20
18,7
22
20
387
20
677
40
18,6
33
40
10620
40
12243
60
18,6
33
55,7
87776
60
36038
80
18,6
43
55,7
87272
80
66298
90
18,5
42
55,7
85954
81
67701
95
18,5
38
55,7
87492
81
70310
Figuur 4.1: Deze afbeeldingen geven de evolutie van out-of-order pakketten en van de ontvangen bandbreedte bij gebruik van RoundRobin Downstream.
Zoals te zien in tabel 4.1 komen er erg veel pakketten in verkeerde volgorde toe bij het gebruik van meerdere modems. We verwachtten echter niet dat er bij gebruik van 1 modem pakketten in verkeerde volgorde zouden toekomen. De maximaal haalbare snelheid met 6 modems blijkt gelimiteerd te zijn tot 81 Mbps, wat een stuk onder onze theoretische berekeningen voor 1 UTP kabel ligt (zie 3.4.1). Voor 3 modems is de snelheid gelimiteerd tot 55,7 Mbps, en voor 1 modem tot 18,5 Mbps.
4.1 RoundRobinSched
4.1.1.2
60
TCP
Tabel 4.2: TCP bandbreedte.
Aantal modems
bandbreedte (Mbps)
1 Modem
18,2
2 Modems
32,2
3 Modems
35
4 Modems
39,9
5 Modems
46,7
6 Modems
55,9
Figuur 4.2: Deze afbeeldingen geeft de downstream TCP-bandbreedte voor RoundRobin.
We merken dat de snelheid van TCP slecht meeschaalt bij verhoging van het aantal modems. We zagen bij UDP dat vele pakketten in verkeerde volgorde toekomen. Aangezien TCP een slechte performantie haalt wanneer veel pakketten in verkeerde volgorde toekomen, vermoeden we dat dit de oorzaak is van de slechte TCP-performantie.
4.1.2 4.1.2.1
Upload UDP
Ook bij de upload merken dat er weer veel pakketten in verkeerde volgorde toekomen (tabel 4.3). Bij gebruik van ´e´en modem komen de pakketten deze keer in de juiste volgorde toe. Het aantal pakketten dat in de verkeerde volgorde toekomt is bij upload kleiner dan bij download. Dit is het gevolg van de kleinere upload-bandbreedte.
4.2 TimeSortedSched
61
Tabel 4.3: UDP RoundRobinSwitch Up
1 Modem
3 Modems
6 Modems
Verstuurd
Ontvangen
Out-of-
Ontvangen
Out-of-
Ontvangen
Out-of-
(kbps)
(kbps)
order
(kbps)
order
(kbps)
order
pakketten
pakketten
pakketten
1000
848
0
1000
0
1000
0
2000
849
0
2000
1
2000
1
3000
849
0
2529
2144
3000
2
4000
849
0
2547
2805
4000
1
5000
849
0
2547
2510
5000
31
10000
849
0
2546
2310
5059
6256
40000
849
0
2547
393
5058
3240
90000
849
0
2547
1748
5076
3752
Figuur 4.3: Deze afbeeldingen geven de evolutie van out-of-order pakketten en van de ontvangen bandbreedte bij gebruik van RoundRobin Upstream.
4.1.2.2
TCP
Zoals we kunnen zien in tabel 4.4 heeft TCP minder moeite met opschalen bij de lage uploadbandbreedtes.
4.2
TimeSortedSched
We hebben gemerkt dat pakketten bij gebruik van meerdere modems vaak in de verkeerde volgorde toekomen. Om aan reordering van pakketten te doen, wordt een systeem op basis van
4.2 TimeSortedSched
62
Tabel 4.4: TCP bandbreedte.
Aantal modems
bandbreedte (kbps)
1 Modem
839
2 Modems
1664
3 Modems
2506
4 Modems
3339
5 Modems
4162
6 Modems
4747
Figuur 4.4: Deze afbeeldingen geeft de upstream TCP-bandbreedte voor RoundRobin.
Timestamp voorgesteld (zie 3.2.2). Dit systeem biedt in matige vorm reordering van pakketten. Al de testen maken gebruik van 3 modems.
4.2.1 4.2.1.1
Download UDP
Zoals we kunnen zien in tabel 4.5 blijkt de transparante DSL bonding op basis van een Timestamp niet goed te zijn in het herordenen van de pakketten, met vaak zelf slechtere waarden als bij het systeem dat niet aan herordening van de pakketten doet.
4.2.1.2
TCP
Bij gebruik van drie modems biedt TimesortedSched een TCP bandbreedte van 31 Mbps
4.2 TimeSortedSched
63
Tabel 4.5: UDP TimesortedSched down
Verstuurd (Mbps)
Ontvangen (Mbps)
out-of-order
10
10
33
20
20
417
40
40
10882
60
55,9
86436
80
55,9
84480
90
55,9
85320
95
55,9
88470
Figuur 4.5: Deze afbeeldingen geven de evolutie van out-of-order pakketten en van de ontvangen bandbreedte bij gebruik van Timestamp Downstream.
Figuur 4.6: Deze afbeeldingen geeft de up- en downstream TCP-bandbreedte voor TimeSortedSched.
. Gezien de hoeveelheid pakketten die in de verkeerde volgorde toekomen, is het niet verwonderlijk dat ook hier de downloadsnelheid van TCP vrij pover is.
4.2 TimeSortedSched
4.2.2 4.2.2.1
64
Upload UDP
Tabel 4.6: UDP TimesortedSched up
Verstuurd (kbps)
Ontvangen (kbps)
out-of-order
1000
1000
0
2000
2000
1
3000
2539
2087
4000
2539
2919
5000
2523
2513
10000
2523
2136
40000
2522
1082
90000
2534
1283
Figuur 4.7: Deze afbeeldingen geven de evolutie van out-of-order pakketten en van de ontvangen bandbreedte bij gebruik van Timestamp Upstream.
Tabel 4.6 leert ons dat er ook veel pakketten ongeordend blijven bij upload. Ook hier faalt de transparante DSL bonding-proxy om een beter resultaat neer te zetten dan wanneer er geen gebruik wordt gemaakt van herordening.
4.2.2.2
TCP
Bij gebruik van drie modems biedt TimesortedSched een TCP bandbreedte van
2391 kbps
4.3 SequenceSortedSched
65
. We besluiten dus dat de DSL bonding proxy op basis van een timestamp geen merkbare verbetering brengt ten opzichte van het niet gebruiken van herordening van de pakketten. Zoals reeds gezien in 3.2.2.3 zal TimeSortedSched enkel reordenen wanneer er zich pakketten aan beide inputs bevinden. TimeSortedSched houdt ook niet bij welke pakketten hij reeds verstuurd heeft, waardoor de scheduler niet kan weten of hij al dan niet op een laat pakket dient te wachten.
4.3
SequenceSortedSched
De transparante DSL bonding proxy die herordent op basis van een sequentienummer, zou aanzienlijk minder pakketten in verkeerde volgorde moeten doorsturen. We gaan dit nu toetsen met de nodige testen.
4.3.1 4.3.1.1
Download UDP
Tabel 4.7: UDP bandbreedte.
Ontvangen (Mbps) Verstuurd (Mbps)
1 Modem
2 Modems
3 Modems
4 Modems
5 Modems
6 Modems
10
10
10
10
10
10
10
20
18,7
20
20
20
20
20
40
18,5
37,3
40
40
40
40
60
18,7
37,2
55,8
60
60
60
80
18,7
37,2
55,4
74,3
80
80
90
18,7
37,2
55,5
74,5
81,8
80,7
95
18,5
37,2
55,8
74,5
82,4
81,6
In tabel 4.7 is het aantal pakketten dat in de verkeerde volgorde toekomt niet opgenomen. Bij elk getest aantal modems bleek dat er tijdens de transmissie geen enkel pakket in de verkeerde volgorde toekwam. Bij het afsluiten van de verbinding gaf Iperf wel aan dat er systematisch bij het be¨eindigen van een verbinding ´e´en pakket in de verkeerde volgorde toekomt, ongeacht het aantal modems. We merken in ieder geval een grote verbetering ten opzicht van de twee bonding proxies die reeds getest waren. Ook hier blijkt dat de maximaal bereikbare bandbreedte rond
4.3 SequenceSortedSched
66
Figuur 4.8: UDP bandbreedte downstream SequenceSortedSched.
de 81-82 Mbps ligt. Wanneer er met UDP getest wordt met stromen van 81-82 Mbps, blijkt de buffer die zich juist voor de verzendende netwerkkaart aan de LAN-kant bevindt, over te lopen. Click blijkt dus niet in staat meer bandbreedte door een 100 Mbps netwerkkaart te sturen. SequenceSortedSched blijkt geen bottleneck te zijn. De bezetting van de interne ringbuffer blijft meestal vrij laag, in de grootteordes van minder dan 10 pakketten, met enkele uitschieters naar 800 pakketten. De grootte van de ringbuffer is 30000 pakketten. Er worden dan ook geen pakketten gedropt door een overbelaste scheduler.
4.3.1.2
TCP
Tabel 4.8: TCP bandbreedte.
Aantal modems
bandbreedte (Mbps)
1 Modem
16,1
2 Modems
31,3
3 Modems
46,1
4 Modems
62,2
5 Modems
80
6 Modems
80
Zoals te verwachten was bij de analyse van het UDP-verkeer, blijkt TCP nu wel goed mee te schalen, zoals te zien in tabel 4.8. Het feit dat er geen pakketten meer in de verkeerde volgorde toekomen zal de grootste oorzaak zijn tot het behalen van deze TCP-bandbreedtes.
4.3 SequenceSortedSched
67
Figuur 4.9: TCP bandbreedte downstream SequenceSortedSched.
4.3.2
Upload
4.3.2.1
UDP
Tabel 4.9: UDP bandbreedte.
Ontvangen (kbps) Verstuurd (kbps)
1 Modem
2 Modems
3 Modems
4 Modems
5 Modems
6 Modems
1000
847
1000
1000
1000
1000
1000
2000
846
1694
2000
2000
2000
2000
3000
845
1696
2539
3000
3000
3000
4000
841
1682
2548
3387
4000
4000
5000
842
1693
2544
3386
4232
5000
10000
840
1693
2521
3362
4231
5051
40000
840
1683
2521
3362
4202
5042
90000
810
1682
2540
3387
4233
5043
Figuur 4.10: UDP bandbreedte upstream SequenceSortedSched.
4.3 SequenceSortedSched
68
De UDP-upload vertelt ons weer hetzelfde verhaal als de UDP-downloads: er komen geen pakketten in verkeerde volgorde toe, zoals ge¨ıllustreerd in tabel 4.9.
4.3.2.2
TCP
Tabel 4.10: TCP bandbreedte.
Aantal modems
bandbreedte (Mbps)
1 Modem
805
2 Modems
1625
3 Modems
2437
4 Modems
3313
5 Modems
4015
6 Modems
4894
Figuur 4.11: TCP bandbreedte upstream SequenceSortedSched.
Tabel 4.10 bevestigt onze vermoedens: UDP schaalt goed mee met het verhogen van het aantal modems. Dit zal weer het gevolg zijn van het feit dat er geen pakketten meer in de verkeerde volgorde toekomen.
4.3.3
Zonder modems
De scheduler werd ook zonder modems getest, direct over 1 UTP-kabel, met 1 tot 5 VLANs om parallelle lijnen te simuleren. Uit tabel 4.11 leiden we af dat de scheduler geen hinder ondervindt van het opschalen van het aantal lijnen. De maximale snelheden van 80 Mbps voor TCP en 82 Mbps voor UDP komen ook hier terug.
4.4 Besluit
69
Tabel 4.11: UTP bandbreedte SequenceSortedSched
Aantal
bandbreedte TCP
bandbreedte TCP
bandbreedte
bandbreedte UDP
VLANs
up (Mbps)
down (Mbps)
UDP up (Mbps)
down (Mbps)
1 VLAN
80
80
82
82
2 VLANs
80
80
82
82
3 VLANs
80
80
82
82
4 VLANs
80
80
82
82
5 VLANs
80
80
82
82
4.4
Besluit
Het is duidelijk dat er aan degelijke herordening van de pakketten moet gedaan worden. Zowel wanneer er niet aan herordening gedaan wordt, als wanneer aan herordening op basis van timestamp gedaan wordt, blijkt het aantal pakketten in verkeerde volgorde in hoge mate aanwezig. Uit de testen is ook gebleken dat de transparante DSL bonding proxy op basis van een timestamp geen adequate oplossing biedt voor het herordenen van de pakketten, vandaar dat er een nieuwe oplossing op basis van sequentienummers is ontwikkeld. We hebben overal gemerkt dat het niet mogelijk is om meer dan 82 Mbps UDP of 80 Mbps TCP te halen via de verschillende versies transparante DSL bonding proxy. Dit zijn precies de grenzen die ook werd tegengekomen werden bij het testen van de SequenceSortedSched over ethernet, zonder modems. Wanneer we de resultaten over UTP, zonder modems, bekijken, vermoeden we dat de scheduler niet de bottleneck kan zijn. De Click modular router is geoptimaliseerd voor het gebruik in combinatie met polling drivers. Wij hebben er geen gebruik van gemaakt. Het kan dus zijn dat de Click modular router geen hogere performantie op 100Mbps UTP kan halen zonder polling drivers. Het overschakelen naar een gigabit-netwerk kan hier eventueel uitsluitsel over geven.
BESLUIT
70
Hoofdstuk 5
Besluit Nieuwe internettoepassingen worden vaak gelimiteerd door de aanwezige bandbreedte bij de eindgebruiker. Om meer bandbreedte aan de eindgebruiker te bieden, dient er vaak ge¨ınvesteerd te worden in nieuwe infrastructuur die snellere breedbandlijnen aanbiedt. Deze kosten worden doorgerekend aan de klant, waardoor snelle lijnen moeilijk toegang vinden bij particulieren of KMO’s. Om kosten te drukken, kunnen KMO’s best zo veel mogelijk activiteiten die geen kernactiviteit vormen, uit te besteden aan andere bedrijven. Een activiteit die mogelijk uitbesteed kan worden, is de backup van al de bedrijfskritieke data. Traditionele breedbandlijnen bieden hier niet de nodige capaciteit voor. Snellere lijnen zijn vaak te duur om aan te schaffen. In dit boek wordt een systeem ontwikkeld die de bandbreedte bij de eindgebruiker aanzienlijk verhoogt, terwijl er, door middel van het bundelen van verschillende goedkope DSL lijnen, gebruik kan gemaakt worden van de bestaande breedbandinfrastructuur. De TCP- en UDPprotocollen zijn ontworpen met de achtergrondgedachte dat ´e´en TCP- of UDP- stroom van pakketten over ´e´en enkele lijn verzonden wordt. De nodige maatregelen dienen genomen te worden om de optimale werking van TCP en UDP te garanderen. Zo zal TCP hinder ondervinden van zowel verloren gegane netwerkpakketten als netwerkpakketten die in de verkeerde volgorde toekomen. Alhoewel het UDP-protocol geen garanties biedt voor het toekomen van de verstuurde data, noch voor het toekomen van de pakketten in de juiste volgorde, zullen applicaties die UDP gebruiken om te communiceren, vaak wel hinder ondervinden wanneer veel pakketten in de verkeerde volgorde toekomen. Bij het ontwerp van de transparante DSL bonding proxy werd dan ook rekening gehouden met deze gevaren. Er worden meerdere transparante DSL bonding proxies ontworpen en ge¨ımplementeerd, die elk
BESLUIT
71
de netwerkpakketten over de verschillende DSL lijnen verdelen. Elk van deze proxy oplossingen maakt gebruik van een netwerktunnel. Het begin- en eindpunt van de tunnel is een Click-router die de pakketten over de verschillende lijnen verdeelt, en bij aankomst weer bijeen brengt. Een eerste ontwerp maakt gebruik van NAT, maar kent vele nadelen. Zo worden de pakketten niet herordend wanneer ze in een verkeerde volgorde toekomen, is het systeem niet transparant, en kan er maar ´e´en client-server verbinding tegelijk actief zijn. Om komaf te maken met deze nadelen, werd een tweede systeem ontworpen dat gebruik maakt van IP tunnels om het verkeer tussen de verschillende Click-routers te routeren. Aan elk pakket wordt ook een timestamp toegevoegd, dat vervolgens gebruikt kan worden om toekomende pakketten weer in de juiste volgorde te plaatsen. Aangezien het onmogelijk is om te voorspellen hoeveel pakketten er tussen twee tijdstippen verstuurd werden, kan dit systeem ook onmogelijk al de pakketten perfect herordenen. Uiteindelijk werd een nieuw systeem ontwikkeld dat gebruik maakt van IP-tunnels en aan elk pakket een sequentienummer bijvoegt. Op deze manier kan een bonding proxy perfect voorspellen op welke pakketten hij moet wachten. Pakketten kunnen echter ook om diverse redenen gedropt worden tussen beide Click-routers. De moeilijkheid bestaat er nu in om robuuste regels te ontwerpen die snel kunnen beslissen of een pakket vertraagd of gedropt is. Deze regels worden ge¨ımplementeerd in het eigen geschreven Click element SequenceSortedSched. Van dit element werden meerdere versies gemaakt met elk een verschillend stel regels om timeouts te bepalen. Er werden daarnaast nog verschillende elementen ge¨ımplementeerd voor VLAN-afhandeling, toekenning van een sequentie, opslaan van een sequentie in een pakket en om een sequentie of een timestamp uit de data van een pakket halen. Hierna werden de verschillende systemen uitvoerig getest. Door een click-configuratie te bouwen die aan DSL bonding doet zonder herordening, werd aangetoont dat herordening weldegelijk noodzakelijk is. Een groot deel van de pakketten komt immers in een verkeerde volgorde toe. De zelf ontworpen oplossingen werden ook uitvoerig getest, waardoor bleek dat het systeem dat aan herordening op basis van sequentienummers doet, degelijke prestaties aflevert en geen enkel pakket in de verkeerde volgorde doorstuurt. Alhoewel het systeem specifiek voor voor DSL bonding is ontwikkeld, is het breed inzetbaar op vele soorten netwerkverbindingen. Er is aangetoond dat het bundelen van verschillende DSL-lijnen mogelijk is, mits gebruik van de Click Modular Router Architectuur. Alhoewel de gehaalde snelheden erg goed zijn, is er nog steeds ruimte ter uitbreiding. Zo kunnen de identificatienummers van de externe IP headers
BESLUIT
72
gebruikt worden voor een betere timeout-detectie, kan failover ge¨ımplementeerd worden en kan het systeem nog verder getest worden op gigabitnetwerken met een veel groter aantal modems.
INSTALLATIE EN CONFIGURATIE
73
Bijlage A
Installatie en Configuratie A.1
Gebruikte opstelling
Het gebruikte materiaal: Een Alcatel Isam DSLAM D-LINK DES-3500 Layer 2 Managed Stackable Fast Ethernet Switch met 24 UTP en 22
Mini-GBIC combo poorten. 5 Thomson Speedtouch 585 ADSL2+ modems en 1 Thomson 620 ADSL2+ modems 5 servers: Artemis3
AMD Athlon 1 GHz
Client of server in Client-server verbinding
256 MiB RAM Artemis6
AMD Athlon XP 2400+
Click router aan Artemis3-kant
256 MiB RAM Artemis7
AMD Athlon XP 2400+
Click router aan Artemis12-kant
256 MiB RAM Artemis9
AMD Athlon64 3000+
BRAS-server
512 MiB RAM Artemis12
AMD K6-2 400 MHz
Client of server in Client-server verbinding
192 MiB RAM Al de servers draaien Debian 3.1 Sarge. De BRAS-server draait PPPoE-Server 3.5. Artemis6 en Artemis7 draaien de CVS-versie van 6 juli 2007 van Click[1], die een verdere ontwikkeling is van Click versie 1.5.0. Voor visualisatie van de Click configuraties werd gebruik gemaakt van
A.2 Installatie & Configuratie
74
ClickGUI[3]. De kernel-versies van de servers, alsook het IP-adres van de servers, switch en DSLAM binnen het controlenetwerk wordt gegeven door tabel A.1. Voor de performantietesten wordt er gebruik gemaakt van Iperf versie 2.02[4]. Tabel A.1: Kernel-versies en IP’s van het gebruikte materiaal.
Apparaat Artemis3 Artemis6 Artemis7 Artemis9 Artemis12 D-Link Isam
Kernel/Firmware 2.6.18.2 2.6.16.13 2.6.16.13 2.6.17.14 2.6.18.2 2.00-B19
IP 10.10.3.3 10.10.3.6 10.10.3.7 10.10.3.9 10.10.3.12 10.10.14.30 10.10.14.15
Figuur A.1: De opstelling op het testlab.
Een vereenvoudigd schema van de gebruikte opstelling is te zien in figuur A.1. Artemis3 is verbonden met Artemis6 via een crossed wire UTP kabel. Artemis6 is door middel van VLANs verbonden met de drie modems. De modems zijn verbonden met de DSLAM via gewone analoge telefoonkabels. De DSLAM is via een 1 Gbit fiber verbonden met de switch. De BRAS is via een gewone UTP kabel verbonden met de switch, en via een crossed wire UTP kabel met Artemis7. Artemis7 is vervolgens via een crossed wire UTP kabel verbonden met Artemis12. De IP-adressen die gebruikt worden in de opstelling zijn te vinden in de figuur.
A.2 A.2.1
Installatie & Configuratie Switch
Op de switch dienen de nodige VLANs aangemaakt worden. Als we er van uitgaan dat Artemis6 verbonden is op poort 2 en de modems op poorten 9,10 en 11, dan dienen volgende commando’s ingevoerd te worden:
A.2 Installatie & Configuratie
create config config create config config create config config
A.2.2
vlan vlan vlan vlan vlan vlan vlan vlan vlan
A62CPE1 A62CPE1 A62CPE1 A62CPE2 A62CPE2 A62CPE2 A62CPE3 A62CPE3 A62CPE3
tag add add tag add add tag add add
75
101 untagged 2 tagged 9 102 untagged 2 tagged 10 103 untagged 2 tagged 11
Artemis3
Artemis3 heeft niet veel configuratiewerk nodig. We wijzen het IP adres 10.0.2.2/24 toe aan de interface die verbonden is met de Click-router Artemis6: ifconfig eth1 10.0.2.2 netmask 255.255.255.0 Vervolgens vertellen we aan Artemis3 dat hij al het verkeer binnen het subnetwerk 10.0.2.0 via de click-router moet gaan: route add -net 10.0.2.0 netmask 255.255.255.0 gw 10.0.2.1 Om onze netwerktesten uit te voeren hebben we iperf nodig: apt-get update && apt-get install iperf We vergroten ook de maximum- en standaard-waarden voor de autotuning van de TCP-window. echo echo echo echo
16777216 > /proc/sys/net/core/rmem_max 16777216 > /proc/sys/net/core/wmem_max "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_rmem "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_wmem
A.2.3
Artemis12
De configuratie van Artemis12 is gelijkaardig aan die van Artemis3. Al het netwerkverkeer dient langs Click-router Artemis7 gestuurd te worden. Ook hier dienen we iperf te installeren en de TCP-window instellingen aan te passen. De commando’s zijn: ifconfig eth1 10.0.2.101 netmask 255.255.255.0 route add -net 10.0.2.0 netmask 255.255.255.0 gw 10.0.2.100 apt-get update && apt-get install iperf
A.2 Installatie & Configuratie
echo echo echo echo
76
16777216 > /proc/sys/net/core/rmem_max 16777216 > /proc/sys/net/core/wmem_max "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_rmem "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_wmem
A.2.4
Artemis7
Artemis7 doet dienst als Click-router. Click moet in kernelmode te draaien om een redelijke performantie te halen. Hiervoor dient een eigen kernel gecompileerd te worden, die vervolgens gepatcht moet worden met een patch die door Click geleverd wordt. Meer info is te vinden in de INSTALL-notes van Click. Eerst moet een compatibele kernel gedownload worden: apt-get update && apt-get install kernel-package ncurses-dev fakeroot wget bzip2 cd /usr/src wget http://www.eu.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.13.tar.bz2 tar xjf linux-2.6.16.13.tar.bz2 Vervolgens downloaden we Click en patchen we de kernel: cvs -d :pserver:
[email protected]:22401/git/click co -d click master cd linux-2.6.16.13 patch -p0 -b < /usr/src/click/etc/linux-2.6.16.13-patch De kernel kan nu geconfigureerd worden. We gebruiken het configuratiebestand van de huidige kernel: cp /boot/config-‘uname -r‘ ./.config make menuconfig Laad de configuratie .config, configureer de kernel en sluit het menu. Compileer nu de kernel: make-kpkg clean make-kpkg --initrd --append-to-version=-Click kernel_image kernel_headers Installeer de kernels na het compileren: cd .. dpkg -i linux-image-2.6.16.13-Click.deb dpkg -i linux-headers-2.6.16.13-Click.deb
A.2 Installatie & Configuratie
77
Kopi¨eer nu al de .hh en .cc bestanden van de eigengemaakte Click elementen naar /usr/src/click/elements/local. Configureer en installeer daarna Click: cd /usr/src/click ./configure --enable-local --enable-analysis make && make install Herstart zodat de nieuwe kernel geladen is. Installeer nu het nodige configuratiebestand: click-install server.3.click
A.2.5
Artemis6
Artemis6 is net zoals Artemis7 een Click-router. Voordat we echter Click installeren, dienen we de modems te configureren. We dienen dus eerst VLANs aan te maken op Artemis6. Dit gaat als volgt: apt-get update && apt-get install vlan ifconfig eth0 0.0.0.0 vconfig add eth0.101 vconfig add eth0.102 vconfig add eth0.103 Nu kunnen de modems geconfigureerd worden. Zie hiervoor A.2.6. Na de configuratie van de modems kan Click ge¨ınstalleerd worden. Dit dient op dezelfde manier te gebeuren als bij Artemis7. Na het herstarten dient er wel een andere configuratie ingelezen te worden, namelijk: click-install client.3.click
A.2.6
modems
Via de webinterface op Home Network -> LocalNetworkInterface -> Configure kunnen de locale IP-gegevens gewijzigd worden. Modem1 moet als IP 192.168.1.254/30 krijgen, modem2 192.168.1.250/30 en modem3 192.168.1.246/30. Nadien dient via telnet ingelogd worden op elke modem. In het menu dient er gegaan te worden naar nat. Daar moet het commando mapadd ingevoerd te worden. De int is Internet, type is NAT, outside addr is het externe IP van de modem, inside addr is het IP van Artemis6 dat gebruikt wordt om met de modem te communiceren, protocol is ipip. De andere parameters mogen open gelaten worden. De instellingen worden bewaard via saveall.
SCHEMA’S VAN CLICK CONFIGURATIES
Bijlage B
Schema’s van Click configuraties
78
Figuur B.1: Dit is de Click config aan client-zijde voor de tweede versie transparante DSL bonding proxy op basis van timestamp bij gebruik van twee modems.
SCHEMA’S VAN CLICK CONFIGURATIES 79
Figuur B.2: Dit is de Click config aan server-zijde voor de tweede versie transparante DSL bonding proxy op basis van timestamp bij gebruik van twee modems.
SCHEMA’S VAN CLICK CONFIGURATIES 80
Figuur B.3: Dit is de Click config aan client-zijde voor de derde versie transparante DSL bonding proxy op basis van sequence bij gebruik van twee modems.
SCHEMA’S VAN CLICK CONFIGURATIES 81
Figuur B.4: Dit is de Click config aan server-zijde voor de derde versie transparante DSL bonding proxy op basis van sequence bij gebruik van twee modems.
SCHEMA’S VAN CLICK CONFIGURATIES 82
REFERENTIES
83
Referenties [1] Click CVS. http://www.read.cs.ucla.edu/click/cvs. [2] Click Elements. http://www.read.cs.ucla.edu/click/elements. [3] ClickGUI: The Click Graphical User Interface. http://clickgui.atlantis.ugent.be/. [4] Iperf. http://dast.nlanr.net/Projects/Iperf/. [5] The Click Modular Router. http://www.read.cs.ucla.edu/click/. [6] Wikipedia: Asymmetric Digital Subscriber Line. http://en.wikipedia.org/wiki/ADSL. [7] IEEE Standard for Local and metropolitan area networks, Virtual Bridged Local Area Networks. Technical report, IEEE Computer Society, 2005. [8] M. Allman, V. Paxson, and W. Stevens. TCP Congestion Control. IETF RFC-2581, http: // tools. ietf. org/ html/ rfc2581 , 1999. [9] F. Baker. Requirements for IP Version 4 Routers. IETF RFC-1812, http: // tools. ietf. org/ html/ rfc1812 , 1995. [10] J. Border, M. Kojo, J. Griner, G. Montenegro, and Z. Shelby.
Performance Enhan-
cing Proxies Intended to Mitigate Link-Related Degradations. IETF RFC-3135, http: // tools. ietf. org/ html/ rfc3135 , 2001. [11] J. D. Cavanaugh. Protocol Overhead in IP/ATM Networks. Technical report, Minnesota Supercomputer Center, Inc., 1994. [12] M. Chatel. Classical versus Transparent IP Proxies. IETF RFC-1919, http: // tools. ietf. org/ html/ rfc1919 , 1996.
REFERENTIES
84
[13] The ATM Forum. TELECOMMUNICATIONS PROTOCOLS, Asynchronous Transfer Mode (ATM). The ATM Forum, http: // www. tekelec. com/ ss7/ protocols/ atm-start. asp , 2000. [14] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing Encapsulation (GRE). IETF RFC-1701, http: // tools. ietf. org/ html/ rfc1701 , 1994. [15] W. Heylen. Experimentele evaluatie en karakterisatie van de effici¨entie van verschillende types DSL bonding. Master’s thesis, Departement PIH, Hogeschool West-Vlaanderen, 2005. [16] E. Kohler. The Click modular router. PhD thesis, Massachusetts Institute of Technology, 2000. [17] E. Kohler, R. Morris, C. Benjie, J. Jannotti, and M. F. Kaashoek. The Click modular router. ACM Transactions on Computer Systems, 18(3):263–297, 2000. [18] K. W. Kurose, J. F. en Ross. Computernetwerken: Een ’top-down’-benadering, 3e editie. Pearson, Addison Wesley, 2005. [19] P. Macaulay. DSL Physical Layer. ZDSL, http: // www. zdsl. com/ zdsl content/ DSL T02. pdf , 2005. [20] P. Macaulay and J. Southworth. DSL Standards Update. ZDSL, http: // www. zdsl. com/ zdsl content/ DSL S01. pdf , 2005. [21] C. Perkins. IP Encapsulation within IP. IETF RFC-2003, http: // tools. ietf. org/ html/ rfc2003. html , 1996. [22] J. Postel. User Datagram Protocol. IETF RFC-0768, http: // tools. ietf. org/ html/ rfc0768 , 1980. [23] J. Postel. Internet Control Protocol, DARPA Internet Program, protocol specification. IETF RFC-0792, http: // tools. ietf. org/ html/ rfc0792 , 1981. [24] J. Postel. Internet Protocol, DARPA Internet Program, protocol specification. IETF RFC0791, http: // tools. ietf. org/ html/ rfc0791 , 1981. [25] J. Postel. Transmission Control Protocol, DARPA Internet Program, protocol specification. IETF RFC-0793, http: // tools. ietf. org/ html/ rfc0793 , 1981.
REFERENTIES
85
[26] J. Postel and J. Reynolds. A Standard for the Transmission of IP Datagrams over IEEE 802 Networks. IETF RFC-1042, http: // tools. ietf. org/ html/ rfc1042 , 1988. [27] W. Simpson. The Point-to-Point Protocol (PPP). IETF RFC-1548, http: // tools. ietf. org/ html/ rfc1548 , 1993. [28] D. Van Aken. Encapsulation Overhead(s) in ADSL Access Networks. Technical report, Alcatel, 2000. [29] G. Young. Asymmetric Digital Subscriber Line Tutorial. DSL Forum, http: // www. dslforum. org/ learndsl/ ppt/ ADSL Slideshow07. ppt , 1997. [30] J. Zwiekhorst. met breedband in Belgi¨e, De jarretellen aan!
Diskidee, http: // www.
diskidee. be/ 2000/ 08/ 07/ de-jarretellen-aan-/ 1723/ , 2000.
