Appunti di Reti

LCP

Vediamo quali sono i comandi che LCP usa:

Sono 11:

-> 4 di configurazione

-> 2 di terminazione

-> 2 rifiuto

-> 2 di eco

-> 1 di test

Configurazione LCP

Configure-request:

Sender -> Receiver

Propone opzioni per la configurazione della linea

Configure-ack:

Sender <- Receiver

Manca il controllo ACK nel contenitore PPP viene quindi rimpiazzata da

una reimplementazione nel sottoprotocollo

Configure-nak:

Sender <- Receiver

Il NAK per configure-request

Configure-reject:

Sender <- Receiver

Non c'è nulla da fare, (opzioni non negoziabili)

Per evitare sprechi è possibile rimuovere i campi Address e Control

Terminazione LCP

Terminate-request

Sender-Reciver

Terminate-ack

L'ACK di terminazione-request va bene, comunicazione chiusa

Rifiuto LCP

Code-reject

Receiver -> Sender

Non ho capito cosa intendevi, richiesta sconosciuta

Protocl-reject

Non capisco di che protocollo parli, (o c'è stato un errore sulla linea)

Echo LCP

Echo-request

Sender -> Receiver

Per favore, rimandami il frame indietro

Echo-reply

Sender <- Receiver

Serve a controllare/misurare la qualità della linea di comunicazione

Test LCP

Discard-request

Sender -> Receiver

Ignora il frame

Serve a fare un primo test preliminare della linea e trovare eventuali

loops.

PPP e le ADSL

Ricordiamo che ci sono vari parametri settabili in PPP

Alcuni ovvi come abbiamo visto, che tolgono byte inutili da ogni frame.

L'altro aspetto è il payload variabile

La taglia dei pacchetti

Significa quindi che dovremmo scegliere una taglia massima per i nostri

pacchetti

Quello che in gergo si chiama MTU - Maximum Transmission Unit

Ogni protocollo ha un MTU, fissato dallo standard ed eventualmente

riconfigurabile verso il basso

Lo Zen e l'arte dell'MTU ADSL

Intuizione generale sull'MTU

MTU grande -> pacchetti più grandi -> meno overhead -> più banda (va bene

se il canale ha pochi errori)

MTU piccolo -> pacchetti più piccoli -> più overhead -> meno banda (va

bene se il canale ha molti errori)

PPP si usa in due varianti primarie

Le varianti sono

PPPoE - PPP over Ethernet

PPPoA - PPP over ATM

"over" = incapsulato dentro flussi Ethernet ed ATM

PPP -> PPPoE/PPPoA -> Ethernet/ATM

Ma la situazione è più complessa

Flusso dati 1: dal computer al router

Flusso dati 2: dal router al modem

Flusso dati 3: dal modem al provider

Ma neanche così è finita

Flusso 3: dal modem "al provider"...?

Flusso 3: dal modem al primo DSLAM (Digital Subscriber Line Access

Multiplexer)

Flusso 4: dal primo DSLAM fino a qualche punto del provider

Flusso 5: ci si collega alla rete Internet

Nei flussi "lato provider"

ci possono essere due tecnologie, quella ATM e quella Ethernet

Molto spesso il primo tratto è formato da ATM e l'ultimo da Ethernet

ATM

Asynchronous Transfer Mode

Usa TDM, si dividono i dati in flusso di celle di ampiezza fissa.

Analogo di HDLC ma nato per telefonia/bancomat etc e non per internet,

gestisce controllo di flusso con sliding windows( "16 spicchi"), error

detection (CRC-8)

Indirizzamento ATM

Doppia gerarchia, cammmini ("path") e canali ("channel")

Che sono le due etichette VPI e VCI che vediamo nelle configurazioni ADSL

VPI - Virtual Path Identifer

VCI - Virtual Channel Identifer

-> terminologia: Virtual Channel - ATM è connection-oriented

Anche ATM, come PPP, viene concretamente embeddato dentro altri

pacchetti.

Giacchè appunto si tratta di canali in multiplex e quindi c'è interazione

con altri flussi dati

LLC o VC-MUX

LLC - Logical Link Control: Protocolli multipli per canale

VC-MUX - Virtual Connection Multiplexing: Un solo protocollo per canale

Flusso dati 1: dal computer al router (Es. PPPoEoE PPP -> PPPoE ->

Ethernet)

Flusso dati 2: dal router al modem (Es. PPPoEoA Ethernet -> ATM)

Flusso dati 3: dal modem al provider (Es. PPPoA ATM -> LLC/VC-MUX)

Flusso dati 4: dal provider ad un punto interno

Flusso dati 5: da un punto interno ad una rete Ethernet esterna

Se di mezzo c'è il wireless la situazione si fa ancora più complicata

In pratica l'MTU interagisce con tutti gli altri protocolli in tutti i

flussi in atto

Quindi occorre stare bene attenti a sapere esattamente cosa si modifica.

caso ideale: linea senza errori

-> MTU grande

Ma, diminuendo l'MTU sotto certe soglie critiche, la banda migliora.

Deriva tutto dall'interazione con gli altri flussi.

C'è poi da considerare tutta l'interazione con gli strati superiori

In ogni caso ci torneremo quando avremo altre nozioni che ora ci mancano

Alla visione più vicina a PPP, e quella più comune: PPPoE

PPPoE: ciclo iniziale

La connessione ADSL inizia così:

Il nostro computer/modem invia un frame PPPoE (Active Discovery

Initiation) col suo indirizzo fisico (MAC)

Ogni servizio ADSL disponibile risponde con un PADO in cui dà il proprio

indirizzo e si "offre" per la connessione.

Il nostro computer risponde con un PADR (PPPoE Active Discovery Request)

in cui segnala il servizio ADSL che ha scelto.

Il servizio fa l'ACK usando un frame PADS

Competizione e "lock-in"

I protocolli multiaccesso

Finora abbiamo visto il caso point-to-point, in cui c'è uno che parla e

uno che ascolta, ed un canale tutto pe loro.

Ovviamente, ci sono molti altri contesti in cui queste assunzioni non

sono valide, e ci sono molte entità diverse che vogliono usare lo stesso

canale per parlarsi

I contention system

Sono quei sistemi di comunicazione multipla in cui c'è un unico canale

condiviso da molti, e si possono creare contenziosi.

Assunzioni

Station Model: sono le entità che trasmettono. Dopo che hanno iniziato la

trasmissione di un frame, non fanno altro finchè non è stato trasmesso.

Single Channel: c'è un canale singolo disponibile per tutti

Collision: se due frame si sovrappongono, c'è una collisione e sono

inutilizzabili

Sul tempo

O continuo (non c'è un orologio centrale)

oppure slotted (a intervalli)

Su carrier (il mezzo di trasporto)

Carrier Sense (una stazione può vedere se il canale è in uso prima di

tentare una trasmissione)

No Carrier Sense

Sfruttamento del caso

Probabilità

La distribuzione di Poisson

Pr[k] = ( G^k * e^-G ) / k!

Protocollo Aloha

Dobbiamo vedere qual è la probabilità che ci sia una sola trasmissione

(pr[1)] in un tempo doppio

-> la media in quel periodo è 2G

-> la probabilità ( Pr[k] = (G^k * e^-G ) / k! è 2G*e-2G

La probabilità che il canale sia usato correttamente in ogni singolo slot

di tempo è la meta G * e^-2G

E quindi, a quanto mi conviene settare la velocità di tentativi di

accesso al canale (G) per massimizzare le prestazioni?

Il massimo facile da vedere si ottiene con G = 0.5

-> 1/2e frame/sec -> circa 0.184

18.4% di banda... è poco

Però il 18.4 non dipende da quante entità possono trasmettere, che

possono essere tantissimi

Altra variabile possibile: lunghezza del frame random

Ma conviene fissare frame di lunghezza fissa

Motivo intuitivo: perchè avere frame diversi creerebbe rotture di

simmetria

Slotted Aloha

Due anni dopo Aloha, Roberts trova un modo per migliorarla

Assume che il tempo sia "slotted" tramite una stazione principale che

manda un segnale di sincronizzazione

In tal modo, una stazione deve attendere prima di trasmettere il

pacchetto, non c'è trasmissione istantanea.

Come cambiano le prestazioni?

Il periodo "critico" che può generare conflitti stavolta è dimezzato.

Ora la probabilità di successo è Pr[1] = G * e^-G

Il numero massimo di frame al secondo si ha con G=1 e diventa: 1/e

Cioè circa 36.8%, il doppio di Aloha

Abbiamo raddoppiato la velocità alterando le regole del gioco

Si può fare ancora meglio?

Carrier Sense

1 - persistent CSMA

CSMA - Carrier Sense Multiple Access protocol

-> prima di trasmettere, controlla che non ci sia già una

trasmissione (carrier sense)

Se c'è una trasmissione, controlla il canale, e non appena si libera,

trasmette

Può lo stesso succedere che ci siano collisioni (Murphy...) in questo

caso?

Si riaspetta un certo tempo casuale e poi si riprova

Performance: aumenta a più del 50%

Difetto di 1-CSMA

Se molte stazioni stanno aspettando durante una trasmissione, alla fine

della trasmissione tutte cercano di trasmettere contemporaneamente

provocando una collisione

Se fossero un po' meno "egoiste", il mondo funzionerebbe meglio

p-persistent CSMA

Si ottiene rilassando l'ipotesi che uno debba sempre trasmettere (p=1)

quando trova la linea libera, ma invece, trasmette con probabilità p (non

deve trasmettere a tutti i costi)

Performance: Migliora, con molte stazioni al diminuire di p

Al limite si può arrivare al 100% dell'efficienza

Nonpersitent CSMA

Usa un metodo alternativo: invece di tenere d'occhio il canale per

ricominciare la trasmissione non appena è libero, se trova il canale

occupato aspetta un periodo di tempo casuale e poi riprova.

Performance: la curva di performance si comporta differentemente da p-

CSMA e poò raggiungere performance vicine al 90&

CSMA/CD - CSMA Collision Detection

Avendo il carrier Sense, possiamo anche essere più furbi quando

trasmettiamo: non controlliamo solo quando vogliamo spedir il segnale, ma

anche durane tutta la trasmissione, e se ci sono accorgiamo di una

collisione, ritrasmettiamo dopo sprecando meno banda

Quindi, rilassiamo l'assunzione station model, possiamo fare anche altro

mentre trasmettiamo

In CSMA/CD possiamo separare tre possibili stati della rete trasmissione,

contention e idle:

E' nella parte contention, cioè decidere quanto tempo allocare a quella

zona in cui si decidono le sorti della trasmissione

Il tempo da allocare sarà due volte il tempo di trasmissione tra le due

stazioni più distanti (tempo di roundtrip)

Tipicamente il periodo di contention ha durata il tempo massimo di

roundtrip, e si usano più tecniche di protocollo multiaccesso per vincere

il round ed essere sicuri che il canale è nostro.

Protocolli collision-free

Anche detti CSMA/CA (Collision avoidance)

In questa classe di protocolli si fa un uso intelligente dei contetion