|
Dimensione: 112895
Commento:
|
Dimensione: 130221
Commento:
|
| Le cancellazioni sono segnalate in questo modo. | Le aggiunte sono segnalate in questo modo. |
| Linea 20: | Linea 20: |
| * collegamenti punto-punto (<i>point-to-point links</i>) * collegamento punto-multipunto (<i>point-to-multipoint links</i>) * reti multipunto-multipunto (<i>multipoint-to-multipoint clouds</i>) |
* collegamenti punto-punto (''point-to-point links'') * collegamento punto-multipunto (''point-to-multipoint links'') * reti multipunto-multipunto (''multipoint-to-multipoint clouds'') |
| Linea 28: | Linea 28: |
| Collegamenti '''''punto-a-punto''''' (<i>Point-to-point links</i>) garantiscono, tipicamente, una connessione Internet dove l'accesso non sia altrimenti disponibile. Ad un capo di tale collegamento verrà offerta la connessione ad Internet, mentre all'altro estremo Internet viene connessa. Per esenpio, una univesità può disporre di una connessione veloce di tipo frame relay o VSAT al centro del campus, ma non può permettersi lo stesso tipo di connessione per un edificio distaccato. Se l'edificio principale gode di una visuale libera verso il sito distaccato, una connessione punto-a-punto può essere impiegata per connettere assieme i due edifici. Con tale accorgimento, si puossono estendere come capapacità, od addirittura sostituire, i collegamenti di tipo telefonico già esistenti. Con antenne adatte e visuale libera, sono possibili collegamenti affidabili punto-a-punto anche oltre i trenta chilometri. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.1.png|| |
Collegamenti '''''punto-a-punto''''' (''Point-to-point links'') garantiscono, tipicamente, una connessione Internet dove l'accesso non sia altrimenti disponibile. Ad un capo di tale collegamento verrà offerta la connessione ad Internet, mentre all'altro estremo Internet viene connessa. Per esenpio, una univesità può disporre di una connessione veloce di tipo frame relay o VSAT al centro del campus, ma non può permettersi lo stesso tipo di connessione per un edificio distaccato. Se l'edificio principale gode di una visuale libera verso il sito distaccato, una connessione punto-a-punto può essere impiegata per connettere assieme i due edifici. Con tale accorgimento, si puossono estendere come capapacità, od addirittura sostituire, i collegamenti di tipo telefonico già esistenti. Con antenne adatte e visuale libera, sono possibili collegamenti affidabili punto-a-punto anche oltre i trenta chilometri. ||<:>attachment:figure-3.1-ita.png|| |
| Linea 41: | Linea 41: |
| ||<:>http://wiki.wndw.net/images/figures/en/figure-3.2.png|| | ||<:>attachment:figure-3.2-ita.png|| |
| Linea 50: | Linea 50: |
The third type of network layout is '''''multipoint-to-multipoint''''', which is also referred to as an '''''ad-hoc'''''or '''''mesh''''' network. In a multipoint-to-multipoint network, there is no central authority. Every node on the network carries the traffic of every other as needed, and all nodes communicate with each other directly. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.3.png|| ||<:>''Figure 3.3: A multipoint-to-multipoint mesh. Every point can reach each other at very high speed, or use the central VSAT connection to reach the Internet.''|| The benefit of this network layout is that even if none of the nodes are in range of a central access point, they can still communicate with each other. Good mesh network implementations are self-healing, in that they automatically detect routing problems and fix them as needed. Extending a mesh network is as simple as adding more nodes. If one of the nodes in the "cloud" happens to be an Internet gateway, then that connection can be shared among all of the clients. Two big disadvantages to this topology are increased complexity and lower performance. Security in such a network is also a concern, since every participant potentially carries the traffic of every other. Multipoint-to-multipoint networks tend to be complicated to troubleshoot, due to the large number of changing variables as nodes move around. Multipoint-to-multipoint clouds typically do not have the same capacity as point-to-point or point-to-multipoint networks, due to the additional overhead of managing the network routing and increased contention in the radio spectrum. Nevertheless, mesh networks are useful in many circumstances. We will see an example of how to build a multipoint-to-multipoint mesh network using a routing protocol called OLSR at the end of this chapter. === Use the technology that fits === All of these network designs can be used to complement each other in a large network, and can obviously make use of traditional wired networking techniques whenever possible. It is a common practice, for example, to use a long distance wireless link to provide Internet access to a remote location, and then set up an access point on the remote side to provide local access. One of the clients to this access point may also act as a mesh node, allowing the network to spread organically between laptop users who all ultimately use the original point-to-point link to access the Internet. Now that we have a clear idea of the way that wireless networks are typically arranged, we can begin to understand how communication is possible over such networks. == The logical network == Communication is only possible when the participants speak a common language. But once the communication becomes more complex than a simple ongoing broadcast, '''''protocol''''' becomes just as important as language. All of the people in an auditorium may speak English, but without a set of rules in place to establish who has the right to use the microphone, the communication of an individual's ideas to the entire room is nearly impossible. Now imagine an auditorium as big as the world, full of all of the computers that exist. Without a common set of communication protocols to regulate when and how each computer can speak, the Internet would be a chaotic mess where every machine tries to speak at once. '''''TCP/IP''''' refers to the suite of protocols that permit conversations to happen on the global Internet. By understanding TCP/IP, you can build networks that will scale to virtually any size, and will ultimately become part of the global Internet. === The TCP/IP model === Data networks are often described as being built on many layers. Each layer depends on the operation of all of the underlying layers before communication can take place, but only needs to exchange data with the layer above or beneath it. The TCP/IP model of networking describes five layers, as shown in this diagram: ||<:>http://wiki.wndw.net/images/figures/en/figure-3.4.png|| ||<:>''Figure 3.4: The TCP/IP networking model.''|| The previous section on network layouts described layer one: the '''''physical layer'''''. This is the physical medium over which communications take place. This can be a copper CAT5 cable, a fiber optic bundle, radio waves, or just about any other medium. The next layer up is referred to as the '''''data link layer'''''. Whenever two or more nodes share the same physical medium (for example, several computers plugged into a hub, or a room full of laptops all using the same radio channel) they use the data link layer to determine whose turn it is to transmit on the medium. Common examples of data link protocols are Ethernet, Token Ring, ATM, and the wireless networking protocols (802.11a/b/g). Communication on this layer is said to be '''''link local''''', since all nodes connected at this layer can communicate with each other directly. On networks modeled after Ethernet, nodes are referred to by their '''''MAC address''''', which is a unique 48 bit number assigned to every networking device when it is manufactured. Just above the data link layer is the '''''Internet layer'''''. For TCP/IP, this is the Internet Protocol ('''''IP'''''). At the Internet layer, packets can leave the link local network and be retransmitted on other networks. Routers perform this function on a network by having at least two network interfaces, one on each of the networks to be interconnected. Nodes on the Internet are reached by their globally unique '''''IP address'''''. Once Internet routing is possible, a method is needed to reach a particular service at a given IP address. This function is filled by the next layer, the '''''transport layer'''''. TCP and UDP are common examples of transport layer protocols. Some protocols at the transport layer (such as TCP) ensure that all of the data has arrived at the destination, and is reassembled and delivered to the next layer in the proper order. Finally, at the top of the pile we have the '''''application layer'''''. This is the layer that most network users are exposed to, and is the level at which human communication happens. HTTP, FTP, and SMTP are all application layer protocols. The human sits at the top of all of the layers, and needs little or no knowledge of the layers beneath to effectively use the network. One way to look at the TCP/IP model is to think of a person delivering a letter to an office building downtown. They first need to interact with the road itself (the physical layer), pay attention to other traffic on the road (the data link layer), turn at the proper place to connect to other roads and arrive at the correct address (the Internet layer), go to the proper floor and room number (the transport layer), and finally find the recipient or a receptionist who can take the letter from there (the application layer). The five layers can be easily remembered by using the mnemonic "'''P'''lease''' D'''on't''' L'''ook '''I'''n '''T'''he '''A'''ttic," which of course stands for "'''P'''hysical / '''D'''ata '''L'''ink / '''I'''nternet / '''T'''ransport / '''A'''pplication." == 802.11 wireless networks == Before packets can be forwarded and routed to the Internet, layers one (the physical) and two (the data link) need to be connected. Without link local connectivity, network nodes cannot talk to each other and route packets. To provide physical connectivity, wireless network devices must operate in the same part of the radio spectrum. As we saw in chapter two, this means that 802.11a radios will talk to 802.11a radios at around 5GHz, and 802.11b/g radios will talk to other 802.11b/g radios at around 2.4GHz. But an 802.11a device cannot interoperate with an 802.11b/g device, since they use completely different parts of the electromagnetic spectrum. More specifically, wireless cards must agree on a common channel. If one 802.11b radio card is set to channel 2 while another is set to channel 11, then the radios cannot communicate with each other. When two wireless cards are configured to use the same protocol on the same radio channel, then they are ready to negotiate data link layer connectivity. Each 802.11a/b/g device can operate in one of four possible modes: 1. '''''Master mode''''' (also called '''''AP''''' or '''''infrastructure mode''''') is used to create a service that looks like a traditional access point. The wireless card creates a network with a specified name (called the '''''SSID''''') and channel, and offers network services on it. While in master mode, wireless cards manage all communications related to the network (authenticating wireless clients, handling channel contention, repeating packets, etc.) Wireless cards in master mode can only communicate with cards that are associated with it in managed mode. 1. '''''Managed mode''''' is sometimes also referred to as '''''client''''' mode. Wireless cards in managed mode will join a network created by a master, and will automatically change their channel to match it. They then present any necessary credentials to the master, and if those credentials are accepted, they are said to be '''''associated''''' with the master. Managed mode cards do not communicate with each other directly, and will only communicate with an associated master. 1. '''''Ad-hoc mode''''' creates a multipoint-to-multipoint network where there is no single master node or AP. In ad-hoc mode, each wireless card communicates directly with its neighbors. Nodes must be in range of each other to communicate, and must agree on a network name and channel. 1. '''''Monitor mode''''' is used by some tools (such as Kismet, chapter six) to passively listen to all radio traffic on a given channel. When in monitor mode, wireless cards transmit no data. This is useful for analyzing problems on a wireless link or observing spectrum usage in the local area. Monitor mode is not used for normal communications. When implementing a point-to-point or point-to-multipoint link, one radio will typically operate in master mode, while the other(s) operate in managed mode. In a multipoint-to-multipoint mesh, the radios all operate in ad-hoc mode so that they can communicate with each other directly. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.5.png|| ||<:>''Figure 3.5: APs, Clients, and Ad-Hoc nodes.''|| It is important to keep these modes in mind when designing your network layout. Remember that managed mode clients cannot communicate with each other directly, so it is likely that you will want to run a high repeater site in master or ad-hoc mode. As we will see later in this chapter, ad-hoc is more flexible but has a number of performance issues as compared to using the master / managed modes. Now that your wireless cards are providing physical and data link connectivity, they are ready to start passing around packets on layer 3: the internetworking layer. == Internet networking == IP addresses, network addressing, routing, and forwarding are important and related concepts in Internet networking. An '''''IP address''''' is an identifier for a network node such as a PC, server, router, or bridge. '''''Network addressing''''' is the system used to assign these identifiers in convenient groups. '''''Routing''''' keeps track of where in the network these groups may be found. The results of the routing process is kept in a list called a '''''routing table'''''. '''''Forwarding''''' is the action of using the routing table to send a data packet to either the final destination or to the "next hop" which is closer to the destination. === IP addresses === In an IP network, the address is a 32-bit number, normally written as four 8-bit numbers expressed in decimal form, separated by periods. Examples of IP addresses are 10.0.17.1, 192.168.1.1, or 172.16.5.23. === Network addressing === Interconnected networks must agree on an IP addressing plan. In the global Internet, committees of people allocate groups of IP addresses with a consistent, coherent method to ensure that duplicate addresses are not used by different networks and so that a shorthand can be used to refer to groups of addresses. These groups of addresses are called sub-networks, or '''''subnets '''''for short. Larger subnets can be further subdivided into smaller subnets. Sometimes a group of related addresses is referred to as an '''''address space'''''. On the Internet, no person or organization really owns these groups of addresses because the addresses only have meaning if the rest of the Internet community agrees with their usage. By agreement, the addresses are allocated to organizations according to their need and size. An organization which has been allocated an address range may then allocate a portion of that address range to another organization as part of a service agreement. Addresses which have been allocated in this manner, starting with internationally recognized committees, and then broken down hierarchically by national or smaller regional committees are referred to as '''''globally routed IP addresses'''''. Sometimes it is inconvenient or impossible to get more than one globally routed IP address allocated to an individual or organization. In this case a technique knows as Network Address Translation, or '''''NAT''''' can be used. A NAT device is a router with two network ports. The outside port uses one globally routed IP address, while the inside port uses an IP address from a special range known as '''''private addresses'''''. The NAT router allows the single global address to be shared with all of the inside users, who all use private addresses. It converts the packets from one form of addressing to the other as the packets pass through it. As far as the network users can tell, they are directly connected to the Internet and require no special software or drivers to share the single globally routed IP address. |
Il terzo tipo di configurazione di rete è quello '''''multipunto-multipunto''''', definito anche rete '''''ad-hoc''''' o '''''mesh'''''. In una rete multipunto-multipunto, non c'è un'autorità centrale. Ogni nodo sulla rete si prende carico del traffico di ogni altro nodo, secondo necessità, ed ogni nodo comunica direttamente con ogni altro. ||<:>attachment:figure-3.3.png|| ||<:>''Figura 3.3: una maglia (mesh) multipunto-multipunto. Ogni punto riesce a raggiungere ogni altro a velocità molto alta, così come può raggiungere Internet tramite il VSAT centrale.''|| I vantaggi di tale configurazione di rete risiedono nel fatto che, anche se nessuno dei nodi fosse in contatto con l'access point centrale, questi potrebbero comunque comunicare tra loro. Le realizzazioni a regola d'arte di reti mesh sono auto-riconfiguranti, nel senso che riescono a riconoscere automaticamente i problemi di routing e riescono a risolverli nel modo opportuno. Estendere una rete mesh è semplice come aggiungere nuovi nodi. Se uno dei nodi nella "nuvola" si trova ad essere un gateway (varco) verso Internet, allora l'accesso può essere condiviso tra tutti i client presenti. Due gravi svantaggi di tale tipologia sono la complessità crescente e la bassa prestazione. Anche la sicurezza, in una rete simile, rappresenta un serio problema, poichè ogni singolo partecipante può, potenzialmente, prendersi carico del traffico di ogni altro. Reti multipunto-multipunto tendono ad essere complicate nella diagnostica dei problemi, a causa del grande numero di variabili che insorgono quando i nodi cambiano di posizione. Le reti multipunto-multipunto, tipicamente, non dispongono della stessa capacità di reti punto-punto o punto-multipunto, a causa dell'overhead supplementare necessario per il routing della rete e della più serrata competizione per l'impiego dello spettro elettromagnetico. Tuttavia, le reti a maglia (mesh networks) sono utili in diverse situazioni. Alla fine di questo capitolo, vedremo un esempio di come rendere attiva una rete a maglia multipunto-multipunto impiegando un protocollo di routing chiamato OLSR. === Impiega la tecnologia che risolve il problema === Tutti questi progetti di rete possono essere usati per complementarsi a vicenda in una rete più grande, e possono ovviamente far uso delle tradizionali tecniche di una rete su cavo, ove possibile. Si fa infatti comunemente ricorso ad un collegamento wireless a lunga distanza per assicurare l'accesso Internet ad una postazione remota, impiegando poi un access pont su tale postazione per garantire l'accesso a livello locale. Uno dei client di questo access point può poi, a sua volta, comportarsi come nodo di maglia, permettendo alla rete di espandersi tra gli utenti dei laptop che, alla fine, usano tutti il collegamento punto-punto originale per aver accesso ad Internet. Ora che è stata fornita una chiara idea sul modo con cui vengono tipicamente impostate le reti wireless, si può iniziare a comprendere come sia possibile la comunicazione attraverso tali reti. == La rete logica == La comunicazione diventa realizzabile solo quando i partecipanti impiegano un linguaggio comune. Quando però la comunicazione diventa più complessa che una semplice radio-diffusione, il '''''protocollo''''' acquista un'importanza pari a quella del linguaggio. Tutte le persone in un auditorium possono parlare lo stesso Inglese, ma in assenza di regole per stabilire chi abbia diritto di prendere il microfono, la comunicazione delle idee di un singolo individuo all'intera platea diventa praticamente impossibile. Si immagini ora un auditorium che si estenda al mondo intero, ove siano compresi tutti i computer esistenti. Senza un insieme di protocolli di comunicazione comuni per regolare quando e come un computer possa prendere la parola, Internet sarebbe solo una disordinata confusione, dove tutte le macchina provano a parlare nello stesso momento. '''''TCP/IP''''' si riferisce alla suite di protocolli che permettono la realizzazione delle conversazioni sull'Internet globale. Se si comprende TCP/IP, si possono costruire reti in grado di crescere praticamente a qualsiasi dimensione, per arrivare a diventare parte, alla fine, dell'Internet globale. === Il modello TCP/IP === Le reti di dati sono spesso descritte come costituite su strati diversi. Ogni strato dipende dalle operazioni condotte da tutti gli strati sottostanti, prima che la comunicazione possa aver luogo, ma ogni strato scambia i dati solo con lo strato superiore o con quello inferiore ad esso. Il modello TCP/IP delle reti descrive cinque strati, come evidenziato dal diagramma sotto riportato: ||<:>attachment:figure-3.4-ita.png|| ||<:>''Figura 3.4: Il modello di rete TCP/IP.''|| La precedente sezione sulla configurazione della rete descriveva il primo strato: lo '''''strato fisico'''''. Si tratta del mezzo fisico sul quale la comunicazione ha luogo. Può essere un cavo di rame di tipo CAT5, un fascio di fibre ottiche, onde radio, od anche un altro mezzo. Lo strato soprastante è chiamato '''''strato data link'''''. Quando due o più nodi condividono lo stesso mezzo fisico (per esempio, diversi computer attestati ad un hub, od una sala piena di laptop che usano tutti lo stesso canale radio), essi usano lo strato data link per determinare a chi spetti trasmettere sul mezzo. Esempi comuni di protocolli di data link sono Ethernet, il Token Ring, l'ATM, ed i protocolli di rete wireless (802.11a/b/g). Le comunicazioni su questo strato sono definite '''''link locali''''', poichè tutti i nodi connessi su questo strato possono comunicare direttamente l'uno con l'altro. Sulle reti che assumono Ethernet come modello di riferimento, i nodi vengono distinti sulla base del proprio '''''indirizzo MAC''''', che è un numero univoco di 48 bit assegnato ad ogni periferica di rete dal suo costruttore. Appena sopra dallo strato data link c'è lo '''''strato Internet'''''. Per il TCP/IP, questo è detto Internet Protocol ('''''IP'''''). Sullo strato Internet, i pacchetti possono lasciare la rete del collegamento locale per essere ritrasmessi su altre reti. I router prendono in carico questa funzione su una rete, disponendo di almento due interfacce di rete, una per ogni rete che devono interconnettere. I nodi su Internet sono raggiungibili grazie al loro '''''IP address''''', che è globalmente unico. Diventato possibile il routing su Internet, si rende ora necessario raggiungere un particolare servizio disponibile presso un indirizzo IP dato. La funzione è soddisfatta dallo strato successivo, lo '''''strato di trasporto'''''. TCP ed UDP sono classici esempi di strati di trasporto. Alcuni protocolli dello strato di trasporto (come TCP) assicurano che tutti i dati arrivino a destinazione, siano riassemblati e quindi consegnati allo strato superiore, nell'ordine previsto. Alla fine, sulla cima della pila si trova lo '''''strato applicativo'''''. E' lo strato che si interfaccia con la maggior parte degli utenti della rete, ed è a livello di questo strato che avviene la comunicazione per le persone. HTTP, FTP e SMTP sono tutti protocolli dello strato applicativo. La persona si pone al di sopra di tutti questi strati, e non deve conoscere praticamente nulla di tutti gli strati sottostanti, per impiegare in modo efficace la rete. Un modo per riconoscere il modello TCP/IP può essere quello che prevede una persona che intenda consegnare una lettera ad un ufficio in un palazzo del centro. Occorre prima interagire con la stessa strada (lo strato fisico), prestare attenzione al traffico che altri conducono sulla strada (lo strato data-link), giungere al posto giusto per immettersi su altre strade ed arrivare all'indirizzo giusto (lo strato Internet), portarsi al piano giusto ed al corretto numero di stanza (lo strato di trasporto), e finalmente trovare il destinatario o un commesso che possa prendere in carico la lettera (lo strato applicativo). I cinque strati possono facilmente essere ricordati usando il trucco mnemonico "'''F'''orse '''D'''omani '''I'''ncontrerò '''T'''ue '''A'''miche", che naturalmente ricorda: " '''F'''isico / '''D'''ata-link / '''I'''nternet / '''T'''rasporto / '''A'''pplicativo." == reti wireless 802.11 == Prima che i pacchetti possano essere inoltrati ed instradati su Internet, il primo strato (quello fisico) ed il secondo (quello data link) devono essere connessi. Senza connessione sul collegamento locale, i nodi della rete non possono comunicare tra di loro, nè possono instradare pacchetti. Per garantire connessione fisica, le periferiche wireless devono operare nella stessa finestra dello spettro radio. Come si è visto nel capitolo 2, ciò significa che le radio 802.11a potranno comunicare con altre radio 802.11a sulla banda dei 5GHz, mentre le radio 802.11b/g comunicheranno con altre radio 802.11b/g sulla banda dei 2.4 GHz. Ma una periferica 802.11a non potrà colloquiare con una periferica 802.11b/g, poichè usano segmenti completamente diversi dello spettro elettromagnetico. In modo più specifico, le schede wireless devono accordarsi su un canale comune. Se una scheda radio 802.11b è impostata sul canale 2 mentre un'altra è impostata sul canale 11, le due radio non comunicheranno tra di loro. Quando due schede wireless sono configurate per impiegare lo stesso protocollo sullo stesso canale radio, sono allora pronte per negoziare la connettività sullo strato data link. Ogni periferica 802.11a/b/g può lavorare in uno dei quattro possibili modi: 1. '''''Master mode''''' (altrimenti chiamato '''''AP''''' or '''''modo infrastruttura''''') è usato per rendere disponibile un servizio simile ad un access point tradizionale. La scheda wireless crea una rete con un nominativo specifico (chiamato '''''SSID''''') ed un proprio canale, ed offre servizi di rete su questo. Posta in modo master, la carta wireless governa tutte le comunicazioni relative alla rete (autenticando i client wireless, gestendo le contese sul canale, ripetendo i pacchetti, etc.). Le schede wireless poste in modo master possono comunicare solo con altre schede che le siano associate in modalità ''managed'' (gestita). 1. '''''Managed mode''''' viene talvolta chiamato '''''client''''' mode. Le schede wireless poste in managed mode si aggregheranno a reti create da un master, e provvederanno automaticamente a reimpostare il proprio canale di lavoro per adeguarsi al canale del master. Provvederanno quindi a presentare ogni credenziale necessaria al master, e se queste credenziali saranno accettate, queste schede verranno definite '''''associate''''' (associated) al master. Le schede in Managed mode non comunicano direttamente tra di loro, ma comunicano solo con il master loro associato. 1. '''''Ad-hoc mode''''' crea reti multipunto-multipunto dove non è presente un signolo nodo master, od Access Point. Nel modo ad-hoc, ogni scheda wireless comunica direttamente con i propri vicini. I nodi devono essere nel raggio d'azione di ogni altro nodo corrispondente per comunicare, e devono accordarsi sul nome della rete e sul canale da impiegare. 1. '''''Monitor mode''''' è impiegato da alcuni strumenti (come Kismet, vedasi al capitolo sei) che ascoltano passivamente il traffico presente su un dato canale. Quando sono in Monitor Mode, le schede wireless non trasmettono dati. Tale caratteristica è importante per analizzare problemi su un collegamento wireless o per osservare l'impiego dello spettro elettromagnetico in una zona locale. Il Monitor Mode non è usate per le normali comunicazioni. Nella realizzazione di un collegamento punto-punto o punto-multipunto, una radio dovrà tipicamente operare in Master Mode, mentre le altre verranno poste in Managed Mode. In una rete multipunto-multipunto, le radio opereranno tutte in modalità ad-hoc, sì che possano comunicare direttamente una con le altre. ||<:>attachment:figure-3.5-ita.png|| ||<:>''Figura 3.5: Access Point, Client, e nodi Ad-Hoc.''|| E' importante mantenere queste modalità in mente quando si progettano le configurazioni di rete. Si ricordi come i client in Managed Mode non possano comunicare direttamente gli uni con gli altri, sì da rendere probabile l'impiego in un sito ripetitore a maggiore altezza che sia in Master Mode o Ad-Hoc Mode. Come si vedrà più avanti nel capitolo, il modo Ad-Hoc è più flessibile ma presenta maggiori problemi di prestazioni, rispetto al Master Mode ed al Managed Mode. Ora che le schede wireless garantiscono connettività sia nello strato fisico che in quello data-link, sono in grado di cominciare a trasferire i pacchetti sul terzo strato, lo strato internetworking. == reti Internet == Indirizzi IP, indirizzamento di rete, routing e forwarding sono tutti concetti importanti e correlati nell'ambito delle reti Internet. Un '''''indirizzo IP''''' è un identificatore per un nodo di rete quale un PC, un server, un router od un bridge. '''''Indirizzamento di Rete''''' è il sistema impiegato per assegnare tali identificatori raggruppandoli in gruppi significativi. Il '''''Routing''''' tiene traccia di dove questi gruppi possano essere trovati nella rete. Il risultato del processo di routing è mantenuto in una lista chiamata '''''tabella di routing'''''. Il '''''Forwarding''''' è l'azione di impiegare la tabella di routing per spedire un pacchetto dati o verso la sua destinazione finale, o verso "il prossimo salto" che lo avvicina alla destinazione. === Indirizzi IP === In una rete IP, l'indirizzo è un numero di 32 bit, normalmente scritto sotto forma di quattro numeri ad otto bit, separati da punti. Esempi di indirizzi IP sono 10.0.17.1, 192.168.1.1, o 172.16.5.23. === indirizzamento di rete === Reti interconnesse devono concordare un piano di indirizzamento IP. Nella Internet globale, commissioni di persone distribuiscono gruppi di indirizzi IP in modo coerente per assicurare che indirizzi duplicati non vengano usati da reti differenti, provvedendo altresì che ci si possa riferire in modo rapido a gruppi di indirizzi. Questi gruppi di indirizzi sono chiamati sotto-reti o '''''subnets ''''' come abbreviazione. Sottoreti più ampie possono essere ulteriormente suddivise in sottoreti minori. Talvolta, un gruppo di indirizzi collegati è chiamato Spazio di Indirizzi o '''''address space'''''. Su Internet, nessuna persona e nessuna organizzazione possiede effettivamente questi gruppi di indirizzi perchè gli indirizzi hanno significato solo se il resto della comunità di Internet concorda nel loro utilizzo. Per accordo, gli indirizzi sonon distribuiti alle organizzazioni sulla base dei loro bisogni e della loro dimensione. Un'organizzazione che abbia ricevuto un segmento di indirizzi potrebbe quindi assegnarne una porzione ad un'altra organizzazione, sulla base di un accordo di servizio. Indirizzi che vengono assegnati in questa maniera, partendo dalle commissioni internazionalmente riconosciute per poi essere via via spezzati gerarchicamente da comitati nazionali o regionali, sono detti '''''indirizzi IP globalmente instradati''''' (''lobally routed IP addresses''). A volte non è conveniente, se non impossibile, ottenere per un individuo od un'organizzazione più di un indirizzo IP globalmente instradato. In questo caso può essere impiegata una tecnica conosciuta come ''Network Address Translation'' (traduzione dell'indirizzo di rete), o '''''NAT'''''. Un dispositivo NAT è un router con due porte di rete. La porta esterna impiega un indirizzo IP globalmente instradato, mentre la porta interna usa un indirizzo IP appartenente ad un segmento particolare, chiamato '''''indirizzi privati'''''. Il router NAT permette al singolo indirizzo globale di essere condiviso da parte di tutti gli utenti interni, che impiegano indirizzi privati. Il router NAT converte i pacchetti da una forma di indirizzamento all'altra, quando i pacchetti lo attraversano. Gli utenti interni credono di essere direttamente connessi ad Internet e non richiedono nèoftware particolare, nè driver, per condividere il singolo indirizzo IP globale. |
| Linea 135: | Linea 141: |
| The Internet is constantly changing and growing. New networks are continually added, and links between networks are added and removed, fail and come back. It is the job of '''''routing''''' to determine the best path to the destination, and to create a routing table listing the best path for all the different destinations. '''''Static routing''''' is the term used when the routing table is created by manual configuration. This is sometimes convenient for small networks but can easily become very difficult and error prone for large networks. Worse, if the best path to a network becomes unusable because of equipment failure or other reasons, static routing will not make use of the next best path. '''''Dynamic routing''''' is a method in which network elements, in particular routers, exchange information about their state and the state of their neighbours in the network, and then use this information to automatically pick the best path and create the routing table. If something changes, such as a router failing or a new router being put into service, then the dynamic routing protocols make adjustments to the routing table. The system of packet exchanges and decision making is known as a '''''routing protocol'''''. There are many routing protocols that are used in the Internet today, including OSPF, BGP, RIP, and EIGRP. Wireless networks are like wired networks in that they need dynamic routing protocols, but they are also different enough from wired networks that they need different routing protocols. In particular, wired network connections typically work well or don't work at all (eg., either an Ethernet cable is plugged in, or it isn't). Things are not so clear when working with wireless networks. Wireless communication can be affected by objects moving into the path of the signal, or by interfering signals. Consequently, links may work well, or poorly, or vary between the two extremes. Since existing network protocols don't take the quality of a link into account when making routing decisions, the IEEE 802.11 committees and the IETF are working on standardizing protocols for wireless networks. It is currently unclear when a single standard for dealing with variable link quality will emerge. In the meantime, there are many ongoing ad-hoc programming attempts to address the problem. Some examples include '''''Hazy Sighted Link State''''' ('''''HSLS'''''), '''''Ad-hoc On-demand Distance Vector''''' ('''''AODV'''''), and '''''Optimized Link State Routing''''' ('''''OLSR'''''). Another is '''''SrcRR''''', a combination of DSR and ETX implemented by the M.I.T. Roofnet project. Later in this chapter we will see an example of how to implement a network using OLSR to make routing decisions. |
Internet cresce e cambia costantemente. Nuove reti sono aggiunte in continuazione, mentre i collegamenti tra le reti sono aggiunti, sono rimossi, cadono e vengono ripristinati. E' compito del '''''routing''''' determinare il percorso migliore verso la destinazione, e creare tabelle di routing che elenchino il percorso migliore per ogni possibile destinazione. '''''Routing Statico''''' è il termine usato per le tabelle di routing compilate a mano. E' talvolta conveniente per piccole reti, ma può facilmente diventare impraticabile e soggetto ad errori per reti di maggiore dimensione. Ancora peggio, se il percorso migliore verso una rete diventa inimpiegabile, per un'avaria hardware o per altre ragioni, il routing statico non farà uso del miglior percorso secondario. '''''Routing Dinamico''''' è una soluzione dove gli elementi di rete, in particolare i router, si scambiano reciprocamente informazioni sul loro stato e sullo stato dei propri vicini nella rete, e quindi usano queste informazioni per rilevare automaticamente il percorso migliore e per compilare la tabella di routing. Se ci sono cambiamenti, come un router che si blocca od un nuovo router che entra in azione, allora i protocolli di routing dinamico apportano aggiustamenti alle tabelle di routing. Il sistema di scambio dei pacchetti e la definizione delle decisioni è denominato '''''protocollo di routing'''''. Ci sono diversi protocolli di routing che sono usati oggi su Internet, tra cui OSPF, BGP, RIP, and EIGRP. Le reti wireless sono come le reti su cavo, per quanto riguarda la loro necessità di protocolli di routing, ma sono anche tanto differenti, da richiedere protocolli di routing diversi. In particolare, le connessioni su reti su cavo tipicamente o funzionano bene, o non funzionano affatto (in altre parole, un cavo Ethernet o è allacciato, o non lo è). La situazione non è così chiara quando si tratta di reti wireless. Le comunicazioni radio possono essere affette da oggetti che si muovono sul percorso del segnale, o da disturbi che interferiscono. Conseguentemente, i collegamenti possono funzionare bene, o male, o in modo sfumato tra i due estremi. Poichè i protocolli attuali non tengono in conto la qualità del collegamento nel definire le decisioni, i comitati IEEE 802.11 e l'IETF stanno lavorando sulla standardizzazione dei protocolli per le reti wireless. Al momento, non è ancora chiaro se si imporrà un singolo standard per affrontare la qualità variabile di un collegamento. Nel frattempo, sono in corso diversi tentativi di affrontare il problema. Alcuni esempi sono '''''Hazy Sighted Link State''''' ('''''HSLS'''''), '''''Ad-hoc On-demand Distance Vector''''' ('''''AODV'''''), e '''''Optimized Link State Routing''''' ('''''OLSR'''''). Un altro è '''''SrcRR''''', una combinazione del DSR e dell'ETX, realizzato dal progetto Roofnet del M.I.T. Più avanti, in questo capitolo, vedremo un esempio di come realizzare una rete usando OLSR per le decisioni di routing. |
| Linea 147: | Linea 154: |
| '''''Forwarding''''' is straightforward compared to addressing and routing. Each time a router receives a data packet, it consults its internal routing table. Starting with the high order (or most significant) bit, the routing table is searched for the entry that matches the most number of bits in the destination address. This is called the address '''''prefix'''''. If an entry with a matching prefix is found in the routing table, then the '''''hop count''''' or '''''time to live''''' ('''''TTL''''') field is decremented. If the result is zero, then the packet is dropped and an error packet is returned to the sender. Otherwise, the packet is sent to the node or interface specified in the routing table. For example, if the routing table contains these entries | Il '''''Forwarding''''' è diretto, in confronto con l'indirizzamento ed il routing. Ogni volta che riceve un pacchetto di dati, il router consulta la tabella di routing che possiede internamente. Partendo dal bit più significativo (o di maggior ordine), la tabella di routing viene scandita per ricercare il valore che corrisponda per il maggior numero di bit all'indirizzo di destinazione. Tale valore (il primo campo di ogni riga) è denominato il '''''prefisso''''' dell'indirizzo. Se viene trovato nella tabella di routing un prefisso che corrisponda, allora il '''''contatore dei salti''''' (''hop counter'') od il campo '''''time to live''''' ('''''TTL''''') è decrementato. Se il risultato è zero, allora il pacchetto viene lasciato cadere ed un pacchetto di segnalazione di errore viene rinviata al mittente. Altrimenti, il pacchetto viene inviato al nodo od alla interfaccia specificata nella tabella di routing. Come esempio, se la tabella di routing contiene questi valori... |
| Linea 157: | Linea 164: |
| ...and a packet arrives with the destination address of 10.15.6.23, then the router would send it out on interface eth1. If the packet has a destination of 10.15.6.108, then it would be forwarded to the gateway 10.15.6.7 (since it is more specific and matches more high-order bits than the 10.15.6.0 network route). A destination of 0.0.0.0 is a special convention referred to as the '''''default gateway'''''. If no other prefixes match the destination address, then the packet is sent to the default gateway. For example, if the destination address was 72.1.140.203, then the router would forward the packet to 216.231.38.1 (which would presumably send it closer to the ultimate destination, and so on). If a packet arrives and no entry is found (i.e., there is no default gateway defined and no prefix matches a known route), then the packet is dropped and an error packet is returned to the sender. The TTL field is used to detect routing loops. Without it, a packet could endlessly be sent back and forth between two routers who each list the other as the next best hop. These kinds of loops can cause so much unnecessary traffic on a network that they threaten its stability. Use of the TTL field doesn't fix routing loops, but it does help to prevent them from destroying a network due to simple misconfiguration. === Putting it all together === Once all network nodes have an IP address, they can send data packets to the IP address of any other node. Through the use of routing and forwarding, these packets can reach nodes on networks that are not physically connected to the originating node. This process describes much of what "happens" on the Internet. This is illustrated in the following figure: ||<:>http://wiki.wndw.net/images/figures/en/figure-3.6.png|| ||<:>''Figure 3.6: Internet networking. Each network segment has a router with two IP addresses, making it "link local" to two different networks. Packets are forwarded between routers until they reach their ultimate destination.''|| In this example, you can see the path that the packets take as Alice chats with Bob using an instant messaging service. Each dotted line represents an Ethernet cable, a wireless link, or any other kind of physical network. The cloud symbol is commonly used to stand in for "The Internet", and represents any number of intervening IP networks. Neither Alice nor Bob need to be concerned with how those networks operate, as long as the routers forward IP traffic towards the ultimate destination. If it weren't for Internet protocols and the cooperation of everyone on the net, this kind of communication would be impossible. Now that we have seen how packets flow on IP networks, let's look at a very specialized kind of IP network: an OLSR mesh. == Mesh networking with OLSR == Most WiFi networks operate in infrastructure mode - they consist of an access point somewhere (with a radio operating in master mode), attached to a DSL line or other large scale wired network. In such a '''''hotspot''''' the access point usually acts as a master station that is distributing Internet access to its clients, which operate in managed mode. This topology is similar to a mobile phone (GSM) service. Mobile phones connect to a base station - without the presence of such a base station mobiles can't communicate with each other. If you make a joke call to a friend that is sitting on the other side of the table, your phone sends data to the base station of your provider that may be a mile away - the base station then sends data back to the phone of your friend. WiFi cards in managed mode can't communicate directly, either. Clients - for example, two laptops on the same table - have to use the access point as a relay. Any traffic between clients connected to an access point has to be sent twice. If client A and C communicate, client A sends data to the access point B, and then the access point will retransmit the data to client C. A single transmission may have a speed of 600 kByte/sec (thats about the maximum speed you could achieve with 802.11b) in our example - thus, because the data has to be repeated by the access point before it reaches its target, the effective speed between both clients will be only 300 kByte/sec. In ad-hoc mode there is no hierarchical master-client relationship. Nodes can communicate directly as long as they are within the range of their wireless interfaces. Thus, in our example both computers could achieve full speed when operating ad-hoc, under ideal circumstances. The disadvantage to ad-hoc mode is that clients do not repeat traffic destined for other clients. In the access point example, if two clients A and C can't directly "see" each other with their wireless interfaces, they still can communicate as long as the AP is in the wireless range of both clients. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.7.png|| ||<:>''Figure 3.7: Access point B will relay traffic between clients A and C. In Ad-Hoc mode, node B will not relay traffic between A and C by default.''|| Ad-hoc nodes do not repeat by default, but they can effectively do the same if '''''routing''''' is applied. Mesh networks are based on the strategy that every mesh-enabled node acts as a relay to extend coverage of the wireless network. The more nodes, the better the radio coverage and range of the mesh cloud. There is one big tradeoff that must be mentioned at this point. If the device only uses one radio interface, the available bandwidth is significantly reduced every time traffic is repeated by intermediate nodes on the way from A to B. Also, there will be interference in transmission due to nodes sharing the same channel. Thus, cheap ad-hoc mesh networks can provide good radio coverage on the last mile(s) of a community wireless network at the cost of speed-- especially if the density of nodes and transmit power is high. If an ad-hoc network consists of only a few nodes that are up and running at all time, don't move and always have stable radio links - a long list of ifs - it is possible to write individual routing tables for all nodes by hand. Unfortunately, those conditions are rarely met in the real world. Nodes can fail, WiFi enabled devices roam around, and interference can make radio links unusable at any time. And no one wants to update several routing tables by hand if one node is added to the network. By using routing protocols that automatically maintain individual routing tables in all nodes involved, we can avoid these issues. Popular routing protocols from the wired world (such as OSPF) do not work well in such an environment because they are not designed to deal with lossy links or rapidly changing topology. === Mesh routing with olsrd === The Optimized Link State Routing Daemon - olsrd - from olsr.org is a routing application developed for routing in wireless networks. We will concentrate on this routing software for several reasons. It is a open-source project that supports Mac OS X, Windows 98, 2000, XP, Linux, FreeBSD, OpenBSD and NetBSD. Olsrd is available for access points that run Linux like the Linksys WRT54G, Asus Wl500g, AccessCube or Pocket PCs running Familiar Linux, and ships standard on Metrix kits running Metrix Pebble. Olsrd can handle multiple interfaces and is extensible with plug-ins. It supports IPv6 and it is actively developed and used by community networks all over the world. Note that there are several implementations of Optimized Link State Routing, which began as an IETF-draft written at INRIA France. The implementation from olsr.org started as a master thesis of Andreas Toennesen at UniK University. Based on practical experience of the free networking community, the routing daemon was modified. Olsrd now differs significantly from the original draft because it includes a mechanism called Link Quality Extension that measures the packet loss between nodes and calculates routes according to this information. This extension breaks compatibility to routing daemons that follow the INRIA draft. The olsrd available from olsr.org can be configured to behave according to the IETF draft that lacks this feature - but there is no reason to disable Link Quality Extension unless compliance with other implementations is required. === Theory === After olsrd is running for a while, a node knows about the existence of every other node in the mesh cloud and which nodes may be used to route traffic to them. Each node maintains a routing table covering the whole mesh cloud. This approach to mesh routing is called '''''proactive routing'''''. In contrast, '''''reactive routing''''' algorithms seek routes only when it is necessary to send data to a specific node. There are pros and cons to proactive routing, and there are many other ideas about how to do mesh routing that may be worth mentioning. The biggest advantage of proactive routing is that you know who is out there and you don't have to wait until a route is found. Higher protocol traffic overhead and more CPU load are among the disadvantages. In Berlin, the Freifunk community is operating a mesh cloud where olsrd has to manage more than 100 interfaces. The average CPU load caused by olsrd on a Linksys WRT54G running at 200 MHz is about 30% in the Berlin mesh. There is clearly a limit to what extent a proactive protocol can scale - depending on how many interfaces are involved and how often the routing tables are updated. Maintaining routes in a mesh cloud with static nodes takes less effort than a mesh with nodes that are constantly in motion, since the routing table has to be updated less often. === Mechanism === A node running olsrd is constantly broadcasting 'Hello' messages at a given interval so neighbours can detect it's presence. Every node computes a statistic how many 'Hellos' have been lost or received from each neighbour - thereby gaining information about the topology and link quality of nodes in the neighbourhood. The gained topology information is broadcasted as topology control messages (TC messages) and forwarded by neighbours that olsrd has chosen to be 'multipoint' relays. The concept of multipoint relays is a new idea in proactive routing that came up with the OLSR draft. If every node rebroadcasts topology information that it has received, unnecessary overhead can be generated. Such transmissions are redundant if a node has many neighbours. Thus, an olsrd node decides which neighbours are favorable multipoint relays that should forward its topology control messages. Note that multipoint relays are only chosen for the purpose of forwarding TC messages. Payload is routed considering all available nodes. Two other message types exist in OLSR that announce information: whether a node offers a gateway to other networks (HNA messages) or has multiple interfaces (MID messages). There is not much to say about what this messages do apart from the fact that they exist. HNA messages make olsrd very convenient when connecting to the Internet with a mobile device. When a mesh node roams around it will detect gateways into other networks and always choose the gateway that it has the best route to. However, olsrd is by no means bullet proof. If a node announces that it is an Internet gateway - which it isn't because it never was or it is just offline at the moment - the other nodes will nevertheless trust this information. The pseudo-gateway is a black hole. To overcome this problem, a dynamic gateway plugin was written. The plugin will automatically detect at the gateway if it is actually connected and whether the link is still up. If not, olsrd ceases to send false HNA messages. It is highly recommended to build and use this plugin instead of statically enabling HNA messages. === Practice === Olsrd implements IP-based routing in a userland application - installation is pretty easy. Installation packages are available for OpenWRT, AccessCube, Mac OS X, Debian GNU/Linux and Windows. OLSR is a standard part of Metrix Pebble. If you have to compile from source, please read the documentation that is shipped with the source package. If everything is configured properly all you have to do is start the olsr program. First of all, it must be ensured that every node has a unique statically assigned IP-Address for each interface used for the mesh. It is not recommended (nor practicable) to use DHCP in an IP-based mesh network. A DHCP request will not be answered by a DHCP server if the node requesting DHCP needs a multihop link to connect to it, and applying dhcp relay throughout a mesh is likely impractical. This problem could be solved by using IPv6, since there is plenty of space available to generate a unique IP from the MAC address of each card involved (as suggested in "IPv6 Stateless Address Autoconfiguration in large mobile ad hoc networks" by K. Weniger and M. Zitterbart, 2002). A wiki-page where every interested person can choose an individual IPv4 address for each interface the olsr daemon is running on may serve the purpose quite well. There is just not an easy way to automate the process if IPv4 is used. The broadcast address should be 255.255.255.255 on mesh interfaces in general as a convention. There is no reason to enter the broadcast address explicitly, since olsrd can be configured to override the broadcast addresses with this default. It just has to be ensured that settings are the same everywhere. Olsrd can do this on its own. When a default olsrd configuration file is issued, this feature should be enabled to avoid confusion of the kind 'why can't the other nodes see my machine?!?" Now configure the wireless interface. Here is an example command how to configure a WiFi card with the name wlan0 using Linux: |
...ed un pacchetto arriva con indirizzo di destinazione 10.15.6.23, questi verrà allora spedito al gateway 10.15.6.7 (poichè il primo campo, di ingresso, trova sulla linea di tale gateway una corrispondenza più completa rispetto dalla rotta della rete 10.15.6.0) Una destinazione 0.0.0.0 è convenzionalmente considerata il '''''default gateway'''''. Se nessun altro prefisso trova corrispondenza con l'indirizzo di destinazione, allora il pacchetto viene spedito al ''default gateway''. Per esempio, se l'indirizzo di destinazione fosse 72.1.140.203, allora il router indirizzerebbe il pacchetto al gateway 216.231.38.1 (che sarà, verosimilmente, più prossimo alla destinazione finale, e così via). Se per il pacchetto in ingresso non è trovata nessuna corrispondenza valida (cioè, se non esiste un default gateway e non c'è corrispondenza con il prefisso di una rotta stabilita), allora il pacchetto viene lasciato cadere ed un pacchetto di errore viene restituito al mittente. Il campo TTL è impiegato per riconoscere i giri a vuoto dei pacchetti (''routing loops''). Senza tale campo, un pacchetto potrebbe essere continuamente rimbalzato tra un router ed un altro, qualora questi si indicassero a vicenda come prossimo passo verso la destinazione finale. Questo tipo di giro a vuoto può dare origine ad un forte traffico non necessario sulla rete, tale da minacciarne la stabilità. L'impiego del TTL non scongiura i giri a vuoto, ma contribuisce ad evitare che questi distruggano la rete a causa di un semplice errore di configurazione. === Comporre il tutto in una visione unica === Ciascun nodo della rete può inviare pacchetti di dati all'indirizzo IP di un altro nodo, una volta che tutti abbiano ricevuto il proprio indirizzo IP. Attraverso l'uso del routing e del forwarding, questi pacchetti possono raggiungere i nodi sulla rete che non sono fisicamente connessi al nodo di origine. Questo processo sintetizza la gran parte di ciò che avviene su Internet. Tutto ciò è illustrato nelle figure seguenti: ||<:>attachment:figure-3.6-ita.png|| ||<:>''Figura 3.6: Reti su Internet. Ogni segmento di rete dispone di un router con due indirizzi IP, ponendolo in un "collegamento locale" (''link local'') su due reti differenti. I pacchetti sono passati tra router fintantochè non raggiungano la loro destinazione finale''|| In questo esempio, potete vedere il percorso che completano i pacchetti quando Alice scambia messaggi con Bob impiegando un servizio di ''istant messaging''. Ogni linea punteggiata rappresenta un cavo Ethernet, un collegamento wireless, od ogni altra possibile rete fisica. Il simbolo ''a nuvola'' viene comunemente usato per rappresentare "Internet", e corrisponde ad un numero di reti IP che vi partecipano. Nè Alice, nè Bob devono preoccuparsi di come le proprie reti cooperino tra loro, fintantochè i router inviino il traffico IP fino alla destinazione finale. Se non fosse per i protocolli di Internet e la collaborazione di ciascuno sulla rete, questo tipo di comunicazione non sarebbe possibile. Ora che abbiamo visto come i pacchetti fluiscano sulle reti IP, vediamo un tipo particolare di rete IP: una maglia OLSR. == Reti a Maglia con OLSR == Gran parte delle reti wireless lavorano in Infrastructure Mode; sono costituite di un access point posto da qualche parte, con una scheda radio che lavora in Master Mode, ed un collegamento ad una linea DSL od ad un'altra rete di grande dimensione, di tipo su cavo. In questo '''''hotspot''''', l'access point lavora tipicamente da Master Station che distribuisce l'accesso ad Internet ai propri client, che funzionano invece in Managed Mode. Questa topologia è simile al servizio mobile telefonico GSM. I telefonini si connettono ad una stazione base; senza la presenza di tale stazione base, i telefonini non sarebbero in grado di comunicare tra loro. Se desiderate giocare uno scherzo, chiamate l'amico che siede dall'altro lato del tavolo; il vostro telefono spedice alla stazione base del vostro provider telefonico che può essere lontana un paio di chilometri, ed è la stazione base che reinvia poi il segnale al telefono del vostro amico. Anche le schede WiFi in Managed Mode non possono comunicare direttamente. I client - ad esempio, due portatili sullo stesso tavolo - devono impiegare un access point come relay. Tutto il traffico tra i client aggregati ad un access point deve quindi essere spedito due volte. Se i client A e C comunicano, il cliente A spedisce i propri dati all'access point B, quindi l'access point ritrasmette i dati al cliente C. La singola trasmissione può raggiungere, nel nostro esempio, i 600 kByte/sec (all'incirca, la velocità massima raggiungibile con il protocollo 802.11b). Così, poichè i dati devono essere ripetuti dall'access point prima che raggiungano il proprio destinatario, la velocità effettiva tra due client sarà solo di 300 kByte/sec. Nel modo ad-hoc non c'è un rapporto gerarchico master-client. I nodi possono comunicare direttamente, fintantochè siano nel raggio d'azione delle proprie interfacce wireless. Così, nel nostro esempio entrambi i computer potrebbero raggiungere la massima velocità se lavorassero in modalità ad-hoc, in condizioni ideali. Lo svantaggio della modalità ad-hoc è che i client non ritrasmettono il traffico destinato ad altri client. Nel caso dell'access point (modalità infrastructure), invece, se due client A e C non possono vedersi direttamente con le loro interfacce wireless, sono comunque in grado di comunicare, fintantochè l'Access Point sia nel raggio wireless di entrambi i client. ||<:>attachment:figure-3.7-ita.png|| ||<:>''Figura 3.7: L'Access Point B ritrasmetterà il traffico tra i client A and C. Nella modalità Ad-Hoc, il nodo B non ripeterà il traffico tra A e C per default.''|| I nodi Ad-hoc non ritrasmettono il traffico per default, ma possono comportarsi in modo simile se viene applicato un opportuno '''''routing'''''. Le reti a maglia (''Mesh networks'') sono basate sulla strategia che rende ogni nodo - capace di costituire maglie - relay per estendere la copertura della rete wireless. Maggiore il numero dei nodi, migliore diventa la copertura radio e la portata della nuvola di maglie. Un importante costo dev'essere menzionato a questo proposito. Se il dispositivo usa solo un'interfaccia radio, la banda disponibile è ridotta in modo significativo ogni volta che il traffico viene ripetuto da nodi intermedi posti sul percorso da A a B. Inoltre, ci sarà interferenza nella trasmissione a causa della condivisione dello stesso canale da parte dei nodi. Cosi, economiche reti a maglia su modalità ad-hoc possono garantire una buona copertura radio sull'ultimo miglio di una rete di una comunità wireless al costo della velocità, specialmente se la densità dei nodi e la potenza di trasmissione sono alte. Se una rete ad-hoc è costituita solamente di pochi nodi che sono accesi ed attivi in modo continuo, che non si muovono e che dispongono sempre di collegamenti radio stabili - una lunga lista di condizioni - diventa possibile compilare a mano le tabelle di routing per tutti i nodi. Sfortunatamente, le condizioni citate si incontrano difficilmente nel mondo reale. I nodi possono cadere, dispositivi WiFi sono presenti nelle vicinanze, e le interferenze possono rendere inimpiegabili i collegamenti radio in qualsiasi momento. Nessuno ha l'intenzione di aggiornare a mano diverse tabelle di routing ogni volta che un nuovo nodo è aggiunto alla rete. Impiegando invece protocolli di routing che mantengono in modo automatico le specifiche tabelle di routing su tutti i nodi coinvolti, diventa possibile evitare questo problema. I protocolli di routing di maggiore impiego nel mondo cablato (protocolli come OSPF) non funzionano al meglio in un ambiente wireless perchè non sono progettati per contrastare i collegamenti con attenuazioni o le topologie che cambiano con rapidità. === Mesh Routing con olsrd === Il demone Optimized Link State Routing - olsrd - fornito da olsr.org è un'applicazione di routing sviluppata per il routing nelle reti wireless. Ci si concentrerà su questo software di routing per diverse ragioni. E' un progetto open-source che supporta Mac OS X, Windows 98, 2000, XP, Linux, FreeBSD, OpenBSD e NetBSD. Olsrd è disponibile per access point che funzionano sotto Linux, come il Linksys WRT54GL, l'Asus WL-500G, l'AccessCube od i PocketPC che funzionano su Familiar Linux, e viene fornito come standard sui kit Metrix che funzionano su Metrix Pebble. Olsrd può gestire interfacce multiple ed è estensibile con appositi moduli aggiuntivi (plug-in). Supporta IPv6 ed è attivamente sviluppato ed impiegato da reti di comunità in tutto il mondo. Si noti come esistano diverse versioni dell'Optimized Link State Routing, che è nato come un draft IETF scritto dall'istituto francese INRIA. La realizzazione distribuita da olsr.org ha visto la luce come tesi di master di Andrea Toennesen all'università di Unik. Basato sull'esperienza pratica della comunità delle reti libere, il demone di routing venne modificato. Olsrd attualmente si differenzia significativamente dalla proposta originale, perchè include un dispositivo chiamato Link Quality Extension che rileva il tasso di pacchetti perduti tra i nodi e ricalcola le rotte sulla base di queste informazioni. Questa estensione rompe la compatibilità con i demoni di routing che seguono la proposta INRIA. Il demone olsrd disponibile da olsr.org può essere configurato per comportarsi in ossequio alla proposta IETF che manca di questa caratteristica, ma non v'è ragione per disabilitare la Link Quality Extension, a meno che non sia espressamente richiesta la piena aderenza con le altre realizzazioni. === La Teoria === Dopo che il demone olsrd è stato attivato per un tempo adeguato, un nodo apprende dell'esistenza di ogni altro nodo nella nuvola di maglie, e riconosce anche quale nodo possa essere impiegato per indirizzargli il traffico. Ogni nodo mantiene aggiornata una tabella di routing che descrive l'intera nuvola di maglie. Questo approccio al mesh routing viene chiamato '''''routing proattivo'''''. Al contrario, gli algoritmi di '''''routing reattivo''''' ricercano le rotte solo quando è necessario spedire dei dati verso un nodo specifico. Ci sono vantaggi e svantaggi nel routing proattivo, e per realizzare il mesh routing ci sono molte altre impostazioni differenti, meritevoli di citazione. Il maggior vantaggio del routing proattivo risiede nel fatto che viene reso noto chi sia presente all'esterno e non si deve quindi aspettare che la rotta venga trovata. Tra gli svantaggi, ci sono il maggior sovraccarico di traffico ed il maggior carico sulla CPU. A Berlino, la comunità Freifunk impiega una nuvola di maglie dove olsrd deve gestire più di 100 interfacce. Il carico medio sulla CPU di un Linksys WRT54G a 200 MHz, causato da olsrd, è circa del 30%, nella rete di Berlino. C'è chiaramente un limite alla scalabilità di un protocollo proattivo, limite che dipende da quante interfacce siano coinvolte e da quanto frequentemente le tabelle di routing vengano aggiornate. Mantenere le rotte in una nuvola di maglie coon nodi statici richiede meno sforzo di quanto sia invece necessario in una maglia dove i nodi siano in costante movimento, poichè le tabelle di routing devono essere aggiornate con frequenza minore. === Il Meccanismo === Un nodo, su cui gira olsrd, diffonde periodicamente messaggi di 'hello' in modo che i propri vicini possano riconoscerne la presenza. Ogni nodo mantiene una statistica di quanti messaggi di 'hello' siano stati ricevuti o persi da parte di ognuno dei suoi vicini, riuscendo così a ricevare informazioni sulla topologia dei nodi vicini e sulla qualità dei collegamenti. Le informazioni ricavate sulla tipologia sono poi diffuse via radio come messaggi di controllo della topologia (messaggi TC) ed inoltrati dai vicini che olsrd ha preventivamente eletto come relay multipunto. Nel routing proattivo Il concetto di relay multipunto è un'idea nuova che è sorta con la bozza di OLSR. Se ogni nodo ridiffondesse via radio le informazioni di topologia che ha ricevuto, potrebbe generarsi un sovraccarico eccessivo nella rete. Queste trasmissioni sono ridondanti, se un nodo ha diversi vicini. Un nodo olsrd, allora, decide quali vicini siano relay multipunto favorevoli per inoltrare i propri messaggi di controllo della tipologia. Si noti che i relay multipunto sono scelti con l'unico scopo di inoltrare i messaggi TC. Il contenuto utile (''payload'') viene soggetto a routing che può coinvolgere ogni nodo disponibile. Altri due tipi di messaggio sono presenti in OLSR per passare informazioni: se un nodo presenta un gateway ad altre reti (messaggi HNA) o se ha più interfacce (messaggi MID). Non c'è molto da dire su quale compito svolgano questi messaggi, a parte il fatto che esistono. I messaggi HNA rendono olsrd molto utile quanto si tratti di connettere Internet con un dispositivo mobile. Quando un nodo di maglia si sposta intorno, potrà riconoscere dei gateway nelle altre reti, e sceglierà sempre il gateway che presenta la rotta migliore. Comunque, olsrd non è assolutamente a prova di errore. Se un nodo dichiara di essere un gateway verso Internet - funzione che non ricopre. in realtà, perchè non lo è mai stato o perchè si trova disconnesso al momento - gli altri nodi presteranno fede all'affermazione. Il finto-gateway diventa un buco nero. Per superare questo problema, è stato scritto un plugin (modulo aggiuntivo) per il gateway dinamico. Il plugin nel gateway verificherà automaticamente se questi sia connesso e se il collegamento stia ancora in piedi. In caso negativo, l'olsrd terminerà di inviare falsi messaggi HNA. E' fortemente raccomandato di inserire ed impiegare questo plugin, piuttosto che dare manualmente l'abilitazione all'invio di messaggi HNA. === In Pratica === Olsrd realizza il routing basato su IP con un'applicazione nello spazio-utente; l'installazione è quindi piuttosto semplice. I pacchetti per l'installazione sono disponibili per OpenWRT, Accesscube, Mac OS X, Debian GNU/Linux e Windows. OLSR è un componente standard di Metrix Pebble. Se si deve compilarlo dai sorgenti, occorre leggere la documentazione che è diffusa all'interno del pacchetto del sorgente. Se ogni cosa è configurata ammodo, tutto ciò che rimane da fare è l'avvio del programma olsr. Prima di tutto, occorre assicurarsi che ogni nodo abbia un indirizzo IP, assegnato staticamente ed unico, per ogni interfaccia usata per la maglia. Non è raccomandato (nè è praticabile) impiegare DHCP in una rete a maglia basata su IP. Una richiesta DHCP non verrà soddisfatta da un server DHCP se il nodo che la inoltra richiede più di un salto per essere raggiunto, ed inserire dei relay DHCP su una maglia è pressochè impraticabile. Questo problema potrebbe essere risolto usando IPv6, poichè in tal modo sarebbe disponibile uno spazio-indirizzi enorme per generare un indirizzo IP a partire dall'indirizzo MAC di ogni scheda coinvolta (come suggerisce in "IPv6 Stateless Address Autoconfiguration in large mobile ad hoc networks" di K. Weniger e M. Zitterbart, 2002). Potrebbe servire allo scopo anche una pagina wiki, dove ogni persona interessata potrebbe scegliere un indirizzo IPv4 unico per ognuna delle interfacce sulle quali il demone olsr verrebbe fatto girare. In sintesi, non c'è una soluzione facile per rendere automatico tale processo, se si ricorre ad IPv4. L'indirizzo di broadcast, per convenzione generale, dovrebbe essere 255.255.255.255 su interfacce che si affacciano sulla rete a maglia. Non c'è nessun motivo, per inserire esplicitamente l'indirizzo di broadcast, poichè olsrd può essere configurato per sostituire gli indirizzi di broadcast con tale valore predefinito. Occorre solo essere sicuri che tali impostazioni siano uniformi in ogni parte. Olsrd può raggiungere tale scopo da solo. Quando un file predefinito di configurazione di olsrd è distribuito, questa caratteristica dovrebbe essere abilitata per evitare confusione del tipo "perchè gli altri nodi non riescono a vedere la mia macchina?!?" Ora configuriamo l'interfaccia wireless. Di seguito un comando, come esempio di come configurare una scheda wifi, con il nome wlan0, usando Linux: |
| Linea 233: | Linea 245: |
| Verify that the wireless part of the WiFi card has been configured so it has an ad-hoc connection to other mesh nodes within direct (single hop) range. Make sure the interface joins the same wireless channel, uses the same wireless network name ESSID (Extended Service Set IDentifier) and has the same Cell-ID as all other WiFi-Cards that build the mesh. Many WiFi cards or their respective drivers do not act compliant to the 802.11 standard for ad-hoc networking and thus may fail miserably to connect to a cell. They may be unable to connect to other devices on the same table, even if they are set up with the correct channel and wireless network name. They may rather confuse other cards that behave according to the standard by creating their own Cell-ID on the same channel with the same wireless network name. WiFi cards made by Intel that are shipped with Centrino Notebooks are notorious to do this. You can check this out with the command '''iwconfig''' when using GNU/Linux. Here is the output on my machine: |
Occorre verificare che la parte wireless della scheda wifi sia stata configurata in modo che abbia una connessione ad-hoc verso gli altri nodi della maglia direttamente raggiungibili (nodi entro il singolo salto). Occorre anche assicurarsi che l'interfaccia si aggreghi allo stesso canale wireless, che usi lo stesso nome di rete wireless ESSID (Extended Service Set IDentifier) e che sia caratterizzato dallo stesso Cell-ID come tutte le altre schede wifi che compongono la maglia. Molte schede wifi, od i loro rispettivi driver, non si comportano in maniera conforme a quanto previsto dagli standard 802.11 per il networking ad-ho, e così può fallire miseramente il tentativo di connettersi ad una cella. Le stesse schede possono non essere in grado di connettersi ad altri dispositivi sullo stesso tavolo, anche se questi sono impostati con il corretto canale e nome di rete wireless.Queste schede possono, piuttosto, confondere altre schede che si comportano invece conformemente allo standard, creando il proprio indicativo di cella (Cell-ID) sullo stesso canale con lo stesso nome di rete wireless. Le schede wifi costruite dall'Intel e che sono distribuite con i notebook Centrino sono famose per comportarsi in tale maniera. E' possibile verificare tutto con il comando '''iwconfig''', quando si usa Linux. Di seguito, l'output che si ottiene sulla mia macchina. |
| Linea 249: | Linea 261: |
| It is important to set the 'Request To Send' threshold value RTS for a mesh. There will be collisions on the radio channel between the transmissions of nodes on the same wireless channel, and RTS will mitigate this. RTS/CTS adds a handshake before each packet transmission to make sure that the channel is clear. This adds overhead, but increases performance in case of hidden nodes - and hidden nodes are the default in a mesh! This parameter sets the size of the smallest packet (in bytes) for which the node sends RTS. The RTS threshold value must be smaller than the IP-Packet size and the 'Fragmentation threshold' value - here set to 256 - otherwise it will be disabled. TCP is very sensitive to collisions, so it is important to switch RTS on. Fragmentation allows to split an IP packet in a burst of smaller fragments transmitted on the medium. This adds overhead, but in a noisy environment this reduces the error penalty and allows packets to get through interference bursts. Mesh networks are very noisy because nodes use the same channel and therefore transmissions are likely to interfere with each other. This parameter sets the maximum size before a data packet is split and sent in a burst - a value equal to the maximum IP packet size disables the mechanism, so it must be smaller than the IP packet size. Setting fragmentation threshold is recommended. Once a valid IP-address and netmask is assigned and the wireless interface is up, the configuration file of olsrd must be altered in order that olsrd finds and uses the interfaces it is meant to work on. For Mac OS-X and Windows there are nice GUI's for configuration and monitoring of the daemon available. Unfortunately this tempts users that lack background knowledge to do stupid things - like announcing black holes. On BSD and Linux the configuration file === A simple olsrd.conf === We are not going to provide a complete configuration file. Here are some essential settings that should be checked. |
E' importante impostare la soglia del 'Request To Send' (RTS) per una maglia. Ci saranno delle collisioni sul canale radio tra le trasmissioni dei nodi dello stesso canale radio, e l'RTS mitigherà tali effetti. RTS/CTS introduce un handshake prima di ogni pacchetto di trasmissione per sincerarsi che il canale sia chiaro. Si introduce del sovraccarico, ma si incrementano le prestazioni in caso di nodi nascosti - ed i nodi nascosti sono presenti per default sulla maglia! Questo parametro imposta la dimensione in Byte del più piccolo pacchetto per il quale il nodo spedisce l'RTS. La soglia RTS deve avere un valore minori della dimensione del pacchetto IP e il valore di 'soglia di frammentazione' - qui posto a 256 - altrimenti sarà disabilitato. Il TCP è molto sensibile alle collisioni, così è importante attivare l'RTS. La frammentazione permette di spezzare un pacchetto IP in una serie di frammenti minori che vengono trasmessi sul medium. Tutto questo aggiunge sovraccarico, ma in un ambiente rumoroso ciò riduce il costo dell'errore e permette ai pacchetti di attraversare le scariche di rumore. Le reti a maglia sono molto rumorose perchè i nodi impiegano lo stesso canale e, quindi, è probabile che le trasmissioni inteferiscano a vicenda. Questo parametro imposta la massima dimensione in byte che permetta la pacchetto di non essere spezzettato per poi essere recapitato a pezzi - un valore uguale alla massima dimensione IP disabilita il meccanismo, cos' dev'essere minore della dimensione del pacchetto IP. Impostare la soglia di frammentazione è raccomandato. Una volta che sono stati assegnati un indirizzo IP valido ed una maschera di rete, una volta che l'interfaccia wireless sia attiva, il file di confifurazione di olsrd dev'essere alterato perchè olsrd trovi ed impieghi le interfacce con le quali si intende farlo lavorare. Per Mac OS-X e Windows è disponibile una simpatica GUI per configurare e controllare il demone disponibile. Sfortunatamente, questi tenta l'utente che manchi di competenze a commettere errori stupidi - quali annunciare la presenza di un buco nero. Su BSD e Linux il file di configurazione è: === Un semplice file di configurazione olsrd.conf === Non verrà di seguito presentato un file di configurazione completo. Ci saranno invece alcune impostazioni essenziali che devono essere controllate. |
| Linea 280: | Linea 294: |
| There are many more options available in the '''olsrd.conf''', but these basic options should get you started. After these steps have been done, olsrd can be started with a simple command in a terminal: | Ci sono molte altre opzioni disponibili nel '''olsrd.conf''', ma queste opzioni base dovrebbero permettervi di iniziare. Dopo che questi passi sono stati completati, olsrd può essere avviato con un semplice comando all'interno di un terminale: |
| Linea 286: | Linea 301: |
| I recommend to run it with the debugging option -d 2 when used on a workstation, especially for the first time. You can see what olsrd does and monitor how well the links to your neighbours are. On embedded devices the debug level should be 0 (off), because debugging creates a lot of CPU load. The output should look something like this: |
Si raccomanda di lanciare il programma con l'opzione di debugging "-d 2", quando lo si usi su una workstation, specialmente se si tratta del primo avvio. Si può così osservare come si comporti olsrd e monitorare quale sia la qualità dei link con i vicini. Sui dispositivi embedded, invece, il livello di debug dovrebbe essere posto a zero (off), perchè le operazioni di debugging caricano pesantemente la CPU. I dati in uscita del debugging dovrebbero essere simili a questo: |
| Linea 316: | Linea 331: |
| === Using OLSR on Ethernet and multiple interfaces === It is not necessary to have a wireless interface to test or use olsrd - although that is what olsrd is designed for. It may as well be used on any NIC. WiFi-interfaces don't have to operate always in ad-hoc mode to form a mesh when mesh nodes have more then one interface. For dedicated links it may be a very good option to have them running in infrastructure mode. Many WiFi cards and drivers are buggy in ad-hoc mode, but infrastructure mode works fine - because everybody expects at least this feature to work. Ad-hoc mode has not had many users so far, so the implementation of the ad-hoc mode was done sloppily by many manufacturers. With the rising popularity of mesh networks, the driver situation is improving now. Many people use olsrd on wired and wireless interfaces - they don't think about network architecture. They just connect antennas to their WiFi cards, connect cables to their Ethernet cards, enable olsrd to run on all computers and all interfaces and fire it up. That is quite an abuse of a protocol that was designed to do wireless networking on lossy links - but - why not? They expect olsrd to be an ueberprotocol. Clearly it is not necessary to send 'Hello' messages on a wired interface every two seconds - but it works. This should not be taken as an recommendation - it is just amazing what people do with such a protocol and have success with it. In fact the idea of having a protocol that does everything for newbies that want to have a small to medium sized routed LAN is very appealing... === Plugins === A number of plugins are available for olsrd. Check out the olsr.org website for a complete list. Here a little HOWTO for the network topology visualization plugin ||<:>http://wiki.wndw.net/images/figures/en/figure-3.8.png|| ||<:>''Figure 3.8: An automatically generated OLSR network topology.''|| Often it is very good for the understanding of a mesh network to have the ability to show the network topology graphically. Olsrd_dot_draw outputs the topology in the dot file format on TCP port 2004. The graphviz tools can then be used to draw the graphs. === Installing the dot_draw Plugin === Compile the olsr plugins separately and install them. To load the plugin add the following lines to '''/etc/olsrd.conf''' |
=== Impiego di OLSR su Ethernet e su interfacce multiple === Non è necessario disporre di un'interfaccia wireless per provare od impiegare olsrd - sebbene sia per queste interfacce che olsrd è stato progettato. Olsrd può essere benissimo impiegato su qualsiasi NIC (scheda di rete). Le interfacce WiFi non necessariamente devono operare in modo ad-hoc per formare una maglia quando i nodi dispongano di più di una interfaccia. Per dei collegamenti dedicati potrebbe essere un'interessante opzione mantenerli attivi in Infrastructure Mode. Molte schede WiFi posseggono driver che presentano problemi in Ad-hoc Mode, ma l'Infrastructure Mode funziona bene - perchè tutti si aspettano che almeno questa prestazione sia garantita. Il modo ad-hoc non è così popolare, così la realizzazione di un modo ad-hoc è sempre stata trascurata da molti produttori. Con la crescente attenzione alle reti a maglia, la situazione dei driver sta ora migliorando. Molte persone usano olsrd su interfacce wireless ed altre cablate, non hanno bisgono di tenere conto dell'architettura della rete. Si limitano a collegare antenne alle loro schede WiFi, collegare cavi alle loro schede Ethernet, abilitare olsrd ad essere lanciato su tutti i computer e su tutte le interfacce e quindi danno il via al tutto. Tutto ciò è piuttosto un abusare di un protocollo che era stato concepito per permettere il wireless networking su link con perdite, ma perchè impedirlo? Ci si aspetta che olsrd sia un sovra-protocollo. Chiaramente non è necessario inviare un messaggio di Hello su un'interfaccia ogni due secondi, ma funziona. Questo comportamento non dev'essere assunto come raccomandazione, è solo incredibile cosa facciano le persone di questo protocollo, ed hanno successo. Infatti è entusiasmante l'idea di mettere a disposizione un protocollo che risolva tutto per dei principianti che desiderino reti LAN di dimensioni medio-piccole. === Plugin === Diversi plugin sono disponibili per olsrd. Si veda sul sito olsr.org per una lista completa. Di seguito, una breve HOW-TO per il plugin che visualizza la topologia di una rete. ||<:>attachment:figure-3.8.png|| ||<:>''Figura 3.8: Una topologia di rete OLSR generata automaticamente.''|| Spesso, per la comprensione di una rete a maglia, è molto utile riuscire ad esibirne la topologia di rete in modo grafico. Olsrd_dot_draw presenta come risultato la tipologia nel formato "dot file" sulla porta 2004 in TCP. Gli strumenti graphviz possono quindi essere impiegati per tracciarne i grafici. === Installare il plugin dot_draw === Si compilino i plugin olsr separatamente e li si installi. Per caricare il plugin, aggiungere la seguente riga al file '''/etc/olsrd.conf''' |
| Linea 345: | Linea 362: |
| The parameter "accept" specifies which host is accepted to view the Topology Information (currently only one) and is "localhost" by default. The parameter "port" specifies the TCP port. Then restart olsr and check if you get output on TCP Port 2004 |
Il parametro "accept" specifica quale macchina sia abilitata a visualizzare le informazioni della topologia (al momento, solo una) e, di default, è impostato "localhost". Far ripartire olsr e verificare se si ottenga output sulla porta TCP 2004 |
| Linea 353: | Linea 370: |
| After a while you should get some text output. Now you can save the output graph descriptions and run the tools '''`dot`''' or '''`neato`''' form the graphviz package to get images. Bruno Randolf has written a small perl script which continuously gets the topology information from olsrd and displays it using the graphviz and ImageMagick tools. First install the following packages on your workstation: |
Dopo un certo periodo, si dovrebbe ottenere del testo come risultato. Si può allora salvare l'output delle descrizioni grafiche e lanciare i tool '''`dot`''' o '''`neato`''' dal pacchetto graphviz, al fine di ottenere le immagini. Bruno Randolf ha scritto un breve script perl che richiede periodicamente le informazioni di topologia da olsrd e le visualizza impiegando gli strumenti di graphviz e di ImageMagick. Per prima cosa, si installino sulla workstation i seguenti pacchetti: |
| Linea 364: | Linea 381: |
| Download the script at: http://meshcube.org/nylon/utils/olsr-topology-view.pl Now you can start the script with '''`./olsr-topology-view.pl`''' and view the topology updates in near-realtime. === Troubleshooting === As long as the WiFi-cards can 'see' each other directly with their radios, doing a ping will work whether olsrd is running or not. This works because the large netmasks effectively make every node link-local, so routing issues are sidestepped at the first hop. This should be checked first if things do not seem to work as expected. Most headaches people face with WiFi in Ad-Hoc mode are caused by the fact that the ad-hoc mode in drivers and cards are implemented sloppily. If it is not possible to ping nodes directly when they are in range it is most likely a card/driver issue, or your network settings are wrong. If the machines can ping each other, but olsrd doesn't find routes, then the IP-addresses, netmask and broadcast address should be checked. Are you running a firewall? Make sure it doesn't block UDP port 698. Have fun! == Estimating capacity == Wireless links can provide significantly greater '''''throughput''''' to users than traditional Internet connections, such as VSAT, dialup, or DSL. Throughput is also referred to as '''''channel capacity''''', or simply '''''bandwidth''''' (although this term is unrelated to radio bandwidth). It is important to understand that a wireless device's listed speed (the '''''data rate''''') refers to the rate at which the radios can exchange symbols, not the usable throughput you will observe. As mentioned earlier, a single 802.11g link may use 54Mbps radios, but it will only provide up to 22Mbps of actual throughput. The rest is overhead that the radios need in order to coordinate their signals using the 802.11g protocol. Note that throughput is a measurement of bits over time. 22Mbps means that in any given second, up to 22 megabits can be sent from one end of the link to the other. If users attempt to push more than 22 megabits through the link, it will take longer than one second. Since the data can't be sent immediately, it is put in a '''''queue''''', and transmitted as quickly as possible. This backlog of data increases the time needed for the most recently queued bits to the traverse the link. The time that it takes for data to traverse a link is called '''''latency''''', and high latency is commonly referred to as '''''lag'''''. Your link will eventually send all of the queued traffic, but your users will likely complain as the lag increases. How much throughput will your users really need? It depends on how many users you have, and how they use the wireless link. Various Internet applications require different amounts of throughput. ||<rowstyle="background-color: #C0C0C0;">'''Application'''||'''BW / User'''||'''Notes'''|| ||Text messaging / IM||< 1 Kbps||As traffic is infrequent and asynchronous, IM will tolerate high latency.|| ||Email||1 to 100 Kbps||As with IM, email is asynchronous and intermittent, so it will tolerate latency. Large attachments, viruses, and spam significantly add to bandwidth usage. Note that web email services (such as Yahoo or Hotmail) should be considered as web browsing, not as email. || ||Web browsing||50 - 100+ Kbps||Web browsers only use the network when data is requested. Communication is asynchronous, so a fair amount of lag can be tolerated. As web browsers request more data (large images, long downloads, etc.) bandwidth usage will go up significantly.|| ||Streaming audio ||96 - 160 Kbps||Each user of a streaming audio service will use a constant amount of relatively large bandwidth for as long as it plays. It can tolerate some transient latency by using large buffers on the client. But extended periods of lag will cause audio "skips" or outright session failures.|| ||Voice over IP (VoIP)||24 - 100+ Kbps ||As with streaming audio, VoIP commits a constant amount of bandwidth to each user for the duration of the call. But with VoIP, the bandwidth is used roughly equally in both directions. Latency on a VoIP connection is immediate and annoying to users. Lag greater than a few milliseconds is unacceptable for VoIP. || ||Streaming video||64 - 200+ Kbps||As with streaming audio, some intermittent latency is avoided by using buffers on the client. Streaming video requires high throughput and low latency to work properly.|| ||Peer-to-peer filesharing applications (BitTorrent, KaZaA, Gnutella, eDonkey, etc.)||0 - infinite Mbps||While peer to peer applications will tolerate any amount of latency, they tend to use up all available throughput by transmitting data to as many clients as possible, as quickly as possible. Use of these applications will cause latency and throughput problems for all other network users unless you use careful bandwidth shaping.|| To estimate the necessary throughput you will need for your network, multiply the expected number of users by the sort of application they will likely use. For example, 50 users who are chiefly browsing the web will likely consume 2.5 to 5Mbps or more of throughput at peak times, and will tolerate some latency. On the other hand, 50 simultaneous VoIP users would require 5Mbps or more of throughput '''in both directions''' with absolutely no latency. Since 802.11g wireless equipment is '''''half duplex''''' (that is, it only transmits or receives, never both at once) you should accordingly double the required throughput, for a total of '''10Mbps'''. Your wireless links must provide that capacity every second, or conversations will lag. Since all of your users are unlikely to use the connection at precisely the same moment, it is common practice to '''''oversubscribe''''' available throughput by some factor (that is, allow more users than the maximum available bandwidth can support). Oversubscribing by a factor of 2 to 5 is quite common. In all likelihood, you will oversubscribe by some amount when building your network infrastructure. By carefully monitoring throughput throughout your network, you will be able to plan when to upgrade various parts of the network, and how much additional resources will be needed. Expect that no matter how much capacity you supply, your users will eventually find applications that will use it all. As we'll see at the end of this chapter, using bandwidth shaping techniques can help mitigate some latency problems. By using bandwidth shaping, web caching, and other techniques, you can significantly reduce latency and increase overall network throughput. To get a feeling for the lag felt on very slow connections, the ICTP has put together a bandwidth simulator. It will simultaneously download a web page at full speed and at a reduced rate that you choose. This demonstration gives you an immediate understanding of how low throughput and high latency reduce the usefulness of the Internet as a communications tool. It is available at http://wireless.ictp.trieste.it/simulator/ == Link planning == A basic communication system consists of two radios, each with its associated antenna, the two being separated by the path to be covered. In order to have a communication between the two, the radios require a certain minimum signal to be collected by the antennas and presented to their input socket. Determining if the link is feasible is a process called '''''link budget''''' calculation. Whether or not signals can be passed between the radios depends on the quality of the equipment being used and on the diminishment of the signal due to distance, called '''''path loss'''''. === Calculating the link budget === The power available in an 802.11 system can be characterized by the following factors: * '''''Transmit Power'''''. It is expressed in milliwatts or in dBm. Transmit Power ranges from 30mW to 200mW or more. TX power is often dependent on the transmission rate. The TX power of a given device should be specified in the literature provided by the manufacturer, but can sometimes be difficult to find. Online databases such as the one provided by SeattleWireless (http://www.seattlewireless.net/HardwareComparison) may help. * '''''Antenna Gain'''''. Antennas are passive devices that create the effect of amplification by virtue of their physical shape. Antennas have the same characteristics when receiving and transmitting. So a 12 dBi antenna is simply a 12 dBi antenna, without specifying if it is in transmission or reception mode. Parabolic antennas have a gain of 19-24 dBm, omnidirectional antennas have 5-12 dBi, sectorial antennas have roughly a 12-15 dBi gain. * '''''Minimum Received Signal Level,''''' or simply, the sensitivity of the receiver. The minimum RSL is always expressed as a negative dBm (- dBm) and is the lowest power of signal the radio can distinguish. The minimum RSL is dependent upon rate, and as a general rule the lowest rate (1 Mbps) has the greatest sensitivity. The minimum will be typically in the range of -75 to -95 dBm. Like TX power, the RSL specifications should be provided by the manufacturer of the equipment. * '''''Cable Losses'''''. Some of the signal's energy is lost in the cables, the connectors and other devices, going from the radios to the antennas. The loss depends on the type of cable used and on its length. Signal loss for short coaxial cables including connectors is quite low, in the range of 2-3 dB. It is better to have cables as short as possible. When calculating the path loss, several effects must be considered. One has to take into account the '''''free space loss''''', '''''attenuation''''' and '''''scattering'''''. Signal power is diminished by geometric spreading of the wavefront, commonly known as free space loss. Ignoring everything else, the further away the two radios, the smaller the received signal is due to free space loss. This is independent from the environment, depending only on the distance. This loss happens because the radiated signal energy expands as a function of the distance from the transmitter. Using decibels to express the loss and using 2.45 GHz as the signal frequency, the equation for the free space loss is |
Si scarichi lo script da: http://meshcube.org/nylon/utils/olsr-topology-view.pl Ora è possibile lanciare lo script con il comando: '''`./olsr-topology-view.pl`''' , e vedere così gli aggiornamenti della topologia in tempo quasi-reale. === Risoluzione dei malfunzionamenti === Fintantochè le schede WiFi riescono a 'vedersi' una con l'altra tramite collegamenti radio, la richiesta di un ping funzionerà, a prescindere dall'esecuzione di olsrd. Ciò succede perchè le ampie netmask rendono effettivamente ogni nodo su un link-local, sì da accantonare qualsiasi problema di routing già con il primo hop. E' la prima cosa che si dovrebbe controllare se il comportamento della rete non sia quello aspettato. Gran parte dei malditesta che vengono forniti dalle schede WiFi nella modalità Ad-Hoc sono causati dal fatto che i driver per il modo Ad-Hoc sono realizzati in modo approssimativo. Se non è possibile ottenere il ping diretto con i nodi in visibilità, si tratta probabilmente di un problema di scheda e driver, od, in alternativa, sono errati i parametri di impostazione della rete. Se le macchine possono ottenere il ping una dall'altra, ma olsrd non riesce a ricavare le rotte, allora dovrebbero essere ricontrollati gli indirizzi IP, la netmask ed il broadcast. E' forse in azione un firewall? Verificare che non intercetti la porta UDP 698. Buon divertimento! == Stima della Capacità == I collegamenti wireless possono assicurare agli utenti un '''''throughput''''' maggiore, rispetto alle tradizionali connessioni ad Internet, quali la VSAT, la linea telefonica o la DSL. Il Throughput è altrimento denominato '''''capacità del canale''''', o semplicemente '''''larghezza di banda''''' (sebbene tale termine non abbia attinenza con la larghezza di banda radio). E' importante comprendere che la velocità dichiarata di un dispositivo wireless (il '''''data rate''''') indica la velocità alla quale questi riesce a comunicare simboli via radio, non l'effettivo throughput che potrà essere osservato in pratica. Come accennato in precedenza, un singolo collegamento 802.11g può raggiungere i 54Mbps via radio, ma assicurerà un throighput effettivo fino a 22Mbps; il resto è sovraccarico che le radio impiegano per coordinare il proprio segnale usando il protocollo 802.11g. Si noti che il throughput è una misura di bit sul tempo. 22Mbps significa che, in un qualsiasi secondo, 22 megabit possono essere inviati da un capo del collegamento all'altro. Se l'utente tenta di spingervi più di 22 megabit, l'operazione richiederà un tempo maggiore di un secondo. Poichè non possono essere inviati immediatamente, i dati vengono inseriti in una '''''coda''''', per poi essere trasmessi il più presto possibile. Questo accodamento di dati allunga i tempi necessari perchè l'ultimo bit inserito in coda possa attraversare il collegamento. Il tempo che si rende necessario per l'attraversamento del collegamento è chiamato '''''latenza''''', ed una latenza più pesante è chiamata '''''ritardo'''''. Il collegamento potrà anche trasferire tutto il traffico accodato, ma chi lo riceve potrà lamentare un incremento del ritardo. Quale troughput sarà richiesto per i vostri utenti? Dipende da quanti essi siano, e da come intendano impiegare il collegamento wireless. Applicazioni diverse di Internet richiedono valori diversi di throughput. ||<rowstyle="background-color: #C0C0C0;">'''Applicazione'''||'''BW / Utente'''||'''Note'''|| ||Messaggi di Testo / IM||< 1 Kbps||Poichè il traffico è rado ed asincrono, IM accetterà alta latenza.|| ||Posta Elettronica||da 1 a 100 Kbps||Come per IM, la posta elettronica è asincrona ed intermittente, quindi ammetterà latenza. Allegati pesanti, virus e spam incrementano sensibilmente l'impiego di banda. Si noti come i servizi di posta elettronica via web (come Yahoo ed Hotmail) debbano essere considerati navigazione sul web, piuttosto che posta elettronica. || ||Navigazione web||50 - 100+ Kbps||I Web browser impiegano la rete solo quando richiedono dati. La comunicazione è asincrona, quindi un sensibile ritardo può essere accettato. Quando i browser richiedono più dati (immagini di grandi dimensioni, download pesanti, etc.), l'impiego di banda s'innalzerà in maniera significativa..|| ||Streaming audio ||96 - 160 Kbps||Ogni utente di un servizio di streaming audio service impiegherà una relativamente ampia larghezza di banda in modo costante, fintantochè trasferisce audio. Il servizio può accettare una latenza occasionale, impiegando dei buffer ampi presso i partecipanti. Periodi più lunghi di ritardo causeranno invece degli "slittamenti" dell'audio, se non addirittura la caduta della sessione.|| ||Voice over IP (VoIP)||24 - 100+ Kbps ||Come nello streaming audio, il VoIP richiede una quantità costante di banda per ciascuno degli utente per la dirata della chiamata, ma tale quantità di banda è pressochè equivalente nelle due direzioni del collegamento. La latenza su una connessione VoIP è avvertita immediatamente e disturba l'impiego. Ritardi superiori a pochi millisecondi sono inaccettabili per il VoIP.. || ||Streaming video||64 - 200+ Kbps||Come per lo streming audio, l'occasionale latenza è evitata ricorrendo all'uso di buffer sugli utenti. Per funzionare con buona qualità, lo streaming video richiede alto throughput e bassa latenza.|| ||Applicazioni peer-to-peer per il filesharing (BitTorrent, KaZaA, Gnutella, eDonkey, etc.)||0 - infiniti Mbps||Se pure accettano valori arbitrari di latenza, le applicazioni peer-to-peer tendono a saturare tutto il throughput disponibile trasmettendo dati a quanti più utenti possibile, quanto più in fretta possibile. L'impiego di queste applicazioni sarà causa di ritardo e problemi di throughput per tutti gli altri utenti della rete, a meno che non si adottino attente allocazioni di banda.|| Per valutare il throughput necessario per la rete, si moltiplichi il numero di utenti previsti per l'applicazione che verrà presumibilmente richiesta. Per esempio, 50 utenti interessati prevalentemente alla navigazione web consumeranno presumibilmente 2.5 Mbps di throughput, o qualcosa di più nei momenti di punta, ed accetteranno una discreta latenza. Al contrario, 50 utenti VoIP che lavorino nello stesso momento richiederanno almeno 5Mbps di throughput '''in entrambe le direzioni''' con assolutamente nessuna latenza. Dal momento che gli apparati wireless 802.11g sono '''''half-duplex''''' (possono, cioè, alternativamente trasmettere o ricevere, ma non possono compiere le due azioni nello stesso momento), occorrerà di conseguenza raddoppiare il throughput richiesto, per un totale di '''10Mbps'''. I collegamenti wireless dovranno garantire tale capacità ogni secondo, o la conversazione soffrirà di ritardi. Poichè sarà improbabile che tutti gli utilizzatori richiedano la connessione precisamente nello stesso momento, si ricorre comunemente alla pratica detta della '''''sovriscrizione''''' (permettendo, cioè, più utenti di quanto la banda massima possa sostenere). Una sovriscrizione di un fattore da 2 a 5 è piuttosto comune. Con tutta probabilità, la sovriscrizione verrà impiegata nella fase di costruzione dell'infrastruttura di rete. Attraverso l'attenta osservazione del throughput sulla rete, sarà poi possibile pianificare quando incrementare vari segmenti della rete, e quante risorse supplementari siano necessarie. Per quanta capacità verrà fornita, gli utenti troveranno alla fine delle applicazioni che la satureranno. Come si vedrà alla fine di questo capitolo, impiegare tecniche di ''bandwith shaping'' (allocazione di banda) può contribuire a ridurre i problemi di latenza. Ricorrendo al bandwith shaping, al web caching ed ad altre tecniche, si possono ridurre significatamente i valori di latenza, migliorando il throughput complessivo della rete. Per avere un'idea del ritardo avvertito su connessioni molto lente, l'ICTP ha realizzato un simulatore di larghezza di banda. Questo simulatore provvederà a scaricare una pagina web, impiegando la massima velocità e la velocità ridotta secondo le impostazioni che si sceglieranno. Questa dimostrazione offre un'immediata comprensione di come l'utilità di Internet, come strumento di comunicazione, venga ridotta da basso throughput e da alta latenza. Il simulatore è disponibile sotto http://wireless.ictp.trieste.it/simulator/ == Pianificazione del Collegamento == Un sistema di comunicazione base consiste di due radio, ciascuna con la propria antenna, che sono separate dal percorso che dev'essere coperto. Per poter instaurare una comunicazione, le due radio richiedono un segnale minimo che raggiunga le antenne e che venga quindi presentato ai loro ingressi. La determinazione della fattibilità del collegamento è un processo chiamato calcolo del '''''link budget'''''. Se i segnali possano o meno essere scambiati tra le radio dipende dalla qualità dell'attrezzatura usata e dal degrado del segnale dovuto dalla distanza, degrado chimato '''''path loss''''' (perdita di percorso). === Calcolare il link budget === La potenza disponibile in un sistema 802.11 può essere caratterizzata dai due seguenti fattori: * '''''Potenza di Trasmissione'''''. E' espressa in milliwatt o in dBm. La potenza di trasmissione varia dai 30mW ai 200mW o più. La potenza di trasmissione è spesso dipendente dalla velocità della trasmissione stessa. La potenza di trasmissione di un particolare dispositivo dovrebbe essere esplicitata dalla documentazione fornita dal produttore, ma può essere difficile da trovare. Può allora essere d'aiuto la consultazione di database disponibili online, quali quello offerto da Seattle Wireless (http://www.seattlewireless.net/HardwareComparison). * '''''Guadagno d'Antenna'''''. Le antenne sono dispositivi passivi che amplificano il segnale ricevuto grazie alla loro forma fisica. Le antenne presentano la stessa caratteristica in trasmissione ed in ricezione. Un'antenna da 12 dB è tale senza dover specificare se sia in modalità di ricezione o di trasmissione. Le antenne paraboliche presentano un guadagno di 19-24 dB, le antenne omnidirezionali di 5-12 dB, quelle settoriali di 12-15 dB. * '''''Livello minimo di Segnale ricevuto''''' o, semplicemente, la sensibilità del ricevitore. Il minimo RSL (''Received Signal Level'', livello di segnale ricevuto) è sempre espresso in debibel negativi (- dBm) ed è la minima potenza di segnale che la radio riesce a distinguere. Il minimo RSL dipende dalla velocità, e come regola generale la velocità trasmissiva più bassa (1 Mbps) garantisce la sensibilità massima. Tale minimo è, tipicamente, compreso tra i -75 e -95 dBm. Come per la potenza di trasmissione, il dettaglio del RSL dovrebbe essere specificato dal produttore dell'apparato. * '''''Perdite di Cavo'''''. Parte dell'energia del segnale è persa nei cavi, nei connettori ed in altri dispositivi, presenti nel tratto tra l'antenna e la radio. La perdita dipende dal tipo di cavo usato e dalla sua lunghezza. La perdita di segnale per cavi coassiali corti, che includano i connettori, è relativamente bassa, compresa tra i valori di 2-3 dB. E' opportuna mantenere i cavi tra antenna e radio i più corti possibili. Quando si calcola la perdita di percorso, diversi fattori devono essere considerati. Occorre mettere in conto la '''''perdita nello spazio libero''''', la '''''attenuazione''''' e lo '''''scattering'''''. La potenza del segnale si riduce a causa della diffusione geometrica del fronte d'onda, comunemente conosciuta come perdita nello spazio libero. Trascurando il resto, più lontano sono le due radio, minore sarà il segnale ricevuto, a causa delle perdite in spazio libero. Tutto ciò è indipendente dall'ambiente circostante, ma è legato alla sola distanza. Questa perdita si genera perchè l'energia del segnale irradiato si espande secondo una funzione della distanza dal trasmettitore. Impiegando i decibel per esprimere la perdita, ed adottando i 2.45 GHz come frequenza di ricetrasmissione, l'equazione per la perdita in spazio libero diventa: |
| Linea 424: | Linea 447: |
| where Lfsl is expressed in dB and r is the distance between the transmitter and receiver, in meters. The second contribution to the path loss is given by attenuation. This takes place as some of the signal power is absorbed when the wave passes through solid objects such as trees, walls, windows and floors of buildings. Attenuation can vary greatly depending upon the structure of the object the signal is passing through, and it is very difficult to quantify. The most convenient way to express its contribution to the total loss is by adding an "allowed loss" to the free space. For example, experience shows that trees add 10 to 20 dB of loss per tree in the direct path, while walls contribute 10 to 15 dB depending upon the construction. Along the link path, the RF energy leaves the transmitting antenna and energy spreads out. Some of the RF energy reaches the receiving antenna directly, while some bounces off the ground. Part of the RF energy which bounces off the ground reaches the receiving antenna. Since the reflected signal has a longer way to travel, it arrives at the receiving antenna later than the direct signal. This effect is called '''''multipath''''', fading or signal dispersion. In some cases reflected signals add together and cause no problem. When they add together out of phase, the received signal is almost worthless. In same cases, the signal at the receiving antenna can be zeroed by the reflected signals. This is known as '''''nulling'''''. There is a simple technique that is used to deal with multipath, called '''''antenna diversity'''''. It consists in adding a second antenna to the radio. Multipath is in fact a very location-specific phenomenon. If two signals add out of phase at one location, they will not add destructively at a second, nearby location. If there are two antennas, at least one of them should be able to receive a usable signal, even if the other is receiving a distorted one. In commercial devices, antenna switching diversity is used: there are multiple antennas on multiple inputs, with a single receiver. The signal is thus received through only one antenna at a time. When transmitting, the radio uses the antenna last used for reception. The distortion given by multipath degrades the ability of the receiver to recover the signal in a manner much like signal loss. A simple way of applying the effects of scattering in the calculation of the path loss is to change the exponent of the distance factor of the free space loss formula. The exponent tends to increase with the range in an environment with a lot of scattering. An exponent of 3 can be used in an outdoor environment with trees, while one of 4 can be used for an indoor environment. When free space loss, attenuation, and scattering are combined, the path loss is: |
dove Lfsl (attenuazione in spazio libero) è espressa in dB ed r è la distanza tra il trasmettitore ed il ricevitore, espressa in metri. Il secondo contributo alla perdita sul percorso è dato dall'attenuazione, ovvero dall'assorbimento di parte di potenza del segnale nell'attraversamento di ostacoli quali alberi, mura, finestre e pavimenti di edifici. L'attenuazione può variare in modo pesante, dipendendo dalla struttura degli oggetti che il segnale attraversa, ed è di difficile quantificarla. Il modo più semplice per esprimere questo contributo alla perdita totale è quello di aggiungere una "perdita ammissibile" alla perdita in spazio libero. Per esempio, l'esperienza indica che gli alberi aggiungono un 10-20 dB di perdita per albero presente sul percorso, mentre i muri contribuiscono per 10-15 dB, in funzione della costruzione. Sul percorso del collegamento, l'energia RF (Radio-Frequenza) lascia l'antenna trasmittente e si espande. Parte di questa energia raggiunge direttamente l'antenna ricevente, mentre altra vi arriva dopo essere rimbalzata sul terreno. Questo segnale riflesso, avendo percorso un tragitto più lungo di quello diretto, arriva all'antenna ricevente in ritardo, interferendo con il segnale principale. Questo effetto è chiamato '''''multipath''''', fading o dispersione di segnale. In alcuni casi i segnali riflessi si sommano assieme e non causano problemi. Quando si sommano fuori fase, il segnale ricevuto è trascurabile. Ciò viene denominato '''''nulling'''''. Esiste una semplice tecnica per trattare il multipath, chiamata '''''diversità d'antenna''''' (''antenna diversity''): consiste nel dotare la radio di una seconda antenna. Il multipath è infatti un fenomeno fortemente legato al percorso. Se due segnali si annullano in fase in un punto, non si sommeranno distruttivamente in un secondo punto, vicino al primo. Se sono presenti due antenne, almeno una di quete dovrebbe essere in grado di ricevere un segnale utile, anche se l'altra sta ricevendo un segnale distorto. Nei dispositivi commerciali, viene impiegato la diversità d'antenna che ne attiva l'una o l'altra. Il segnale è così ricevuto solo da un'antenna per volta. Quanto trasmette, la radio usa l'antenna che è stata impiegata per ultima nella ricezione. La distorsione causata dal multipath riduce la capacità del ricevitore di ricostruire il segnale in una modo simile alla perdita di segnale. Un modo semplice per inserire gli effetti dello scattering nel calcolo delle perdite di percorso è di cambiare l'esponente del fattore distanza nella formula della perdita in spazio libero. L'esponente tende ad incrementare con il percorso in un ambiente con pesante scattering. Un 3 come esponente può essere usato in un ambiente esterno con alberi, mentre un 4 come esponente è impiegabile per un ambiente interno. Quando si considerano assieme le perdite di spazio libero, l'attenuazione e lo scattering, la perdita di percorso è: |
| Linea 436: | Linea 462: |
| For a rough estimate of the link feasibility, one can evaluate just the free space loss. The environment can bring further signal loss, and should be considered for an exact evaluation of the link. The environment is in fact a very important factor, and should never be neglected. To evaluate if a link is feasible, one must know the characteristics of the equipment being used and evaluate the path loss. Note that when performing this calculation, you should only add the TX power of one side of the link. If you are using different radios on either side of the link, you should calculate the path loss twice, once for each direction (using the appropriate TX power for each calculation). Adding up all the gains and subtracting all the losses gives {{{ TX Power Radio 1 + Antenna Gain Radio 1 - Cable Losses Radio 1 + Antenna Gain Radio 2 - Cable Losses Radio 2 |
Per una valutazione speditiva della fattibilità del collegamento, ci si può limitare a stimare la sola perdita in spazio libero. L'ambiente può apportare ulteriori perdite di segnale, e dovrebbe essere considerato per una valutazione esatta del collegamento. L'ambiente è in effetti un elemento importante, che che non dovrebbe mai essere trascurato. Per valutare se un collegamento sia possibile, si dovrebbero conoscere le caratteristiche del materiale che viene usato e si dovrebbe stimare la perdita di percorso. Si noti che, nel condurre tale calcolo, si debba solo aggiungere la potenza di trasmissione da un capo del collegamento. Se si impiegano radio differenti nei due estremi del collegamento, occorre calcolare due vole la perdita sul percorso, una per ogni direzione, impiegando la corretta potenza di trasmissione per ognuno dei due calcoli. Aggiungendo tutti i guadagni e sottraendo tutte le perdite porta a: {{{ Potenza di Trasmissione della Radio 1 + Guadagno d'Antenna della Radio 1 - Perdite di Cavo della Radio 1 + Guadagno d'Antenna della Radio 2 - Perdite di Cavo della Radio 2 |
| Linea 447: | Linea 473: |
| = Total Gain }}} Subtracting the Path Loss from the Total Gain: {{{ Total Gain - Path Loss |
= Guadagno Totale }}} Sottraendo le perdite di percorso al guadagno totale: {{{ Guadagno Totale - Perdite di Percorso |
| Linea 456: | Linea 482: |
| = Signal Level at one side of the link }}} If the resulting signal level is greater than the minimum received signal level, then the link is feasible! The received signal is powerful enough for the radios to use it. Remember that the minimum RSL is always expressed as a negative dBm, so -56dBm is greater than -70dBm. On a given path, the variation in path loss over a period of time can be large, so a certain margin (difference between the signal level and the minimum received signal level) should be considered. This margin is the amount of signal above the sensitivity of radio that should be received in order to ensure a stable, high quality radio link during bad weather and other atmospheric disturbances. A margin of error of 10-15 dB is fine. To give some space for attenuation and multipath in the received radio signal, a margin of 20dB should be safe enough. Once you have calculated the link budget in one direction, repeat the calculation for the other direction. Substitute the transmit power for that of the second radio, and compare the result against the minimum received signal level of the first radio. === Example link budget calculation === As an example, we want to estimate the feasibility of a 5km link, with one access point and one client radio. The access point is connected to an omnidirectional antenna with 10dBi gain, while the client is connected to a sectorial antenna with 14dBi gain. The transmitting power of the AP is 100mW (or 20dBm) and its sensitivity is -89dBm. The transmitting power of the client is 30mW (or 15dBm) and its sensitivity is -82dBm. The cables are short, with a loss of 2dB at each side. Adding up all the gains and subtracting all the losses for the AP to client link gives: {{{ 20 dBm (TX Power Radio 1) + 10 dBi (Antenna Gain Radio 1) - 2 dB (Cable Losses Radio 1) + 14 dBi (Antenna Gain Radio 2) - 2 dB (Cable Losses Radio 2) |
= Livello di segnale ad un capo del collegamento (al ricevitore della Radio 2) }}} Se il livello di segnale che si ottiene è maggiore del minimo livello di segnale ricevuto, allora il collegamento è fattibile! Il segnale ricevuto è sufficientemente potente per le radio da poter essere usato. Si ricordi che il minimo RSL è sempre espresso in decibel negativi, quindi -56dBm è migliore di -70dBm. Su un dato percorso, la variazione nelle perdite di percorso nel tempo può essere rimarchevole, quindi un certo margine di sicurezza (divverenza tra il livello di segnale ed il minimo livello di segnale ricevuto) dovrebbe essere considerato. Questo margine è la quantità di segnale che, superando la sensibilità della radio, dev'essere ricevuta per garantire un collegamento stabile e di buona qualità anche sotto cattive condizioni meteorologiche o durante altri disturbi atmosferici. Un margine d'errore di 10-15 dB può andar bene. Per garantire spazio all'attenuazione ed al multipath nel segnale ricevuto, un margine di 20dB dovrebbe essere sufficiente. Una volta che si sia calcolato il link budget verso una direzione, occorre ripetere il calcolo nella direzione opporta. Si sostituisca la potenza di trasmissione della seconda radio, e si verifichino i risultati verso il minimo livello di segnale ricevuto della prima radio. === Esempio di Calcolo di link budget === Come esempio, si intenda stimare la fattibilità di un collegamento di 5km, con un access point ed una radio come client. L'access point è connesso ad un'antenna omnidirezionale che ha un guadagno di 10 dBi, mentre il client è connesso ad un'antenna settoriale con guadagno 14dBi. La potenza di trasmissione dell'access point è di 100mW (ovvero, 20dBm), mentre la sua sensibilità è di -89dBm. Per il client, la potenza di trasmissione è di 30mW (o 15dBm) e la sua sensibilità è di -82 dBm. I cavi di connessione tra antenne e radio sono brevi, con una perdita di 2dB a ciascun lato del collegamento radio. Sommando tra loro tutti i guadagni e sottraendo tutte le perdite nel collegamento tra AP e client, si ottiene: {{{ + 10 dBi (Guadagno d'Antenna della Radio 1) - 2 dB (Perdita nel Cavo d'Antenna della Radio 1) + 14 dBi (Guadagno d'Antenna della Radio 2) - 2 dB (Perdita nel Cavo d'Antenna della Radio 2) |
| Linea 476: | Linea 502: |
| 40 dB = Total Gain }}} The path loss for a 5km link, considering only the free space loss is: {{{ Path Loss = 40 + 20log(5000) = 113 dB }}} Subtracting the path loss from the total gain {{{ 40 dB - 113 dB = -73 dB }}} Since -73dB is greater than the minimum receive sensitivity of the client radio (-82dBm), the signal level is just enough for the client radio to be able to hear the access point. There is only 9dB of margin (82dB - 73dB) which will likely work fine in fair weather, but may not be enough to protect against extreme weather conditions. Next we calculate the link from the client back to the access point: {{{ 15 dBm (TX Power Radio 2) + 14 dBi (Antenna Gain Radio 2) - 2 dB (Cable Losses Radio 2) + 10 dBi (Antenna Gain Radio 1) - 2 dB (Cable Losses Radio 1) |
20 dB = Guadagno Totale }}} Trasmettendo quindi una potenza di 20dBm sull'AP, sul client radio - a distanza nulla dall'AP - si riceverebbero un segnale di potenza: {{{ + 20dBm + 20dB ---------------------------------- 40dBm = Potenza Segnale Ricevuto a Distanza Nulla (Prx0) }}} Considerando come il client radio non sia a distanza nulla dall'AP, occorrerà inserire la Perdita di Percorso che, su un collegamento di 5km dove si considera il solo spazio libero, sarà: {{{ Perdita di Percorso(dB) = 40 + 20log(5000) = 113 dB }}} Sottraendo la Perdita di Percorso dalla Potenza del Segnale Ricevuto a Distanza Nulla si ottiene: {{{ 40 dBm - 113 dB = -73 dBm }}} Poichè -73dBm è una potenza magggiore della sensibilità della radio client (-82dBm), il livello di segnale è sufficiente alla radio client per raccogliere la trasmissione dell'access point. Rimangono 9dB di margine (-73dBm - -82dBm) che consentiranno un funzionamento dignitoso quando sia bel tempo, ma che potrebbero rivelarsi insufficienti in caso di avverse condi-meteo. Si calcoli ora il collegamento nella direzione che parte dal client e prosegue verso l'access point: {{{ 15 dBm (Potenza di Trasmissione della Radio 2) + 14 dB (Guadagno d'Antenna della Radio 2) - 2 dB (Perdita nel Cavo d'Antenna della Radio 2) + 10 dB (Guadagno d'Antenna della Radio 1) - 2 dB (Perdita nel Cavo della Radio 1) |
| Linea 502: | Linea 537: |
| 35 dB = Total Gain }}} |
35 dBm = Potenza del Segnale Ricevuto a Distanza Nulla (Prx0) }}} Naturalmente, la Perdita di Percorso è la stessa sul viaggio di ritorno. Il segnale ricevuto sull'access point diventa quindi: |
| Linea 508: | Linea 544: |
| 35 dB - 113 dB = -78 dB }}} Since the receive sensitivity of the AP is -89dBm, this leaves us 11dB of fade margin (89dB - 78dB). Overall, this link will probably work but could use a bit more gain. By using a 24dBi dish on the client side rather than a 14dBi sectorial antenna, you will get an additional 10dBi of gain on both directions of the link (remember, antenna gain is reciprocal). A more expensive option would be to use higher power radios on both ends of the link, but note that adding an amplifier or higher powered card to one end does not help the overall quality of the link. Online tools can be used to calculate the link budget. For example, the Green Bay Professional Packet Radio's Wireless Network Link Analysis (http://my.athenet.net/~multiplx/cgi-bin/wireless.main.cgi) is an excellent tool. The Super Edition generates a PDF file containing the Fresnel zone and radio path graphs. The calculation scripts can even be downloaded from the website and installed locally. We will look at one excellent online tool in more detail in the next section, '''Link planning software'''. The Terabeam website also has excellent calculators available online (http://www.terabeam.com/support/calculations/index.php). === Tables for calculating link budget === To calculate the link budget, simply approximate your link distance, then fill in the following tables: ==== Free Space Path Loss at 2.4GHz ==== ||<style="background-color: #C0C0C0;">Distance (m)||100||500||1,000||3,000||5,000||10,000|| ||<style="background-color: #C0C0C0;">Loss (dB)||80||94||100||110||113||120|| ==== Antenna Gain: ==== ||<rowstyle="background-color: #C0C0C0;">Radio 1 Antenna (dBi)||+ Radio 2 Antenna (dBi)||= Total Antenna Gain|| |
35 dBm - 113 dB = -78 dBm Potenza del Segnale Ricevuto presso l'AP }}} Poichè la sensibilità dell'AP è -89dBm, 11dB sono garantiti come margine (-78dBm - -89dBm). Nel complesso, questo collegamento dovrebbe funzionare, ma si potrebbe puntare ad aumentare il margine di sicurezza del guadagno. Usando un'antenna a parabola (''dish antenna'') a 24dB sul lato client, piuttosto che l'antenna settoriale a 14dB, si otterrebbe un incremento del guadagno di 10dB in entrambe le direzioni del collegamento (si ricordi, infatti, come il guadagno d'antenna sia lo stesso sia in ricezione, che in trasmissione). Un'opzione più costosa potrebbe essere quella di impiegare radio con maggiore potenza ad entrambi i lati del collegamento, ma si osservi come l'aggiunta di un amplificatore, o l'impiego di una scheda radio di maggior potenza, ad un solo lato del collegmamento non ne migliori la qualità complessiva. Strumenti disponibili online possono essere impiegati per calcolare il link budget. Per esempio, il ''Green Bay Professional Packet Radio's Wireless Network Link Analysis'' (http://my.athenet.net/~multiplx/cgi-bin/wireless.main.cgi) è uno strumento eccellente. La ''Super Edition'' genera un file PDF che contiene la zona di Fresnel ed i grafici dei percorsi radio. Gli script di calcolo possono essere scaricati dal sito web ed essere installati sul proprio computer. Si approfondirà l'argomento di un eccellente strumento online nella prossima sezione, ''Software per la Pianificazione del Collegamento''). Anche il sito web Terabeam dispone di un eccellente calcolatore, disponibile online (http://www.terabeam.com/support/calculations/index.php). === Tavole per il Calcolo del Link Budget === Per calcolare il link budget, si approssimi semplicemente la distanza, quindi si ricorra alla tavola seguente: ==== Perdita in Spazio Libero a 2.4GHz ==== ||<style="background-color: #C0C0C0;">Distanza (m)||100||500||1,000||3,000||5,000||10,000|| ||<style="background-color: #C0C0C0;">Perdita (dB)||80||94||100||110||113||120|| ==== Guadagno d'Antenna Totale: ==== ||<rowstyle="background-color: #C0C0C0;">Guadagno d'Antenna Radio 1 (dB)||+ Guadagno d'Antenna Radio 2 (dB)||= Guadagno Totale d'Antenna|| |
| Linea 532: | Linea 568: |
| ==== Losses: ==== ||<rowstyle="background-color: #C0C0C0;">Radio 1 + Cable Loss (dB)||Radio 2 + Cable Loss (dB)||Free Space Path Loss (dB)||= Total Loss (dB)|| |
==== Perdite: ==== ||<rowstyle="background-color: #C0C0C0;">Perdita del Cavo d'Antenna sulla Radio 1 (dB)||Perdita del Cavo d'Antenna sulla Radio 2 (dB)||Perdita in Spazio Libero (dB)||= Perdita Totale (dB)|| |
| Linea 537: | Linea 573: |
| ==== Link Budget for Radio 1 -> Radio 2: ==== ||<rowstyle="background-color: #C0C0C0;">Radio 1 TX Power||+ Antenna Gain||- Total Loss||= Signal||> Radio 2 Sensitivity|| |
==== Link Budget per collegamento Radio 1 -> Radio 2: ==== ||<rowstyle="background-color: #C0C0C0;">Potenza TX Radio 1 (dBm)||+ Guadagno Totale d'Antenna Antenna (dB)||- Perdita Totale (dB)||= Potenza del Segnale Ricevuto (dBm)||> Sensibilità della Radio 2(dBm)|| |
| Linea 543: | Linea 578: |
| ==== Link Budget for Radio 2 -> Radio 1: ==== ||<rowstyle="background-color: #C0C0C0;">Radio 2 TX Power||+ Antenna Gain||- Total Loss||= Signal||> Radio 1 Sensitivity|| |
==== Link Budget per collegamento Radio 2 -> Radio 1: ==== ||<rowstyle="background-color: #C0C0C0;">Potenza TX Radio 2 (dBm)||+ Guadagno Totale d'Antenna Antenna (dB)||- Perdita Totale (dB)||= Potenza del Segnale Ricevuto (dBm)||> Sensibilità della Radio 1(dBm)|| |
| Linea 548: | Linea 583: |
| If the received signal is greater than the minimum received signal strength in both directions of the link, then the link is feasible. === Link planning software === While calculating a link budget by hand is straightforward, there are a number of tools available that will help automate the process. In addition to calculating free space loss, these tools will take many other relevant factors into account as well (such as tree absorption, terrain effects, climate, and even estimating path loss in urban areas). In this section, we will discuss two free tools that are useful for planning wireless links: Green Bay Professional Packet Radio's online interactive network design utilities, and RadioMobile. ==== Interactive design CGIs ==== The Green Bay Professional Packet Radio group (GBPRR) has made a variety of very useful link planning tools available for free online. You can browse these tools online at http://www.qsl.net/n9zia/wireless/page09.html . Since the tools are available online, they will work with any device that has a web browser and Internet access. We will look at the first tool, '''Wireless Network Link Analysis''', in detail. You can find it online at http://my.athenet.net/~multiplx/cgi-bin/wireless.main.cgi . To begin, enter the channel to be used on the link. This can be specified in MHz or GHz. If you don't know the frequency, consult the table in Appendix B. Note that the table lists the channel's center frequency, while the tool asks for the highest transmitted frequency. The difference in the ultimate result is minimal, so feel free to use the center frequency instead. To find the highest transmitted frequency for a channel, just add 11MHz to the center frequency. Next, enter the details for the transmitter side of the link, including the transmission line type, antenna gain, and other details. Try to fill in as much data as you know or can estimate. You can also enter the antenna height and elevation for this site. This data will be used for calculating the antenna tilt angle. For calculating Fresnel zone clearance, you will need to use GBPRR's Fresnel Zone Calculator. The next section is very similar, but includes information about the other end of the link. Enter all available data in the appropriate fields. Finally, the last section describes the climate, terrain, and distance of the link. Enter as much data as you know or can estimate. Link distance can be calculated by specifying the latitude and longitude of both sites, or entered by hand. Now, click the Submit button for a detailed report about the proposed link. This includes all of the data entered, as well as the projected path loss, error rates, and uptime. These numbers are all completely theoretical, but will give you a rough idea of the feasibility of the link. By adjusting values on the form, you can play "what-if?" to see how changing various parameters will affect the connection. In addition to the basic link analysis tool, GBPRR provides a "super edition" that will produce a PDF report, as well as a number of other very useful tools (including the Fresnel Zone Calculator, Distance & Bearing Calculator, and Decibel Conversion Calculator to name just a few). Source code to most of the tools is provided as well. |
Se il segnale ricevuto è maggiore della sensibilità in entrambe le direzioni del collegamento, il collegamento è fattibile. === Software per la Pianificazione del Collegamento === Se il calcolo a mano del link budget è impegnativo, ci sono diversi strumenti a disposizione che possono contribuire ad automatizzare il processo. Oltre a calcolare la Perdita in Spazio Libero, questi strumenti tengono anche conto di diversi altri rilevanti fattori (come assorbimento per gli alberi, effetti del terreno, clima, ed addirittura stime di perdita di percorso in tratte urbane). In questa sezione, si discuterà di due strumenti liberi che sono utili per pianificare collegamenti wireless: le utility per la progettazione interattiva della rete online Green Bay Professional Packet Radio e Radop,pboòe- ==== CGI per il Progetto interattivo ==== Il ''Green Bay Professional Packet Radio group'' (GBPRR) ha realizzato diversi strumenti decisamente utili per pianificare i collegamenti, ponendoli poi gratuitamente a disposizione online. Si possono ricercare sotto http://www.qsl.net/n9zia/wireless/page09.html . Poichè sono su Internet, questi strumenti richiederanno per funzionare il semplice impiego di un navigatore che disponga di accesso ad Internet. Si esaminerà ora il primo strumento di lavoro, il '''Wireless Network Link Analysis'''. E' reperibile online presso: http://my.athenet.net/~multiplx/cgi-bin/wireless.main.cgi . Per iniziare, si inserisca il canale che dev'essere impiegato nel collegamento. Il canale può essere descritto in MHz o GHz. Se la frequenza non è nota, si consulti la tabella in Appendice B. Si osservi come la tabella riporti la frequenza centrale di ogni canale, mentre lo strumento richiede la massima frequenza trasmessa. Per ricavare la massima frequenza trasmessa per un canale, basta addizionare 11MHz alla frequenza centrale. Quindi, si proceda con i dettagli del lato trasmettitore del collegamento, comprendendo il tipo di linea trasmissiva, il guadagno d'antenna, ed altri particolari. Si cerchi di inserire quanti più dati sia possibile, provvedendo eventualmente a stimarli. Si possono inserire anche l'altezza dell'antenna e l'elevazione del sito: questi dati verranno usati per determinare l'angolo di elevazione dell'antenna. Per ricavare la zona libera di Fresnel, sarà necessario usare il calcolatore della zona di Fresnel del GBPRR. La sezione successiva è molto simile, e si riferisce all'altro capo del collegamento. Si inseriscano tutti i dati nei campi relativi. Per finire, l'ultima sezione descrive il clima, il terreno e la distanza del collegamento. Si inseriscano più dati possibili, provvedendo eventualmente a stimarli. La distanza di collegamento può essere calcolata specificando la latitudine e la longitudine di entrami i siti, oppure può essere inserita direttamente a mano. Ora, si clicchi sul bottone ''Submit'' per ottenere un resoconto dettagliato sul link proposto. Questo resoconto include tutti i dati inseriti, così come la perdita di percorso previsto, l'incidenza di errori (''error rate'') ed il periodo di operatività (''uptime''). Questi numeri sono tutti completamente teorici, ma possono offrire un'idea della fattibilità del link. Giocando con i valori inseriti in ingresso, si può provare un "cosa-succede-se", per vedere come la variazione dei parametri influirà sulla connessione. Oltre allo strumento base per l'analisi del collegamento, GBPRR fornisce "un'edizione speciale" che fornirà anche un resoconto in PDF, come pure un numero di altri strumenti molto utili (compreso il calcolatore della zona di Fresnel, il calcolatore delle Distanze & Angoli di Brandeggio, il calcolatore per la conversione in Decibel, giusto per citarne qualcuno). Viene anche fornito il codice sorgente di gran parte di questi strumenti. |
| Linea 574: | Linea 610: |
| Radio Mobile is a tool for the design and simulation of wireless systems. It predicts the performance of a radio link by using information about the equipment and a digital map of the area. It is public domain software that runs on Windows, or using Linux and the Wine emulator. Radio Mobile uses a '''''digital terrain elevation model''''' for the calculation of coverage, indicating received signal strength at various points along the path. It automatically builds a profile between two points in the digital map showing the coverage area and first Fresnel zone. During the simulation, it checks for line of sight and calculates the Path Loss, including losses due to obstacles. It is possible to create networks of different topologies, including net master/slave, point-to-point, and point-to-multipoint. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.9.png|| The software calculates the coverage area from the base station in a point-to-multipoint system. It works for systems having frequencies from 20 kHz to 200 GHz. '''''Digital elevation maps''''' ('''''DEM''''') are available for free from several sources, and are available for most of the world. DEMs do not show coastlines or other readily identifiable landmarks, but they can easily be combined with other kinds of data (such as aerial photos or topographical charts) in several layers to obtain a more useful and readily recognizable representation. You can digitize your own maps and combine them with DEMs. The digital elevation maps can be merged with scanned maps, satellite photos and Internet map services (such as Mapquest) to produce accurate prediction plots. Download Radio Mobile here: http://www.cplus.org/rmw/download.html The main Radio Mobile webpage, with examples and tutorials, is available at: http://www.cplus.org/rmw/english1.html ==== RadioMobile under Linux ==== Radio Mobile will also work using Wine under Ubuntu Linux. While the application runs, some button labels may run beyond the frame of the button and can be hard to read. We were able to make Radio Mobile work with Linux using the following environment: |
Radio Mobile è uno strumento di progetto e simulazione di sistemi wireless. Stima le prestazioni di un collegamento radio impiegando le informazioni disponibili sul materiale e su una mappa digitale dell'area. E' un programma sotto licenza "public domain" che gira sotto Windows, o sotto Linux con l'impiego delle API di Wine. Radio Mobile usa un '''''modello digitale del rilievo del terreno''''' per il calcolo della copertura, indicando la potenza del segnale ricevuto su vari punti lungo il percorso. Costruisce automaticamente un profilo tra due punti sulla mappa digitale, mostrando l'area di copertura e la prima zona di Fresnel. Nella simulazione, controlla la linea di vista e calcola la Perdita di Percorso, includendo le perdite dovute ad ostacoli. E' possibile creare reti di tipologie differenti, comprese le reti master/slave, le punto-punto e le punto-multipunto. ||<:>attachment:figure-3.9.png|| Il software calcola l'area di copertura dalla stazione base in un sistema punto-multipunto. Funziona per sistemi che siano caratterizzati da una frequenza di lavoro dai 20 kHz ai 200 GHz. Le '''''Mappe digitali di Rilievo''''' (DEM, ''Digital Elevation Map'') sono liberamente disponibili da differenti fonti, e sono disponibili per gran parte del mondo. Le DEM non mostrano la linea di costa od altri punti cospicui, rapidamente riconoscibili, ma possono facilmente essere combinate con altri tipi di informazione (quali foto aere, o carte topografiche) su strati differenti, per ottenere una rappresentazione più utile ed immediatamente riconoscibile. Si possono digitalizzare le proprie mappe e combinarle con le DEM. Le mappe digitali di rilievo possono essere combinate con le mappe ottenute dallo scanner, dalle foto satellitari e con i servizi cartografici su Internet (come Mapquest) per costruire dei diagrammi di predizione. Radio Mobile può essere scaricato da qui: http://www.cplus.org/rmw/download.html La pagina principale del sito Radio Mobile, con esempi e tutorial, è disponibile sotto: http://www.cplus.org/rmw/english1.html ==== RadioMobile e Linux ==== Radio Mobile gira anche impiegando Wine con Ubuntu Linux. Mentre l'applicazione funziona, alcuni bottoni possono apparire fuori della propria posizione e possono quindi essere difficili da leggere. A noi è riuscito far funzionare Radio Mobile con Linux impiegando il seguente ambiente: |
| Linea 593: | Linea 629: |
| * Wine version 20050725, from the Ubuntu Universe repository There are detailed instructions for installing RadioMobile on Windows at http://www.cplus.org/rmw/download.html. You should follow all of the steps except for step 1 (since it is difficult to extract a DLL from the VBRUN60SP6.EXE file under Linux). You will either need to copy the MSVBVM60.DLL file from a Windows machine that already has the Visual Basic 6 run-time environment installed, or simply Google for MSVBVM60.DLL, and download the file. Now continue with step 2 at from the above URL, making sure to unzip the downloaded files in the same directory into which you have placed the downloaded DLL file. Note that you don't have to worry about the stuff after step 4; these are extra steps only needed for Windows users. Finally, you can start Wine from a terminal with the command: |
* Wine version 20050725, dall'''Ubuntu Universe repository''' Informazioni dettagliate su come installare Radio Mobile su Wine sono disponibili sotto http://www.cplus.org/rmw/download.html. Sono da seguire tutti i passaggi, ad eccezione del passo 1 (poichè risulta difficile estrarre una libreria DLL dal file VBRUN60SP6.EXE sotto Linux). Si potrà ricorrere od alla copia del file MSVBVM60.DLL da una macchina Windows, che già abbia installato l'ambiente run-time di Visual Basic 6, od allo scarico del file da Internet, dopo aver cercato MSVBVM60.DLL con Google. Si riprenda quindi dal passo 2 dell'URL sopra riportata, assicurandosi di scompattare il file scaricato nella stessa directory nella quale è stato posto il file DLL scaricato. Si osservi come non occorra poi preoccuparsi delle prescrizioni che seguono il passo 4; sono fasi successive che sono necessarie solo per utenti Windows. Alla fine, si può lanciare Wine da un terminale con il comando: |
| Linea 605: | Linea 641: |
| You should see RadioMobile running happily in your XWindows session. === Avoiding noise === The unlicensed ISM and U-NII bands represent a very tiny piece of the known electromagnetic spectrum. Since this region can be utilized without paying license fees, many consumer devices use it for a wide range of applications. Cordless phones, analog video senders, Bluetooth, baby monitors, and even microwave ovens compete with wireless data networks for use of the very limited 2.4GHz band. These signals, as well as other local wireless networks, can cause significant problems for long range wireless links. Here are some steps you can use to reduce reception of unwanted signals. * '''Increase antenna gain on both sides of a point-to-point link. '''Antennas not only add gain to a link, but their increased directionality tends to reject noise from areas around the link. Two high gain dishes that are pointed at each other will reject noise from directions that are outside the path of the link. Using omnidirectional antennas will receive noise from all directions. * '''Don't use an amplifier. '''As we will see in chapter four, amplifiers can make interference issues worse by indiscriminately amplifying all received signals, including sources of interference. Amplifiers also cause interference problems for other nearby users of the band. * '''Use sectorials instead of using an omnidirectional.''' By making use of several sectorial antennas, you can reduce the overall noise received at a distribution point. By staggering the channels used on each sectorial, you can also increase the available bandwidth to your clients. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.10.png|| ||<:>''Figure 3.10: A single omnidirectional antenna vs. multiple sectorials.''|| * '''Use the best available channel.''' Remember that 802.11b/g channels are 22Mhz wide, but are only separated by 5MHz. Perform a site survey (as detailed in chapter eight), and select a channel that is as far as possible from existing sources of interference. Remember that the wireless landscape can change at any time as people add new devices (cordless phones, other networks, etc.) If your link suddenly has trouble sending packets, you may need to perform another site survey and pick a different channel. * '''Use smaller hops and repeaters, rather than a single long distance shot. '''Keep your point-to-point links as short as possible. While it may be possible to create a 12km link that cuts across the middle of a city, you will likely have all kinds of interference problems. If you can break that link into two or three shorter hops, the link will likely be more stable. Obviously this isn't possible on long distance rural links where power and mounting structures are unavailable, but noise problems are also unlikely in those settings. * '''If possible, use 5.8GHz, 900MHz, or another unlicensed band'''. While this is only a short term solution, there is currently far more consumer equipment installed in the field that uses 2.4GHz. Using 802.11a or a 2.4GHz to 5.8GHz step-up device will let you avoid this congestion altogether. If you can find it, some old 802.11 equipment uses unlicensed spectrum at 900MHz (unfortunately at much lower bit rates). Other technologies, such as Ronja (http://ronja.twibright.com/) use optical technology for short distance, noise-free links. * '''If all else fails, use licensed spectrum'''. There are places where all available unlicensed spectrum is effectively used. In these cases, it may make sense to spend the additional money for proprietary equipment that uses a less congested band. For long distance point-to-point links that require very high throughput and maximum uptime, this is certainly an option. Of course, these features come at a much higher price tag compared to unlicensed equipment. To identify sources of noise, you need tools that will show you what is happening in the air at 2.4GHz. We will see some examples of these tools in chapter six. === Repeaters === The most critical component to building long distance network links is '''''line of sight''''' (often abbreviated as '''''LOS'''''). Terrestrial microwave systems simply cannot tolerate large hills, trees, or other obstacles in the path of a long distance link. You must have a clear idea of the lay of the land between two points before you can determine if a link is even possible. But even if there is a mountain between two points, remember that obstacles can sometimes be turned into assets. Mountains may block your signal, but assuming power can be provided they also make very good '''''repeater''''' sites. Repeaters are nodes that are configured to rebroadcast traffic that is not destined for the node itself. In a mesh network, every node is a repeater. In a traditional infrastructure network, nodes must be configured to pass along traffic to other nodes. A repeater can use one or more wireless devices. When using a single radio (called a '''''one-arm repeater'''''), overall efficiency is slightly less than half of the available bandwidth, since the radio can either send or receive data, but never both at once. These devices are cheaper, simpler, and have lower power requirements. A repeater with two (or more) radio cards can operate all radios at full capacity, as long as they are each configured to use non-overlapping channels. Of course, repeaters can also supply an Ethernet connection to provide local connectivity. Repeaters can be purchased as a complete hardware solution, or easily assembled by connecting two or more wireless nodes together with Ethernet cable. When planning to use a repeater built with 802.11 technology, remember that nodes must be configured for master, managed, or ad-hoc mode. Typically, both radios in a repeater are configured for master mode, to allow multiple clients to connect to either side of the repeater. But depending on your network layout, one or more devices may need to use ad-hoc or even client mode. Typically, repeaters are used to overcome obstacles in the path of a long distance link. For example, there may be buildings in your path, but those buildings contain people. Arrangements can often be worked out with building owners to provide bandwidth in exchange for roof rights and electricity. If the building owner isn't interested, tenants on high floors may be able to be persuaded to install equipment in a window. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.11.png|| ||<:>''Figure 3.11: The repeater forwards packets over the air between nodes that have no direct line of sight.''|| If you can't go over or through an obstacle, you can often go around it. Rather than using a direct link, try a multi-hop approach to avoid the obstacle. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.12.png|| ||<:>''Figure 3.12: No power was available at the top of the hill, but it was circumvented by using multiple repeater sites around the base.''|| Finally, you may need to consider going backwards in order to go forwards. If there is a high site available in a different direction, and that site can see beyond the obstacle, a stable link can be made via an indirect route. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.13.png|| ||<:>''Figure 3.13: Site D could not make a clean link to site A or B, since site C is in the way and is not interested in hosting a node. By installing a high repeater, nodes A, B, and D can communicate. Note that traffic from node D actually travels further away from the rest of the network before the repeater forwards it along. ''|| Repeaters in networks remind me of the "six degrees of separation" principle. This idea says that no matter who you are looking for, you need only contact five intermediaries before finding the person. Repeaters in high places can "see" a great deal of intermediaries, and as long as your node is in range of the repeater, you can communicate with any node the repeater can reach. == Traffic optimization == Bandwidth is measured as a bit rate over a time interval. This means that over time, bandwidth available on any link approaches infinity. Unfortunately, for any given period of time, the bandwidth provided by any given network connection is not infinite. You can always download (or upload) as much traffic as you like; you need only wait long enough. Of course, human users are not as patient as computers, and are not willing to wait an infinite amount of time for their information to traverse the network. For this reason, bandwidth must be managed and prioritized much like any other limited resource. You will significantly improve response time and maximize available throughput by eliminating unwanted and redundant traffic from your network. This section describes many common techniques for making sure that your network carries only the traffic that must traverse it. |
A questo punto, si dovrebbe vedere Radio Mobile che funziona nella sessione X Windows. === Eliminare il Rumore === Le bande U-NII e ISM - non soggette a licenza - rappresentano un segmento molto limitato dello spettro elettromagnetico conosciuto. Dato che tale regione può essere impiegata senza corrispondere pagamenti di licenza, molti dispositivi di consumo la impiegano per una vasta serie di applicazioni. Telefoni cordless, ripetitori video, bluetooth, baby monitor ed anche forni a microonde conmpetono con le reti wireless per l'impiego della limitatissima banda su 2.4 GHz. Questi segnali, così come quelli di altre reti wireless, possono comportare problemi significativi per i collegamenti wireless a lunga distanza. Di seguito sono descritti alcune misure che si possono intraprendere per ridurre la ricezione di segnali indesiderati. * '''Aumentare il guadagno d'antenna su entrambi gli estremi del collegamento punto-a-punto''''. Le antenne non solo aumentano il guadagno in un collegamento, ma aumentando la loro direttività si tende ad abbattere il rumore che proviene dalle aree prossime al collegamento. Due antenne a parabola ad alto guadagno, puntate una verso l'altra, ridurranno fortemente il rumore dalle direzioni che sono fuori dal percorso del collegamento. Usando invece antenne omnidirezionali, si raccoglierà il rumore da tutte le direzioni. * '''Non usare un amplificatore''' Come si vedrà nel capitolo quattro, gli amplificatori possono peggiorare i problemi di interferenza, amplificando indiscriminatamente tutti i segnali ricevuti, compreso le sorgenti di rumore. Gli amplificatori causano inoltre problemi di interferenza per altri utenti della stessa banda che siano nelle vicinanze. * '''Usare antenne settoriali anzichè un'antenna omnidirezionale''' Con l'impiego di più antenne settoriali, si può ridurre il rumore complessivo ricevuto ad un punto di distribuzione. Impiegando canali scalati su ciascuna antenna settoriale, si può inoltre aumentare la banda disponibile per i vostri utenti. ||<:>attachment:figure-3.10-ita.png|| ||<:>''Figure 3.10: Confronto tra una singola antenna omnidirezionale e più antenne settoriali''|| * '''Usare il miglior canale disponibile''' Si ricordi che i canali dell'802.11b/g sono ampi 22MHz, ma sono scalati tra loro di appena 5 MHz. Si conduca una ''site survey'' (verifica d'ambiente), come spiegato nel capitolo otto, e si selezioni un canale che sia il più lontano possibile dalle sorgenti di rumore presenti. Si ricordi che il panorama wireless può cambiare in ogni momento, quando le persone inseriscono nuovi dispositivi (telefoni cordless, altre reti, etc.). Se il vostro collegamento registra difficoltà nell'inviare i pacchetti, potrebbe esser necessario condurre un'altra ''site survey'' e scegliere un canale differente. * '''Impiegare salti più ridotti e dei ripetitori, piuttosto che un unico balzo a lunga distanza'''. Si mantengano i collegamenti punto-a-punto i più brevi possibile. Se può essere possibile creare un collegamento di 12km che tagli da parte a parte la città, si creeranno comunque ogni genere di interferenze. Se è possibile spezzare il collegamento unico in due o tre salti più ridotti, il collegamento complessivo risulterà probabilmente più stabile. Naturalmente, ciò non sarà possibile sui collegamenti rurali a lunga distanza, dove l'alimentazione e le infrastrutture non sono disponibili, ma d'altro canto anche i problemi di interferenza in tali condizioni diventano meno probabili. * '''Se possibile, si usino le bande di 5.8GHz, 900MHz od altre bande non soggette a licenza'''. Anche se questa è solo una soluzione a breve termine, ci sono attualmente molti più dispositivi di consumo che impiegano la banda dei 2.4GHz. Impiegando l'802.11a od un dispositivo che porti la banda da 2.4GHz a 5.8GHz si potranno evitare i problemi di congestione. Se si riesce a trovarli, alcuni vecchi apparati wireless (802.11) impiegano la banda libera a 900MHz (sfortunatamente, a bit rate decisamente minori). Altre tecnologie, come Ronja (http://ronja.twibright.com/), impiegano tecnologia ottica per collegamenti a corta distanza, senza interferenze. * '''Se tutto il resto fallisce, adottare lo spettro soggetto a licenza'''. Ci sono posti dove tutto lo spettro libero è impiegato completamente. In questi casi, può essere ragionevole affrontare la spesa addizionale per apparati proprietari che impieghino una banda meno congestionata. Per collegamenti punto-a-punto a lunga portata, che richiedano larga banda e la massima disponibilità, questa è senz'altro un'ozione da valutare. Naturalmente, queste caratteristiche sono ottenibili a prezzi decisamente superiori rispetto all'impiego di apparati per lo spettro libero. Per riconoscere le sorgenti di rumore, sono necessari degli strumenti che esibiscano cosa stia succedendo nell'etere a 2.4GHz. Vedremo di seguito alcuni esempi di tali strumenti nel capitolo sei. === Ripetitori === L'elemento più critico nell'impostare collegamenti di rete sulle lunghe distanze è la '''''linea di vista''''' (spesso abbreviata in '''''LOS''''', ''Line Of Sight''). I sistemi a microonde terrestri non possono tollerare grandi colline, alberi, od altri ostacoli sul percorso di un collegamento a lunga distanza. Occorre disporre di una chiara percezione della disposizione del terreno tra i due punti per poter determinare se il collegamento sia possibile. Ma anche se ci fosse una montagna tra due punti, si ricordi come gli ostacoli possano a volte essere trasformati in vantaggi. Le montagne possono bloccare il segnale, ma nell'ipotesi che l'alimentazione possa essere fornita, possono anche rappresentare ottimi luoghi per i '''''ripetitori'''''. I ripetitori sono nodi che vengono configurati per ritrasmettere un traffico che non è destinato a loro stessi. In una rete a maglia, ogni nodo è un ripetitore. In una rete con infrastruttura tradizionale, i nodi devono essere configurati per inoltrare il traffico verso altri nodi. Un ripetitore può impiegare uno o più dispositivi wireless. Quando si impieghi un solo elemento radio (è il caso detto '''''ripetitore a braccio unico''''', ''one-arm repeater''), l'efficienza totale è sotto la metà della banda disponibile, poichè la radio inviare o ricevere dati in modo alternativo, ma non in contemporanea. Tali dispositivi sono più economici, semplici, ed hanno minori pretese per l'alimentazione. Un ripetitore con due (o più) elementi radio può impiegarli al massimo delle loro capacità, posto che siano configurati su canali che non si sovrappongano. Naturalmente, i ripetitori possono disporre di una connessione Ethernet per garantire connettività locare su cavo. I ripetitori possono essere acquistati come soluzione hardware completa, od essere altrimenti facilmente assemblati aggregando due o più nodi wireless con un cavo Ethernet. Quando si valuti di impiegare un ripetitore basato su tecnologia 802.11, si tenga presente che i nodi devono essere configurati in modalità master, managed od ad-hoc. Tipicamente, entrambi gli elementi radio in un ripetitore sono configurati in modalità master, per consentire a più utenti di connettersi ad entrambi i lati del ripetitore. Ma a seconda della configurazione della rete, uno o più dispositivi possono ricorrere alla modalità ad-hoc od anche a quella client. Tipicamente, i ripetitori sono usati per superare ostacoli sul percorso di un collegamento a lunga distanza. Per esempio, ci possono essere edifici sul percorso, ma questi edifici sono abitati. ACcordi possono spesso essere composti con i proprietari dell'edificio per fornire loro banda come contropartita dei diritti di impiego del tetto e dell'alimentazione elettrica. Se i proprietari dell'edificio non sono interessati, gli inquilini dei piani più alti possono venir persuasi ad installare gli apparati su una finestra. ||<:>attachment:figure-3.11-ita.png|| ||<:>''Figura 3.11: Il ripetitore inoltra i pacchetti in aria tra i nodi che non hanno diretta visibilità.''|| Se non si riesce a scavalcare un ostacolo, si può però spesso aggirarlo. Piuttosto che usare un link diretto, si provi l'approccio a salto multiplo per evitare l'ostacolo. ||<:>attachment:figure-3.12-ita.png|| ||<:>''Figura 3.12: L'alimentazione non era disponibile in cima alla collina, ma si risolse il problema impiegando ripetitori multipli attorno alla base.''|| Infine, si può valutare di compiere un passo indietro per procedere in avanti. Se è disponibile un alto sito in una direzione diversa, e se tale sito ha visibilità oltre l'ostacolo, un collegamento stabile può essere realizzato tramite un percorso indiretto. ||<:>attachment:figure-3.13-ita.png|| ||<:>''Figura 3.13: Il sito D non garantiva un collegamento pulito tra i siti A o B, poichè il sito C è sul percorso e non è interessato ad accogliere un nodo. Con l'installazione di un ripetitore più alto, i nodi A, B e D possono connettersi. Si noti come il traffico dal nodo D in effetti si allontani dal resto della rete, prima di essere rilanciato. ''|| I ripetitori in una rete ricordano il principio de "i sei gradi di separazione". Il concetto spiega come, a prescindere dalla persona ricercata, siano necessari al massimo cinque intermediari per arrivare a contattarla. I ripetitori su alti siti possono "vedere" un gran numero di intermediari e, se il nodo è in vista del ripetitore, diventa possibile connettersi ad ogni altro nodo raggiungibile dal ripetitore. == Ottimizzazione del Traffico == La larghezza di banda viene misurata come quantità di bit su un intervallo di tempo. Sfortunatamente, la banda garantita da qualsiasi connessione di rete non è infinita. Si può sempre scaricare (o caricare) tutto il traffico che si richieda, basta attendere per tempi sufficientemente lunghi. Naturalmente, gli esseri umani non sono utenti pazienti come i computer, e non accettano di aspettare tempi infiniti perchè le proprie informazioni attraversino la rete. Per tale ragione, la larghezza di banda dev'essere gestita e soggetta a priorità, così come ogni altra risorsa limitata. E' possibile migliorare significativamente il tempo di risposta, e massimizzare la velocità di trasferimento, eliminando dalla rete il traffico ridondante o non desiderato. Questa sezione descrive diverse tecniche di uso comune per sincerarsi che la rete trasporti solo il traffico che deve effettivaemente aattraversarla. |
| Linea 662: | Linea 698: |
| A web proxy server is a server on the local network that keeps copies of recently retrieved or often used web pages, or parts of pages. When the next person retrieves these pages, they are served from the local proxy server instead of from the Internet. This results in significantly faster web access in most cases, while reducing overall Internet bandwidth usage. When a proxy server is implemented, the administrator should also be aware that some pages are not cacheable-- for example, pages that are the output of server-side scripts, or other dynamically generated content. The apparent loading of web pages is also affected. With a slow Internet link, a typical page begins to load slowly, first showing some text and then displaying the graphics one by one. In a network with a proxy server, there could be a delay when nothing seems to happen, and then the page will load almost at once. This happens because the information is sent to the computer so quickly that it spends a perceptible amount of time rendering the page. The overall time it takes to load the whole page might take only ten seconds (whereas without a proxy server, it may take 30 seconds to load the page gradually). But unless this is explained to some impatient users, they may say the proxy server has made things slower. It is usually the task of the network administrator to deal with user perception issues like these. ==== Proxy server products ==== There are a number of web proxy servers available. These are the most commonly used software packages: * '''Squid'''. Open source Squid is the de facto standard at universities. It is free, reliable, easy to use and can be enhanced (for example, adding content filtering and advertisement blocking). Squid produces logs that can be analyzed using software such as Awstats, or Webalizer, both of which are open source and produce good graphical reports. In most cases, it is easier to install as part of the distribution than to download it from http://www.squid-cache.org/ (most Linux distributions such as Debian, as well as other versions of Unix such as NetBSD and FreeBSD come with Squid). A good Squid configuration guide can be found at http://squid- docs.sourceforge.net/latest/book-full.html. * '''Microsoft Proxy server 2.0.''' Not available for new installations because it has been superseded by Microsoft ISA server and is no longer supported. It is nonetheless used by some institutions, although it should perhaps not be considered for new installations. * '''Microsoft ISA server.''' ISA server is a very good proxy server program, that is arguably too expensive for what it does. However, with academic discounts it may be affordable to some institutions. It produces its own graphical reports, but its log files can also be analyzed with popular analyzer software such as Sawmill (http://www.sawmill.net/). Administrators at a site with MS ISA Server should spend sufficient time getting the configuration right; otherwise MS ISA Server can itself be a considerable bandwidth user. For example, a default installation can easily consume more bandwidth than the site has used before, because popular pages with short expiry dates (such as news sites) are continually being refreshed. Therefore it is important to get the pre-fetching settings right, and to configure pre-fetching to take place mainly overnight. ISA Server can also be tied to content filtering products such as WebSense. For more information, see: http://www.microsoft.com/isaserver/ and http://www.isaserver.org/ . ==== Preventing users from bypassing the proxy server ==== While circumventing Internet censorship and restrictive information access policy may be a laudable political effort, proxies and firewalls are necessary tools in areas with extremely limited bandwidth. Without them, the stability and usability of the network are threatened by legitimate users themselves. Techniques for bypassing a proxy server can be found at http://www.antiproxy.com/ . This site is useful for administrators to see how their network measures up against these techniques. To enforce use of the caching proxy, you might consider simply setting up a network access policy and trusting your users. In the layout below, the administrator has to trust that his users will not bypass the proxy server. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.14.png|| ||<:>''Figure 3.14: This network relies on trusted users to properly configure their PCs to use the proxy server.''|| In this case the administrator typically uses one of the following techniques: * '''Not giving out the default gateway address through DCHP.''' This may work for a while, but some network-savvy users who want to bypass the proxy might find or guess the default gateway address. Once that happens, word tends to spread about how to bypass the proxy. * '''Using domain or group policies.''' This is very useful for configuring the correct proxy server settings for Internet Explorer on all computers in the domain, but is not very useful for preventing the proxy from being bypassed, because it depends on a user logging on to the NT domain. A user with a Windows 95/98/ME computer can cancel his log-on and then bypass the proxy, and someone who knows a local user password on his Windows NT/2000/XP computer can log on locally and do the same. * '''Begging and fighting with users.''' This is never an optimal situation for a network administrator. The only way to ensure that proxies cannot be bypassed is by using the correct network layout, by using one of the three techniques described below. |
Un Proxy Server web è un server sulla rete locale che mantiene copie delle pagine che siano state recentemente richieste o che siano più spesso richiamate. Quando un nuovo utente richiede queste pagine, queste vengono fornite dal proxy server locale, anzichè essere ricevute via Internet. Ciò si traduce in un accesso web decisamente più veloce, in molti casi, riducendo inoltre l'impiego della banda su Internet. Quando viene realizzato un proxy server, l'amministratore deve tener conto che alcune pagine non sono mantenibili in cache; per esempio, pagine che siano il risultato di script lato server, od altro contenuto generato dinamicamente. Anche il caricamento delle pagine web viene apprezzato in modo diverso. Con un collegamento Internet lento, una pagina web tipica viene caricata lentamente, mostrando prima parte del testo e presentando quindi le figure una dietro l'altra. In una rete con un proxy server, ci possono essere dei ritardi durante i quali sembra non succedere niente, quando finalmente la pagina viene caricata in modo pressochè istantaneo. Ciò succede poichè l'informazione viene inviata dal computer così velocemente che si rende necessario un percettibile intervallo di tempo per costruire la pagina. Il tempo totale che si rende necessario per caricare un'intera pagina può arrivare ai dieci secondi, là ove in mancanza di un proxy server, sarebbero stati necessari 30 secondi per caricare la pagina in modo graduale. Ma se tale fenomeno non viene spiegato ad alcuni utenti impazienti, questi potrebbero lamentarsi della lentezza introdotta dal proxy server. E' normalmente compito dell'amministratore di rete gestire con gli utenti problemi di percezione di questo tipo. ==== Proxy server disponibili ==== Sono diversi i proxy server web disponibili. Di seguito sono elencati i pacchetti software più spesso utilizzati: * '''Squid'''. Il software open source Squid è lo standard de facto presso le università. E' libero, affidabile, facile da impiegare e da estendere (ad esempio, con l'inserimento di filtraggi sui contenuti e con il blocco delle pubblicità). Squid genera file di log che possono essere analizzati con applicativi come Awstats, o Webalizer, entrambi open source ed in grado di generare buoni report grafici. In generale, è più semplice installarlo come parte di una distribuzione specifica, piuttosto che scaricarlo da http://www.squid-cache.org/ (gran parte delle distribuzioni come Debian, così come versioni derivate da Unix come NetBSD e FreeBSD, vengono distribuite già fornite di Squid). Una buona guida per la configurazione di Squid può essere trovata presso http://squid-docs.sourceforge.net/latest/book-full.html. * '''Microsoft Proxy server 2.0.''' Non è disponibile per nuove installazioni, perchè è stato superato da Microsoft ISA server e non è più supportato. E' tuttavia impiegato presso alcuni enti, sebbene non debba forse esser preso in considerazione per nuove installazioni. * '''Microsoft ISA server.''' ISA server è un proxy server decisamente buono, che probabilmente è troppo costoso per ciò che fornisce. Comunque, con gli sconti educational può essere alla portata di alcuni enti. Presenta i propri report grafici, ma i file di log possono essere analizzati anche con i comuni software di analisi come Sawmill (http://www.sawmill.net/). Gli amministratori di un sito che impieghi MS ISA Server dovrebbero dedicare sufficiente impegno per ottenere una configurazione adeguata; in caso contrario, MS ISA Server può tradursi in un consumatore di banda di tutto rispetto. Per esempio, una installazione di default può facilmente consumare più banda di quanta il sito impiegasse precedentemente, perchè le pagine più richieste, con date di scadenza serrate (come quelle dei siti di informazione) vengono continuamente aggiornate. Per questo motivo diventa importante impostare correttamente i modi di caricamento, e configurarli perchè vengano impiegati prevalentemente in orari notturni. ISA Server può anche essere collegato a prodotti per il filtraggio dei contenuti, come WebSense. Per ulteriori informazioni, si veda: http://www.microsoft.com/isaserver/ e http://www.isaserver.org/ . ==== Impedire agli Utenti di aggirare il Proxy Server ==== Se, in generale, evadere la censura su Internet ed eludere le politiche di accesso riservato alle informazioni può essere un impegno politico encomiabile, proxy e firewall rimangono però strumenti necessari nelle aree che dispongano di banda molto limitata. Senza di loro, la stabilità e la disponibilità della rete sarebbero minacciate dagli stessi utenti legittimi. Tecniche per aggirare un proxy server possono essere reperito sotto: http://www.antiproxy.com/ . Questo sito risulta utile agli amministratori per valutare come la propria rete risponda a queste tecniche. Per rendere efficace l'uso di un cache proxy, si potrebbe considerare la semplice impostazione di una politica d'accesso, fidandosi degli utenti. Nella raffigurazione sottostante, l'amministratore deve fidarsi del fatto che i propri utenti non scavalchino il proxy server. ||<:>attachment:figure-3.14-ita.png|| ||<:>''Figura 3.14: In questa rete si confida che gli utenti configurino propriamente i propri PC per l'impiego del proxy server.''|| In questo caso l'amministratore usa, tipicamente, una delle seguenti tecniche: * '''Non presentare l'indirizzo del default gateway attraverso il servizio di DHCP.''' Sulle prime ciò può funzionare, ma qualche utente di rete più smaliziato che intenda scavalcare il proxy server potrebbe trovare - od indovinare - l'indirizzo del default gateway. Una volta che ciò si sia realizzato, la soluzione di come aggirare il proxy tenderà a passare di bocca in bocca. * '''Usare politiche di dominio o di gruppo.''' Ciò è molto utile per impostare correttamente il proxy server per Internet Explorer su tutti i computer del dominio, ma non è molto utile per prevenire l'aggiramento del proxy, perchè dipende dall'utente che si registra nel dominio NT. Un utente, con un computer su Windows 95/98/ME, può cancellare la propria registrazione e quindi scavalcare il proxy, e qualcuno che conosca la password di un utente locale sul suo computer Windows NT/2000/XP può registrarsi localmente e comportarsi in modo analogo. * '''Supplicare ed altercare con gli utenti.''' Non è mai la situazione ideale per l'amministratore di rete. L'unico modo per assicurarsi che i proxy non vengano scavalcati, è adottare la corretta configurazione di rete, impiegando una delle tre tecniche sotto descritte. |
| Linea 693: | Linea 730: |
| A more reliable way to ensure that PCs don't bypass the proxy can be implemented using the firewall. The firewall can be configured to allow only the proxy server through, i.e. to make HTTP requests to the Internet. All other PCs are blocked, as shown in the diagram below. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.15.png|| ||<:>''Figure 3.15: The firewall prevents PCs from accessing the Internet directly, but allows access via the proxy server.''|| Relying on a firewall, as in the above diagram, may or may not be sufficient, depending on how the firewall is configured. If it only blocks access from the campus LAN to port 80 on web servers, there will be ways for clever users to find ways around it. Additionally, they will be able to use other bandwidth hungry protocols such as Kazaa. ==== Two network cards ==== Perhaps the most reliable method is to install two network cards in the proxy server and connect the campus network to the Internet as shown below. In this way, the network layout makes it physically impossible to reach the Internet without going through the proxy server. ||<:>http://wiki.wndw.net/images/figures/en/figure-3.16.png|| ||<:>''Figure 3.16: The only route to the Internet is through the proxy.''|| The proxy server in this diagram should not have IP forwarding enabled, unless the administrators knows exactly what they want to let through. One big advantage to this design is that a technique known as '''''transparent proxying''''' can be used. Using a transparent proxy means that users' web requests are automatically forwarded to the proxy server, without any need to manually configure web browsers to use it. This effectively forces all web traffic to be cached, eliminates many chances for user error, and will even work with devices that do not support use of a manual proxy. For more details about configuring a transparent proxy with Squid, see: |
Un modo più affidabile per assicurarsi che dai PC non si possa aggirare il proxy può essere realizzato impiegando un firewall. Il firewall può essere configurato per permettere al solo proxy server di attraversarlo, cioè a presentare richieste HTTP su Internet. Ogni altro PC è bloccato, come mostrato nella figura sottostante. ||<:>attachment:figure-3.15-ita.png|| ||<:>''Figura 3.15: Il firewall interdice ai PC l'accesso diretto ad Internet, ma lo consente tramite il proxy server.''|| Basarsi su un firewall, come nella rappresentazione sopra citata, può essere sufficiente o meno, in funzione da come sia configurato il firewall. Se questi si limita a bloccare l'accesso dalla LAN di campus verso la porta 80 dei server web, gli utenti smaliziati avranno modo di escogitare delle scappatoie. Inoltre, gli utenti saranno comunque in grado di impiegare protocolli avidi di banda, come Kazaa. ==== Doppia scheda di rete ==== Probabilmente il metodo più sicuro si ottiene installando due schede di rete nel proxy server, connettendo la rete di campus ad Internet come mostrato di seguito. In questo modo, la struttura di rete rende fisicamente impossibile raggiungere Internet senza passare attraverso il proxy server. ||<:>attachment:figure-3.16-ita.png|| ||<:>''Figura 3.16: L'unica percorso verso Internet attraversa il proxy.''|| Il proxy server nella figura non dovrebbe avere impostato l'IP forwarding, a meno che gli amministratore non sappiano esattamente cosa intendano lasciar passare. Un grande vantaggio di questa impostazione è che la tecnica conosciuta come '''''transparent proxying''''' può venire impiegata. Usare un transparent proxy significa deviare automaticamente le richieste web degli utenti al proxy server, senza alcun bisogno di configurare manualmente i singoli web browser affinchè usino il proxy server stesso. Tutto ciò forza l'intero traffico web ad essere messo in cache, elimina diverse possibilità di errore per gli utenti, e funziona pure con ogni dispositivo che non sia in grado di impiegare un proxy impostatovi manualmente. Per maggiori dettagli sulla configurazione di un transparent proxy con Squid, vedere sotto: |
| Linea 714: | Linea 751: |
| ==== Policy-based routing ==== One way to prevent bypassing of the proxy using Cisco equipment is with policy routing. The Cisco router transparently directs web requests to the proxy server. This technique is used at Makerere University. The advantage of this method is that, if the proxy server is down, the policy routes can be temporarily removed, allowing clients to connect directly to the Internet. ==== Mirroring a website ==== With permission of the owner or web master of a site, the whole site can be mirrored to a local server overnight, if it is not too large. This is something that might be considered for important websites that are of particular interest to the organization or that are very popular with web users. This may have some use, but it has some potential pitfalls. For example, if the site that is mirrored contains CGI scripts or other dynamic content that require interactive input from the user, this would cause problems. An example is a website that requires people to register online for a conference. If someone registers online on a mirrored server (and the mirrored script works), the organizers of the site will not have the information that the person registered. Because mirroring a site may infringe copyright, this technique should only be used with permission of the site concerned. If the site runs '''''rsync''''', the site could be mirrored using rsync. This is likely the fastest and most efficient way to keep site contents synchronized. If the remote web server is not running rsync, the recommended software to use is a program called '''''wget'''''. It is part of most versions of Unix/Linux. A Windows version can be found at http://xoomer.virgilio.it/hherold/, or in the free Cygwin Unix tools package (http://www.cygwin.com/). A script can be set up to run every night on a local web server and do the following: * Change directory to the web server document root: for example, * Mirror the website using the command: |
==== Routing impostato su Politiche di Gestione ==== Un modo per evitare l'aggiramento del proxy, ove si impieghino apparati Cisco, è l'adozione di politiche di routing ('''policy routing'''). Il router Cisco dirige le richieste web in modo trasparente verso il proxy server. Questa tecnica è impiegata presso la Makerere University. Il vantaggio di questo metodo è che, se il proxy è fuori servizio, le rotte fissate dal policy routing possono essere temporaneamente sospese, consentendo agli utenti di connettersi direttamente ad Internet. ==== Mirroring di un Sito web ==== Con il permesso del suo proprietario o del suo web master, l'intero contenuto di un sito web può essere posto in mirroring ("ricopiato") in un server locale, nelle ore notturne, se non è troppo corposo. Tale azione potrebbe essere valutata per i siti web di rilievo che possano essere di interesse per l'organizzazione o che possano risultare molto popolari tra gli utenti web. Può essere utile, ma ci possono essere anche potenziali svantaggi. Ad esempio, se il sito che viene ricostruito in locale contiene script CGI od altro contenuto dinamico che richieda un'interazione da parte dell'utente, ciò potrebbe causare problemi. Un esempio è quello di un sito web che richieda ai visitatori di registrarsi on link per una conferenza. Se qualcuno si registra on line su un server ricopiato (e se gli script ricopiati funzionano), chi organizza il sito originale non avrà le informazioni della persona che si è registrata. Dato che il mirroring di un sito potrebbe ledere i diritti di autore, questa tecnica dovrebbe essere usata solo dietro l'autorizzazione del sito interessato. Se il sito ha in funzione il comando '''''rsync''''', lo stesso sito può essere ricopiato impiegando lo stesso comando rsync. E' questo, probabilmente, il modo più veloce e più efficiente per mantenere sincronizzato il contenuto tra i due siti. Se il web server remoto non impiega rsync, il software che si raccomanda di usare è un programma chiamato '''''wget'''''. E' presente in gran parte delle distribuzioni di Unix/Linux. Una versione per Windows può essere reperita sotto http://xoomer.virgilio.it/hherold/, o nel pacchetto di tool liberi di Cygwin Unix (http://www.cygwin.com/). Uno script può essere impostato perchè si attivi ogni notte su un web server locale, e conduca le seguenti azioni: * Cambi la directory portandosi nella radice dei documenti del server web: per esempio, * Effettui il mirroring del sito web impiegando il comando: |
| Linea 733: | Linea 770: |
| The mirrored website will be in a directory '''www.python.org'''. The web server should now be configured to serve the contents of that directory as a name-based virtual host. Set up the local DNS server to fake an entry for this site. For this to work, client PCs should be configured to use the local DNS server(s) as the primary DNS. (This is advisable in any case, because a local caching DNS server speeds up web response times). ==== Pre-populate the cache using wget ==== Instead of setting up a mirrored website as described in the previous section, a better approach is to populate the proxy cache using an automated process. This method has been described by J. J. Eksteen and J. P. L. Cloete of the CSIR in Pretoria, South Africa, in a paper entitled '''Enhancing International World Wide Web Access in Mozambique Through the Use of Mirroring and Caching Proxies'''. In this paper (available at http://www.isoc.org/inet97/ans97/cloet.htm) they describe how the process works: ''"An automatic process retrieves the site's home page and a specified number of extra pages (by recursively following HTML links on the retrieved pages) through the use of a proxy. Instead of writing the retrieved pages onto the local disk, the mirror process discards the retrieved pages. This is done in order to conserve system resources as well as to avoid possible copyright conflicts. By using the proxy as intermediary, the retrieved pages are guaranteed to be in the cache of the proxy as if a client accessed that page. When a client accesses the retrieved page, it is served from the cache and not over the congested international link. This process can be run in off-peak times in order to maximize bandwidth utilization and not to compete with other access activities."'' The following command (scheduled to run at night once every day or week) is all that is needed (repeated for every site that needs pre-populating). |
La copia del sito web si troverà nella directory '''www.python.org'''. Il web server dovrebbe quindi essere configurato per fornire i contenuti di questa directory su un host virtuale basato sui nomi. Si imposti un server DNS locale che presenti una registrazione fittizia per questo sito. Affinchè tutto ciò funzioni, i PC client dovrebbero essere configurati per impiegare il server DNS locale come DNS primario (Ciò è comunque consigliabile in ogni caso, perchè un DNS locale velocizza i tempi di risposta per le richieste web). ==== Arricchire preventivamente la cache impiegando wget ==== Invece di impostare una copia locale di un sito web, come descritto nella precedente sezione, un approccio migliore è arricchire la cache del proxy adottando un processo automatico. Questo metodo è stato descritto da J. J. Eksteen e J. P. L. Cloete del CSIR di Pretoria, South Africa, in un documento intitolato '''Enhancing International World Wide Web Access in Mozambique Through the Use of Mirroring and Caching Proxies'''. In questo documento (disponibile presso http://www.isoc.org/inet97/ans97/cloet.htm) i due autori descrivono il funzionamento del procedimento: ''"Un processo automatico recupera l'home page del sito ed un numero specificato di pagine ulteriori (seguendo in modo ricorsivo i link HTML delle pagine già raccolte) per mezzo di un proxy. Invece di scrivere le pagine recuperate sull'hard disk locale, il processo di copia elimina le pagine scaricate. Tutto ciò viene fatto per conservare le risorse di sistema e per evitare possibili conflitti sul diritto d'autore. Usando il proxy come intermediario, si garantisce che le pagine scaricate siano nella cache del proxy, come se un utente avesse avuto accesso a quelle pagine. Quando un utente richiede le pagine già richiamate, gli vengono presentate quelle disponibili nella cache, senza congestionare il collegamento internazionale. Questo processo può essere condotto al di fuori delle ore di punta, con il fine di massimizzare l'impiego della banda e di non interferire con altre attività."'' Il comando seguente (impostato per essere eseguito di notte, ogni giorno o settimana) è tutto ciò che si rende necessario (ripetendolo per ogni sito per cui si richieda l'arricchimento preventivo della cache). |
| Linea 747: | Linea 784: |
Explanation: * '''-m''': Mirrors the entire site. wget starts at www.python.org and follows all hyperlinks, so it downloads all subpages. * '''--proxy-on''': Ensures that wget makes use of the proxy server. This might not be needed in set-ups where a transparent proxy is employed. * '''--cache=off''': Ensures that fresh content is retrieved from the Internet, and not from the local proxy server. * '''--delete after''': Deletes the mirrored copy. The mirrored content remains in the proxy cache if there is sufficient disk space, and the proxy server caching parameters are set up correctly. In addition, wget has many other options; for example, to supply a password for websites that require them. When using this tool, Squid should be configured with sufficient disk space to contain all the pre-populated sites and more (for normal Squid usage involving pages other than the pre-populated ones). Fortunately, disk space is becoming ever cheaper and disk sizes are far larger than ever before. However, this technique can only be used with a few selected sites. These sites should not be too big for the process to finish before the working day starts, and an eye should be kept on disk space. ==== Cache hierarchies ==== When an organization has more than one proxy server, the proxies can share cached information among them. For example, if a web page exists in server A's cache, but not in the cache of server B, a user connected via server B might get the cached object from server A via server B. '''''Inter-Cache Protocol''''' ('''''ICP''''') and '''''Cache Array Routing Protocol''''' ('''''CARP''''') can share cache information. CARP is considered the better protocol. Squid supports both protocols, and MS ISA Server supports CARP. For more information, see http://squid-docs.sourceforge.net/latest/html/c2075.html. This sharing of cached information reduces bandwidth usage in organizations where more than one proxy is used. ==== Proxy specifications ==== On a university campus network, there should be more than one proxy server, both for performance and also for redundancy reasons. With today's cheaper and larger disks, powerful proxy servers can be built, with 50 GB or more disk space allocated to the cache. Disk performance is important, therefore the fastest SCSI disks would perform best (although an IDE based cache is better than none at all). RAID or mirroring is not recommended. It is also recommended that a separate disk be dedicated to the cache. For example, one disk could be for the cache, and a second for the operating system and cache logging. Squid is designed to use as much RAM as it can get, because when data is retrieved from RAM it is much faster than when it comes from the hard disk. For a campus network, RAM memory should be 1GB or more: * Apart from the memory required for the operating system and other applications, Squid requires 10 MB of RAM for every 1 GB of disk cache. Therefore, if there is 50 GB of disk space allocated to caching, Squid will require 500 MB extra memory. * The machine would also require 128 MB for Linux and 128 MB for X-windows. * Another 256 MB should be added for other applications and in order that everything can run easily. Nothing increases a machine's performance as much as installing a large amount of memory, because this reduces the need to use the hard disk. Memory is thousands of times faster than a hard disk. Modern operating systems keep frequently accessed data in memory if there is enough RAM available. But they use the page file as an extra memory area when they don't have enough RAM. === DNS caching and optimization === Caching-only DNS servers are not authoritative for any domains, but rather just cache results from queries asked of them by clients. Just like a proxy server that caches popular web pages for a certain time, DNS addresses are cached until their '''''time to live''''' ('''''TTL''''') expires. This will reduce the amount of DNS traffic on your Internet connection, as the DNS cache may be able to satisfy many of the queries locally. Of course, client computers must be configured to use the caching-only name server as their DNS server. When all clients use this server as their primary DNS server, it will quickly populate a cache of IP addresses to names, so that previously requested names can quickly be resolved. DNS servers that are authoritative for a domain also act as cache name-address mappings of hosts resolved by them. |
Spiegazione: * '''-m''': ricopia (mirror) l'intero sito. Wget parte da www.python.org e segue tutti i link ipertestuali, sì da scaricare tutte le pagine sottostanti. * '''--proxy-on''': assicurati che wget faccia uso del proxy server. Può non essere necessario nelle impostazioni dove sia impiegato un trasparent proxy * '''--cache=off''': assicurati che i contenuti aggiornati siano scaricati da Internet, e non dal proxy server locale. * '''--delete after''': cancella la copia costruita. Il contenuto in copia rimane nella cache del proxy fintantochè ci sia sufficiente spazio nel disco e posto che i parametri di cache del proxy siano impostati correttamente. Wget dispone di molte altre opzioni in aggiunta a queste; per esempio, per passare la password per un sito web che la richieda. Quando si impiega questo strumento, Squid dovrebbe essere configurato con sufficiente spazio sul disco per contenere tutti i siti precaricati ed altro (intendendo per altro il normale impiego di Squid rivolto a pagine esterne a quelle dei siti precaricati). Fortunatamente, lo spazio sui dischi rigidi diventa sempre più economico e le dimensioni dei dischi sono sempre più ampie. Comunque, questa tecnica può essere usata solo con pochi siti selezionati. Questi siti non dovrebbere essere troppo grossi, affinchè si completi il processo prima che ricominci l'orario di lavoro, ed inoltre occorre sempre monitorare lo spazio libero disponibile sul disco. ==== Gerarchie di Cache ==== Se un organizzazione dispone di più proxy server, questi possono condividere informazioni di cache tra di loro. Per esempio, se una pagina web esiste nella cache del server A, ma non nella cache del server B, un utente collegato sul server B potrebbe ottenere l'oggetto dalla cache di A tramite B. '''''Inter-Cache Protocol''''' ('''''ICP''''') and '''''Cache Array Routing Protocol''''' ('''''CARP''''') possono permettere la condivisione di informazioni di cache. CARP è considerato migliore. Squid supporta entrambi i protocolli, mentre Microsoft ISA Server supporta il solo CARP. Per maggiori informazioni, vedere sotto: http://squid-docs.sourceforge.net/latest/html/c2075.html . Tale condivisione delle informazioni di cache riduce l'impiego di banda esterna nelle organizzazioni dove siano disponibili più proxy server. ==== Specifiche per Proxy ==== Su una rete di campus universitaria dovrebbero insistere più proxy server, sia per migliorare le prestazioni che per ragioni di ridondanza. Con i dischi rigidi odierni, più economici e capienti, si possono costruire potenti proxy server, con spazio disco di 50 GB e più dedicato alla cache. La prestazione del disco è essenziale, quindi i dischi SCSI, più veloci, sono in grado di offrire prestazioni migliori (sebbene una cache basata su dischi IDE sia comunque meglio di niente). RAID e mirroring non sono raccomandati. E' inoltre consigliabile che un disco rigido separato sia dedicato alla cache. Per esempio, un disco rigido può essere impiegato per la cache, mentre un secondo per il sistema operativo e per la registrazione degli eventi (logging) della cache. Squid è progettato per impiegare quanta più RAM possibile, perchè quando i dati sono estratti dalla RAM si raggiungono velocità decisamente superiori a quelle ottenibili sugli hard disk. Per una rete di campus, la memoria RAM dovrebbe essere di 1 GB o più: * Oltre alla memoria richiesta dal sistema operativo e dalle altre applicazioni, Squid richiede 10 MB di RAM per ogni GB di cache di disco. Quindi, se 50 GB di disco vengono assegnati alla cache, Squid richiederà 500 MB di memoria in più. * La macchina richiederebbe inoltre 128 MB per Linux e 128 MB per X-Windows. * Altri 256 MB dovrebbero essere aggiunti per altre applicazioni; sotto queste condizioni di lavoro, dovrebbe filare tutto liscio. Niente migliora le prestazioni di una macchina quanto installare un'ampia memoria, perchè ciò riduce la necessità di ricorrere agli hard disk. La memoria è migliaia di volte più veloce di un hard disk. I moderni sistemi operativi mantengono in memoria i dati frequentemente richiesti, se si rende impiegabile sufficiente RAM. Ma ricorrono a memoria virtuale (swap) quando non dispongono di abbastanza RAM. === DNS caching ed ottimizzazione === I server DNS caching-only non sono autorevoli per nessun dominio, forniscono piuttosto risultati dalla cache a fronte di interrogazioni presentate dai client loro attestati. Come un proxy server arricchisce di pagine web popolari la propria cache durante un periodo prefissato, gli indirizzi DNS sono posti in cache fintantochè il proprio '''''time to live''''' ('''''TTL''''') non si estingua. Ciò ridurrà il traffico DNS sulla vostra connessione Internet, poichè la cache DNS sarà in grado di rispondere localmente e molte interrogazioni. Naturalmente, i computer client devono essere configurati per impiegare i server DNS caching-only, come server DNS di riferimento. Quando tutti i client impiegano questo server come proprio server DNS primario, questi si arricchirà presto la cache di indirizzi, sì da poter rapidamente risolvere gli indirizzi che siano stati già richiesti. I server DNS che sono autorevoli per un dominio agiscono anche come riferimento nomi-indirizzi per i computer di cui curano la diffusione dell'indirizzo IP. |
| Linea 777: | Linea 817: |
| Bind is the de facto standard program used for name service on the Internet. When Bind is installed and running, it will act as a caching server (no further configuration is necessary). Bind can be installed from a package such as a Debian package or an RPM. Installing from a package is usually the easiest method. In Debian, type | Bind è il programma standard di fatto per il ''name service'' in Internet. Installato e avviato, Bind funziona come caching server (nessuna ulteriore configurazione è necessaria). Bind può essere installato da un pacchetto tipo pacchetto Debian o tipo RPM. L'installazione da un pacchetto è normalmente il metodo più semplice. Su Debian, digitare: |
| Linea 783: | Linea 823: |
| In addition to running a cache, Bind can also host authoritative zones, act as a slave to authoritative zones, implement split horizon, and just about everything else that is possible with DNS. | Oltre a mandare in esecuzione una cache, Bind può anche gestire zone autorevoli, può prestare servizi sotto altre zone autorevoli, può realizzare segmenti di spazi indirizzi, e pressochè ogni altra funzione che è possibile svolgere con il DNS. |
| Linea 787: | Linea 827: |
| One alternative caching DNS server is '''''dnsmasq'''''. It is available for BSD and most Linux distributions, or from http://freshmeat.net/projects/dnsmasq/. The big advantage of dnsmasq is flexibility: it easily acts as both a caching DNS proxy and an authoritative source for hosts and domains, without complicated zone file configuration. Updates can be made to zone data without even restarting the service. It can also serve as a DHCP server, and will integrate DNS service with DHCP host requests. It is very lightweight, stable, and extremely flexible. Bind is likely a better choice for very large networks (more than a couple of hundred nodes), but the simplicity and flexibility of dnsmasq makes it attractive for small to medium sized networks. | Un caching server DNS alternativo può essere '''''dnsmasq'''''. E' disponibile per BSD e per la più parte delle distribuzioni Linux, o dal sito http://freshmeat.net/projects/dnsmasq/ . Il maggior vantaggio di dnsmasq è la flessibilità; può funzionare facilmente sia come caching DNS proxy e come riferimento autorevole per macchine e domini, senza complicate configurazione dei file di zona. Gli aggiornamenti possono essere inseriti nei dati di zona senza nemmeno dover far riavviare il servizio. Può anche funzionare come DHCP server, e integrerà il servizio di DNS con le richieste DHCP delle macchine in rete. E' decisamente snello, stabile, ed estremamente flessibile. Bind è probabilmente una scelta indovinata per reti estese (oltre qualche centinaio di nodi), ma la semplicità e la flessibilità di dnsmasq lo rendono interessante per reti di dimensioni medio-piccole. |
| Linea 791: | Linea 831: |
| To install the DNS service on Windows NT4: select Control Panel -> Network -> Services -> Add -> Microsoft DNS server. Insert the Windows NT4 CD when prompted. Configuring a caching-only server in NT is described in Knowledge Base article 167234. From the article: ''"Simply install DNS and run the Domain Name System Manager. Click on DNS in the menu, select New Server, and type in the IP address of your computer where you have installed DNS. You now have a caching-only DNS server."'' |
Per installare il servizio DNS su Windows NT4: selezionale il Pannello di Controllo -> Rete -> Servizi -> Aggiungi -> Microsoft DNS server. Inserire il CD NT4 di Windows quando richiesto. La configurazione di un server caching-only in NT è descritta nell'articolo 167234 della Knowledge Base. Dall'articolo: ''"Installare semplicemente DNS e lanciare il Domain Name System Manager. Cliccare su DNS nel menù, selezionare Nuovo Server, ed inserire l'indirizzo IP del vostro computer dove è stato installato il DNS. Avete ora un server DNS caching-only."'' |
| Linea 797: | Linea 839: |
| Install DNS service: Start -> Settings -> Control Panel -> Add/Remove Software. In Add/Remove Windows Components, select Components -> Networking Services -> Details -> Domain Name System (DNS). Then start the DNS MMC (Start -> Programs -> Administrative Tools -> DNS) From the Action menu select "Connect To Computer..." In the Select Target Computer window, enable "The following computer:" and enter the name of a DNS server you want to cache. If there is a . [dot] in the DNS manager (this appears by default), this means that the DNS server thinks it is the root DNS server of the Internet. It is certainly not. Delete the . [dot] for anything to work. ==== Split DNS and a mirrored server ==== The aim of split DNS (also known as '''''split horizon''''') is to present a different view of your domain to the inside and outside worlds. There is more than one way to do split DNS; but for security reasons, it's recommended that you have two separate internal and external content DNS servers (each with different databases). Split DNS can enable clients from a campus network to resolve IP addresses for the campus domain to local RFC1918 IP addresses, while the rest of the Internet resolves the same names to different IP addresses. This is achieved by having two zones on two different DNS servers for the same domain. One of the zones is used by internal network clients and the other by users on the Internet. For example, in the network below the user on the Makerere campus gets http://www.makerere.ac.ug/ resolved to 172.16.16.21, whereas a user elsewhere on the Internet gets it resolved to 195.171.16.13. The DNS server on the campus in the above diagram has a zone file for makerere.ac.ug and is configured as if it is authoritative for that domain. In addition, it serves as the DNS caching server for the Makerere campus, and all computers on the campus are configured to use it as their DNS server. The DNS records for the campus DNS server would look like this: |
Per installare il servizio DNS: Menù d'avvio -> Impostazioni -> Pannello di controllo -> Aggiungi / Rimuovi Software. Tra i componenti di "Aggiungi / Rimuovi Software", selezionare Componenti -> Servizi di Rete -> Dettagli -> Domain Name System (DNS). Quindi avviare l'MMC di DNS (Menù di Avvio -> Programmi -> Strumenti di Gestione -> DNS). Dal Menù delle azioni selezionare "Collegare al computer...". Nella finestra "Seleziona il computer target", attivare "Il seguente computer:" ed inserire il nome di un server DNS che si intenda portare nella propria cache. Se è presente un "." [punto] nel manager DNS (appare di default), significa che il server DNS ritiene di essere il server DNS di root di Internet. Senz'altro si sbaglia. Cancellare il "." [punto] per rendere funzionante il tutto. ==== DNS separato e server ricopiato ==== Lo scopo di un DNS separato (''split DNS'', conosciuto anche come '''''orizzonte separato''''', ''split horizon'') è presentare una visione del dominio dall'interno differente da quella del mondo esterno. Esistono diversi accorgimenti per realizzare un DNS separato; per motivi di sicurezza, è consigliabile disporre di due differenti server DNS (ciascuno con un proprio database), uno interno ed uno esterno al dominio. Il DNS separato può rendere possibile per dei client di una rete di campus risolvere gli indirizzi IP del dominio del campus in indirizzi locali IP secondo lo standard RFC1918, mentre il resto di Internet traduce gli stessi nomi in indirizzi IP differenti. Tutto ciò si realizza mantenendo due zone su due differenti server DNS relativi allo stesso dominio. Una delle zone viene impiegata dai client di rete interni, mentre l'altra viene usata dagli utenti esterni di Internet. Per esempio, nella rete sottostante l'utente nel campus Makerere ottiene la risoluzione di http://www.makerere.ac.ug in 172.16.16.21, mentre un utente in qualsiasi altra parte di Internet ottiene invece la risoluzione in 195.171.16.13. Il server DNS nel campus del disegno sopra riportato mantiene una file di zona per makerere.ac.ug ed è configurato come autorevole per tale dominio. Inoltre, funge come server DNS di cache per il campus Makerere, e tutti i computer nel campus sono configurati per impiegarlo come proprio server DNS. I record DNS per il server DNS di campus apparirebbero simili a quanto segue: |
| Linea 821: | Linea 866: |
| But there is another DNS server on the Internet that is actually authoritative for the ''makerere.ac.ug'' domain. The DNS records for this external zone would look like this: | Ma c'è un secondo server DNS presente in Internet che è in effetti autorevole per il dominio ''makerere.ac.ug''. I record DNS per questa zona esterna risulterebbero come segue: |
| Linea 831: | Linea 876: |
| Split DNS is not dependent on using RFC 1918 addresses. An African ISP might, for example, host websites on behalf of a university but also mirror those same websites in Europe. Whenever clients of that ISP access the website, it gets the IP address at the African ISP, and so the traffic stays in the same country. When visitors from other countries access that website, they get the IP address of the mirrored web server in Europe. In this way, international visitors do not congest the ISP's VSAT connection when visiting the university's website. This is becoming an attractive solution, as web hosting close to the Internet backbone has become very cheap. | Il DNS separato non è vincolato all'impiego di indirizzi secondo lo standard RFC1918. Un ISP africano potrebbe, per esempio, mantenere siti web per conto di una università, ma anche mantenere copia degli stessi siti web in Europa. Ogni volta che i client di tale ISP provassero ad accedere al sito web, otterrebbero l'indirizzo IP presso l'ISP africano, mantenendo così il traffico all'interno dello stesso Paese. Quanto i visitatori di altri Paesi dovessero accedere al sito web, questi otterrebbero gli indirizzi IP dei siti web ricopiati in Europa. In questo modo, i visitatori internazionali non congestionerebbero i collegamenti satellitari (VSAT) impiegati dall'ISP per visitare il sito web dell'Università. Tale soluzione sta divendanto un'opzione allettante, poichè l'hosting web in prossimità della dorsale Internet è divendato decisamente economico.. |
| Linea 843: | Linea 889: |
| ||<:>http://wiki.wndw.net/images/figures/en/figure-3.17.png|| | ||<:>attachment:figure-3.17-ita.png|| |
Progetto della Rete
Prima di acquistare del materiale o di decidersi sulla piattaforma hardware da adottare, occorre farsi una chiara idea sulla natura del problema di comunicazione. Probabilmente, state leggendo questo libro perchè intendete collegare tra loro reti di computer, al fine di condividere risorse fino a raggiungere la più estesa Internet. Il progetto di rete che scegliete di realizzare dovrà rispondere alle esigenze di comunicazione che state tentando di soddisfare. Dovete connettere un sito remoto ad una connessione Internet nel centro del vostro campus universitario? La vostra rete potrà presumibilmente crescere, fino ad includere diversi siti remoti? La maggior parte dei vostri componenti di rete sarà installata in postazioni fisse, o la vostra rete si espanderà fino a comprendere centinaia di portatili ed altri dispositivi che migrano da una cella all'altra?
Quando si affronta un problema complesso, si rivela spesso utile tracciare un grafico delle risorse a disposizione e del problema. In questo capitolo, daremo un'occhiata alle modalità che altre persone hanno scelto per costruire reti wireless in grado di soddisfare le proprie esigenze di comunicazione, comprendendo anche i diagrammi essenziali delle strutture di reti. Procederemo quindi con l'affrontare i concetti di networking che definiscono la suite TCP/IP, ovvero il principale linguaggio del networking che si impiega su Internet. Dimostreremo diversi metodi ormai comuni per ottenere che l'informazione fluisca efficacemente attraverso la vostra rete verso il resto del mondo.
Progettare la rete fisica
Potrebbe sembrare bizzarro parlare della rete "fisica" quando si costruiscono reti wireless. Dopo tutto, dov'è la parte fisica della rete? Nelle reti wireless, il mezzo fisico che impieghiamo per la comunicazione è, ovviamente, l'energia elettromagnetica. Ma nel contesto di questo capitolo, il termine "rete fisica" intende riferirsi al banale concetto di dove mettere le cose. Dove sistemare l'attrezzatora, in modo che sia possibile raggiungere i client wireless? Sia che si intenda coprire l'area di un edificio o che si intenda coprire diversi chilometri, le reti wireless sono suddivise in queste tre configurazioni logiche:
collegamenti punto-punto (point-to-point links)
collegamento punto-multipunto (point-to-multipoint links)
reti multipunto-multipunto (multipoint-to-multipoint clouds)
La struttura di rete fisica da adottare dipenderà dalla natura del problema che si intende risolvere. Mentre parti differenti della rete possono sfruttare ognuna delle citate configurazioni, ogni singolo collegamento ricadrà in una delle tre tipologia sopra riportate. L'applicazione di ciascuna di tali tipologie è meglio spiegata con degli esempi.
Punto-Punto
Collegamenti punto-a-punto (Point-to-point links) garantiscono, tipicamente, una connessione Internet dove l'accesso non sia altrimenti disponibile. Ad un capo di tale collegamento verrà offerta la connessione ad Internet, mentre all'altro estremo Internet viene connessa. Per esenpio, una univesità può disporre di una connessione veloce di tipo frame relay o VSAT al centro del campus, ma non può permettersi lo stesso tipo di connessione per un edificio distaccato. Se l'edificio principale gode di una visuale libera verso il sito distaccato, una connessione punto-a-punto può essere impiegata per connettere assieme i due edifici. Con tale accorgimento, si puossono estendere come capapacità, od addirittura sostituire, i collegamenti di tipo telefonico già esistenti. Con antenne adatte e visuale libera, sono possibili collegamenti affidabili punto-a-punto anche oltre i trenta chilometri.
attachment:figure-3.1-ita.png |
Figura 3.1: Un collegamento punto-a-punto permette ad un sito distaccato di attingere ad una connessione Internet centrale. |
Naturalmente, una volta che una connessione punto-punto è stata messa in piedi, altre connessioni possono essere impiegate per estendere la rete ulteriormente. Se l'edificio distaccato del nostro esempio è in cima ad una collina, può essere in visibilità di altre importanti aree che non sarebbero direttamente visibili dal campus centrale. Installando un secondo collegamento punto-punto sul sito remoto, un altro nodo può raggiungere la rete e far così uso della connessione centrale verso Internet.
I collegamenti punto-punto non devono, necessariamente, riguardare l'accesso ad Internet. Supponiamo per esempio di dover condurre una stazione di monitoraggio ambientale, su di una collina, con lo scopo di raccogliere i dati che questa registra nel tempo. Si potrebbe connettere il sito con un collegamento punto-punto, permettendo la raccolta dati ed il monitoraggio in tempo reale, senza la necessità di portarsi fisicamente sul posto. Le reti wireless assicurano sufficiente banda per portare grandi quantità di dati (compresi audio e video) tra due punti che siano tra loro connessi, anche se mancano di allacciamento diretto ad Internet.
Punto-multipunto
La seconda disposizione di rete maggiormente diffusa è la punto-multipunto (point-to-multipoint). Ove diversi nodi sono in connessione con un punto centrale di accesso, questa è un'applicazione del punto-multipunto. Il classico esempio di una configurazione punto-multipunto è l'impiego di un punto di accesso wireless che garantisce la connessione a diversi laptop. I laptop non comunicano direttamente tra di loro, ma devono rimanere nel raggio di azione dell'access point per poter usare la rete.
attachment:figure-3.2-ita.png |
Figura 3.2: Il VSAT centrale è ora condiviso tra diversi siti remoti. I tre siti possono tra loro comunicare anche direttamente, a velocità decisamente superiori a quelle del VSAT. |
Il networking punto-multipunto può anche applicarsi al precedente esempio dell'università. Si supponga che l'edificio distaccato sulla cima della collina sia connesso al campus centrale con un collegamento punto-punto. Piuttosto che tirare su diversi collegamenti punto-punto per distribuire l'accesso ad Internet, può venir impiegata un'unica antenna che sia visibile dai diversi edifici lontani. Questo è un classico esempio di una connessione punto (sito distaccato sulla collina) -multipunto (molti edifici nella valle sottostante) su area estesa.
Si osservi come sussistano limiti nelle prestazioni di collegamenti punto-multipunto su distanze molto estese, limiti che verranno discussi più avanti nel capitolo. Questi collegamenti sono possibili ed utili in diverse situazioni, ma si eviti di ricadere nel classico errore di installare un singolo traliccio radio ad alta potenza nel bel mezzo della città, con la pretesa di portare il servizio a migliaia di utenti, così come si potrebbe invece fare per una stazione radio FM. Come si vedà più avanti, le reti di dati si comportano in modo decisamente differente dalle trasmissioni della radio.
Multipunto-multipunto
Il terzo tipo di configurazione di rete è quello multipunto-multipunto, definito anche rete ad-hoc o mesh. In una rete multipunto-multipunto, non c'è un'autorità centrale. Ogni nodo sulla rete si prende carico del traffico di ogni altro nodo, secondo necessità, ed ogni nodo comunica direttamente con ogni altro.
attachment:figure-3.3.png |
Figura 3.3: una maglia (mesh) multipunto-multipunto. Ogni punto riesce a raggiungere ogni altro a velocità molto alta, così come può raggiungere Internet tramite il VSAT centrale. |
I vantaggi di tale configurazione di rete risiedono nel fatto che, anche se nessuno dei nodi fosse in contatto con l'access point centrale, questi potrebbero comunque comunicare tra loro. Le realizzazioni a regola d'arte di reti mesh sono auto-riconfiguranti, nel senso che riescono a riconoscere automaticamente i problemi di routing e riescono a risolverli nel modo opportuno. Estendere una rete mesh è semplice come aggiungere nuovi nodi. Se uno dei nodi nella "nuvola" si trova ad essere un gateway (varco) verso Internet, allora l'accesso può essere condiviso tra tutti i client presenti.
Due gravi svantaggi di tale tipologia sono la complessità crescente e la bassa prestazione. Anche la sicurezza, in una rete simile, rappresenta un serio problema, poichè ogni singolo partecipante può, potenzialmente, prendersi carico del traffico di ogni altro. Reti multipunto-multipunto tendono ad essere complicate nella diagnostica dei problemi, a causa del grande numero di variabili che insorgono quando i nodi cambiano di posizione. Le reti multipunto-multipunto, tipicamente, non dispongono della stessa capacità di reti punto-punto o punto-multipunto, a causa dell'overhead supplementare necessario per il routing della rete e della più serrata competizione per l'impiego dello spettro elettromagnetico.
Tuttavia, le reti a maglia (mesh networks) sono utili in diverse situazioni. Alla fine di questo capitolo, vedremo un esempio di come rendere attiva una rete a maglia multipunto-multipunto impiegando un protocollo di routing chiamato OLSR.
Impiega la tecnologia che risolve il problema
Tutti questi progetti di rete possono essere usati per complementarsi a vicenda in una rete più grande, e possono ovviamente far uso delle tradizionali tecniche di una rete su cavo, ove possibile. Si fa infatti comunemente ricorso ad un collegamento wireless a lunga distanza per assicurare l'accesso Internet ad una postazione remota, impiegando poi un access pont su tale postazione per garantire l'accesso a livello locale. Uno dei client di questo access point può poi, a sua volta, comportarsi come nodo di maglia, permettendo alla rete di espandersi tra gli utenti dei laptop che, alla fine, usano tutti il collegamento punto-punto originale per aver accesso ad Internet.
Ora che è stata fornita una chiara idea sul modo con cui vengono tipicamente impostate le reti wireless, si può iniziare a comprendere come sia possibile la comunicazione attraverso tali reti.
La rete logica
La comunicazione diventa realizzabile solo quando i partecipanti impiegano un linguaggio comune. Quando però la comunicazione diventa più complessa che una semplice radio-diffusione, il protocollo acquista un'importanza pari a quella del linguaggio. Tutte le persone in un auditorium possono parlare lo stesso Inglese, ma in assenza di regole per stabilire chi abbia diritto di prendere il microfono, la comunicazione delle idee di un singolo individuo all'intera platea diventa praticamente impossibile. Si immagini ora un auditorium che si estenda al mondo intero, ove siano compresi tutti i computer esistenti. Senza un insieme di protocolli di comunicazione comuni per regolare quando e come un computer possa prendere la parola, Internet sarebbe solo una disordinata confusione, dove tutte le macchina provano a parlare nello stesso momento.
TCP/IP si riferisce alla suite di protocolli che permettono la realizzazione delle conversazioni sull'Internet globale. Se si comprende TCP/IP, si possono costruire reti in grado di crescere praticamente a qualsiasi dimensione, per arrivare a diventare parte, alla fine, dell'Internet globale.
Il modello TCP/IP
Le reti di dati sono spesso descritte come costituite su strati diversi. Ogni strato dipende dalle operazioni condotte da tutti gli strati sottostanti, prima che la comunicazione possa aver luogo, ma ogni strato scambia i dati solo con lo strato superiore o con quello inferiore ad esso. Il modello TCP/IP delle reti descrive cinque strati, come evidenziato dal diagramma sotto riportato:
attachment:figure-3.4-ita.png |
Figura 3.4: Il modello di rete TCP/IP. |
La precedente sezione sulla configurazione della rete descriveva il primo strato: lo strato fisico. Si tratta del mezzo fisico sul quale la comunicazione ha luogo. Può essere un cavo di rame di tipo CAT5, un fascio di fibre ottiche, onde radio, od anche un altro mezzo.
Lo strato soprastante è chiamato strato data link. Quando due o più nodi condividono lo stesso mezzo fisico (per esempio, diversi computer attestati ad un hub, od una sala piena di laptop che usano tutti lo stesso canale radio), essi usano lo strato data link per determinare a chi spetti trasmettere sul mezzo. Esempi comuni di protocolli di data link sono Ethernet, il Token Ring, l'ATM, ed i protocolli di rete wireless (802.11a/b/g). Le comunicazioni su questo strato sono definite link locali, poichè tutti i nodi connessi su questo strato possono comunicare direttamente l'uno con l'altro. Sulle reti che assumono Ethernet come modello di riferimento, i nodi vengono distinti sulla base del proprio indirizzo MAC, che è un numero univoco di 48 bit assegnato ad ogni periferica di rete dal suo costruttore.
Appena sopra dallo strato data link c'è lo strato Internet. Per il TCP/IP, questo è detto Internet Protocol (IP). Sullo strato Internet, i pacchetti possono lasciare la rete del collegamento locale per essere ritrasmessi su altre reti. I router prendono in carico questa funzione su una rete, disponendo di almento due interfacce di rete, una per ogni rete che devono interconnettere. I nodi su Internet sono raggiungibili grazie al loro IP address, che è globalmente unico.
Diventato possibile il routing su Internet, si rende ora necessario raggiungere un particolare servizio disponibile presso un indirizzo IP dato. La funzione è soddisfatta dallo strato successivo, lo strato di trasporto. TCP ed UDP sono classici esempi di strati di trasporto. Alcuni protocolli dello strato di trasporto (come TCP) assicurano che tutti i dati arrivino a destinazione, siano riassemblati e quindi consegnati allo strato superiore, nell'ordine previsto.
Alla fine, sulla cima della pila si trova lo strato applicativo. E' lo strato che si interfaccia con la maggior parte degli utenti della rete, ed è a livello di questo strato che avviene la comunicazione per le persone. HTTP, FTP e SMTP sono tutti protocolli dello strato applicativo. La persona si pone al di sopra di tutti questi strati, e non deve conoscere praticamente nulla di tutti gli strati sottostanti, per impiegare in modo efficace la rete.
Un modo per riconoscere il modello TCP/IP può essere quello che prevede una persona che intenda consegnare una lettera ad un ufficio in un palazzo del centro. Occorre prima interagire con la stessa strada (lo strato fisico), prestare attenzione al traffico che altri conducono sulla strada (lo strato data-link), giungere al posto giusto per immettersi su altre strade ed arrivare all'indirizzo giusto (lo strato Internet), portarsi al piano giusto ed al corretto numero di stanza (lo strato di trasporto), e finalmente trovare il destinatario o un commesso che possa prendere in carico la lettera (lo strato applicativo). I cinque strati possono facilmente essere ricordati usando il trucco mnemonico "Forse Domani Incontrerò Tue Amiche", che naturalmente ricorda: " Fisico / Data-link / Internet / Trasporto / Applicativo."
reti wireless 802.11
Prima che i pacchetti possano essere inoltrati ed instradati su Internet, il primo strato (quello fisico) ed il secondo (quello data link) devono essere connessi. Senza connessione sul collegamento locale, i nodi della rete non possono comunicare tra di loro, nè possono instradare pacchetti.
Per garantire connessione fisica, le periferiche wireless devono operare nella stessa finestra dello spettro radio. Come si è visto nel capitolo 2, ciò significa che le radio 802.11a potranno comunicare con altre radio 802.11a sulla banda dei 5GHz, mentre le radio 802.11b/g comunicheranno con altre radio 802.11b/g sulla banda dei 2.4 GHz. Ma una periferica 802.11a non potrà colloquiare con una periferica 802.11b/g, poichè usano segmenti completamente diversi dello spettro elettromagnetico.
In modo più specifico, le schede wireless devono accordarsi su un canale comune. Se una scheda radio 802.11b è impostata sul canale 2 mentre un'altra è impostata sul canale 11, le due radio non comunicheranno tra di loro.
Quando due schede wireless sono configurate per impiegare lo stesso protocollo sullo stesso canale radio, sono allora pronte per negoziare la connettività sullo strato data link. Ogni periferica 802.11a/b/g può lavorare in uno dei quattro possibili modi:
Master mode (altrimenti chiamato AP or modo infrastruttura) è usato per rendere disponibile un servizio simile ad un access point tradizionale. La scheda wireless crea una rete con un nominativo specifico (chiamato SSID) ed un proprio canale, ed offre servizi di rete su questo. Posta in modo master, la carta wireless governa tutte le comunicazioni relative alla rete (autenticando i client wireless, gestendo le contese sul canale, ripetendo i pacchetti, etc.). Le schede wireless poste in modo master possono comunicare solo con altre schede che le siano associate in modalità managed (gestita).
Managed mode viene talvolta chiamato client mode. Le schede wireless poste in managed mode si aggregheranno a reti create da un master, e provvederanno automaticamente a reimpostare il proprio canale di lavoro per adeguarsi al canale del master. Provvederanno quindi a presentare ogni credenziale necessaria al master, e se queste credenziali saranno accettate, queste schede verranno definite associate (associated) al master. Le schede in Managed mode non comunicano direttamente tra di loro, ma comunicano solo con il master loro associato.
Ad-hoc mode crea reti multipunto-multipunto dove non è presente un signolo nodo master, od Access Point. Nel modo ad-hoc, ogni scheda wireless comunica direttamente con i propri vicini. I nodi devono essere nel raggio d'azione di ogni altro nodo corrispondente per comunicare, e devono accordarsi sul nome della rete e sul canale da impiegare.
Monitor mode è impiegato da alcuni strumenti (come Kismet, vedasi al capitolo sei) che ascoltano passivamente il traffico presente su un dato canale. Quando sono in Monitor Mode, le schede wireless non trasmettono dati. Tale caratteristica è importante per analizzare problemi su un collegamento wireless o per osservare l'impiego dello spettro elettromagnetico in una zona locale. Il Monitor Mode non è usate per le normali comunicazioni.
Nella realizzazione di un collegamento punto-punto o punto-multipunto, una radio dovrà tipicamente operare in Master Mode, mentre le altre verranno poste in Managed Mode. In una rete multipunto-multipunto, le radio opereranno tutte in modalità ad-hoc, sì che possano comunicare direttamente una con le altre.
attachment:figure-3.5-ita.png |
Figura 3.5: Access Point, Client, e nodi Ad-Hoc. |
E' importante mantenere queste modalità in mente quando si progettano le configurazioni di rete. Si ricordi come i client in Managed Mode non possano comunicare direttamente gli uni con gli altri, sì da rendere probabile l'impiego in un sito ripetitore a maggiore altezza che sia in Master Mode o Ad-Hoc Mode. Come si vedrà più avanti nel capitolo, il modo Ad-Hoc è più flessibile ma presenta maggiori problemi di prestazioni, rispetto al Master Mode ed al Managed Mode.
Ora che le schede wireless garantiscono connettività sia nello strato fisico che in quello data-link, sono in grado di cominciare a trasferire i pacchetti sul terzo strato, lo strato internetworking.
reti Internet
Indirizzi IP, indirizzamento di rete, routing e forwarding sono tutti concetti importanti e correlati nell'ambito delle reti Internet. Un indirizzo IP è un identificatore per un nodo di rete quale un PC, un server, un router od un bridge. Indirizzamento di Rete è il sistema impiegato per assegnare tali identificatori raggruppandoli in gruppi significativi. Il Routing tiene traccia di dove questi gruppi possano essere trovati nella rete. Il risultato del processo di routing è mantenuto in una lista chiamata tabella di routing. Il Forwarding è l'azione di impiegare la tabella di routing per spedire un pacchetto dati o verso la sua destinazione finale, o verso "il prossimo salto" che lo avvicina alla destinazione.
Indirizzi IP
In una rete IP, l'indirizzo è un numero di 32 bit, normalmente scritto sotto forma di quattro numeri ad otto bit, separati da punti. Esempi di indirizzi IP sono 10.0.17.1, 192.168.1.1, o 172.16.5.23.
indirizzamento di rete
Reti interconnesse devono concordare un piano di indirizzamento IP. Nella Internet globale, commissioni di persone distribuiscono gruppi di indirizzi IP in modo coerente per assicurare che indirizzi duplicati non vengano usati da reti differenti, provvedendo altresì che ci si possa riferire in modo rapido a gruppi di indirizzi. Questi gruppi di indirizzi sono chiamati sotto-reti o subnets come abbreviazione. Sottoreti più ampie possono essere ulteriormente suddivise in sottoreti minori. Talvolta, un gruppo di indirizzi collegati è chiamato Spazio di Indirizzi o address space.
Su Internet, nessuna persona e nessuna organizzazione possiede effettivamente questi gruppi di indirizzi perchè gli indirizzi hanno significato solo se il resto della comunità di Internet concorda nel loro utilizzo. Per accordo, gli indirizzi sonon distribuiti alle organizzazioni sulla base dei loro bisogni e della loro dimensione. Un'organizzazione che abbia ricevuto un segmento di indirizzi potrebbe quindi assegnarne una porzione ad un'altra organizzazione, sulla base di un accordo di servizio. Indirizzi che vengono assegnati in questa maniera, partendo dalle commissioni internazionalmente riconosciute per poi essere via via spezzati gerarchicamente da comitati nazionali o regionali, sono detti indirizzi IP globalmente instradati (lobally routed IP addresses).
A volte non è conveniente, se non impossibile, ottenere per un individuo od un'organizzazione più di un indirizzo IP globalmente instradato. In questo caso può essere impiegata una tecnica conosciuta come Network Address Translation (traduzione dell'indirizzo di rete), o NAT. Un dispositivo NAT è un router con due porte di rete. La porta esterna impiega un indirizzo IP globalmente instradato, mentre la porta interna usa un indirizzo IP appartenente ad un segmento particolare, chiamato indirizzi privati. Il router NAT permette al singolo indirizzo globale di essere condiviso da parte di tutti gli utenti interni, che impiegano indirizzi privati. Il router NAT converte i pacchetti da una forma di indirizzamento all'altra, quando i pacchetti lo attraversano. Gli utenti interni credono di essere direttamente connessi ad Internet e non richiedono nèoftware particolare, nè driver, per condividere il singolo indirizzo IP globale.
Routing
Internet cresce e cambia costantemente. Nuove reti sono aggiunte in continuazione, mentre i collegamenti tra le reti sono aggiunti, sono rimossi, cadono e vengono ripristinati. E' compito del routing determinare il percorso migliore verso la destinazione, e creare tabelle di routing che elenchino il percorso migliore per ogni possibile destinazione.
Routing Statico è il termine usato per le tabelle di routing compilate a mano. E' talvolta conveniente per piccole reti, ma può facilmente diventare impraticabile e soggetto ad errori per reti di maggiore dimensione. Ancora peggio, se il percorso migliore verso una rete diventa inimpiegabile, per un'avaria hardware o per altre ragioni, il routing statico non farà uso del miglior percorso secondario.
Routing Dinamico è una soluzione dove gli elementi di rete, in particolare i router, si scambiano reciprocamente informazioni sul loro stato e sullo stato dei propri vicini nella rete, e quindi usano queste informazioni per rilevare automaticamente il percorso migliore e per compilare la tabella di routing. Se ci sono cambiamenti, come un router che si blocca od un nuovo router che entra in azione, allora i protocolli di routing dinamico apportano aggiustamenti alle tabelle di routing. Il sistema di scambio dei pacchetti e la definizione delle decisioni è denominato protocollo di routing. Ci sono diversi protocolli di routing che sono usati oggi su Internet, tra cui OSPF, BGP, RIP, and EIGRP.
Le reti wireless sono come le reti su cavo, per quanto riguarda la loro necessità di protocolli di routing, ma sono anche tanto differenti, da richiedere protocolli di routing diversi. In particolare, le connessioni su reti su cavo tipicamente o funzionano bene, o non funzionano affatto (in altre parole, un cavo Ethernet o è allacciato, o non lo è). La situazione non è così chiara quando si tratta di reti wireless. Le comunicazioni radio possono essere affette da oggetti che si muovono sul percorso del segnale, o da disturbi che interferiscono. Conseguentemente, i collegamenti possono funzionare bene, o male, o in modo sfumato tra i due estremi. Poichè i protocolli attuali non tengono in conto la qualità del collegamento nel definire le decisioni, i comitati IEEE 802.11 e l'IETF stanno lavorando sulla standardizzazione dei protocolli per le reti wireless. Al momento, non è ancora chiaro se si imporrà un singolo standard per affrontare la qualità variabile di un collegamento.
Nel frattempo, sono in corso diversi tentativi di affrontare il problema. Alcuni esempi sono Hazy Sighted Link State (HSLS), Ad-hoc On-demand Distance Vector (AODV), e Optimized Link State Routing (OLSR). Un altro è SrcRR, una combinazione del DSR e dell'ETX, realizzato dal progetto Roofnet del M.I.T. Più avanti, in questo capitolo, vedremo un esempio di come realizzare una rete usando OLSR per le decisioni di routing.
Forwarding
Il Forwarding è diretto, in confronto con l'indirizzamento ed il routing. Ogni volta che riceve un pacchetto di dati, il router consulta la tabella di routing che possiede internamente. Partendo dal bit più significativo (o di maggior ordine), la tabella di routing viene scandita per ricercare il valore che corrisponda per il maggior numero di bit all'indirizzo di destinazione. Tale valore (il primo campo di ogni riga) è denominato il prefisso dell'indirizzo. Se viene trovato nella tabella di routing un prefisso che corrisponda, allora il contatore dei salti (hop counter) od il campo time to live (TTL) è decrementato. Se il risultato è zero, allora il pacchetto viene lasciato cadere ed un pacchetto di segnalazione di errore viene rinviata al mittente. Altrimenti, il pacchetto viene inviato al nodo od alla interfaccia specificata nella tabella di routing. Come esempio, se la tabella di routing contiene questi valori...
Destination Gateway Genmask Flags Metric Iface 10.15.6.0 0.0.0.0 255.255.255.0 U 0 eth1 10.15.6.108 10.15.6.7 255.255.255.255 UG 1 eth1 216.231.38.0 0.0.0.0 255.255.255.0 U 0 eth0 0.0.0.0 216.231.38.1 0.0.0.0 UG 0 eth0
...ed un pacchetto arriva con indirizzo di destinazione 10.15.6.23, questi verrà allora spedito al gateway 10.15.6.7 (poichè il primo campo, di ingresso, trova sulla linea di tale gateway una corrispondenza più completa rispetto dalla rotta della rete 10.15.6.0)
Una destinazione 0.0.0.0 è convenzionalmente considerata il default gateway. Se nessun altro prefisso trova corrispondenza con l'indirizzo di destinazione, allora il pacchetto viene spedito al default gateway. Per esempio, se l'indirizzo di destinazione fosse 72.1.140.203, allora il router indirizzerebbe il pacchetto al gateway 216.231.38.1 (che sarà, verosimilmente, più prossimo alla destinazione finale, e così via).
Se per il pacchetto in ingresso non è trovata nessuna corrispondenza valida (cioè, se non esiste un default gateway e non c'è corrispondenza con il prefisso di una rotta stabilita), allora il pacchetto viene lasciato cadere ed un pacchetto di errore viene restituito al mittente.
Il campo TTL è impiegato per riconoscere i giri a vuoto dei pacchetti (routing loops). Senza tale campo, un pacchetto potrebbe essere continuamente rimbalzato tra un router ed un altro, qualora questi si indicassero a vicenda come prossimo passo verso la destinazione finale. Questo tipo di giro a vuoto può dare origine ad un forte traffico non necessario sulla rete, tale da minacciarne la stabilità. L'impiego del TTL non scongiura i giri a vuoto, ma contribuisce ad evitare che questi distruggano la rete a causa di un semplice errore di configurazione.
Comporre il tutto in una visione unica
Ciascun nodo della rete può inviare pacchetti di dati all'indirizzo IP di un altro nodo, una volta che tutti abbiano ricevuto il proprio indirizzo IP. Attraverso l'uso del routing e del forwarding, questi pacchetti possono raggiungere i nodi sulla rete che non sono fisicamente connessi al nodo di origine. Questo processo sintetizza la gran parte di ciò che avviene su Internet. Tutto ciò è illustrato nelle figure seguenti:
attachment:figure-3.6-ita.png |
Figura 3.6: Reti su Internet. Ogni segmento di rete dispone di un router con due indirizzi IP, ponendolo in un "collegamento locale" (link local) su due reti differenti. I pacchetti sono passati tra router fintantochè non raggiungano la loro destinazione finale |
In questo esempio, potete vedere il percorso che completano i pacchetti quando Alice scambia messaggi con Bob impiegando un servizio di istant messaging. Ogni linea punteggiata rappresenta un cavo Ethernet, un collegamento wireless, od ogni altra possibile rete fisica. Il simbolo a nuvola viene comunemente usato per rappresentare "Internet", e corrisponde ad un numero di reti IP che vi partecipano. Nè Alice, nè Bob devono preoccuparsi di come le proprie reti cooperino tra loro, fintantochè i router inviino il traffico IP fino alla destinazione finale. Se non fosse per i protocolli di Internet e la collaborazione di ciascuno sulla rete, questo tipo di comunicazione non sarebbe possibile.
Ora che abbiamo visto come i pacchetti fluiscano sulle reti IP, vediamo un tipo particolare di rete IP: una maglia OLSR.
Reti a Maglia con OLSR
Gran parte delle reti wireless lavorano in Infrastructure Mode; sono costituite di un access point posto da qualche parte, con una scheda radio che lavora in Master Mode, ed un collegamento ad una linea DSL od ad un'altra rete di grande dimensione, di tipo su cavo. In questo hotspot, l'access point lavora tipicamente da Master Station che distribuisce l'accesso ad Internet ai propri client, che funzionano invece in Managed Mode. Questa topologia è simile al servizio mobile telefonico GSM. I telefonini si connettono ad una stazione base; senza la presenza di tale stazione base, i telefonini non sarebbero in grado di comunicare tra loro. Se desiderate giocare uno scherzo, chiamate l'amico che siede dall'altro lato del tavolo; il vostro telefono spedice alla stazione base del vostro provider telefonico che può essere lontana un paio di chilometri, ed è la stazione base che reinvia poi il segnale al telefono del vostro amico.
Anche le schede WiFi in Managed Mode non possono comunicare direttamente. I client - ad esempio, due portatili sullo stesso tavolo - devono impiegare un access point come relay. Tutto il traffico tra i client aggregati ad un access point deve quindi essere spedito due volte. Se i client A e C comunicano, il cliente A spedisce i propri dati all'access point B, quindi l'access point ritrasmette i dati al cliente C. La singola trasmissione può raggiungere, nel nostro esempio, i 600 kByte/sec (all'incirca, la velocità massima raggiungibile con il protocollo 802.11b). Così, poichè i dati devono essere ripetuti dall'access point prima che raggiungano il proprio destinatario, la velocità effettiva tra due client sarà solo di 300 kByte/sec.
Nel modo ad-hoc non c'è un rapporto gerarchico master-client. I nodi possono comunicare direttamente, fintantochè siano nel raggio d'azione delle proprie interfacce wireless. Così, nel nostro esempio entrambi i computer potrebbero raggiungere la massima velocità se lavorassero in modalità ad-hoc, in condizioni ideali.
Lo svantaggio della modalità ad-hoc è che i client non ritrasmettono il traffico destinato ad altri client. Nel caso dell'access point (modalità infrastructure), invece, se due client A e C non possono vedersi direttamente con le loro interfacce wireless, sono comunque in grado di comunicare, fintantochè l'Access Point sia nel raggio wireless di entrambi i client.
attachment:figure-3.7-ita.png |
Figura 3.7: L'Access Point B ritrasmetterà il traffico tra i client A and C. Nella modalità Ad-Hoc, il nodo B non ripeterà il traffico tra A e C per default. |
I nodi Ad-hoc non ritrasmettono il traffico per default, ma possono comportarsi in modo simile se viene applicato un opportuno routing. Le reti a maglia (Mesh networks) sono basate sulla strategia che rende ogni nodo - capace di costituire maglie - relay per estendere la copertura della rete wireless. Maggiore il numero dei nodi, migliore diventa la copertura radio e la portata della nuvola di maglie.
Un importante costo dev'essere menzionato a questo proposito. Se il dispositivo usa solo un'interfaccia radio, la banda disponibile è ridotta in modo significativo ogni volta che il traffico viene ripetuto da nodi intermedi posti sul percorso da A a B. Inoltre, ci sarà interferenza nella trasmissione a causa della condivisione dello stesso canale da parte dei nodi. Cosi, economiche reti a maglia su modalità ad-hoc possono garantire una buona copertura radio sull'ultimo miglio di una rete di una comunità wireless al costo della velocità, specialmente se la densità dei nodi e la potenza di trasmissione sono alte.
Se una rete ad-hoc è costituita solamente di pochi nodi che sono accesi ed attivi in modo continuo, che non si muovono e che dispongono sempre di collegamenti radio stabili - una lunga lista di condizioni - diventa possibile compilare a mano le tabelle di routing per tutti i nodi.
Sfortunatamente, le condizioni citate si incontrano difficilmente nel mondo reale. I nodi possono cadere, dispositivi WiFi sono presenti nelle vicinanze, e le interferenze possono rendere inimpiegabili i collegamenti radio in qualsiasi momento. Nessuno ha l'intenzione di aggiornare a mano diverse tabelle di routing ogni volta che un nuovo nodo è aggiunto alla rete. Impiegando invece protocolli di routing che mantengono in modo automatico le specifiche tabelle di routing su tutti i nodi coinvolti, diventa possibile evitare questo problema. I protocolli di routing di maggiore impiego nel mondo cablato (protocolli come OSPF) non funzionano al meglio in un ambiente wireless perchè non sono progettati per contrastare i collegamenti con attenuazioni o le topologie che cambiano con rapidità.
Mesh Routing con olsrd
Il demone Optimized Link State Routing - olsrd - fornito da olsr.org è un'applicazione di routing sviluppata per il routing nelle reti wireless. Ci si concentrerà su questo software di routing per diverse ragioni. E' un progetto open-source che supporta Mac OS X, Windows 98, 2000, XP, Linux, FreeBSD, OpenBSD e NetBSD. Olsrd è disponibile per access point che funzionano sotto Linux, come il Linksys WRT54GL, l'Asus WL-500G, l'AccessCube od i PocketPC che funzionano su Familiar Linux, e viene fornito come standard sui kit Metrix che funzionano su Metrix Pebble. Olsrd può gestire interfacce multiple ed è estensibile con appositi moduli aggiuntivi (plug-in). Supporta IPv6 ed è attivamente sviluppato ed impiegato da reti di comunità in tutto il mondo.
Si noti come esistano diverse versioni dell'Optimized Link State Routing, che è nato come un draft IETF scritto dall'istituto francese INRIA. La realizzazione distribuita da olsr.org ha visto la luce come tesi di master di Andrea Toennesen all'università di Unik. Basato sull'esperienza pratica della comunità delle reti libere, il demone di routing venne modificato. Olsrd attualmente si differenzia significativamente dalla proposta originale, perchè include un dispositivo chiamato Link Quality Extension che rileva il tasso di pacchetti perduti tra i nodi e ricalcola le rotte sulla base di queste informazioni. Questa estensione rompe la compatibilità con i demoni di routing che seguono la proposta INRIA. Il demone olsrd disponibile da olsr.org può essere configurato per comportarsi in ossequio alla proposta IETF che manca di questa caratteristica, ma non v'è ragione per disabilitare la Link Quality Extension, a meno che non sia espressamente richiesta la piena aderenza con le altre realizzazioni.
La Teoria
Dopo che il demone olsrd è stato attivato per un tempo adeguato, un nodo apprende dell'esistenza di ogni altro nodo nella nuvola di maglie, e riconosce anche quale nodo possa essere impiegato per indirizzargli il traffico. Ogni nodo mantiene aggiornata una tabella di routing che descrive l'intera nuvola di maglie. Questo approccio al mesh routing viene chiamato routing proattivo. Al contrario, gli algoritmi di routing reattivo ricercano le rotte solo quando è necessario spedire dei dati verso un nodo specifico.
Ci sono vantaggi e svantaggi nel routing proattivo, e per realizzare il mesh routing ci sono molte altre impostazioni differenti, meritevoli di citazione. Il maggior vantaggio del routing proattivo risiede nel fatto che viene reso noto chi sia presente all'esterno e non si deve quindi aspettare che la rotta venga trovata. Tra gli svantaggi, ci sono il maggior sovraccarico di traffico ed il maggior carico sulla CPU. A Berlino, la comunità Freifunk impiega una nuvola di maglie dove olsrd deve gestire più di 100 interfacce. Il carico medio sulla CPU di un Linksys WRT54G a 200 MHz, causato da olsrd, è circa del 30%, nella rete di Berlino. C'è chiaramente un limite alla scalabilità di un protocollo proattivo, limite che dipende da quante interfacce siano coinvolte e da quanto frequentemente le tabelle di routing vengano aggiornate. Mantenere le rotte in una nuvola di maglie coon nodi statici richiede meno sforzo di quanto sia invece necessario in una maglia dove i nodi siano in costante movimento, poichè le tabelle di routing devono essere aggiornate con frequenza minore.
Il Meccanismo
Un nodo, su cui gira olsrd, diffonde periodicamente messaggi di 'hello' in modo che i propri vicini possano riconoscerne la presenza. Ogni nodo mantiene una statistica di quanti messaggi di 'hello' siano stati ricevuti o persi da parte di ognuno dei suoi vicini, riuscendo così a ricevare informazioni sulla topologia dei nodi vicini e sulla qualità dei collegamenti. Le informazioni ricavate sulla tipologia sono poi diffuse via radio come messaggi di controllo della topologia (messaggi TC) ed inoltrati dai vicini che olsrd ha preventivamente eletto come relay multipunto.
Nel routing proattivo Il concetto di relay multipunto è un'idea nuova che è sorta con la bozza di OLSR. Se ogni nodo ridiffondesse via radio le informazioni di topologia che ha ricevuto, potrebbe generarsi un sovraccarico eccessivo nella rete. Queste trasmissioni sono ridondanti, se un nodo ha diversi vicini. Un nodo olsrd, allora, decide quali vicini siano relay multipunto favorevoli per inoltrare i propri messaggi di controllo della tipologia. Si noti che i relay multipunto sono scelti con l'unico scopo di inoltrare i messaggi TC. Il contenuto utile (payload) viene soggetto a routing che può coinvolgere ogni nodo disponibile.
Altri due tipi di messaggio sono presenti in OLSR per passare informazioni: se un nodo presenta un gateway ad altre reti (messaggi HNA) o se ha più interfacce (messaggi MID). Non c'è molto da dire su quale compito svolgano questi messaggi, a parte il fatto che esistono. I messaggi HNA rendono olsrd molto utile quanto si tratti di connettere Internet con un dispositivo mobile. Quando un nodo di maglia si sposta intorno, potrà riconoscere dei gateway nelle altre reti, e sceglierà sempre il gateway che presenta la rotta migliore. Comunque, olsrd non è assolutamente a prova di errore. Se un nodo dichiara di essere un gateway verso Internet - funzione che non ricopre. in realtà, perchè non lo è mai stato o perchè si trova disconnesso al momento - gli altri nodi presteranno fede all'affermazione. Il finto-gateway diventa un buco nero. Per superare questo problema, è stato scritto un plugin (modulo aggiuntivo) per il gateway dinamico. Il plugin nel gateway verificherà automaticamente se questi sia connesso e se il collegamento stia ancora in piedi. In caso negativo, l'olsrd terminerà di inviare falsi messaggi HNA. E' fortemente raccomandato di inserire ed impiegare questo plugin, piuttosto che dare manualmente l'abilitazione all'invio di messaggi HNA.
In Pratica
Olsrd realizza il routing basato su IP con un'applicazione nello spazio-utente; l'installazione è quindi piuttosto semplice. I pacchetti per l'installazione sono disponibili per OpenWRT, Accesscube, Mac OS X, Debian GNU/Linux e Windows. OLSR è un componente standard di Metrix Pebble. Se si deve compilarlo dai sorgenti, occorre leggere la documentazione che è diffusa all'interno del pacchetto del sorgente. Se ogni cosa è configurata ammodo, tutto ciò che rimane da fare è l'avvio del programma olsr.
Prima di tutto, occorre assicurarsi che ogni nodo abbia un indirizzo IP, assegnato staticamente ed unico, per ogni interfaccia usata per la maglia. Non è raccomandato (nè è praticabile) impiegare DHCP in una rete a maglia basata su IP. Una richiesta DHCP non verrà soddisfatta da un server DHCP se il nodo che la inoltra richiede più di un salto per essere raggiunto, ed inserire dei relay DHCP su una maglia è pressochè impraticabile. Questo problema potrebbe essere risolto usando IPv6, poichè in tal modo sarebbe disponibile uno spazio-indirizzi enorme per generare un indirizzo IP a partire dall'indirizzo MAC di ogni scheda coinvolta (come suggerisce in "IPv6 Stateless Address Autoconfiguration in large mobile ad hoc networks" di K. Weniger e M. Zitterbart, 2002).
Potrebbe servire allo scopo anche una pagina wiki, dove ogni persona interessata potrebbe scegliere un indirizzo IPv4 unico per ognuna delle interfacce sulle quali il demone olsr verrebbe fatto girare. In sintesi, non c'è una soluzione facile per rendere automatico tale processo, se si ricorre ad IPv4.
L'indirizzo di broadcast, per convenzione generale, dovrebbe essere 255.255.255.255 su interfacce che si affacciano sulla rete a maglia. Non c'è nessun motivo, per inserire esplicitamente l'indirizzo di broadcast, poichè olsrd può essere configurato per sostituire gli indirizzi di broadcast con tale valore predefinito. Occorre solo essere sicuri che tali impostazioni siano uniformi in ogni parte. Olsrd può raggiungere tale scopo da solo. Quando un file predefinito di configurazione di olsrd è distribuito, questa caratteristica dovrebbe essere abilitata per evitare confusione del tipo "perchè gli altri nodi non riescono a vedere la mia macchina?!?"
Ora configuriamo l'interfaccia wireless. Di seguito un comando, come esempio di come configurare una scheda wifi, con il nome wlan0, usando Linux:
iwconfig wlan0 essid olsr.org mode ad-hoc channel 10 rts 250 frag 256
Occorre verificare che la parte wireless della scheda wifi sia stata configurata in modo che abbia una connessione ad-hoc verso gli altri nodi della maglia direttamente raggiungibili (nodi entro il singolo salto). Occorre anche assicurarsi che l'interfaccia si aggreghi allo stesso canale wireless, che usi lo stesso nome di rete wireless ESSID (Extended Service Set IDentifier) e che sia caratterizzato dallo stesso Cell-ID come tutte le altre schede wifi che compongono la maglia. Molte schede wifi, od i loro rispettivi driver, non si comportano in maniera conforme a quanto previsto dagli standard 802.11 per il networking ad-ho, e così può fallire miseramente il tentativo di connettersi ad una cella. Le stesse schede possono non essere in grado di connettersi ad altri dispositivi sullo stesso tavolo, anche se questi sono impostati con il corretto canale e nome di rete wireless.Queste schede possono, piuttosto, confondere altre schede che si comportano invece conformemente allo standard, creando il proprio indicativo di cella (Cell-ID) sullo stesso canale con lo stesso nome di rete wireless. Le schede wifi costruite dall'Intel e che sono distribuite con i notebook Centrino sono famose per comportarsi in tale maniera.
E' possibile verificare tutto con il comando iwconfig, quando si usa Linux. Di seguito, l'output che si ottiene sulla mia macchina.
wlan0 IEEE 802.11b ESSID:"olsr.org"
Mode:Ad-Hoc Frequency:2.457 GHz Cell: 02:00:81:1E:48:10
Bit Rate:2 Mb/s Sensitivity=1/3
Retry min limit:8 RTS thr=250 B Fragment thr=256 B
Encryption key:off
Power Management:off
Link Quality=1/70 Signal level=-92 dBm Noise level=-100 dBm
Rx invalid nwid:0 Rx invalid crypt:28 Rx invalid frag:0
Tx excessive retries:98024 Invalid misc:117503 Missed beacon:0 E' importante impostare la soglia del 'Request To Send' (RTS) per una maglia. Ci saranno delle collisioni sul canale radio tra le trasmissioni dei nodi dello stesso canale radio, e l'RTS mitigherà tali effetti. RTS/CTS introduce un handshake prima di ogni pacchetto di trasmissione per sincerarsi che il canale sia chiaro. Si introduce del sovraccarico, ma si incrementano le prestazioni in caso di nodi nascosti - ed i nodi nascosti sono presenti per default sulla maglia! Questo parametro imposta la dimensione in Byte del più piccolo pacchetto per il quale il nodo spedisce l'RTS. La soglia RTS deve avere un valore minori della dimensione del pacchetto IP e il valore di 'soglia di frammentazione' - qui posto a 256 - altrimenti sarà disabilitato. Il TCP è molto sensibile alle collisioni, così è importante attivare l'RTS.
La frammentazione permette di spezzare un pacchetto IP in una serie di frammenti minori che vengono trasmessi sul medium. Tutto questo aggiunge sovraccarico, ma in un ambiente rumoroso ciò riduce il costo dell'errore e permette ai pacchetti di attraversare le scariche di rumore. Le reti a maglia sono molto rumorose perchè i nodi impiegano lo stesso canale e, quindi, è probabile che le trasmissioni inteferiscano a vicenda. Questo parametro imposta la massima dimensione in byte che permetta la pacchetto di non essere spezzettato per poi essere recapitato a pezzi - un valore uguale alla massima dimensione IP disabilita il meccanismo, cos' dev'essere minore della dimensione del pacchetto IP. Impostare la soglia di frammentazione è raccomandato.
Una volta che sono stati assegnati un indirizzo IP valido ed una maschera di rete, una volta che l'interfaccia wireless sia attiva, il file di confifurazione di olsrd dev'essere alterato perchè olsrd trovi ed impieghi le interfacce con le quali si intende farlo lavorare.
Per Mac OS-X e Windows è disponibile una simpatica GUI per configurare e controllare il demone disponibile. Sfortunatamente, questi tenta l'utente che manchi di competenze a commettere errori stupidi - quali annunciare la presenza di un buco nero. Su BSD e Linux il file di configurazione è:
Un semplice file di configurazione olsrd.conf
Non verrà di seguito presentato un file di configurazione completo. Ci saranno invece alcune impostazioni essenziali che devono essere controllate.
UseHysteresis no
TcRedundancy 2
MprCoverage 3
LinkQualityLevel 2
LinkQualityWinSize 20
LoadPlugin "olsrd_dyn_gw.so.0.3"
{
PlParam "Interval" "60"
PlParam "Ping" "151.1.1.1"
PlParam "Ping" "194.25.2.129"
}
Interface "ath0" "wlan0" {
Ip4Broadcast 255.255.255.255
}Ci sono molte altre opzioni disponibili nel olsrd.conf, ma queste opzioni base dovrebbero permettervi di iniziare. Dopo che questi passi sono stati completati, olsrd può essere avviato con un semplice comando all'interno di un terminale:
olsrd -d 2
Si raccomanda di lanciare il programma con l'opzione di debugging "-d 2", quando lo si usi su una workstation, specialmente se si tratta del primo avvio. Si può così osservare come si comporti olsrd e monitorare quale sia la qualità dei link con i vicini. Sui dispositivi embedded, invece, il livello di debug dovrebbe essere posto a zero (off), perchè le operazioni di debugging caricano pesantemente la CPU.
I dati in uscita del debugging dovrebbero essere simili a questo:
--- 19:27:45.51 --------------------------------------------- DIJKSTRA 192.168.120.1:1.00 (one-hop) 192.168.120.3:1.00 (one-hop) --- 19:27:45.51 ------------------------------------------------ LINKS IP address hyst LQ lost total NLQ ETX 192.168.120.1 0.000 1.000 0 20 1.000 1.00 192.168.120.3 0.000 1.000 0 20 1.000 1.00 --- 19:27:45.51 -------------------------------------------- NEIGHBORS IP address LQ NLQ SYM MPR MPRS will 192.168.120.1 1.000 1.000 YES NO YES 3 192.168.120.3 1.000 1.000 YES NO YES 6 --- 19:27:45.51 --------------------------------------------- TOPOLOGY Source IP addr Dest IP addr LQ ILQ ETX 192.168.120.1 192.168.120.17 1.000 1.000 1.00 192.168.120.3 192.168.120.17 1.000 1.000 1.00
Impiego di OLSR su Ethernet e su interfacce multiple
Non è necessario disporre di un'interfaccia wireless per provare od impiegare olsrd - sebbene sia per queste interfacce che olsrd è stato progettato. Olsrd può essere benissimo impiegato su qualsiasi NIC (scheda di rete). Le interfacce WiFi non necessariamente devono operare in modo ad-hoc per formare una maglia quando i nodi dispongano di più di una interfaccia. Per dei collegamenti dedicati potrebbe essere un'interessante opzione mantenerli attivi in Infrastructure Mode. Molte schede WiFi posseggono driver che presentano problemi in Ad-hoc Mode, ma l'Infrastructure Mode funziona bene - perchè tutti si aspettano che almeno questa prestazione sia garantita. Il modo ad-hoc non è così popolare, così la realizzazione di un modo ad-hoc è sempre stata trascurata da molti produttori. Con la crescente attenzione alle reti a maglia, la situazione dei driver sta ora migliorando.
Molte persone usano olsrd su interfacce wireless ed altre cablate, non hanno bisgono di tenere conto dell'architettura della rete. Si limitano a collegare antenne alle loro schede WiFi, collegare cavi alle loro schede Ethernet, abilitare olsrd ad essere lanciato su tutti i computer e su tutte le interfacce e quindi danno il via al tutto. Tutto ciò è piuttosto un abusare di un protocollo che era stato concepito per permettere il wireless networking su link con perdite, ma perchè impedirlo?
Ci si aspetta che olsrd sia un sovra-protocollo. Chiaramente non è necessario inviare un messaggio di Hello su un'interfaccia ogni due secondi, ma funziona. Questo comportamento non dev'essere assunto come raccomandazione, è solo incredibile cosa facciano le persone di questo protocollo, ed hanno successo. Infatti è entusiasmante l'idea di mettere a disposizione un protocollo che risolva tutto per dei principianti che desiderino reti LAN di dimensioni medio-piccole.
Plugin
Diversi plugin sono disponibili per olsrd. Si veda sul sito olsr.org per una lista completa. Di seguito, una breve HOW-TO per il plugin che visualizza la topologia di una rete.
attachment:figure-3.8.png |
Figura 3.8: Una topologia di rete OLSR generata automaticamente. |
Spesso, per la comprensione di una rete a maglia, è molto utile riuscire ad esibirne la topologia di rete in modo grafico. Olsrd_dot_draw presenta come risultato la tipologia nel formato "dot file" sulla porta 2004 in TCP. Gli strumenti graphviz possono quindi essere impiegati per tracciarne i grafici.
Installare il plugin dot_draw
Si compilino i plugin olsr separatamente e li si installi. Per caricare il plugin, aggiungere la seguente riga al file /etc/olsrd.conf
LoadPlugin "olsrd_dot_draw.so.0.3"
{
PlParam "accept" "192.168.0.5"
PlParam "port" "2004"
}Il parametro "accept" specifica quale macchina sia abilitata a visualizzare le informazioni della topologia (al momento, solo una) e, di default, è impostato "localhost".
Far ripartire olsr e verificare se si ottenga output sulla porta TCP 2004
telnet localhost 2004
Dopo un certo periodo, si dovrebbe ottenere del testo come risultato.
Si può allora salvare l'output delle descrizioni grafiche e lanciare i tool dot o neato dal pacchetto graphviz, al fine di ottenere le immagini.
Bruno Randolf ha scritto un breve script perl che richiede periodicamente le informazioni di topologia da olsrd e le visualizza impiegando gli strumenti di graphviz e di ImageMagick.
Per prima cosa, si installino sulla workstation i seguenti pacchetti:
Si scarichi lo script da: http://meshcube.org/nylon/utils/olsr-topology-view.pl
Ora è possibile lanciare lo script con il comando: ./olsr-topology-view.pl , e vedere così gli aggiornamenti della topologia in tempo quasi-reale.
Risoluzione dei malfunzionamenti
Fintantochè le schede WiFi riescono a 'vedersi' una con l'altra tramite collegamenti radio, la richiesta di un ping funzionerà, a prescindere dall'esecuzione di olsrd. Ciò succede perchè le ampie netmask rendono effettivamente ogni nodo su un link-local, sì da accantonare qualsiasi problema di routing già con il primo hop. E' la prima cosa che si dovrebbe controllare se il comportamento della rete non sia quello aspettato. Gran parte dei malditesta che vengono forniti dalle schede WiFi nella modalità Ad-Hoc sono causati dal fatto che i driver per il modo Ad-Hoc sono realizzati in modo approssimativo. Se non è possibile ottenere il ping diretto con i nodi in visibilità, si tratta probabilmente di un problema di scheda e driver, od, in alternativa, sono errati i parametri di impostazione della rete.
Se le macchine possono ottenere il ping una dall'altra, ma olsrd non riesce a ricavare le rotte, allora dovrebbero essere ricontrollati gli indirizzi IP, la netmask ed il broadcast.
E' forse in azione un firewall? Verificare che non intercetti la porta UDP 698.
Buon divertimento!
Stima della Capacità
I collegamenti wireless possono assicurare agli utenti un throughput maggiore, rispetto alle tradizionali connessioni ad Internet, quali la VSAT, la linea telefonica o la DSL. Il Throughput è altrimento denominato capacità del canale, o semplicemente larghezza di banda (sebbene tale termine non abbia attinenza con la larghezza di banda radio). E' importante comprendere che la velocità dichiarata di un dispositivo wireless (il data rate) indica la velocità alla quale questi riesce a comunicare simboli via radio, non l'effettivo throughput che potrà essere osservato in pratica. Come accennato in precedenza, un singolo collegamento 802.11g può raggiungere i 54Mbps via radio, ma assicurerà un throighput effettivo fino a 22Mbps; il resto è sovraccarico che le radio impiegano per coordinare il proprio segnale usando il protocollo 802.11g.
Si noti che il throughput è una misura di bit sul tempo. 22Mbps significa che, in un qualsiasi secondo, 22 megabit possono essere inviati da un capo del collegamento all'altro. Se l'utente tenta di spingervi più di 22 megabit, l'operazione richiederà un tempo maggiore di un secondo. Poichè non possono essere inviati immediatamente, i dati vengono inseriti in una coda, per poi essere trasmessi il più presto possibile. Questo accodamento di dati allunga i tempi necessari perchè l'ultimo bit inserito in coda possa attraversare il collegamento. Il tempo che si rende necessario per l'attraversamento del collegamento è chiamato latenza, ed una latenza più pesante è chiamata ritardo. Il collegamento potrà anche trasferire tutto il traffico accodato, ma chi lo riceve potrà lamentare un incremento del ritardo.
Quale troughput sarà richiesto per i vostri utenti? Dipende da quanti essi siano, e da come intendano impiegare il collegamento wireless. Applicazioni diverse di Internet richiedono valori diversi di throughput.
Applicazione |
BW / Utente |
Note |
Messaggi di Testo / IM |
< 1 Kbps |
Poichè il traffico è rado ed asincrono, IM accetterà alta latenza. |
Posta Elettronica |
da 1 a 100 Kbps |
Come per IM, la posta elettronica è asincrona ed intermittente, quindi ammetterà latenza. Allegati pesanti, virus e spam incrementano sensibilmente l'impiego di banda. Si noti come i servizi di posta elettronica via web (come Yahoo ed Hotmail) debbano essere considerati navigazione sul web, piuttosto che posta elettronica. |
Navigazione web |
50 - 100+ Kbps |
I Web browser impiegano la rete solo quando richiedono dati. La comunicazione è asincrona, quindi un sensibile ritardo può essere accettato. Quando i browser richiedono più dati (immagini di grandi dimensioni, download pesanti, etc.), l'impiego di banda s'innalzerà in maniera significativa.. |
Streaming audio |
96 - 160 Kbps |
Ogni utente di un servizio di streaming audio service impiegherà una relativamente ampia larghezza di banda in modo costante, fintantochè trasferisce audio. Il servizio può accettare una latenza occasionale, impiegando dei buffer ampi presso i partecipanti. Periodi più lunghi di ritardo causeranno invece degli "slittamenti" dell'audio, se non addirittura la caduta della sessione. |
Voice over IP (VoIP) |
24 - 100+ Kbps |
Come nello streaming audio, il VoIP richiede una quantità costante di banda per ciascuno degli utente per la dirata della chiamata, ma tale quantità di banda è pressochè equivalente nelle due direzioni del collegamento. La latenza su una connessione VoIP è avvertita immediatamente e disturba l'impiego. Ritardi superiori a pochi millisecondi sono inaccettabili per il VoIP.. |
Streaming video |
64 - 200+ Kbps |
Come per lo streming audio, l'occasionale latenza è evitata ricorrendo all'uso di buffer sugli utenti. Per funzionare con buona qualità, lo streaming video richiede alto throughput e bassa latenza. |
Applicazioni peer-to-peer per il filesharing (BitTorrent, KaZaA, Gnutella, eDonkey, etc.) |
0 - infiniti Mbps |
Se pure accettano valori arbitrari di latenza, le applicazioni peer-to-peer tendono a saturare tutto il throughput disponibile trasmettendo dati a quanti più utenti possibile, quanto più in fretta possibile. L'impiego di queste applicazioni sarà causa di ritardo e problemi di throughput per tutti gli altri utenti della rete, a meno che non si adottino attente allocazioni di banda. |
Per valutare il throughput necessario per la rete, si moltiplichi il numero di utenti previsti per l'applicazione che verrà presumibilmente richiesta. Per esempio, 50 utenti interessati prevalentemente alla navigazione web consumeranno presumibilmente 2.5 Mbps di throughput, o qualcosa di più nei momenti di punta, ed accetteranno una discreta latenza. Al contrario, 50 utenti VoIP che lavorino nello stesso momento richiederanno almeno 5Mbps di throughput in entrambe le direzioni con assolutamente nessuna latenza. Dal momento che gli apparati wireless 802.11g sono half-duplex (possono, cioè, alternativamente trasmettere o ricevere, ma non possono compiere le due azioni nello stesso momento), occorrerà di conseguenza raddoppiare il throughput richiesto, per un totale di 10Mbps. I collegamenti wireless dovranno garantire tale capacità ogni secondo, o la conversazione soffrirà di ritardi.
Poichè sarà improbabile che tutti gli utilizzatori richiedano la connessione precisamente nello stesso momento, si ricorre comunemente alla pratica detta della sovriscrizione (permettendo, cioè, più utenti di quanto la banda massima possa sostenere). Una sovriscrizione di un fattore da 2 a 5 è piuttosto comune. Con tutta probabilità, la sovriscrizione verrà impiegata nella fase di costruzione dell'infrastruttura di rete. Attraverso l'attenta osservazione del throughput sulla rete, sarà poi possibile pianificare quando incrementare vari segmenti della rete, e quante risorse supplementari siano necessarie.
Per quanta capacità verrà fornita, gli utenti troveranno alla fine delle applicazioni che la satureranno. Come si vedrà alla fine di questo capitolo, impiegare tecniche di bandwith shaping (allocazione di banda) può contribuire a ridurre i problemi di latenza. Ricorrendo al bandwith shaping, al web caching ed ad altre tecniche, si possono ridurre significatamente i valori di latenza, migliorando il throughput complessivo della rete.
Per avere un'idea del ritardo avvertito su connessioni molto lente, l'ICTP ha realizzato un simulatore di larghezza di banda. Questo simulatore provvederà a scaricare una pagina web, impiegando la massima velocità e la velocità ridotta secondo le impostazioni che si sceglieranno. Questa dimostrazione offre un'immediata comprensione di come l'utilità di Internet, come strumento di comunicazione, venga ridotta da basso throughput e da alta latenza. Il simulatore è disponibile sotto http://wireless.ictp.trieste.it/simulator/
Pianificazione del Collegamento
Un sistema di comunicazione base consiste di due radio, ciascuna con la propria antenna, che sono separate dal percorso che dev'essere coperto. Per poter instaurare una comunicazione, le due radio richiedono un segnale minimo che raggiunga le antenne e che venga quindi presentato ai loro ingressi. La determinazione della fattibilità del collegamento è un processo chiamato calcolo del link budget. Se i segnali possano o meno essere scambiati tra le radio dipende dalla qualità dell'attrezzatura usata e dal degrado del segnale dovuto dalla distanza, degrado chimato path loss (perdita di percorso).
Calcolare il link budget
La potenza disponibile in un sistema 802.11 può essere caratterizzata dai due seguenti fattori:
Potenza di Trasmissione. E' espressa in milliwatt o in dBm. La potenza di trasmissione varia dai 30mW ai 200mW o più. La potenza di trasmissione è spesso dipendente dalla velocità della trasmissione stessa. La potenza di trasmissione di un particolare dispositivo dovrebbe essere esplicitata dalla documentazione fornita dal produttore, ma può essere difficile da trovare. Può allora essere d'aiuto la consultazione di database disponibili online, quali quello offerto da Seattle Wireless (http://www.seattlewireless.net/HardwareComparison).
Guadagno d'Antenna. Le antenne sono dispositivi passivi che amplificano il segnale ricevuto grazie alla loro forma fisica. Le antenne presentano la stessa caratteristica in trasmissione ed in ricezione. Un'antenna da 12 dB è tale senza dover specificare se sia in modalità di ricezione o di trasmissione. Le antenne paraboliche presentano un guadagno di 19-24 dB, le antenne omnidirezionali di 5-12 dB, quelle settoriali di 12-15 dB.
Livello minimo di Segnale ricevuto o, semplicemente, la sensibilità del ricevitore. Il minimo RSL (Received Signal Level, livello di segnale ricevuto) è sempre espresso in debibel negativi (- dBm) ed è la minima potenza di segnale che la radio riesce a distinguere. Il minimo RSL dipende dalla velocità, e come regola generale la velocità trasmissiva più bassa (1 Mbps) garantisce la sensibilità massima. Tale minimo è, tipicamente, compreso tra i -75 e -95 dBm. Come per la potenza di trasmissione, il dettaglio del RSL dovrebbe essere specificato dal produttore dell'apparato.
Perdite di Cavo. Parte dell'energia del segnale è persa nei cavi, nei connettori ed in altri dispositivi, presenti nel tratto tra l'antenna e la radio. La perdita dipende dal tipo di cavo usato e dalla sua lunghezza. La perdita di segnale per cavi coassiali corti, che includano i connettori, è relativamente bassa, compresa tra i valori di 2-3 dB. E' opportuna mantenere i cavi tra antenna e radio i più corti possibili.
Quando si calcola la perdita di percorso, diversi fattori devono essere considerati. Occorre mettere in conto la perdita nello spazio libero, la attenuazione e lo scattering. La potenza del segnale si riduce a causa della diffusione geometrica del fronte d'onda, comunemente conosciuta come perdita nello spazio libero. Trascurando il resto, più lontano sono le due radio, minore sarà il segnale ricevuto, a causa delle perdite in spazio libero. Tutto ciò è indipendente dall'ambiente circostante, ma è legato alla sola distanza. Questa perdita si genera perchè l'energia del segnale irradiato si espande secondo una funzione della distanza dal trasmettitore.
Impiegando i decibel per esprimere la perdita, ed adottando i 2.45 GHz come frequenza di ricetrasmissione, l'equazione per la perdita in spazio libero diventa:
Lfsl = 40 + 20*log(r)
dove Lfsl (attenuazione in spazio libero) è espressa in dB ed r è la distanza tra il trasmettitore ed il ricevitore, espressa in metri.
Il secondo contributo alla perdita sul percorso è dato dall'attenuazione, ovvero dall'assorbimento di parte di potenza del segnale nell'attraversamento di ostacoli quali alberi, mura, finestre e pavimenti di edifici. L'attenuazione può variare in modo pesante, dipendendo dalla struttura degli oggetti che il segnale attraversa, ed è di difficile quantificarla. Il modo più semplice per esprimere questo contributo alla perdita totale è quello di aggiungere una "perdita ammissibile" alla perdita in spazio libero. Per esempio, l'esperienza indica che gli alberi aggiungono un 10-20 dB di perdita per albero presente sul percorso, mentre i muri contribuiscono per 10-15 dB, in funzione della costruzione.
Sul percorso del collegamento, l'energia RF (Radio-Frequenza) lascia l'antenna trasmittente e si espande. Parte di questa energia raggiunge direttamente l'antenna ricevente, mentre altra vi arriva dopo essere rimbalzata sul terreno. Questo segnale riflesso, avendo percorso un tragitto più lungo di quello diretto, arriva all'antenna ricevente in ritardo, interferendo con il segnale principale. Questo effetto è chiamato multipath, fading o dispersione di segnale. In alcuni casi i segnali riflessi si sommano assieme e non causano problemi. Quando si sommano fuori fase, il segnale ricevuto è trascurabile. Ciò viene denominato nulling. Esiste una semplice tecnica per trattare il multipath, chiamata diversità d'antenna (antenna diversity): consiste nel dotare la radio di una seconda antenna. Il multipath è infatti un fenomeno fortemente legato al percorso. Se due segnali si annullano in fase in un punto, non si sommeranno distruttivamente in un secondo punto, vicino al primo. Se sono presenti due antenne, almeno una di quete dovrebbe essere in grado di ricevere un segnale utile, anche se l'altra sta ricevendo un segnale distorto. Nei dispositivi commerciali, viene impiegato la diversità d'antenna che ne attiva l'una o l'altra. Il segnale è così ricevuto solo da un'antenna per volta. Quanto trasmette, la radio usa l'antenna che è stata impiegata per ultima nella ricezione. La distorsione causata dal multipath riduce la capacità del ricevitore di ricostruire il segnale in una modo simile alla perdita di segnale. Un modo semplice per inserire gli effetti dello scattering nel calcolo delle perdite di percorso è di cambiare l'esponente del fattore distanza nella formula della perdita in spazio libero. L'esponente tende ad incrementare con il percorso in un ambiente con pesante scattering. Un 3 come esponente può essere usato in un ambiente esterno con alberi, mentre un 4 come esponente è impiegabile per un ambiente interno.
Quando si considerano assieme le perdite di spazio libero, l'attenuazione e lo scattering, la perdita di percorso è:
L(dB) = 40 + 10*n*log(r) + L(allowed)
Per una valutazione speditiva della fattibilità del collegamento, ci si può limitare a stimare la sola perdita in spazio libero. L'ambiente può apportare ulteriori perdite di segnale, e dovrebbe essere considerato per una valutazione esatta del collegamento. L'ambiente è in effetti un elemento importante, che che non dovrebbe mai essere trascurato.
Per valutare se un collegamento sia possibile, si dovrebbero conoscere le caratteristiche del materiale che viene usato e si dovrebbe stimare la perdita di percorso. Si noti che, nel condurre tale calcolo, si debba solo aggiungere la potenza di trasmissione da un capo del collegamento. Se si impiegano radio differenti nei due estremi del collegamento, occorre calcolare due vole la perdita sul percorso, una per ogni direzione, impiegando la corretta potenza di trasmissione per ognuno dei due calcoli. Aggiungendo tutti i guadagni e sottraendo tutte le perdite porta a:
Potenza di Trasmissione della Radio 1
+ Guadagno d'Antenna della Radio 1
- Perdite di Cavo della Radio 1
+ Guadagno d'Antenna della Radio 2
- Perdite di Cavo della Radio 2
------------------------
= Guadagno TotaleSottraendo le perdite di percorso al guadagno totale:
Guadagno Totale
- Perdite di Percorso
--------------
= Livello di segnale ad un capo del collegamento (al ricevitore della Radio 2)Se il livello di segnale che si ottiene è maggiore del minimo livello di segnale ricevuto, allora il collegamento è fattibile! Il segnale ricevuto è sufficientemente potente per le radio da poter essere usato. Si ricordi che il minimo RSL è sempre espresso in decibel negativi, quindi -56dBm è migliore di -70dBm. Su un dato percorso, la variazione nelle perdite di percorso nel tempo può essere rimarchevole, quindi un certo margine di sicurezza (divverenza tra il livello di segnale ed il minimo livello di segnale ricevuto) dovrebbe essere considerato. Questo margine è la quantità di segnale che, superando la sensibilità della radio, dev'essere ricevuta per garantire un collegamento stabile e di buona qualità anche sotto cattive condizioni meteorologiche o durante altri disturbi atmosferici. Un margine d'errore di 10-15 dB può andar bene. Per garantire spazio all'attenuazione ed al multipath nel segnale ricevuto, un margine di 20dB dovrebbe essere sufficiente.
Una volta che si sia calcolato il link budget verso una direzione, occorre ripetere il calcolo nella direzione opporta. Si sostituisca la potenza di trasmissione della seconda radio, e si verifichino i risultati verso il minimo livello di segnale ricevuto della prima radio.
Esempio di Calcolo di link budget
Come esempio, si intenda stimare la fattibilità di un collegamento di 5km, con un access point ed una radio come client. L'access point è connesso ad un'antenna omnidirezionale che ha un guadagno di 10 dBi, mentre il client è connesso ad un'antenna settoriale con guadagno 14dBi. La potenza di trasmissione dell'access point è di 100mW (ovvero, 20dBm), mentre la sua sensibilità è di -89dBm. Per il client, la potenza di trasmissione è di 30mW (o 15dBm) e la sua sensibilità è di -82 dBm. I cavi di connessione tra antenne e radio sono brevi, con una perdita di 2dB a ciascun lato del collegamento radio.
Sommando tra loro tutti i guadagni e sottraendo tutte le perdite nel collegamento tra AP e client, si ottiene:
+ 10 dBi (Guadagno d'Antenna della Radio 1) - 2 dB (Perdita nel Cavo d'Antenna della Radio 1) + 14 dBi (Guadagno d'Antenna della Radio 2) - 2 dB (Perdita nel Cavo d'Antenna della Radio 2) --------------------------------- 20 dB = Guadagno Totale
Trasmettendo quindi una potenza di 20dBm sull'AP, sul client radio - a distanza nulla dall'AP - si riceverebbero un segnale di potenza:
+ 20dBm + 20dB ---------------------------------- 40dBm = Potenza Segnale Ricevuto a Distanza Nulla (Prx0)
Considerando come il client radio non sia a distanza nulla dall'AP, occorrerà inserire la Perdita di Percorso che, su un collegamento di 5km dove si considera il solo spazio libero, sarà:
Perdita di Percorso(dB) = 40 + 20log(5000) = 113 dB
Sottraendo la Perdita di Percorso dalla Potenza del Segnale Ricevuto a Distanza Nulla si ottiene:
40 dBm - 113 dB = -73 dBm
Poichè -73dBm è una potenza magggiore della sensibilità della radio client (-82dBm), il livello di segnale è sufficiente alla radio client per raccogliere la trasmissione dell'access point. Rimangono 9dB di margine (-73dBm - -82dBm) che consentiranno un funzionamento dignitoso quando sia bel tempo, ma che potrebbero rivelarsi insufficienti in caso di avverse condi-meteo.
Si calcoli ora il collegamento nella direzione che parte dal client e prosegue verso l'access point:
15 dBm (Potenza di Trasmissione della Radio 2)
+ 14 dB (Guadagno d'Antenna della Radio 2)
- 2 dB (Perdita nel Cavo d'Antenna della Radio 2)
+ 10 dB (Guadagno d'Antenna della Radio 1)
- 2 dB (Perdita nel Cavo della Radio 1)
---------------------------------
35 dBm = Potenza del Segnale Ricevuto a Distanza Nulla (Prx0)Naturalmente, la Perdita di Percorso è la stessa sul viaggio di ritorno. Il segnale ricevuto sull'access point diventa quindi: Obviously, the path loss is the same on the return trip. So our received signal level on the access point side is:
35 dBm - 113 dB = -78 dBm Potenza del Segnale Ricevuto presso l'AP
Poichè la sensibilità dell'AP è -89dBm, 11dB sono garantiti come margine (-78dBm - -89dBm). Nel complesso, questo collegamento dovrebbe funzionare, ma si potrebbe puntare ad aumentare il margine di sicurezza del guadagno. Usando un'antenna a parabola (dish antenna) a 24dB sul lato client, piuttosto che l'antenna settoriale a 14dB, si otterrebbe un incremento del guadagno di 10dB in entrambe le direzioni del collegamento (si ricordi, infatti, come il guadagno d'antenna sia lo stesso sia in ricezione, che in trasmissione). Un'opzione più costosa potrebbe essere quella di impiegare radio con maggiore potenza ad entrambi i lati del collegamento, ma si osservi come l'aggiunta di un amplificatore, o l'impiego di una scheda radio di maggior potenza, ad un solo lato del collegmamento non ne migliori la qualità complessiva.
Strumenti disponibili online possono essere impiegati per calcolare il link budget. Per esempio, il Green Bay Professional Packet Radio's Wireless Network Link Analysis (http://my.athenet.net/~multiplx/cgi-bin/wireless.main.cgi) è uno strumento eccellente. La Super Edition genera un file PDF che contiene la zona di Fresnel ed i grafici dei percorsi radio. Gli script di calcolo possono essere scaricati dal sito web ed essere installati sul proprio computer. Si approfondirà l'argomento di un eccellente strumento online nella prossima sezione, Software per la Pianificazione del Collegamento).
Anche il sito web Terabeam dispone di un eccellente calcolatore, disponibile online (http://www.terabeam.com/support/calculations/index.php).
Tavole per il Calcolo del Link Budget
Per calcolare il link budget, si approssimi semplicemente la distanza, quindi si ricorra alla tavola seguente:
Perdita in Spazio Libero a 2.4GHz
Distanza (m) |
100 |
500 |
1,000 |
3,000 |
5,000 |
10,000 |
Perdita (dB) |
80 |
94 |
100 |
110 |
113 |
120 |
Guadagno d'Antenna Totale:
Guadagno d'Antenna Radio 1 (dB) |
+ Guadagno d'Antenna Radio 2 (dB) |
= Guadagno Totale d'Antenna |
_ |
_ |
_ |
Perdite:
Perdita del Cavo d'Antenna sulla Radio 1 (dB) |
Perdita del Cavo d'Antenna sulla Radio 2 (dB) |
Perdita in Spazio Libero (dB) |
= Perdita Totale (dB) |
_ |
_ |
_ |
_ |
Link Budget per collegamento Radio 1 -> Radio 2:
Potenza TX Radio 1 (dBm) |
+ Guadagno Totale d'Antenna Antenna (dB) |
- Perdita Totale (dB) |
= Potenza del Segnale Ricevuto (dBm) |
> Sensibilità della Radio 2(dBm) |
_ |
_ |
_ |
_ |
_ |
Link Budget per collegamento Radio 2 -> Radio 1:
Potenza TX Radio 2 (dBm) |
+ Guadagno Totale d'Antenna Antenna (dB) |
- Perdita Totale (dB) |
= Potenza del Segnale Ricevuto (dBm) |
> Sensibilità della Radio 1(dBm) |
_ |
_ |
_ |
_ |
_ |
Se il segnale ricevuto è maggiore della sensibilità in entrambe le direzioni del collegamento, il collegamento è fattibile.
Software per la Pianificazione del Collegamento
Se il calcolo a mano del link budget è impegnativo, ci sono diversi strumenti a disposizione che possono contribuire ad automatizzare il processo. Oltre a calcolare la Perdita in Spazio Libero, questi strumenti tengono anche conto di diversi altri rilevanti fattori (come assorbimento per gli alberi, effetti del terreno, clima, ed addirittura stime di perdita di percorso in tratte urbane). In questa sezione, si discuterà di due strumenti liberi che sono utili per pianificare collegamenti wireless: le utility per la progettazione interattiva della rete online Green Bay Professional Packet Radio e Radop,pboòe-
CGI per il Progetto interattivo
Il Green Bay Professional Packet Radio group (GBPRR) ha realizzato diversi strumenti decisamente utili per pianificare i collegamenti, ponendoli poi gratuitamente a disposizione online. Si possono ricercare sotto http://www.qsl.net/n9zia/wireless/page09.html . Poichè sono su Internet, questi strumenti richiederanno per funzionare il semplice impiego di un navigatore che disponga di accesso ad Internet.
Si esaminerà ora il primo strumento di lavoro, il Wireless Network Link Analysis. E' reperibile online presso: http://my.athenet.net/~multiplx/cgi-bin/wireless.main.cgi .
Per iniziare, si inserisca il canale che dev'essere impiegato nel collegamento. Il canale può essere descritto in MHz o GHz. Se la frequenza non è nota, si consulti la tabella in Appendice B. Si osservi come la tabella riporti la frequenza centrale di ogni canale, mentre lo strumento richiede la massima frequenza trasmessa. Per ricavare la massima frequenza trasmessa per un canale, basta addizionare 11MHz alla frequenza centrale.
Quindi, si proceda con i dettagli del lato trasmettitore del collegamento, comprendendo il tipo di linea trasmissiva, il guadagno d'antenna, ed altri particolari. Si cerchi di inserire quanti più dati sia possibile, provvedendo eventualmente a stimarli. Si possono inserire anche l'altezza dell'antenna e l'elevazione del sito: questi dati verranno usati per determinare l'angolo di elevazione dell'antenna. Per ricavare la zona libera di Fresnel, sarà necessario usare il calcolatore della zona di Fresnel del GBPRR.
La sezione successiva è molto simile, e si riferisce all'altro capo del collegamento. Si inseriscano tutti i dati nei campi relativi.
Per finire, l'ultima sezione descrive il clima, il terreno e la distanza del collegamento. Si inseriscano più dati possibili, provvedendo eventualmente a stimarli. La distanza di collegamento può essere calcolata specificando la latitudine e la longitudine di entrami i siti, oppure può essere inserita direttamente a mano.
Ora, si clicchi sul bottone Submit per ottenere un resoconto dettagliato sul link proposto. Questo resoconto include tutti i dati inseriti, così come la perdita di percorso previsto, l'incidenza di errori (error rate) ed il periodo di operatività (uptime). Questi numeri sono tutti completamente teorici, ma possono offrire un'idea della fattibilità del link. Giocando con i valori inseriti in ingresso, si può provare un "cosa-succede-se", per vedere come la variazione dei parametri influirà sulla connessione.
Oltre allo strumento base per l'analisi del collegamento, GBPRR fornisce "un'edizione speciale" che fornirà anche un resoconto in PDF, come pure un numero di altri strumenti molto utili (compreso il calcolatore della zona di Fresnel, il calcolatore delle Distanze & Angoli di Brandeggio, il calcolatore per la conversione in Decibel, giusto per citarne qualcuno). Viene anche fornito il codice sorgente di gran parte di questi strumenti.
RadioMobile
Radio Mobile è uno strumento di progetto e simulazione di sistemi wireless. Stima le prestazioni di un collegamento radio impiegando le informazioni disponibili sul materiale e su una mappa digitale dell'area. E' un programma sotto licenza "public domain" che gira sotto Windows, o sotto Linux con l'impiego delle API di Wine.
Radio Mobile usa un modello digitale del rilievo del terreno per il calcolo della copertura, indicando la potenza del segnale ricevuto su vari punti lungo il percorso. Costruisce automaticamente un profilo tra due punti sulla mappa digitale, mostrando l'area di copertura e la prima zona di Fresnel. Nella simulazione, controlla la linea di vista e calcola la Perdita di Percorso, includendo le perdite dovute ad ostacoli. E' possibile creare reti di tipologie differenti, comprese le reti master/slave, le punto-punto e le punto-multipunto.
attachment:figure-3.9.png |
Il software calcola l'area di copertura dalla stazione base in un sistema punto-multipunto. Funziona per sistemi che siano caratterizzati da una frequenza di lavoro dai 20 kHz ai 200 GHz. Le Mappe digitali di Rilievo (DEM, Digital Elevation Map) sono liberamente disponibili da differenti fonti, e sono disponibili per gran parte del mondo. Le DEM non mostrano la linea di costa od altri punti cospicui, rapidamente riconoscibili, ma possono facilmente essere combinate con altri tipi di informazione (quali foto aere, o carte topografiche) su strati differenti, per ottenere una rappresentazione più utile ed immediatamente riconoscibile. Si possono digitalizzare le proprie mappe e combinarle con le DEM. Le mappe digitali di rilievo possono essere combinate con le mappe ottenute dallo scanner, dalle foto satellitari e con i servizi cartografici su Internet (come Mapquest) per costruire dei diagrammi di predizione.
Radio Mobile può essere scaricato da qui: http://www.cplus.org/rmw/download.html
La pagina principale del sito Radio Mobile, con esempi e tutorial, è disponibile sotto: http://www.cplus.org/rmw/english1.html
RadioMobile e Linux
Radio Mobile gira anche impiegando Wine con Ubuntu Linux. Mentre l'applicazione funziona, alcuni bottoni possono apparire fuori della propria posizione e possono quindi essere difficili da leggere.
A noi è riuscito far funzionare Radio Mobile con Linux impiegando il seguente ambiente:
- IBM Thinkpad x31
Ubuntu Breezy (v5.10), http://www.ubuntu.com/
Wine version 20050725, dallUbuntu Universe repository
Informazioni dettagliate su come installare Radio Mobile su Wine sono disponibili sotto http://www.cplus.org/rmw/download.html. Sono da seguire tutti i passaggi, ad eccezione del passo 1 (poichè risulta difficile estrarre una libreria DLL dal file VBRUN60SP6.EXE sotto Linux). Si potrà ricorrere od alla copia del file MSVBVM60.DLL da una macchina Windows, che già abbia installato l'ambiente run-time di Visual Basic 6, od allo scarico del file da Internet, dopo aver cercato MSVBVM60.DLL con Google.
Si riprenda quindi dal passo 2 dell'URL sopra riportata, assicurandosi di scompattare il file scaricato nella stessa directory nella quale è stato posto il file DLL scaricato. Si osservi come non occorra poi preoccuparsi delle prescrizioni che seguono il passo 4; sono fasi successive che sono necessarie solo per utenti Windows.
Alla fine, si può lanciare Wine da un terminale con il comando:
# wine RMWDLX.exe
A questo punto, si dovrebbe vedere Radio Mobile che funziona nella sessione X Windows.
Eliminare il Rumore
Le bande U-NII e ISM - non soggette a licenza - rappresentano un segmento molto limitato dello spettro elettromagnetico conosciuto. Dato che tale regione può essere impiegata senza corrispondere pagamenti di licenza, molti dispositivi di consumo la impiegano per una vasta serie di applicazioni. Telefoni cordless, ripetitori video, bluetooth, baby monitor ed anche forni a microonde conmpetono con le reti wireless per l'impiego della limitatissima banda su 2.4 GHz. Questi segnali, così come quelli di altre reti wireless, possono comportare problemi significativi per i collegamenti wireless a lunga distanza. Di seguito sono descritti alcune misure che si possono intraprendere per ridurre la ricezione di segnali indesiderati.
Aumentare il guadagno d'antenna su entrambi gli estremi del collegamento punto-a-punto'. Le antenne non solo aumentano il guadagno in un collegamento, ma aumentando la loro direttività si tende ad abbattere il rumore che proviene dalle aree prossime al collegamento. Due antenne a parabola ad alto guadagno, puntate una verso l'altra, ridurranno fortemente il rumore dalle direzioni che sono fuori dal percorso del collegamento. Usando invece antenne omnidirezionali, si raccoglierà il rumore da tutte le direzioni.
Non usare un amplificatore Come si vedrà nel capitolo quattro, gli amplificatori possono peggiorare i problemi di interferenza, amplificando indiscriminatamente tutti i segnali ricevuti, compreso le sorgenti di rumore. Gli amplificatori causano inoltre problemi di interferenza per altri utenti della stessa banda che siano nelle vicinanze.
Usare antenne settoriali anzichè un'antenna omnidirezionale Con l'impiego di più antenne settoriali, si può ridurre il rumore complessivo ricevuto ad un punto di distribuzione. Impiegando canali scalati su ciascuna antenna settoriale, si può inoltre aumentare la banda disponibile per i vostri utenti.
attachment:figure-3.10-ita.png |
Figure 3.10: Confronto tra una singola antenna omnidirezionale e più antenne settoriali |
Usare il miglior canale disponibile Si ricordi che i canali dell'802.11b/g sono ampi 22MHz, ma sono scalati tra loro di appena 5 MHz. Si conduca una site survey (verifica d'ambiente), come spiegato nel capitolo otto, e si selezioni un canale che sia il più lontano possibile dalle sorgenti di rumore presenti. Si ricordi che il panorama wireless può cambiare in ogni momento, quando le persone inseriscono nuovi dispositivi (telefoni cordless, altre reti, etc.). Se il vostro collegamento registra difficoltà nell'inviare i pacchetti, potrebbe esser necessario condurre un'altra site survey e scegliere un canale differente.
Impiegare salti più ridotti e dei ripetitori, piuttosto che un unico balzo a lunga distanza. Si mantengano i collegamenti punto-a-punto i più brevi possibile. Se può essere possibile creare un collegamento di 12km che tagli da parte a parte la città, si creeranno comunque ogni genere di interferenze. Se è possibile spezzare il collegamento unico in due o tre salti più ridotti, il collegamento complessivo risulterà probabilmente più stabile. Naturalmente, ciò non sarà possibile sui collegamenti rurali a lunga distanza, dove l'alimentazione e le infrastrutture non sono disponibili, ma d'altro canto anche i problemi di interferenza in tali condizioni diventano meno probabili.
Se possibile, si usino le bande di 5.8GHz, 900MHz od altre bande non soggette a licenza. Anche se questa è solo una soluzione a breve termine, ci sono attualmente molti più dispositivi di consumo che impiegano la banda dei 2.4GHz. Impiegando l'802.11a od un dispositivo che porti la banda da 2.4GHz a 5.8GHz si potranno evitare i problemi di congestione. Se si riesce a trovarli, alcuni vecchi apparati wireless (802.11) impiegano la banda libera a 900MHz (sfortunatamente, a bit rate decisamente minori). Altre tecnologie, come Ronja (http://ronja.twibright.com/), impiegano tecnologia ottica per collegamenti a corta distanza, senza interferenze.
Se tutto il resto fallisce, adottare lo spettro soggetto a licenza. Ci sono posti dove tutto lo spettro libero è impiegato completamente. In questi casi, può essere ragionevole affrontare la spesa addizionale per apparati proprietari che impieghino una banda meno congestionata. Per collegamenti punto-a-punto a lunga portata, che richiedano larga banda e la massima disponibilità, questa è senz'altro un'ozione da valutare. Naturalmente, queste caratteristiche sono ottenibili a prezzi decisamente superiori rispetto all'impiego di apparati per lo spettro libero.
Per riconoscere le sorgenti di rumore, sono necessari degli strumenti che esibiscano cosa stia succedendo nell'etere a 2.4GHz. Vedremo di seguito alcuni esempi di tali strumenti nel capitolo sei.
Ripetitori
L'elemento più critico nell'impostare collegamenti di rete sulle lunghe distanze è la linea di vista (spesso abbreviata in LOS, Line Of Sight). I sistemi a microonde terrestri non possono tollerare grandi colline, alberi, od altri ostacoli sul percorso di un collegamento a lunga distanza. Occorre disporre di una chiara percezione della disposizione del terreno tra i due punti per poter determinare se il collegamento sia possibile.
Ma anche se ci fosse una montagna tra due punti, si ricordi come gli ostacoli possano a volte essere trasformati in vantaggi. Le montagne possono bloccare il segnale, ma nell'ipotesi che l'alimentazione possa essere fornita, possono anche rappresentare ottimi luoghi per i ripetitori.
I ripetitori sono nodi che vengono configurati per ritrasmettere un traffico che non è destinato a loro stessi. In una rete a maglia, ogni nodo è un ripetitore. In una rete con infrastruttura tradizionale, i nodi devono essere configurati per inoltrare il traffico verso altri nodi.
Un ripetitore può impiegare uno o più dispositivi wireless. Quando si impieghi un solo elemento radio (è il caso detto ripetitore a braccio unico, one-arm repeater), l'efficienza totale è sotto la metà della banda disponibile, poichè la radio inviare o ricevere dati in modo alternativo, ma non in contemporanea. Tali dispositivi sono più economici, semplici, ed hanno minori pretese per l'alimentazione. Un ripetitore con due (o più) elementi radio può impiegarli al massimo delle loro capacità, posto che siano configurati su canali che non si sovrappongano. Naturalmente, i ripetitori possono disporre di una connessione Ethernet per garantire connettività locare su cavo.
I ripetitori possono essere acquistati come soluzione hardware completa, od essere altrimenti facilmente assemblati aggregando due o più nodi wireless con un cavo Ethernet. Quando si valuti di impiegare un ripetitore basato su tecnologia 802.11, si tenga presente che i nodi devono essere configurati in modalità master, managed od ad-hoc. Tipicamente, entrambi gli elementi radio in un ripetitore sono configurati in modalità master, per consentire a più utenti di connettersi ad entrambi i lati del ripetitore. Ma a seconda della configurazione della rete, uno o più dispositivi possono ricorrere alla modalità ad-hoc od anche a quella client.
Tipicamente, i ripetitori sono usati per superare ostacoli sul percorso di un collegamento a lunga distanza. Per esempio, ci possono essere edifici sul percorso, ma questi edifici sono abitati. ACcordi possono spesso essere composti con i proprietari dell'edificio per fornire loro banda come contropartita dei diritti di impiego del tetto e dell'alimentazione elettrica. Se i proprietari dell'edificio non sono interessati, gli inquilini dei piani più alti possono venir persuasi ad installare gli apparati su una finestra.
attachment:figure-3.11-ita.png |
Figura 3.11: Il ripetitore inoltra i pacchetti in aria tra i nodi che non hanno diretta visibilità. |
Se non si riesce a scavalcare un ostacolo, si può però spesso aggirarlo. Piuttosto che usare un link diretto, si provi l'approccio a salto multiplo per evitare l'ostacolo.
attachment:figure-3.12-ita.png |
Figura 3.12: L'alimentazione non era disponibile in cima alla collina, ma si risolse il problema impiegando ripetitori multipli attorno alla base. |
Infine, si può valutare di compiere un passo indietro per procedere in avanti. Se è disponibile un alto sito in una direzione diversa, e se tale sito ha visibilità oltre l'ostacolo, un collegamento stabile può essere realizzato tramite un percorso indiretto.
attachment:figure-3.13-ita.png |
Figura 3.13: Il sito D non garantiva un collegamento pulito tra i siti A o B, poichè il sito C è sul percorso e non è interessato ad accogliere un nodo. Con l'installazione di un ripetitore più alto, i nodi A, B e D possono connettersi. Si noti come il traffico dal nodo D in effetti si allontani dal resto della rete, prima di essere rilanciato. |
I ripetitori in una rete ricordano il principio de "i sei gradi di separazione". Il concetto spiega come, a prescindere dalla persona ricercata, siano necessari al massimo cinque intermediari per arrivare a contattarla. I ripetitori su alti siti possono "vedere" un gran numero di intermediari e, se il nodo è in vista del ripetitore, diventa possibile connettersi ad ogni altro nodo raggiungibile dal ripetitore.
Ottimizzazione del Traffico
La larghezza di banda viene misurata come quantità di bit su un intervallo di tempo. Sfortunatamente, la banda garantita da qualsiasi connessione di rete non è infinita. Si può sempre scaricare (o caricare) tutto il traffico che si richieda, basta attendere per tempi sufficientemente lunghi. Naturalmente, gli esseri umani non sono utenti pazienti come i computer, e non accettano di aspettare tempi infiniti perchè le proprie informazioni attraversino la rete. Per tale ragione, la larghezza di banda dev'essere gestita e soggetta a priorità, così come ogni altra risorsa limitata.
E' possibile migliorare significativamente il tempo di risposta, e massimizzare la velocità di trasferimento, eliminando dalla rete il traffico ridondante o non desiderato. Questa sezione descrive diverse tecniche di uso comune per sincerarsi che la rete trasporti solo il traffico che deve effettivaemente aattraversarla.
Web caching
Un Proxy Server web è un server sulla rete locale che mantiene copie delle pagine che siano state recentemente richieste o che siano più spesso richiamate. Quando un nuovo utente richiede queste pagine, queste vengono fornite dal proxy server locale, anzichè essere ricevute via Internet. Ciò si traduce in un accesso web decisamente più veloce, in molti casi, riducendo inoltre l'impiego della banda su Internet. Quando viene realizzato un proxy server, l'amministratore deve tener conto che alcune pagine non sono mantenibili in cache; per esempio, pagine che siano il risultato di script lato server, od altro contenuto generato dinamicamente.
Anche il caricamento delle pagine web viene apprezzato in modo diverso. Con un collegamento Internet lento, una pagina web tipica viene caricata lentamente, mostrando prima parte del testo e presentando quindi le figure una dietro l'altra. In una rete con un proxy server, ci possono essere dei ritardi durante i quali sembra non succedere niente, quando finalmente la pagina viene caricata in modo pressochè istantaneo. Ciò succede poichè l'informazione viene inviata dal computer così velocemente che si rende necessario un percettibile intervallo di tempo per costruire la pagina. Il tempo totale che si rende necessario per caricare un'intera pagina può arrivare ai dieci secondi, là ove in mancanza di un proxy server, sarebbero stati necessari 30 secondi per caricare la pagina in modo graduale. Ma se tale fenomeno non viene spiegato ad alcuni utenti impazienti, questi potrebbero lamentarsi della lentezza introdotta dal proxy server. E' normalmente compito dell'amministratore di rete gestire con gli utenti problemi di percezione di questo tipo.
Proxy server disponibili
Sono diversi i proxy server web disponibili. Di seguito sono elencati i pacchetti software più spesso utilizzati:
Squid. Il software open source Squid è lo standard de facto presso le università. E' libero, affidabile, facile da impiegare e da estendere (ad esempio, con l'inserimento di filtraggi sui contenuti e con il blocco delle pubblicità). Squid genera file di log che possono essere analizzati con applicativi come Awstats, o Webalizer, entrambi open source ed in grado di generare buoni report grafici. In generale, è più semplice installarlo come parte di una distribuzione specifica, piuttosto che scaricarlo da http://www.squid-cache.org/ (gran parte delle distribuzioni come Debian, così come versioni derivate da Unix come NetBSD e FreeBSD, vengono distribuite già fornite di Squid). Una buona guida per la configurazione di Squid può essere trovata presso http://squid-docs.sourceforge.net/latest/book-full.html.
Microsoft Proxy server 2.0. Non è disponibile per nuove installazioni, perchè è stato superato da Microsoft ISA server e non è più supportato. E' tuttavia impiegato presso alcuni enti, sebbene non debba forse esser preso in considerazione per nuove installazioni.
Microsoft ISA server. ISA server è un proxy server decisamente buono, che probabilmente è troppo costoso per ciò che fornisce. Comunque, con gli sconti educational può essere alla portata di alcuni enti. Presenta i propri report grafici, ma i file di log possono essere analizzati anche con i comuni software di analisi come Sawmill (http://www.sawmill.net/). Gli amministratori di un sito che impieghi MS ISA Server dovrebbero dedicare sufficiente impegno per ottenere una configurazione adeguata; in caso contrario, MS ISA Server può tradursi in un consumatore di banda di tutto rispetto. Per esempio, una installazione di default può facilmente consumare più banda di quanta il sito impiegasse precedentemente, perchè le pagine più richieste, con date di scadenza serrate (come quelle dei siti di informazione) vengono continuamente aggiornate. Per questo motivo diventa importante impostare correttamente i modi di caricamento, e configurarli perchè vengano impiegati prevalentemente in orari notturni. ISA Server può anche essere collegato a prodotti per il filtraggio dei contenuti, come WebSense. Per ulteriori informazioni, si veda: http://www.microsoft.com/isaserver/ e http://www.isaserver.org/ .
Impedire agli Utenti di aggirare il Proxy Server
Se, in generale, evadere la censura su Internet ed eludere le politiche di accesso riservato alle informazioni può essere un impegno politico encomiabile, proxy e firewall rimangono però strumenti necessari nelle aree che dispongano di banda molto limitata. Senza di loro, la stabilità e la disponibilità della rete sarebbero minacciate dagli stessi utenti legittimi. Tecniche per aggirare un proxy server possono essere reperito sotto: http://www.antiproxy.com/ . Questo sito risulta utile agli amministratori per valutare come la propria rete risponda a queste tecniche.
Per rendere efficace l'uso di un cache proxy, si potrebbe considerare la semplice impostazione di una politica d'accesso, fidandosi degli utenti. Nella raffigurazione sottostante, l'amministratore deve fidarsi del fatto che i propri utenti non scavalchino il proxy server.
attachment:figure-3.14-ita.png |
Figura 3.14: In questa rete si confida che gli utenti configurino propriamente i propri PC per l'impiego del proxy server. |
In questo caso l'amministratore usa, tipicamente, una delle seguenti tecniche:
Non presentare l'indirizzo del default gateway attraverso il servizio di DHCP. Sulle prime ciò può funzionare, ma qualche utente di rete più smaliziato che intenda scavalcare il proxy server potrebbe trovare - od indovinare - l'indirizzo del default gateway. Una volta che ciò si sia realizzato, la soluzione di come aggirare il proxy tenderà a passare di bocca in bocca.
Usare politiche di dominio o di gruppo. Ciò è molto utile per impostare correttamente il proxy server per Internet Explorer su tutti i computer del dominio, ma non è molto utile per prevenire l'aggiramento del proxy, perchè dipende dall'utente che si registra nel dominio NT. Un utente, con un computer su Windows 95/98/ME, può cancellare la propria registrazione e quindi scavalcare il proxy, e qualcuno che conosca la password di un utente locale sul suo computer Windows NT/2000/XP può registrarsi localmente e comportarsi in modo analogo.
Supplicare ed altercare con gli utenti. Non è mai la situazione ideale per l'amministratore di rete.
L'unico modo per assicurarsi che i proxy non vengano scavalcati, è adottare la corretta configurazione di rete, impiegando una delle tre tecniche sotto descritte.
Firewall
Un modo più affidabile per assicurarsi che dai PC non si possa aggirare il proxy può essere realizzato impiegando un firewall. Il firewall può essere configurato per permettere al solo proxy server di attraversarlo, cioè a presentare richieste HTTP su Internet. Ogni altro PC è bloccato, come mostrato nella figura sottostante.
attachment:figure-3.15-ita.png |
Figura 3.15: Il firewall interdice ai PC l'accesso diretto ad Internet, ma lo consente tramite il proxy server. |
Basarsi su un firewall, come nella rappresentazione sopra citata, può essere sufficiente o meno, in funzione da come sia configurato il firewall. Se questi si limita a bloccare l'accesso dalla LAN di campus verso la porta 80 dei server web, gli utenti smaliziati avranno modo di escogitare delle scappatoie. Inoltre, gli utenti saranno comunque in grado di impiegare protocolli avidi di banda, come Kazaa.
Doppia scheda di rete
Probabilmente il metodo più sicuro si ottiene installando due schede di rete nel proxy server, connettendo la rete di campus ad Internet come mostrato di seguito. In questo modo, la struttura di rete rende fisicamente impossibile raggiungere Internet senza passare attraverso il proxy server.
attachment:figure-3.16-ita.png |
Figura 3.16: L'unica percorso verso Internet attraversa il proxy. |
Il proxy server nella figura non dovrebbe avere impostato l'IP forwarding, a meno che gli amministratore non sappiano esattamente cosa intendano lasciar passare.
Un grande vantaggio di questa impostazione è che la tecnica conosciuta come transparent proxying può venire impiegata. Usare un transparent proxy significa deviare automaticamente le richieste web degli utenti al proxy server, senza alcun bisogno di configurare manualmente i singoli web browser affinchè usino il proxy server stesso. Tutto ciò forza l'intero traffico web ad essere messo in cache, elimina diverse possibilità di errore per gli utenti, e funziona pure con ogni dispositivo che non sia in grado di impiegare un proxy impostatovi manualmente. Per maggiori dettagli sulla configurazione di un transparent proxy con Squid, vedere sotto:
Routing impostato su Politiche di Gestione
Un modo per evitare l'aggiramento del proxy, ove si impieghino apparati Cisco, è l'adozione di politiche di routing (policy routing). Il router Cisco dirige le richieste web in modo trasparente verso il proxy server. Questa tecnica è impiegata presso la Makerere University. Il vantaggio di questo metodo è che, se il proxy è fuori servizio, le rotte fissate dal policy routing possono essere temporaneamente sospese, consentendo agli utenti di connettersi direttamente ad Internet.
Mirroring di un Sito web
Con il permesso del suo proprietario o del suo web master, l'intero contenuto di un sito web può essere posto in mirroring ("ricopiato") in un server locale, nelle ore notturne, se non è troppo corposo. Tale azione potrebbe essere valutata per i siti web di rilievo che possano essere di interesse per l'organizzazione o che possano risultare molto popolari tra gli utenti web. Può essere utile, ma ci possono essere anche potenziali svantaggi. Ad esempio, se il sito che viene ricostruito in locale contiene script CGI od altro contenuto dinamico che richieda un'interazione da parte dell'utente, ciò potrebbe causare problemi. Un esempio è quello di un sito web che richieda ai visitatori di registrarsi on link per una conferenza. Se qualcuno si registra on line su un server ricopiato (e se gli script ricopiati funzionano), chi organizza il sito originale non avrà le informazioni della persona che si è registrata.
Dato che il mirroring di un sito potrebbe ledere i diritti di autore, questa tecnica dovrebbe essere usata solo dietro l'autorizzazione del sito interessato. Se il sito ha in funzione il comando rsync, lo stesso sito può essere ricopiato impiegando lo stesso comando rsync. E' questo, probabilmente, il modo più veloce e più efficiente per mantenere sincronizzato il contenuto tra i due siti. Se il web server remoto non impiega rsync, il software che si raccomanda di usare è un programma chiamato wget. E' presente in gran parte delle distribuzioni di Unix/Linux. Una versione per Windows può essere reperita sotto http://xoomer.virgilio.it/hherold/, o nel pacchetto di tool liberi di Cygwin Unix (http://www.cygwin.com/).
Uno script può essere impostato perchè si attivi ogni notte su un web server locale, e conduca le seguenti azioni:
- Cambi la directory portandosi nella radice dei documenti del server web: per esempio,
- Effettui il mirroring del sito web impiegando il comando:
wget --cache=off -m http://www.python.org
La copia del sito web si troverà nella directory www.python.org. Il web server dovrebbe quindi essere configurato per fornire i contenuti di questa directory su un host virtuale basato sui nomi. Si imposti un server DNS locale che presenti una registrazione fittizia per questo sito. Affinchè tutto ciò funzioni, i PC client dovrebbero essere configurati per impiegare il server DNS locale come DNS primario (Ciò è comunque consigliabile in ogni caso, perchè un DNS locale velocizza i tempi di risposta per le richieste web).
Arricchire preventivamente la cache impiegando wget
Invece di impostare una copia locale di un sito web, come descritto nella precedente sezione, un approccio migliore è arricchire la cache del proxy adottando un processo automatico. Questo metodo è stato descritto da J. J. Eksteen e J. P. L. Cloete del CSIR di Pretoria, South Africa, in un documento intitolato Enhancing International World Wide Web Access in Mozambique Through the Use of Mirroring and Caching Proxies. In questo documento (disponibile presso http://www.isoc.org/inet97/ans97/cloet.htm) i due autori descrivono il funzionamento del procedimento:
"Un processo automatico recupera l'home page del sito ed un numero specificato di pagine ulteriori (seguendo in modo ricorsivo i link HTML delle pagine già raccolte) per mezzo di un proxy. Invece di scrivere le pagine recuperate sull'hard disk locale, il processo di copia elimina le pagine scaricate. Tutto ciò viene fatto per conservare le risorse di sistema e per evitare possibili conflitti sul diritto d'autore. Usando il proxy come intermediario, si garantisce che le pagine scaricate siano nella cache del proxy, come se un utente avesse avuto accesso a quelle pagine.
Quando un utente richiede le pagine già richiamate, gli vengono presentate quelle disponibili nella cache, senza congestionare il collegamento internazionale. Questo processo può essere condotto al di fuori delle ore di punta, con il fine di massimizzare l'impiego della banda e di non interferire con altre attività."
Il comando seguente (impostato per essere eseguito di notte, ogni giorno o settimana) è tutto ciò che si rende necessario (ripetendolo per ogni sito per cui si richieda l'arricchimento preventivo della cache).
wget --proxy-on --cache=off --delete after -m http://www.python.org
Spiegazione:
-m: ricopia (mirror) l'intero sito. Wget parte da www.python.org e segue tutti i link ipertestuali, sì da scaricare tutte le pagine sottostanti.
--proxy-on: assicurati che wget faccia uso del proxy server. Può non essere necessario nelle impostazioni dove sia impiegato un trasparent proxy
--cache=off: assicurati che i contenuti aggiornati siano scaricati da Internet, e non dal proxy server locale.
--delete after: cancella la copia costruita. Il contenuto in copia rimane nella cache del proxy fintantochè ci sia sufficiente spazio nel disco e posto che i parametri di cache del proxy siano impostati correttamente.
Wget dispone di molte altre opzioni in aggiunta a queste; per esempio, per passare la password per un sito web che la richieda. Quando si impiega questo strumento, Squid dovrebbe essere configurato con sufficiente spazio sul disco per contenere tutti i siti precaricati ed altro (intendendo per altro il normale impiego di Squid rivolto a pagine esterne a quelle dei siti precaricati). Fortunatamente, lo spazio sui dischi rigidi diventa sempre più economico e le dimensioni dei dischi sono sempre più ampie. Comunque, questa tecnica può essere usata solo con pochi siti selezionati. Questi siti non dovrebbere essere troppo grossi, affinchè si completi il processo prima che ricominci l'orario di lavoro, ed inoltre occorre sempre monitorare lo spazio libero disponibile sul disco.
Gerarchie di Cache
Se un organizzazione dispone di più proxy server, questi possono condividere informazioni di cache tra di loro. Per esempio, se una pagina web esiste nella cache del server A, ma non nella cache del server B, un utente collegato sul server B potrebbe ottenere l'oggetto dalla cache di A tramite B. Inter-Cache Protocol (ICP) and Cache Array Routing Protocol (CARP) possono permettere la condivisione di informazioni di cache. CARP è considerato migliore. Squid supporta entrambi i protocolli, mentre Microsoft ISA Server supporta il solo CARP. Per maggiori informazioni, vedere sotto: http://squid-docs.sourceforge.net/latest/html/c2075.html . Tale condivisione delle informazioni di cache riduce l'impiego di banda esterna nelle organizzazioni dove siano disponibili più proxy server.
Specifiche per Proxy
Su una rete di campus universitaria dovrebbero insistere più proxy server, sia per migliorare le prestazioni che per ragioni di ridondanza. Con i dischi rigidi odierni, più economici e capienti, si possono costruire potenti proxy server, con spazio disco di 50 GB e più dedicato alla cache. La prestazione del disco è essenziale, quindi i dischi SCSI, più veloci, sono in grado di offrire prestazioni migliori (sebbene una cache basata su dischi IDE sia comunque meglio di niente). RAID e mirroring non sono raccomandati.
E' inoltre consigliabile che un disco rigido separato sia dedicato alla cache. Per esempio, un disco rigido può essere impiegato per la cache, mentre un secondo per il sistema operativo e per la registrazione degli eventi (logging) della cache. Squid è progettato per impiegare quanta più RAM possibile, perchè quando i dati sono estratti dalla RAM si raggiungono velocità decisamente superiori a quelle ottenibili sugli hard disk. Per una rete di campus, la memoria RAM dovrebbe essere di 1 GB o più:
- Oltre alla memoria richiesta dal sistema operativo e dalle altre applicazioni, Squid richiede 10 MB di RAM per ogni GB di cache di disco. Quindi, se 50 GB di disco vengono assegnati alla cache, Squid richiederà 500 MB di memoria in più.
- La macchina richiederebbe inoltre 128 MB per Linux e 128 MB per X-Windows.
- Altri 256 MB dovrebbero essere aggiunti per altre applicazioni; sotto queste condizioni di lavoro, dovrebbe filare tutto liscio. Niente migliora le prestazioni di una macchina quanto installare un'ampia memoria, perchè ciò riduce la necessità di ricorrere agli hard disk. La memoria è migliaia di volte più veloce di un hard disk. I moderni sistemi operativi mantengono in memoria i dati frequentemente richiesti, se si rende impiegabile sufficiente RAM. Ma ricorrono a memoria virtuale (swap) quando non dispongono di abbastanza RAM.
DNS caching ed ottimizzazione
I server DNS caching-only non sono autorevoli per nessun dominio, forniscono piuttosto risultati dalla cache a fronte di interrogazioni presentate dai client loro attestati. Come un proxy server arricchisce di pagine web popolari la propria cache durante un periodo prefissato, gli indirizzi DNS sono posti in cache fintantochè il proprio time to live (TTL) non si estingua. Ciò ridurrà il traffico DNS sulla vostra connessione Internet, poichè la cache DNS sarà in grado di rispondere localmente e molte interrogazioni. Naturalmente, i computer client devono essere configurati per impiegare i server DNS caching-only, come server DNS di riferimento. Quando tutti i client impiegano questo server come proprio server DNS primario, questi si arricchirà presto la cache di indirizzi, sì da poter rapidamente risolvere gli indirizzi che siano stati già richiesti. I server DNS che sono autorevoli per un dominio agiscono anche come riferimento nomi-indirizzi per i computer di cui curano la diffusione dell'indirizzo IP.
Bind (named)
Bind è il programma standard di fatto per il name service in Internet. Installato e avviato, Bind funziona come caching server (nessuna ulteriore configurazione è necessaria). Bind può essere installato da un pacchetto tipo pacchetto Debian o tipo RPM. L'installazione da un pacchetto è normalmente il metodo più semplice. Su Debian, digitare:
apt-get install bind9
Oltre a mandare in esecuzione una cache, Bind può anche gestire zone autorevoli, può prestare servizi sotto altre zone autorevoli, può realizzare segmenti di spazi indirizzi, e pressochè ogni altra funzione che è possibile svolgere con il DNS.
dnsmasq
Un caching server DNS alternativo può essere dnsmasq. E' disponibile per BSD e per la più parte delle distribuzioni Linux, o dal sito http://freshmeat.net/projects/dnsmasq/ . Il maggior vantaggio di dnsmasq è la flessibilità; può funzionare facilmente sia come caching DNS proxy e come riferimento autorevole per macchine e domini, senza complicate configurazione dei file di zona. Gli aggiornamenti possono essere inseriti nei dati di zona senza nemmeno dover far riavviare il servizio. Può anche funzionare come DHCP server, e integrerà il servizio di DNS con le richieste DHCP delle macchine in rete. E' decisamente snello, stabile, ed estremamente flessibile. Bind è probabilmente una scelta indovinata per reti estese (oltre qualche centinaio di nodi), ma la semplicità e la flessibilità di dnsmasq lo rendono interessante per reti di dimensioni medio-piccole.
Windows NT
Per installare il servizio DNS su Windows NT4: selezionale il Pannello di Controllo -> Rete -> Servizi -> Aggiungi -> Microsoft DNS server. Inserire il CD NT4 di Windows quando richiesto. La configurazione di un server caching-only in NT è descritta nell'articolo 167234 della Knowledge Base. Dall'articolo:
"Installare semplicemente DNS e lanciare il Domain Name System Manager. Cliccare su DNS nel menù, selezionare Nuovo Server, ed inserire l'indirizzo IP del vostro computer dove è stato installato il DNS. Avete ora un server DNS caching-only."
Windows 2000
Per installare il servizio DNS: Menù d'avvio -> Impostazioni -> Pannello di controllo -> Aggiungi / Rimuovi Software. Tra i componenti di "Aggiungi / Rimuovi Software", selezionare Componenti -> Servizi di Rete -> Dettagli -> Domain Name System (DNS). Quindi avviare l'MMC di DNS (Menù di Avvio -> Programmi -> Strumenti di Gestione -> DNS). Dal Menù delle azioni selezionare "Collegare al computer...". Nella finestra "Seleziona il computer target", attivare "Il seguente computer:" ed inserire il nome di un server DNS che si intenda portare nella propria cache. Se è presente un "." [punto] nel manager DNS (appare di default), significa che il server DNS ritiene di essere il server DNS di root di Internet. Senz'altro si sbaglia. Cancellare il "." [punto] per rendere funzionante il tutto.
DNS separato e server ricopiato
Lo scopo di un DNS separato (split DNS, conosciuto anche come orizzonte separato, split horizon) è presentare una visione del dominio dall'interno differente da quella del mondo esterno. Esistono diversi accorgimenti per realizzare un DNS separato; per motivi di sicurezza, è consigliabile disporre di due differenti server DNS (ciascuno con un proprio database), uno interno ed uno esterno al dominio.
Il DNS separato può rendere possibile per dei client di una rete di campus risolvere gli indirizzi IP del dominio del campus in indirizzi locali IP secondo lo standard RFC1918, mentre il resto di Internet traduce gli stessi nomi in indirizzi IP differenti. Tutto ciò si realizza mantenendo due zone su due differenti server DNS relativi allo stesso dominio.
Una delle zone viene impiegata dai client di rete interni, mentre l'altra viene usata dagli utenti esterni di Internet. Per esempio, nella rete sottostante l'utente nel campus Makerere ottiene la risoluzione di http://www.makerere.ac.ug in 172.16.16.21, mentre un utente in qualsiasi altra parte di Internet ottiene invece la risoluzione in 195.171.16.13.
Il server DNS nel campus del disegno sopra riportato mantiene una file di zona per makerere.ac.ug ed è configurato come autorevole per tale dominio. Inoltre, funge come server DNS di cache per il campus Makerere, e tutti i computer nel campus sono configurati per impiegarlo come proprio server DNS.
I record DNS per il server DNS di campus apparirebbero simili a quanto segue:
makerere.ac.ug www CNAME webserver.makerere.ac.ug ftp CNAME ftpserver.makerere.ac.ug mail CNAME exchange.makerere.ac.ug mailserver A 172.16.16.21 webserver A 172.16.16.21 ftpserver A 172.16.16.21
Ma c'è un secondo server DNS presente in Internet che è in effetti autorevole per il dominio makerere.ac.ug. I record DNS per questa zona esterna risulterebbero come segue:
makerere.ac.ug
www A 195.171.16.13
ftp A 195.171.16.13
mail A 16.132.33.21
MX mail.makerere.ac.ug Il DNS separato non è vincolato all'impiego di indirizzi secondo lo standard RFC1918. Un ISP africano potrebbe, per esempio, mantenere siti web per conto di una università, ma anche mantenere copia degli stessi siti web in Europa. Ogni volta che i client di tale ISP provassero ad accedere al sito web, otterrebbero l'indirizzo IP presso l'ISP africano, mantenendo così il traffico all'interno dello stesso Paese. Quanto i visitatori di altri Paesi dovessero accedere al sito web, questi otterrebbero gli indirizzi IP dei siti web ricopiati in Europa. In questo modo, i visitatori internazionali non congestionerebbero i collegamenti satellitari (VSAT) impiegati dall'ISP per visitare il sito web dell'Università. Tale soluzione sta divendanto un'opzione allettante, poichè l'hosting web in prossimità della dorsale Internet è divendato decisamente economico..
Internet link optimization
As mentioned earlier, network throughput of up to 22Mbps can be achieved by using standard, unlicensed 802.11g wireless gear. This amount of bandwidth will likely be at least an order of magnitude higher than that provided by your Internet link, and should be able to comfortably support many simultaneous Internet users.
But if your primary Internet connection is through a VSAT link, you will encounter some performance issues if you rely on default TCP/IP parameters. By optimizing your VSAT link, you can significantly improve response times when accessing Internet hosts.
TCP/IP factors over a satellite connection
A VSAT is often referred to as a long fat pipe network. This term refers to factors that affect TCP/IP performance on any network that has relatively large bandwidth, but high latency. Most Internet connections in Africa and other parts of the developing world are via VSAT. Therefore, even if a university gets its connection via an ISP, this section might apply if the ISP's connection is via VSAT. The high latency in satellite networks is due to the long distance to the satellite and the constant speed of light. This distance adds about 520 ms to a packet’s round-trip time (RTT), compared to a typical RTT between Europe and the USA of about 140 ms.
attachment:figure-3.17-ita.png |
Figure 3.17: Due to the speed of light and long distances involved, a single ping packet can take more than 520ms to be acknowledged over a VSAT link. |
The factors that most significantly impact TCP/IP performance are long RTT, large bandwidth delay product, and transmission errors.
Generally speaking, operating systems that support modern TCP/IP implementations should be used in a satellite network. These implementations support the RFC 1323 extensions:
The window scale option for supporting large TCP window sizes (larger than 64KB).
Selective acknowledgement (SACK) to enable faster recovery from transmission errors.
- Timestamps for calculating appropriate RTT and retransmission timeout values for the link in use.
Long round-trip time (RTT)
Satellite links have an average RTT of around 520ms to the first hop. TCP uses the slow-start mechanism at the start of a connection to find the appropriate TCP/IP parameters for that connection. Time spent in the slow-start stage is proportional to the RTT, and for a satellite link it means that TCP stays in slow-start mode for a longer time than would otherwise be the case. This drastically decreases the throughput of short-duration TCP connections. This is can be seen in the way that a small website might take surprisingly long to load, but when a large file is transferred acceptable data rates are achieved after a while.
Furthermore, when packets are lost, TCP enters the congestion-control phase, and owing to the higher RTT, remains in this phase for a longer time, thus reducing the throughput of both short- and long-duration TCP connections.
Large bandwidth-delay product
The amount of data in transit on a link at any point of time is the product of bandwidth and the RTT. Because of the high latency of the satellite link, the bandwidth-delay product is large. TCP/IP allows the remote host to send a certain amount of data in advance without acknowledgment. An acknowledgment is usually required for all incoming data on a TCP/IP connection. However, the remote host is always allowed to send a certain amount of data without acknowledgment, which is important to achieve a good transfer rate on large bandwidth-delay product connections. This amount of data is called the TCP window size. The window size is usually 64KB in modern TCP/IP implementations.
On satellite networks, the value of the bandwidth-delay product is important. To utilize the link fully, the window size of the connection should be equal to the bandwidth-delay product. If the largest window size allowed is 64KB, the maximum theoretical throughput achievable via satellite is (window size) / RTT, or 64KB / 520 ms. This gives a maximum data rate of 123KB/s, which is 984 Kbps, regardless of the fact that the capacity of the link may be much greater.
Each TCP segment header contains a field called advertised window, which specifies how many additional bytes of data the receiver is prepared to accept. The advertised window is the receiver's current available buffer size. The sender is not allowed to send more bytes than the advertised window. To maximize performance, the sender should set its send buffer size and the receiver should set its receive buffer size to no less than the bandwidth-delay product. This buffer size has a maximum value of 64KB in most modern TCP/IP implementations.
To overcome the problem of TCP/IP stacks from operating systems that don't increase the window size beyond 64KB, a technique known as TCP acknowledgment spoofing can be used (see Performance Enhancing Proxy, below).
Transmission errors
In older TCP/IP implementations, packet loss is always considered to have been caused by congestion (as opposed to link errors). When this happens, TCP performs congestion avoidance, requiring three duplicate ACKs or slow start in the case of a timeout. Because of the long RTT value, once this congestion-control phase is started, TCP/IP on satellite links will take a longer time to return to the previous throughput level. Therefore errors on a satellite link have a more serious effect on the performance of TCP than over low latency links. To overcome this limitation, mechanisms such as Selective Acknowledgment (SACK) have been developed. SACK specifies exactly those packets that have been received, allowing the sender to retransmit only those segments that are missing because of link errors.
The Microsoft Windows 2000 TCP/IP Implementation Details White Paper states
"Windows 2000 introduces support for an important performance feature known as Selective Acknowledgment (SACK). SACK is especially important for connections using large TCP window sizes."
SACK has been a standard feature in Linux and BSD kernels for quite some time. Be sure that your Internet router and your ISP’s remote side both support SACK.
Implications for universities
If a site has a 512 Kbps connection to the Internet, the default TCP/IP settings are likely sufficient, because a 64 KB window size can fill up to 984 Kbps. But if the university has more than 984 Kbps, it might in some cases not get the full bandwidth of the available link due to the "long fat pipe network" factors discussed above. What these factors really imply is that they prevent a single machine from filling the entire bandwidth. This is not a bad thing during the day, because many people are using the bandwidth. But if, for example, there are large scheduled downloads at night, the administrator might want those downloads to make use of the full bandwidth, and the "long fat pipe network" factors might be an obstacle. This may also become critical if a significant amount of your network traffic routes through a single tunnel or VPN connection to the other end of the VSAT link.
Administrators might consider taking steps to ensure that the full bandwidth can be achieved by tuning their TCP/IP settings. If a university has implemented a network where all traffic has to go through the proxy (enforced by network layout), then the only machines that make connections to the Internet will be the proxy and mail servers.
For more information, see http://www.psc.edu/networking/perf_tune.html .
Performance-enhancing proxy (PEP)
The idea of a Performance-enhancing proxy is described in RFC 3135 (see http://www.ietf.org/rfc/rfc3135), and would be a proxy server with a large disk cache that has RFC 1323 extensions, among other features. A laptop has a TCP session with the PEP at the ISP. That PEP, and the one at the satellite provider, communicate using a different TCP session or even their own proprietary protocol. The PEP at the satellite provider gets the files from the web server. In this way, the TCP session is split, and thus the link characteristics that affect protocol performance (long fat pipe factors) are overcome (by TCP acknowledgment spoofing, for example). Additionally, the PEP makes use of proxying and pre-fetching to accelerate web access further.
Such a system can be built from scratch using Squid, for example, or purchased "off the shelf" from a number of vendors.