Dslam

Tutto ciò che ha a che fare con le reti

Moderators: Federico.Lagni, TheIrish, banshee, Wizard

Postby ep » Wed 04 Feb , 2009 1:32 am

Non avrò mai la pazienza di trovare o fare diagrammi così. Purtroppo mi rifaccio col testo :D

Comunque: Marx, gli "aggregating routers" del tuo schema possono in effetti essere corrispondenti ai BRA, tant'è vero che, ad esempio, almeno fino a un paio di anni fa (quindi prima della riorganizzazione delle aree di raccolta wholesale di TI) la buona Infostrada aggregava clientela residenziale e business povera (come me) di un bel pezzo di nord-est su di un BRA di Venezia, dei quali per inciso ogni tanto qualche parte rendeva l'anima bella al creatore, lasciando un bel po' di gente senza ADSL.

Non è detto, però, che coincidano: si possono anche tenere separati (e alla fine del post ci sarà un esempio).

Secondo me chi ha disegnato lo schema ha allungato troppo un paio di frecce e hai ragione tu, tant'è vero che è anche scritto che LCP/IPCP, lato utente, terminano presso il CPE, e non presso il PC. Il caso in cui non terminano è quello in cui il CPE è un modesto bridge (ad es. modem Pirelli tarpati da TI per la clientela con tariffe a consumo). In quei casi l'utente sceglie se collegarsi in Ethernet o in USB al CPE, ma è il computer a gestire la connessione PPP con un minidriver PPPoE o con qualcosa che parli su USB come al CPE più aggrada.

Infine, due note sullo stack dei protocolli: c'è in rete una bella analisi degli overhead, che necessariamente tratta anche i protocolli. Lo consiglio perché è molto chiaro.

Tutte le ADSL, con gli standard attuali, modulano su una parte più o meno estesa della banda disponibile su un normale doppino fonia, e tutte sfruttano le varie portanti create per scambiare delle celle ATM di 53 bytes, 5 di header e 48 di payload. Su questo non si scappa. Il DSLAM "stupido" L2 arriva fino a qui; è trasparente rispetto ai protocolli che girano sopra. Lui si occupa di scambiare in ciascuna cella gli identificatori del virtual path e del virtual channel (VPI/VCI) con qualcos'altro, preventivamente concordato con il loro prossimo punto di destinazione (sono degli indirizzi link-local, sostanzialmente!), forzare i limiti di banda previsti, multiplexare le celle sul flusso giusto e spedirle via. Diverso, ovviamente, il discorso per i DSLAM recenti e "furbi" (L3), che gestiscono anche quanto indicato da qui in poi.

Visto che i 48 byte di payload di una cella sono pochi e non potremmo farci stare nulla di utile, si usa sempre AAL5 (ATM Adaptation Layer 5) per spalmare i frame su più celle; AAL5 non è nulla di trascendentale, e prevede semplicemente che vengano create più celle ATM in sequenza (con i bit degli header settati correttamente, ecc.), che nell'ultima cella si metta il padding necessario, e che la si chiuda con 8 byte finali di gestione, tra cui 4 per un CRC.

Fino qui tutte le DSL sono uguali, ora viene il bello… :) Sopra questo strato ATM/AAL5, finalmente, possiamo mettere qualche tipo di frame; qui entriamo nella giungla di RFC 2684, con una quantità mostruosa di opzioni diverse.

Siccome è previsto che uno possa utilizzare più protocolli sulla stessa DSL, ci sono due possibilità: o sfruttiamo ATM e concordiamo con il nostro fornitore di connettività più virtual channel diversi, in modo da spedire ciascun protocollo su di un VC distinto, o inseriamo nel nostro frame degli elementi distintivi. Nel primo caso abbiamo il noto VC-mux (che più che un'incapsulazione è l'assenza di un'incapsulazione: vuol dire che non aggiungo nulla all'interno della mia data unit!); nel secondo la famosa LLC encapsulation, che consiste nel mettere in testa altri 3 o 4 byte e preparare il frame secondo LLC. Lo header in questione consiste di SAP di sorgente e destinazione, cioè l'equivalente delle "porte" di LLC, se mi si passa l'analogia, poi il tipo di frame, ed in alcuni casi il tipo di protocollo, detto NLPID.

Con il VC-mux è tutto abbastanza facile. Se ho deciso di farci girare IP routed, basterà schiaffare nel payload AAL5 il pacchetto IP. Se ho deciso di farci girare un protocollo bridged, compreso PPPoE, metterò due byte di padding e poi il frame Ethernet, a partire dall'indirizzo MAC di destinazione. Se voglio far girare PPP over ATM, entra in gioco RFC 2364, secondo il quale non faccio altro, nuovamente, che mettere l'intero pacchetto PPP dentro il payload AAL5.

Con l'LLC encapsulation la situazione è un filo più sofisticata, ma non molto: per i protocolli routed (ad es. IP) posso usufruire del formato abbreviato, in cui ho solo i 4 byte di cui sopra (specificati dall'RFC), compreso quindi l'NLPID, e poi il pacchetto da incapsulare; tutti insieme questi formano il payload AAL5. In alternativa posso usare un formato generico più dispendioso, che impiega 8 byte di intestazione: dei SAP diversi da quelli del formato "abbreviato" e una parte di header SNAP, con tre byte nulli ad indicare che la formattazione è la stessa di Ethernet (EtherType) ed il tipo Ethernet del protocollo trasportato (ad es. 08 00 per IPv4).

Nel caso di protocolli bridged, lo overhead aumenta ancora. LLC prevede diversi protocolli, quindi, per segnalare che sto incapsulando un pacchetto Ethernet: rispetto ad un pacchetto Ethernet "normale" ci sono almeno 8 byte di overhead, dopo i quali inizia lo header MAC (quindi il solito: 6 byte di MAC address di destinazione, 6 di MAC address sorgente, 2 di Ethertype). Alla fine si può scegliere di includere o non includere il codice di controllo (la FCS, frame check sequence).

Ovviamente il VC-mux è più semplice e trasmette meno dati. Però, tutto questo è stato standardizzato considerando che se il fornitore di connettività fa pagare relativamente poco per ciascun VC e relativamente tanto per la quantità di dati trasmessi, è convienente usare il VC-mux; al contrario, se il fornitore chiede delle tariffe rilevanti per ciascun VC instradato, allora mi conviene chiedergliene uno solo e giocarmelo nel migliore dei modi.

Insomma: se proprio bisogna usare PPP per forza, con PPPoA su VC-Mux ho l'alternativa più semplice: è veramente PPP incapsulato in ATM (mediante AAL5). Con PPPoE ho: PPP, dentro PPPoE (6 byte), dentro un frame Ethernet (18 byte se sono fortunato… perché se il frame è troppo piccolo, devo metterci padding e farlo diventare di almeno 64 bytes, o il primo apparato ligio al dovere lo considera un "runt" e lo scarta), dentro LLC (10 byte), incapsulato in ATM mediante AAL5. Un casino.

Credo che il grosso vantaggio di questa configurazione sia il poter disaccoppiare tutti gli elementi con estrema facilità da entrambi i lati della connessione: lato provider, perché i router che terminano la connessione ATM possono parlare PPP, volendo, oppure semplicemente far viaggiare i pacchetti PPP mediante PPPoE su una rete Ethernet "vera", e consegnarli ad un'altra macchina. (Entusiasmante: il DSLAM in centrale termina il link locale, un router ATM termina il circuito virtuale estraendo i frame Ethernet, ed una terza macchina infine termina il link PPP.) Lato utente, perché posso collegare il modem ADSL Ethernet al PC senza dover configurare il modem, e lasciare tutto lo sporco lavoro al PC.

Spero che almeno una parte di questo sproloquio sia comprensibile! :D

Ciao!
ep
Network Emperor
 
Posts: 260
Joined: Sat 06 Dec , 2008 11:36 am

Postby andrewp » Wed 04 Feb , 2009 8:56 am

ep wrote:Con PPPoE ho: PPP, dentro PPPoE (6 byte), dentro un frame Ethernet (18 byte se sono fortunato… perché se il frame è troppo piccolo, devo metterci padding e farlo diventare di almeno 64 bytes, o il primo apparato ligio al dovere lo considera un "runt" e lo scarta), dentro LLC (10 byte), incapsulato in ATM mediante AAL5. Un casino.


That´s why l´MTU é 1492 su PPPoE :) Buona spiegazione ep!
Manipolatore di bit.
User avatar
andrewp
Messianic Network master
 
Posts: 2199
Joined: Mon 13 Jun , 2005 7:32 pm
Location: Roma

Postby RJ45 » Wed 04 Feb , 2009 1:02 pm

ep wrote:Purtroppo mi rifaccio col testo :D

Stai scherzando??? La tua risposta l'ho stampata! :D
Complimentissimi! :wink:

Azzz... hai un altro caffè da avere...
User avatar
RJ45
Network Emperor
 
Posts: 456
Joined: Wed 07 Jun , 2006 6:40 am
Location: Udine (UD)

Postby ep » Wed 04 Feb , 2009 1:04 pm

RJ45 wrote:Azzz... hai un altro caffè da avere...

volentieri… dopo la pizza che a questo punto posso mettere io!:D
ep
Network Emperor
 
Posts: 260
Joined: Sat 06 Dec , 2008 11:36 am

Postby Raistlin » Wed 04 Feb , 2009 5:55 pm

ora sto 3d lo metto bene e me lo stampo ^^.
CCNA® Certified 640-802

CCDA® Certified 640-863

http://www.youtube.com/watch?v=aPtr43KHBGk
User avatar
Raistlin
Network Emperor
 
Posts: 294
Joined: Wed 02 Apr , 2008 7:23 pm
Location: Brno

Postby Wizard » Thu 05 Feb , 2009 4:44 pm

Impostato come importante!
Bravi networkers!
Il futuro è fatto di persone che hanno delle intuizioni e visioni .....sono quelle persone che fanno la differenza...... quelle dotate di un TERZO OCCHIO....
User avatar
Wizard
Intergalactic subspace network admin
 
Posts: 3441
Joined: Fri 03 Feb , 2006 10:04 am
Location: Emilia Romagna

Previous

Return to Networking

Who is online

Users browsing this forum: No registered users and 1 guest