Introduzione alle Reti ATM: Struttura, Funzionamento e Configurazione, Dispense di Reti Di Telecomunicazioni

Scarica Introduzione alle Reti ATM: Struttura, Funzionamento e Configurazione e più Dispense in PDF di Reti Di Telecomunicazioni solo su Docsity! 1.CONNECTION-ORIENTED NETWORKS (SONET/SDH, ATM, MPLS and OPTICAL NETWORKS) 1.2.1 CONNESSIONE ATM La figura 1.3 mostra il setup di una connessione di tipo ATM, che a differenza della rete IP, è connection oriented ovvero, prima dello scambio dei dati, c’è una fase per stabilire una connessione. La cella ATM ha una dimensione fissa di 53 byte, di cui 5 sono usati per l’header e gli altri 48 per il payload. L’utente A manda un messaggio di SETUP allo switch ATM1, che è collegato direttamente, e questo calcola un percorso per raggiungere l’utente destinatario e poi verifica che il percorso ha abbastanza capacità per accettare questa nuova connessione. Il messaggio di SETUP passa attraverso i vari switch per poi raggiungere l’utente destinatario B. La connessione è stabilita quando l’utente ritorna il messaggio CONNECT che si propaga lungo la via di ritorno verso la sorgente A. La decisione di accettare o meno una nuova connessione è legata al fatto che il traffico previsto può soddisfare il QoS richiesto, andando (o meno) a influenzare il QoS delle connessioni già esistenti. Quando la connessione è accettata, lo switch assegna la banda sul link di uscita per la connessione: rifiuta una nuova connessione quando si andrebbe fuori banda o viene superata una certa percentuale di utilizzazione della banda. La trasmissione inizia solo se l’utente A riceve il messaggio CONNECT. L’header della cella ATM contiene 2 campi, il VPI (virtual path identifier) e il VCI (virtual connection identifier), usati per identificare una connessione. L’ATM mantiene, come nel caso del router IP, una tabella che specifica il prossimo hop per ogni valore VPI/VCI. La tabella ATM è più piccola della tabella di routing IP perché contiene soltanto le connessioni ATM esistenti piuttosto che un intero set di indirizzi IP. Svantaggio: trasmissione dei pacchetti più complessa Vantaggio: è garantita una certa QoS che non è possibile nelle reti IP 1.2.2 CONNESSIONE MPLS MPLS introduce una struttura connection-oriented in una rete IP (che è connctionless). MPLS-ready non si basa sull’indirizzo di destinazione dell’header per inviare i pacchetti ma li inoltra tenendo conto di un’etichetta molto simile, funzionalmente parlando, alla coppia VPI/VCI della cella ATM. L’header MPLS e’ in mezzo tra IP header e LLC header. Il router IP MPLS-ready, conosciuto come LSR (label switched router), mantiene una tabella di etichette. Quando il pacchetto IP arriva all’ LSR , l’etichetta portata nell’ header MPLS e’ rimandata alla tabella delle etichette del prossimo hop trovato. Il pacchetto IP e’ poi inoltrato verso la porta di uscita di destinazione dell’LSR che e’ connessa al successivo hop LSR. La procedura è simile a quella relativa all’ATM. Allo scopo di trasmettere su una rete IP MPLS-enabled, un utente deve per prima richiedere la connessione, e questo avviene usando due protocolli di segnalazione, il CR-LDP o l’RSVP-TE. Nell’MPLS la connessione è chiamata LPS (label switched path). Come nel caso dell’ATM, un LSR è a conoscenza di tutte le connessioni che passano attraverso la propria struttura di commutazione. 1.2.3 CONNESSIONE TELEFONICA Quella telefonica è una rete a commutazione di circuito (connessione=circuito). Uno switch telefonico, conosciuto come central office, serve migliaia di utenti. Questi swith sono connessi tra loro tramite dei link TDM, come link SONET/SDH e link PDH. Un frame, composto da 24 time slot (8 bit per cadauno), si ripete ogni 128 micro secondi. Vedi figura 1.4 e i passi per la connessione. 1.2.4 CONNESSIONE DI RETE OTTICA A COMMUTAZIONE DI LUNGHEZZA D’ONDA La rete ottica è basata sulla tecnologia WDM che convoglia più lunghezze d’onda su una stessa fibra ottica. Un dispositivo molto importante di questo tipo di reti è l’OXC(optical cross connect) che permette la commutazione di segnali ottici ad alta velocità nella fibra, senza dover convertire il segnale da ottico in elettrico, e quindi evitando una diminuzione del rate di trasmissione. 2.3 STRUTTURA DEL FRAME SONET STS-1 Il frame SONET STS-1 (vedi fig 2.3 di pag 24) è composto da 810 bytes e viene trasmesso 8000 volte al secondo (ogni 125 µsec) e questo corrisponde a un rate di 51,84 Mbps. Esso è graficamente rappresentato con una matrice 9x90, in cui ogni cella corrisponde a un byte, e si può suddividere in sezione di overhead e sezione di payload. La sezione di overhead, detta ‘transport overhaead’ (TOH), occupa le prime 3 colonne, mentre le restanti 87 contengono il ‘ synchronous payload envelop’ (SPE). L’SPE trasporta un payload di dati utente e qualche overhead addizionale, detto ‘payload overhead’ (POH). L’utente non è sempre allineato con i frame SONET trasmessi, e quindi l’SPE potrebbe diventare disponibile per la trasmissione mentre viene trasmesso il frame SONET. Questo problema può essere alleviato mettendo in buffer l’SPE fino all’inizio del prossimo frame: se la velocità del frame cresce, cresce anche il requirement del buffer. Una soluzione alternativa al buffering dell’SPE è quella di trasmetterlo nel momento in cui diventa disponibile: questo significa che l’SPE può iniziare in ogni punto dentro il payload SONET (vedi figura 2.4 di pag 25). Il ‘transport overhead’ (TOH) è composto da ‘section overhead’ (SOH) e ‘line overhead’ (LOH). C’è anche un ‘path overhead’ incastrato nell’SPE. 2.3.1 SECTION, LINE E PATH OVERHEAD La rete SONET di fig 2.5 è composta dai dispositivi A1 fino ad A12, A, B e i dispositivi in ricezione B1 fino a B12. ‘A‘ multipla i dodici flussi STS-1 in arrivo in un flusso di tipo STS-12, trasmettendolo tramite due rigeneratori a ‘B’; ‘B’ a sua volta demultipla il flusso ricevuto nei singoli flussi STS-1 da consegnare ai vari Bi. La qualità del segnale ottico si deteriora man mano che si propaga lungo la fibra, per questo motivo è necessaria la presenza di dispositivi di rigenerazione: tale processo viene fatto nel dominio ottico, quindi il segnale viene convertito da ottico a elettrico, processato, riconvertito in ottico e poi inviato in fibra. Gli svantaggi, in termini di perdite e ritardi, legati a questa procedura portano a considerare, nel futuro, un meccanismo di rigenerazione di tipo ottico e non più elettrico. In SONET, un singolo link con un dispositivo SONET o un rigeneratore è conosciuto come ‘sezione’ Invece, un link con 2 dispositivi SONET è indicato col termine ‘linea’. SONET (vedi fig 2.6) è organizzato come una pila composta da 4 livelli, tutti incastrati nello strato fisico: il più basso, ‘photoniclayer’, si occupa della trasmissione ottica dei frame STS; ‘section layer’ gestisce il trasporto dei suddetti frame sul ‘photonic layer’; ‘line layer’ tratta il trasporto degli SPE sulle linea e l’ultimo, ‘path layer’, processa la trasmissione end-to-end tra i punti in cui l’SPE inizia e finisce. In SONET, il dispositivo che può processare la section overhead prende il nome di ‘section terminating equipment’ (STE) e analogamente quella relativa alla linea (line) è detta LTE, quella relativa al path PTE. 2.3.2 SECTION, LINE E PATH OVERHEAD DELL’STS-1 La ‘section overhead’ SOH occupa le prime tre righe delle prime tre colonne mentre ‘line overhead’ le ultime sei righe sempre delle prime tre colonne. Definizione dei byte della ‘section overhead’ SOH:  A1 e A2: ‘framing bytes’ usati per l’allineamento del frame  J0: ‘section trace byte’ usato per risalire dal frame STS-1 al dispositivo che lo ha originato  B1: ‘bit interleaved parity byte’ usato per realizzare un controllo di parità sul frame STS-1 precedente dopo che il frame è stato criptato  E1: fornisce un canale a 64 Kbps che può essere usato per comunicazioni vocali dagli ingegneri del campo  F1: riservato all’operatore di rete  D1, D2 e D3: usati per le operazione di gestione della rete Definizione dei byte della ‘line overhead’ LOH:  H1 e H2: ‘pointer bytes’ contengono un puntatore che punta all’inizio dell’SPE che si trova all’interno del frame STS-1  H3: ‘pointer action byte’ usato per compensare le piccole differenze di tempo che potrebbero esistere tra i dispositivi SONET  B2: analogo al B1, trasporta il BIP(bit interleaved parity) eseguito su LOH e payload section  K1 e K2: usati nella commutazione di protezione automatica  D4 a D12: formano un canale di comunicazione dati di 576 Kbps che è usato per la gestione delle rete  Z1 e Z2: parzialmente definiti  E2: simile a E1 Definizione dei byte della ‘path overhead’ POH (vedi fig 2.8):  J1: simile al J0 dell’SOH  B3: simile al B1 dell’SOH e al B2 dell’LOH  C2: ‘path signal label’ indica il tipo di informazione trasportata nell’SPE  G1: ‘path status byte’ trasporta lo stato e la diagnostica del segnale  F2: riservato agli operatori di rete  H4: ‘multi-frame indicator’ usato per identificare i payload trasportati dentro lo stesso frame  Z3 e Z4: riservati per un utilizzo futuro  Z5: usato per il monitoraggio del tandem, che è un commutatore telefonico che è usato nella rete telefonica dorsale 2.3.3 PAYLOAD DELL’STS-1 Il payload può essere definito per trasportare degli strati multipli di flussi di dati: un tale substrato è conosciuto come ‘virtual tributary’. L’utente A, che è connesso a TM1, che a sua volta è connesso ad ADM1, stabilisce una connessione all’utente B che è connesso ad ADM3 tramite TM2. Si assume che A trasmette un segnale DS1 e che il segnale di uscita di TM1 è un segnale OC-3; ADM1 aggiunge il segnale OC-3 ricevuto da TM1 nel payload di STS-12 e trasmette il tutto al successivo ADM; il segnale OC-12 viene trasmesso ad ADM2, dove viene convertito nel dominio elettrico; ADM2 aggiunge e toglie vari segnali e trasmette i frame STS-12 risultanti ad ADM3; a questo punto il segnale DS1 appartente ad A viene tolto dal payload e trasmesso con gli altri segnali al TM2; quest’ultimo demultipla ciò che ha ricevuto e consegna il segnale DS1 di A a B. Nella fig 2.14 si può apprezzare un’interconnessione di 2 ring SONET, che vanno a formare il cosiddetto ‘digital cross connect systems’ (DCS): il nodo DCS riceve dei frame STS-N dal anello 1 e per ogni frame ‘droppa’ i tributari virtuali predefiniti e aggiunge quelli nuovi, ovvero quelli che vengono dal dispositivo SONET locale e quelli che vengono dall’anello 2; i frame STS-N risultanti sono poi trasmessi al dispositivo ADM adiacente sull’anello 1; i tributari virtuali ‘droppati’ dai frame provenienti dall’anello 1 o vengono consegnati al dispositivo SONET locale o vengono commutati all’anello 2. Ogni nodo DCS è provvisto di un interruttore in modo che possa commutare i tributari virtuali da un’interfaccia di input verso un’interfaccia di output. Gli anelli SONET/SDH sono tipicamente impiegati nelle aree metropolitane, o al confine dell’anello o al centro. 2.6 ANELLI SONET/SDH ‘SELF-HEALING’ Una delle principali cause del guasto di un anello è il danneggiamento del collegamento in fibra. E’ stato stimato che, per quel che riguarda gli anelli SONET/SDH, il tempo di inattività medio si attesta attorno ai 6 minuti all’anno. Allo scopo di ristabilire il servizio quanto prima e di non abbassare significativamente le prestazioni della rete, si fa uso di un protocollo di commutazione a protezione automatica (APS), secondo cui il tempo di ripristino del servizio deve essere inferiore ai 50 msec. La protezione del link può essere fatta in maniera dedicata 1 a 1 o in maniera condivisa 1 a 1 e 1 a N. Nello schema 1 a 1 (vedi fig 2.15) 2 dispositivi sono connessi con 2 differenti fibre, una progettata come ‘working fiber’ e l’altra come ‘protection fiber’: se un collegamento cade, la destinazione continua a ricevere il segnale dall’altro. Le due fibre, per aumentare il livello di protezione, devono avere dei percorsi fisici differenti e quindi devono usare delle tubature separate. Gli anelli ‘self-healing’ si distinguono grazie a 3 particolari caratteristiche:  Numero di fibre : può essere formato da 2 o 4 fibre; nell’esempio di fig 2.16 le fibre 1, 2, 3 e 4 sono usate dal ‘working ring’ e 5, 6, 7 e 8 sono usate allo scopo di formare un anello di protezione (la trasmissione sul ‘working’ avviene in senso orario)  Direzione di trasmissione : può essere unidirezionale o bidirezionale, ovvero una trasmissione che può avvenire o in una o in entrambe le direzioni  Commutazione di linea o di percorso : ricordando che la ‘linea’ è un link tra 2 dispositivi SONET/SDH e il ‘path’ è un collegamento end-to-end tra il punto in cui ha origine un SPE e quello in cui termina, la protezione può avvenire al livello di linea o a livello di percorso. In base a queste 3 proprietà si hanno le seguenti architetture a 2 e a 4 fibre: ‘unidirectional line switched ring’ (ULSR), ‘bidirectional’ (BLSR), ‘unidirectional path’ (UPSR) e ‘bidirectional’ (BPSR). 2.6.1 2F-UPSR Architettura che consiste in 2 fibre con trasmissione unidirezionale e commutazione di percorso (vedi fig 2.17): 1-2-3-4 è l’anello ‘working’, 5-6-7-9 l’anello ‘protection’. Un segnale trasmesso da A viene ‘splittato’ in 2: una copia viene trasmessa sulle fibre ‘working’ e l’altra su quelle ‘ protection’ (8-7-6); il dispositivo B riceverà 2 segnali identici e selezionerà quello con la migliore qualità. 2.6.2 2F-BLSR Architettura che consiste in 2 fibre con trasmissione bidirezionale e commutazione di linea (vedi fig 2.18): 1-2-3-4-5-6 formano un anello su cui si ha una trasmissione in senso orario, 7-8…-12 uno su cui si ha una trasmissione in senso antiorario. A differenza del precedente 2F-BLSR, entrambi gli anelli, dividendo la capacità di ogni fibra in 2 parti, trasportano traffico ‘working’ e ‘protection’. Dato che il link è bidirezionale, la scelta di trasmettere sull’anello 1 o 2 dipende dal percorso più corto tra sorgente e destinatario. Assumendo che A trasmetta a B e supponendo che la fibra 2 sia guasta, tutto il traffico su di essa verrà automaticamente smistato alla parte di protezione dell’anello 2 e quindi il traffico arriverà a B tramite le fibre 7-12-11-10-9. Nel caso di un guasto contemporaneo delle fibre 2 e 8, il traffico trasmesso sulla fibra 2 da ADM3 sarà smistato alla parte di protezione dell’anello 2, e il traffico trasmesso da ADM3 sulla fibra 8 ADM3 sarà smistato alla parte di protezione dell’anello 1. 2.6.3 4F-BLSR Architettura che consiste in 4 fibre con trasmissione bidirezionale e commutazione di linea (vedi fig 2.19): ci sono 2 anelli ‘working’ e 2 ‘protection’; ogni anello ‘working’ è sostenuto da uno ‘protection’ nella stessa direzione. Gli anelli ‘protection’ possono essere passivi o trasportare traffico a bassa priorità. Dato che il link è bidirezionale, la scelta di trasmettere su un anello o un altro dipende dal percorso più corto tra sorgente e destinatario. Se una fibra ‘working’ è guasta, il suo traffico viene trasferito sul relativo anello ‘protection’: questa tecnica è conosciuta come ‘span switching’ (vedi fig 2.20 di pag 39). Se le fibre ‘working’ e ‘protection’ non sono sufficientemente lontane e vengono danneggiate allo stesso tempo, il traffico sarà smistato alle fibre ‘protection’: questa tecnica è conosciuta come ‘ring switching’ (vedi fig 2.21). 2.7.2 FUNZIONI DEL GFP CLIENT-INDEPENDENT GFP supporta le seguenti procedure di base, che sono comuni a tutti i payload:  ‘Frame delineation’: semplice procedura che assicura che l’inizio di un frame GFP sia correttamente identificata  ‘Frame multiplexing’: usata per multiplare i frame ‘client data’ e i frame ‘client management’ su base frame dopo frame. Quando non c’è nessun frame disponibile, GFP inserisce dei frame vuoti allo scopo di mantenere un flusso di bit continuo  ‘Header and payload scrambling’  ‘Client management’ 2.7.3 FUNZIONI DEL GFP CLIENT-DEPENDENT I dati client possono essere trasportati in frame GFP usando una delle seguenti modalità d’adattamento: ‘frame-mapped GFP’ che è applicabile alla maggior parte dei tipi di pacchetti dati e in cui ogni client-frame ricevuto viene interamente in un singolo payload GFP, e ‘trasparent-mapped GFP’ che è applicabile nei segnali codificati 8B/10B e viene utilizzato in un bit-rate a trasporto continuo. 2.8 DATA OVER SONET (DoS) L’architettura DoS provvede a un meccanismo per il trasporto efficiente dei servizi dati integrati. Le caratteristiche principali sono:  provvede ad un assegnamento di banda flessibile con una granularità di 50 Mbps  non sono richieste delle modifiche ai nodi intermedi  usando GFP, provvede ad un efficiente schema di framing con un piccolo overhead  può contenere pacchetti IP, frame Ethernet e dati a bit rate costante e informazioni di controllo trasportati su fibra ottica  coesistenza nello stesso frame SONET/SDH dei tradizionali servizi voce e dei nuovi servizi dati  gestione della rete attraverso l’esistente SONET/SDH gestione della qualità della rete DoS utilizza 3 tecnologie: GFP, ‘virtual concatenation’ e ‘link capacity adjustment scheme’ (LCAS) 2.8.1 VIRTUAL CONCATENATION Si tratta di una procedura con cui si mappa il flusso di traffico in arrivo in un certo numero di payload di substrato individuale: in questo modo il payload ha una banda minore della banda di un link SONET/SDH. La ‘virtual concatenation’ deve essere implementata solo sul nodo originario, in cui il traffico in arrivo viene demultiplato in 7 payload di substrato, e sul nodo terminale, dove i payload vengono multiplati per andare a formare il flusso originale. Come già visto nel paragrafo 2.3.3, mentre si trasportano dei pacchetti IP su SONET/SDH, l’intero payload SONET/SDH deve essere dedicato ai pacchetti IP. A differenza del Pos, la ‘virtual concatenation’ permette la divisione della banda di un frame SONET/SDH in più payload di substrato, ognuna delle quali può trasportare differenti tipi di traffico(vedi fig 2.26). 2.8.2 LINK CAPACITY ADJUSTMENT SCHEME (LCAS) Il numero di payload di substrato dedicati a un’applicazione sono tipicamente determinati in anticipo. Ma, dato che il rate di trasmissione di un’applicazione cambia nel corso del tempo, è utile che il numero di payload di sybstrato dedicati a un’applicazione vari dinamicamente: questo è possibile usando LCAS, che al contempo assicura che il processo di aggiustamento non comporti la perdita di alcun dato. 3. RETE ATM 3.1 INTRODUZIONE La rete ATM e’ stata progettata al fine di trasmettere voce , dati e video sulla stessa rete. Questi differenti tipi di traffico hanno disparati livelli di tolleranza per quanto riguarda la perdita di pacchetti e il ritardo end – to- end come mostrato in tabella 3.1. L’architettura ATM e’ basata nella commutazione di pacchetto ed e’ una connessione orientata. La connessione e’ stabilita durante la fase di impostazione della chiamata e dopo quando il trasferimento dei dati e’ completato la connessione andrà giù. Non c’e’ un controllo di errore ne’ un controllo di flusso tra due nodi adiacenti in ATM. Il controllo di errore non e’ necessario, poiché i collegamenti nella rete hanno un basso bit-error rate. Comunque l’header e’ protetto al fine di evitare l’inoltro di un pacchetto errato al destinatario. Il recupero di un pacchetto perso o di un pacchetto che e’ consegnato alla destinazione con payload errati e’ lasciato alla strato di protocolla più alto. La mancanza del controllo di flusso richiede uno schema del controllo di congestione che permette ad un operatore di rete ATM di effettuare tanto più traffico possibile senza perdere plurime celle. 3.2 LA STRUTTURA DELL’HEADER DELLA CELLA ATM Il pacchetto ATM e’ chiamato cella ed ha una sezione fissa di 53 byte ( 48 di payload e 5 di header ). Due formati differenti per l’header della cella vengono adottati, uno per UNI ( user network interface) e una leggermente diversa per la NNI ( network-network interface). La UNI e’ riferita con l’interfaccia tra un dispositivo end ATM e il switch ATM a cui e’ collegato. La NNI e’ usato tra due switches ATM appartenenti alla stessa rete o due reti diverse. Il formato dell’header della cella per queste due interfacce e’ mostrato in figura 3.2 Come si può vedere, questi due formati differiscono solo nel primo campo. Adesso definiamo gli altri campi dell’header. Il generic flow control (GFC) permette la multiplazione di trasmissioni da diversi terminali verso l’interfaccia dell’utente. Esso e’ usato anche per il controllo di flusso del traffico dal dispositivo end alla rete. Una connessione ATM e’ identificata dalla combinazione del virtual path identifier (VPI) e virtual channel identifier (VCI). Una tale connessione e’ identificata come una connessione di canale virtuale VCC. Il campo VPI/VCI e’ di 28 bits nell’interfaccia NNI e 24 bits nell’interfaccia UNI. Il campo VPI e’ 8 bits nell’interfaccia UNI e 12 nell’interfaccia NNI. Quindi un interfaccia UNI puo’ avere al massimo di 256 percorsi virtuali ,mentre l’interfaccia NNI al massimo 4096 percorsi virtuali. 3.3 PILA PROTOCOLLO ATM La pila ATM e’ mostrata in figura 3.5. E’ importante notare che lo strato ATM e lo strato di adattamento non corrispondono ad alcuni strati dello specifico modello OSI. Nella fattispecie e’ errato riferire lo strato ATM con lo strato data link. 3.4 STRATO FISICO Lo strato fisico trasporta celle ATM tra due strati adiacenti ATM. Lo strato ATM e’ indipendente dallo strato fisico, esso opera tra una grande varietà di strati fisici. Lo strato fisico e’ diviso in transmission convergence TC e physical medium dependent PDM. Nel substrato PDM , il trasmettitore e’ interessato alla trasmissione e trasporto di un flusso di bit , che li manda al substrato TC. Nel lato di ricezione , si recuperano il flusso di bit e vengono passati allostrato TC. IL tc invece interagisce tra lo strato ATM e il PDM . Nel lato di trasmissione riceve le celle ATM dallo strato ATM e crea un flusso di bit che passa al PDM. Nel lato di ricezione costruisce le celle ATM dal flusso di bit ricevuto dal PDM e li passa allo strato ATM. 3.4.1 SUBSTRATO TC In seguito verranno menzionate le principali funzioni di gestione di questo substrato. GENERAZIONE E VERIFICA CELLA HEC Lo strato ATM passa le celle allo strato fisico per la trasmissione sul link. Ogni cella Atm e’ completa eccetto per i byte HEC. Questo byte e’ computato e inserito all’interno del campo HEC nel substrato TC. Nel lato ricezione del link, lo /stato macchina HEC e’ implementato nel substrato TC. DISACCOPPIAMENTO DEL RATE DELLA CELLA IL PDM aspetta di ricevere un flusso continuo di bit. Durante il tempo che le celle ATM non sono passate giù dallo strato ATM, il TC inserisce celle inattive tra le celle ricevute dallo strato ATM per mantenere un flusso di bit continuo attesi da PDM. Codeste celle inattive sono identificate dai parametri VPI=VCI=PTI=CLP=0 DELINEAZIONE DELLA CELLA La delineazione della cella e’ usato nell’estrazioni di celle dal flusso di bit ricevuti dal substrato PDM. Quando si ottiene una corrispondenza, allora sappiamo che dobbiamo individuare correttamente, nel flusso di bit l'inizio di una cella. Questa semplice idea e’ usata nello stato della macchina per delineare le celle. Lo stato della macchina consiste del hut state , presync state e il sync state. Lo stato della macchina e’ nello stato hunt quando il link e’ inizializzato, o dopo che e’ stata rilevata una fallita ricezione. Quando esiste una corrispondenza si passa allo stato presync state. In questo stato , si controlla che la FCS di x cella sia 0. Se la FCS di una di queste celle non e’ settato a 0 lo stato della macchina ritorna allo stato precedente,ossia, lo stato hunt. Altrimenti, la sincronizzazione con il flusso di bit e’ raggiunta, e lo stato della macchina passa allo stato sync . Quando siamo nello stato sync, lo stato della macchina HEC e’ usato a rilevare errori nell’header dell’inizio cella . Rammentiamo che quando lo stato della macchina figura in correction mode , la cella e’ scartata se abbiamo più di un bit errato, mentre se abbiamo un solo bit errato viene corretto e successivamente la cella passerà allo strato ATM. Mentre in detection mode , la cella viene scartata comunque sia per un bit e sia per multi bit errati. TRASMISSIONE E RICOVERO DEL FRAME GENERATO Nel sistema di trasmissione, il TC genera frames nel lato mittente inserendo informazioni from-related e cella ATM nella struttura frame definita. Nel lato di ricezione ,recupera il frames e la cella ATM dal flusso di bit. 3.4.2 PDM (THE FHYSICAL MEDIUM-DEPENDENT SUBLAYER) Le principali funzioni di questo stato sono: FUNZIONI DI SINCRONIZZAZIONE Questa funzione viene usata per la sincronizzazione della tx e rx del substrato PDM. CODIFICA E DECODIFICA Il PMD può operare su una base bit-by-bit o con un gruppo di bit. Nello schema di codifica 4B/5B, ogni gruppo di 4 bit e’ codificato da un codice di 5 bit. Il gruppo di bit codificato e’ conosciuto come block coding. Quest’ultimo richiede piu’ banda di quella riservata efficacemente. 3.5 LO STRATO ATM Lo strato ATM si preoccupa dal trasferimento di informazioni end-to-end. Le principali funzioni sono: CONNESSIONE ORIENTATA DI COMMUTAZIONE DI PACCHETTO Lo strato ATM e’ una connessione orientata di commutazione di pacchetto. A differenza dello rete IP , un dispositivo ATM non può trasmettere celle alla destinazione ATM su una rete ATM senza aver stabilito una connessione di canale virtuale e la fase iniziale di “established”. Le celle sono consegnate alla destinazione nell’ordine in cui sono state tx. Come asserito in sezione 3.2 la connessione e’ identificata da una serie di etichette VPI/VCI e le connessioni possono essere di tipo PVC/SVC. DIMENSIONE FISSA DELLA CELLA Come evidenziato nella sezione 3.2 nello strato ATM le celle hanno dimensione fissa di 52 bytes. COMMUTAZIONE DI CELLA La commutazione di celle in una rete ATM e’ fatto dallo strato ATM. Un esempio della pila ATM e’ mostrato in figura 3.7. NO ERROR E CONTROLLO DI FLUSSO Nel modello OSI , lo strato data link prevede errori e il controllo di flusso in ogni “hop” usando il meccanismo ARQ. Nella rete ATM, non c’e’ nessun controllo di errore e di flusso tra due commutatori ATM adiacenti che sono connessi con un link punto punto. Se la cella arriva ad un commutatore ATM quando esso e’ in congestione , la cella e’ persa, o probabilmente viene consegnata alla destinazione con un payload errato. Le probabilità che i bit errati vengono consegnati e’ comunque molto bassa. Due parametri fondamentali sono il rate di celle perse e il QoS. Quando TCP/IP gira su ATM, la perdita o la corruzione del payload di una singola cella consiste nella ritrasmissione di un intero TCP PDU. Assumiamo che vogliamo mandare un singolo TCP PDU su una rete ATM. Questo PDU verrà incapsulato su IP e verrà passato su la rete ATM. Come si vedrà nella sezione 3.7, lo strato adaptation ATM smembrerà il PDU IP in piccoli segmenti, ogni segmento verrà posizionato nel payload di una cella ATM. Noi assumiamo che il PDU IP sarà portato in n celle, quando queste arrivano alla destinazione , il payload verrà estratto e l’originale PDU IP sara’ ricostruito, tra cui il rispettivo TCP PDU verrà estratto. Se una di queste n celle e’ persa o il payload e’ corrotto , verrà ritrasmesso l’intero PDU. Poiché questo non dovrebbe succedere molto spesso, non dovrebbe influire sulle prestazioni della rete. INDIRIZZAMENTO Il commutatore ATM ha un unico indirizzo ATM. Gli indirizzi ATM sono differenti di quelli IP. Pertanto, durante l'esecuzione di IP su ATM, l’indirizzo IP deve essere tradotto in indirizzo ATM, e viceversa. QoS In ogni connessione ATM e’ associata una categoria QoS. Ci sono 6 categorie differenti: bit rate costante (CBR), real-time variable bit rate (RT-VBR ) , non real-time variable bit rate (NRT-VBR) , available bit rate (ABR), unspecified bit rate (UBR) , guaranteed frame rate (GFR). CONTROLLO DI CONGESTIONE Nella rete ATM,il controllo di congestione permette all’operatore di rete di portare quanto più traffico possibile, senza influire sul QoS richiesto dall'utente. Il controllo di flusso può essere preventive o reactive. Nel preventive congestion control , la congestione nella rete può essere impedito dall’uso di un algoritmo call admission control (CAC). Il CAC decide di accettare o meno una nuova connessione. Nel reactive congestion control, la congestione della rete e’ controllata regolando la quantità di dispositivi finali trasmettendo messaggi di feedback. THE WEIGHTED ROUND-ROBIN SCHEDULER Ogni buffer di uscita è organizzato in un qualsiasi numero di code. Per esempio, ci potrebbe essere una coda per ogni connessione che passa attraverso una particolare porta di uscita Oppure ci potrebbero essere meno code, come una coda per ogni categoria di QoS. Lo scheduler serve uno cella da ogni coda in un round-robin. Le code sono numerate da 1 a M,e vengono serviti in sequenza. Cioè, se una cella dalla coda 1 è stato servito, poi la prossima coda ad essere servita e’ la coda 2.Questo servizio sequenziale delle code continua fino a quando la coda m-essima e’ servita, dopo di che lo scheduler risale alla coda 1. 3.7 LO STRATO DI ADATTAMENTO ATM Lo strato ATM “adaptation “ (AAL) e’ compreso tra lo strato ATM e lo strato “higher-level” (vedi figura 3.12). AAL converte il traffico generato dal livello superiore in payload ATM e prevede differenti tipi di servizi allo strato superiore . AAL consiste in due sottostrati: il convergence sublayer (CS) e la segmentation and reassembly sublayer (SAR) (vedi figura 3.13). Lo strato CS prevede delle funzioni specifiche. Esso e’ ulteriormente diviso in service-specific convergence sublayer (SSCS convergenze specifiche del servizio di sottolivello) e il common part sublayer (CPS parte comune del substrato). SAR, d'altra parte, ha due funzioni correlate, a seconda di dove la cella ATM si trova : al lato mittente o dal lato ricevente. Sono stati standardizzati quattro 4 livelli di adeguamento: uno strato di adattamento ATM (AAL 1),ATMadaptation livello 2 (AAL 2), strato di adattamento ATM 3 / 4 (AAL 3 / 4), e ATMadaptation strato 5 (AAL 5). Di questi, tutti sono attualmente in uso ad eccezione di AAL 3 / 4. Un ulteriore strato ATM di adattamento detto ATM (Saal), è stato definita per sostenere la i protocolli di segnalazione. SAAL è descritto nel capitolo 5 AAL 1 L'AAL 1 è utilizzato per applicazione che adoperano un'emulazione di circuito ( canale punto punto TDM) oppure per applicazioni che utilizzano sorgenti audio che hanno un costant-bit rate costante. Rientrano cosi nella Classe di servizio CBR. L'incapsulazione SAR in ALL1 avviene riservando un byte del payload della cella, dove sono specificati i seguenti campi: CSI 1 bit Sequence Count 3 bits (Indica il numero della cella,può essere utile per verificare la perdita di celle o l'inserimento errato) CRC 3 bits (Controllo ridondanza ciclica, è un controllo sul Sequence Count) Parity 1 bit Inoltre il Sottolivello Convergence fornisce un buffer per eliminare il jitter fra le celle. AAL 2 L'AAL 2 è utilizzato per quelle applicazione che richiedono una classe di servizione VBR-rt (Dimensione traffico variabile, real time) Es: Audio Video Compresso. Su una singola connessione Atm possono viaggiare più flussi dati appartenenti a sorgenti distinte. È necessario un meccanismo per separare questi flussi. Il sottolivello Convergence ha il compito di Multiplexare questi flussi in fase di invio dei flussi, e di demultiplexare questi flussi in fase di ricezione. Il sottolivello Convergence è suddiviso in SSCS (service specific convergence sublayer) e CPS (Common part sublayer). Le celle in ALL 2 hanno una forma di questo tipo: Start Field: OSF 6 bits SN 1 bit sequence number P 1 bit parità Packet HEader: CID 8 bits LI 6 bit lunghezza paylod UUI 5 bit HEC 5 bit Varible: PAYLOD restanti bit Pad AAL 3/4 ALL 3/4 si rivolge ad applicazioni che richiedono una classe di servizione VBR-nrt (dimensione traffico variabile , non real time). Per applicazioni di questo tipo si preferisce garantire la correttezza dei dati al Delay. Controlli di correttezza sul Paylod e Serial number sostituiscono quei campi che prima erano dedicati a controlli sulla tempificazione. I messaggi sono incapsulati in un Header e in un Trailer dopodiche vengono segmentati nelle Celle ATM. Le celle di ALL 3/4 sono costituite da un Header che fornisce informazioni sul segmento, numero di sequenza, campo per il multiplexing, e da un trailer che contiene un indicatore di lunghezza e CRC. AAL 5 L'AAL 5 non fa altro che inserire una coda di 8 byte ad ogni pacchetto che contiene un campo riservato, lunghezza payload, 32 bit di CRC. Il pacchetto viene incapsulato nella cella ATM si utilizzano due bit del campo PTI per definire l'ultima cella appartenente ad un aggregato di celle corrispondenti ad un pacchetto. ALL 5 viene utilizzato ad esempio per utilizzare ATM in LAN. Quello che avviene sostanzialmente grazie a AAL 5 è convertire gli Indirizzi MAC di 48 bit dei dispositivi in indirizzi locali per ATM 20 byte. una cella, mentre altri sono vuoti. Le sorgenti ATM sono classificati in bit rate costante (CBR) e velocità in bit variabile (VBR). SORGENTE CBR Come accennato in precedenza, una sorgente CBR genera lo stesso numero di bit per ogni unità di tempo. Poiché il flusso di traffico generato è costante, la PCR, SCR, e il rate medio di cella di una sorgente CBR sono tutti uguali, e una sorgente CBR può essere completamente caratterizzato dalla sua PCR. SORGENTE VBR Un modello di traffico comunemente usato per il trasferimento dei dati è il processo on / off (si veda la Figura 4.5). In questo modello, si assume una sorgente che trasmette solo durante un periodo attivo, conosciuto come il periodo on. Questo periodo è seguito da un periodo di silenzio, noto come il periodo di off, durante in cui la sorgente non trasmette. Durante il periodo on,una cella potrebbe essere trasmessa in ogni slot o in un numero fisso di slot, questo dipende dalla PCR della sorgente e la velocità di collegamento. La PCR di una sorgente on / off è il rate in cui trasmette celle durante il periodo on. Si può dire che il picco del bit rate della sorgente è la metà della capacità del link, espressa in bit al secondo. La media del rate della cella e’: PCR × mean length of on period / mean length of on and off period Il modello on / off cattura il concetto di burstiness, che è una caratteristica importante del traffico nelle reti ATM. Il burstiness di una sorgente e’ l’indicativo di come le celle sono raggruppati insieme. Ci sono diverse formule per la misura del burstiness. La formula più semplice è : r = la lunghezza media del periodo/ la somma della media dei periodi on e off. Questa quantità può essere anche visto come la frazione di tempo che la sorgente è attiva a trasmettere. Quando r è vicino a 0 o 1, la sorgente non è burst. Il burstiness della sorgente aumenta con l'avvicinarsi di r a 0.5. Un'altra misura comunemente usato per burstiness, ma più complicato da calcolare, è il coefficiente di variazione al quadrato del tempo di inter-arrivo definito da Var (X) / (E (X)) 2, dove X è una variabile casuale che indica il tempo di inter-arrivo. Un caso particolare del processo on / off è il ben noto processo interrupted di Bernoulli (IBP), che è stata ampiamente utilizzata negli studi di prestazioni delle reti ATM. Durante il periodo on ogni slot contiene una cella con probabilità α , o è vuoto con probabilità 1 - α. Il processo IBP può essere generalizzato in due stati Markov modulati con il processo di Bernoulli (MMBP). Uno dei due stati MMBP si compone di due periodi alternati, periodi 1 e 2 Ogni periodo è geometricamente distribuito. Durante il periodo i, abbiamo arrivi di Bernoulli con rate αi, i = 1, 2. Cioè, ogni slot durante il periodo” i” ha probabilità αi di contenere una cella (vedi figura 4.6) . La transizione tra i due periodi sarà cosi : (vedi tabella subito sotto la figura 4.6). Cioè, se il processo è nel periodo 1 (periodo 2), poi nel prossimo slot sarà nello stesso periodo con probabilità p (q) o si trasforma in Periodo 2 (periodo 1) con probabilità1 - p (1 - q). I processi di arrivo di sopra sono stati definiti in tempo discreto. Analoghi sono stati definiti in tempo continuo. L'equivalente a tempo continuo della IBP è il processo di Poisson interrupted (IPP) che è un processo ben noto utilizzato negli studi del tele traffico. L'IPP può essere generalizzato in due stati Markov modulati con processo di Poisson (MMPP), che consiste in due periodi alternati, periodo dal 1 ° al periodo 2. Ogni periodo i, i = 1, 2, è distribuito esponenzialmente con una media 1/μi e durante i-esimo periodo di arrivi che avviene in modo di Poisson al rate di γi. Più complicato MMPPs può essere ottenuta utilizzando n periodi diversi anziché due periodi come il caso MMPP. 4.2 QUALITA’ DI SERVIZIO QoS E PARAMETRI Un numero di parametri differenti possono essere utilizzati per esprimere la QoS di una connessione, come cell loss rate (CLR), jitter, cell transfer delay (CTD), peak-to-peak cell delay variation, e maximum cell transfer delay (maxCTD). Il cell loss rate (CLR) è uno dei parametri più conosciuti del QoS. Inoltre, la perdita di celle è facile da quantificare, a differenza di altri parametri di QoS quali jitter e il ritardo di trasferimento delle celle. La prerogativa e’ quella di ridurre al minimo il cell loss rate in un commutatore ATM, infatti è stato usato come guida per il dimensionamento dello switch ATM. Il jitter è un importante parametro del QoS per applicazioni in tempo reale, come la voce e video. In generale ,il divario di partenze tra celle successive trasmesse e’ diverso dal divario di arrivo tra celle successive rivevute.Prendiamo in considerazione Figura 4.7. Il divario tra la fine della trasmissione della cella-esimo e l'inizio della trasmissione della (i + 1) cella è TI. Il divario tra la fine dell'arrivo della cella-esima e l'inizio dell'arrivo del (i + 1) cella è SI. L'inter-partenza TI può essere inferiore, uguale o maggiore di SI. Ciò è dovuto buffering e al ritardo di congestione nella rete ATM. Questa variabilità dei tempi di arrivo tra celle nella destinazione è noto come jitter. E 'importante che il servizio fornito da una rete ATM per una connessione voce o video è tale che il jitter è limitato. Se il divario inter-arrivo sono costantemente superiore al divario inter-partenza, poi il play-out processo di celle si esaurirà e si fermerà. La delimitazione jitter non è facile da realizzare. Il cell transfer delay (CTD) è il tempo necessario per trasferire una cella in end-to-end. CTD è costituito da una componente fissa e una parte variabile. Questi ritardi sono dovuti essenzialmente all’ accodamento dei ritardi nei commutatori lungo il percorso delle celle. Il peak-to-peak cell delay variation non deve essere confuso con cell delay variation tolerance (CDVT), che viene utilizzato nel generic cell rate algorithm (GCRA) descritto in Sezione 4.7.1. Il maximum cell transfer delay (max CTD) è un altro parametro di QoS che definisce un limite superiore sul ritardo di trasferimento end-to-end delle celle. Questo limite superiore non è un limite assoluto. Piuttosto, si tratta di una statistica limite superiore, il che significa che l'effettivo end-to-end del ritardo di trasferimento delle celle può occasionalmente superare il max CTD. La rete accettarà la connessione, se è in grado di garantire i valori richiesti di QoS. Tre ulteriori parametri QoS vengono utilizzati: cell error rate (CER), severely errored cell block ratio (SECBR), e il cell misinsertion rate (CMR). Questi tre parametri non sono utilizzati per l’impostazione della chiamate .Servono per monitorare la rete. Il CER di un collegamento è il rapporto tra il numero di celle errate (cioè, le celle consegnate alla destinazione con payload errato) per il numero totale di celle trasmesse dalla sorgente. Il SECBR è il rapporto del numero totale di cell blocks gravemente errati diviso il numero totale di cell blocks trasmesse. Il CMR e’ il numero di celle consegnate ad una errata destinazione diviso dal un intervallo di tempo fisso. 4.3 CATEGORIA DI SERVIZIO ATM Una categoria di servizio ATM è, in termini semplici, una classe di QoS. Ogni categoria di servizio è associata con un insieme di parametri di traffico e una serie di parametri di QoS. Funzioni come l’ammissione di controllo delle chiamate e l'assegnazione di banda (vedi sezione 4.6) sono applicate in modo diverso per ciascuna categoria di servizio. Inoltre, l'algoritmo di scheduling che determina in quale ordine le celle in un buffer di uscita di uno switch ATM sono trasmessi fuori, fornisce diversi priorità alle celle appartenenti a diverse categorie di servizi (vedi punto 3.6.2).La categoria di servizio di un collegamento viene segnalato alla rete con l’ impostazione del tempo della chiamata, insieme con il suo traffico e dei parametri di QoS. Il forum ATM ha definito le seguenti sei categorie di servizi: a bit rate costante (CBR), tempo reale bit rate variabile (VBR-RT), non in tempo reale bit rate variabile (VBR-NRT), Bit Rate non specificata (UBR), bit rate disponibile (ABR), e rate frame garantiti (GFR). Le prime due categorie di servizi (CBR e VBR-RT) sono per applicazioni in tempo reale , le rimanenti categorie di servizi non sono per applicazioni in tempo reale. 4.3.1 IL SERVIZIO CBR Questo servizio è stato progettato per applicazioni in tempo reale, che trasmettono a bit rate costante, come servizi di emulazione del circuito e costante bit rate video. Dal momento che il rate di trasmissione di una applicazione con costante bit rate non cambia nel tempo,il picco di rate della cella è sufficiente a descrivere il traffico che l’applicazione trasmette nella connessione. Nel servizio CBR il ritando end to end e’ un importante parametro QoS. In sintesi, la PCR e i parametri di traffico CDVT sono specificati. Inoltre, i seguenti parametri QoS sono specificati: CLR, picco-picco variazione del ritardo delle cellule, e max CTD. 4.3.2 IL SERVIZIO RT-VBR Questo servizio è stato progettato per applicazioni in tempo reale che trasmettono con un bit rate variabile, ad esempio come video codificati e voce codificato. Dal momento che il rate di trasmissione di una applicazione con bit rate variabile varia nel tempo, il picco rate della cella non è sufficiente a descrivere la quantità di traffico che l'applicazione trasmette tramite la connessione. Oltre al PCR e la tolleranza della variazione del ritardo della cella (CDVT), il rate di cellule sostenuta (SCR) e la dimensione massima burst (MBS) sono specificati .Come nel servizio CBR, il servizio di RT-VBR è destinato anche per applicazioni in tempo reale. Pertanto, oltre al CLR, i due parametri relativi ritardo (picco-picco variazione del ritardo cella e il max CTD) sono specificati. essere CPU intensive. Il problema se accettare o rifiutare una nuova connessione può essere formulato come un problema di accodamento. Ad esempio, consideriamo di nuovo il commutatore non-blocking con buffer di uscita. L'algoritmo CAC deve essere applicato in ogni porta di uscita. Se isoliamo una porta di uscita e il buffer del commutatore, otterremo il modello di accodamento mostrato nella Figura 4.9. Questo tipo di struttura di accodamento è noto come il multiplexer ATM. Esso rappresenta un numero di sorgente ATM di una coda di capacità finita, che è servita da un server, esempio la porta di uscita. Il tempo di servizio è costante ed è uguale al tempo necessario per trasmettere una cella ATM . Supponiamo che il QoS, espresso in cell loss rate , delle connessioni esistenti è soddisfatto. La domanda che si pone è se il rate di perdita di celle sarà ancora mantenuta se la nuova connessione viene accetta. Questo può essere risolta con la soluzione del modello di accodamento del multiplexer ATM con i collegamenti esistenti e la nuova connessione. Tuttavia, la soluzione a questo problema è l’intensivo CPU e non può essere effettuata in tempo reale. In considerazione di questo, una varietà di differenti algoritmi CAC sono stati proposti che non richiedono la soluzione di un tale modello di accodamento. La maggior parte degli algoritmi CAC che sono stati proposti si basano unicamente sul rate di perdita della cella parametro QoS. Cioè, la decisione di accettare o rifiutare una nuova connessione dipende dal commutatore se e’ in grado di fornire la nuova connessione con il rate di perdita della cella richiesto senza influenzare il tasso di perdita di celle delle connessioni esistenti. Nessun altro parametro QoS ,come la variazione del ritardo picco-picco delle celle e il max CTD sono considerati da questi algoritmi. Di seguito, esaminiamo la larghezza di banda equivalente e poi presentiamo il blocco di trasferimento ATM (ABT) utilizzato per le sorgenti burst. In questo schema, la larghezza di banda è assegnata su richiesta e solo per la durata di un burst. Infine, presentiamo uno schema per controllare la quantità di traffico in una rete ATM basati su connessioni di percorsi virtuali (VPC). 4.6.2 LARGHEZZA DI BANBA EQUIVALENTE Si consideri una coda di capacità finita servita da un server con rate μ. Si suppone che questa coda è alimentata da una singola sorgente, e di calcolare la larghezza di banda equivalente. Se si imposta μ pari al bit rate di picco della sorgente, allora non osserveremo un accumulo di celle nel buffer. Questo perché le celle arrivano più in fretta di come vengono trasmessi fuori. Se vogliamo ridurre leggermente il rate di servizio μ , vedremo che le celle iniziano ad accumularsi nel buffer. Se vogliamo ridurre il tasso di servizio ancora un po’ di più, aumenterà la dimensione del buffer. Se continuiamo a ripetere questo esperimento, vedremo che il rate di perdita della cella comincia ad aumentare. La larghezza di banda equivalente della sorgente è definita come il rate di servizio al quale la coda è servita che corrisponde a un rate di perdita delle celle pari a ε. La larghezza di banda equivalente di una sorgente cade a metà strada tra il bit rate medio e il suo bit rate di picco. Se la sorgente è burst, è più vicina ai bit rate di picco, in caso contrario, è più vicina ai bit rate medio. Si noti che la larghezza di banda equivalente di una sorgente non è collegata con la SRC della sorgente. Ci sono varie approssimazioni che possono essere utilizzate per calcolare rapidamente la larghezza di banda equivalente di una sorgente. Una approssimazione comunemente utilizzata è basata sul presupposto che la sorgente è un processo di fluido interrotto (IFP). IFP è caratterizzata dalla terna (R, r, b), dove R è il bit rate di picco, r la frazione di tempo in cui la sorgente è attiva, definita come il rapporto della lunghezza media del periodo on (attivo) diviso la somma della media tra il periodo on e off ; b e la durata media del periodo on. Si supponga che la sorgente alimenta una coda con capacità finita con un tempo di servizio costante, e sia k la dimensione della coda espressa in bit. Il tempo di servizio è pari al tempo necessario per trasmettere una cella. Poi, la larghezza di banda equivalente è dato dalla seguente espressione: 4.6.3 ABT (ATM BLOCK TRANSFER SCHEME) Un numero di sistemi di controllo di congestione sono stati concepiti per le sorgenti bursty in cui ogni commutatore alloca larghezza di banda su richiesta e solo per la durata di un burst. In fase di impostazione della connessione, viene selezionato il percorso della rete ATM , e ogni switch del percorso alloca le necessarie etichette VPI / VCI e aggiorna la tabella di commutazione utilizzate per il label swapping. Tuttavia,non viene assegnato qualsiasi larghezza di banda in questa connessione. Quando la sorgente è pronta a trasmettere un burst, lo comunica allo switch lungo il percorso. Una volta notificato, ogni switch assegna la larghezza di banda necessaria per la durata del burst. Questi sistemi di controllo della congestione sono noti come sistemi di allocazione di banda veloce. Il trasferimento a blocchi ATM (ABT), si tratta di un sistema veloce di banda, è uno standard di capacità di trasferimento ATM. In ABT, una sorgente richiede una larghezza di banda a passi incrementali e decrementali . Il totale di richiesta della larghezza di banda per ogni connessione può variare tra lo 0 e il suo bit rate di picco. Un protocollo di prenotazione veloce (FRP) è stato implementato per gestire le relative direzione delle celle. Questa unità si trova al UNI. Il protocollo utilizza diversi timer per garantire il funzionamento affidabile. Quando l'unità di FRP riceve uno step di aumento di richiesta, inoltra la richiesta al primo switch del percorso,che a sua volta lo trasmette al switch successivo, e così via. Se la richiesta e’ accettata da tutti i commutatori del percorso, l’ ultimo invierà un ACK all'unità FRP. L'unità di FRP informa il dispositivo finale che la richiesta è stata accettata, aggiorna la funzione di policing, e invia una cella di convalida agli switch nel percorso per confermare la prenotazione. Se la richiesta non può essere soddisfatta da un interruttore, il commutatore scarta semplicemente la richiesta. I commutatori a monte, che hanno già riservato la larghezza di banda, scarterà la prenotazione, se non ricevono la cella di convalida entro un tempo prestabilito. Questo timer è uguale al massimo ritardo di andata e ritorno tra l'unità di FRP e il commutatore più lontano. Se la richiesta è bloccata, l'unità di FRP proverà a chiedere lo step di incremento dopo un periodo impostato da un altro timer. Il numero di tentativi è limitato. Questo meccanismo può essere utilizzato da un dispositivo che trasmette burst.Quando il dispositivo è pronto a trasmettere un burst, emette una richiesta di incremento con una larghezza di banda richiesta uguale al bit rate di picco. Se la richiesta è accolta, il dispositivo trasmette il burst, e alla fine annuncia uno step di decremento con larghezza di banda uguale al suo bit rate di picco. In una versione leggermente diversa del protocollo ABT, il dispositivo inizia a trasmettere immediatamente un burst dopo che ha espresso la richiesta di prenotazione. Il vantaggio di questo sistema è che il dispositivo non deve aspettare fino a quando la richiesta viene accolta .Il burst verrà perso se uno switch nel percorso non è in grado di accogliere la richiesta. 4.6.4 CONNESSIONE DEL PERCORSO VIRTUALE Una connessione di percorso virtuale può essere utilizzato in una rete ATM per creare una connessione dedicata tra due commutatori. Supponiamo, per esempio, che una connessione permanente di percorso virtuale è stabilito tra due interruttori (switch 1 e l'interruttore 2). Questi due commutatori potrebbero non essere adiacenti, in tal caso, essi possono comunicare attraverso diverse altri commutatori. Un importo fisso di larghezza di banda è assegnata alla connessione del percorso virtuale. Questa larghezza di banda è riservata per questa particolare connessione e non può essere condivisa con le altre connessioni, anche quando non viene utilizzato completamente. Un dispositivo attaccato allo switch 1 e che desidera comunicare con dispositivo collegato al commutatore 2, è assegnata una parte della larghezza di banda del percorso virtuale della connessione utilizzando l'assegnazione delle bande non statistico. Il collegamento e’ respinto se non c'è abbastanza banda disponibile nel collegamento virtuale, poiché il traffico totale effettuato da questa connessione virtuale non può essere superiore alla larghezza di banda allocata. Un canale di connessione virtuale mantiene lo stesso valore di VCI nell’ intero percorso virtuale. Cioè, il suo valore VCI ha un significato globale. Il percorso virtuale, tuttavia, è identificato da una serie di valori VPI, ciascuno con un significato locale. Un esempio di label swapping (etichetta di scambio) in un percorso virtuale è mostrato in: Un percorso virtuale è stato stabilito tra gli switch 1 e 3. Gli utenti A, B, e C sono attaccati allo switch 1, e tramite il percorso virtuale, sono connessi a alle loro destinazioni A ,B’ e C’. Che sono collegate al commutatore 3. (Per semplicità, supponiamo che la tabella di commutazione in switch 1 è centralizzata e contiene informazioni per tutte le porte di ingresso.) Le prime tre colonne della tabella di commutazione riporta i VPI / VCI di ciascuna connessione in entrata e le relative porte di ingresso. Le altre tre colonne riportano la nuova etichetta e la porta di uscita della connessione. Il percorso virtuale ha un VPI = 1 nella UNI tra gli utenti A, B, C e switch 1, un VPI = 5 nel salto dallo switch 1 allo switch 2, un VPI = 6 dallo switch 2 per passare al commutatore 3; e un VPI = 7, relativa alla norma UNI tra switch tra 3 e utenti A’,B’,e C’. Le connessioni di canale virtuale da A ad A’, B a B’ , e C a C’ sono identificati dalle VCIs 47, 39, e 41, rispettivamente. All'interno di questa connessione, il cliente può creare un numero qualsiasi di circuiti virtuali , a condizione che la larghezza di banda totale assegnata alla connessione del percorso virtuale non è superata. Le connessioni di percorsi virtuali possono essere combinati per formare una rete virtuale sovrapposta su che viaggiano da trasmettitore e ricevitore seguendo lo stesso percorso dei dati. Il ricevitore le ritrasmette indietro alla sorgente come backward RM cells. Gli switches, se necessario, possono introdurre in queste celle delle informazioni di controllo che poi trasmettitore e ricevitore usano per regolare il loro rate. Tuttavia questo meccanismo è inefficace se abbiamo lunghi ritardi di propagazione nel link. Per quanto riguarda la struttura delle celle RM, abbiamo: Message type field: è un campo di 1-byte che contiene sottocampi da 1-bit DIR: indica la direzione delle celle. BN: indica esplicitamente che si tratta di una cella baclward explicit congestion (BECN) generate da uno switch o dal dispositivo di destinazione, senza aspettare che arrivino quelle della sorgente. CI: lo switch o il dispositivo destinazione avverte il trasmettitore che la rete è congestionata. NI: serve ad evirate che il mittente aumenti il suo allowed cell rate (ACR), ovvero il rate corrente. Explicit rate(ER): contiene il rate calcolato da un commutatore nel percorso, se un altro switch calcola un ER più basso il valore verrà aggiornato. Current cell rate (CCR): serve al sending end device per indicare il suo allowed cell rate (ACR). Minimum cell rate( MCR): è il minimo rate che la connessione richiede e che la rete deve garantire. IL MECCANISMO ABR ABR supporta due modalità: binary mode e explicit rate mode. Binary mode: Lo switch marca il campo EFCN( che è uno dei 3 bit definiti nel payload type indicator dell’header di una cella) per indicare che c’è una congestione pendente. Visto ciò la destinazione marca i bit CI e NI nella cella RM di ritorno e poi decide cosa fare con il rate,ossia aumentarlo, diminuirlo o lasciarlo invariato. Explicit mode: uno switch definisce il rate a cui la sorgente può trasmettere nel campo ER delle celle RM di background solamente se questo nuovo rate è minore di quello attuale. Mentre se viene rilevata una congestione lo switch può generare celle RM di background in modo da comunicare lo stato della congestione senza dover aspettare che gli arrivino celle RM. 5.SEGNALAZIONE IN RETE ATM 5.1 INTRODUZIONE Sappiamo che in una rete ATM si possono istaurare 2 tipi di connessioni: · PVC connessioni virtuali permanenti; · SVC connessioni virtuali a commutazione (o switched). Siamo interessati a quest’ultima modalità in cui la connessione viene stabilita mediante procedure di segnalazione in tempo reale. Una connessione punto- punto SVC è stabilita sull’UNI (User Network Interface) tramite il protocollo Q.2931. Una connessione punto – multipunto SVC invece viene stabilita sull’UNI tramite sia il protocollo Q.2931 che Q.2971. Come protocolli di interfaccia tra due swich ATM si utilizza il PNNI il quale acronimo può significare due cose differenti nel caso in cui i due dispositivi appartengano alla stessa rete privata o a due reti differenti: · Private network-node interface: · Private network-network interface. Il PNNI è costituito da 2 componenti: · PNNI signaling protocoll: che serve per stabilire mantenere e pulire connessioni ATM · PNNI routing protocoll: che serve per distribuire informazioni sulla topologia e creare i path. I protocolli PNNI sono stati studiati per essere scalabili in relazione alla dimensione della rete ATM. 5.2 STACK PROTOCOLLARE DI SEGNALAZIONE Simile allo stack protocollare ATM utilizzato per il trasferimento dei dati lo stack di segnalazione serve per la creazione di un SVC 5.3 SAAL (The Signaling ATM Adaptation Layer) Il SAAL è costituito da 2 parti ovvero: SSCS service specific convergence sublayer e CPCS common part convergence sublayer. Il primo dei due a sua volta è diviso in SSCOP e SSCF mentre la parte comune è costituita dal AAL 5. L’SSCF mappa i servizi richiesti dal protocollo di segnalazione al SSCOP, quest’ultimo invece nasce per realizzare connessioni affidabili sull’UNI e nodi peer SSCOP. Ricordiamo che il DATA PLANE non prevedeva alcun controllo sugli errori, invece sul SIGNAL PLANE che stiamo trattando risulta necessario il controllo sugli errori perché ha un impatto notevole sulle prestazioni. 5.3.1 L’SSCOP Nel modello OSI lo strato data link provvede al recupero dei dati tramite HDLC go back n e selective reject ARQ, quest’ultimo risulta più efficace poiché ritrasmette solo quello perso o corrotto. Gli schemi ARQ sono stati concepiti per reti con prodotto banda ritardo basso mentre le reti ATM sono più veloci e si è costatato che i metodi tradizionali di ARQ sono inefficienti dato che viene ritrasmesso un PDU alla volta. Allora sono stati concepiti nuovi protocolli che hanno migliorato il trhoughput. In questi protocolli c’è uno scambio periodico degli stati delle varie entità comunicanti, le decisioni riguardanti i pacchetti ricevuti sono comunicati al trasmettitore in interi blocchi SD e l’elaborazione del protocollo è parallelizzato. Di seguito si descrivono le varie PDU che possono scambiare 2 entità SSCOP Stabilire una connessione: · BEGIN (BGN) è utilizzato per richiedere l’istituzione di un collegamento tra entità SSCOP richiedendo la chiarezza dei peer, i buffer dei ricevitori e le variabili di stato di entrambi; · BGAK è l’ack di risposta per il BGN (accetto); · BGREJ è il nack di risposta per il BGN (rifiuto); Rilascio · END è usato per rilasciare una connessione; · ENDAK per conferma del rilascio; Risicronizzazione · RS richiesta di sincronizzazione delle variabili di stato e buffer; · RSAK conferma per la richiesta di sincronizzazione; Recupero · ER è usato per correggere gli errori; · RSAK conferma per la richiesta di correzione; 5.4 IL CANALE DI SEGNALAZIONE Questa è una connessione VC che viene utilizzato esclusivamente per sostenere il traffico ATM che risultati dallo scambio di messaggi di segnalazione tra due peer protocolli di segnalazione. Si tratta di un difetto di connessione individuati dalla VPI=0 e VCI= 5. Questo canale di segnalazione viene utilizzato per controllare le connessioni VC all'interno di tutti i percorsi virtuali. La segnalazione canale VPI / VCI = 0 / 5 è utilizzato in combinazione con la modalità di segnalazione noto come segnalazioni non associati segnalazione. In questa modalità, tutte le connessioni VC sono state create, controllato e rilasciato tramite il canale di segnalazione VPI / VCI = 0 / 5. Un canale di segnalazione all'interno di un VPI = x, dove x> 0, viene utilizzato in combinazione con la modalità di segnalazione nota come segnalazione associata. In questa modalità, solo le connessioni VC all'interno del percorso virtuale x vengono creati, controllato e rilasciato tramite il canale di segnalazione VPI / VCI = x / 5. 5.5 INDIRIZZI ATM Ciascun dispositivo ATM ha un unico indirizzo, reti ATM pubbliche o private utilizzano formati di indirizzamento diversi: · Reti ATM pubbliche E.164 · Reti ATM private NSAP E.164 è costituito da 16 digit (64 bits) , ogniuno dei quali sono codici in binary coded decimal (BCD) usando 4 bits. Quindi la lunghezza totale dell’indirizzo E.164 è 64 bits. Il primo digit indica se è unicast o multicast, i tre digit successivi indicano il codice del paese e i restanti sono utilizzati per indicare una zona o città, un codice di scambio, e un identificatore di dispositivo di fine. Quando si collega una rete ATM privata a una rete pubblica, solo il UNI,s è collegato direttamente alla rete pubblica e ha un indirizzo E.164. L’indirizzo privato è basato concettualmente su domini gerarchici ed è costituito da IDP e DSP: L’IDP specifica l’amministratore che è responsabile dell’assegnazione del DSP. L’IDP è diviso in AFI e IDI. L’AFI specifica il formato dell’IDI e l’IDI specifica l’indirizzo di rete da cui l’DSP sono assegnati. Esistono 3 tipi di IDI · DCC (data country code) · ICD (international code designator) · Indirizzo E.164 Il DSP è costituito dal HO-DSP, ES1 e SEL. L’ESI è l’identificativo del dispositivo finale, è unico per IDP e HO DSP (potrebbe essere l’indirizzo MAC). Il SEL ha un significato solo locale utilizzato per distinguere le diverse destinazioni finali raggiungibili. 5.6 IL FORMATO DEL MESSAGGIO DI SEGNALAZIONE Il formato del messaggio di segnalazione è quello mostrato sotto, esso è identico sia per Q.2931 Q2971 e PNNI. Il campo protocol discriminator è usato per identificare il protocollo di segnalazione utilizzato, dal byte 3 al 5 vi è il numero di chiamata (call reference value) esso è un numero assegnato da chi origina la connessione uno per ogni chiamata (connessione) e viene tenuto per tutta la connessione, è usato dal protocollo di segnalazione per associare il messaggio alla specifica chiamata ( da non confondere con VPI / VCI valori che verrà assegnato alla connessione ATM risultante. La lunghezza del call ref. Value è posta nel secondo byte (per esempio 0011 indica una lunghezza di 3 byte del call reference value). Può accadere che due chiamate abbiano lo stesso call reference value se sono generate da interfaccia opposte, a tal fine esiste il flag posto nel terzo byte che viene posto a zero se il messaggio è inviato da chi la genera e 1 viceversa. Il tipo di messaggio (message type) posto tra il sesto e settimo byte è usato per identificare il tipo del messaggio di segnalazione. Il campo message length posto tra l’ottavo e nono byte è usato per indicare la lunghezza del messaggio di segnalazione escludendo i primi nove byte. In generale ogni messaggio di segnalazione ha una certa varietà di informazioni di cui deve essere dotata, queste informazioni sono organizzate in differenti gruppi chiamati information elementes (IE) ogni messaggio di segnalazione contiene un numero variabile di informazioni che sono aggiunti dal byte 10. La struttura degli information elementes è mostrata sotto, il primo byte contiene l’identificativo ( IE identifier) che è usato unicamente per identificare l'elemento di informazione. Il secondo byte contiene vari campi, quali lo standard di codifica, vale a dire, ITU-T, ISO / IEC, nazionali, di rete standard specifici (privati o pubblica), e l'indicatore di azione di IE. 3 e 4 byte contengono la lunghezza degli IE (escludendo dal 1 al 4 byte) e dal 5 in poi contengono le informazioni per specifico IE. 5.7 IL PROTOCOLLO DI SEGNALAZIONE Q2931 Questo protocollo stabilisce un point-to-point SVC su UNI in tempo reale. In questa sezione prima esaminiamo gli elementi di informazione usati nel messaggio Q.2931 e poi descriviamo il messaggio Q.2931 e mostreremo come avviene la fase iniziale e finale di una chiamata. 5.7.1 INFORMATION ELEMENTS (IE) Come visto prima ogni messaggio di segnalazione contiene una serie di informazioni organizzate in gruppi diversi, conosciuti come elementi di informazione (IE). Di seguito si riportano alcuni IE usati nel protocollo di segnalazione Q.2931: · AAL parameter IE indica il valore del parametro AAL usato dai dispositivi finali; · ATM traffic descriptor IE Specifica i parametri del traffico in entrambe direzioni; · Broadband bearer capability IE Usato per definire il servizio ATM richiesto per una nuova; · Broadband high-layer IE, broadband low-layer IEutilizzato per verificare la compatibilità dell’user chiamato; · Broadband repeat indicator IE indica come IE ripetuti vanno interpretati; · Call state descrive lo stato attuale della chiamata; · Called party number IE, and called party subaddress IE identificano il nome dell’user chiamato; · Calling party number IE, and calling party subaddress IE identificano l’user del chiamante; · Cause IE descrive il motivo della generazione di determinati messaggi indica la posizione e le cause che lo hanno generato; · Connection identifier IE identificano il VPI/VCI allocate alla connessione UNI; · End-to-end transit delay IE indica il ritardo massimo accettabile di transito da prevedere nella connessione; · Extended QoS parameters IE specifica i valori accettabili e cumulative di alcuni dei parametri QoS; · Transit network selection IE identifica una rete di transito che la chiamata può attraversare. Un dispositivo ATM potrebbe non essere in grado di elaborare tutte queste informazioni, prenderà in esame solo ciò che gli interessa. 5.7.2 Q.2931 MESSAGGI I messaggi di Q2931 possono essere raggruppati nelle seguenti tre categorie call, establishment, call clearing, and miscellaneous. Ogni categoria di messaggio usa il formato descritto in precedenza (con il protocol discriminator posto a 00001001) e contiene una serie di IE. 6.L’ARCHITETTURA MULTI-PROTOCOL LABEL SWITCHING (MPLS) INTRODUZIONE Lo schema multi-protocol label switching (MPLS) si basa su tag switching di Cisco, che a sua volta è ispirato dal sistema di commutazione IP switching scheme, un approccio per la commutazione dei pacchetti IP su ATM è stato proposto dalla Ipsilon Networks. MPLS è stato standardizzato da IETF, e introduce una struttura orientata alla connessione sulla rete IP che diversamente è connectionless. MPLS elude la tabella di look-up della CPU - intensitive nella trasmissione della tabella di routing necessarie a determinare il prossimo router di un pacchetto IP. Inoltre, può essere utilizzata per introdurre QoS nella rete IP. Interessante notare che, dopo l'introduzione dei tag switching, e successivamente dell’ MPLS, sono stati sviluppati diversi algoritmi CPU-efficient per realizzare la tabella di look-up nella tabella di routing. L'importanza di MPLS, però, non è diminuita dal momento che è considerato come una soluzione per l'introduzione di QoS nelle reti IP. MPLS richiede una serie di procedure per la distribuzione affidabile dell’assegnazione delle label (etichette).In considerazione di ciò, vari schemi sono stati proposti per la distribuzione dei label come label distribution protocol (LDP) e il resource reservation protocol – traffic engineering (RSVP-TE) che sono i più popolari. 6.1 IL PROTOCOLLO INTERNET (IP) IP fa parte della suite TCP / IP dei protocolli utilizzati in Internet. TCP corrisponde al livello trasporto e IP al livello rete del modello OSI. In questa sezione, si descrive l'attuale versione di IP, nota come IP versione 4 (IPv4). IP fornisce un servizio senza connessione con commutazione di pacchetto con datagrams. Un host IP può trasmettere datagrammi ad un host IP di destinazione, senza dover impostare una connessione con la destinazione, come nel caso di X.25, frame relay e ATM. Gli IP datagrams vengono instradati attraverso la rete IP in modo indipendente gli uni dagli altri e, in teoria, possono seguire diversi percorsi attraverso la rete IP. In pratica, tuttavia, la rete IP utilizza le tabelle di routing che restano fissi per un periodo di tempo. In considerazione di ciò, tutti i pacchetti IP da un mittente a un destinatario solitamente seguono lo stesso percorso. Queste tabelle di routing sono aggiornate periodicamente tenendo conto di collegamenti congestionati e malfunzionamenti hardware dei router e link. IP non garantisce la consegna dei datagrams IP. Inoltre,come nelle reti ATM, IP non controlla il payload dei datagram IP per gli errori, ma controlla solo header IP. IP scarterà i datagram IP, se ritiene che il suo header sia errato. Perdite o errori sono determinati dal TCP del destinatario. 6.11 L’HEADER IP Un datagrams IP è costituito da un header e un payload. L’header IP è mostrato nella figura sotto ed è costituito da una parte fissa di 20 byte e una parte opzionale di lunghezza variabile. I seguenti campi sono definiti nell'intestazione IP: Version: un campo di 4 bit utilizzato per indicare quale versione del protocollo utilizzato; Internet Header Length (IHL) campo di 4 bit che fornisce la lunghezza dell'intestazione in parole di 32 bit. La lunghezza minima dell’header è 5 parole di 32-bit (o 20 byte); Type of service: è un campo di 8 bit che indica se il mittente preferisce avere un percorso con ritardo minimo, o un percorso con throughput massimo; Total lenght: un campo a 16 bit utilizzato per indicare la lunghezza del datagram intero (header e payload). Il valore predefinito per la lunghezza massima è di 65.535 byte; Identification: campo di 16 bit utilizzati dal ricevitore per identificare il frammento a cui il datagram appartiene. Tutti i frammenti di un datagramma hanno lo stesso valore per il campo identification; Flags: questo è un campo di 3 bit, ma solo due bit sono utilizzati ovvero il more fragments and don’t fragment. Tutti i frammenti, tranne l'ultimo, hanno il more fragments più bit settato. Questa informazione permette l icevitore di sapere quando tutti i frammenti sono arrivati. Il don’t fragment è utilizzato per impedire la frammentazione; Fragment offset: questo campo a 13 bit contiene un offset che indica la posizione del frammento nel datagramm originale; Time to live: questo è un campo di 8 bit che specifica in secondi per quanto tempo è permesso al datagram di stare in rete. La durata massima è di 255 sec. Ogni router che elabora il datagram deve diminuire questo settore da un secondo a alcuni secondi se il datagram è in coda nel router per lungo tempo. Questo campo può essere visto come simile a un conteggio di hop. Quando il time to live campo diventa 0, il datagram viene scartato. Questo impedisce ad un datagram di muoversi nella rete per sempre; Protocoll: questo campo è lungo 8 bit e determina il protocollo di livello superiore (ad esempio TCP o UDP), al quale il datagram dovrà essere passato; Header checksum: un campo di 16 bit utilizzato per verificare se l'header IP è stato ricevuto correttamente.Il mittente aggiunge tutti i 16-bit mezze parole dell'intestazione utilizzando una aritmetica a complemento, supponendo che il campo checksum è 0. Il 1's complemento del risultato finale viene poi calcolato e inserito nel campo checksum. Il ricevente calcola la checksum, e se il risultato finale è 0, quindi l'intestazione è stata ricevuto correttamente. In caso contrario, l'intestazione è erronea e il datagramma viene scartato. Il checksum viene ricalcolato ad ogni router lungo il percorso del datagramma, visto che a almeno un campo di intestazione (il tempo di vivere sul campo) è cambiato; Source address: un campo a 32 bit compilato con l’ host che sta inviando il messaggio; Destination address: un campo a 32 bit compilato con l’ host che sta ricevendo il messaggio;. La schema di indirizzamento IP sarà discusso di seguito; Options: campo a lunghezza variabile utilizzato per codificare le opzioni su richiesta dell'utente (ad esempio, la sicurezza, il source routing, registrazione percorso e timbratura di tempo); Padding: campo a lunghezza variabile usato per fare l'intestazione del datagramma un multiplo intero di parole di 32 bit. 6.1.2 INDIRIZZO IP Come abbiamo visto sopra, gli indirizzi IP sono di 32 bit. La parte di rete individua la rete fisica su cui l'host è collegato. Il suffisso identifica l’host stesso. Le dimensioni di questi due campi variano a seconda della classe di IP. In particolare ci sono cinque classi diverse di indirizzi - A, B, C, D ed E (vedi figura sotto). Classi A, B e C si chiamano classi primarie, perché sono utilizzati per ospitare indirizzi. Classe D è utilizzato per il multicasting, classe E è riservata per usi futuri. Il primo campo determina la classe IP, e va da 1 bit per una classe A fino a 5 per la classe E. Il secondo campo dà l'indirizzo di rete, e il terzo campo è il suffisso che dà l'indirizzo dell'host. Nella classe A, la parte rete è di 7-bit e la parte d’indirizzo degli host è di 24-bit , risultando 128 indirizzi di rete e 16.777.216 indirizzi di host. Nella classe B, la parte rete è di 14 bit mentre la parte di l'indirizzo è di 16-bit, risultando 16.384 indirizzi di rete e 65.536 host. Nella classe C sono dedicati 21 bit per l'indirizzo di rete e 8 bit, con conseguenti 2.097.152 di indirizzi di rete e 256 indirizzi host. Gli indirizzi di rete di solito sono scritti nella notazione decimale puntata (dotted decimal notation). Cioè, ogni byte è scritto in cifre decimali che vanno da 0 a 255. A titolo di esempio, l'indirizzo IP 00000111 00000010 00000000 00000010 sarà scritto come 7.2.0.2. Usando questa notazione, abbiamo che la gamma di indirizzi di classe A è da 1.0.0.0 a 127.255.255.255, la classe B ha una gamma di valori da 128.0.0.0 a 191.255.255.255, e per la classe C abbiamo un gamma da 192.0.0.0 a 233.255.255.255. La Classe C è molto comune, mentre la classe A è usato raramente poiché ci sono solo poche reti con quel gran numero di host. IP dell'host riserva l’indirizzo 0 per indicare l'indirizzo di una rete. Per esempio, l'indirizzo di classe B 128.32.0.0 ha il campo di rete 128.32 e il suo suffisso è 0.0. Questo indica l'indirizzo della rete 128.32. Per la radiodiffusione all'interno della rete, utilizza l'indirizzo IP 128.32.255.255. IP assegna più indirizzi IP per i router, dal momento che un router è collegato a più reti. In particolare, un router ha un indirizzo IP per ogni rete che è collegato ad esso. Un singolo host collegato a più reti è anche più indirizzi IP, uno per ciascuna connessione di rete. Tale host è denominato multihomed. SUBNETTING La struttura degli indirizzi IP descritta sopra introduce una gerarchia a due livelli. Il primo livello è l'indirizzo di rete e il secondo livello è l'host. In molti casi, questi due livelli di indirizzamento non sono sufficienti. Per esempio, se si considera un'organizzazione dotata di un indirizzo di classe B, allora tutti gli host sembrano essere organizzati in un unico gruppo, descritto dall'indirizzo di rete. Tuttavia, gli host all'interno di una organizzazione sono tipicamente raggruppati per formare un certo numero di reti LAN differenti. Al fine di distinguere le LAN il suffisso dell'indirizzo IP è suddiviso in una parte di sottorete e una parte host. Ciascuna LAN ha assegnato un indirizzo di subnet trasportato nella parte di sottorete e un host nella LAN viene assegnato a un indirizzo che è trasportato nella parte host. L'analisi reale del suffisso in questi due sottocampi è dettata da una maschera di sottorete. La maschera di sottorete è nota solo ai router all'interno della rete in quanto le subnet non sono visibili all'esterno della rete. Questa tecnica è nota come subnetting. CLASSLESS INTER-DOMAIN ROUTING (CIDR) La causa principale di esaurimento di indirizzi è stato lo spreco di indirizzi di classe B; molte organizzazioni usavano indirizzi di classe B, ma aveva solo un piccolo numero di host, lasciando così lo spazio di indirizzi host in gran parte inutilizzati. L'esplosione di tabelle di routing era dovuta al fatto che i router dominio in cui l'IP router utilizzano la decisione consueta trasmissione basata su prefissi). Come mostrato nella Figura 6.4, il dominio MPLS B è composto da cinque router, di cui due LSR (LSR LSR 1 e 2); le altre tre potrebbero essere LSR o nodi MPLS. Il dominio MPLS B è collegato al dominio MPLS A via LSR 1, ed è collegata alla non-MPLS C del dominio IP via LSR 2. LSR 1 e 2 sono indicati come nodi di bordo MPLS. Per semplicità, supponiamo che tutti i nodi all'interno di un dominio MPLS sono LSR. Per vedere come funziona MPLS, consideriamo un dominio MPLS composta da cinque LSR (LSR A, B, C, D ed E), tutti collegati con connessioni punto-punto, come mostrato in Figura sotto. LSR A e C sono collegati ai domini non-MPLS 1 e 2. Supponiamo che una nuova serie di host con il prefisso (X.0.0.0, y.0.0.0), dove x.0.0.0 è l'indirizzo di rete di base e y.0.0.0 è la maschera, è direttamente collegato a E. Il flusso dei pacchetti IP con questo prefisso da A a E è via B e D. Cioè, il next hop di A per questo prefisso è B, il next hop di B è D e il next hop di D E. Allo stesso modo, il flusso di pacchetti IP con lo stesso prefisso da C a E è via D. Cioè, il next hop di C per questo prefisso è D, e il next hop di D è E. Le interfacce in Figura mostrano come questi router sono interconnessi. Per esempio, A è interconnesso a B via if0 e B è interconnesso a Ae B è interconnesso ad A, C, D via I1, If2 e if0, rispettivamente. Quando un LSR identifica la FEC associato a questo nuovo prefisso X(.0.0.0, y.0.0.0), Si seleziona una etichetta da un pool di etichette libere e crea una voce nella tabella di indirizzamento (LFIB). Questa tabella contiene informazioni relative alle etichette di entrata e in uscita associata ad una FEC e l'interfaccia di uscita, cioè il FEC's hop router successivo. La LSR salva anche l'etichetta nella sua FIB nella voce associate con il FEC. La voca nella LFIB associato a questo particolare FEC per ogni LSR è mostrato in Tabella sopra. (Ai fini della presentazione abbiamo elencato tutte le voci in un’ unica tabella). Si noti che B ha scelto come etichetta in entrata pari a 62; D ha selezionato 15; E ha selezionato 60. Dal momento che A e C sono router MPLS non si aspettano di ricevere etichette dai pacchetti IP, e non hanno selezionato una etichetta in arrivo per questa FEC. Ie rimanenti informazioni di ogni voce dà il prossimo hop LSR e l'interfaccia di output per il FEC. Quindi, per questo FEC, il next hop per A è B, ed è attraverso if0. L’ incoming label è l'etichetta che un LSR si aspetta di trovare in tutti i pacchetti IP in entrata che appartengono a un FEC. Ad esempio, nell'esempio precedente, LSR B aspetta che tutti i pacchetti IP in entrata appartenenti al FEC associati con il prefisso (x.0.0.0, y.0.0.0) devono essere etichettati con il valore 62. L'etichettatura di questi pacchetti deve essere fatto dai LSR a monte di B. In altre parole, essi sono a monte rispetto al flusso dei pacchetti IP associato a questo FEC. In questo esempio, l'unica LSP che è a monte di B è A. Nel caso di D, sia B che C sono LSR a monte. Affinché un LSR riceva pacchetti IP in ingresso etichettati con il valore che essa ha selezionato, il LSR deve informare i suoi vicini circa la sua scelta per una particolare etichetta FEC. Nell'esempio precedente, LSR B invia le informazioni ad A, D e C. A riconosce che è a monte da B, e utilizza le informazioni per aggiornare la voce per questo FEC nella sua LFIB. Per quanto concerne questo FEC, D e C non sono a monte di B, e non utilizzano queste informazioni nella loro LFIBs. Tuttavia, essi possono scegliere di conservarla per uso futuro. Ad esempio, nel link C-to-D potrebbe guastarsi rendendo l’LSR B il salto successivo per questo FEC. In questo caso, C userà il label pubblicizzato da B e aggiornerà la voce nella sua LFIB. D invia i suoi dati a B, C e E. Esendo B e C entrambi a monte di D, loro utilizzeranno queste informazioni per aggiornare le voci nella loro LFIB. Infine E invia le sue informazioni a D, che utilizza per aggiornare la sua voce nella sua LFIB. Come risultato, ogni voce di LFIB ciascun LSR saranno modificati (vedi Tabella sotto). Per LSR E, il next hop successivo è se stesso. Ciò indica che i pacchetti IP associati a il prefisso (x.0.0.0, y.0.0.0) saranno trasmessi alla destinazione locale su se 0 utilizzando il loro prefisso. Una volta che le etichette sono state distribuite e le voci sono state aggiornate nel LFIBs, la trasmissione di un pacchetto IP appartenente alla FEC associati con il prefisso (x.0.0.0, y.0.0.0) viene fatto usando solo le etichette. Supponiamo che A riceve un pacchetto IP dal dominio non-MPLS IP 1 con un prefisso (x.0.0.0, y.0.0.0). A identifica che il pacchetto IP ha un indirizzo IP appartiene alla FEC, e guarda sulla propria LFIB per ottenere il valore dell’etichetta e interfaccia in uscita. Si imposta il valore dell'etichetta a 62, incapsula utilizzando il formato mostrato in figura 6.3 (vedi pag 7), e la trasmette alla interfaccia in uscita if0. Quando il pacchetto IP arriva a LSR B, l'etichetta viene estratta e B guarderà sulla propria LIB. La vecchia etichetta viene sostituita dalla nuova, che ha 15, e il pacchetto IP viene inoltrato all'interfaccia if0. LSR D segue esattamente la stessa procedura. Quando essa riceve il pacchetto IP da B, che sostituisce l'etichetta in arrivo con l'etichetta in uscita, che è 60, e la trasmette alla interfaccia IF2. Infine, E invia il pacchetto IP a destinazione locale. La stessa procedura vale per un pacchetto IP con un prefisso (x.0.0.0, y.0.0.0) che arriva alla C dal non-dominio MPLS 2. Nella Figura 6.6 (sotto), si riportano le etichette assegnate dalle LSR. Queste etichette sono simili ai VPI / VCI nella ATM. Essi hanno un significato locale, cioè, ogni etichetta è valido solo per un link. La sequenza di etichette di 62, 15, 60 forma un percorso conosciuto come il Label Switched path (LSP). Questo percorso è analogo a una connessione point-to-point ATM, che è definita dal una sequenza di VPI/VCI. Una connessione ATM è associata con due dispositivi, considerando che un percorso Label Switched è associato ad una FEC. Diversi label switched paths sono tipicamente associati alla stessa FEC, formando un diagramma ad albero (vedi Figura 6.6). Ogni LSP ha un LSR di ingresso e un LSR di uscita. Per esempio, in figura 6.6, LSR A ed E sono LSR di ingresso e uscita, rispettivamente, per il LSP dalla A a E. Allo stesso modo, LSR C ed E sono LSR di ingresso e l'uscita per la LSP LSR da C a E. Il label switching elimina la tabella di CPU-intensive "look-up nella FIB, necessari per determinare il router successivo di un pacchetto IP. Una tabella di look-up in LFIB non è così in termini di tempo al momento che un LFIB è notevolmente più piccola di un FIB. Dopo l'introduzione del label switching, sono stati sviluppati diversi algoritmi di CPU-efficace per svolgere ricerche tavolo nella FIB. Questo non diminuisce l'importanza della Label Switching dal momento che è stato visto come un mezzo per introdurre QoS nella rete IP. Un modo in cui può essere introdotta QoS nella rete è quello di associare ogni pacchetto IP con una priorità. Questa priorità può essere effettuata tramite il campo di 3 bit sperimentale dell’incapsulamento del label (vedi Figura 6.3). Le priorità possono essere assegnati da un nodo di bordo MPLS.L’etichettamento dei pacchetti IP all'interno di un LSR sono serviti secondo la loro priorità, come nel caso di uno switch ATM. Ricordiamo che, nelle reti ATM, ciascuna connessione VC è associato ad una categoria QoS. Uno switch ATM può determinare la QoS di una cella in arrivo dal suo valore VPI / VCI, e di conseguenza può accodare la cella nella coda appropriata QoS. Uno switch ATM diverse code QoS per ogni interfaccia di uscita. Queste code sono servite utilizzando un algoritmo di scheduling, in modo che le connessioni VC possono essere servite in base al loro QoS richiesto. Una struttura di accodamento simile può ora essere introdotte in un router IP. I pacchetti IP possono ora essere in coda ad una interfaccia di uscita secondo la loro priorità, e possono essere trasmesse in un ordine determinato da un schedulatore. 6.2.1 SCHEMA DI RIPARTIZIONE DEI LABEL Nell’esempio di Label Switching sopra, un LSR lega (cioè alloca) un'etichetta per un FEC e salva queste informazioni nel suo LFIB come etichetta in arrivo. Annuncia quindi il legame tra l'etichetta in arrivo e la FEC ai suoi LSR vicini. Un LSR upstream (per esempio un LSR che è a monte del collegamento del flusso di traffico) pone l'etichetta nel campo outgoing nella voce del suo LFIB che è associato a questo FEC. trasmesso al LSR 5 usando la etichetta 70.Infine, LSR 5 inoltra il pacchetto al LSR 6 con l'operazione di etichettatura: sostituiscel'etichetta in alto sullo stack con una nuova etichetta. Come risultato, il pacchetto arriva al LSR 6 con una etichetta 30. Come possiamo vedere, quando un pacchetto viene trasmesso all'interno del dominio MPLS B, che contiene due etichette. L'etichetta in alto è utilizzato per label switching all'interno del dominio MPLS B, e l'etichetta in basso è utilizzato nei due nodi al bordo del collegamento dei domini MPLS B e C. Questo uso dello stack di label permette la creazione di tunnel LSP. Ad esempio,si può pensare che il percorso tra LSR 3 e 4, attraverso il dominio MPLS B, definito dalle etichette di 22, 54, e 66, è un tunnel che interconnette gli LSR 2 e 5. L’ LSR 2 per inoltrare i pacchetti a questo tunnel, deve utilizzare l'etichetta 40. Dall'altra parte del tunnel, in modo che i pacchetti siano inoltrati all LSR 6, l’etichetta di arrivo all’LSR 5 deve avere il valore 70, in modo che LSR 5 può “switcchiare” all’ LSR 6. Questa etichetta è trasportata nella parte inferiore nello stack di label. 6.3 MPLS OVER ATM MPLS è stato definito per essere eseguito su diversi sistemi di rete tra cui ATM e Frame Relay. Nel caso di MPLS su ATM, i protocolli di segnalazione che tipicamente girano su un switch ATM, quali Q.2931 e PNNI, sono sostituiti dai protocolli IP, come OSPF, BGP, PIM e RSVP. Lo switch ATM è utilizzato come semplice dispositivo a commutazione di cella. In una rete ATM, la connessione non è configurata usando Q.2931 e PNNI. Utilizzando PNNI, uno switch ATM prende coscienza della topologia del suo gruppo di peer e dei nodi logici in gruppi di peer dei livelli più alti. Quando un utente chiante intende stabilire una connessione verso un utente di destinazione, invia un messaggio SETUP verso il suo switch ATM d’ingresso utilizzando il protocollo di segnalazione Q.2931. Il commutatore ATM d’ingresso calcola un percorso attraverso la rete ATM, e quindi utilizzando il protocollo PNNI inoltra il messaggio di SETUP allo switch successivo lungo il percorso, che lo inoltra al prossimo switch ATM sul percorso, e così via, fino a quando il messaggio di SETUP raggiunge lo switch ATM d’uscita che serve l'utente chiamato. Lo switch d’uscita inoltra il messaggio SETUP all'utente chiamato con il protocollo di segnalazione Q.2931, e se l'utente chiamato accetta, una conferma è tornato indietro per l’utente chiamante. A quel tempo, l'utente chiamante può iniziare la trasmissione dei dati verso l'utente chiamato. In MPLS su ATM, l’intera funzionalità di segnalazione viene rimossa dagli switch ATM. Invece, ogni switch ATM è identificato da un indirizzo IP e gestisce protocolli IP di routing. Un tale switch ATM è denominato-ATM LSR. Come in un router IP, utilizzando Protocolli di routing IP, un ATM-LSR può conoscere i suoi vicini e la topologia del suo dominio IP, ed è in grado di calcolare l’hop successivo ATM LSR per ogni IP di destinazione. In MPLS su ATM, un LSP non è altro che una connessione ATM che si configura mediante MPLS. L'etichetta MPLS viene portata nel campo VPI / VCI della cella. Se è usato uno stack label, possono essere trasportate solo due etichette. La top label è trasportata nel campo VPI e quella inferiore nel campo VCI. La pubblicità di associazioni etichetta è fatta usando allocazione downstream on demand. Cioè, quando un ATM LSR individua una nuova FEC alloca una etichetta, ma non la pubblicizza ai suoi vicini. Un ATM-LSR a monte (upstream) ottiene il legame all’etichetta con l'invio di una richiesta. Una connessione predefinita ATM VC è usata per lo scambio delle informazioni sui legami di etichetta. Consideriamo ora una rete di ATM-LSR. Un pacchetto IP nell’ ATM LSR di ingresso, prima è incapsulato in una CPS-PDU con AAL 5. Poi, è suddiviso in un numero intero di blocchi di 48 byte e ciascun blocco viene portato in una cella ATM diversa. L'etichetta associato alla particolare LSP viene portata nel campo VPI / VCI della cella. Quando un cella ATM raggiunge il next hop ATM LSR, la sua etichetta è sostituita dalla etichetta in uscita e la cella viene commutata sulla uscita appropriata da dove viene trasmessa fuori al prossimo ATM LSR. Questo continua fino a quando la cella raggiunge l’ATM LSR di uscita. Lì, la cella è assemblata con le altre celle nell’originale AAL 5 CSC-PDU, e il pacchetto IP viene recuperato dal suo payload e consegnato al protocollo IP. Pertanto, un pacchetto IP attraversa la rete di ATM-LSR in una sequenza di celle ATM che vengono commutate attraverso ogni-ATM LSR senza dover ricostruire il pacchetto IP originale in ogni ATM LSR intermediario, tranne che nell’ATM LSR di uscita. Questo è molto simile allo schema di commutazione IP. 6.3.1 VC MERGING (fusione) Un problema interessante che si pone nella label switching su ATM è VC merging. Questo problema si pone quando due LSR ATM sono entrambi collegati alla stessa ATM-LSR a valle. Consideriamo 4 ATM-LSR (A, B, C e D) in Figura 6.9, ci lascia presumere che il flusso di pacchetti IP per uno specifico FEC va da A a C e poi a D e da B a C e poi a D. Si supponga che D è l’ LSR di bordo che serve host associati con una FEC. (Le etichette assegnate sono mostrati in Figura 6.9 in grassetto.) Adesso vediamo cosa accade quando A ha un pacchetto IP (lo chiamiamo pacchetto 1) da trasmettere che appartiene a questo FEC. Questo pacchetto sarà incapsulato da AAL 5 e poi sarà segmentato in un numero intero di blocchi di 48 byte. Ogni blocco sarà poi trasportato nel payload di una cella ATM etichettati con il valore 15.Le celle saranno trasmesse a C, dove avranno cambiato la loro etichetta a 20 e poi viene trasmessa al buffer di output che collega D. In questo buffer, è possibile che queste celle vengano interlacciate (interleaved) con celle appartenenti ad un pacchettoIP, lo chiamano pacchetto 2, associato allo stesso FEC e trasmesso da B. Ovvero, come le celle simettono in coda nel buffer, i pacchetti 1 possono trovarsi tra due successivi pacchetti 2. Dal momento che tutte queste celle saranno inviate a D con l'etichetta di 20, D non sarà in grado di identificare quali di queste celle fanno parte del pacchetto 1 o di pacchetto 2. Di conseguenza, D non sarà in grado di ricostruire l'originale AAL 5 PDU. Una semplice soluzione a questo problema è quello di raccogliere prima tutte le celle appartenenti alla lo stesso pacchetto IP nel buffer della porta di uscita di C. Una volta che tutte le celle sono arrivati, allora possono essere trasmessi in back-to-back a D. Per fare questo, lo switch dovrà essere in grado di individuare le celle di inizio e fine AAL 5 PDU. Per fare questo lo switch deve essere impostato early-packet and partial-packet discard policies. In caso contrario, si usano più etichette, in modo che il percorso da A a D è associato a un diverso set di etichette rispetto al percorso da B a D. • A-E: 2 sessioni LDP, uno per ‹Lsr170, 2› e uno per ‹lsr170, 3› • A-F: 2 sessioni di LDP, uno per ‹Lsr170, 0› e uno per ‹lsr170, 4› E 'anche possibile impostare una sessione LDP tra due LSR non direttamente collegati. Questo può essere utile quando due LSR lontani potrebbero voler comunicare tramite un LSP. I due LSR possono stabilire una sessione al fine di comunicare un’associazione di etichetta. Questa etichetta può essere spinta verso il basso nello stack delle etichette come nell'esempio discusso 6.2.4. Un meccanismo di scoperta LDP permette ad un LSR di scoprire dei potenziali peer LDP (cioè, altri LSR che sono direttamente collegati ad esso). Un LSR invia periodicamente link LDP hellos fuori da ogni interfaccia. I pacchetti di Hello vengono inviati sull’ UDP indirizzato a una porta discovery LDP conosciuta per l’indirizzo del gruppo multicast "tutti i router su questa sottorete". Un link LDP Hello inviato da un LSR trasporta l’id dello spazio etichetta che LSR vuole utilizzare per la interfaccia e, eventualmente, ulteriori informazioni. Ricezione di un link LDP Hello individua una “hello adjacency”. Per ogni interfaccia, vi è una “hello adjacency”. Un esteso meccanismo di scoperta può essere utilizzato per LSR non direttamente connessi. Un LSR invia periodicamente degli LDP “targated hellos” a un indirizzo specifico su UDP. La ricezione di un LDP “targated hellos” identifica una “hello adjacency”. Lo scambio link LDP Hello tra due LSR innesca l'istituzione di una sessione LDP. Se vi è un solo legame tra due LSR, allora vengono istituiti una sola “hello adjacency” e una singola sessione LDP. Se ci sono dei link paralleli con spazio d’etichetta per piattaforma, allora ci sono tante “hello adjacency” quanto il numero di link, ma solo una sessione LDP. Se ci sono collegamenti in parallelo, uno con spazio d’etichetta per piattaforma e gli altri spazio d’etichetta per interfaccia, allora vengono impostate una sessione per interfaccia e una adiacenze per sessione. Per l'esempio in Figura 7.1, sono impostate le seguenti sessioni e “hello adjacency”: • A-B: Una sessione LDP con un “hello adjacency” • A-D: Una sessione LDP con un “hello adjacency” • AC: Una sessione LDP con due “hello adjacency” • AE: Due sessioni di LDP, ciascuna associata ad un “hello adjacency” • AF: Due sessioni di LDP, ciascuna associata ad un “hello adjacency” L'istituzione di una sessione LDP prevede due fasi In primo luogo, viene stabilita una sessione TCP. In secondo luogo, viene inizializzata una sessione LDP, durante la quale i due LSR negoziano i parametri di sessione (come la versione del protocollo, il metodo di distribuzione ecologica, i valori del timer, l’intervallo di VPI / VCI valori per ATM, e la gamma di valori di frame relay DLCI). Un LSR mantiene un timer per ogni “hello adjacency”, che si riavvia ogni volta che riceve un messaggio di Hello. Se il timer scade senza che sia stato ricevuto un messaggio di Hello dal peer LSR , viene soppressa la “hello adjacency”. La sessione LDP è terminata, se vengono soppresse tutte le “hello adjacency” associate ad una sessione LDP. Un LSR mantiene un timer keepalive per ogni sessione. Il timer viene azzerato ogni volta che riceve un PDU(Packet Data Unit) di tipo LSP dal suo peer LDP. Se il peer LDP non ha nulla da trasmettere, invia un messaggio di keepalive. 7.1.2 FORMATO DEL PDU di tipo LPD Un PDU LDP consiste di un header LDP seguito da uno o più messaggi LDP che potrebbero non essere collegati gli uni agli altri. Il formato LDP PDU è mostrato in Figura 7.2. Il LDP header consiste di campi: • Versione: un campo a 16 bit che contiene la versione del protocollo. • Lunghezza PDU: un campo a 16 bit che dà la lunghezza totale del LDP PDU in byte, esclusi la versione e i campi lunghezza PDU dell'header LDP PDU. • LDP id: Un campo di 48 bit che contiene l'id dell’ LDP (cioè, l'id dello spazio etichetta), che ha la forma ‹32-bit id router, numero dello spazio etichetta›. Il formato del messaggio LDP è costituito da un'intestazione seguita da parametri obbligatori e facoltativi. L'intestazione e i parametri sono tutti codificati utilizzando lo schema “type-length-value” (TLV) mostrato nella Figura 7.3. Sono stati definiti i seguenti campi: • U (Unkwown bit TLV): Utilizzato quando viene ricevuto un ignoto TLV. Se U = 0,viene restituita un notifica al mittente del messaggio e l'intero messaggio viene ignorato. Se U = 1, allora il TLV viene silenziosamente ignorato e il resto del messaggio viene elaborato come se il TLV non esistesse. • F (Forward Unkwown bit TLV): questo bit si applica solo quando U = 1, e deve essere trasmesso il messaggio LDP contenente l'ignoto TLV. Se F = 0, l'ignoto TLV non viene trasmesso con il resto del messaggio. Se F = 1, l'ignoto TLV viene trasmesso con il resto del messaggio. • Tipo: un campo a 14 bit che descrive come deve essere interpretato il campo valore. • Lunghezza: un campo a 16 bit che fornisce la lunghezza del campo valore in byte. • Valore: contiene informazioni che sono interpretate come specificato nel campo Tipo. Potrebbe contenere esso stesso la codificaTLV. 7.1.3 FORMATO DEL MESSAGGIO LPD Il formato del messaggio LDP è mostrato nella Figura 7.4. Sono stati definiti i seguenti campi: • U (Unkwown message bit): Alla ricezione di un messaggio di sconosciuto, se U = 0, viene restituita una notificaval mittente del messaggio. Se U = 1, il messaggio sconosciuto viene silenziosamente ignorato. • Tipo di messaggio: un campo a 15 bit che viene utilizzato per identificare il tipo di messaggio. • Lunghezza dei messaggi: un campo a 16 bit che fornisce la lunghezza totale (in bytes) del campo messaggio ID e i campi dei parametri obbligatori e facoltativi. • Messaggio ID: un valore a 32 bit utilizzato per identificare questo messaggio. I messaggi successivi a questo devono trasportare lo stesso messaggio ID. I campi obbligatori verranno discussi separatamente per ogni singolo messaggio LDP. 7.1.4 I MESSAGGI LPD Sono stati definiti i seguenti messaggi di LDP: notification, hello, initialization, keepAlive, address, address withdraw (ritirare), label mapping, label request, label abort request, label withdraw e label release. MESSAGGIO DI NOTIFICA Questo messaggio è usato per informare un peer LDP di un errore fatale, o per fornire informazioni di consulenza sui risultati del trattamento di un messaggio LDP o dello stato di una sessione LDP. Alcuni dei messaggi di notifica sono i seguenti: • PDU o messaggio “Malformed” • Unkwown o “Malformed” TLV • Scadenza del timer della sessione keepalive • Spegnimento della sessione unilaterale • Eventi di inizializzazione di un messaggio • Eventi derivanti da altri errori MESSAGGIO HELLO I messaggi LDP Hello vengono scambiati come parte del meccanismo di scoperta LDP. Il formato del messaggio Hello è mostrato nella Figura 7.4, con il bit U pari a 0 e il tipo di messaggio impostato su hello (0x0100). Il campo dei parametri obbligatori, chiamato “the common hello parameters TLV”, è mostrato nella Figura 7.5. MESSAGGIO LABEL REQUEST Un LSR invia un messaggio di label request a un peer LPD per richiedere una mappatura a particolari FEC. Il messaggio di label request ha il formato mostrato nella Figura 7.4, con il bit U pari a 0 e il tipo di messaggio impostato su label request (0x0401). Il campo parametri obbligatori contiene il TLV FEC mostrato nella Figura 7.7. Un LSR può trasmettere un messaggio di label request alle seguenti condizioni: • l’ LSR riconosce un nuovo FEC attraverso la sua tabella di routing forwarding, il salto successivo è un peer LDP, e la LSR non dispone già di una mappatura del salto successivo per il dato FEC. • Il salto successivo alle modifiche FEC, e la LSR non dispone già di una mappatura da il salto successivo per il dato FEC. • La LSR riceve una label request per un FEC da un peer LDP upstream, il salto successivo del FEC è un peer LDP e l’LSR non dispone già di una mappatura del salto successivo. MESSAGGI LABEL ABORT, LABEL WITHDRAW E LABEL RELEASE Un LSR A può inviare un messaggio label abort a un peer LDP LSR B per interrompere un messaggio label request in sospeso. Ciò può accadere, ad esempio, se il salto successivo dell’LSR A per il FEC è cambiato dall’ LSR B a un LSR diverso. Un LSR A utilizza un messaggio label withdraw per segnalare ad un peer LDP LSR B che non può continuare a utilizzare uno specifico mapping FEC-label che LSR A aveva precedentemente annunciato. Un LSR A invia un messaggio di label release a un peer LDP LSR B per segnalare all’ LSR B che l’ LSR A non necessita più di uno specifico FEC-label che precedentemente era stato richiesto e / o pubblicizzati dal peer. 7.2 THE CONSTRAINED-BASED ROUTING LABEL DISTRIBUTION PROTOCOL (CR-LDP) CR-LDP è un protocollo di distribuzione “label” basato su LDP. Come descritto in precedenza, LDP può essere utilizzato per istituire un LSP associato ad una particolare FEC. CR-LDP viene utilizzato per creare un point-to-ponit unidirezionale esplicitamente indirizzati LSP, denominato “constrained-based routed label switched path” (CR-LSP). Un LSP è istituito a seguito delle informazioni di routing in una rete IP utilizzando l’algoritmo a percorso più breve. Un CR-LSP è calcolato alla sorgente LSR basata sui criteri non limitati alle informazioni di routing, come ad esempio il routing esplicito e il routing basato sul QoS. La rotta viene poi segnalata agli altri nodi lungo il percorso che obbedisce alle istruzioni di routing della fonte. Questa tecnica di routing, chiamata “source routing”, è utilizzato anche in ATM. UN CR-LSP in MPLS è analogo a una connessione in ATM, solo che è unidirezionale. La procedura di segnalazione ATM imposterà automaticamente una connessione bidirezionale tra i due host ATM, dove ogni direzione della connessione può essere associato a diversi parametri di traffico e di QoS. Un CR-LSP bidirezionale tra LSR 1 e 2 può essere creato attraverso l’instaurazione di un CR-LSP da LSR 1 a LSR 2 e un altro da LSR 2 a LSR 1. Come nel caso di un LSP, un CR-LSP ha un ingresso ed una uscita LSR. CR-LSP può essere utilizzato in una varietà di modi. Per esempio, essi possono essere utilizzati in una rete IP per fare il bilanciamento del carico. Cioè, il traffico tra i suoi link può essere distribuito uniformemente forzando una parte del traffico sui CR- LSP che passano attraverso collegamenti meno utilizzati. CR-LSP può anche essere usato per creare tunnel in MPLS, e introdurre percorsi basati sul criterio QoS, come la minimizzazione del ritardo totale end-to-end, e la massimizzazione del throughput. Ad esempio, consideriamo la rete MPLS in Figura 7.9, e supponiamo che il percorso tra l'ingresso LSR A e l’uscita LSR G, calcolato utilizzando OSPF, passa per E e F. Usando CR-LDP siamo in grado di creare un CR-LSP che soddisfa un criterio di QoS, come ridurre al minimo il ritardo end-to-end. Per esempio, se LSR B, C, e D non sono molto utilizzati, indirizzando il CR-LSP attraverso questi LSR ridurrà il ritardo end-to-end, anche se il numero di salti sarà superiore al percorso E-F. Le seguenti sono alcune delle caratteristiche di CR-LDP: • CR-LDP è basato su LDP e si esegue all'inizio del TCP per l'affidabilità. • Lo stato della macchina CR-LDP non richiede rinfresco periodico. • CR-LDP permette percorsi espliciti rigorosi e liberi. Questo consente all'ingresso LSR qualche grado di conoscenza imperfetta sulla topologia di rete (si veda la Sezione 6.2.3). La fonte LSR può altresì chiedere un “route pinning”, che fissa il percorso attraverso una rotta definita scorrevolmente(o vagamente) in modo che non cambia quando sarà disponibile un miglior “next hop”. • CR-LDP permette il possesso del percorso tramite la priorità di assegnazione delle priorità di setup/partecipazione ai CR-LSP. Se non si riesce a trovare una rotta per un CR-LSP ad alta priorità, gli esistenti CR-LSP con priorità inferiore possono essere deviati per consentire la costituzione di quelli a priorità più alta. • L'operatore di rete può classificare le risorse di rete in vari modi. CR-LDP permette l'indicazione delle classi di risorse che possono essere utilizzate quando viene stabilito un CR-LSP. • Come nel caso dell’ATM, CR-LDP permette la specificazione dei parametri di traffico su una CR-LSP e di come questi parametri devono essere controllati. CR-LDP dipende dalle seguenti funzionalità LDP minime: • Meccanismo di scoperta base e/o esteso • Messaggio di label request per downstream on demand con controllo logico • Messaggio di label mapping per downstream on demand con controllo logico • Messaggi di notifica • Messaggi di label withdraw e release • Rilevamento Loop per segmenti di vagamente instradati 7.2.1 PROCEDURA DI SETUP DI UNA CR-LSP Un CR-LSP viene configurato con l'assegnazione on demand in downstream con controllo ordinato. Ricordiamo che nello schema d’assegnazione on demand in downstream, ogni LSR lega una label in arrivo ad una FEC e crea una entry adeguata nel suo LFIB. Tuttavia, non pubblicizza la sua “label mapping” ai suoi vicini, come nello schema d’assegnazione in downstream spontaneo. Invece, un upstream LSR ottiene la “label mapping” mediante l'emissione di una richiesta. Nello schema di controllo ordinato, l'assegnazione di etichette procede all’indietro, dall’uscita LSR verso l'ingresso LSR. In particolare, un LSR lega una label ad una FEC solo se è l’uscita per quel FEC, o se ha già ricevuto una etichetta obbligatoria (binding) per quel FEC dal suo “next hop” LSR. Un esempio di come un CR-LSP è impostato è mostrato nella Figura 7.10. Supponiamo che un LSR A è stato richiesto per istituire un CR-LSP verso LSR E. La richiesta di istituire un CR-LSP verso LSR E potrebbe essere originario di un sistema di gestione o di un'applicazione. LSR A calcola il percorso esplicito utilizzando le informazioni fornite dal sistema di gestione, o dall'applicazione, o da una tabella di routing, e crea il messaggio di label request. Il percorso esplicito in questo caso è dato dalla serie di LSR B, C, e D. Esso è trasportato in una speciale TLV nel messaggio di label request chiamata “explicit route TLV” (ER-TLV). L'ingresso LSR A invia il messaggio di label request a LSR B, il primo LSR indicato nel TLV-ER, richiedendo una label mapping per la FEC associata alla CR-LSP. A causa del sistema di controllo ordinato, LSR B non può creare una label mapping per il FEC fino a quando non ha ricevuto una label mapping dal suo next hop LSR C. Inoltre, a causa dello schema d’assegnazione on demand in downstream, LSR C non pubblicizzare la sua label mapping ai suoi vicini. In considerazione di ciò, LSR B inoltra il messaggio di label request a LSR C richiedendo una label mapping per la FEC. LSR C inoltra la label mapping request per le stesse ragioni a LSR D, che poi inoltra il messaggio di label request all’uscita LSR E. All'uscita LSR E ora è consentito di creare una label mapping per la FEC. Fa questo e risponde al messaggio di label request di LSR D con un messaggio di label mapping che contiene l'etichetta assegnata. Quando LSR D riceve il messaggio di label mapping da LSR E, risponde al messaggio di label request di LSR C con un messaggio di label mapping che contiene la propria etichetta in entrata, e così via, fino a che LSR A riceve un messaggio di label mapping da LSR B. A quel tempo, la CR-LSP è stato istituito. In quel che segue vengono descritti il messaggio di label request e il messaggio di label mapping. 7.2.2 IL MESSAGGIO DI LABEL REQUEST Il messaggio di label request è mostrato in Figura 7.11. Il bit U è impostato su 0, e il tipo di messaggio impostato su label request (0x0401). Il FEC TLV (vedi Figura 7.7) deve essere incluso nel messaggio label request, e contiene un unico nuovo elemento FEC, denominato CR-LSP. E’ richiesto l’LSPID TLV e viene usato per dare un univoco identificatore di un CR-LSP. Esso è composto Il “type” dei parametri di traffico TLV è 0x0810,e la lunghezza del campo “value” è di 24 byte. Sono stati definiti i seguenti campi: flags, frequency, weight, peak data rate (PDR), peak burst size (PBS), committed data rate (CDR) , committed burst size (CBS) and excess burst size (EBS). I parametri PDR e PBS sono utilizzati per definire il traffico inviato al CR-LSP. I parametri di CDR, CBS, e EBS, sono utilizzati per specificare come la rete controllerà il traffico presentato al CD-LSP. Infine, i campi flags, frequency e weight sono usati per fornire ulteriori Informazioni come si vedrà di seguito. PEAK DATA RATE(PDR) E PEAK BURST SIZE(PBS) Il peak rate è il massimo rate con cui il traffico viene mandato al CR-LDP, ed è espresso in bytes/sec. Il parametro equivalente in ATM è il “peak cell rate”(PCR).A differenza del PCR, che è specificato da un unico valore, il peak rate in CR-LDP è specificato in termini di token bucket P. La dimensione massima di token bucket di P è uguale al “peak bursts size” (PBS), espresso in byte, e il token bucket è riempito al “”peak data rate”(PDR), espressa in byte / sec. La PBS definisce la dimensione massima dei pacchetti che possono essere inviati al CR-LSP, e il PDR dà il rate massimo al quale il traffico viene trasmesso dall'utente. Il peak rate è l'uscita dal token bucket P, che viene inviato al CR-LSP. Il token bucket funziona come segue: • Inizialmente, il numero di token (cioè il numero di token nel token bucket) è Tp = PBS. • PDR = N byte / sec. Se Tp ≤ PBS, il numero di token TP viene incrementato ogni N secondi (non deve superare PBS). • Quando arriva un pacchetto di B byte, se Tp - B ≥ 0 il pacchetto non eccede il peak rate e Tp = Tp - B. • In caso contrario, se è superiore al peak rate Tp non viene ridotta. Il pacchetto è un ”violating packet” e può essere contrassegnato o scartato. Si noti che un valore positivo di una delle infinite PBS o MBS implica che i pacchetti in arrivo non sono mai in eccesso rispetto alla velocità di picco. Un esempio del peak rate dell’operazione token bucket è dato in Figura 7.16. La linea spessa in alto indica il valore di TP e la linea sottile sotto indica l'arrivo di un pacchetto. La pendenza di tutte le linee è pari a PDR. Al tempo t = 0, il token bucket contiene i tokens PBS. Il pacchetto 1 inizia ad arrivare alla velocità di PDR byte / sec. Quando è arrivato del tutto, la dimensione del pacchetto in byte viene detratta dall’attuale numero di token TP, il pacchetto è autorizzato a passare e la ricostituzione del token bucket inizia alla velocità di PDR byte / sec. Il pacchetto 2 comincia ad arrivare subito dopo pacchetto 1. Poiché le dimensioni del pacchetto 2 sono inferiori all’attuale numero token, gli è consentito passare. In generale, tutti i pacchetti passeranno finché l'utente trasmette a un tasso che è inferiore o uguale a PDR. Consideriamo il caso in cui la velocità di trasmissione dell’utente supera temporaneamente PDR (vedi Figura 7.17). Le linee tratteggiate indicano la velocità di trasmissione di un pacchetto se la fonte l’ha trasmesso al rate del PDR. Le linee sottili continue (sopra le linee tratteggiate) indicano il rate al quale vengono trasmessi i pacchetti, e la linea spessa nella parte superiore del diagramma mostra il numero corrente di token. Si noti che il pacchetto 1, anche se arriva più velocemente di quanto dovrebbe, passa. Il conteggio dei token è ridotto in modo appropriato, e comincia la ricostituzione del token bucket al rate PDR. Il pacchetto 2 non è così fortunato, e sarà o marcato e lasciato nella rete o scartato. Il pacchetto 3 passa. Pertanto, se la velocità di trasmissione è temporaneamente superiore a PDR, è possibile che alcuni dei pacchetti passeranno, come nel caso dello schema di GCRA in ATM. D'altra parte, se l'utente tenta di trasmettere un pacchetto la cui dimensione è maggiore di MBS, questo pacchetto sarà immediatamente classificato come “violating”, in quanto il token bucket non può mai contenere più token di PBS. COMMETTED DATA RATE (CDR), COMMITTED BURST SIZE (CBS) E EXCESS BURST SIZE (EBS) Il traffico che viene inviato alla rete, che è l'uscita del token bucce P, viene controllato usando il token bucket C, denominato “committed token bucket”. La dimensione massima di C token bucket è impostata uguale alla “committed burst size” (CBS), espresso in byte, e il token bucket è riempito al tasso “committed data rate” (CDR), espresso in byte / sec. L'output di questo token bucket è chiamato “committed rate” ed è la somma della larghezza di banda che la rete dovrebbe assegnare per il CR-LSP. Oltre al C, è possibile utilizzare un secondo token bucket di controllo (policing) E, denominato “excess token bucket”(EBS). La dimensione massima di questo token bucket è pari a EBS, espresso in byte, e il token bucket è riempito con un rate pari a CDR, espresso in byte / sec. Come si vedrà in seguito, questo token bucket può essere usato per decidere se un “violating packet” deve essere contrassegnato e lasciato in rete o essere eliminato. Il funzionamento dei token bucket “commmitted” e “excess” è il seguente: • Inizialmente, il numero di token nel “committed token bucket” Tc = CBS, e il numero di token nell’ ”excess token bucket” Te = EBS. • Successivamente, Tc e Te sono aggiornati ogni secondo come segue: ◦ Se Tc <CBS, Te viene incrementato di M byte (non dovrebbe superare CBS). ◦ Se Te <EBS, Te viene incrementato di M byte (non dovrebbe superare EBS) dove CDR = M byte / sec. • L'azione seguente viene presa quando arriva un pacchetto di dimensione B: ◦ Se Tc - B ≥ 0, ci sono abbastanza token nel “committed token bucket” per il pacchetto, e Tc = Tc - B. ◦ Se Tc-B <0 e Te - B ≥ 0, allora non ci sono abbastanza gettoni nel “committed token bucket”, ma ci sono abbastanza gettoni nell’ “excess token bucket” e Te = Te - B. ◦ Se Tc-B <0 e Te-B <0, allora non ci sono abbastanza gettoni nel “committed token bucket” o nell’ “excess token bucket”, e Te e Tc non sono decrementati. Si noti che se il CDR è infinito positivo, quindi un pacchetto in arrivo non sarà mai superiore del numero di uno dei token bucket. L'azione intrapresa quando la dimensione di un pacchetto supera il numero di token nel token bucket (o committed o excess) è l'implementazione dipendente. Per esempio, se la dimensione del pacchetto è più grande del numero di token nel “committed token bucket”, ma meno del numero di token nell’ “excess token bucket”, potremmo scegliere segnarlo e lasciarlo nella rete. Se la dimensione del pacchetto è più grande di entrambi i conteggi di token, allora potremmo scegliere di perderlo (drop). Un esempio di come questi due schemi di gestione (policing) vengono utilizzati è mostrata in Figura 7.18. Il disegno in alto si riferisce all’ ”excess token bucket”, e quello inferiore per “committed token bucket”. Le regole descritte nel paragrafo precedente per le applicazioni di “marking” e “dropping”. Tutti i quattro pacchetti arrivano a rate superiori a CDR. Come possiamo vedere, i pacchetti 1 e 3 passano. Il pacchetto 2 arriva in un momento in cui il “committed token bucket” non ha abbastanza gettoni, ma ci sono abbastanza gettoni nell’ ”excess token bucket” . Come risultato, il numero di token Tc resta invariato, il numero di token Te è ridotto della dimensione del pacchetto 2, e il pacchetto 2 è segnato (marked) e lasciato in rete. I pacchetti 4 e 5 vengono ignorati, dal momento che arrivano in un momento quando nessuno dei “token bucket” ha abbastanza token. In entrambi i casi il numero di token Tc e Te sono immutati. I cinque parametri di traffico - PDR, PBS, CDR, CBS, e EBS - possono essere impostati per diversi valori in modo da creare diverse classi di servizio, come un servizio sensibile al ritardo e un servizio best effort. Essi possono anche essere impostati per fornire diverse categorie di servizi ATM. Esempi di come questi cinque parametri possono essere impostati in modo da fornire diverse classi di i servizi sono riportati alla sezione 7.2.5. Come accennato in precedenza, l'uscita del “committed token bucket” è il traffico che entrerà nella rete. Un algoritmo di allocazione di banda può essere usato in ogni LSR per decidere se il nuovo CR-LSP sarà accettata o meno. Come in ATM, possono essere usati schemi differenti per calcolare quanta banda deve essere assegnata al CR-LSP. Il più semplice schema prevede di assegnare una banda pari a CDR. Questo è equivalente allo schema di assegnazione di “peak rate” in ATM. In “intserv”, il mittente specifica quanto traffico sarà trasmesso al suo ricevitore(i), e un ricevitore specifica quanto traffico può ricevere e il QoS richiesto, espresso in termini di pacchetti persi e ritardo end-to-end. Questa informazione permette ad ogni router IP lungo il percorso seguito dai pacchetti del mittente, di eseguire le seguenti funzioni: 1. “Policing”(sorveglianza?): Esso è usato per verificare che il traffico trasmesso dal mittente osservi il sender’s Tspec, un set di rappresentatori di traffico che caratterizza il traffico trasmesso dal mittente. 2. “Admission controll”: Esso è usato per decidere se un router IP ha risorse adeguate a quelle richieste dal QoS. 3. “Classification”: Esso è usato per decidere quali pacchetti IP dovrebbero essere considerati come parte del traffico del mittente e forniscono il QoS richiesto. 4. “Queueing and scheduling”(Code e pianificazione/programmazione?): Affinchè un router IP fornisca differenti QoS a diversi ricevitori, esso deve essere capace di mettere in coda pacchetti in diverse code e trasmettere pacchetti fuori da queste code in accordo con la programmazione. L’architettura “intserv” richiede un protocollo di segnalazione per la costituzione affidabile e il mantenimento delle prenotazione di risorse. Come nel MPLS, intserv non richiede l’uso di uno specifico protocollo di segnalazione, e può adattarsi ad una varietà di protocolli di segnalazione, tra cui l’RSVP è il più popolare. RSVP è stato sviluppato per supportare l’architettura intserv, ma può essere usato per trasportare altri tipi di informazioni di controllo. Questo è perché RSVP non è consapevole del contenuto dei campi del protocollo RSVP che contiene informazioni su traffico e controllo usate dai router come risorse di riserva . RSVP può essere usato per fare prenotazioni di risorse sia per applicazioni unicast che per applicazioni many-to-many multicast. RSVP è stato creato con lo scopo di supportare le conferenze multiparty, i.e., many-to-many, con svariati ricevitori. In RSVP, la prenotazione di risorse è decisa e iniziata da un ricevitore, dal momento che solo il ricevitore può al momento sapere di quanta banda ha bisogno. Questo approccio permette anche ad un ricevitore di unirsi o lasciare un multicast quando esso vuole. Un problema con l’approccio “receiver-initiated” è che il ricevitore non sa il percorso dal mittente a sé stesso. Quindi, non può richiedere allocazioni di risorse su ciascun router lungo il percorso dal momento che non sa quali sono questi router. Questo problema è risolto usando il “Path message”(messaggio di percorso) che parte dal mittente e attraverso il percorso unicast o multicast arriva al ricevitore. Il principale obiettivo del “Path message” è di conservare il “path state information”(informazione di stato di percorso) in ogni nodo lungo il percorso e trasportare informazioni riguardanti le caratteristiche del traffico del mittente e le proprietà del percorso end-to-end. Qui di seguito riportiamo parte dell’informazione contenuta nel “Path message”:  “Phop”: Questo è l’indirizzo del precedente hop router RSVP-capable(?) che inoltra il messaggio. Questo indirizzo è memorizzato nel “path state information” ad ogni nodo ed è usato per inviare un messaggio di prenotazione (di riserva?) verso il mittente.  “Sender template”(modello mittente?): Questo campo trasporta l’indirizzo IP del mittente e opzionalmente la porta UDP/TCP del mittente.  “Sender TSpec”: Questo definisce le caratteristiche di traffico del data flow(flusso di dati) che il mittente genererà. Il formato sender Tspec, che è usato per l’architettura intserv, sarà descritto sotto.  “Adspec”: Questo trasporta l’informazione “one-pass with advertising”(OPWA) (mono-passaggio con annuncio?). Questa è l’informazione(annuncio) raccolta ad ogni nodo lungo il percorso seguito dal “Path message”.Questa informazione è consegnata al ricevitore, il quale può usarla poi per costruire una nuova richiesta di prenotazione o per modificare una prenotazione esistente. Ricevuto il “Path message”, il ricevitore invia un “Resv message” indietro al mittente lungo il percorso opposto a quello seguito dal “Path message” (figura 7.19). Di seguito ecco parte dell’informazione contenuta nel “Resv message”:  “Flowspec”: Specifica il QoS desiderato. Esso è costituito dal “Tspec”, l’ “Rspec” e il “service class”. Il ricevitore “TSpec” è un set di descrittori(rappresentatori) di traffico che è usato dai nodi lungo il percorso per prenotare risorse. L’ ”RSpec” definisce la banda desiderata e le garanzie di ritardo. Quando RSVP è usato nell’intserv, il “service class” può essere o “guaranteed service”(servizio garantito) o “controllore-load service”(servizio a carico controllato). Il formato per il ricevitore TSpec e RSpec usato nell’architettura intserv è descritto qui sotto.  “Filter spec”: Definisce i pacchetti che riceveranno il QoS richiesto che è stato definito nel “flowspec”. Un semplice filter spec(specifica di filtro?) potrebbe essere soltanto l’indirizzo IP del mittente e opzionalmente la sua porta UDP o TCP. Quando un router riceve il messaggio “Resv”, riserva(prenota) risorse per le istruzioni del ricevitore e poi invia il messaggio Resv all’hop router precedente ottenuto dall’informazione di path state(stato del percorso). I messaggi RSVP sono inviati in datagrammi IP grezzi senza un incapsulamento TCP o UDP.(l’incapsulamento UDP è permesso ai router che non supportano datagrammi IP grezzi). RSVP fa uso di nozioni di “data flow” e “session”. Una session (sessione) è definita da dei parametri: indirizzo IP di destinazione, protocollo id, e opzionalmente il numero di porta di destinazione. Un data flow è semplicemente l’insieme dei pacchetti trasmessi da un mittente in una particolare sessione. RSVP è simplex; cioè crea prenotazioni solo per data flow unidirezionali. Quindi, affinchè due utenti A e B comunichino in entrambi i versi, devono essere stabilite due sessioni separate; una sessione da A a B, e una da B ad A. 7.3.1 RESERVATION STYLES ( MODELLI(STILI) DI PRENOTAZIONE) Con RSVP possono essere usati Tre differenti reservation styles, per esempio gli schemi(sistemi). Per capire questi sistemi, consideriamo il caso in cui un numero di mittenti trasmettono informazioni allo stesso ricevitore. Ogni mittente trasmette il suo data flow di pacchetti in una sessione, che è definita dal protocollo id e dall’indirizzo IP del ricevitore. Un’opzione di prenotazione è implicata con la prenotazione di risorse di queste sessioni. In particolare, assumiamo che molte di questi data flow passino attraverso lo stesso router. Il router ha l’opzione di stabilire una prenotazione separata per ogni data flow o di fare una singola prenotazione per tutti i data flow. Una seconda opzione di prenotazione controlla la selezione dei mittenti. Può essere “explicit” (netto) o “wildcard” (jolly). Nel caso di selezione di mittente explicit, il ricevitore fornisce una lista di mittenti da cui vorrebbe ricevere dati. Un mittente non può inviare pacchetti al ricevitore a meno che il suo indirizzo IP sia nella lista esplicita(explicit). Nel caso do selezione di mittente wildcard, qualche mittente può trasmettere dati al ricevitore. Basati su queste due opzioni, sono stati definiti i tre differenti styles(modelli) seguenti: 1. Wildcard-filter (WF) style: Qualche mittente può trasmettere alla sessione. C’è una singola prenotazione di risorse condivisa da tutti i data flow provenienti da tutti i mittenti a monte. La prenotazione di risorse è la più grande di tutte le prenotazioni. 2. Fixed-filter (FF) style: Una prenotazione separata è creata per ogni particolare mittente che è specificato nella lista esplicita di mittenti. Altri mittenti identificati nella lista esplicita che trasmettono nella stessa sessione non condividono questa prenotazione. 3. Shared explicit (SE) style: Una lista di mittenti è determinata esplicitamente, e c’è una singola prenotazione condivisa per tutti i loro flow. 7.3.2 SOFT STATE RSVP assume un approccio soft state per riuscire a specificare la prenotazione nei router e negli host. Cioè, l’informazione di stato(state information) in ogni router e host deve essere periodicamente aggiornata da messaggi Path e Resv. Lo stato di una prenotazione è cancellato se non arrivano messaggi di refresh(aggiornamento) di coordinamento prima di un intervallo di timeout di “cleanup”(timeout di pulitura). Lo stato può anche essere cancellato da un messaggio esplicito di “teardown” (rottura, demolizione). Quando un percorso cambia, il successivo messaggio di Path inizializzerà il “path state” sui router lungo il nuovo percorso e il messaggio Resv stabilirà una prenotazione su ognuno di questi router. Lo stato di un percorso non usato andrà in time out. RSVP invia i suoi messaggi come datagrammi IP senza garanzia che essi saranno consegnati. Un messaggio RSVP può non essere mai consegnato a causa di errori di trasmissione o di buffer overflow. Questa situazione è salvaguardata dai periodici messaggi di refresh. Inviare messaggi di refresh incrementa però il carico di una rete, ma elimina il bisogno di usare un protocollo affidabile(sicuro) come il TCP, il quale garantisce la consegna sicura di messaggi RSVP. 7.4 IL RESOURCE RESERVATION PROTOCOL – TRAFFIC ENGINEERING (RSVP-TE) Il re source reservation protocol – traffic engineering (RSVP-TE) è un’estensione del re source reservation protocol (RSVP), descritto sopra. L’ RSVP-TE può essere usato nell’ MPLS per costruire LSPs usando o l’informazione del next hop nella tabela di routing o un percorso esplicito. Mantenendo la terminologia usata nell’ RSVP-TE (che di fatto è la stessa del RSVP) useremo i termini nodo, mittente e ricevitore per indicare rispettivamente un LSR, un LSR di ingresso e un LSR di uscita. Ricordiamo che, nell’RSVP, una sessione è un data flow con un particolare indirizzo IP di destinazione e protocollo id. Nell RSVP-TE, una sessione è un LSP. L’RSVP-TE usa un’allocazione di etichetta downstream-on-demand per costruire un LSP. Questo è implementato usando i messaggi Path e Resv che sono stati incrementati con nuovi oggetti. Un LSP può essere costruito usando l’informazione del next hop nella tabella di routing. Inoltre, l’RSVP-TE può costruire LSPs inoltrati esplicitamente. Questo è fatto usando un nuovo oggetto – EXPLICIT_ROUTE – per incapsulare gli hop che creano un percorso esplicito. Ogni hop nel percorso può essere un nodo individuale o un nodo astratto. Un nodo astratto è un gruppo di nodi la cui topologia interna è sconosciuta al mittente. Attraverso un nodo astratto è permesso sia un routing rigido che libero. Per costruire un LSP, il nodo di ingresso invia un Path message con un oggetto LABEL REQUEST. Questo è un nuovo oggetto e indica che è richiesto che si unisca un’etichetta per il percorso. 11. ACCESS NETWORKS Una rete di accesso è una rete a commutazione di pacchetto che fornisce la connettività Internet ad alta velocità a casa. Si prevede che le reti di accesso forniranno anche servizi aggiuntivi, come il Voice over IP o ATM e video on demand. Le reti di accesso hanno caratteristiche e requirements diversi rispetto a reti LAN, MAN e WAN. Attualmente, ci sono due reti di accesso diverse in atto, una è fornita tramite la linea telefonica e l'altra tramite il cavo TV. Nuove reti di accesso, come ATM passive optical network (APON), e le reti di accesso basate su Ethernet e wireless-based stanno cominciando ad emergere. Gli operatori telefonici forniscono accesso ad alta velocità a Internet tramite la linea telefonica in aggiunta ai servizi telefonici di base. Video on demand e voice over IP o ATM saranno inoltre previsti in futuro. Una famiglia di modem conosciuto come X-Type Digital Subscriber Line (xDSL) è stata sviluppata per fornire un accesso ad alta velocità a Internet tramite la linea telefonica. Dei modem xDSL, DSL asimmetrica (ADSL) è la più popolare. Gli operatori via cavo forniscono accesso a Internet tramite la rete via cavo, oltre alla distribuzione di canali TV. Inoltre, voice over IP e servizi di video on demand su cavo sono state introdotte di recente. La rete di accesso cavo-based utilizza il servizio data-over-cable service interface specification (DOCSIS). APON è un'alternativa conveniente per reti di accesso telephone-based e cavo-based. Un APON utilizza una rete ottica di distribuzione, che consiste di fibre ottiche e splitter passivi. Può essere usata per fornire connessione internet ad alta velocità, voice over IP, Voice over ATM e servizi di video on demand. In questo capitolo si descrive la rete di accesso ADSL, la rete di accesso cavo-based, e la APON. La rete di accesso ADSL-based e le APON sono state progettate per supportare ATM e di conseguenza sono reti orientate alla connessione. La rete di accesso cavo-based supporta la rete IP. Anche se la rete di accesso cavo-based non è orientato alla connessione, è stato incluso in questo capitolo, a causa della sua importanza nel mercato delle reti di accesso. 11.1 THE RETI DI ACCESSO BASATE SU ADSL ADSL è una delle tecnologie di accesso che possono essere utilizzate per convertire la linea telefonica in un collegamento ad alta velocità digitale. Fa parte di una famiglia di tecnologie denominata x-type digital subscriber line (xDSL), dove x sta per una delle varie lettere dell'alfabeto e indica una tecnica diversa di trasmissione. Esempi di tecnologie xDSL famiglia sono: asymmetric DSL (ADSL), high data rate DSL (HDSL), symmetric DSL (SDSL), ISDN DSL (IDSL), and very high data rate DSL (VDSL). Alcune delle tecnologie xDSL utilizzano metodi analogici di segnalazione per il trasporto di informazioni analogiche o digitali su doppino telefonico (twisted pair), mentre altri usano una vera e propria segnalazione digitale per il trasporto di informazioni digitali. Una lista di specifiche per le tecnologie xDSL è indicata nella tabella 11.1. Nelle reti di accesso, downstream significa dalla rete all'utente, upstream dall'utente alla rete. Queste specifiche sono suscettibili di evoluzione come la tecnologia si evolve. VDSL, come suggerisce il nome, raggiunge velocità di trasferimento dati molto elevata sul doppino telefonico. Tuttavia, la distanza a cui tali rate possono essere trasportati è limitata. Attualmente, si può raggiungere un data rate in downstream di 52 Mbps e un data rate di 6 Mbps su una distanza fino a 1000 metri. Per la stessa distanza, si può anche fornire rate simmetrici di 26 Mbps sia in up che in downstream. La più lunga distanza, a cui è possibile trasportare, è attualmente di 5000 piedi per i quali si può raggiungere 13 Mbps downstream e 1,6 Mbps upstream. VDSL può essere utilizzato per fornire video di alta qualità nonché l'accesso a Internet e servizi telefonici regolari. A causa della limitazione di distanza, è previsto che sarà utilizzato per fornire le informazioni da una console in strada, che è collegata a un APON. ADSL utilizza la tecnologia twisted pair esistente, dall'ufficio centrale a casa, per trasportare i dati in aggiunta ai servizi telefonici di base. È stato originariamente progettato per fornire servizi di video on demand trasportato su link switched DS1 o E1. A questo tipo di traffico si fa riferimento nello standard ADSL come synchronous transfer mode traffic (STM). Nella sua attuale standard (ITU-T G.992.1) full rate ADSL è stato definito per trasportare sia il traffico ATM o STM o entrambi. ADSL è utilizzato principalmente per il traffico ATM, e c'è un numero limitato di applicazioni per il traffico STM. Come suggerisce il nome, ADSL fornisce data reti asimmetrici con rate downstream nettamente superiori rispetto ai rate upstream. La velocità dei dati dipende dalla lunghezza del doppino, il calibro (gauge) del filo, la presenza di rubinetti a ponte (bridged taps), e l'interferenza cross-couple. Ignorando i bridged taps, ADSL attualmente è in grado di fornire un segnale downstream (full) DS1 o E1 su un singolo doppino con 24 gauge per una distanza massima di 18.000 piedi. Fino a 6,1 Mbps è possibile per una distanza massima di 12.000 piedi, e 8,128 Mbps per una distanza massima di 9000 piedi. I data rate upstream sono attualmente compresi tra 64 Kbps e 800 Kbps. La velocità di trasmissione dati ADSL sono stati migliorati, con due nuovi standard: ADSL2 e ADSL2 + (si veda la Sezione 11.1.5). Lo sviluppo di ADSL su doppino telefonico, richiede una unità di trasmissione ADSL su ciascuna estremità della linea. L'unità di trasmissione ADSL presso il cliente viene definita come “ADSL transceiver unit, remote terminal” (ATU-R) e l'unità di trasmissione ADSL presso l'ufficio centrale è denominato ADSL “transceiver unit, central office” (ATU-C). Il segnale trasmesso attraverso il doppino telefonico, che contiene sia i dati ADSL sia la voce, si propaga attraverso fili del telefono della casa (vedi Figura 11.1). Il segnale vocale viene filtrato con un filtro passa-alto all'interno del ATU-R. D'altra parte, il segnale ADSL può causare un forte rumore udibile attraverso l'apparecchio telefonico. Pertanto, ogni telefono è collegato a una presa telefonica attraverso un filtro, che filtra il segnale ADSL e al tempo stesso isola eventi di voce, come anello e on/off hook, dal segnale ADSL. L'ATU-R può essere collegato a qualsiasi presa telefonica (telephone plug). Si consideri l’ATU-C, presso l'ufficio centrale. Nella direzione downstream, il segnale vocale viene aggiunto dopo che il segnale ADSL lascia l'ATU-C (vedi Figura 11.2). In direzione upstream, il segnale vocale viene estratto dal segnale ADSL, prima della ATU-C. L'ATU-C genera il segnale ADSL in direzione downstream, e termina il segnale ADSL in direzione upstream. Un certo numero di ATU-Cs sono serviti da multiplexer di accesso ADSL, noto come DSLAM, che fornisce la connettività a reti IP e ATM. Il DSLAM è uno switch ATM. Ha un link OC-3/STM-1 o superiore per una rete backbone di accesso ATM, e ha collegamenti ADSL che servono un certo numero dei clienti. Ogni collegamento ADSL al DSLAM è associato ad un ATU-C, che è il livello fisico associato al link. Passiamo ora a descrivere come opera un ATU-C o un ATU-R. I protocolli utilizzati per fornire servizi IP e ATM su ADSL sono descritti nella sezione 11.1.4. 11.1.1 LA TECNICA “DISCRETE MULTI-TONE” (DMT) La tecnologia Discrete Multi-Tone (DMT) è la tecnica di codifica di linea (standardizzata) utilizzata per l'ADSL. I dispositivi DTM possono facilmente adattarsi al mutare delle condizioni della linea (ad esempio l'umidità o interferenze). Nella tecnica DMT, l'intera larghezza di banda del doppino telefonico è suddivisa in un gran numero di sottocanali equamente distanziati, noti anche come toni. La larghezza di banda disponibile del twisted pair si estende a 1,1 MHz, è diviso in 256 sottocanali, ognuno dei quali occupa 4,3125 KHz. I sottocanali da 1 a 6 sono riservati per la regione Voiceband e sono utilizzati per fornire servizi telefonici di base, o plain old telephone service (POTS) in gergo di rete. ADSL utilizza i sottocanali rimanenti. ADSL è bidirezionale, che significa che sia i dati downstream che i dati upstream sono inviati attraverso lo stesso doppino. In ADSL, la trasmissione bidirezionale sul doppino telefonico può essere implementato usando multiplexing a divisione di frequenza (FDM) o di cancellazione dell'eco. In FDM, ci sono fino a 32 sottocanali upstream che occupano le frequenze immediatamente al di sopra della regione Voiceband. Inoltre, ci sono fino a 218 sottocanali downstream che occupano le frequenze al di sopra dei sottocanali upstream. Una soluzione alternativa è quella di lasciare che il sottocanali up e down utilizzino le stesse frequenze, separandoli usando la tecnica di cancellazione dell'eco. Non tutti i sottocanali sono utilizzati per il trasferimento di informazioni. Alcuni sono utilizzati per la gestione della rete e il monitoraggio delle prestazioni. Tutti i sottocanali sono costantemente monitorati per le prestazioni e gli errori e la velocità di ogni sottocanale o gruppo di sottocanali può effettivamente variare con una granularità di 32 kbps. La trasmissione è ottenuta dividendo il tempo in intervalli di dimensioni fisse. All'interno di ogni intervallo, DMT trasmette un frame di dati che consiste di un numero fisso di bit. I bit in un frame di dati sono suddivisi in gruppi di bit e ogni gruppo viene trasmesso in un sottocanale diverso. Il numero di bit inviati in ogni sottocanale può variare, a seconda del segnale e del livello di rumore in ogni sottocanale. Utilizzando la modulazione di ampiezza in quadratura (QAM), i bit assegnati a ciascun sottocanale vengono convertiti in un numero complesso che viene utilizzato per impostare il sottocanale ampiezza e fase per l'intervallo. I segnali sono sommati e inviati al doppino. Questo segnale risultante da ogni dataframe è noto come simbolo DMT. Un costumer (cliente) “in loco” potrebbe includere una residenza o un ufficio di piccole imprese. In un customer locale ci possono essere uno o più computer collegati tra loro da una rete. La rete di accesso include l'ATU-R presso la sede del cliente, il DSLAM che servono gli ATU-R, e una rete backbone di accesso che interconnette tutti i DSLAM. La connettività ad una NSP e ad un Regional Operations Center (ROC) è fornita attraverso una rete pubblica regionale. In genere, la rete di accesso è gestita da un operatore telefonico, che la controlla tramite un ROC. L'operatore telefonico può essere sia locale (Incumbent Local Exchange Carrier [ILEC]) o nazionale o nuovo arrivato (Competitive Local Exchange Carrier [CLEC]). Nella maggior parte dei casi, gli ATU-R non hanno le funzionalità necessarie per settare SVCs. Invece, PVCs sono utilizzati. Fornire ogni ATU-R con un PVC in ogni NSP richiede un gran numero di PVC per essere settato e gestito. Un approccio più scalabile prevede di fornire un Network Access Server (NAS), come mostrato nella Figura 11.5. Il ruolo dei NAS è di interrompere (terminate) tutti i circuiti PVC da ATU-R e poi aggregare il traffico in una sola connessione per ogni NSP. Gli utenti ADSL creano sessioni per NSP usando il protocollo punto-punto (PPP). Questo protocollo è stato progettato per fornire un metodo standard per il trasporto di pacchetti di protocolli diversi su un collegamento full-duplex. PPP fornisce un numero di funzioni, come l'assegnazione di un indirizzo IP da una rete di destinazione, configurazione automatica del nome di dominio, multiplexing di diversi protocolli di livello di rete, autenticazione, crittografia, compressione, e la fatturazione. I frame PPP sono trasportati utilizzando un incapsulamento HDLC di defalut. Quando PPP si esegue all'inizio del ATM, i frame PPP sono mappati in PDU AAL 5 utilizzando o VC- multiplexed PPP scheme o LLC encapsulated PPP scheme. Nel primo schema, un frame PPP è direttamente trasportato in un PDU AAL 5. Nel secondo, un frame PPP è anche trasportato in una AAL 5 PDU dopo che è stato ulteriormente incapsulato con un header LLC di 2 byte e un identificatore di protocollo del livello rete di 1 byte. THE L2TP ACCESS AGGREGATION SCHEME Questo sistema si basa su Layer 2 Tunneling Protocol (L2TP) di IETF. Gli stack di protocollo coinvolti in questo schema sono illustrati nella Figura 11.6. Per semplicità supponiamo che un utente ADSL ha un singolo computer, invece di una rete di computer interconnessi attraverso una rete ATM. Un utente ADSL è collegato al DSLAM su ADSL, e il DSLAM è collegato ad un NAS, denominato L2TP Access Concentrator (LAC), su una rete ATM. Infine, la LAC è connessa alla L2TP Network Server (LNS) di ciascun NSP di una rete, come IP, Frame Relay e ATM. L'utente ADSL è collegato alla LAC con un PVC ATM attraverso il DSLAM. Questa connessione utilizza AAL 5. La LAC e il LNS di un NSP sono collegati da un tunnel L2TP. Un tunnel L2TP non è un collegamento effettivo, come in una rete orientata alla connessione. Piuttosto, è una connessione logica tra L2TP nel LAC e la sua peer L2TP nel LNS. Una sessione PPP tra l'utente ADSL e il LNS è stabilita come segue. L'utente ADSL invia una richiesta al LAC oltre AAL 5 per avviare una sessione PPP a un LNS. Questa richiesta è trasmessa dal LAC al LNS attraverso un tunnel L2TP. Una volta che la sessione PPP è stabilita, i pacchetti IP possono iniziare a scorrere tra l'utente ADSL e il LNS. Un tunnel tra la LAC e un LNS può multiplexare più sessioni PPP, ciascuno associato a un altro utente ADSL. Inoltre, ci potrebbero essere diverse gallerie tra le LAC e un LNS. L2TP utilizza due tipi di messaggi: messaggi di controllo e messaggi dati. I messaggi di controllo vengono utilizzati per stabilire, mantenere e “pulire” i tunnel e le sessioni PPP su richiesta. I messaggi dati sono utilizzati per trasportare i frame PPP nel tunnel. Il messaggi di controllo e dati sono incapsulati con un'intestazione comune L2TP. Alcuni dei campi in questa intestazione sono: tipo di bit (T), lunghezza della sequenza di bit (L), bit di priorità (P), sequenza di bit (S), la lunghezza, tunnel ID, ID di sessione, numero di sequenza (NS), e numero di sequenza aspettata(Nr). Il campo “tipo di bit” indica se il pacchetto L2TP è un messaggio di controllo o un messaggio di dati. Il campo “lunghezza di bit” indica se il campo di lunghezza è presente. Se è presente, il campo di lunghezza indica la lunghezza totale del pacchetto L2TP in byte. Il bit “priorità” è utilizzato per i messaggi di dati. Se è impostato ad 1 allora il pacchetto L2TP è quello che deve ottenere un trattamento preferenziale nelle code L2TP. Il pacchetto L2TP è associato con un tunnel ID e un ID di sessione PPP, dati nei campi tunnel IP e l'ID di sessione, rispettivamente. La sequenza di bit indica se i numeri di sequenza sono stati utilizzati. Se sono usati, allora sono trasportati nei campi Ns ed Nr, che sono simili ai campi N(R) e N(S) nell'header HDLC. Cioè, il campo Ns contiene il numero di sequenza del pacchetto L2TP trasmesso, e il campo Nr contiene il prossimo numero di sequenza che L2TP trasmittente si aspetta di ricevere dal suo peer L2TP. Un canale affidabile tra due peer L2TP è fornito da L2TP solo per i messaggi di controllo. I numeri di sequenza Ns ed Nr vengono utilizzati per rilevare i pacchetti out-of-sequence e i pacchetti mancanti. I pacchetti persi vengono recuperati dalla ritrasmissione. I messaggi dati possono opzionalmente usare i numeri di sequenza per riordinare i pacchetti e rilevare i pacchetti persi. Tuttavia, non avviene la ritrasmissione di messaggi dati. L2TP viene eseguito su una rete come IP utilizzando UDP, frame relay e ATM. L'istituzione di una sessione all'interno di un tunnel si attiva quando la LAC riceve la richiesta da un utente ADSL per avviare una sessione PPP ad un NLS. Ogni sessione all'interno di un tunnel corrisponde a una singola sessione PPP. Una volta che la sessione viene stabilita, il frame PPP può fluire tra l'utente ADSL e il LNS. In particolare, i frame PPP sono trasmessi alla LAC sul PVC ATM. La LAC riceve il frame PPP da AAL 5, incapsula ogni frame con un header L2TP, e lo trasmette al LNS come messaggio dati. THE PPP TERMINATED AGGREGATION SCHEME Questo sistema (schema) si basa sul protocollo remote authentication dial in user service (RADIUS). Questo è un protocollo client/server utilizzato per l'autenticazione, autorizzazione e accounting. Un NAS, denominata Broadband Access Server (BAS), agisce come un client a un server RADIUS che è gestito da un NSP. Il BAS è responsabile per il passaggio di informazioni di autenticazione, come login utente e password, al server RADIUS. Queste informazioni di autenticazione sono sottomesse da un utente ADSL quando si inizia una sessione PPP. Il server RADIUS è responsabile dell’autenticazione dell'utente ADSL, e del ritorno delle informazioni di configurazione necessarie per la BAS per fornire un servizio all’utenti ADSL. Un BAS trasmette anche informazioni di account del server RADIUS. Gli stack di protocollo coinvolti in questo schema sono illustrati nella Figura 11.7. Come nel precedente schema, si assume che un utente ADSL in una sede abbia un singolo computer, invece di una rete di computer interconnessi attraverso una rete domestica. L'utente ADSL è collegato al DSLAM tramite ADSL. Sul lato della rete backbone di accesso, il DSLAM è collegato alla BAS attraverso una rete ATM. Infine, la BAS è collegato al router NSP in una rete, come IP, Frame Relay e ATM. Un utente ADSL è collegato alla BAS con un PVC ATM attraverso il DSLAM. Una sessione PPP avviata da un utente ADSL termina alla BAS, invece di essere tunneled al NSP come nello schema precedente. Il BAS invia le informazioni di autenticazione degli utenti al server RADIUS appropriato, e la sessione PPP è stabilita dopo che il server RADIUS convalida l'utente. L'utente ADSL può ora trasmettere pacchetti IP, che sono trasmessi dalla BAS al router del competente NSP. 11.1.5 THE ADSL2 AND ADSL2+ STANDARDS ADSL2 aggiunge nuove caratteristiche e funzionalità ad ADSL ed è stato standardizzato da ITU-T nel 2002 (G.992.3 e G.992.4). ADSL2 raggiunge una velocità (data rate) massima di downstream di 12 Mbps e una velocità massima di upstream di 1 Mbps. Si estende anche alla portata di ADSL da 600 metri. ADSL2+ è stato standardizzato da ITU-T nel 2003 (G.992.5) e raddoppia la banda di downstream, aumentando considerevolmente il rate di downstream per le linee telefoniche inferiori a 5000 piedi. Per esempio, può raggiungere 26 Mbps a 1000 piedi, e 20 Mbps a 5000 piedi. Lo splitter passivo (cioè senza componenti elettronici), indicato da cerchi in Figura 11.18, sono utilizzati per dividere il segnale. Questi sono fatti da fibre ottiche twisted e heating (riscaldate) fino a quando la potenza è distribuita uniformemente. Quando un segnale è diviso, c'è sempre la perdita di potenza, il che significa che vi è un limite su quante volte si può dividere. Un APON è un sistema di trasmissione punto-multipunto nella direzione downstream (cioè, dalla OLT all’ONU), e un sistema multipoint-to-point a mezzo condiviso in direzione upstream (cioè dall’ONU alla OLT). La OLT trasmette celle ATM che vengono ricevute da tutti gli ONU. Le celle trasmesse sono criptate con una chiave in modo chela ONU non può leggere le celle destinate ad un altro ONU. Ogni ONU seleziona solo le celle destinate ad essa. In direzione upstream, solo un ONU alla volta può trasmettere; in caso contrario, le celle trasmesse da diverse ONU potrebbero entrare in collisione. Un protocollo di accesso al mezzo permette agli utenti di trasmettere in direzione upstream, senza collisioni. Il meccanismo utilizzato per la trasmissione up e downstream è descritto di seguito. Un esempio di trasmissione downstream/upstream è dato in Figura 11.19. La OLT trasmette tre celle: una per ONU A, uno per ONU B, e uno per ONU C. (In Figura 11.19, una cella è rappresentato da un quadrato, con il nome della destinazione ONU scritto dentro.) Il segnale ottico che trasportano queste celle è diviso in tre, e ogni ONU riceve lo stesso segnale ottico con tutte e tre le celle ATM, di cui legge solo quello ad esso destinato. In direzione upstream, ogni ONU trasmette una cella e, grazie al meccanismo di accesso al mezzo, le celle arrivano al OLT, uno dopo l'altro senza collisioni. In questo esempio, le collisioni possono avvenire solo sul collegamento tra lo splitter, indicato dal cerchio e l’OLT. Il legame tra un ONU e lo splitter non è condiviso da altri ONU. Ogni cella trasmessa da uno ONU si propaga allo splitter, senza possibilità di collisione con altre celle di ONU. Se tutti e tre gli ONU trasmettono una cella nello stesso momento (e supponendo che la loro distanza dallo splitter è lo stesso), le celle arriveranno alla splitter allo stesso tempo e collidono. Lo splitter unirà i tre segnali in un unico segnale con la conseguente informazione distorta. Come si può dedurre dalla discussione precedente, lo splitter ha due funzioni. In direzione downstream divide il segnale, e in direzione upstream combina i segnali in ingresso in un unico segnale. Così, funziona come uno splitter e un combinatore allo stesso tempo. I segnali di downstream e upstream vengono trasmessi su lunghezze d'onda diverse, e quindi è possibile avere trasmissioni che si svolgono al tempo stesso. OLT è costituito da uno switch ATM, ATM si interfaccia con la rete dorsale e le interfacce ODN sul lato utente (vedi Figura 11.20). Ogni interfaccia ODN serve un diverso APON, e ci sono tanti APONs quante interfacce ODN. Per esempio in Figura 11.18, ci sono N interfacce ODN ed N APONs diversi, e nell'esempio dato in Figura 11.19 c'è un APON unico. APON è stato standardizzato da ITU-T nel 1998, nella raccomandazione G.983.1. APON è stata definita come full service access networks (FSAN) come la tecnologia di trasporto ottico comune. FSAN è una iniziativa da parte degli operatori e produttori di telecomunicazioni formato nel 1995 per sviluppare un consenso sulla richiesta del sistema nella rete di accesso locale ad offrire una serie completa di servizi telecomunicazioni sia a banda stretta (narrowband) che a banda larga (broadband). L'architettura di rete G.983.1 è mostrata nella Figura 11.21. A seconda della posizione della ONU, abbiamo le seguenti tre possibili configurazioni: • Fiber to the home (FTTH): L'ONU è in casa. • Fiber to basement/curb (FTTB/C): L'ONU è in un edificio o un marciapiede. La distribuzione per la casa è fatta in rame utilizzando una linea ADSL o VDSL. • Fiber to the cabinet (FTTCab): L'ONU è in una console e la distribuzione alla casa è fatta in rame tramite ADSL o VDSL. FTTB/C e FTTCab sono trattati allo stesso modo dell'architettura di rete G.983.1. L'ONU termina le reti ottiche di accesso e fornisce l'interfaccia(e) user-side su rame utilizzando una linea ADSL/VDSL. Una ONT (optical network terminator) è il dispositivo utilizzato presso il cliente. Per semplicità ci riferiremo all’ ONTs come ONU. L'architettura APON utilizza diverse lunghezze d'onda per la trasmissione up e downstream. Una lunghezza d'onda è un canale segnale ottico realizzato attraverso una fibra ottica (vedi sezione 8.3.1). Un trasmettitore emette un laser a una lunghezza d'onda specifica che viene utilizzato come portante del segnale ottico. Il laser è modulato dal segnale digitale per produrre un segnale ottico che viene guidato attraverso la fibra ottica ad un ricevitore ottico. L'architettura APON si avvale di due lunghezze d'onda per la trasmissione downstream e una lunghezza d'onda per la trasmissione upstream. In particolare, per la trasmissione downstream è utilizzato la lunghezza d’onda 1490 nm per la trasmissione di traffico ATM e una secondo a 1559 nm per la distribuzione video. Per la trasmissione upstream, è utilizza una lunghezza d'onda di 1310 nm, che è condivisa da tutti gli ONU. Lo standard G.983.1 consente anche l'uso di ulteriori fibre unidirezionali, operante a 1310 nm. Due opzioni di trasmissione possono essere utilizzate: simmetrica e asimmetrica. Nella opzione simmetrica, sia la velocità di trasmissione up che downstream per il traffico ATM è 155,52 Mbps. Nell’opzione asimmetrica, le velocità di trasmissione downstream e upstream per il traffico ATM è 622,08 e 155,52 Mbps, rispettivamente. La distanza massima da un fibra ONU ad una OLT è di 20 km, il numero minimo di divisioni supportato per uno splitter passivo è di 16 o 32, e il numero minimo di ONU sostenuti in un APON è 64. Queste specifiche saranno probabilmente cambiate quando la tecnologia si evolverà. APON è in grado di fornire accesso ad alta velocità per il traffico Internet, voce su ATM, voice over IP e servizi video. APON può essere distribuito in nuovi quartieri e comuni. In un nuovo quartiere, la fibra può essere posta allo stesso tempo dell'infrastruttura. I comuni hanno interesse a fornire connettività ad alta velocità ai propri residenti, e possono facilmente implementare APONs facendo passare la fibra attraverso gli attuali condotti sotterranei che conducono in prossimità delle abitazioni. Inoltre, le imprese sono un potenziale fornitore in quanto possono implementare la fibra utilizzando i poli già esistenti che sostengono i cavi elettrici! 11.3.1 STRUTTURE DEL FRAME PER LA TRASMISSIONE DOWNSTREAM E UPSTREAM La trasmissione in downstream sia per 155,52 Mbps che per 622,08 Mbps consiste in un flusso continuo di time slot. Ogni time slot è costituito da 53 byte, e contiene o una cella ATM o uan cella a livello fisico di 53 byte OAM (PLOAM). Le celle PLOAM sono utilizzate solo ogni 28-imo time slot. La loro funzione è spiegata nella sezione seguente.Gruppi di time slot sono organizzati in frame. La struttura del frame per velocità di trasmissione di 155,52 Mbps e di 622,08 Mbps è mostrato nella Figura 11.22. Per la velocità di trasmissione 155,52 Mbps, il frame è composto di 56 tima slot, di cui due sono celle PLOAM e le restanti 54 sono le celle ATM. Come si vede, il primo time slot del frame porta una cella PLOAM e i restanti 27 time slot contengono celle ATM. Questo gruppo di 28 time slot si ripete ancora una volta all'interno della struttura. Cioè, il time slot 29 è una cella PLOAM, e i restanti 27 time slot saranno delle celle ATM. Il frame per la velocità di trasmissione 622,08 Mbps consiste di 244 time slot, di cui otto sono celle PLOAM, e le restanti 216 sono le celle ATM. Il primo time slot di un frame contiene una cella PLOAM e i restanti 27 time slot contengono celle ATM. Questo gruppo di 28 time slot si ripete sette volte di più all'interno della struttura. La struttura del frame per la trasmissione in upstream è mostrato nella Figura 11.23.