Il BackBone IP di Telecom Italia Wireline TECNICO TELECOM ITALIA › Anno 13 n. 2 - Dicembre 2004 61...

NOTIZIARIO TECNICO TELECOM ITALIA › Anno 13 n. 2 - Dicembre 2004 61

Il Backbone IP diTelecom Italia Wireline

ALBERTO MARIA LANGELLOTTI

SIMEONE MASTROPIETRO

FEDERICO TITO MORETTI

ANTONIO SOLDATI

Il successo mondiale dei servizi Internet ed Intranet nel mercato delle tele-comunicazioni ha spinto, nell’ultimo decennio, gli Operatori del settore adinvestire maggiormente nella realizzazione di reti IP/MPLS (Multi ProtocolLabel switching) per trasportare qualunque tipo di servizio.Oggi, convogliare voce, video e dati su un’unica infrastruttura di trasportosi traduce in un requisito tecnico abbordabile, sfidante ed economica-mente vantaggioso in un mercato in continua crescita ed in regime diconcorrenza.Le attuali piattaforme di trasporto IP/MPLS di Telecom Italia Wireline sononate con questo obiettivo e, nei prossimi anni, estenderanno questo para-digma integrandosi progressivamente con la tecnologia dello strato di tra-sporto ottico.Nell’articolo viene descritto il backbone IP/MPLS di Telecom Italia Wirelinenel contesto dei servizi offerti, dell’evoluzione architetturale, della qualitàdel servizio ed, infine, del supporto al servizi telefonici.

1. Introduzione

“Tra non molti anni la mente umana ed i calcola-tori saranno interconnessi molto strettamente equesta alleanza uomo-macchina sarà in grado dipensare così come nessun essere umano ha maifatto finora, elaborando dati con prestazioni chesono ancora irraggiungibili per le macchine con cuieffettuiamo attualmente il trattamento delle infor-mazioni”.

Probabilmente Joseph Carl Robnett Licklider,uno studioso di psicoacustica meglio conosciutocome Lick, quando scrisse queste parole, raccoltein un saggio intitolato “Man-Computer Symbiosis”(simbiosi uomo-computer) negli anni 60, non imma-ginava di certo la portata delle sue parole. Neanchequando, nel lontano agosto del 1962, espose per laprima volta all’assemblea dei docenti del MIT

(Massachusetts Institute of Technology), la sua ideadi una “Galactic Network”, immaginava la reteInternet dei nostri giorni: una rete mondiale di com-puter interconnessi fra loro attraverso i quali tuttipotessero accedere facilmente e velocemente adati e programmi da ogni parte del globo.

Dalla rete ARPANET (figura1), che ne è conse-guita, ad oggi, i passi compiuti dalle telecomunica-zioni e nel mondo dell’informatica sono stati tanti enon è il caso ovviamente di ricordarli.

Il successo mondiale dei servizi Internet edIntranet nel mercato delle telecomunicazioni hacambiato radicalmente il modo di vivere di tuttinoi da molt i punt i d i v ista. Nel campo degl iOperatori tradizionali di telecomunicazioni le con-seguenze del successo delle reti Internet hannoavuto un riflesso tecnologico ed economico digrande portata.

PIATTAFORME

LANGELLOTTI › MASTROPIETRO › MORETTI › SOLDATI • Il Backbone IP di Telecom Italia Wireline.

62 NOTIZIARIO TECNICO TELECOM ITALIA › Anno 13 n. 2 - Dicembre 2004

Qualunque servizio Dati, Voce e Video puòessere veicolato oggi da un’unica piattaforma direte IP/MPLS, un cosiddetto Backbone unico pertutti i servizi. Gli impatti riguardano non soltanto iservizi di alto livello, ma anche le tecnologie tra-smissive e di commutazione del recente passato,veicolabili dal Backbone unico. Convogliare voce,video e dati su un’unica infrastruttura di trasportodati si traduce oggi in un requisito tecnico abbor-dabile, sfidante ed economicamente vantaggiosoin un mercato in continua crescita e in regime diforte competizione.

Il backbone unico IP/MPLS di Telecom ItaliaWireline nasce con questo obiettivo e nei prossimianni estenderà ulteriormente questo paradigma,integrandosi sempre di più con la tecnologia dellostrato di trasporto ottico, sia a livello di piano dicontrollo che di trasporto delle informazioni a pac-chetto.

Nel presente articolo viene descritto il back-bone IP di Telecom Italia Wireline nel contesto deiservizi offerti, dell’evoluzione architetturale, dellaqualità del servizio ed infine del supporto al servi-zio telefonico. In particolare, viene prima affrontatolo scenario dei servizi IP/MPLS, attualmente offertialle reti di accesso, per passare poi alla genesi edall’architettura funzionale e fisica del backbone equindi alla qualità del servizio offerta concludendo,infine, con l’impiego del backbone per i servizitelefonici Class4 e Class5.

2. I servizi IP/MPLS/TE per le reti di EDGE/GATEWAY

La piattaforma di trasporto IP/MPLS di TelecomItalia Wireline è composta da due backbone nazio-nali concepiti all’inizio del 2001 con due finalitàdiverse ma oggi convergenti:• OPB (Optical Packet Backbone), una rete multi-

servizio, nata come evoluzione della precedenterete IP denominata IBS (InterBuSiness) alloscopo di far convergere tutti i servizi dati e vocesu un'unica piattaforma;

• DTC (Data.com backbone), una rete dedicataalla sola clientela Executive.La rete OPB è stata modellata su 32 PoP per

concentrare tutte le tecnologie di accesso datiattualmente in campo nei principali nodi trasmissivinazionali.

La complessa operazione di migrazione dallaprecedente architettura ha richiesto circa treanni di intense attività di collaudo e di inseri-mento in rete. Da una semplice rete IP nazionaledi Router nata nel 1995 con i circuiti ATM a 34Mbit/s e a 155 Mbit/s, si è passati ad una reteIP/MPLS poggiata direttamente su uno stratotrasmissivo ottico a 2,5 Gbit/s e a 10 Gbit/s,epurata dalla componente di trasporto ATM econ funzionalità e prestazioni innovative chehanno già consenti to diversi important i t ra-guardi. Uno di questi è stato raggiunto nel 2003con l’offerta di un servizio di trasporto geogra-fico tra i Media Gateway del BBN (BackBoneNazionale) dedicati al traffico telefonico su IP,con garanzie di elevata protezione ai guasti tra-smissivi, di priorità di trattamento dei pacchettidurante i fenomeni di congestione della rete e disicurezza rispetto al resto del traffico dati veico-lato. Questo traguardo ha consentito la progres-siva dismissione della rete telefonica tradizionalenazionale a lunga distanza e l’integrazione deltrasporto del traffico dati IP con il traffico telefo-nico sulla piattaforma OPB [1].

Il prossimo sfidante traguardo è rivolto allesinergie tra le funzionalità dei backbone dati e larete di Trasporto ottico nazionale (OTN): realiz-zare una piattaforma di backbone per tutti i tipi diservizi fondata su due livelli e integrata, a livellod i p ian i d i cont ro l lo , t ra i nod i o t t ic i e iGigaRouter [2].

La rete DTC è stata invece concepita e realiz-zata negli anni 2000 - 2001 all’interno della busi-ness unit Data.com con l’obiettivo di offrire allaclientela Executive soluzioni innovative quali lereti di raccolta MAN GbE e le reti privati virtuali(VPN-MPLS).

Oggi la rete OPB costituisce il principale back-bone multiservizio per tutti i tipi di clientela, mentrela rete DTC è dedicata ancora alla sola clientelaExecutive. Questo ha consentito di arricchire il por-tafoglio dei servizi Executive con l’offerta “dualbackbone” in grado di garantire più elevati requisitidi affidabilità e di disponibilità di servizio grazie allapresenza di due backbone fisicamente separati mafunzionalmente equivalenti, ciascuno dotato di unpiano di controllo distinto.

FIGURA 1› La prima slide sulle reti IP (Fonte: Alex McKenzie).



La figura 2 sintetizza l’ar-t icolazione dei servizi adoggi attivi sulle due reti pub-bliche IP/MPLS di TelecomItalia Wireline.

I l backbone OPB sup-porta servizi di trasportoIP/MPLS sia per la clientelaExecutive/Business, (atte-stata nella rete di accessoattraverso tecniche ATM,Frame Relay, ADSL e GbE)che per la c l ientelaResidenziale (attestata viarete ADSL e dial-up); OPBfornisce inoltre un livello ditrasporto IP/MPLS per i ser-vizi telefonici su IP di tipoClass4 ( interconnessionenodi del BBN) e Class5(accessi VoIP) e per i servizidi interconnessione con gliIDC (Internet Data Center) diPomezia e Milano.

La rete OPB è diretta-mente col legata al le ret idegl i a l t r i ISP ( InternetService Provider) mediantepunti di peering “Privati” e“Pubblici” a seconda deicasi, realizzati generalmentepresso uno dei due puntineutri d’interconnessioneita l iani present i a Roma(NAMEX) ed a Milano (MIX).

L’interconnessione tra i due backbone è realiz-zata a Roma e a Milano, con collegamenti GbE perservizi IP ed SDH a 2,5 Gbit/s per i servizi VPN-MPLS, attuando in questo caso le funzionalità“Inter-AS-VPN” per le sedi cliente Executive atte-state in modalità “dual backbone”. La connettivitàverso la Big Internet, per tutte le destinazioni chenon siano interne oppure coperte dai Peeringappena citati, è ottenuta attraverso il backboneInternazionale di Telecom Italia Sparkle denominato“SEABONE”, il cosiddetto “Upstream Provider” peri backbone nazionali di Telecom Italia. Tutta la clien-tela nazionale, con o senza un proprio AutonomousSystem, per i servizi di tipo Full Internet o di VPNMPLS, accede ai backbone tramite apposite strut-ture di Edge (Router di Accesso, Router PE MPLS,NAS ADSL e NAS dial up) utilizzando le molteplicireti dedicate di accesso ATM, ADSL, GBE, SDH edISDN oggi disponibili.

3. L’architettura dei backbone IP

3.1 La genesi di OPB

L’attuale architettura della rete OPB è frutto diuna completa rivisitazione dell’architettura, siaf is ica che di rout ing, del l ’a l lora rete IBS(lnterBusiness).

Essa disponeva di 12 PoP (Point of Presence)distribuiti sul territorio nazionale e collegati geogra-ficamente ai due PoP principali di Roma e diMilano (dual-homing) attraverso circuiti PVC ATM,tipicamente dimensionati per qualche decina diMbit/s [3].

L’architettura di routing era basata esclusiva-mente sul protocollo OSPF, mentre il protocolloBGP era utilizzato soltanto per i punti di peering eper l ’ interconnessione con i l backboneInternazionale.

La nuova rete, costruita su 32 PoP nazionali, harivoluzionato l’architettura generale della rete:• trasformando il dual-homing dei PoP su base

geografica (Nord e Sud) in doppie attestazioniattuate verso Roma oppure verso Milano;

• creando altri nuovi 18 PoP, con un’architetturainterna analoga ma semplificata rispetto aquella dei 12 PoP presenti;

• dismettendo progressivamente i collegamentiATM, per iniziare il nuovo lento ma inesorabilepercorso di integrazione tra IP/MPLS e lo stratoottico;

• modellando il routing su un’architettura princi-palmente basata su BGP e OSPF per la topolo-gia della rete.Inoltre, i PoP di Roma e Milano hanno subito un

radicale cambiamento per permettere il nuovo“dual-homing” dei PoP, per raccogliere la cre-

M

M

MAN

GBE

MAN G

BE

Seabone

InternetData

Center

Voice GWCL 4 BBN(23 PoP)

Nodi diControllo CL5(Inner Core)

ClienteVoIP CL5

ClienteResidenziale

(ADSL e Dial-up)

ClienteExecutive

(ATM e MAN)

ClienteExecutiveDual BB

ClienteExecutiveVia ATM

ClienteExecutive

Via MAN GBE

Internet

PeeringNazionali

BackboneDTC

Edge DTC

Edge IBS

OPB

ADSLATMBBCL

DTCGBEGWIBS

MANOPBPoPVoIP

============

Asymmetrical Digital Subscriber LineAsynchronous Transfer ModeBackBoneClass 4 e Class 5Data.comGigaBit EthernetGatewayInternet BuSinessMetro Area NetworkOptical Packet BackbonePoint of PresenceVoice over IP

FIGURA 2› L’articolazione dei servizi sui due backbone IP Pubblici.



scente clientela locale e per abilitare nuovi servizi(come ad esempio il BBN).

Da un singolo PoP a Roma e a Milano si sonodapprima divise le funzionalità su due macchinedistinte (PoP Splitting), poi si sono raddoppiati iPoP (PoP Doubling) giungendo così alla creazionedi quattro PoP completamente autoconsistentidetti di Inner Core.

La tecnologia impiegata ai tempi di IBS eraprincipalmente della classe Cisco 7500, con capa-cità di switching tipicamente intorno ai 500 Mbit/s;nella fase di “PoP Splitting” (sdoppiamento deicentri stella di Roma e Milano per ragioni di “disa-ster recovery”) sono appars i in rete i pr imiGigaSwitchRouter Cisco (GSR) della classe 12000,con capacità pari a 60 Gbit/s (12012) e con archi-tettura interna completamente distribuita dove ilprocessore centrale è responsabile del piano dicontrollo e le singole schede di quello di forwar-ding dei pacchetti . Oggi la rete OPB uti l izzaessenzialmente tecnologia GSR Cisco (12016,12416), con capacità di switching variabili da 80 a320 Gbit/s.

La migrazione su rete SDH/DWDM dell’infra-struttura trasmissiva per tutti i 32 PoP ha richiestonuovi circuiti trasmissivi a 155 Mbit/s, 2,5 Gbit/s ea 10 Gbit/s, a seconda della dimensione e neces-sità di ciascun PoP.

La riorganizzazione del routing ha consentito,nel tempo, l’abilitazione di nuove importanti funzio-nalità quali (figura 3):

• il trasporto del traffico MPLS nella sua compo-nente base denominata “Provider Router” (“P”,giugno 2001, [4, 5]);

• l’abilitazione della componente “MPLS TrafficEngineering” a supporto del traffico voce BBN(“MPLS-TE”, giugno 2002, [6]);

• l’abilitazione della Qualità del Servizio per retiIP/MPLS a supporto del traffico voce BBN (“QoSDiffServ”, giugno 2002);

• l’attivazione delle componenti “MPLS-VPN” per larealizzazione di Reti Private Virtuali (Provider Edge);

• l’interconnessione tra le reti VPN di diversiAutonomous System nell’ambito dell’offerta“dual backbone” (“Inter-AS VPN”, luglio 2002).Attualmente, sono attivi su OPB più di 2.000 tun-nel MPLS-TE per il BBN, realizzati in magliacompleta su 23 PoP in modalità FRR (Fast Re-Routing) per assicurare un rapido ripristino deitunnel in caso di guasti sul backbone.Le altre componenti indicate in figura ed in

corso di approfondimento per un eventuale utilizzoin rete, riguardano:• il trasporto di altre VPN MPLS all’interno delle

VPN MPLS (Carrier Supporting Carrier, CSC);• il routing Multicast all’interno delle VPN (MPLS-

VPN);• il supporto su base geografica alle VPN di

livello 2 (Layer 2 VPN);• il trasporto di altre tecnologie su MPLS (Any

Transport Over MPLS).

3.2 L’architettura della rete OPB

Il backbone OPB (Optical Packet Backbone) èarticolato su 32 PoP nazionali, una topologia adoppio centro stella e la distinzione tra PoP diInner Core ed Outer Core (figura 4). L’Inner Core ècostituito dai due PoP di Roma e i due PoP diMilano, mentre l ’Outer Core è incentrato suirestanti 28, collegati in “dual-homing” a Romaoppure a Milano sulla base della loro localizzazionegeografica.

Il “dual-homing” dei 28 PoP di Outer Core suiCentri Stella è stato reso ancora più affidabile rad-doppiando i PoP di Roma e Milano su centralidiverse ed attestando ciascuno dei PoP Outer Corecon almeno 2 circuiti trasmissivi ai 2 PoP InnerCore (Milano Bersaglio e Milano Malpaga oppureRoma Inviolatella e Roma CTRL). A livello trasmis-sivo i nodi di OPB sono collegati fra loro attraversola rete ottica di trasporto nazionale, con circuitiDWDM punto-punto a 2,5 Gbit/s (STM-16) e a 10Gbit/s (STM-64) e con circuiti SDH a 155 Mbit/s(STM-1), tutti attestati su interfacce di tipo POS(Packet Over Sonet).

Come viene descritto in seguito, la rete è stataprogettata per essere completamente ridondata intutte le sue componenti ed immune a condizioni disingolo guasto, quale ad esempio il guasto di unRouter, di una singola scheda o di un circuito tra-smissivo. In caso di doppio guasto contemporaneoè attiva la funzionalità QoS/CoS (Quality of Service,Class of Service) per salvaguardare i servizi piùpregiati.

Inter-ASVPN

CcS MulticastMPLS-VPN

Layer 2 VPN

VPN MPLS/BGP (PE) Any Transportover MPLS

TrafficEngineering

DiffServQoS

DiffServaware TE

MPLS Funzionalità P(con architettura iBGP)

introdotta in rete

validata in test plant

in fase di studio

Funzionalità

ASCSCiBGP

MPLSPE

QoSVPN

TE

========

Autonomous SystemCarrier Supporting Carrierinternal Border Gateway ProtocolMulti Protocol Label SwitchingProvider EdgeQuality of ServiceVirtual Private NetworkTraffic Engineering

FIGURA 3› Le componenti funzionali del backbone OPB.



L’architettura attuale è costituita da:• 4 PoP Inner Core, equipaggiati ciascuno con

quattro circuiti STM-64, due geografici tra Romae Milano e due metropolitani nelle stesse città;

• 2 PoP Outer Core equipaggiati ciascuno concircuiti STM-64 (Padova, Torino);

• 24 PoP Outer Core equipaggiati con due circuitiSTM-16 (Alessandria, Ancona, Bari, Bergamo,Bologna, Bolzano, Brescia, Cagliari, Catania,Catanzaro, Firenze, Genova, Modena, Napoli,Nola, Palermo, Perugia, Pescara, Pisa, Rimini,Taranto, Trieste, Venezia, Verona);

• 2 PoP Outer Core equipaggiati con circuitiSTM-1 (Como, Savona).Il principale requisito di progetto alla base del

dimensionamento dei circuiti impone un limite sultraffico massimo complessivo per ciascun link parial 50% in modo da essere immuni ad una condi-zione di singolo guasto. La capacità di trasportointerna complessiva netta risultante è pari a circa80 Gbit/s1.

3.2.1 Inner Core

L’Inner Core è articolato sui 4 PoP diRoma e Milano, indipendenti ed autocon-sistenti (figura 5), ognuno dei quali conapparati Cisco GSR che ricoprono i lruolo di:•Centro Stella (CS) per l’attestazione deicircuiti verso i PoP dell’Outer Core;•Transito (T) verso le strutture diEdge/Accesso; •Gateway Internazionali (ITZ) per la termi-nazione dei collegamenti verso i PoP diSeabone;•Gateway (P) verso i punti di Peeringnazionali.I quattro PoP si poggiano su un doppioquadrilatero di circuiti trasmissivi a 10Gbit/s (STM-64) per le quattro dorsaliRoma-Milano. Oltre ai col legamentiPOS (Packet over SDH) [7], sono attivicollegamenti metropolitani in tecnologia10 GigabitEthernet ridondati allo scopodi in terconnet tere i quat t ro CentroStella ai Gateway Internazionali e diPeering e di bilanciare il traffico all’in-terno della rete.

Tutti i PoP dell’Outer Core sono atte-stati ad una coppia di apparati CiscoGSR dell’Inner Core con funzione di CS(Centro Stella). Per aumentare ulterior-mente l’affidabilità, poi, ogni PoP di InnerCore è completamente ridondato ed i col-legamenti provenienti dai PoP di OuterCore sono distribuiti su due coppie dinodi GSR.

Con riferimento alla figura 5, un gene-rico PoP Outer Core attestato all’Inner Core diMilano, ad esempio, dispone di collegamenti verso irouter Centro Stella CS1 e CS4, oppure verso CS2e CS3.

I quattro PoP di Inner Core, oltre a raccogliere edistribuire il traffico per tutta la rete, hanno il com-pito di aggregare il traffico ed i servizi localmenteper Roma e Milano, utilizzando le strutture di Edgededicate ai servizi Executive/Business o Residenziali(figura 6).

Un generico PoP di Inner Core rispetto ad unodi Outer Core dispone di:• uno dei quattro punti di “uscita” della rete dal

proprio Autonomous System per la connetti-vità verso altri ISP nazionali e la Big Internetattraverso Seabone, ut i l izzando due GSRdedicati (GW);

• di due VLAN di Transito a 10 GbE implementatesu di una coppia di Catalyst Cisco 6513, perforn i re la connett iv i tà a 10 Gbit /s con iGateway verso SEABONE ed i Peering. LeVLAN di Transito superano inoltre il confine delPoP per interconnettersi al PoP gemello a livellometropolitano in modo da permettere il bilancia-mento del traffico all’interno della rete.Tutti iGSR con tecnologia a 10Gbit/s (CS, ITZ e P)sono dei Cisco 12416.

TO

AL

SVGE

Milano

COBGBS

BZ

PoP OPB di Inner Core (2 a Roma, 2 a Milano)

PoP OPB principali (8)

dorsale a 2.5 Gbit/s (2 circuiti su router/PoP)

dorsale a 155 Mbit/s (2 circuiti su router/PoP)

dorsale Roma <--> Milano 2 circuiti a 10 Gbit/s

TS

VEPDVRBOMO

FIRN

PGPIAN

PERoma

BA

TA

NolaNA

CZ

CTPA

CA

GSRPoPOPB

===

Gigabit Switch RouterPoint of PresenceOptical Packet Backbone

PoP OPB secondari (20)

dorsale a 10 Gbit/s

•32 PoP, circa 100 GSR Cisco• 4 PoP Inner Core a 10 Gbit/s in dual homing (2 x STM-64 x PoP)• 2 PoP Outer Core a 10 Gbit/s in dual homing (2 x STM-64 x PoP)•24 Pop Outer Core a 2,5 Gbit/s in dual homing (2 x STM-16 x PoP)• 2 PoP a 155 Mbit/s in dual homing (n x STM-1 x PoP)•80 Gbit/s di capacità netta interna (80% del totale)•13 Gbit/s verso la Big Internet (10 x STM-16 x 80%)•12 Gbit/s per peering privati e pubblici (80% del totale)

FIGURA 4› L’architettura del backbone OPB (12/2004).

(1)Si tratta della capacità utile, valutata con l’equazione:24 PoP • 2 circuiti per PoP • 2,5 Gbit/s a circuito • 0,5 = circa 60 Gbit/s,a cui va sommato l’altro contributo:2 PoP • 2 circuiti per PoP • 10 Gbit/s a circuito • 0,5 = circa 20 Gbit/s.



3.2.2 Outer Core

L’Outer Core è costituitoda 28 PoP nazional i ,Pr incipal i o Secondari aseconda che si tratti di sedicon maggiori o minori inte-ressi di traffico.

Dal punto di vista funzio-nale entrambi i tipi di PoPdel l ’Outer Core hanno lestesse caratteristiche e ciòche li differenzia è la pre-senza di uno o due livelli diGigarouter.

L’architettura degli ottoPoP Principali (BA, BO, BS,FI, NA, PA, PD, TO) è illu-strata in figura 7. I due livellidi router nei PoP Principali,denominati Edge ed Core,sono collegati localmente inmaniera ridondata con velo-cità STM-16 e, tenuto contoche, secondo i criteri di pro-getto, i quattro collegamentidevono essere caricati sin-golarmente non più del 50%della loro capacità netta, nerisulta una capacità com-plessiva di traffico internapari a 5 Gbit/s.

Il livello Core vede i rou-ter di Centro Stella dell’areaInner Core su collegamenti avelocità STM-16, mentre ill ivello Edge di tutti i PoPOuter Core vede le strutturedi “Accesso”, indicate infigura 7 con la sigla EDGEIBS (da non confonderli coni GSR di Edge di OPB), sucollegamenti Fast Etherneto Gigabit Ethernet.

Le strutture di “Accesso”in questo contesto corri-spondono ad apparat i dilivello 3 (ovvero routing IP enon switching di livello 2)attraverso i quali vengonoserviti i clienti finali oppureerogate component i diServizio/Controllo. A talescopo una coppia di appa-rati Catalyst Cisco 6509,denominat i “CatalystInfrastrutturali”, realizzanodue VLAN di accesso, indivisione di carico e com-pletamente ridondate, per leseguent i strutture di“Accesso”:•Edge Executive, attraverso

STM-16

STM-16 STM-16

STM-16

POSStm-64

POSStm 64

Mila

no B

ersa

glio

Mila

no M

alpa

ga

Rom

a S

ud

Rom

a In

viol

atel

la

ITZ 1 ITZ 2

2 x 10 GE

2 x 10 GE

E2/T2

E2/T2

E1/T1

E1/T1

E2/T2

E2/T2

E1/T1

E1/T1

POS STM-64

POS STM-64

CS 4CS 1

CS 1

CS 3

CS 3

CS 2

Inner Core OPB

CS 2

P1 P2

ITZ 1 ITZ 2P1 P2

CS 4

CSE

GBEITZ

PPOS

T

=======

Centro StellaEdgeGigaBit EthernetInternazionalePeeringPacket Over SDHTransito

FIGURA 5› L’architettura dell’Inner Core di OPB.

EDGE IBS

STM-16

V

ITZ

P CS1

10GE

verso altro PoP CSVLAN TRS (3 e 4)

verso altro PoP CSVLAN ITZ (5 e 6)

10GE

10GE

GEGE

GE FE

FE

GE/FE

Cat6513

Cat6509

Route Reflector/Transiti per server

PoP CL4 BBNo VoIP CL5

NAS dial-upNAS ADSLEdgeExecutive

CS2

E1/T1E2/T2

STM-1ATMe GE

ADSLCSFEGEIBSITZ

NASPoPTRS

VLANVoIP

===========

Asymmetrical Digital Subscriber LineCentro StellaFast EthernetGigabit EthernetInterBuSinessInternazionaleNetwork Access ServerPoint of PresenceTransitoVirtual Local Area NetworkVoice over IP

PoP

FIGURA 6› L’architettura interna dei PoP di Inner Core.



Router di Accesso (RA) per i servizi Full Internete Router PE (Provider Edge) MPLS-VPN per iservizi Hyperway (appa-rati Cisco 7500 o 10Koppure apparati JuniperM20;

• NAS ADSL per clientelaResidenziale o smallBusiness (apparati Cisco6400 o 10K oppureJuniper ERX);

• NAS dial-up delle [email protected] (apparti APX8000Lucent). Il criterio di ripar-tizione del traffico è effet-tuato bilanciando i pac-chetti IP/MPLS sui quat-tro diversi percorsi, tra irouter di Accesso ed iprimi due GSR di OPB, subase “flusso” utilizzandoun algoritmo di hashingche tiene conto degli indi-rizzi di sorgente, destina-zione e porte TCP/UDP.Sono invece direttamente

connessi ai GSR di Edge iVoice Gateway MGX dellarete BBN (nodi Class4 ditransito della rete telefonicapubblica), su collegamentilocali STM-1 ATM e GbE.

L’architettura dei 20 PoPSecondari è mostrata infigura 8, dove i livelli di Coreed Edge coincidono con unasingola coppia di GSR (dettiCore/Edge), ma dove le fun-zionalità supportate, comegià evidenziato, rimangonole stesse.

3.2.3 Routing

3.2.3.1 Routing Unicast

La rete OPB è costituitada due AS (AutonomousSystem), AS6664 e AS3269,il primo ereditato dall’era diIBS ed in via di dismissione,mentre il secondo rappre-senta il dominio principalesul quale sono state svilup-pate tutte le nuove tecnolo-gie e funzionalità.

Come già anticipato, lagenesi del backbone OPBdalla precedente rete IBS hacomportato una complessariorganizzazione del routingdell’AS 3269. La riorganiz-zazione è stata necessariaper superare l’instabilità ed i

limiti di scalabilità dovuti all’utilizzo del protocolloOSPF per la propagazione delle informazioni di

V

BB OPBEDGE IBS

STM-16

STM-16

STM-16

STM-16

E2 C2

Cat6509

ATM

Cat6509

GSREdge

GSRCore

PoPInner Core

E1 C1

CS

CS

Stm 1 AT

M e GE

ISDN

ATMGBE

GE

GE

GE

NAS ADSL

EdgeExecutive

NASdial-up

PoP BBN CL4

GE/FE

FE

ADSLATMBB

CE

FEGE

GSRIBS

ISDNNASOPBPoP

=============

Asymmetrical Digital Subscriber LineAsynchronous Transfer ModeBackBoneCoreEdgeFast EthernetGigabit EthernetGigabit Switch RouterInterBuSinessIntegrated Services Digital NetworkNetwork Access ServerOptical Packet BackbPoint of Presence

FIGURA 7› L’architettura degli otto PoP Principali di Outer Core.

V

BB OPBEDGE IBS

STM-1/16

STM-1/16

E2/C2ATM

Cat6509

GSRCore/Edge

PoPInner CoreE1/C1

CS

CS

Stm 1 AT

M e GEISDN

ATMGBE

GE

GE

GE

NAS ADSL

EdgeExecutive

NASdial-up

PoP BBN CL4

GE/FE

FE

ADSLATMBBCSFE

GBEGE

GSRIBS

ISDNNASOPBPoP

=============

Asymmetrical Digital Subscriber LineAsynchronous Transfer ModeBackBoneCentro StellaFast EthernetGigaBit EthernetGigabit EthernetGigabit Switch RouterInter BuSinessIntegrated Services Digital NetworkNetwork Access ServerOptical Packet BackbPoint of Presence

PoP

FIGURA 8› L’architettura degli venti PoP Secondari di Outer Core.



routing relative alle network dei clienti, nonché perconsentire l’introduzione della tecnica MPLS inrete. Per approfondimenti sui tipi di protocolli siveda il riquadro di approfondimento “I protocolli dirouting”.

Si è scelto di adottare il protocollo iBGP [10]per la distribuzione delle informazioni di routingrelative alle reti Cliente, ed il protocollo OSPF perla distribuzione delle informazioni per la raggiun-gibilità degli apparati. La complessità delle opera-zioni ha richiesto lo svolgimento delle attività intre fasi:• nella prima è stata introdotta la nuova architet-

tura di routing iBGP nella rete di backbone e diaccesso, ad eccezione delle configurazioni rela-tive ai clienti finali;

• nella seconda è avvenuta la migrazione deiclienti di IBS sulla nuova architettura di routine;

• nella terza è stato bonificato il routing OSPFall’interno del backbone, passando da una com-plicata configurazione OSPF multi-processo aduna configurazione multi-area di nuova conce-zione dette Aree NSSA (Not So Stubby Area). Sisono così combinati i punti di forza di due proto-colli di routing, ovvero la capacità di calcolare ilpercorso ottimo del protocollo OSPF, configu-rato in un’architettura a 32 aree periferiche edun’area zero di backbone, e la capacità del pro-tocollo BGP di gestire e “manipolare” un elevatonumero di rotte (indirizzi aggregati IP) assicu-rando un’effettiva scalabilità della rete. In altreparole, con il protocollo OSPF si calcola la rag-giungibilità di tutti i nodi della rete utilizzando leloopback degli apparati (internal route) e con ilBGP si propagano gli annunci delle rotte versole reti dei Clienti.

I PROTOCOLLI DI

ROUTING

Il protocollo OSPF

Il protocollo OSPF (Open ShortestPath First) è un protocollo di instrada-mento IGP (Interior Gateway Protocol,cioè progettato per il routing all’in-terno di un Autonomous System ) ,standardizzato in ambito IETF nellaRFC 2328 [8]. Tale protocollo, a diffe-renza di altri, (ad esempio RIP), chesono di tipo distance vector, è di tipolink-state. Ciò in pratica significa chei router attivi tra di loro collegati, almomento dell’accensione oppure aseguito di variazioni topologiche, siscambiano informazioni relative sola-mente allo stato delle network affe-renti a quei dati router ed ai router adessi adiacenti. In questo modo cia-scun router costruisce un databasetopologico della rete (replicato su tuttii router del dominio), a partire dalquale, indipendentemente dagli altri,si costruisce la sua tabella di routing.L’instadamento finale è scelto indivi-duando, mediante l ’algoritmo diDijkstra, il percorso di rete a costominimo.Nella configurazione del protocollo inun dominio con un elevato numero dirouter, è possibile partizionare la retein aree di dimensioni più piccole, inmodo che siano presenti un’area dibackbone, nota come area 0, e dellearee periferiche connesse alla prece-dente.

Il protocollo BGP

Il BGP (Border Gateway Protocol) è unprotocollo di t ipo EGP (ExteriorGateway Protocol) che è usato perscambiare le informazioni di raggiun-gibi l i tà del le reti di autonomoussystems distinti (external BGP) oppuredelle reti afferenti a diversi routerinterni ad un singolo autonomoussystem (internal BGP). La versione delprotocollo correntemente utilizzata inInternet è definita nella RFC 1771. Irouter tra i quali viene stabilita unasessione BGP vengono detti peer.Il protocollo BGP e' implementato suTCP e non direttamente su IP. Il van-taggio principale di cio e' la delega alTCP di tutte le funzioni di controllo dierrore, ritrasmissione e frammenta-zione. Al momento dell’instaurazionedi una sessione BGP, dopo che i rou-ter con i messaggi di open hannoconcordato i parametri della connes-sione, si scambiano l’intera tabellaBGP su di essi memorizzata.Successivamente, invece, vengonoinviate solo delle notifiche per segna-lare le variazioni sulla di raggiungibi-lità delle reti Internet.Le informazioni scambiate tra peerBGP sono accompagnate da una seriedi attributi, dei quali alcuni opzionali,che consentono sia l’implementazioneautomatica di algoritmi per la preven-zioni di loop e sia la propagazionedelle politiche di routing.Nella RFC 2858 [9], all’implementa-zione iniziale del protocollo sonostate aggiunte ulteriori funzionalitàutili per l’abilitazione di alcuni tipi diservizi , qual i i l mult icast inter-Autonomuos System e le VPN-MPLS.

Il protocollo PIM

Il protocol lo PIM (ProtocolIndipendent Multicast) è un proto-col lo di instradamento mult icaststandardizzato in ambito IETF nellaRFC 2362. Lo standard PIM supponeche i percorsi tra sorgente e destina-zione siano simmetr ic i e ut i l izzaquindi le stesse informazioni conte-nute nella tabella di instradamentounicast.Il protocollo opera in due modalità:nel “dense mode” utilizza algoritmi diinstradamento del tipo Reverse PathForwarding, dove router per routervengono coinvolte nel multicast solole interfacce che rispettano il vincolodel percorso più breve tra Sorgente eDestinazione; nella modalità “sparsemode” si effettua la distribuzione deipacchetti minimizzando il numero dirouter coinvolti, con una dichiara-zione esplicita dei router di adesioneal multicast, contrariamente all’altramodalità dove il multicast è presentesu tutte le interfacce dei router edove spetta a ciascun router esclu-dere quelle interfacce non interessate.



L’implementazione BGP è stata corredata dal-l’importante funzionalità di RR (Route Reflector),secondo la raccomandazione IETF RFC 1966 [11],per evitare una maglia completa di relazioni iBGPtra tutti i router del backbone. Tutti i router (Client)hanno una relazione di peering iBGP con unServer, il Route Reflector, che ha il compito diannunciare a tutti gli altri le rotte apprese da unparticolare Client. La propagazione di un annuncionon è trasparente, ma avviene a seguito di un pro-cesso decisionale che può filtrare e modificare gliattributi degli annunci.

L’architettura iBGP è stata inizialmente basatasu un modello gerarchico di Route Reflector a duelivelli: il “Top Level RR” realizzato su router Cisco7200 dedicati, il secondo livello di RR sui GSR deiPoP di OPB. Le migliorie sulla scalabilità introdottenel BGP e nel Sistema Operativo Cisco (IOS)hanno consentito, nel corso del 2003, di passaread un’architettura ad un solo livello gerarchico diRR dove:• gli elementi di Edge per i servizi Full Internet e i

tutti i GSR di OPB hanno attive due sessioni sudue degli otto RR Cisco 7200 dedicati;

• ognuno dei RR ha attiva una relazione iBGP contutti gli altri. In questo contesto il piano MP-BGP (MultiProtocol BGP) per i servizi VPN-MPLS non fa parte del piano di controllo di OPBma si appoggia su un’architettura di RouterReflector MP-BGP dedicata. Il modello BGPadottato consente la propagazione a tutti i GSRdi OPB delle sole rotte nazionali, costituite dallenetwork interne, dei propri clienti e da quelledei Peering Pubblici e Privati di OPB.Per inciso, a parte i Gateway verso Seabone,

gli apparati GSR di OPB non possiedono la FullInternet Table, ovvero la tabella di routing costi-tu i ta da tut t i i pref iss i mondia l i present i suInternet, ma soltanto il sottoinsieme delle rottenazionali; per le rotte dirette fuori dal backbone, èconfigurata una rotta di default, iniettata via pro-tocollo OSPF, verso i quattro Gateway internazio-nali (GW-ITZ). D’altro canto, è ragionevole che unpacchetto che non sia dest inato al dominiointerno oppure ad un peering sia destinato a qual-che rete raggiungibile tramite l’upstream providere dovrà quindi necessariamente essere traspor-tato verso il Gateway Internazionale più vicinogeograficamente.

Un discorso opposto viene fatto per l’area EdgeExecutive, legata in particolare ai servizi FullInternet, dove i clienti con proprio AS (detti AS-Client) hanno bisogno della “Full Internet Table”.

Tornando al paradigma generale, ciascun ele-mento di Accesso/Edge si fa carico di annunciarele reti (network) dei clienti ad esso attestati, avendocura di scrivere nel campo next hop l’indirizzo dellapropria interfaccia di loopback.

In questo modo ogni altro router, per raggiun-gere una certa destinazione, deve inoltrare i pac-chetti all’indirizzo del next hop, ovvero al routerche ha originato l’annuncio e sarà compito diquesto istradare i l pacchetto verso i l cl ientefinale.

La raggiungibilità delle interfacce di loopbackdegli elementi di Accesso è assicurata dalle istanzedel protocollo OSPF.

L’architettura gerarchica scelta per il proto-collo OSPF divide l’area di backbone dalle aree diperiferia:• l’area di backbone (area 0) è costituita da tutti i

router del backbone propriamente detto, daiRR, GW-ITZ e dai router di peering, ivi compresiquelli dislocati nelle sedi NAP;

• le aree periferiche sono numerate in manieratale da individuare univocamente ciascuno dei32 PoP OPB e comprendono tutti gli apparati diaccesso (RA, PE MPLS e NAS, inclusi i GSR dicollegamento al BackBone), ad eccezione degliapparati di transito del BBN inseriti in un pro-cesso OSPF a loro dedicato. I punti di contatto tra area 0 e area periferica

sono realizzati a livello di piano di controllo attra-verso i cosiddetti Router “ABR” (Area BorderRouter) e coincidono su OPB con i GSR di EDGEnei PoP a due l ivel l i (pr incipal i ) , con i GSRCORE/EDGE nei PoP ad un livello (secondari)oppure con i GSR di Transito nei PoP di Inner Core.

I GSR ABR sono infatti appartenenti contempo-raneamente sia all’area 0 che all’area periferica.

Per aumentare ulteriormente la scalabilità del-l’architettura, è stata utilizzata una tipologia diarea detta NSSA (Not So Stubby Area) che pos-siede dei meccanismi di filtraggio per controllarel’iniezione degli annunci OSPF da e verso un’areaperiferica.

In particolare, l’unica informazione che devenecessariamente transitare tra le aree, a partealcuni casi particolari per servizi di load balancing,è l’informazione per la raggiungibilità degli appa-rati (ovvero le network relative alle interfacce diloopback).

Tutte le altre informazioni di routing propagatein area 0 vengono filtrate dagli apparati con fun-zione di ABR: con questi accorgimenti implemen-tati in rete si è in grado di minimizzare la propaga-zione delle perturbazioni di routing in zone remotedella rete.

La peculiarità OSPF di essere un protocollo ditipo “link state”, ovvero di controllo dello stato diun collegamento tra due Router, consente inoltrel’ottimizzazione dell’instradamento del trafficointerno alla rete.

Gli annunci su OSPF dei link connessi agliapparati vengono gestiti con una metrica inversa-mente proporzionale all’effettiva banda fisica: inquesto modo le relazioni di traffico vengono instra-date in rete selezionando il cammino di rete checomplessivamente offre la maggior disponibilità dibanda potenziale. L’interworking tra i protocolliBGP ed OSPF è illustrato schematicamente nellafigura 9.

Dal punto di vista dello sviluppo infrastruttu-rale, a partire dal 2003, si è stabilito che l’amplia-mento della banda d’interconnessione tra OPB eSeabone debba avvenire esclusivamente su diret-trici STM-16, mirando ad un progressivo rilasciodei circuiti di gerarchia inferiore.



Tale scelta ha trovato piena giustificazione allaluce dei seguenti fattori:• trend di crescita del traffico internazionale di

gran lunga superiore alle previsioni;• comparazione dei costi tra collegamenti STM-1

e STM-16;• necessità di ottimizzare l’occupazione di risorse

trasmissive (line card e circuiti) e di semplificarele politiche di routing BGP, mediante aggrega-zione dei traffici generati dalle diverse tipologiedi servizio “affini”.Per ottenere la segregazione del traffico rela-

tivo alle diverse tipologie di servizio, gli annuncidelle reti vengono diversificati in uscita sulla basedegli attributi BGP (denominati communities )imposti dal router da cui sono originati. I PoPInner core della stessa città lavorano in loadbalancing con reciproco back up, ovvero l’in-sieme delle reti annunciate da OPB sono ripartitefra i 4 GW-ITZ e le reti che un certo GW-ITZannuncia verso Seabone con metrica preferen-ziale sono anche annunciate, con metrica sfavo-rita, dall’altro GW-ITZ della stessa città e vice-versa. In questo modo, in condizioni normali difunzionamento, il traffico che rientra verso unarete cliente di OPB transita solo per il link a 2,5Gbit/s a cui quella stessa rete è assegnata, men-tre in caso di perdita di connettività tra un GW-ITZ e il router Seabone, il traffico verrebbe auto-maticamente reinstradato verso l’altro GSR omo-logo della stessa città.

Per ottenere il bilanciamento del traffico inuscita da OPB e diretto verso Seabone, si utilizzauna particolare configurazione di anycast routingdove la subnet comune è quindi annunciata inOSPF dagli stessi GW-ITZ.

La configurazione anycast si basa sull’imposta-zione del next-hop BGP delle route Internet pari adun indirizzo IP comune a tutti i quattro GW-ITZ edannunciato da questi ultimi in OSPF. Questa confi-gurazione e la simmetria dell’architettura di OPBconsentono di ripartire equamente il traffico direttoalla Big Internet fra tutti i quattro punti di intercon-nessione con Seabone.

3.2.3.2 Routing Multicast

Allo scopo di supportare l’offerta commercialedenominata YourCh@nnel, rivolta alla ClientelaBusiness e ai Content Provider, per la distribu-zione di propri servizi su Internet in maniera diffu-siva, alla fine del 2000 è stata introdotta la funzio-nalità di routing multicast sulle reti IP/MPLS.

Il trasporto in “multicast” è una tecnica effi-ciente per trasmettere la stessa informazione aduna moltitudine di riceventi, ottimizzando l’im-piego di banda e di risorse di elaborazione nellereti di telecomunicazioni. La distribuzione ottimaledel le in formazioni verso i r icevent i avv ienesecondo una topologia ad albero in cui la radicerappresenta la sorgente e le foglie corrispondonoai riceventi.

Gli algoritmi di instradamento multicast evitanola duplicazione dei dati lungo i rami dell’albero chevengono attraversati da più di uno dei percorsidiretti alle diverse destinazioni.

Oltre a limitare l’occupazione di banda, il multi-cast permette di raggiungere un numero virtual-mente illimitato di riceventi in quanto la sorgenteemette comunque un unico flusso e non vienesovraccaricata dalla presenza simultanea di piùdestinatari.

L’attivazione in rete del servizio multicast harichiesto:• la configurazione del protocollo di routing multi-

cast PIM v2 (Protocol Indipendent Multicast,versione 2) [12] in modalità sparse mode su tuttigli apparati e le interfacce di backbone;

• l’attivazione della funzionalità di RP (Rendez-Vous Point ) su una coppia di apparati delbackbone, per la raccolta delle richieste diadesione ai gruppi multicast da parte dei rice-venti e delle richieste di trasmissione da partedalle sorgenti;

• la conf igurazione del protocol lo MSDP(Multicast Source Discovery Protocol) [13] sugliRP per la sincronizzazione delle informazionirelative alle sorgenti attive;

• la conf igurazione del protocol lo IGMP v2(Internet Group Management Protocol, versione2) [14] sui router di accesso al backbone perl’adesione e l’abbandono di una sessione mul-ticast da parte degli utilizzatori finali. La sceltadi avere una coppia di apparati di backbonecon funzioni di Rendez-Vous Point è stata gui-data da questioni di ridondanza.I due RP sono stati identificati mediante lo

stesso indirizzo IP anycast e tale indirizzo è confi-gurato in maniera statica sui router di accesso,punti di connessione di sorgenti e destinazioni.

ATMiBGPNET

OSPF

====

Asynchronous Transfer Modeinternal Border Gateway ProtocolNetworkOpen Shortest Path First

OSPF3269

iBGP3269

Loop 1Loop 2

Loop 3

Loop 1via

ATM 1/1

NETX

Y via Loop 3

Y via Loop 3

NETYForwarding Plane

Control Plane

Traffico

Int ATM 1/1

Router iBGP 3269redistribute static.............IP route Y ATM 0/0.101

FIGURA 9› L’Interworking tra i protocolli BGP e OSPF.



In tal modo, sia la sorgente che le destina-zioni interessate al flusso multicast, possonoraggiungere sempre il RP attivo più vicino utiliz-zando le tabelle di routing unicast (OSPF perOPB, IS-IS per DTC). L’indisponibilità di uno deidue viene quindi coperta dall’altro RP grazie alfatto di aver assegnato ad entrambi gli RP lostesso indirizzo IP. Per questioni architetturali suOPB sono stati scelt i come RP due apparatiGSR di Centro Ste l la , uno a Roma e uno aMilano.

3.2.4 Catalyst e Gateway

Gli apparati Catalyst della infrastruttura di OPBsvolgono due compiti fondamentali:• consentono l’interconnessione al backbone

degli apparati di accesso e di Edge attraversole VLAN di accesso presenti nei 32 PoP diOPB;

• supportano il traffico di transito al backbone neiNodi di Inner Core a Roma e Milano verso i nodidi peering, Internazionale e IDC, attraverso leVLAN di transito.Dal punto di vista del routing, la modalità stan-

dard di attestazione ad OPB prevede che gli ele-menti di Accesso e/o Edge siano:• configurati sulle VLAN di “Accesso” di OPB con

interfacce GE/FE e con indirizzo IP della sotto-rete logica IP (LIS) delle VLAN;

• conosciuti su OPB via OSPF nell’area NSSAesclusivamente per la propria loopback e leproprie interfacce verso i Catalyst;

• in grado di annunciare in iBGP ai RouteReflector Server gli aggregati delle reti deiclienti/sistemi a loro attestati, utilizzando perl’indirizzo di next hop BGP la loopback dell’ap-parato di accesso.Come alternativa al protocollo OSPF, è possibile

configurare sui GSR di OPB delle statiche, poidistribuite in iBGP e come alternativa al i-BGP èpossibile configurare sempre sui GSR di OPB dellestatiche per gli aggregati delle reti cliente. In ognicaso i Catalyst Infrastrutturali di OPB si aspettanodi raccogliere traffico esclusivamente da apparatidi Accesso/Edge di livello 3 (routing IP) e non daSwitch Ethernet di livello 2.

Le interconnessioni con la rete OPB sono realiz-zate con GW (Gateway GigaRouter) dedicati verso:• l’Upstream Provider Seabone, su circuiti Stm-

16 dedicat i a i serviz i Mass Market(Residenziale) e circuiti STM-16 per i serviziExecutive/Business (figura 10);

• il Bakbone DTC su circuiti STM-16 e GbE.

3.2.5 Il Peering

Le “politiche di peering” sono costituite da uninsieme di regole che disciplinano lo scambio diinformazioni di instradamento tra AutonomousSystem.

La manipolazione delle informazioni ricevute e/otrasmesse consente il controllo sui flussi di trafficoscambiati con l'esterno.

Il protocollo BGP è normalmente utilizzato perrealizzare le politiche di peering in quanto natoappositamente per lo scambio di informazioni dirouting relative alla raggiungibilità delle destina-zioni (dette anche rotte, oppure network o route)proprie di ciascun ISP (Internet Service Provider).Per la definizione di ISP su veda il riquadro diapprofondimento “Internet Service Provider”. Esso,inoltre, implementa vari meccanismi atti ad evitarel'instaurarsi di annunci su percorsi chiusi (loop),consentendo la segmentazione degli annunci suuna molteplicità di sessioni e assegnando a cia-scun annuncio una priorità qualora esistano piùpercorsi verso la stessa destinazione.

Le relazioni di peering possono essere realiz-zate presso apposite strutture denominate NAP(Neutral Access Point - Punti di Peering pubblici) omediante interconnessione diretta tra i backbonedegli ISP tramite collegamenti diretti (Punti diPeering privati).

In entrambi i casi viene instaurata una sessioneeBGP (external BGP) tra i router di ciascun lato delpeering (figura 11).

Un NAP può essere considerato un’infrastrut-tura di livello 2 (LAN con Switch Ethernet), ingenere centralizzata in un’unica sede e la cuigestione è normalmente affidata ad un consorzio diISP, senza scopi di lucro che ne assicura la conti-nuità del servizio e la gestione dei malfunziona-menti 24 ore su 24.

La figura 12 illustra come i router di proprietàdei vari ISP (detti anche GateWay) sono da unaparte connessi ai LAN Switch del NAP e dall’altraai vari backbone degli ISP.

GEGWPoP

===

Gigabit EthernetGateWayPoint of Presence

PoPRoma sud

PoPMI/BE

PoPRoma Inv.

InnerCore

POSStm 64

POSStm 64

POSStm 64

POSStm 64

GWITZ

GWITZ

PoPMI/MA

GWITZ

GWITZ

PoPMI/MA

SEABONE

PoPRoma nord

2 x 10 GETransito

2 x 10 GETransito

4 x Stm 16

4 x Stm 16

4 x Stm 16

4 x Stm 16

MI (Milano)BE (Milano Bersaglio)MA (Milano Malpaga)

FIGURA 10› L’interconnessione OPB - Seabone.



I due principali NAP Italiani verso la rete OPBsono equipaggiati:• al MIX di Milano con due GW GSR 12012, cia-

scuno con doppia attestazione Gigabit Ethernetsulle due VLAN pubbliche del MIX e con duecollegamenti STM-16 verso i GSR di peering diMilano (Bersaglio e Malpaga);

• al Namex di Roma con un GW GSR 12012, cia-scuno con doppia attestazione Gigabit Ethernetsulle due VLAN pubbliche del Namex e con ottocollegamenti STM-1 verso i GSR di Peering diRoma (Inviolatella e CTRL).

I peering instaurati all’interno di un NAP per-mettono di creare sessioni BGP tra un numeroconsiderevole di ISP, senza dover creare unamaglia completa di collegamenti diretti tra i varibackbone, come sarebbe necessario fare utiliz-zando Peering Privati.

Le sessioni eBGP garantiscono quindi un inter-connessione logica tra ISP nei punti di PeeringPubblici e i vari operatori concordano direttamentetra loro le sessioni eBGP, i filtri e le politiche di pee-ring. In un contesto nazionale, il numero di NAP deveessere necessariamente contenuto; dal punto divista tecnico-architetturale, per OPB si armonizzanobene due punti di accesso, uno a Roma ed uno aMilano2. Analoga considerazione può essere appli-cata ai Peering Privati i quali sono di regola instauratisolo con ISP di grande caratura (ad esempio, peruno scambio di traffico maggiore di 500 Mbit/s).

Dal punto di vista del routing, agli “ISP-Peer”, iService Provider con cui Telecom Italia effettua un

INTERNET SERVICE

PROVIDER

(ISP)

È un fornitore di accessi ad Internet(per esempio, con listino ufficiale pub-blicato di prodotti realizzati all’internodel proprio address space edAutonomous System, come l’accesso

ad Internet via rete ATM e leased lines,ADSL o dial up ) . L’ ISP (InternetService Provider) è in possesso del-l’autorizzazione Ministeriale per la for-nitura di accessi ad Internet (rilasciatadal Ministero delle Comunicazioni aisensi del D.L. n. 103 del 17/3/95 e delD.P.R. n. 420 del 4.9.95). È registratopresso RIPE NCC o un registro equiva-lente come Local Internet Registry(avendo, quindi, facoltà di assegnarereti IP ai propri clienti). Ha un proprionumero di Autonomous System pub-blico rilasciato da un registro ricono-sciuto ed annuncia le proprie reti

all’interno del proprio AutonomousSystem. Ha una propria connettivitàall'Internet globale indipendente dalPeering (sia esso Privato o Pubblico)con disponibilità della Full InternetTable (tutte le rotte di Internet).Mantiene aggiornato i l NetworkManagement Database pubblico diRIPE secondo le specifiche dettate daldocumento RFC-2622 (detto ancheRPSL).

ASIBSISP

NAPOPB

=====

Autonomous SystemInterBuSinessInternet Service ProviderNeutral Access PointOptical Packet Backbone

OPB/IBS

InternetISP

ISPNAP

Clientecon AS

versoUpstream Provider

(Seabone)

peeringpubblico

peeringprivato

ISP

FIGURA 11› L’architettura logica dei Peering.

BBBGPGWISPLANNAP

======

BackBoneBorder Gateway ProtocolGateWayInternet Service ProviderLocal Area NetworkNeutral Access Point

BB ISP 1BB IS 2

BB ISP 3

BB ISP 4 BB ISP 5

LANNAP

sessioniBGP

GW ISP

FIGURA 12› L’architettura tipica di un NAP.

(2)Esistono altri due NAP sul territorio nazionale, il TIX ed il Topix che svi-luppano però attualmente un traffico esiguo (circa 10 Mbit/s ciascuno).



peering, vengono annunciate su eBGP le retiaggregate di dominio Telecom Italia e le reti deiClienti che possiedono un AS (AS-Cliente), con unproprio spazio di indirizzamento e con un accessoa pagamento.

Nel verso opposto, dagli ISP-Peer vengonoinvece accettate le reti aggregate proprie del peere le reti dei suoi AS-Cliente.

È importante notare che gli annunci appresidagli ISP-Peer non vengono propagati versoSeabone/Internet e verso gli altri ISP-Peer; in altritermini la rete OPB non effettua “transito” a favoredegli altri ISP-Peer.

Per quanto riguarda invece gli AS-Cliente, gliannunci appresi vengono ovviamente propagativerso Seabone/Internet, oltre che verso gli ISP-Peer.

Inoltre all’AS-Cliente viene tipicamente annun-ciata la “Ful l Internet table”, costituita dagliannunci delle reti OPB e da quelli appresi daSeabone, dai Peering e dagli AS-Clienti.

In virtù degli molteplici punti di interconnes-sione di OPB con Internet (Seabone, PeeringPubblici e Privati ) e con i propri cl ienti (AS-Clienti), è usuale che uno stesso annuncio giungaad OPB attraverso diversi punti di ingresso allarete ma è altrettanto importante che vengonodefinite delle regole per la scelta di quale annun-cio prendere come valido. Le politiche di routingdella rete OPB, applicate al contesto dei peering(figura 13) prevedono che un AS-Cliente o un ISP-Peer possa smistare gli annunci delle proprie reti

mediante più sessioni instaurate su collegamentidi diversa natura, ma l’annuncio più attendibileviene scelto sulla base della tipologia dei collega-menti attivi.

La massima priorità è data all’accesso comeCliente a pagamento (AS-Cliente), in secondoluogo all’annuncio da un Peering Privato, in terzoda un Peering Pubblico e la bassa priorità all’an-nuncio via Internet (tramite Seabone).

Un esempio di coesistenza di sessioni diversedi peering tra OPB ed un AS-Cliente è riportatonella figura 14, dove è prevista la non coesistenzadi un Peering Privato con un accesso di tipo AS-Cliente.

Con la graduale affermazione del Namex in ter-mini di banda ed ISP connessi e la creazione dialtri punti di peering pubblici (TOPIX a Torino, TIX aFirenze), è nata l’esigenza di condividere presso ivari comitati tecnici dei NAP la politica di peering. Icriteri auspicati da Telecom Italia sono generalizzatinelle seguenti regole:a) dovrà essere preferito sempre il Peering Privato

(se questo è presente) r ispetto a quel loPubblico (presso un NAP);

b) questa politica dovrà essere impostata in retesia lato OPB che lato ISP-Peer (tipicamente conil meccanismo delle “Local Preference BGP”) enon potrà essere arbitrariamente modificata dauna delle due parti;

c) in generale dovrà esserci al massimo un peeringPrivato e uno Pubblico con un generico ISP-Peer;

d) come “regola generale” un ISP-Peer avrà unpeering Pubblico con OPB presso un unicoNAP e, per eccezione, si valuterà di volta involta l’opportunità di gestire il peering su duepunti di scambio in funzione delle risorse dispo-nibili presso i due NAP, sia di OPB che dell’ISP-Peer;

ASIBS

OPB

===

Autonomous SystemInterBuSinessOptical Packet Backbone

I(x, xc)

X, Xc

X, Xc

X, Xc

I(p)

I(p) Xc

I(p)

P

P

Cliente con retiX X di IBS

Cliente con proprioAS e reti (network)

OPB/IBS(AS3268)

X

X

TL-RR

SeaboneInternet

Peering(pubblici e privati)

AS Cliente(Xc)

X Reti aggregate di IBS (x maiuscolo)Xc Reti dei Clienti IBS con proprio ASI Reti Internet da Seabone; I(k) contiene kP Reti dai Peering (Pubblici e Privati)TL-RR Top Level RR: reti aggregate di IBS

K Annuncio in EBGP delle Reti K

FIGURA 13› Schematizzazione delle politiche di Peering in OPB/IBS.

ASIBS

OPB

===

Autonomous SystemInterBuSinessOptical Packet Backbone

4

2 - 3

1

Seabone

Internet

OPB/IBSASxxx

Peering

AS - Cliente1 Accesso a pagamento2 Peering Privato3 Peering Pubblico4 No Peering

FIGURA 14› La coesistenza di Peering diversi tra OPB e AS - Cliente.



e) qualora OPB ed un ISP-Peer decidano dieffettuare due peering Pubblici presso duestrutture NAP, dovrà essere concordata lapriorità di utilizzo dei peering in base a criteridi reciproca convenienza e tale politica nonpotrà essere arbitrariamente modificata dauna delle due parti. La “regola generale” fariferimento al fatto che Telecom Italia ha adot-tato fin dalle origini di IBS, l’approccio diaccettare come “default” i peering Pubblicicon tutti gli ISP che lo richiedessero; comenaturale estensione di questa pol i t ica, s iammette che un ISP-Peer possa richiedere diinstaurare un Peering Pubblico presso ungenerico NAP a scelta.

3.3 L’architettura della rete DTC

La rete Datacom offre alla clientela Executiveservizi business legati anche ad applicazioni “mis-sion critical” (banche, trading on line…), con con-nettività sia in rete privata (VPN-MPLS) che versoInternet.

Il backbone è costituito da un Inner Core diquattro PoP-LH (Point of Presence-Long Haul)

situati nelle città di Milano, Roma, Padova eBologna, ciascuno dotato di 1 MAN GBE “locale” eda un Outer Core di 13 MAN GBE “remote”.

Come indicato in figura 15, i PoP-LH sonointerconnessi con due collegamenti POS STM-16garantendo il reinstradamento automatico in casodi guasti. Il PoP-LH di Milano svolge la funzionedi concentrazione del traffico dagli altri PoP dibackbone e la connettività internazionale conSeabone.

L’interconnessione con OPB è realizzata aRoma e a Milano, su collegamenti GbE per serviziIP e di tipo SDH a 2,5 Gbit/s per servizi VPN-MPLS, attuando in questo caso le funzionalità“Inter-AS-VPN” per le sedi cliente Executive atte-state in modalità “dual backbone”.

Nell’architettura attuale, ciascuna MAN è realizzatacon due Router Cisco 7600 che svolgono funzionalità diTransito per i Servizi o Edge Full-Internet e VPN-MPLS,ad eccezione di Roma e Milano dove due coppie diGSR 12416 fungono da Transito per l’Edge locale.

Il routing del backbone Executive è fondato sudue livelli: • il protocollo IS-IS [15] è utilizzato per calcolare i

percorsi che permettono di raggiungere gli

STM-16

STM-16

STM-1

STM-16

Milano

SeabonePadova

BolognaRoma

MAN PD

Esempiodi MANremota

(13 città)

Catalyst 6509Infrastrutturali

PE/RA/RR

PE/RA/RRPE/RA/RRPE PE/RA

MAN Bologna

MAN RM

PE/RA/RR

Catalyst 6509Infrastrutturali

PE

GE

GEGE

GE

GSR LH

GE GE

GSR LHGSR LH

MAN MI

Peering conOPB

GEGSR

LHMANOPB

PERARR

========

Gigabit EthernetGigabit Switch RouterLong HaulMetro Area NetworkOptical Packet BackbProvider EdgeRouter AccessRoute Reflector

FIGURA 15› L’architettura attuale di DTC.



apparati di rete (in particolare le route verso leloopback);

• il protocollo iBGP è utilizzato per propagare leinformazioni dei clienti (viene impostato comenext hop la loopback dell’apparato di accesso).Tale soluzione combina i punti di forza dei dueprotocolli: la capacità di calcolare il percorsoottimo di IS-IS e la capacità di gestire con effi-cienza un elevato numero di route del BGP.

4. La Qualità del Servizio

La Quality of Service (QoS) nelle reti di teleco-municazioni è tipicamente riferita ad un insieme diparametri prestazionali osservabili e misurabilidirettamente agli estremi dei punti di accesso di unservizio di trasporto dati. In questo contesto non siintende fare una trattazione generale sulla qualitàdel servizio in una rete di telecomunicazioni mapiuttosto dare una descrizione dei criteri, para-digmi e meccanismi di QoS applicati ed applicabilisu un backbone dati.

I meccanismi a supporto della qualità di un ser-vizio di trasporto di pacchetti, per un backbone,come quelli di Wireline, progettato con criteri diridondanza di apparati e di collegamenti tra i nodi,entrano in gioco praticamente solo in condizioni diguasto, specialmente se questo è multiplo.

Il concetto di “Best Effort”, ovvero il trasporto dipacchetti dati senza alcuna garanzia di ricezionenato nel periodo di gioventù di Internet, è stato lar-gamente superato con le tecnologie oggi disponi-bili e da un’adeguata progettazione della rete.

Un backbone ben progettato, costituito daapparati Gigarouter, da collegamenti dorsali ad altacapacità ottici da 2,5 Gbit/s a 10 Gbit/s, con tempidi attraversamento nel singolo nodo sotto al milli-secondo e con ritardi end to end tra due POPlegati essenzialmente alla velocità trasmissiva dellarete di trasporto sottostante, consente di fatto unservizio di trasporto di pacchetti di ottima qualitàper tutti i servizi supportati. Le prestazioni tipicheper un backbone non eccessivamente esteso geo-graficamente come quelli OPB o DTC, sono quindidi qualche decina di millisecondi di ritardo end toend tra i PoP con un jitter minore del 50% sulritardo end to end.

4.1 L’ortogonalità tra QoS e MPLS

A prescindere da considerazioni affidabilistiche,le funzionalità MPLS e la QoS sono praticamente“ortogonali”: attivando MPLS non si ottengonocioè vantaggi in termini di prestazioni o di migliora-mento della QoS.

La funzionalità di QoS, in accordo ai paradigmidi differenziazione della qualità dei servizi (modelliDiffServ), viene gestita grazie a politiche e mecca-nismi di accodamento (scheduling) dei pacchettiIP/MPLS nei buffer dei router, ovvero in uscitaverso le interfacce ed in entrata verso la matricedel nodo; ciò vale indistintamente sia per il trafficoIP che per quello imbustato via MPLS.

I suddetti meccanismi di scheduling entrano ingioco solo in caso di congestione interna al nodo,quale ad esempio la saturazione di un’interfaccia;ciò può accadere solo in caso di guasti in rete ditipo multiplo se si sono dimensionati i collegamentiin modo da non superare il 50% della capacità.

4.2 Criteri di implementazione della QoS su OPB

I principi generali che hanno guidato l’imple-mentazione della QoS su OPB sono basati su cri-teri di semplicità, efficienza ed efficacia: il back-bone deve, cioè, essere in grado di trasportarepacchetti/trame in grosse quantità e ad alta velo-cità, lavorando i volumi di traffico “all’ingrosso” enon il “bit” al “dettaglio”, come invece è, in genere,richiesto all’area di Edge IP/MPLS. I punti di forzarisiedono nell’utilizzo di adeguate tecnologie diswitching e dimensionamento dei collegamentiinfrastrutturali. Con questi criteri, apparentemente“banali”, un backbone IP/MPLS offre prestazionieccellenti.

Le stesse considerazioni devono essere appli-cate a tutti i criteri di progettazione, ivi compresoquello del piano di controllo e ciò ha comportatoper la realizzazione di OPB:• l’impiego di tecnologia di Gigarouter GSR,

modello di punta della Cisco Systems per back-bone IP;

• l’utilizzo di circuiti tutti di tipo SDH/DWDM,sempre dimensionati al massimo al 50% dellepropria capacità;

• un Piano di controllo il più semplice e scalabilepossibile.In condizioni normali, ovvero in assenza di gua-

sto, si fa principalmente affidamento sulla tecnolo-gia interna del nodo Gigarouter, basata su unavelocità di “switching” della matrice intorno ai 500microsecondi ed una celerità di attraversamentodel singolo nodo tipicamente dell’ordine del milli-secondo.

In caso invece di congestione del nodo, ovveroin caso di guasti multipli in rete, entrano in gioco iclassici meccanismi previsti nel modello DiffServ(Differentiated Services) standardizzati in ambitoIETF [16, 17]. Il modello tratta unicamente gliaggregati di traffico e non interviene sui singoliflussi, quali quelli dei clienti o delle singole applica-zioni. Il trattamento dei pacchetti, applicato all’in-terno del nodo, in base al valore IP Precedence delcampo ToS (Type of Service) nell’intestazione deipacchetti IP (o il valore Experimental nell’intesta-zione delle trame MPLS), è uguale per tutti i pac-chetti appartenenti alla stessa classe ed è determi-nato dall’attribuzione di una determinata quantitàdi risorse riservata alla classe.

I Gigarouter implementano due meccanismi diQoS per la gestione delle risorse interne al nodo:• il Modified Deficit Round Robin (MDRR);• il Weighted Random Early Detection (WRED).

L’algoritmo MDRR è utilizzato per la gestionedelle code interne al router: su ogni coda puòessere mappata una o più delle suddette classidi servizio e servita in modalità “round-robin”.



Ad ogni coda viene assegnato un “peso” rela-tivo differente, attraverso il quale è possibile asse-gnare una porzione di banda relativa ad ogni codada utilizzare in caso di congestione. L’algoritmoMDRR supporta inoltre una gestione delle prioritànello smaltimento delle code (Priority Queue), inmodo da rispondere ai requisiti di basso delay e jit-ter che richiede il traffico “sensibile al tempo”,come il traffico Voce su IP. L'implementazione pre-vede anche la modalità SRT (Strict Real Time) nellaquale la coda è servita fino al completo svuota-mento in modo da garantire il minimo ritardo tem-porale.

L’algoritmo WRED cerca di evitare la conge-stione delle code attuando uno scarto selettivo dipacchetti sulla base della priorità. Lo scarto deipacchetti IP avviene al superamento di una certasoglia di occupazione del collegamento e con pro-babilità crescente in funzione del livello di occupa-zione. Il WRED inoltre gestisce la differenziazionedelle soglie e delle probabilità di scarto in base allaclasse di servizio, consentendo quindi la prote-zione del traffico più pregiato.

Attualmente, su OPB è stato implementato unprofilo di QoS per tre tipologie di traffico:• Gold, dedicato al traffico VoIP BBN marcato

con IPPrec o Exp MPLS a 5;• Premium, con pacchetti IP/MPLS marcati con

IPPrec o Exp MPLS a 6, 7, 4 , 2;• Default, marcato a 0, 1, 3.

Il traffico VoIP su BBN, marcato con valore ExpMPLS pari a 5 nel Media Gateway, viene inseritonelle code interne SRT a bassa latenza dei GSR;tutto il resto del traffico viene invece inserito in duecode MDRR dove, alla coda 1 è dato un pesoMDRR equivalente all’80%, alla coda 0 di default ilrestante valore del 20% (figura 16). Per quantoriguarda il WRED, è stato scelto un modello “tailand drop”, con le stesse soglie per le varie classi di

servizio (campi IP Prec o Exp MPLS), all’internodelle code del Gigarouter. Questo profilo di QoS èstato attuato sia in ingresso alla matrice di com-mutazione interna del GSR che sulle code inuscita delle interfacce del nodo ed è configuratosui collegamenti interni al backbone e non verso leVLAN di Accesso. Riguardo alla coda SRT, comesi è già detto, essa non è soggetta ai meccanismiRound Robin dell’algoritmo MDRR; in altre parole,questo vuol dire che i pacchetti o trame MPLSinserite nelle code SRT sono potenzialmente ingrado di attingere al 100% delle risorse interne alnodo.

La cosa non è un problema nel caso che la per-centuale di traffico mappato sulla coda SRT vengalimitata in rete ad un valore “ragionevole”, ovveroun valore intorno al 10% (al massimo pari al 15%)della capacità di un generico circuito.

5. Impieghi per applicazioni Voce: Class 4/5

5.1 Progetto BBN Class4

Il progetto “BBN” è nato nel 2001 per sostituireil livello di trasporto a commutazione di circuito deltraffico Voce, eliminando gli SGT (Stadi di Gruppodi Transito) con nodi di tecnologia innovativa, dettinodi “BBN” oppure “Class4” [1].

La prima attivazione è avvenuta tra Roma eMilano nell’agosto del 2002 ed è proseguita neimesi successivi con il graduale ribaltamento deltraffico telefonico sui nuovi nodi. I requisiti del pro-getto BBN hanno richiesto al backbone OPB unservizio di trasporto il più possibile simile ad unainterconnessione “trasmissiva”, attuato in unambiente “chiuso”. A tale scopo, i Media Gatewaydi BBN usufruiscono di una struttura di tunnelMPLS-TE che ha fondamentalmente il compito dicreare un piano di controllo e di forwarding com-pletamente separato r ispetto al l ’universo“Pubblico”.

In questo contesto per ambiente “Pubblico” siintende la possibilità di raggiungere a livello IP tuttile tipologie dei Clienti o gli elementi di Edge(Router di Accesso, NAS ADSL e dial up) nelle retidi backbone ed in generale su Internet attraversoSeabone ed i Peering Privati e Pubblici. Un buonesempio di implementazione di un Piano “Privato”,completamente indipendente da quello Pubblico, èquello delle reti Private Virtuali MPLS (VPN MPLS),dove soltanto un gruppo ristretto di apparati e hostdi Clienti possono comunicare fra loro a livello geo-grafico.

Le reti VPN MPLS sono supportate da funziona-lità di transito MPLS (dette funzionalità “P”) suibackbone OPB e DTC, mentre le componenti diservizio sono configurate sui PE (Provider Edge)MPLS, attestati alle VLAN di Accesso.

Il progetto Class4 in definitiva ha comportato(figura 17):• la realizzazione di una maglia completa di tun-

nel MPLS-TE su 23 PoP di OPB, per un totale dicirca 2.000 tunnel;

BBNIPPRECMDRRMPLS

SRTVoIP

WRED

=======

BackBone NazionaleIP PRECedenceModified Deficit Round RobinMulti Protocol Label SwitchingStrict Real TimeVoice over IPWeighted Random Early/Detection

5

80%

20%

2, 4

6, 7

0, 1, 3

VoIP BBN SRT

Strict priority

Default

MDRR/WRED

IPPR

EC o

MPL

S E

XP b

it

FIGURA 16› La configurazione QoS delle code sui GSR.



• la configurazione di un piano di indirizzamentostabilito a priori per un’architettura dimensio-nata a regime, con una /16 o classe B per PoP,dove gli indirizzi da 10.0.0.0 a 10.30.0.0 sonostati assegnati a BBN Class4;

• l’attivazione di un routing statico su classi pri-vate, le quali non vengono annunciate in BGPo OSPF. Per una maggiore sicurezza, sonostati anche implementati sugli apparati Edge diOPB dei meccanismi, controllati sui RR BGP,per lo scarto di pacchetti IP con indirizza-mento privato che dovessero tentare di supe-rare i confini di OPB.Nella figura 18 viene illustrata, per grandi linee,

l’architettura di un genericonodo BBN e soprattutto lesue connessioni con gl iapparati GSR di OPB.

I l nodo BBN Class4 ècollegato ad OPB tramitedue t ipologie di col lega-menti:• ATM STM-1, per l’inter-

connessione con i MGWcostituit i dal la schedeVISM dei nodi MGX;

• GbE, per la visibilità delleparti di controllo/segna-lazione del nodo.Un generico pacchetto

IP, con indirizzo di destina-zione appartenete al laclasse IP Privata assegnataal PoP BBN di destinazioneviene imbustato dal MediaGateway in un PVC ATM,terminato in uno dei dueGSR di OPB, ed infine ruo-tato tramite una statica nei

due tunnel MPLS-TE che terminano nei due GSRpresenti nel PoP BBN di destinazione.

Questa architettura di Tunnel MPLS-TE èrisultata efficace ed adatta ad interconnetterenodi BBN in un struttura di servizio statica e pre-definita.

Negli ultimi tempi tuttavia stanno emergendonuovi servizi che richiedono delle strutture piùdinamiche, aperte dal punto di vista della raggiun-gibilità IP e soprattutto non predefinite comequella del BBN Class4. Sono state, quindi, stu-diate e sono in corso di implementazione su OPBnuove soluzioni basate su routing “classico” viaOSPF e BGP che per loro natura sono più dinami-che e scalabili, come verrà meglio chiarito nelprossimo paragrafo.

5.2 Progetti Class5 ed interconessione PEB-BBN

I nuovi progetti richiedono l’apertura gradualedei nodi BBN all’ambiente IP pubblico in quantoalcune risorse dei Media Gateway BBN dovrannoessere raggiunte potenzialmente da qualsiasiapparato di accesso o terminale di utente che uti-lizza indirizzi pubblici; ciò accade per i progetti ditipo Class5, ed anche per l’interconnessione IPcon la rete VoIP di Sparkle, il PEB (Pan EuropeanBackbone) che utilizza indirizzi pubblici della reteSeabone.

L’apertura all’ambiente pubblico IP è indispen-sabile per introdurre una serie di nuovi servizi dicomunicazione telefonica sia per la cl ientelaBusiness che Residenziale.

I servizi di comunicazione di tipo Class5 preve-dono una nuova tipologia di piattaforma di con-trollo centralizzata per servizi telefonici e multime-diali, principalmente per la segnalazione a sup-porto dell’instaurazione di un canale di comunica-zione (voce o video) su IP.

BBNOPBMG

===

BackBone Nazionale Optical Packet BackboneMedia Gateway

EdgeExecutive,Business,

Mass Market

OPB Piano Pubblico

OPB Piano Privato

MG BBN C4

Due piani indipendenti (sia a livello di controllo/routingche di forwarding) che condividonole stesse risorse fisiche.

FIGURA 17› Il Piano Pubblico e Privato di OPB.

PoP BBN

ADM

AreaGW

SGU

STM-1 Ethernet TunnelMPLS-TE

GSR1

STM-1ATM

GSR1

GSR2 GSR2OPB

PoPBBN

iMSS

MGX

GE

E1

6509 conrouting

STM-1OLO

ADMATMBBN

GEGSRGW

iMSSMGXOLOOPBSTM

===========

Add Drop MultiplexerAsynchronous Transfer ModeBackBone NazionaleGigabit EthernetGigabit Switch RouterGateWayItaltel Multi Service Solution Nodo ATM di Cisco SystemsOther Licenced OperatorOptical Packet BackboneSynchronous Transport Module

VV

V

V VISM con indirizzi IP privati

VISM con indirizzi IP pubblici

FIGURA 18› L’architettura di un PoP BBN.



Due sono i possibili scenari di comunicazione:• tra clienti/applicazioni, oppure tra elementi di

rete dett i “Border Gateway”, o “AccessGateway” tutti appartenenti al piano IP Pubblicoe collegati quindi alle strutture di Accesso/Edgedi OPB;

• tra un cliente appartenente al piano IP Pubblicoed un cliente del mondo legacy TDM, attestatoquindi ad una centrale di commutazione urbanatradizionale raggiungibile, telefonicamente tra-mite un nodo BBN Class4. Questi nodi Class5,in numero contenuto e centralizzato, sarannoattestati direttamente ai GSR di OPB nei quattroPoP di Inner Core, secondo una modalità moltosimile a quella dei nodi Class4. Lo schema diinterconnessione con OPB viene mostrato nellafigura 19, dove le schede VISM del MediaGateway ed alcune strutture interne al nododovranno essere necessariamente configuratecon indirizzi IP pubblici.Per quanto riguarda il routing, è previsto che

vengano ut i l izzat i i protocol l i OSPF e BGP,secondo quanto previsto nel routing standard:• il routing iBGP 3269 per propagare su OPB gli

annunci aggregati delle reti pubbliche delleschede VISM e del la componente internaPubblica del nodo, tramite configurazione edistribuzione di rotte statiche sui transiti diOPB;

• il routing OSPF 3269 per garantire la raggiungi-bilità dei next-hop degli annunci iBGP che corri-spondono alle LB (Loop Back) dei due GSR.I nuovi servizi VoIP prevedono che un cliente o

applicazione, attestato ad un generico apparato diEdge di OPB sul piano Pubblico, abbia “visibilità” a

livello IP dei Media Gateway (schede VISM) deinodi Class4 di BBN; in altri termini, si rende neces-sario mettere in qualche modo in comunicazione idue universi (Pubblico e Privato), come schematiz-zato nella figura 20.

Dal punto di vista concettuale, ciò può esserefatto fondamentalmente in due modi: facendo

diventare pubbliche almeno partedelle risorse del piano Privato (inmodo da diventare automatica-mente v is ibi l i in tutta la rete) ,oppure inserendo degli elementi diconfine tra i due universi (detti“Border Gateway”), con il precisoscopo di metterl i in comunica-zione.

Per quanto riguarda lo speci-fico scenario di BBN Class4, èstato deciso di configurare partedel le schede VISM dei MediaGateway con indirizzi pubblici IP.

Inizialmente questo paradigmaporterà ad una nuova configura-zione ed instal lazione di unnumero limitato di schede VISMnei Media Gateway dei 24 PoPBBN.

L’inserimento verrà poi gradual-mente guidato dalla numerositàdella clientela/servizi sul pianopubblico che hanno la necessità dicomunicare con il mondo TDM tra-dizionale, ricordando che “dietro”ai nodi BBN Class4 vi sono i bacinidi raccolta TDM tramite gli SGUtradizionali.

V

V

V

STM-1ATM

6509 conRouting

Nod

o P

ubbl

ico

con

netw

ork

aggr

egab

ile

MGX

GE

OPB

PoPBBN C5

BGPBGP

OSPF

OSPF

BGP

RR BGP

GSR1

VISM con indirizzi IP Pubblici

Statica verso il nodo Pubblico e VISM,ridistribuita in BGP con next-hop LB GSR.

LB GSR

LB GSR

GSR2Elementi

Privati internial nodo C5

ATMBBNBGP

GEGSR

LBMGXOPBPoPRR

VISM

===========

Asymmetrical Transfer ModeBackBone NazionaleBorder Gateway ProtocolGigabit EthernetGigabit Switch RouterLoopBackNodo ATM di Cisco SystemsOptical Packet BackbonePoint of PresenceRouter ReflectorVoice Interworking Service Module

FIGURA 19› Interconnessione di un PoP BBN C5 a OPB.

M

MMM

M

PEB

OPB Piano Pubblico

OPB Piano Privato

InterconnessionePEB-BBN

InterconnessionePubblico-Privato (CL5)

BBNOPBPEB

===

BackBone NazionaleOptical Packet BackbonePan European Backbone

FIGURA 20› Schematizzazione dell’interconnessione tra il Piano

Pubblico e il Piano Privato.



Per il routing delle schede VISM pubbliche, èadottata la stessa soluzione Class5, dove gliaggregati delle reti pubbliche delle schede VISMsono annunciati in iBGP attraverso la distribuzionedi statiche.

Per i serviz i VoIP a l ivel lo internazionale,l’Upstream Provider Sparkle ha implementato sulbackbone Seabone un’architettura di rete di tra-sporto VoIP analoga a quella del BBN, denominataPEB (Pan European Backbone).

Le schede VISM dei Media Gateway del PEBsono dotate di un indirizzamento IP pubblico equindi automaticamente visibili per qualsiasi clientedella rete.

Nell’interconnessione tra le due piattaformePEB-BBN, una chiamata telefonica tra un clientelegacy del dominio nazionale viene prima trattatadallo SGU (Stadio di Gruppo Urbano) della retetelefonica tradizionale di competenza, poi dal nodoBBN e, dopo il transito sul piano pubblico sui duebackbone IP OPB e Seabone, viene trattata dalnodo PEB Class4 ed in ultimo passata allo SGUinternazionale. I meccanismi di QoS sul BackboneSEABONE sono analoghi a quelli di OPB, sia perquanto riguarda il valore di IP Precedence chedelle code Strict-Real-Time dei GSR.

6. Conclusioni

In questo articolo è stata presentata la piat-taforma di trasporto pubblica IP/MPLS di TelecomItalia Wireline, nel contesto dei servizi da essoofferti, dell’evoluzione architetturale, della Qualityof Service ed infine delle applicazioni VoIP.

I successi dei servizi voce, video e dati di oggi edi domani vanno di pari passo con l’elevata qualitàdei livelli di servizio che un backbone dati puògarantire.

Uno di questi è stato raggiunto l’anno scorsonell’ambito della Fonia su IP, offrendo un servizio ditrasporto geografico tra i Media Gateway BBN congaranzie di elevata protezione, sicurezza e tratta-mento ai possibili casi di guasto o congestionedella rete.

Altri non meno importanti traguardi sono stati esaranno raggiunti grazie ad una attenta progetta-zione delle architetture fisiche e di routing, all’ado-zione di semplici paradigmi per l’attestazione diapparati di accesso al backbone ed alla condivi-sione con tutti gli ISP di politiche generali nei puntidi peering pubblici e privati.

ADSL Asymmetrical Digital Subscriber LineAS Autonomous SystemATM Asynchronous Transfer ModeBGP Border Gateway ProtocolBBN Backbone NazionaleDTC DatacomDWDM Dense Wawelenght Division MultiplexingeBGP external Border Gateway ProtocolFE Fast EthernetGE Gigabit EthernetGSR Gigabit Switch RouterGW GatewayGW-ITZ Gateway InternazionaleiBGP internal Border Gateway ProtocolIBS InterBuSinessIETF The Internet Engineering Task ForIGMP Internet Group Management ProtocolIP Internet ProtocolISDN Integrated Service Digital NetworkLIS Logical IP SubnetLH Long HaulMAN Metro Area NetworkMDRR Modified Deficit Round RobinMGX Nodo ATM di Cisco SystemsMP-BGP MultiProtocol BGPMPLS Multi Protocol Label SwitchingMPLS-TE Multi Protocol Label Switching-Traffic

EngineeringNAS Network Access ServerNSSA Not-so-stubby AreaOPB Optical Packet backboneOSPF Open Shortest Path FirstOTN Optical Transport NetworkPE Provider EdgePEB Pan European BackbonePOS Packet Over SDHPoP Point of PresenceQoS Quality of ServiceRA Router AccessRR Router ReflectorSEABONE South European Access BackboneSGT Stadio di Gruppo di TransitoSGU Stadio di Gruppo UrbanoSRM Strict Priority ModeTCP Transport Control ProtocolTDM Time Division MultiplexingTOS Type Of ServiceVISM Voice Interworking Service ModuleVoIP Voice over IPVPN Virtual Private NetworkWRED Weighted Random Early Detection

— ABBREVIAZIONI



Alberto Mar ia Langel lot t i s i èlaureato nel 1991 presso l ’Univers i tà d iRoma. È entrato in SIP nello stesso annone l l ’a rea Rete. Dopo l ’anno d i corso d ispecializzazione presso la Scuola SuperioreSSGRR di L'Aquila ha lavorato, nell’ambitodella Rete, nelle linee di Ricerca e Sviluppo,Tecnologie ed Architetture, Ingegneria delleReti Dati, Ingegneria dei Servizi e nell’attualeNetwork Services, dove ha partecipato a

progetti sulla multimedialità, l’ADSL e servizi IP per la clientelaBusiness e Residenziale. Dal 2000 si occupa del BackboneIP/MPLS ed attualmente è responsabile della funzione “Trasportoed OPB”.

Simeone Mastropietro si è laureatocon lode in Ingegneria Elettronica pressol’Università degli Studi di Roma “La Sapienza”nel 2000 con una tesi sperimentale sulle RetiIP DiffServ. Nel corso dello stesso anno hacollaborato con il Co.Ri.Tel nell’ambito delp roget to europeo AQUILA impern ia tosull’analisi e sulle tecniche per il provisioningdella qualità di servizio nelle reti IP/MPLS. Allafine dello stesso anno è entrato in Telecom

Italia occupandosi sin dall’inizio del nascente Optical PacketBackBone (OPB). La sua at t i v i tà è s ta ta pr inc ipa lmentefocal izzata sugl i aspett i d i rout ing (BGP ed OSPF) e delprotocollo MPLS. Nel corso del 2003 ha fatto parte del gruppod i lavoro RT4Sec. Ha avuto anche co l laboraz ion i conpartecipate estere (Entel Bolivia, Etecssa Cuba) e con GlobalNetwwork (Progetto Hansenet).

Antonio Soldat i s i è lau rea to inIngegneria Elettronica presso l'Università “LaSapienza” di Roma, è in Telecom Italia dal1991. Dopo il corso di perfezionamento inTe lecomun icaz ion i p resso la Scuo laSuperiore SSGRR di L'Aquila, ha ricopertovar i i ncar ich i ne l l ' a rea de l la R icerca eSviluppo prima e, in seguito, delle Tecnologiee Architetture. Dal 2000 opera nell'ambitodel l ' Ingegner ia dei Serviz i (oggi Network

Services), dove attualmente coordina le attività di Ingegneriadelle reti di Backbone IP.

Federico Tito Moretti si è laureato inIngegneria Elettronica presso l ’Universitàdegli studi di Roma “La Sapienza” nel 1995con una tes i sper imenta le ne l campodell’Optoelettronica. Dopo aver conseguito ilMaster TLC presso la Scuola Superiore diSpecial izzazione in Telecomunicazioni delMinistero PT, nel 1996 è entrato in TelecomIta l ia occupandosi d i speci f iche, gare eco l laud i de i s is temi d i super v is ione e

controllo della rete di accesso a larga banda. Dal 2000 ha svoltoattività di industrializzazione e network monitoring della rete ditrasporto SDH/DWDM e, a partire dal 2002, presso l’attualefunzione Network Services, si occupa dell’industrializzazione delBackbone IP/MPLS (OPB).

[1] Fratianni, Lalli, Lamberti, Langellotti, Moretti, Scrimitore:“Il backbone IP per i servizi telefonici”. <NotiziarioTecnico Telecom Italia>, anno 13, n. 1, giugno 2004,pp. 56-73

[2] Pagnan, Picciano, Langellotti: “Il nuovo backbone otticodi Telecom Italia”. <Notiziario Tecnico Telecom Italia>,anno 11, n. 2, settembre 2002, pp. 55-74

[3] Montechiarini: “I servizi IP di Telecom Italia: l’offerta per iclienti affari”. <Notiziario Tecnico Telecom Italia>, anno8, n. 3, dicembre 1999, pp. 44-56

[4] IETF RFC 3031: Multiprotocol Label SwitchingArchitecture

[5] IETF RFC 3032: MPLS Label Stack Encoding

[6] ETF RFC 2702: Requirements for Traffic EngineeringOver MPLS

[7] IETF RFC 2328: PPP over SONET/SDH

[8] IETF RFC 2328: OSPF Version 2

[9] IETF RFC 2858: Multiprotocol Extensions for BGP-4

[10] IETF RFC 1771: A Border Gateway Protocol 4 (BGP-4)

[11] IETF FRC 1966: BGP Route Reflection: An alternative tofull mesh iBGP

[12] IETF RFC 2362: Protocol Independent Multicast-SparseMode (PIM-SM): Protocol Specification

[13] IETF RFC 3618: Multicast Source Discovery Protocol(MSDP)

[14] IETF RFC 2236: Internet Group Management Protocol,Version 2

[15] IETF RFC 1195: Use of OSI IS-IS for Routing in TCP/IPand Dual Environments

[16] IETF RFC 2475: An Architecture for DifferentiatedServices

[17] IETF RFC 3260: New Terminology and Clarifications forDiffServ

— BIBLIOGRAFIA

Il BackBone IP di Telecom Italia Wireline TECNICO TELECOM ITALIA › Anno 13 n. 2 - Dicembre 2004 61...

Documents

Transcript of Il BackBone IP di Telecom Italia Wireline TECNICO TELECOM ITALIA › Anno 13 n. 2 - Dicembre 2004 61...