Rete Accademica Albanese - rash.al · 2.4.1.1 Piano di indirizzamento IP ... Albanese e del...

Rete Accademica

Albanese

RETE TELEMATICA DELLE UNIVERSITÀ

PUBBLICHE ALBANESI E SERVIZI CONNESSI

Progetto Tecnico

Rete Telematica delle Università Pubbliche Albanesi e servizi connessi - Progetto Tecnico

2

1 Introduzione e finalità ........................................................................................................ 4

2 Progettazione dell’infrastruttura di rete...................................................................... 5

2.1 Overview della soluzione proposta ......................................................................................... 5

2.2 Classificazione dei PoP e requisiti dei collegamenti ......................................................... 9

2.3 Topologia fisica della rete ......................................................................................................... 10

2.3.1 Nodi di backbone ............................................................................................................................... 10

2.3.2 Lista dei nodi da collegare ............................................................................................................. 14

2.4 Rete MPLS/IP ................................................................................................................................. 19

2.4.1 Indirizzamento IPv4 e IPv6 ........................................................................................................... 19

2.4.1.1 Piano di indirizzamento IP ......................................................................................................................... 20

2.4.1.2 Risorse IP per link di backbone ................................................................................................................ 23

2.4.1.3 Risorse IP per link di accesso .................................................................................................................... 24

2.4.1.4 Risorse IP per la gestione degli apparati ............................................................................................. 25

2.4.1.5 Risorse IP per la navigazione internet e i servizi degli utilizzatori finali .............................. 25

2.4.1.6 Indirizzi gestiti dai (B)PoP ......................................................................................................................... 26

2.4.1.7 Tipologie di allocazione di risorse pubbliche .................................................................................... 28

2.4.2 Modalità di accesso alla rete accademica ................................................................................ 28

2.4.2.1 Scenario A: accesso diretto tramite PoP .............................................................................................. 30

2.4.2.2 Scenario B: accesso indiretto tramite CPE dell’organizzazione ................................................. 33

2.4.2.3 Scenario C: accesso ibrido .......................................................................................................................... 34

2.4.3 Routing interno .................................................................................................................................. 35

2.4.3.1 Routing OSPFv2 – IPv4 ................................................................................................................................ 37

2.4.3.2 Routing OSPFv3 – IPv6 ................................................................................................................................ 37

2.4.4 Routing esterno .................................................................................................................................. 38

2.4.5 Funzionalità aggiuntive .................................................................................................................. 40

2.4.5.1 MPLS L3 VPN .................................................................................................................................................... 41

2.4.5.2 MPLS L2 VPN .................................................................................................................................................... 43

2.4.5.3 QoS e Shaping ................................................................................................................................................... 45

2.4.5.4 Security ............................................................................................................................................................... 49

2.4.5.5 Sistema di gestione e monitoraggio ....................................................................................................... 50

3 Glossario ............................................................................................................................... 52


3

FIGURA 1: TOPOLOGIA FISICA ................................................................................................................................................................................... 6

FIGURA 2: ARCHITETTURA LOGICA .......................................................................................................................................................................... 8

FIGURA 3: BACKBONE DELLA MAN DI TIRANA ................................................................................................................................................... 11

FIGURA 4: BPOP1 E AFFERENTI ............................................................................................................................................................................. 12




FIGURA 8: PIANO DI INDIRIZZAMENTO IPV4 PUBBLICO ..................................................................................................................................... 20

FIGURA 9: PIANO DI INDIRIZZAMENTO IPV4 PRIVATO ....................................................................................................................................... 21

FIGURA 10: PIANO DI INDIRIZZAMENTO IPV6 PUBBLICO .................................................................................................................................. 22

FIGURA 11: PIANO DI INDIRIZZAMENTO IPV6 PRIVATO .................................................................................................................................... 23

FIGURA 12: INDIRIZZAMENTO BACKBONE ............................................................................................................................................................ 23

FIGURA 13: INDIRIZZAMENTO ACCESSO ................................................................................................................................................................ 24

FIGURA 14: ESEMPIO INDIRIZZAMENTO IPV4 PUBBLICO .................................................................................................................................. 29

FIGURA 15: ESEMPIO INDIRIZZAMENTO IPV4 PRIVATO .................................................................................................................................... 29

FIGURA 16: ESEMPIO INDIRIZZAMENTO IPV6 PUBBLICO .................................................................................................................................. 30

FIGURA 17: ESEMPIO INDIRIZZAMENTO IPV6 PRIVATO .................................................................................................................................... 30

FIGURA 18: SCENARIO A - ACCESSO DIRETTO TRAMITE POP ............................................................................................................................ 31

FIGURA 19: SCENARIO A1 – ACCESO DIRETTO UNIVERSITÀ REMOTE SENZA LAN ........................................................................................ 33

FIGURA 20: SCENARIO B - ACCESSO INDIRETTO TRAMITE CPE ORGANIZZAZIONE ....................................................................................... 34

FIGURA 21 SCENARIO C - ACCESSO IBRIDO ........................................................................................................................................................... 35

FIGURA 22: ESEMPIO SCENARIO MPLS L3 VPN ................................................................................................................................................ 42

FIGURA 23: ESEMPIO SCENARIO MPLS L2 VPN ................................................................................................................................................ 44


4

1 Introduzione e finalità )l presente documento costituisce il progetto per l’infrastruttura di rete e il servizio VoIP della Rete Accademica Albanese (Academic Network of Albania, ANA).

Il progetto è stato scritto da CASPUR (Consorzio interuniversitario per le Applicazioni di Supercalcolo Per Università e Ricerca nell’ambito della realizzazione da parte del Raggruppamento Temporaneo di Imprese (RTI) CINECA-CASPUR del bando «Fornitura dei servizi di Progettazione della rete telematica delle Università pubbliche albanesi ed assistenza al costituendo Centro Servizi », Dono No. A)D . L’infrastruttura della Rete Accademica Albanese è stata progettata per collegare tutte le Università pubbliche albanesi, nonché i Centri di Ricerca e le Istituzioni pubbliche collegate al sistema universitario e della ricerca albanese. L’infrastruttura stessa è stata ideata in modo da poter essere facilmente ampliata, se necessario, per poter accogliere in futuro nuove entità da

collegare alla Rete Accademica (università pubbliche, atenei privati, ulteriori istituzioni o

scuole, ecc.). L’obiettivo del presente progetto è di fornire una base per la stesura del Capitolato Tecnico collegato alla gara per la realizzazione dell’infrastruttura della Rete Accademica Albanese e del servizio VoIP, specificando i requisiti per la rete concordati insieme al centro

servizi.

In un documento separato verrà elaborato il progetto per il centro di gestione e

monitoraggio della rete NOC e della sua sicurezza SOC , come richiesto dal bando Dono No. A)D .


5

2 Progettazione dell’infrastruttura di rete

2.1 Overview della soluzione proposta

La soluzione architetturale prevista per la rete Accademica Albanese è illustrata

schematicamente in Figura 1 e Figura 2. La topologia fisica della rete, rappresentata in

Figura 1, è organizzata su due livelli gerarchici, il livello di backbone e il livello di accesso; il

livello di backbone è costituito da 4 nodi di aggregazione (in seguito Backbone PoP o BPoP)

collegati tra loro da un’anello in fibra ottica in tecnologia 10 gigabit ethernet. Tra i BPoP, il più

rilevante è il BPoP1, che avrà sede presso il Data Center del Centro Servizi della Rete

Accademica Albanese.

Ogni edificio a Tirana partecipante alla rete accademica (in seguito PoP) sarà collegato

in gigabit ethernet su fibra ottica ad uno dei 4 BPoP, mentre i collegamenti interurbani delle

università fuori Tirana saranno attestati sul BPoP1, con banda non inferiore a 10 Mb/s.

Il collegamento con il GARR/GEANT per il transito verso le reti della ricerca europee e mondiali, nonche verso la rete )nternet globale, sarà altresì attestato sul BPoP1 che,

accentrando anche i collegamenti interurbani, assumerà un ruolo di primaria importanza

nella rete.

La soluzione proposta è stata ideata in modo da supportare l’accesso a )nternet in multihoming, prevedendo fin dal principio l’utilizzo di un ulteriore transito )nternet con un ISP locale per consentire alla rete accademica di essere raggiunta e di raggiungere

velocemente le reti degli altri operatori presenti in Albania nonche di disporre di un accesso alternativo a Internet rispetto a quello fornito dal GARR/GEANT. )l presente progetto prevede l’attestazione del transito verso GARR/GEANT sul BPoP1, e del secondo transito )nternet con un )SP locale sul BPoP , per consentire l’accesso a )nternet alla rete accademica anche in caso di failure di uno dei due BPoP. I due transiti Internet potranno essere usati uno come backup dell’altro o contemporaneamente in modalità di

bilanciamento di carico.

Tuttavia, è importante sottolineare che la scelta dei BPoP su cui attestare i due transiti

potrà essere effettuata dal Centro Servizi sulla base di proprie considerazioni strategiche

anche durante la realizzazione della rete senza che ciò comporti variazioni strutturali nell’architettura proposta.


6

Figura 1: Topologia fisica


7

Sul BPoP4 potrà essere attestato, quando e se disponibile, un eventuale peering con

AKSHI che consentirà alla rete accademica di scambiare traffico in modo efficiente verso le

reti delle organizzazioni governative. Si ritiene che il BPoP4 rappresenti il BPoP ideale per l’instaurazione del peering con AKS() visto che si troverà presso l’Agenzia nazionale degli Esami (AKP), che essendo anche ente governativo sarà collegata anche alla rete AKSHI;

tuttavia, anche il peering con AKSHI potrà essere attestato su altri BPoP a discrezione del

Centro Servizi.

Dal punto di vista dell’architettura logica (rappresentata in Figura 2), la rete, che sarà

basata su un backbone in tecnologia MPLS (Multi Protocol Label Switch) in grado di fornire

servizi evoluti quali L2/L3 VPN, supporterà il dual stack IPv4/IPv6 su ogni nodo, e utilizzerà

OSPF (Open Shortest Path First) come protocollo di routing interno e BGP (Border Gateway

Protocol) per l’instradamento del traffico verso la Global Internet.

Per quanto riguarda OSPF, ogni BPoP svolgerà il ruolo di Area Border Router (ABR) tra

la backbone area, costituita dai collegamenti a 10 gigabit verso gli altri BPoP, e la specifica area foglia costituita dai collegamenti gigabit verso i PoP di competenza del BPoP.

Il collegamento della rete accademica verso la Global Internet sarà invece realizzato

tramite BGP nella sua versione esterna (E-BGP) per ricevere dal GARR/GEANT e dal local

Albanian ISP la Full )nternet Routing Table e da AKSHI le sole reti appartenenti alle

organizzazioni governative. La versione interna di BGP (I-BGP) sarà invece utilizzata per

propagare ai BPoP le informazioni di routing esterne e garantire in tal modo l’instradamento migliore del traffico verso internet, da ogni punto della rete, in base alla politica di

instradamento globale prevista.


8

Figura 2: Architettura logica


9

2.2 Classificazione dei PoP e requisiti dei collegamenti

Prima di indicare i requisiti principali per la topologia fisica della rete procediamo con

la classificazione dei PoP della rete; i PoP sono stati divisi in 3 categorie a seconda delle loro

dimensioni e funzionalità:

BPoP – Backbone PoP, router di fascia core

PoP-M – Medium PoP, router di fascia alta

PoP-S – Small PoP, router di fascia bassa

Caratteristiche hardware principali BPoP

PoP ad alte prestazioni utilizzato per la realizzazione del backbone e per l’aggregazione geografica dei nodi di accesso

Dispone di almeno 2 interfacce 10 gibabit ethernet

Dispone di almeno 16 interfacce gigabit ethernet

Sia l’alimentazione che il modulo di controllo sono ridondati

Caratteristiche hardware principali PoP-M

PoP di accesso alla rete accademica (più performante)

Dispone di almeno 3 porte gigabit ethernet

Sia l’alimentazione che il modulo di controllo sono ridondati

Caratteristiche hardware principali PoP-S

PoP di accesso alla rete accademica (meno performante)

Dispone di almeno 3 porte gigabit ethernet

L’alimentazione e il modulo di controllo non sono ridondati

Le tecnologie che dovranno essere supportate dai nodi della rete sono le seguenti:

MPLS (L3 e L2 VPN) – solo BPoP

OSPF v2 e v3 – tutti

BGP – solo BPoP

Route Reflector BGP (anche se al momento non utilizzati) – solo BPoP

IPv4 e IPv6 – tutti

VLAN IEEE 802.1Q – tutti


10

DCHPv4 – tutti

DHCPv6 – tutti

Autoconfiguration Stateless IPv6 – tutti

NAT IPv4 – tutti

Funzionalità di firewall stateful IPv4 e IPv6 – tutti

Funzionalità di switching – tutti

Funzionalità QoS (DiffServ) e Shaping – tutti

Per quanto riguarda i requisiti principali dei collegamenti, il progetto prevede che:

I collegamenti di backbone tra BPoP siano realizzati in tecnologia 10 gigabit

ethernet su fibra ottica

I collegamenti di accesso tra PoP e BPoP a Tirana siano realizzati in tecnologia

gigabit ethernet su fibra ottica

I collegamenti di accesso tra il BPoP1 e i PoP fuori Tirana siano realizzati in

ethernet in fibra ottica o in tecnologia wireless

Il collegamento verso il GARR/GEANT sia realizzato in fibra ottica

2.3 Topologia fisica della rete

2.3.1 Nodi di backbone

La posizione fisica di ogni BPoP a Tirana è stata scelta cercando di raggiungere al meglio

i seguenti obiettivi:

Prossimità: garantire il collegamento del maggior numero possibile di PoP

minimizzando la lunghezza della fibra ottica

Scalabilità: espansione futura della rete

Supporto locale da parte di personale esperto

Disponibilità di un locale protetto, refrigerato, chiuso, ecc.

Possibilità di realizzare un’uscita in doppia via sull’anello metropolitano

La proposta per il collegamento dei 4 nodi di backbone (BPoP) è illustrata in Figura 3; il backbone è rappresentato in rosso, e i BPoP sono segnati con la lettera P .


11

Figura 3: Backbone della MAN di Tirana

Di seguito presentiamo la lista dettagliata dei BPoP.

BPoP1 – Ufficio del Centro Servizi (ANA)

Il BPoP1 sarà installato presso l’edificio che ospiterà il Centro Servizi. Questo BPoP

sarà il nodo-chiave della rete, poiché collegherà alla Rete Accademica il Data Center

del Centro Servizi, nel quale saranno presenti i server per le applicazioni condivise

tra le università, tra cui quelle sviluppate da CINECA. Dal BPoP1 partirà il link verso

il GARR/GEANT che collegherà la rete di ANA alle reti accademiche europee e a

Internet.

Il BPoP1 funzionerà inoltre come nodo di aggregazione per l’area sud-ovest di

Tirana e per le università fuori Tirana.

Il BPoP1 con i PoP afferenti (tranne quelli interurbani) è mostrato in Figura 4.


12

Figura 4: BPoP1 e afferenti

BPoP 2 – Rettorato Università di Tirana )l BPoP sarà situato presso l’edificio del Rettorato dell’Università di Tirana, in una

stanza utilizzata come server room, già adeguata per ospitare il BPoP. La stanza è chiusa a chiave, condizionata esistono condizionatori e c’è la possibilità di installare un rack per il BPoP.

Nella piazza dove si trova il rettorato arrivano le fibre di diversi operatori ed è facile

realizzare due ingressi in fibra ottica su percorsi fisici completamente indipendenti

per il collegamento verso il BPoP1 e il BPoP3.

Il BPoP2 funzionerà come nodo di aggregazione per la parte sud-est di Tirana.

Il BPoP2 con i PoP afferenti è mostrato in Figura 5.


13


BPoP 3 – Facoltà di Medicina dell’Università di Tirana

Il BPoP sarà posizionato presso l’edificio di Pre-Clinic della facoltà di Medicina dell’università di Tirana, che dispone di una stanza dove può essere installato il

BPoP. Il BPoP3 funzionerà come nodo di aggregazione per la parte nord-est di

Tirana.

Il BPoP3 con i PoP afferenti è mostrato in Figura 6.



14

BPoP 4 – Agenzia Nazionale per gli esami (AKP) )l BPoP sarà situato presso l’edificio dell’Agenzia Nazionale per gli esami (AKP),

dove esiste una stanza adeguata per ospitare il BPoP. La stanza è refrigerata e chiusa

a chiave. Inoltre questa stanza sarà servita a breve da due linee elettriche distinte e

protette da un gruppo elettrogeno. Il BPoP4 funzionerà come nodo di aggregazione

per la parte nord-ovest di Tirana. )l BPoP con i PoP afferenti tranne l’Università agraria, che si trova fuori città verso nord-ovest) è mostrato in Figura 7.


2.3.2 Lista dei nodi da collegare

Di seguito vengono presentate 4 tabelle che elencano i PoP collegati ad ogni BPoP con le

loro caratteristiche. Per ogni PoP è indicata la categoria secondo la classificazione fatta in 2.2

(BPoP, PoP-M o PoP-S).


15

PoP Università/Ente Edificio Indirizzo Tipologia PoP Note

1.1 Centro Servizi della Rete

Accademica Albanese Uffici Centrali

Rruga Sami Frasheri,

Tirana PoP-M

Installato nello

stesso edificio del

BPoP1

1.2 Università di Tirana Facoltà di Scienze Sociali

e Facoltà di Diritto

Rruga Milto Tutulani,

Tirana PoP-M

1.2 bis Università di Tirana Facoltà di Scienze Sociali Bulevardi Gjergj

Fishta PoP-M

1.3 Università di Tirana Istituto di Biotecnologie Rruga Sami Frasheri,

Tirana PoP-S

Stesso edificio del

Centro Servizi

1.4 Università di Tirana Giardino Botanico Rruga Mehdi

Frasheri, Tirana PoP-S

1.5 Politecnico di Tirana Facoltà di Ingegneria

Matematica e Fisica

Rruga Muhamet

Gjollesha, Tirana PoP-S

1.6 Università di Durazzo Rettorato Rruga e Currilave,

Durrës PoP-M

Università fuori

Tirana

1.7 Università di Elbasan Rettorato Rruga Ismail Zyma,

Elbasan PoP-M

Università fuori

Tirana

1.8 Università di Scutari Rettorato Rruga Studenti,

Shkodër PoP-M

Università fuori

Tirana

1.9 Università di Korça Campus Bolevardi Gjergj

Kastrioti, Korçë PoP-M

Università fuori

Tirana

1.10 Università di Argirocastro Campus Rruga Tahir Kadare,

Gjirokastër PoP-M

Università fuori

Tirana

1.11 Università di Valona Rettorato L. Pavarësia, Vlorë PoP-M Università fuori

Tirana

Tabella 1: PoP Associati al BPoP1


16


2.1 Università di Tirana Rettorato Sheshi Nënë Tereza,

Tirana PoP-M

Installato nello

stesso edificio del

BPoP2

2.2 Università di Tirana

Facoltà di Storia e

Filologia e Facoltà di

Lingue

Rruga e Elbasanit,

Tirana PoP-M

2.3 Università di Tirana Facoltà di Economia Rruga e Elbasanit,

Tirana PoP-M

2.4 Università di Tirana Facoltà di Legge (Master) Rruga Arben Broci,

Tirana PoP-S

2.5 Politecnico di Tirana Rettorato Sheshi Nënë Tereza 4,

Tirana PoP-M

2.6 Politecnico di Tirana Facoltà di Geologia e

Miniere

Rruga Gjeneral

Nikols, Tirana PoP-S

2.7 Politecnico di Tirana Biblioteca Sheshi Nënë Tereza,

Tirana PoP-S

Nello stesso

edificio del BPoP

2.8 Università delle Arti Campus Sheshi Nënë Tereza,

Tirana PoP-M

2.9 Centro studi albanologici Accademia degli Studi

Albanesi

Sheshi Nënë Tereza,

Tirana PoP-M



17


3.1 Università di Tirana “Pre-Clinic”

Centro Ospedaliero

“Nënë Tereza”, Rruga e Dibrës, Tirana

PoP-S

Installato nello

stesso edificio del

BPoP3

3.2 Università di Tirana Facoltà di Medicina –

Edificio amministrativo

Rruga e Dibrës,

Tirana PoP-S


Dipartimento di Farmacia

Rruga e Dibrës,

Tirana PoP-S


Dipartimento di Anatomia

Centro Ospedaliero


PoP-S


Dipartimento di Pediatria

Centro Ospedaliero


PoP-S

3.6 Università di Tirana Facoltà di Infermieristica

Centro Ospedaliero


PoP-S

3.7 Università di Tirana Facoltà di Stomatologia

Centro Ospedaliero


PoP-S

3.8 Università di Tirana Facoltà di Scienze

Naturali

Bulevardi Zogu I,

Tirana PoP-M

3.9 Università di Tirana Istituto di Ricerca di

Fisica Nucleare

Rruga Qemal Stafa,

Tirana PoP-S

3.10 AKTI - Rruga Abdi Toptani,

Tirana PoP-S

3.11 Accademia delle Scienze - Rruga Murat Toptani,

Tirana PoP-S



18


4.1 AKP - Rruga Naim Frasheri

37, Tirana PoP-M

Installato nello

stesso edificio del

BPoP4

4.2 Università di Tirana Museo di Scienze

Naturali

Rruga e Kavajes,

Tirana PoP-S

4.3 Politecnico di Tirana Facoltà di Ingegneria

delle Costruzioni

Rruga Muhamet

Gjollesha 54, Tirana PoP-M

4.4 Politecnico di Tirana Istituto di Geoscienze Rruga Don Bosko 60,

Tirana PoP-S

4.5 Università dello Sport Campus Rruga Muhamet

Gjollesha, Tirana PoP-M

4.6 Università Agraria Campus PoP-M

4.7 QSA IAKSA PoP-S

4.8 QSA Istituto di lingue, storia,

letteratura, arte PoP-S

4.9 APAAL - Rruga e Durresit,

Tirana PoP-S

4.10 MASH - Rruga e Durresit 23,

Tirana PoP-M

4.11 AKSHI1 -

Rruga Papa Gjon Pali

II 3 -1


1 AKSHI utilzzerà i propri apparati per collegarsi alla rete accademica pertanto è richiesta la fornitura della sola connettività in fibra ottica verso il B-PoP4


19

2.4 Rete MPLS/IP

2.4.1 Indirizzamento IPv4 e IPv6

Come già anticipato, la rete accademica supporterà in ogni nodo il dual stack IPv4 e

IPv6. A causa della scarsa disponibilità di indirizzi IPv4, il progetto prevede un piano di numerazione interno interamente privato per l’infrastruttura di backbone e di accesso in

modo da dedicare gli indirizzi )Pv pubblici per l’accesso ad Internet delle postazioni utente

del personale o ai servizi pubblici di una università/ente (es. server web, server di posta, ecc.). Al contrario, grazie all’ampia disponibilità di indirizzi IPv6 che saranno riservati alla rete accademica albanese, l’indirizzamento )Pv sarà pubblico sia per i link di backbone che per quelli di accesso alla rete che, più in generale, per tutte le postazioni interne e i servizi

eventualmente offerti dalle università.

Per la gestione degli apparati di rete, il progetto prevede l’utilizzo di network private IPv4 e IPv6, annunciate internamente tramite OSPF, dalle quali saranno ricavati gli indirizzi

necessari da configurare sulle interfacce di loopback di ogni PoP della rete. In questo modo

sarà pertanto possibile gestire tutti gli apparati di rete tramite indirizzi indipendenti dallo

stato fisico dei collegamenti. )noltre l’esistenza delle classi di indirizzamento riservate

esclusivamente alla gestione degli apparati consentirà di:

implementare le necessarie policy di accesso agli apparati in modo semplificato

per i soli server di gestione del centro servizi

classificare e riservare banda al traffico di gestione (vedi paragrafo 2.4.5.3)

consentire la corretta configurazione delle sessioni di peering I-BGP globali e

VPNv4 (vedi paragrafi 2.4.4 e 2.4.5.1)

Supponendo di disporre di almeno una classe /22 di indirizzi IPv4 e di una classe /32

di indirizzi IPv6, si riporta di seguito il piano di indirizzamento pubblico e privato per le

risorse IPv4 e IPv6, previste per:

link di backbone, tra BPoP

link di accesso, tra BPoP e PoP

gestione degli apparati

allocazioni pubbliche


20

2.4.1.1 Piano di indirizzamento IP

2.4.1.1.1 Piano di indirizzamento IPv4

Ad ogni BPoP sarà allocata una /24 pubblica (Figura 8) suddivisa in due /25.

Ogni BPoP inizierà ad assegnare indirizzi a partire dalla prima /25 secondo le

modalità descritte in 2.4.1.5. La seconda /25 sarà invece riservata per utilizzi

futuri (ad eccezione del BPoP1)

Il BPoP1 inizierà ad assegnare indirizzi a partire dalla prima /25 come gli altri

BPoP, ma delegherà al PoP 1.1 (vedi paragrafo 2.3.2) anche la prima /26 della / riservata. Questa / servirà per l’indirizzamento dei servizi che saranno offerti dal Centro Servizi.

Figura 8: Piano di indirizzamento IPv4 pubblico

Il piano di indirizzamento IPv4 privato seguirà invece lo schema illustrato in Figura 9.

Gli indirizzi IPv4 privati saranno usati per:

i collegamenti tra BPoP (par. 2.4.1.2)

i collegamenti tra BPoP e PoP (par. 2.4.1.3)

i collegamenti tra PoP e CPE (se presenti, par. 2.4.1.3)


21

le loopback di gestione (par. 2.4.1.4)

Figura 9: Piano di indirizzamento IPv4 privato

2.4.1.1.2 Piano di indirizzamento IPv6

Per consentire ai router di effettuare opportune operazioni di aggregazione delle reti

IPv6, necessarie per limitare la crescita della dimensione delle tabelle di routing e il carico

computazionale necessario alla creazione dinamica delle stesse, per ogni BPoP saranno

riservati i blocchi /56 contigui a quello inizialmente utilizzato. In particolare, partendo dalla

/32 IPv6 pubblica il piano di subnetting (vedi Figura 10) seguirà i seguenti criteri:

Ogni BPoP inizierà ad assegnare indirizzi a partire dalla prima /56 relativa alla

/48 ad esso allocata secondo le modalità descritte in 2.4.1.5. Le rimanenti /56

disponibili saranno invece riservate per utilizzi futuri (ad eccezione del BPoP1,

vedi in seguito)

Il BPoP 1 inizierà ad assegnare indirizzi a partire dalla prima /56 come gli altri

BPoP. Diversamente dagli altri BPoP, il BPoP1 delegherà al PoP 1.1 (vedi


22

paragrafo 2.3.2 , la seconda / . Questa / servirà per l’indirizzamento dei servizi che saranno offerti dal Centro Servizi.

La quinta /48 estratta dal prefisso /32 servirà per l’indirizzamento dei

collegamenti tra BPoP, dei collegamenti tra BPoP e PoP e dei collegamenti

eventuali tra PoP e CPE (vedi scenari di accesso B e C, paragrafi 2.4.2.2 e 2.4.2.3)

secondo le modalità specificate in 2.4.1.2 e 2.4.1.3. In particolare ad ogni BPoP

sarà assegnata una /121; la prima /122 estratta dalla /121 sarà utilizzata per l’indirizzamento dei collegamenti tra BPoP e PoP, la seconda per i collegamenti

eventuali tra PoP e CPE. Infine i collegamenti di backbone tra BPoP saranno

ricavati da una /121 dedicata estratta dallo stesso prefisso /48

Figura 10: Piano di indirizzamento IPv6 pubblico

Il piano di indirizzamento IPv6 privato necessario per l’indirizzamento delle loopback di gestione secondo quanto specificato in 2.4.1.4 seguirà lo schema illustrato in Figura 11.


23

Figura 11: Piano di indirizzamento IPv6 privato

2.4.1.2 Risorse IP per link di backbone L’indirizzamento )P per i collegamenti di backbone tra BPoP prevede (vedi Figura 12 e

paragrafo 2.4.1.1):

L’utilizzo di 1 /25 IPv4 privata per ricavare le /30 IPv4 da configurare sui 4

collegamenti tra i BPoP

Utilizzo di 1 /121 IPv6 pubblica per ricavare le /127 IPv6 da configurare sui 4

collegamenti tra i BPoP

Figura 12: Indirizzamento backbone


24

2.4.1.3 Risorse IP per link di accesso L’indirizzamento )P per i collegamenti di accesso tra BPoP e PoP prevede (vedi Figura

13 e paragrafo 2.4.1.1):

L’utilizzo di / privata assegnata ad ogni BPoP per l’indirizzamento dei collegamenti punto punto. Ogni /24 sarà suddivisa in due /25, la prima sarà

utilizzata per ricavare le /30 IPv4 per i collegamenti tra il BPoP ed i PoP

(scenario di accesso A, paragrafo 2.4.2.1 , la seconda per l’eventuale indirizzamento tra PoP e CPE (scenari B e C, paragrafi 2.4.2.2 e 2.4.2.3). In

entrambi i casi il primo IP utile della /30 sarà sempre configurato

rispettivamente sul BPoP (collegamento tra BPoP e PoP) e sul PoP

(collegamento tra PoP e CPE)

L’utilizzo di / pubblica assegnata ad ogni BPoP per l’indirizzamento dei collegamenti punto punto. Ogni /121 sarà suddivisa in due /122, la prima sarà

utilizzata per ricavare le /127 IPv6 per i collegamenti tra il BPoP ed i PoP

(scenario di accesso A, paragrafo 2.4.2.1 , la seconda per l’eventuale indirizzamento tra PoP e CPE (scenari B e C, paragrafi 2.4.2.2 e 2.4.2.3). In

entrambi i casi il primo IP utile della /127 sarà sempre configurato

rispettivamente sul BPoP (collegamento tra BPoP e PoP) e sul PoP

(collegamento tra PoP e CPE)

Figura 13: Indirizzamento accesso


25

2.4.1.4 Risorse IP per la gestione degli apparati L’indirizzamento )P per la gestione degli apparati prevede (vedi paragrafo 2.4.1.1):

L’utilizzo di una / privata assegnata ad ogni BPoP per ricavare le / da configurare sulle interfacce di loopback (L0) per la gestione dei PoP e del BPoP

(Figura 13). Il primo IP utile sarà configurato sul BPoP, gli altri sui PoP afferenti

al BPoP.

L’utilizzo di una / privata assegnata ad ogni BPoP per ricavare le / da configurare sulle interfacce di loopback (L1) per la gestione dei PoP e del BPoP

(Figura 13). Il primo IP utile sarà configurato sul BPoP, gli altri sui PoP afferenti

al BPoP. La network /48 IPv6 privata dalla quale si estrarranno le 4 /123 e successivamente le / sarà di tipo Unique local . Pertanto sarà necessario ricavare il valore del campo global id tramite gli algoritmi previsti dallo standard, RFC 4163, o similari.

Al traffico di gestione proveniente dalle postazioni del personale tecnico del centro

servizi sarà associata una banda minima garantita mediante una specifica policy QoS (vedi

paragrafo 2.4.5.3)

2.4.1.5 Risorse IP per la navigazione internet e i servizi degli utilizzatori finali L’indirizzamento IP pubblico per le allocazioni agli utenti finali prevede (vedi paragrafo

2.4.1.1):

L’utilizzo di una / pubblica assegnata ad ogni BPoP dalla quale ricavare: o / per l’assegnazione degli indirizzi /32 alle interfacce di loopback

(L2) del BPoP e dei relativi PoP afferenti (Figura 13). Il primo IP utile

andrà configurato sul BPoP, i successivi sui PoP ad esso afferenti. Tali

indirizzi saranno utilizzati dai PoP per il NAT delle connessioni

provenienti dalle reti private delle organizzazioni collegate alla rete

accademica

o 6 /28 che potranno essere allocate alle organizzazioni collegate alla rete

accademica in base alle specifiche del paragrafo 2.4.1.7

L’utilizzo di 1 /26 IPv4 pubblica da destinare interamente ai servizi IPv4 erogati

dal centro servizi

L’utilizzo di / )Pv pubblica per ogni BPoP


26

L’utilizzo di / )Pv pubblica per ogni BPoP dalla quale ricavare fino a 32 /62

da assegnare ai PoP afferenti a tale BPoP. Da ogni /62 sarà possibile ricavare

fino a 4 /64 che saranno così ripartite:

o 1 /64 per l’indirizzamento delle postazioni sulla LAN degli utenti; su

questa rete si sfrutteranno i meccanismi nativi dell’autoconfigurazione stateless IPv6

o 1 /64 per gli eventuali servizi pubblici offerti dalla specifica

organizzazione

o 2 /64 libere per allocazioni successive

L’utilizzo di 1 /56 IPv6 pubblica da destinare interamente ai servizi IPv6 erogati

dal centro servizi

2.4.1.6 Indirizzi gestiti dai (B)PoP

Di seguito sono riportati schematicamente gli indirizzi IPv4 e IPv6 che dovranno essere

configurati sulle interfacce dei (B)PoP e gli aggregati da essi gestiti.

Indirizzi IPv4 configurati sui PoP

1 IP (/30) per il link punto punto verso il BPoP (indirizzo privato)

1 IP (/30) per il link punto punto verso l’eventuale CPE esistente (indirizzo

privato)

1 IP (/32) per indirizzo di loopback (L0) dedicato alla gestione (indirizzo

privato)

1 IP (/32) per l’indirizzo di loopback L2) usato per il NAT delle LAN private

delle organizzazioni (indirizzo pubblico)

1 indirizzo IP pubblico utilizzato come default gateway dai server della

eventuale rete DMZ dell’organizzazione connessa dal PoP

Aggregati IPv4 gestiti dal PoP

I PoP non gestiranno nessun aggregato IPv4

Indirizzi IPv4 configurati sui BPoP

2 IP (/30) per il link punto punto verso i BPoP adiacenti (indirizzi privati)


27

N IP (/30) per i link punto punto verso gli N PoP aggregati dal BPoP (indirizzi

privati)


privato)

Aggregati IPv4 gestiti dal BPoP

1 aggregato /24 per indirizzamento dei collegamenti punto punto tra BPoP e

PoP tra PoP e CPE (aggregato privato)

1 aggregato /27 per l’indirizzamento delle loopback di gestione L del BPoP e dei PoP ad esso afferenti (aggregato privato)

1 aggregato /24 – per le allocazioni pubbliche dei PoP da aggregati dal BPoP

(aggregato pubblico)

Indirizzi IPv6 configurati sui PoP

1 IP (/127) per il link punto punto verso il BPoP (indirizzo pubblico)

1 IP (/127 per il link punto punto verso l’eventuale CPE esistente (indirizzo

pubblico)


privato)

fino a 4 IP pubblici (/64) utilizzati come default gateway dai pc/server delle reti

LAN/DMZ dell’organizzazione connessa dal PoP

Indirizzi IPv6 configurati sui BPoP

2 IP (/127) per il link punto punto verso i BPoP adiacenti (indirizzi pubblici)

N IP (/127) per i link punto punto verso gli N PoP aggregati dal BPoP (indirizzi

pubblici)


privato)

Aggregati IPv6 gestiti dal PoP

1 aggregato / per l’assegnazione delle reti pubbliche all’organizzazione collegata dal PoP )(aggregato pubblico)


28

1 aggregato /56 (solo PoP 1.1, vedi paragrafo 2.3.2) per i servizi offerti dal

centro servizi (aggregato pubblico)

Aggregati IPv6 gestiti dal BPoP

1 aggregato / per l’indirizzamento delle organizzazioni afferenti al BPoP (aggregato pubblico)

1 aggregato / per l’indirizzamento dei link punto punto tra BPoP e PoP ed

eventualmente tra PoP e CPE (aggregato pubblico)

1 aggregato /123 per l’indirizzamento delle loopback di gestione (L1) del BPoP

e dei PoP ad esso afferenti (aggregato privato)

2.4.1.7 Tipologie di allocazione di risorse pubbliche

Premesso che di default, ogni organizzazione connessa alla rete accademica riceverà

per la LAN utente, un indirizzo )Pv pubblico configurato sull’interfaccia di loopback L2 dei

PoP) per il NAT degli indirizzi IPv4 privati ed una /64 IPv6 pubblica, le richieste di risorse

pubbliche per le reti DMZ potranno essere gestite secondo lo schema che segue:

Allocazione Standard – 1 /30 IPv4 pubblica (fino a 1 server), 1 /64 IPv6 pubblica

Allocazione Media – 1 /29 IPv4 pubblica (fino a 5 server), 2 /64 IPv6 pubbliche

Allocazione Alta – 1 /28 IPv4 pubblica (fino a 13 server)

Allocazione Custom – da concordare con il Centro Servizi

2.4.2 Modalità di accesso alla rete accademica

I servizi di accesso IPv4/IPv6 alla rete accademica saranno erogati in uno dei seguenti

modi:

Scenario A: accesso diretto tramite PoP

Scenario B: accesso indiretto tramite CPE organizzazione

Scenario C: accesso ibrido

Gli scenari di seguito descritti si basano sulle modalità di indirizzamento IPv4/IPv6

specificate nel paragrafo 2.4.1; le figure che seguono visualizzano le reti IPv4/IPv6 utilizzate.


29

Figura 14: Esempio indirizzamento IPv4 pubblico

Figura 15: Esempio indirizzamento IPv4 privato


30

Figura 16: Esempio indirizzamento IPv6 pubblico

Figura 17: Esempio indirizzamento IPv6 privato

2.4.2.1 Scenario A: accesso diretto tramite PoP

Nello scenario A (Figura 18), il PoP rappresenta il default gateway IPv4/IPv6

(direttamente connesso per le reti dell’organizzazione da collegare alla rete accademica. Non

vi sono cioè ulteriori apparati di livello 3 tra il PoP e gli host e/o i server dell’organizzazione e

il PoP può gestire due interfacce (fisiche o logiche), la prima verso la LAN degli utenti (es:

docenti, amministrativi, studenti, laboratori, ecc.), la seconda verso l’eventuale DMZ dei servizi; su entrambe le reti sarà possibile utilizzare il dual stack IPv4/IPv6.


31

Figura 18: Scenario A - accesso diretto tramite PoP

Nell’esempio in figura, il router ha configurato sulla prima interfaccia un indirizzo IPv4

compatibile con la rete privata già esistente all’interno dell’organizzazione da collegare. Sulla stessa interfaccia il router ha poi configurato l’indirizzo )Pv 2001:a30::1/64 della network pubblica allocata all’organizzazione. )l collegamento verso le altre realtà afferenti alla rete

accademica o più in generale verso la global internet avviene tramite NAT sfruttando l’indirizzo dell’interfaccia loopback L per le connessioni )Pv , o tramite le comuni regole

di instradamento IP per quelle IPv6.

Sulla seconda interfaccia il router può essere configurato con indirizzi IPv4 e IPv6 appartenenti alle reti dedicate all’eventuale DMZ rispettivamente . . . 4/28 e IPv6,

2001:a30:0:1::/64).

La modalità di accesso alla rete accademica per le Università fuori Tirana che non

hanno già una rete interna che colleghi gli edifici potrà utilizzare una variante dello scenario

ora presentato (scenario A1). Tale scenario (Figura 19) presuppone l’acquisto, da parte del

centro servizi, di uno switch di concentrazione (ubicato nello stesso edificio del PoP), di uno

switch di accesso per ogni edificio universitario e dei collegamenti fisici verso l’edificio

centrale ospitante il PoP. Gli switch saranno connessi tra loro in una configurazione a stella e


32

distribuiranno le due LAN, quella utente e quella dei servizi tramite il protocollo IEEE 802.1q

(VLAN all’interno di tutti gli edifici universitari. Nota: Si ricorda che la progettazione delle

LAN delle Università non rientra negli obiettivi del presente progetto.

Nello scenario A (e A1) il PoP dovrà implementare almeno le seguenti funzionalità:

DHCP server per comunicare i parametri di rete (indirizzi IP, default gateway,

DNS server, ecc.) agli host della rete IPv4 privata. In alternativa ogni

organizzazione potrà riservare un indirizzo privato da assegnare al PoP e

configurare staticamente tale indirizzo come default gateway sulle postazioni

interne

NAT IPv4, per consentire agli host sulla rete interna IPv4 privata di collegarsi

alle reti esterne tramite l’indirizzo )Pv pubblico configurato sull’interfaccia di loopback L2 del PoP

Autoconfigurazione Stateless IPv6, per autoconfigurare sugli host gli indirizzi

IPv6 compatibili con il prefisso /64 associato alla LAN (2001:a30::/64)

Policy di sicurezza, per proteggere gli host IPv4/IPv6 della LAN utente e della

DMZ (vedi paragrafo 2.4.5.4)


33

Figura 19: Scenario A1 – acceso diretto università remote senza LAN

2.4.2.2 Scenario B: accesso indiretto tramite CPE dell’organizzazione

In questo scenario (Figura 20 l’organizzazione si collega alla rete accademica

continuando ad utilizzare il proprio router (Customer Premises Equipment, CPE) sia per i

servizi IPv4 che per quelli IPv6. Rispetto allo scenario A è necessario:

Assegnare al segmento di rete tra PoP e CPE il corretto indirizzamento

IPv4/IPv6 secondo le modalità specificate in 2.4.1.3. Compatibilmente con tale paragrafo le network utilizzate nell’esempio in figura sono . . . / e 2001:a30:4:0:0:0:0:4::/127


34

Configurare opportunamente il routing statico verso la CPE delle reti IP pubbliche assegnate all’organizzazione (vedi paragrafi 2.4.3.1 e 2.4.3.2)

E’ importante sottolineare che, in questo caso, l’unica funzionalità necessaria per il PoP

tra quelle specificate in 2.4.2.1 è quella di NAT: sarà sempre il PoP ad eseguire il NAT per le connessioni provenienti dalle reti )Pv private dell’organizzazione; tutte le altre funzionalità (DHCP, policy di sicurezza autoconfigurazione stateless, ecc.) si intendono pertanto trasferite

sulla CPE anche se, in caso di necessità alcune di esse potrebbero comunque essere

implementate sul PoP (ad esempio per gestire eventuali attacchi di tipo DoS).

Figura 20: Scenario B - accesso indiretto tramite CPE organizzazione

2.4.2.3 Scenario C: accesso ibrido Quest’ultimo scenario (Figura 21) si pone a metà tra lo scenario A e lo scenario B. Come nello scenario B l’organizzazione si collega alla rete accademica continuando ad utilizzare il


35

proprio router, ma questa volta per i soli servizi IPv4 perché la CPE non supporta IPv6.

Pertanto i servizi IPv4 saranno gestiti come nello scenario B mentre i servizi IPv6 saranno

gestiti come nello scenario A. L’organizzazione infine potrà decidere se configurare i server

IPv4 nella stessa DMZ dei server IPv6 o mantenere due DMZ distinte in base al protocollo.

Figura 21 Scenario C - accesso ibrido

2.4.3 Routing interno

Il protocollo di routing scelto per la propagazione dinamica delle reti interne all’Autonomous System della rete accademica è OSPF. Tale protocollo dovrà essere utilizzato su ogni BPoP e PoP della rete nelle sue due versioni, OSPFv2 per il routing IPv4, e OSPFv3 per

il routing IPv6. L’architettura OSPF, schematizzata in Figura 2 (pag. 9), prevede che:

ogni BPoP ricopra il ruolo di Area Border Router tra l’area backbone e la specifica area periferica.

ogni area periferica sia configurata come NSSA (Not-So Stubby Area) per

consentire ai PoP interni di ridistribuire le rotte statiche negli scenari che lo

prevedono (scenari B e C, paragrafi 2.4.2.2 e 2.4.2.3)


36

i collegamenti tra BPoP e tra BPoP e PoP siano configurati come collegamenti

point-to-point OSPF al fine di evitare inutili meccanismi di elezione di

Designated Router and Backup Designated Router su segmenti ethernet con solo

due router

ogni BPoP implementi l’aggregazione delle reti dell’area periferica verso l’area backbone

i messaggi OSPF siano autenticati in tutte le porzioni della rete. In particolare si utilizzi l’autenticazione MD nativa di OSPFv e l’autenticazione MD5 o SHA1

fornita nativamente dal protocollo IPv6 per OSPFv3

i costi OSPF dei collegamenti siano ricavati in modo consistente in base alle

interfacce in gioco; ovvero i nodi della rete dovranno essere configurati per

assegnare costi crescenti in modo inversamente proporzionale alla banda

disponibile sull’interfaccia (es. costo decrescente rispettivamente per interfacce

10 Mb/s, 100 Mb/s, 1 Gb/s, 10 Gb/s)

Considerazioni:

L’utilizzo di OSPF nella parte di accesso non è strettamente necessario; al suo

posto, in alternativa, sarebbe possibile utilizzare il routing statico. Tuttavia si è

preferito predisporre e rendere operativo fin dal principio il protocollo

dinamico anche nelle zone periferiche della rete per consentire l’implementazione futura di scenari di ridondanza e/o bilanciamento del

traffico dei PoP con bassissimo impatto sulla configurazione della rete (es.

utilizzo di più collegamenti da un PoP verso i BPoP, chiusura degli anelli

periferici tra PoP, ecc.).

)l progetto prevede, per omogeneità con il resto della rete, l’utilizzo di OSPF anche sui collegamenti interurbani. Nel caso in cui tali collegamenti si

dimostrino instabili si consiglia di escluderli dal routing dinamico e di gestire il

relativo instradamento in modo statico.

I paragrafi seguenti specificano alcuni dettagli di configurazione di PoP e BPoP

relativamente ai protocolli OSPFv2 e OSPFv3.


37

2.4.3.1 Routing OSPFv2 – IPv4

I PoP della rete dovranno annunciare nell’area in cui si trovano: l’indirizzo privato di loopback /32 per la gestione (L0)

l’indirizzo pubblico di loopback /32 per la gestione (L2)

la rete privata /30 tra PoP e BPoP

l’eventuale rete privata / tra PoP e CPE

l’eventuale rete pubblica )Pv assegnata ai servizi della DMZ

le eventuali rotte statiche necessarie per instradare il traffico verso le CPE delle

organizzazioni da collegare (Scenari B e C, paragrafi 2.4.2.2 e 2.4.2.3) mediante

ridistribuzione in OSPF

I BPoP dovranno annunciare:

nell’area non backbone l’indirizzo privato di loopback / per la gestione L

nell’area non backbone l’indirizzo pubblico di loopback / per la gestione L

nell’area non backbone le reti private / tra il BPoP e i PoP ad esso afferenti

nell’area backbone le due reti private /30 verso gli altri due BPoP

Infine i BPoP dovranno:

aggregare verso l’area backbone la rete privata / destinata alla gestione degli apparati interni all’area non backbone

aggregare verso l’area backbone la rete privata / destinata all’indirizzamento dei collegamenti punto punto interni all’area non backbone

aggregare verso l’area backbone la rete pubblica /24 destinata al collegamento

internet delle organizzazioni afferenti al BPoP (indirizzi di loopback per il NAT

delle LAN utente e delle reti DMZ)

2.4.3.2 Routing OSPFv3 – IPv6

) PoP della rete dovranno annunciare nell’area in cui si trovano: l’indirizzo privato di loopback / per la gestione L

le eventuali reti /64 pubbliche destinate alla LAN e ai servizi DMZ

la rete pubblica /127 tra PoP e BPoP

l’eventuale rete pubblica / tra PoP e CPE


38

le eventuali rotte statiche necessarie per instradare il traffico verso le CPE delle

organizzazioni da collegare (Scenario B, paragrafo 2.4.2.2) mediante

ridistribuzione in OSPF

I BPoP dovranno annunciare:

nell’area non backbone l’indirizzo privato di loopback / per la gestione L

nell’area non backbone le reti pubbliche /127 tra il BPoP e i PoP ad esso

afferenti

nell’area backbone le due reti pubbliche /127 verso gli altri due BPoP

Infine i BPoP dovranno:

aggregare verso l’area backbone la rete privata /123 destinata alla gestione

degli apparati interni all’area non backbone

aggregare verso l’area backbone la rete pubblica / destinata all’indirizzamento dei collegamenti punto punto interni all’area non backbone

aggregare verso l’area backbone la rete pubblica /48 destinata al collegamento

internet delle organizzazioni afferenti al BPoP

2.4.4 Routing esterno

Il routing tra la rete accademica e la global Internet sarà garantito dal protocollo BGP.

Tale protocollo (Figura 2, pag. 9), utilizzato solo sui BPoP, sarà implementato secondo le

modalità di seguito descritte:

Il BPoP1 e il BPoP4 saranno gli unici BPoP ad implementare delle sessioni di

External BGP (E-BGP). Tali sessioni, instaurate con GARR/GEANT, con il Local

Albanian ISP e con AKSHI consentiranno ai BPoP di:

o Ricevere la Full Internet Routing Table IPv4 e IPv6 da GARR/GEANT

(BPoP1) e dal Local Albanian ISP (BPoP4)

o Ricevere le reti IPv4 e IPv6 delle organizzazioni governative afferenti ad

AKSHI (BPoP4)

o Annunciare le reti IPv4 e IPv6 della rete accademica Albanese su

entrambi i transiti

Ogni BPoP dovrà stabilire delle sessioni di Internal BGP (I-BGP) verso tutti gli

altri BPoP (collegamenti in bianco tratteggiato, Figura 2). In questo modo ogni


39

BPoP, disponendo delle informazioni di routing esterne al proprio Autonomous

System, avrà sempre la possibilità di instradare il traffico nel modo migliore in

base alla politica di instradamento globale prevista. Per garantire la maggiore

stabilità della rete sfruttando i meccanismi di riconvergenza automatici

implementati da OSPF, le sessioni I-BGP saranno realizzate tramite gli indirizzi

IP privati delle interfacce di loopback L0 (IPv4) e L1 (IPv6). In questo modo l’eventuale malfunzionamento di un collegamento sul backbone non comporterà

il reset delle sessioni I-BGP in quanto gli indirizzi di loopback relativi a tali

sessioni saranno raggiungibili tramite percorsi alternativi.

Di seguito si riporta la lista delle sessioni BGP gestite da ognuno dei 4 BPoP:

BPoP1

o Sessione E-BGP IPv4 verso GARR/GEANT

o Sessione E-BGP IPv6 verso GARR/GEANT

o 3 sessioni I-BGP IPv4 utilizzando gli indirizzi delle interfacce di loopback

L0 verso BPoP2, BPoP3 e BPoP4



BPoP2





BPoP3





BPoP4

o Sessione E-BGP IPv4 verso Local Albanian ISP

o Sessione E-BGP IPv6 verso Local Albanian ISP


40

o Sessione E-BGP IPv4 verso AKSHI

o Sessione E-BGP IPv6 verso AKSHI


L0 rispettivamente verso BPoP1, BPoP2 e BPoP3


L1 rispettivamente verso BPoP1, BPoP2 e BPoP3

L’architettura BGP prevista consentirà di implementare opportune politiche di instradamento del traffico in modo ottimizzato sull’intera rete tramite le potenzialità offerte

dal protocollo BGP.

Una possibile politica di instradamento potrebbe ad esempio essere la seguente:

raggiungere le reti della ricerca italiane ed europee preferibilmente tramite

GARR/GEANT, e solo per backup tramite il Local Albanian ISP

raggiungere le reti governative preferenzialmente tramite i peering diretti con

AKSHI e solo per backup tramite il Local Albanian ISP o GARR/GEANT

raggiungere le reti nazionali preferibilmente tramite il Local Albanian ISP

raggiungere le reti sulla global Internet bilanciando il traffico su entrambi gli

ISP, utilizzando cioè l’attributo AS-PATH di BGP come elemento discriminante

per la scelta dei percorsi

Considerazioni:

gli indirizzi IPv4 e IPv6 per i collegamenti di transito verso la global Internet

apparterranno allo spazio di indirizzamento del GARR/GEANT (collegamento di

transito BPoP1) e del Local Albanian ISP (collegamento di transito BPoP4)

gli indirizzi IPv4 e IPv6 per il peering del BPoP4 con AKSHI saranno concordati

in una fase successiva

il peering I-BGP tra il BPoP3 e il BPoP2 non è necessario; tuttavia è stato

previsto per omogeneità nella configurazione dei BPoP

le politiche di instradamento potranno variare anche in base alla banda

disponibile sui transiti e ai relativi costi

2.4.5 Funzionalità aggiuntive

In questo paragrafo sono presentate le funzionalità aggiuntive che dovranno essere

supportate dalla rete IP. Alcune funzionalità come ad esempio il QoS e lo shaping dovranno


41

essere implementate da subito, altre funzionalità potranno invece essere necessarie solo

successivamente.

2.4.5.1 MPLS L3 VPN

Alcune organizzazioni afferenti alla rete accademica potrebbero avere la necessità di

realizzare da subito o successivamente delle VPN di livello 3 per interconnettere le loro reti

interne IPv4 con indirizzamento privato. La soluzione migliore per fornire tale servizio è

quella che fa uso di MPLS L3 VPN. Sebbene l’architettura di rete proposta per la rete accademica sia stata pensata fin dal principio per supportare le MPLS VPN, sarà necessario

apportare alcune modifiche alla configurazione di base degli apparati. In particolare sarà

necessario introdurre una nuova interfaccia (fisica o logica) tra BPoP e PoP per differenziare il

traffico da trasportare sulla VPN rispetto al traffico internet e poi configurare

opportunamente gli apparati di rete per trasportare quella tipologia di traffico. I dettagli implementativi per la realizzazione del servizio saranno illustrati tramite l’esempio presentato in Figura 22.

Lo scenario riporta il classico caso in cui ad esempio si debba garantire il routing

diretto (cioè senza utilizzo di funzionalità di NAT) tra le reti IPv4 private 10.1.0.0/16,

10.30.0.0/16, e 10.201.0.0/16 rispettivamente appartenenti alle Facoltà X, Y e Z dell’università K. In questo caso, con particolare riferimento alla nomenclatura MPLS, i BPoP 2, 3 e 4

svolgerebbero il ruolo di PE (Provider Edge) router scambiandosi gli indirizzi privati IPv4

tramite delle sessioni I-BGP VPNv4 dedicate, mentre i PoP x, y e z rappresenterebbero i CE

(Customer Edge) router.


42

Figura 22: Esempio scenario MPLS L3 VPN

L’utilizzo di un collegamento aggiuntivo collegamento in blu, Figura 22) tra PE2 e CEx,

PE3 e CEy e PE4 e CEz si rende necessario per differenziare il traffico VPN da quello internet.

Infatti i PE2, PE3 e PE4 assoceranno a tale interfaccia una tabella di routing distinta (VRF) che

verrà popolata principalmente con informazioni provenienti dalle sessioni BGP VPNv4 (in blu

tratteggiato, Figura 22) relative a quella specifica VPN e utilizzata per il routing dei pacchetti

provenienti da tali collegamenti. I pacchetti inoltrati dai CE router sui collegamenti non VPN

saranno invece instradati utilizzando la tabella di routing globale dei PE router secondo le

modalità descritte in 2.4.2. L’indirizzamento )Pv privato dei collegamenti aggiuntivi ora introdotti seguirà le

modalità specificate in 2.4.1.1.1. Infine si ritiene che il routing tra PE e CE relativo alle reti

private da raggiungere tramite VPN, possa essere implementato mediante routing statico

almeno nella fase iniziale di startup della rete in cui pochissime organizzazioni richiederanno l’attivazione del servizio; questa scelta si rende necessaria principalmente per non

appesantire ulteriormente i CE router; naturalmente il servizio VPN potrà essere ottimizzato in qualunque momento tramite l’introduzione del routing dinamico.


43

Considerazioni:

Si ricorda che le organizzazioni connesse alla rete accademica manterranno la loro autonomia nell’utilizzo delle numerazioni )Pv private delle LAN, che

potranno pertanto sovrapporsi con le numerazioni private IPv4 delle altre

organizzazioni. Questo è il motivo principale per il quale le reti private sono

state escluse dal routing globale (cioè non sono propagate via OSPF); la

raggiungibilità di tali reti sarà possibile, ove necessario, tramite l’attivazione dei servizi VPN ora descritti

Il servizio di MPLS L3 VPN è stato pensato solamente per il protocollo IPv4 essendo l’indirizzamento )Pv , pubblico in ogni porzione di rete e gestito centralmente dal centro servizi; l’estensione del servizio di MPLS L3 VPN al

protocollo IPv6 potrà avvenire, se necessario, in una fase successiva

Nella situazione a regime sarà necessario realizzare il full mesh di sessioni I-BGP

VPNv4 analogamente a quanto già accade per il full mesh I-BGP IPv4 ed il full

mesh I-BGP IPv6

I due collegamenti tra CE e PE potranno essere realizzati tramite interfacce

fisiche distinte oppure utilizzando le VLAN (protocollo IEEE 802.1Q)

2.4.5.2 MPLS L2 VPN

Alcune organizzazioni afferenti alla rete accademica potrebbero avere bisogno di

interconnettere le loro reti locali direttamente a livello 2. Questo servizio potrà essere

implementato facilmente tramite le MPLS L2 VPN. Sebbene l’architettura di rete proposta per la rete accademica sia stata pensata fin dal principio per supportare le MPLS VPN, sarà

necessario apportare alcune modifiche alla configurazione di base degli apparati. I dettagli

implementativi per la realizzazione del servizio saranno illustrati tramite l’esempio di Figura

23. In particolare sarà necessario utilizzare un altro collegamento tra PE e CE di tipo fisico o

logico (realizzato cioè tramite VLAN, IEEE 802.1Q). In quest’ultimo caso sarà necessario: definire due VLAN id , il primo per la connettività internet, il secondo per la

MPLS L2 VPN

utilizzare uno switch intermedio tra PE e CE su cui attestare il collegamento

proveniente dal PE o sfruttare le funzionalità di switching eventualmente

disponibili sul CE (vedi considerazioni finali)


44

Figura 23: Esempio scenario MPLS L2 VPN

Nell’esempio in figura i due VLAN id (blu e nero) dovranno essere trasportati taggati sul collegamento verso il PE (grigio) ed estratti untagged sulle porte utente,

rispettivamente del router (nero) e della LAN (blu). La configurazione effettiva della VPN sarà

realizzata sfruttando le potenzialità di MPLS sui PE coinvolti, nel caso in esame PE2 e PE3; su

ogni PE verrà infatti configurato staticamente un tunnel verso l’interfaccia di loopback di

gestione dell’altro PE per trasportare il traffico ethernet ricevuto sull’interfaccia afferente al VLAN id relativo alla VPN. In questo modo le due LAN utente distribuite geograficamente in

locazioni differenti e configurate come appartenenti alla stessa rete IP (10.1.0.0/16)

condivideranno lo stesso dominio di broadcast come se si trovassero all’interno dello stesso

edificio.

Considerazioni:

Le funzionalità di switching necessarie per l’implementazione del servizio di L2

VPN (qualora non sia possibile utilizzare un ulteriore collegamento fisico),

potranno essere svolte da un apparato dedicato come nell’esempio in Figura

23) oppure dal CE stesso. In questo secondo caso il CE dovrà essere in grado di

svolgere sia funzioni di livello 3 che funzioni di livello 2


45

2.4.5.3 QoS e Shaping )l modello architetturale prescelto per l’implementazione delle funzionalità di Quality of Service (QoS) per il traffico IPv4 e IPv6 è il modello DiffServ. Tale modello si basa sul campo

DSCP (DiffServ Code Point), ricavato dai campi type-of-service ToS )Pv e traffic class

IPv6, e prevede la suddivisione del traffico in classi di servizio distinte gestite in modo differenziato dai router della rete. In particolare ad ogni classe di servizio, identificata da

uno specifico valore del campo DSCP, è associata una policy che rappresenta le esigenze

prestazionali per quella specifica classe.

Il meccanismo di funzionamento del DiffServ può essere riassunto come segue:

1. i singoli pacchetti sono classificati dai PoP di accesso (o dai BPoP, vedi in

seguito) e marcati con uno specifico valore del campo DSCP

2. i pacchetti marcati vengono immessi nella rete

3. ogni (B)PoP analizza il campo DSCP dei pacchetti in transito e gestisce le classi

di servizio tramite una policy precedentemente configurata Per (op Behaviour , P(B

Pertanto, la prima cosa da fare è individuare le classi di servizio che dovranno essere gestite in modo differenziato con il modello DiffServ. Analizzando i requisiti risultati dal

survey delle organizzazioni che afferiranno alla rete accademica, si ritiene che le classi di

servizio necessarie siano le seguenti:

Voice over IP

Classe di servizio a cui appartengono tutti quei pacchetti che costituiscono il

traffico voce reale di una chiamata VoIP (escludendo pertanto il traffico di

segnalazione)

Video

Classe di servizio associata al traffico video interattivo generato da

applicazioni per la videoconferenza

Segnalazione Voice over IP

Traffico di segnalazione utilizzato dal VoIP


46

Management/Routing

Classe di servizio associata al traffico di gestione della rete (es. traffico telnet/ssh per l’accesso e la gestione degli apparati di rete o generato dai protocolli di routing (es. BGP, OSPF)

Mission Critical

Classe di servizio associata al traffico generato da/verso applicazioni specifiche

(es. traffico dei servizi utilizzati dalle segreterie didattiche, ecc.)

Bulk Data

Classe di servizio associata al traffico generato da applicazioni che sono

relativamente non-interattive, non sensibili a eventuali drop, e che tipicamente

richiedono un uso prolungato della rete. Esempi di applicazioni di questo tipo sono l’FTP, la posta elettronica, le applicazioni per il backup, per la distribuzione

di contenuti, ecc.

Best Effort

Classe di default associata al traffico generato da tutte le applicazioni non

critiche (es. il web browsing)

Scavenger

Classe di servizio associata al traffico generato da tutte quelle applicazioni

ritenute a priorità più bassa di quelle best effort ma che sono comunque

consentite solo se non interferiscono con il traffico di nessuna delle altre classi

di servizio. Applicazioni tipicamente appartenenti a questa classe sono le

applicazioni di peer-to-peer (P2P) e di media-sharing (es. eDonkey, BitTorrent,

ecc.)

Prima di procedere con la definizione delle politica QoS da associare alle singole classi

di servizio, è necessario ricordare che la qualità dei servizi Voice over IP è determinata da tre

parametri principali, packet loss, latenza e jitter, e dalla disponibilità di banda riservata al

servizio che normalmente è proporzionale al numero di chiamate contemporanee che devono

essere garantite.


47

I valori di riferimento che devono essere tenuti in considerazione per il corretto

funzionamento del servizio VoIP sono i seguenti:

Packet loss non superiore all’ %

Latenza non superiore a 150 ms

Jitter sotto i 30 ms

Banda necessaria per una chiamata VoIP nel range [20-320] Kb/s (dipendente

dal codec, dal sampling rate, ecc.)

Per questi motivi, la classe di servizio VoIP dovrà essere gestita in modo privilegiato

rispetto alle altre classi. In particolare sarà utilizzata la classe Expedited Forwarding

prevista dal modello DiffServ che consente di offrire le prestazioni di una linea dedicata

virtuale con banda garantita caratterizzata da bassi valori di packet loss, latenza, e jitter. In

sostanza il traffico gestito tramite questa modalità sarà introdotto in una coda ad alta priorità

il cui smaltimento sarà sempre garantito anche in presenza di condizioni di congestione,

indipendentemente dal traffico generato dalle altre classi di servizio. Le altre tipologie di

traffico saranno invece gestite, solo dopo aver gestito la coda ad alta priorità, tramite le classi Assured Forwarding (AF), Best effort (BE) e Class Selectors (CS) previste dal modello

DiffServ. Il QoS sarà pertanto implementato assicurando ad ogni specifica classe di servizio

una banda minima garantita rispetto alla banda massima disponibile sul collegamento. In

questo modo, in condizioni normali di funzionamento, tutte le classi di traffico potranno utilizzare la rete senza l’intervento delle funzionalità di QoS fatta eccezione per quelle relative

la marcatura dei pacchetti. In caso di congestione, causata ad esempio dal superamento della

banda minima associata ad una o più classi di servizio, i meccanismi di QoS entreranno in

gioco droppando opportunamente i pacchetti in eccesso delle classi interessate, al fine di

ripristinare le condizioni iniziali.

I dettagli relativi alla banda minima garantita da riservare alle singole classi di servizio

potranno essere definiti in una fase successiva in base alle necessità riportate dal centro

servizi; tuttavia in Tabella 5 è riportato un modello di riferimento indicante, i valori

percentuali delle bande minime garantite (rispetto alla capacità complessiva del

collegamento) e i corrispettivi valori DSCP associati ad ogni specifica classe.

Classe di servizio BMG Valore DSCP

Voice over IP 18% EF

Video 15% AF41, AF42, AF43

Segnalazione Voice over IP 5% CS3


48

Classe di servizio BMG Valore DSCP

Management/Routing 5% CS2, CS6

Mission Critical 27% AF21, AF22, AF23

Bulk Data 4% AF11, AF12, AF13

Best effort 25% 0

Scavenger 1% CS1

Tabella 5: Classi di Servizio DiffServ

Riguardo le fasi di marcatura dei pacchetti in transito e di applicazione delle policy

associate alle classi di servizio si fa presente quanto segue:

Le operazioni di marcatura saranno eseguite su tutti e soli i pacchetti in ingresso

dalle interfacce LAN e/o DMZ dei PoP e di quelle di peering (E-BGP) dei BPoP

Le policy QoS saranno invece applicate al traffico in uscita sulle rimanenti

interfacce (collegamenti tra BPoP e tra PoP e BPoP)

Per garantire un utilizzo più razionale ed equamente distribuito della banda di accesso

a internet (risorsa limitata principalmente da aspetti economici), prima dell’applicazione dei

su citati meccanismi di QoS, sarà necessario implementare opportune tecniche di shaping per

limitare la banda disponibile sui collegamenti tra BPoP e PoP (normalmente pari a 1 Gb/s). In

particolare per ogni collegamento BPoP-PoP dovrà essere possibile

Implementare sul BPoP lo shaping della banda in uscita verso il PoP

(downstream per il PoP)

Implementare sul PoP lo shaping della banda in uscita verso il BPoP

(upstream per il PoP)

Le funzionalità di QoS e di shaping ora descritte dovranno essere implementate sulla

rete sin dal principio.

Considerazioni:

Per evitare l’utilizzo improprio delle funzionalità di QoS implementate sulla rete da parte di utenti o eventuali device, tutti i pacchetti con valori

di DSCP già impostati provenienti in ingresso dalle LAN/DMZ verso i PoP

o da internet verso i BPoP saranno opportunamente rimarcati secondo la

policy QoS della rete accademica


49

L’utilizzo di una banda minima garantita associata ai servizi di Voice over IP consente di stabilire un numero di conversazioni dipendenti dalla

banda richiesta da ogni singola conversazione. Affinché la qualità

complessiva del servizio VoIP sia soddisfacente potrà essere necessario

introdurre opportuni meccanismi di Call Admission Control (CAC) che

tengano conto della banda associata al VoIP prima di consentire l’instaurazione di nuove conversazioni; in caso contrario si rischia di degradare la qualità anche delle conversazioni precedenti. Le stesse

considerazioni valgono anche per il traffico generato da applicazioni di

video conferenza

Anche i servizi di video conferenza hanno requisiti stringenti simili al

VoIP; tuttavia si è ritenuto più importante gestire solo il servizio VoIP

tramite una coda prioritaria principalmente perché, almeno nella fase

iniziale di avvio della rete, non esisterà un servizio di video conferenza

centralizzato fornito dal centro servizi. Si ritiene comunque che eventuali

applicazioni di video conferenza pre-esistenti possano essere

correttamete gestite mediante i meccanismi di QoS presentati. In futuro,

se necessario, sarà chiaramente possibile modificare la politica QoS per

gestire tale traffico mediante una coda prioritaria

L’utilizzo della banda minima garantita più piccola per la classe di

servizio scavenger fa si che tale classe sia la prima ad essere sfavorita in

caso di congestione

2.4.5.4 Security

Sebbene la sicurezza, intesa come protezione del traffico da e verso i PC e/o Server

utilizzanti la rete accademica, sia di competenza delle singole organizzazioni, è comunque

molto importante prevedere anche per i (B)PoP la possibilità di implementare opportune

policy di traffic filtering almeno per i seguenti motivi:

Gestione e prevenzione di eventuali attacchi di tipo DoS verso la rete

accademica

Gestione delle politiche di accesso alla rete per organizzazioni prive di

firewall


50

La policy di sicurezza di default, da applicare sul PoP in caso di attivazione del servizio

da parte di una organizzazione, dovrebbe garantire:

Per la LAN utente in uscita, il solo traffico relativo ai protocolli http, https, dns

(udp), voip, e gli eventuali protocolli specifici per la videoconferenza (es. h.323)

Per la LAN utente in ingresso, il solo traffico di ritorno relativo alle sessioni

avviate in precedenza dai client (le policy da configurare dovranno essere

quindi di tipo stateful)

Per la DMZ in ingresso, per ogni server il solo traffico relativo al servizio offerto.

Tipicamente sulla rete DMZ saranno installati server web, mail, dns (tcp e udp),

e per la videoconferenza

Per la DMZ in uscita , per ogni server il solo traffico di risposta verso i client oltre a eventuali protocolli necessari per l’aggiornamento del sistema operativo (le policy da configurare dovranno essere quindi di tipo stateful)

Naturalmente eventuali variazioni a questa policy potranno essere concordate in base

alle necessità e ai servizi di ogni specifica organizzazione. Si suggerisce comunque di

incentivare le organizzazioni ad una gestione e implementazione autonoma delle politiche di

sicurezza tramite apparati specifici di loro proprietà (CPE, Firewall, ecc.)

2.4.5.5 Sistema di gestione e monitoraggio

Affinché l’infrastruttura di rete possa essere gestita e manutenuta in modo efficiente è

necessario che siano disponibili almeno due categorie di servizi:

Servizi di gestione di base

Servizi di monitoraggio

I servizi di gestione di base consentiranno al personale tecnico responsabile del

funzionamento della rete, di utilizzare degli strumenti in grado di apportare variazioni alle

configurazioni di rete, di consultare i file di log, e di visualizzare lo stato di funzionamento di

ogni specifico apparato, tramite un software centralizzato. Anche se queste informazioni

possono essere acquisite entrando direttamente in gestione sui singoli apparati (es. via

telnet/ssh), tale software consentirà ai responsabili di rete di ottenere rapidamente e in ogni

momento la fotografia dello stato di salute generale della rete; il software di gestione sarà


51

indicato tra i requisiti minimi del capitolato tecnico relativo alla realizzazione del presente

progetto.

Ad ulteriore integrazione o affiancamento delle funzionalità già previste dal sistema di

gestione di base è molto importante che il Network Operating Center (NOC) possa affidarsi a

strumenti di monitoraggio in grado di fornire quante più informazioni possibili in caso, ad

esempio, di situazioni di malfunzionamento della rete. Tali strumenti, tramite l’utilizzo di un’interfaccia tipicamente web, consentono l’analisi e la visualizzazione delle performance di tutti i dispositivi monitorati avvalendosi anche della presenza di cruscotti personalizzabili. Le informazioni prestazionali relative ad esempio

all’utilizzo della CPU, all’indicazione della memoria libera, alla temperatura dell’apparato, al

traffico sulle interfacce in ingresso e in uscita, ecc. sono ricavate tramite il protocollo SNMP

mentre la disponibilità degli apparati viene normalmente verificata tramite l’utilizzo di

pacchetti ICMP (ping).

Tutte le informazioni ricavate dal sistema di monitoring sono generalmente

organizzate sotto forma di grafici temporali e consultabili in tempo reale o tramite serie

storiche con periodo di riferimento giornaliero, settimanale, mensile e annuale.

Tra le funzionalità messe a disposizione da tali sistemi ricordiamo inoltre:

L’implementazione di meccanismi di notifica via sms, email, ecc., in grado di

allertare il NOC al verificarsi di alcune condizioni specifiche (ad esempio in caso

di indisponibilità degli apparati, di ricezione di trap SNMP, di superamento di

soglie precedentemente impostate sul traffico in transito sulle interfacce, sui

valori di temperatura, ecc.)

La gestione dei log relativi a eventi e allarmi

La generazione automatica con periodicità personalizzabile di rapporti di

conformità sulla base dei livelli di servizio richiesti

La creazione di weathermap personalizzate rappresentanti mappe di rete in cui i collegamenti tra apparati sono visualizzati con colori differenti in base al

traffico di rete gestito

L’implementazione di funzionalità di Netflow e SNMP Trap collector per

ricevere e visualizzare eventuali flussi Netflow e Trap SNMP dagli apparati di

rete


52

3 Glossario

Abbreviazioni e acronimi specifici del progetto usati nel presente documento:

PoP: Point of Presence, router di accesso verso il backbone

Backbone Pop o BPoP: router ad alte prestazioni per l’aggregazione geografica dei PoP di edificio

PoP-M: PoP-Medium, router di fascia alta

PoP-S: PoP-Small, router di fascia bassa

ABR: Area Border Router, router di bordo per le aree OSPF

ANA: Academic Network of Albania

AKP: Agenzia nazionale degli esami

AKT): Agenzia per le tecnologie e l’innovazione nella ricerca

AKS(): Agenzia nazionale per la società dell’informazione APAAL: Agenzia pubblica per l’accreditazione nell’educazione

MAS(: Ministero dell’Educazione e della Scienza albanese

QSA: Centro Studi Albanologici

UA: Università dell’Arte

UBT: Università agraria di Tirana

UPT: Università Politecnica di Tirana

UST: Università dello Sport di Tirana

UT: Università di Tirana

Riferimento per abbreviazioni e acronimi di uso comune richiamati nel documento:

BGP (E-BGP, I-BGP): (External/Internal) Border Gateway Protocol

CAC: Call Admission Control

CE: Customer Edge router

CPE: Customer Premises Equipment

DHCP: Dynamic Host Configuration Protocol

DMZ: De-Militarized Zone

DNS: Domain Name System

DSCP: Differentiated Services Code Point

ENUM: E.164 NUmber Mapping


53

GARR: la rete della ricerca italiana

Gb/s: Gigabits per second

Kb/s: Kilobits per second

L2/L3: Layer 2, Layer 3 (della pila ISO/OSI)

LAN: Local Area Network

MPLS: Multi Protocol Label Switching

NOC: Network Operations Center

NSSA: OSPF Not-So-Stubby Area

OSPF: Open Shortest Path First

IEEE: Institute of Electrical and Electronics Engineers

IP: Internet Protocol

IPv4/IPv6: IP versione 4 / versione 6

ISP: Internet Service Provider

IVR: Interactive Voice Response

Mb/s: Megabits per second

NAT: Network Address Translation

PE: Provider Edge router

PSTN: Public Switched Telephone Network

QoS: Quality of Service

RFC: Request For Comments

SIP: Session Initiation Protocol

SOC: Security Operations Center

VLAN: Virtual Local Area Network

VoIP: Voice over IP

VPN: Virtual Private Network

VRF: Virtual Routing and Forwarding

Rete Accademica Albanese - rash.al · 2.4.1.1 Piano di indirizzamento IP ... Albanese e del...

Documents

Transcript of Rete Accademica Albanese - rash.al · 2.4.1.1 Piano di indirizzamento IP ... Albanese e del...