Capitolo 2 Stato della standardizzazione del GMPLS 2.1 Introduzione

Capitolo 2

Stato della standardizzazione del

GMPLS

2.1 Introduzione

Attualmente l’impiego di architetture adatte all’utilizzo dei servizi di prossima generazione richiede l’interconnessione di due domini di rete importanti ma tecnicamente differenti. Tuttavia, definire le relazioni che intercorrono tra questi domini ovvero tra le reti a commutazione di pacchetto o cella (con router IP e switch ATM) e quelle di trasporto ottico (con OXC e DWDM) presenta molteplici problemi legati alla necessaria “coabitazione” di tecnologie diverse, elementi e protocolli di più reti. Per di più, le stesse caratteristiche delle reti ottiche (OTN : Optical Transport Network) stanno cambiando con l’utilizzo di switch ottici “intelligenti” e di topologie “mesh-based” che assicurano efficienza, previsione affidabile e protezione per le connessioni ottiche ad alta velocità.

L’integrazione tra un dominio IP e quello di una rete ottica ci conduce verso un modello in cui i nodi IP possono fare richieste per poter stabilire una connessione ottica e/o “guardare” il percorso di rete ottico.

Quanto detto ci riconduce alla necessità di convalidare un piano di controllo comune per la gestione di diverse componenti di reti. Questo tema, però, rivela molti aspetti ancora non definitivi che possono essere visti, confrontati ed integrati con altre esperienze tuttora in corso che vengono sviluppate da diversi enti internazionali che collaborano e si confrontano per definire degli standard validi all’interno del suddetto piano di controllo.

2.2 Enti di standardizzazione

Il lavoro per definire gli standard per il piano di controllo generalizzato tra i vari livelli e tecnologie di rete viene svolto principalmente da tre enti:

• L’IETF (Internet Engineering Task Force) è l’ente che ha sviluppato il piano di controllo GMPLS basato sulle estensioni ai protocolli RSVP-TE e CR-LDP per la segnalazione e sulle estensioni ai protocolli OSPF-TE ed ISIS-TE per il routing. L’IETF sta anche sviluppando il Link Management Protocol per la gestione del canale di controllo, la correlazione delle proprietà del link, la verifica della sua connettività e la gestione dei guasti..

• L’OIF (Optical Internetworking Forum) è l’ ente che ha sviluppato un’ architettura basata sul modello overlay che separa il dominio utente, rappresentato dalla rete IP, dal dominio OTN . In questa architettura la segnalazione tra il dominio utente e quello OTN è basata sulla OIF User Network Interface (UNI) mentre la

segnalazione tra due domini all’interno dell’OTN è basata sulle specifiche OIF Network-to-Network Interface (NNI). Questa separazione nasconde i dettagli dell’OTN dal dominio utente attraverso una limitazione del raggio d’azione dei protocolli di routing “ottici” al solo dominio di trasporto ottico. In questo caso, una connessione richiesta per una particolare destinazione è fatta dal nodo dell’utente mentre il percorso che conduce al nodo di destinazione è determinato dall’OTN. Ricordiamo che nel GMPLS non esiste alcuna separazione di questo tipo e che i protocolli di gestione e segnalazione dell’architettura OIF sono decisamente basati sulla loro controparte nel GMPLS.

• L’ ITU-T (International Telecomunication Union – Telecomunication Section) è un organismo di standardizzazione che sta sviluppando l’Architettura per reti Automatically Switched Optical Networks (ASON). ASON non è un insieme di protocolli ma un’architettura che definisce i contorni di rete, i differenti tipi di apparecchiature di rete e le interazioni tra differenti domini. I requisiti definiti in ASON possono ritrovarsi nei protocolli GMPLS ed OIF-UNI o nei loro successivi miglioramenti. ASON definisce dei punti di riferimento per indicare dove nella rete i differenti protocolli hanno bisogno di essere definiti.

I benefici dell’integrazione tra i domini IP e Ottico, basata su questi standard emergenti, consentono di sviluppare nuovi tipi di servizi a lunghezza d’onda configurabile e ampiezza di banda a richiesta.

ASON, GMPLS ed UNI/NNI stanno aprendo un varco verso l’adozione di una generazione di servizi e reti ottiche flessibili e dinamiche.

2.3 IETF: struttura e processi di

standardizzazione.

• Struttura e compiti dell’IETF

L’IETF è una comunità internazionale estesa ed “aperta” ,formata da progettisti di rete, operatori e ricercatori che sono interessati allo sviluppo dell’architettura Internet e al suo regolare funzionamento. L’IETF si distingue proprio perché “aperta” tanto che le sue specifiche sono pubbliche e liberamente accessibili. Il lavoro tecnico dell’IETF è attualmente svolto dai Working Group (WG) che sono organizzati in differenti aree caratteristiche. Gran parte del lavoro dei WG viene svolto attraverso delle “mailing list” elettroniche. Ne esiste una per ogni WG così come ne esiste una di discussione generale ed una dedita agli annunci.

Figura 2.1 : struttura IETF

I WG sono raggruppati in aree e vengono gestiti dai direttori d’area (AD) che, a loro volta, sono membri dell’ Internet Engineering Steering Group (IESG) e vengono selezionati dal NOMCOM (NOMination COMmittee). L’IESG è responsabile della gestione tecnica delle attività all’interno dell’IETF e del processo di standardizzazione, ed essendo parte dell’ISOC (Internet SOCiety), amministra i processi secondo i ruoli e le procedure che sono state ratificate dagli amministratori dell’ISOC stesso. L’IESG è anche direttamente responsabile dell’ingresso e dell’avanzamento

dei documenti nel processo di standardizzazione fino alla loro approvazione definitiva. L’IAB (Internet Architecture Board) è, invece, responsabile dell’opera di definizione dell’architettura globale di internet, facendo da guida e fornendo direttive all’IETF. L’IAB serve anche come gruppo di consulto per le tecnologie internet oltre a svolgere un ruolo di sorveglianza e di organismo giudicante quando viene chiesto di vagliare i presunti errori compiuti dall’IESG. L’ISOC si è occupata di istituire l’IAB e l’IESG proprio affinché questi potessero svolgere i ruoli appena esposti. All’interno di questa struttura il Direttore d’Area Generale ha il compito di presiedere sia l’IESG che l’IETF.

L’IETF ha i seguenti compiti :

1. identificare e proporre le soluzioni a problemi operativi e tecnici legati ad Internet

2. specificare l’utilizzo e lo sviluppo di protocolli ed architetture per risolvere problemi tecnici legati ad Internet

3. fornire raccomandazioni all’IESG considerando la standardizzazione e l’utilizzo di protocolli in Internet 4. facilitare il trasferimento di tecnologie dall’IRTF (Internet

Reserch Task Force) ad una più ampia comunità legata ad Internet

5. fornire un forum per lo scambio di informazioni all'interno della Comunità Internet fra i fornitori, gli utenti, i ricercatori ed i gestori di rete.

• Standard IETF

Gli standard prodotti dall’IETF sono pubblicati come RFC (Request For Comments) ed ogni RFC nasce come Internet Draft (ID). Gli ID sono documenti sperimentali e servono perché possono essere commentati dai lettori interessati in modo che gli autori, sulla base dei commenti, possano ripensare a quanto scritto e decidere di quale commento tenere conto per modificare poi l’ID. Un ID può essere il risultato del lavoro di un WG o una pubblicazione individuale e può essere rimosso dagli elenchi in cui è pubblicato dopo sei mesi. I passi fondamentali che devono essere seguiti perché un documento , inizialmente pubblicato come ID, diventi un RFC sono i seguenti:

1. pubblicazione del documento come ID 2. ricezione dei commenti relativi all’ID

3. pubblicazione del documento dopo una revisione basata sui commenti ricevuti

4. ripetizione dei primi tre passi per diverse volte

5. se il draft è individuale bisogna chiedere all’AD di consegnare il draft all’IESG altrimenti, se il draft è prodotto da un WG ufficiale, è il responsabile del WG che chiede all’AD di inviarlo all’IESG dopo aver passato l’esame del WG “ last call ” .

6. il documento è sottoposto all’esame dell’IESG che, al termine, annuncia l’ultima chiamata IETF aperta che serve per richiamare l’attenzione di coloro che non hanno seguito l’evoluzione del draft e possono apportare ulteriori modifiche. L’ultima chiamata dura dalle due alle quattro settimane.

7. vengono eseguiti tutti i cambiamenti ritenuti necessari dall’IESG

8. l’ IESG conviene che il draft può diventare un IS (Internet

Standard) ed inoltra domanda all’ RFC Editor di pubblicarlo come Proposed Standard

La figura che segue illustra in maniera schematica la sequenza temporale che l’ Internet Draft attraversa prima di diventare RFC.

Figura 2.2: timeline dell’evoluzione dell’Internet Draft

Le specifiche soggette all’ ISP (Internet Standard Process) possono essere raggruppate in due categorie: Technical

WG Draft WG WG RFC edit Last Call Discussione

t

Individual Draft _{Approval IETF} RFC

Call Approval Proposed Std

Specification (TS) e Applicability Statement (AS). Nella prima

categoria è possibile trovare la descrizione di un protocollo, di un servizio, di una procedura o di una convenzione mentre nella seconda viene specificato come e in quali circostanze una o più specifiche tecniche possono essere applicate per supportare una particolare possibilità prevista in Internet. Un AS può applicare uno dei seguenti “livelli di richiesta” ad ognuno dei TS cui si riferisce:

Required, Recomended, Elective, Limited Use e Not Recommended.

Le specifiche che aspirano a divenire Internet Standard si evolvono attraverso un insieme di livelli di “maturità” che vengono comunemente chiamati “standard track” (vedi figura 2.2 ) e sono :

o Proposed Standard (è il livello di ingresso per la specifica )

o Draft Standard (la specifica è matura )

o Internet Standard (implementazione significativa seguita da esperienza operativa condotta con successo)

Le specifiche che non appartengono allo “standard track” hanno dei differenti livelli di “maturità”:

o experimental (la specifica è parte di uno sforzo di sviluppo o di ricerca)

o informational (la specifica è pubblicata a scopo informativo )

o historic (la specifica è stata sostituita da una più recente o è semplicemente considerata obsoleta

La “promozione” di una specifica all’interno di uno “standard

track” avviene seguendo delle precise procedure che vedono

coinvolti diversi organismi collegati all’IETF.

Infatti, il draft, diventato Proposed Standard, resta in questa “condizione” per almeno sei mesi .Trascorso questo tempo l’autore dell’RFC (o il responsabile del WG) chiede che diventi Draft Standard. Ma, prima che ciò accada, è necessario convincere l’AD appropriato che ci sono almeno due implementazioni indipendenti ed interoperabili dello standard per avere una prova dell’utilità

dello stesso nel suo insieme. A questo punto spesso capita che le specifiche nello standard abbiano bisogno di essere ripetute o che le implementazioni non realizzino tutte le caratteristiche dello standard. Per questi ed altri motivi non è affatto scontato il passaggio da Proposed a Draft Standard. Se, però, viene raggiunto lo “status“ di Draft Standard, è necessario che, in un tempo che va dai quattro ai ventiquattro mesi, si abbiano più di due implementazioni indipendenti che siano in grado di funzionare tra loro per poter passare allo stato di Internet Standard meglio noto come “full standard”.

2.3.1 Working Group che si occupano

del GMPLS

Ogni WG ha un ordinamento che definisce quale deve essere il campo d’azione della discussione interna e gli obiettivi da perseguire.

Esaminiamo l’ organizzazione e il lavoro svolto dai WG che si occupano del (G)MPLS.

- Descrizione del CCAMP WG

Mentre lo sviluppo del protocollo MPLS è stato eseguito dall’MPLS WG, non appena è comparso sulla “scena” il GMPLS è stato creato un nuovo WG che ne studiasse l’evoluzione , il CCAMP (Common Control and Measurement Plane ).

Il CCAMP WG appartiene alla pseudo-area Sub-IP che è stata creata per gestire quelle questioni che non sono legate soltanto allo strato IP.

Nella Sub-IP troviamo, oltre al CCAMP WG , il TEWG, l’IP over Optical , il GSMP , l’IPORPR , il PPVPN e l’MPLS.

• Punti di interesse del CCAMP

Il CCAMP WG si occupa di coordinare il lavoro all’interno dell’IETF allo scopo di definire un piano di controllo comune ed un differente piano comune di misurazione per le tecnologie di core

tunneling. In questo contesto, la misurazione riguarda

l’acquisizione e la distribuzione di attributi importanti per l’ instaurazione di tunnel e percorsi.

Entrando più nel dettaglio nelle attività del CCAMP WG possiamo rilevare l’importante ruolo che riveste nel processo di standardizzazione del GMPLS.

o in collaborazione con il TEWG, il CCAMP si occupa della definizione di metriche indipendenti dai protocolli e degli attributi di misurazione necessari a descrivere link e percorsi richiesti per il routing e la segnalazione.

o il CCAMP si occupa del Link Management Protocol che, come abbiamo avuto modo di sottolineare, riveste un importante ruolo nella struttura GMPLS.

o in collaborazione con altri WG, CCAMP si occupa di estendere i protocolli di routing (OSPF ed IS-IS) e di segnalazione (RSVP-TE)

o si occupa della definizione dei meccanismi che sono richiesti per determinare le proprietà dei percorsi stabiliti.

o svolge un lavoro di definizione dei moduli MIB relativi a determinati protocolli come l’LMP

All’interno delle attività ora elencate il CCAMP sta svolgendo dei compiti ben precisi:

o CCAMP lavora per fornire una descrizione delle proprietà delle risorse di rete raccolte attraverso i protocolli di misurazione ed esamina come queste possono essere distribuite attraverso i protocolli di routing esistenti come l’OSPF e l’IS-IS

o si occupa delle proprietà dei percorsi che hanno avuto necessità di protezione e ripristino rapido. Inoltre provvede ad assicurare che la protezione dei percorsi multi-layer e le funzioni di ripristino siano ottenibili utilizzando i protocolli già definiti di segnalazione, routing e misurazione già definiti

o lavora alla definizione di un protocollo che possa determinare il percorso attuale ed altre proprietà dei percorsi stabiliti dai protocolli di segnalazione CCAMP o definisce meccanismi di segnalazione e routing per

rendere possibile la creazione di percorsi che misurano diverse aree IGP ed AS

o decisivo per lo sviluppo delle reti ottiche è il lavoro di collaborazione che viene svolto con l’ITU-T nell’ambito dell’ASON (Achitecture for Automatically Switched Optical Networks) del quale parleremo ampiamente più

avanti . Infatti CCAMP lavora per identificare quali requisiti di routing e segnalazione presenti nell’ASON non sono ancora soddisfatti dai protocolli definiti nel CCAMP

- Descrizione dell’MPLS WG

L’ MPLS WG è responsabile per la standardizzazione della tecnologia che consente l’utilizzo del label switching e per l’implementazione di percorsi a commutazione di label su Packet-over-Sonet , Frame Relay , ATM e LAN. Questo WG è anche responsabile della descrizione delle MIB per le funzionalità specificate nella tecnologia MPLS.

• Punti di interesse dell’ MPLS WG relativi allo sviluppo del

GMPLS

L’MPLS WG ha concluso la fase di standardizzazione relativa alla prima generazione dell’MPLS e si occupa ora di diverse questioni relative all’MPLS stesso e al GMPLS . Queste ultime, in collaborazione col CCAMP WG, riguardano :

o aspetti specifici MPLS del traffic engineering per le multi-aree/multi-AS

determinazione delle procedure appropriate per valutare le proposte di estendere i protocolli MPLS e GMPLS .

- Descrizione del TE WG

L’ingegneria del traffico Internet viene vista come quell’ aspetto dell’ingegneria delle reti che si occupa dell’ottimizzazione delle prestazioni nella gestione del traffico ponendo particolare attenzione

all’ottimizzazione che può ottenere minimizzando il sovra-utilizzo della capacità nella rete.

Il gruppo di lavoro Internet Traffic Engineering definisce,sviluppa, specifica e raccomanda principi, tecniche e meccanismi per l’ingegneria del traffico in Internet. Questo WG serve anche come forum generale per discutere i miglioramenti da apportare ai protocolli IETF per sviluppare le funzioni di ingegneria del traffico.

• Punti di interesse del TEWG

Il principale interesse del TEWG risiede nella misurazione e negli aspetti di controllo dell’ingegneria del traffico internet

Intra-Domain (I-D) che include la previsione, la misurazione e il

controllo del routing I-D nonché la misurazione e gli aspetti di controllo per l’allocazione delle risorse di rete I-D. Le tecniche già in uso o in una situazione di sviluppo avanzato per l’ingegneria del traffico includono i modelli ATM e Frame Relay,approcci basati sull’MPLS, routing C-B (Constraint-Based) e metodologie di ingegneria del traffico in ambiente Diff-Serv. Il TEWG descrive e caratterizza queste ed altre tecniche, documenta come si adattano e identifica gli scenari in cui sono utili. È importante sottolineare che il TEWG collabora con il CCAMP per definire parametri, misurazioni e controlli di cui l’ingegneria del traffico ha bisogno. - Descrizione del WG IPO

L’avvento di reti ottiche che utilizzano tecnologie come la DWDM (Dense Wavelenght Division Multiplexing) e di dispositivi come gli OXC (Optical Cross-connect) aggiunge molte nuove possibilità al

miglioramento delle prestazioni delle reti IP e al supporto di una previsione più veloce e flessibile dei servizi IP. È comunque necessario che molti aspetti vengano puntualizzati prima che i prodotti basati su queste tecnologie possano essere impiegati nelle reti dai SP ( Service Providers). All’ interno di questo scenario si muove l’IPO WG .

• Punti di interesse del WG IPO

o si occupa di documentare l’utilizzo di metodi per il piano dati e di controllo per l’IP over Optical

o identifica e documenta le caratteristiche delle reti di trasporto ottiche importanti per selezionare i percorsi dei canali ottici ed instaurarli o meno.

o documenta le applicazioni del controllo comune ed i protocolli di misurazione

o documenta i requisiti per il controllo di reti ottiche attraverso elementi al di fuori della rete ottica stessa o si occupa di documentare l’applicabilità dei protocolli

basati sull’IP per poter controllare la diffusione delle informazioni sulla topologia della rete ottica, della metrica e delle informazioni di vincolo

o si occupa di far approvare un nuovo programma di lavoro se si riscontra la necessità di sviluppare nuovi protocolli . L’IPO WG lavora in coordinamento con altri WG all’interno dell’IETF per sollecitare lo sviluppo dei lavori in corso e, quando lo ritiene necessario, genera richieste ad altri WG. Ma è importante anche il lavoro che svolge in collaborazione con gli altri enti di

standardadizzazione, come ITU-T, che sono coinvolti nelle stesse attività dell’IPO WG allo scopo di condividere informazioni e coordinare le attività.

- Descrizione dell’GSMP WG

Il GSMP WG è responsabile del completamento della standardizzazione del protocollo GSMP attraverso una risposta a quei problemi del protocollo che sorgono durante l’implementazione delle specifiche . Ricordiamo che il protocollo GSMP fornisce il controllo sulla configurazione degli switch oltre alla gestione delle “porte” , al controllo della connessione, Quality of Service (QoS) con controllo del traffic engineering (TE) e segnalazione delle statistiche e degli eventi asincroni per i dispositivi MPLS che commutano le label.

• Punti di interesse del GSMP WG

È importante dare rilievo al fatto che il GSMP WG, nell’ambito del processo di miglioramento del protocollo GSMP, sta lavorando per fare in modo che quest’ultimo venga esteso per supportare le caratteristiche richieste dal CCAMP WG . Infatti , attualmente, il GSMP manca delle specifiche semantiche necessarie agli switch ottici,allora ,il GSMP WG sta provvedendo a definire quelle soluzioni che consentono di supportare lo switching ottico e pone attenzione alla compatibilità con il lavoro del CCAMP WG. Gli sviluppi che verranno apportati, includeranno i nuovi casi di “label” per supportare l’utilizzo delle tecnologie ottiche.

La figura che segue (figura 2.4) ha lo scopo di mostrare lo stato dei principali protocolli che fanno parte della struttura del GMPLS all’interno del processo di standardizzazione portato avanti dall’IETF. Essi sono suddivisi nelle tre categorie : Signaling, Routing e Link Management.

Figura 2.4 : timeline sullo stato della standardizzazione GMPLS

- Signaling

- Link Management

o

È stato sottoposto diverse volte al WG-last call

- Routing

o

WG Draft WG Approval

Individual Draft IETF Approval Proposed Std RFC LMP Signaling Routing

t

Risulta evidente che mentre i protocolli di segnalazione sono nel livello d’ingresso dello standard track, i protocolli di management e di routing si trova ancora nella condizione di ID e quindi sono sottoposti a cambiamenti ulteriori prima di entrare nello standard track.

La tabella che segue,invece, fornisce un elenco completo di tutti i documenti prodotti dai vari WG dell’IETF che hanno attinenza al (G)MPLS.

La tabella è suddivisa in Aree : (G)MPLS, GMPLS DiffSrv ed estensioni ASON, SDH/SONET, G.709WDM, RSVP-TE, CR-LDP, LMP, RoutingGeneral, Routing OSPF, Routing ISIS, Routing BGP, IPO, MIB, Multi-Area-Routing. Per ogni documento viene specificato, oltre al titolo , il tipo e la sigla che lo contraddistingue e lo stato attuale.

2.4 ITU-T:struttura e processi di

standardizzazione

L’ITU-T è uno degli enti maggiormente coinvolti nella creazione di standard internazionali nel settore delle telecomunicazioni ed utilizza una filosofia di lavoro differente dagli altri enti perché i requisiti e le architetture di rete che vengono realizzate dai suoi SG (Study Group) rispondono alle richieste dei membri dell’ITU stesso.

All’interno dell’ITU-T, l’SG 15 è il gruppo che si occupa dello studio delle reti di trasporto ottiche ed è per questo direttamente coinvolto nello sviluppo dell’ASON all’interno del progetto di definizione di uno standard per il piano di controllo ottico. Questo lavoro ha avuto inizio come risposta ad una domanda dei membri dell’ITU di creare e definire le reti di trasporto commutate in maniera automatica. Il lavoro svolto dall’ITU-T si diversifica in maniera sostanziale da quello svolto dagli altri enti di standardizzazione perché parte da un punto di vista architetturale e solo in un secondo momento passa a quello implementativo.

- Descrizione dell’ ASON

Le moderne reti ottiche comprendono un piano di trasporto ed un piano di gestione. ASON introduce un piano di controllo che interagisce sia con quello di trasporto che con quello di gestione. E’ bene sottolineare che ASON non è un protocollo o un insieme di protocolli

o facilitare una configurazione rapida ed efficiente delle connessioni all’interno dello strato di trasporto per poter supportare diversi tipi di connessione

o riconfigurare o modificare le connessioni che supportano le Call (cioè l’associazione tra due utenti che si trovano alle estremità che supportano esempi di servizi) stabilite in precedenza

o eseguire la funzione di ripristino

Il piano di controllo previsto dall’ASON è costituito di diverse componenti che eseguono funzioni specifiche comprese quelle di determinazione del percorso e di segnalazione. Le componenti del piano di controllo sono descritte in modo che non ci siano restrizioni relative al modo in cui queste funzioni sono combinate e messe insieme. Le interazioni tra queste componenti e il flusso di informazioni richiesto per la comunicazione tra i componenti sono ottenuti attraverso le interfacce. Nella figura 2.3 è possibile vedere l’interazione tra i piani di controllo, gestione e trasporto che vengono utilizzati per supportare le connessioni commutate dello strato di rete.

Nella figura possiamo notare il DCN (Data Comunication Network) che fornisce dei percorsi di comunicazione per trasportare le informazioni di segnalazione e di gestione. Il piano di controllo fornisce la possibilità di stabilire o mettere giù una connessione su richiesta dell’utente oltre a poter gestire una richiesta. In aggiunta, esso consente che vengano ristabilite le connessioni non riuscite. Le informazioni sullo stato della connessione (guasti e qualità del segnale) sono scoperte attraverso il piano di trasporto e fornite al piano di controllo. Il piano di controllo è in grado di distribuire informazioni legate allo stato dei link (adiacenza,capacità disponibile e guasti) per consentire di mettere su una connessione o viceversa. Le informazioni dettagliate relative alla gestione dei guasti o quelle che vengono fuori dal monitoraggio delle prestazioni sono trasportate attraverso il piano di trasporto e di gestione. Il piano di controllo, così come quello di trasporto, viene suddiviso in domini che combaciano con i domini amministrativi della rete. All’interno del dominio amministrativo, il piano di controllo può essere ulteriormente suddiviso in aree di routing (per poter avere una maggiore scalabilità); queste,poi, possono essere ancora suddivise in insiemi di componenti di controllo. Le risorse del piano di trasporto utilizzate dall’ASON saranno poi suddivise per corrispondere esattamente alle suddivisioni create nel piano di controllo. L’interconnessione tra domini, aree di routing e componenti di controllo viene descritta in termini di punti di riferimento. Lo scambio delle informazioni attraverso questi punti di riferimento è descritto attraverso molte interfacce astratte tra i componenti di controllo. L’interconnessione fisica è fornita da una o più

interfacce. L’interfaccia fisica si ottiene attraverso il “mapping” di un’interfaccia astratta con un protocollo.

Il punto di riferimento tra il dominio amministrativo ed un utente finale è chiamato UNI , quello tra domini è chiamato E-NNI e quello tra aree di routing o tra aree di controllo è chiamato I-NNI.

La figura seguente mostra,per ogni piano all’interno dell’ASON, quali sono le funzioni svolte.

figura 2.6: funzioni dei piani in una rete ottica - Procedure di standardizzazione dell’ITU-T

Il WTSA (World Telecommunications Standardization Assembly) è l’ente che si riunisce con cadenza quadriennale e definisce la politica generale per il settore delle telecomunicazioni, determina gli SG ed

approva il loro programma di lavoro per un periodo di studio di quattro anni oltre a nominare presidente e vice-presidente dell’SG stesso. Il TSAG (Telecomunication Standardization Advisory Group), invece, si occupa di revisionare programmi, priorità, questioni finanziarie e strategiche per il settore delle telecomunicazioni; esso controlla il completamento del programma di lavoro, ristruttura e determina gli SG .Il TSAG fornisce linee guida per il lavoro degli SG oltre alle misure da utilizzare per avere una maggiore collaborazione con gli altri settori dell’ITU-T e gli altri enti di standardizzazione.

Il lavoro vero e proprio di standardizzazione viene svolto dagli SG che sviluppano raccomandazioni per i vari campi delle telecomunicazioni. Gli SG, per portare avanti con più efficienza il loro lavoro, utilizzano le “questioni di studio”. Ognuna di queste indirizza gli studi tecnici in una area particolare della standardizzazione delle telecomunicazioni. Gli SG si incontrano ad intervalli di nove mesi per fare il punto sullo sviluppo dello standard.

- ITU-T SG15 e GMPLS

ASON è un’architettura che mira ad essere completa ,scalabile ed elastica nei confronti dei guasti ed è stata sviluppata dall’alto in basso considerando cioè prima una lista esplicita di requisiti e partendo da una architettura di alto livello fino a raggiungere i componenti individuali dell’architettura. Soltanto quando i singoli componenti architetturali sono definiti in dettaglio vengono presi in considerazione quei protocolli che rispondono ai requisiti dei componenti stessi .

Lo SG 15 è il gruppo leader nello studio e nello sviluppo delle tecnologie e delle reti di trasporto ottico. Le sue funzioni possono essere così riassunte:

o studio di alcune delle questioni cardine relative alla struttura e alla tecnologia delle OTN (Optical Transport Network)

o definizione e mantenimento degli standard in collaborazione con altri SG ed altri enti di standardizzazione

o coordinazione dei gruppi di studio per assicurare lo sviluppo di raccomandazioni complete , opportune ed omogenee.

Lo SG 15 ha sviluppato diversi ed importanti standard che si riferiscono direttamente all’ASON come:

o G.ason che descrive l’architettura ASON.

o G.dcm che descrive gli aspetti che riguardano la segnalazione.

o G.rtg che si occupa della descrizione dell’architettura e dei requisiti per il routing nell’ ASON.

o G.disc che descrive le tecniche per la scoperta automatizzata e generalizzata.

Nella figura seguente vengono esposti i documenti redatti dallo SG 15 relativamente all’ASON e i protocolli GMPLS che rispondono ai requisiti ASON nei vari settori: routing, segnalazione, link management.

Figura 2.7: relazioni tra requisiti dell’architettura ASON e protocolli GMPLS

All’interno dello SG 15 vengono sviluppati anche quei protocolli che sono detti ASON-compliant perché rispettano l’architettura ASON e le sue specifiche. Tra questi abbiamo diversi protocolli utilizzati nel

GMPLS che sono stati opportunamente elaborati per rispondere alle specifiche dell’ASON. Vediamo quali sono le raccomandazioni che descrivono il funzionamento di questi protocolli:

o G.7713.2/Y.1704.2 descrive i meccanismi di chiamata distribuita e di gestione della connessione (DCM) utilizzando il protocollo RSVP-TE utilizzato all’interno della struttura GMPLS.

o G.7713.3/Y.1704.3 descrive i meccanismi di chiamata distribuita e di gestione della connessione (DCM) utilizzando il protocollo CR-LDP utilizzato all’interno della struttura GMPLS.

o G.7714.1/Y.1705.1 descrive i protocolli per la scoperta automatica nelle reti SDH ed OTN. I protocolli utilizzati fanno uso di alcuni aspetti presenti nel Link Management Protocol .

Nella tabella che segue vengono elencate alcune delle raccomandazioni elaborate dallo SG 15 .

Le raccomandazioni elencate riguardano sia l’architettura , gli aspetti di segnalazione e routing dell’ASON sia quei protocolli che vengono utilizzati nel GMPLS o che provengono da altre esperienze relative alle reti di trasporto ma che vengono elaborati dallo SG 15 perché rispondano ai requisiti e all’architettura ASON.

Tabella 2.2 : raccomandazioni prodotte dall’ ITU-T SG15

2.5 OIF: Struttura e processi di

standardizzazione

L’OIF è un forum che ha come obiettivo l’accelerazione dello sviluppo dell’Internetwork ottico ed è aperto alla partecipazione di oltre 250 compagnie. L’organizzazione mira a fornire una sede per utenti, carrier, service provider e produttori di attrezzature per lavorare in collaborazione, risolvere problemi e sviluppare importanti specifiche che assicurino l’interoperabilità delle reti ottiche.

- Organizzazione e working group

Attualmente all’interno dell’OIF sono presenti ben sei WG. La figura 2.5 mostra com’è organizzato l’OIF e quali sono i rapporti tra i vari WG.

o Architecture WG

L’architecture WG, basandosi sulle richieste dei service provider, definisce i concetti, le definizioni, le analisi e la documentazione inerenti ai problemi dell’architettura delle reti ottiche.

o Carrier WG

Definisce e produce le linee guida relative ai servizi e alle funzioni che saranno supportate dai futuri prodotti impiegati nel networking ottico.

o Interoperability WG

Semplifica le metodologie di verifica che sono utilizzate per omologare la conformità dei risultati ottenuti e

contribuisce attraverso una guida tecnica alle prove di interoperabilità.

Figura 2.6 : relazioni tra i WG nell’OIF

o OAM&P (Operation Administration Maintenance &

Provisioning) WG

Sviluppa le operazioni , l’amministrazione, i requisiti di mantenimento e previsione e le linee guida che si possono utilizzare per fare progettazione, ingegnerizzazione e previsione delle risorse di rete.

o Physical and Link Layer WG

Specifica le funzioni e le caratteristiche necessarie a definire e stabilire l’interconnessione dei segnali tra i dispositivi di internetworking ottico.

o Signaling WG

Specifica gli accordi sull’implementazione legati ai protocolli di segnalazione da utilizzare rimettendo in uso gli standard esistenti .

- Principali produzioni degli OIF WG e relazioni col GMPLS Oggi i carrier e i service provider hanno due requisiti imprescindibili:

o sistemi di “provisioning” dinamico che forniscano un buon rapporto costo-efficienza

o soluzioni di interoperabilità tra reti per essere in grado di ottenere in breve tempo reti ottiche intelligenti.

Come abbiamo avuto già modo di constatare, l’interoperabilità del piano di controllo permette di semplificare il processo di integrazione di differenti tecnologie ed apparecchiature oltre che di facilitare l’introduzione di nuovi servizi.

Per dare una risposta a tutte queste esigenze OIF ha adottato un approccio di tipo “evolutivo” sostenendo l’applicazione di tecnologie all’interno del piano di controllo che consentono l’interconnessione della rete di trasporto con i suoi client attraverso l’ User Network Interface (OIF UNI 1.0) e tra diversi domini della rete di trasporto attraverso l’interfaccia Network Network Interface (OIF NNI).

La figura seguente mostra un esempio di utilizzo delle interfacce suddette.

Figura 2.8: esempio di utilizzo e disposizione delle interfacce UNI/NNI

Nel documento prodotto da OIF “User Network Interface 1.0 Signalling Specification” sono descritti gli accordi di implementazione prodotti da OIF per garantire il corretto funzionamento dell’interfaccia UNI . Questi sono stati standardizzati nel 2001, anno nel quale è stata condotta una dimostrazione di interoperabilità basata sull’utilizzo dell’RSVP-TE

all’interno del SuperComm 2001. Gli accordi di implementazione hanno portato a definire i seguenti aspetti:

o interfacce fisiche tra client e reti di trasporto o servizi di connettività tra reti di trasporto

o protocolli di segnalazione da utilizzare per invocare i servizi o meccanismi per il trasferimento dei messaggi di segnalazione e

procedure di auto-discovery che sorreggono la segnalazione

Dall’analisi di questi aspetti risulta evidente l’utilizzo sia dei requisiti ASON che di diversi protocolli GMPLS.

Vediamo quindi con attenzione quali protocolli del GMPLS sono stati utilizzati dall’OIF nella definizione dell’interfaccia UNI 1.0:

o per la parte di segnalazione vengono utilizzati i protocolli RSVP-TE e CR-LDP

o per il mantenimento del canale di controllo vengono utilizzate le procedure descritte nel protocollo LMP

o per la “scoperta del vicino” in fibra e fuori fibra vengono utilizzate le procedure LMP di configurazione manuale

o per la procedura di “service discovery” vengono utilizzate le procedure LMP di configurazione manuale.

L’interfaccia NNI viene utilizzata per connessioni tra elementi di questo tipo :

o reti di service provider differenti o sottoreti dello stesso provider

o connessione tra switch di differenti fornitori all’interno della stessa sottorete

Anche l’interfaccia NNI prevede l’utilizzo di protocolli standardizzati dall’IETF e utilizzati all’interno del GMPLS come il CR-LDP, l’RSVP-TE e l’OSPF-TE per il routing.

Mentre la versione 1.0 della UNI è stata ormai standardizzata, OIF sta ora lavorando ad una seconda versione delle specifiche UNI aggiungendo nuove caratteristiche richieste dai carrier membri dell’OIF stesso oltre che accordi sull’implementazione dell’NNI e sull’interoperabilità delle interfacce UNI-NNI.

Nella tabella seguente sono elencati i lavori svolti dall’OIF, principalmente dall’OAM&P WG, nell’ambito dello sviluppo dell’interfaccia UNI, dell’adozione ed adattamento di protocolli standardizzati dall’IETF e di risposta ai requisiti dell’architettura ASON. I documenti sono suddivisi in due sezioni : una prima in cui si trovano i documenti per i quali c’è già un accordo di esecuzione ed un’altra in cui abbiamo i documenti che sono sottoposti a riesame e per questo ancora oggetto di studio.

Tabella 2.3 : documenti prodotti dall’OIF

- Utilizzo congiunto OIF-UNI & GMPLS

Come abbiamo avuto modo di dire in precedenza, OIF ha sviluppato un’architettura basata sul modello Overlay nel quale non è necessario che tra i domini venga condivisa nessuna informazione sulla topologia e la rete ottica è in grado di servire più client. Seguendo questa strada OIF ha elaborato modelli in cui è permessa una “convivenza” tra GMPLS ed interfacce UNI e, come si può vedere nella figura 2.9, è possibile che un client LSR segnali la richiesta di un percorso ottico

utilizzando i protocolli di segnalazione GMPLS o segnali una richiesta di connettività utilizzando l’interfaccia UNI.

Figura 2.9:GMPLS-UNI

OIF ha elaborato anche altri modelli di rete ottica intelligente all’interno dei quali abbiamo una nuova visione della gestione del trasporto (vedi figura 2.10) . All’interno di questo modello gli OXC sono componenti essenziali del nucleo ottico della rete. Essi fanno uso del piano di controllo GMPLS e sono in grado di supportare sia il modello Peer che quello Overlay. La gestione del trasporto non assolve più il compito di instaurare connessioni individuali ma si occupa

dell’SLA (Service Level Agreement) e può essere utilizzata per supportare le VPN (Virtual Private Network).

Figura 2.10 : OIF-UNI ,GMPLS e Gestione del Trasporto

2.6 Interazione tra gli enti di

standardizzazione

I tre enti di standardizzazione (OIF , ITU-T ed IETF) svolgono le loro discussioni in parallelo, sviluppano lavori complementari e mantengono

stretti legami. Infatti, si è capito che è soltanto attraverso l’utilizzo di una linea comune di intenti che si può accelerare il processo di standardizzazione e di conseguenza sia i carrier che i vendor potranno beneficiare delle innovazioni che ne deriverebbero.

La sinergia tra i tre enti è mostrata nella figura 2.11 dalla quale si desumono i differenti compiti eseguiti alla ricerca della definizione di un piano di controllo ottico comune.

Nonostante ciò, tra i vari enti sussistono differenze metodologiche e tecniche che non è facile superare e che sono diretta conseguenza delle scelte da loro compiute negli anni precedenti.

- IETF ed ITU-T

ITU-T produce requisiti ed architetture basandosi sulle richieste dei suoi membri e non lavora allo sviluppo di nuovi protocolli quando quelli già esistenti svolgono le funzioni previste. L’IETF, invece, produce protocolli in risposta a requisiti industriali generali. ASON e GMPLS possono essere parti complementari di un unico lavoro e gli sviluppi apportati sono volti ad assicurare che i due modelli possano lavorare correttamente assieme. Le relazioni tra i due enti sono continue, ognuno riconosce ed apprezza il lavoro svolto dall’altro ed anche le compagnie che lavorano nel settore delle telecomunicazioni sono impegnate ad assicurare che le due organizzazioni lavorino in maniera sincronizzata.

- Differenze tecniche tra ASON e GMPLS

Gli switch GMPLS operano all’interno di un’area in cui gli elementi sono alla “pari”. I nodi ai confini della rete sono in grado di accettare flussi di dati di tipo differente e di inviarli attraverso l’area GMPLS verso gli altri nodi di confine. Tutti i nodi che fanno parte della rete GMPLS scambiano le informazioni liberamente come se GMPLS racchiudesse i vari elementi all’interno di un ambiente “fidato”. Un modello di questo tipo viene chiamato “GMPLS ovunque” (vedi figura 2.12) ed utilizza un approccio differente dall’ASON che, invece, ha come obiettivo quello di costruire un supporto per quei dispositivi di

rete che già esistevano ma sono stati “ereditati” nell’architettura. ASON non considera come realistica la possibilità dell’inter-operabilità tra i vendor a causa dei problemi di compatibilità del piano dati. L’architettura ASON è quella che prende in considerazione i domini che interagiscono tra loro in maniera standardizzata ma le cui

Figura 2.12: rete GMPLS

operazioni interne sono indipendenti dai protocolli e non soggette a standardizzazione . Nel modello previsto da ASON (vedi figura 2.13), l’utente è un terminale che richiede servizi alla rete di trasporto piuttosto che fornirli e può richiedere servizi di connessione

dinamicamente attraverso la UNI. Gli UNI, I-NNI ed E-NNI,che come abbiamo già detto sono noti col nome di punti di riferimento, indicano le posizioni all’interno della rete in cui è necessario che vengano utilizzati i protocolli standardizzati.

figura 2.13: rete ASON che utilizza le interfacce UNI ed E-NNI

Ogni punto di riferimento ha requisiti diversi sul grado di informazione da nascondere .

o UNI nasconde all’utente tutte le informazioni di routing e di indirizzamento relative alla parte interna della rete . o I-NNI permette che vengano fornite tutte le informazioni

relative al routing.

o E-NNI inter operator permette che vengano scambiati alcuni tipi di informazioni per fare in modo che i percorsi possano essere calcolati attraverso la rete ma la parte interna della rete è nascosta

o E-NNI intra operator può nascondere o meno informazioni a seconda della struttura amministrativa del particolare operatore.

- Punti di conflitto tra architettura ASON e protocolli di

segnalazione GMPLS e contributo dell’ OIF-UNI 1.0

L’interfaccia UNI richiede nuove funzioni che non sono fornite dal GMPLS. Vediamo quali sono le funzioni di segnalazione richieste:

1. E’ necessario che vengano assegnati nuovi indirizzi agli utenti della rete per poter mantenere una completa separazione tra l’utente stesso e gli indirizzi di rete.

2. Poiché nessuna informazione di routing può “passare” attraverso l’interfaccia UNI, l’utente non può calcolare i percorsi da seguire e deve passare le sue richieste al nodo più vicino all’interno della rete .

3. L’utente deve conoscere in anticipo quali richieste la rete può soddisfare. Questo porta alla necessità di includere un servizio di scoperta .

L’OIF, nelle specifiche UNI 1.0, ha lavorato proprio alla creazione di profili dei due protocolli di segnalazione GMPLS in modo che soddisfino i requisiti di cui sopra ed ha apportato miglioramenti al protocollo LMP perché possa includere un servizio di scoperta. L’ITU-T ha spinto con decisione il lavoro dell’OIF in questa area .

Esistono altri divari tra l’architettura ASON e le definizioni inserite negli attuali protocolli GMPLS; infatti, è necessario soddisfare il requisito ASON di distinguere la segnalazione per istituire una call da quella per mettere su una connessione.

È problematico riuscire a trasferire il concetto di call nel GMPLS per i seguenti motivi:

- A differenza del GMPLS, nell’ASON gli utenti sono dei dispositivi finali che richiedono i servizi alla rete di trasporto piuttosto che fornirli. Nel GMPLS la cosa che più si avvicina ad un utente ASON può essere un nodo di confine.

- I protocolli di segnalazione GMPLS hanno già prevista una associazione tra parti finali così una call può sembrare una duplicazione di funzioni.

Ci sono attualmente proposte di estendere la segnalazione GMPLS in modo da includere il “call setup” ASON ma si incontrano delle

resistenze da parte di quei vendor che potremmo definire “puristi” del GMPLS poichè non ritengono necessarie tali estensioni. Anche i protocolli di routing GMPLS hanno bisogno di essere modificati per supportare i requisiti ASON ma anche in questo caso si sono trovate due grosse differenze tecniche : la prima legata al modello a strati ASON e la seconda legata al routing gerarchico.

- Punti di conflitto tra architettura ASON e protocolli GMPLS legati

al modello a strati ASON

Le difficoltà di convivenza tra architettura ASON e protocolli GMPLS si riscontrano anche nel routing, infatti, a causa della diversa origine, si riscontrano differenze già nella definizione di link . Nel GMPLS, infatti, un link è in grado di supportare molti strati differenti di traffico commutato. Nell’ASON, invece, un link viene definito come in grado di trasportare solo un singolo strato di traffico commutato. Qui, un link realizzato su di un mezzo fisico non è distinguibile dal punto di vista della segnalazione, del routing e della scoperta da uno realizzato su di uno strato inferiore in una connessione con una banda più ampia. Questo fa si che ogni strato della rete debba essere trattato in maniera separata ovvero, per ogni strato, è richiesto uno specifico esempio di protocollo di segnalazione, routing e discovery. Le differenze tra ITU-T ed IETF possono essere parzialmente attribuite al fatto che i protocolli di routing IETF, tradizionalmente, hanno a che fare con un singolo

strato, quello IP, mentre ITU-T ha definito un certo numero di tecnologie del piano di trasporto stratificato e la terminologia utilizzata nell’ASON segue i concetti ereditati.

o Routing stratificato

Nel GMPLS una fibra reale, fisica può essere rappresentata come un singolo link logico con diverse possibilità di switching attraverso il protocollo OSPF-TE.

Al contrario, nell’ASON, i differenti link logici all’interno della fibra devono essere comunicati, ognuno allo strato relativo, nel protocollo di routing. L’ITU-T guarda a questo requisito sulla stratificazione come un elemento cruciale per avere una maggiore scalabilità nelle reti poiché concede ad ogni strato la possibilità di operare indipendentemente dagli altri. Secondo l’ITU-T l’aggiunta di strati non incrementa la complessità del calcolo dei percorsi e non rende eccessiva l’abbondanza di informazioni in un particolare strato. IETF non concorda con le deduzioni dell’ITU-T e, a suo parere, la stratificazione richiede un aumento della capacità della memoria per gli elementi di rete ed accresce il traffico nella rete di controllo.

Il lavoro svolto nell’ultimo periodo dall’IETF ha tenuto comunque conto dei requisiti che provengono dall’ITU-T

ASON e ha proposto l’utilizzo di protocolli di routing GMPLS adattandoli alle necessità ASON .

o Discovery stratificato

I draft iniziali relativi al protocollo LMP non contemplano il caso in cui vengono utilizzati diversi esempi di LMP in differenti strati. Ma IETF, già da tempo, ha previsto le estensioni al protocollo LMP per sistemi di linee ottiche DWDM nel documento “draft-ietf-ccamp-lmp-wdm-02.txt” che è inserito nella tabella 2.1. Qui già si prevede di utilizzare il protocollo LMP su due strati e ciò potrebbe, almeno in teoria, essere esteso al modello ASON.

Un altro problema relativo al protocollo LMP è quello della sua non perfetta rispondenza al concetto di discovery esposto nella raccomandazione G.7714/Y.1705.

Nel CCAMP dell’IETF è in corso un dibattito sulla necessità di includere quanto previsto dalla raccomandazione suddetta nel protocollo LMP.

- Punti di conflitto tra architettura ASON e protocolli GMPLS legati

al routing gerarchico

Per avere una descrizione completa dello strato di rete è necessario fornire informazioni relative a tutti i suoi nodi e link. Oggi,però, distribuire una descrizione della topologia completa della rete attraverso un protocollo di routing può diventare una soluzione

impraticabile una volta che la rete ha superato certe dimensioni a causa della frequenza degli aggiornamenti che bisogna distribuire e del largo numero di utenti . Per riuscire a migliorare la scalabilità delle reti è necessario ridurre il numero di informazioni da distribuire. La rete è suddivisa amministrativamente in aree di routing . I database di routing contengono informazioni dettagliate riguardo l’area di routing locale e meno dettagliate riguardo le aree di routing remote. Le aree di routing possono essere suddivise, a loro volta, in maniera ricorsiva creando una gerarchia di informazioni di routing . Un protocollo di routing lavora ad ogni livello di questa gerarchia.

Attualmente, nelle reti a commutazione di pacchetto, ci sono due approcci al routing gerarchico: BGP e PNNI.

BGP (Border Gateway Protocol) diffonde un vettore informazione sul percorso ovvero fa conoscere il percorso verso la destinazione ma non le informazioni sulla topologia della rete. Quando diverse destinazioni sono raggiungibili utilizzando lo stesso percorso, esse vengono aggregate in modo che solo un percorso venga diffuso. Quando, invece, una singola destinazione è raggiungibile attraverso percorsi differenti, viene utilizzato solo il percorso al quale è associato il costo minore mentre gli altri vengono scartati. I più volte citati OSPF ed ISIS sono della famiglia BGP e creano due o tre livelli di gerarchia di routing. PNNI (Private Network to Node Interface) crea una gerarchia di controllori di routing che hanno una visione dello stato dei link della rete e possono utilizzarsi ricorsivamente ad ogni livello della gerarchia,diversamente da BGP che viene utilizzato solo nel livello più

alto. I controllori che si trovano ad un livello più elevato hanno una visione più ampia della rete ma solo informazioni limitate riguardo ai nodi e link. I controllori che si trovano ad un livello più basso hanno una visione più limitata della rete ma informazioni più dettagliate su nodi e link . Il cuore del problema è legato all’utilizzo del vettore che contiene informazioni sul percorso per le reti ottiche. Infatti i cosiddetti protocolli Path Vector rendono noti i percorsi che hanno pre-calcolato. Ci si chiede, però, come chi comincia una connessione ottica può essere garantito a trovare un percorso pre-calcolato che soddisfi tutte le particolari restrizioni di una particolare connessione. Infatti, il numero di potenziali combinazioni di restrizioni è elevato e quindi risulta difficile riuscire a trovare una strategia per rendere noti alcuni percorsi verso una destinazione comune quando ognuno è calcolato utilizzando dei diversi vincoli.

L’ITU-T sostiene che le informazioni del Path Vector non possono essere sufficienti per il routing nelle reti ottiche di grosse dimensioni. Mentre l’IETF è molto combattuto sull’argomento , OIF ha proposto di migliorare il protocollo OSPF-TE per trasformarlo in un protocollo di routing link state chiamato DDRP (Domain-to-Domain Routing Protocol). Il DDRP è stato poi suddiviso in due parti : una che descrive i requisiti e l’architettura ed un’altra in cui troviamo due documenti di specifiche rispettivamente su OSPF ed ISIS. Quando il lavoro sarà completo OIF potrà decidere quale soluzione adottare per caratterizzare l’interfaccia E-NNI. La tendenza da parte di ITU-T sembra essere quella di adottare il DDRP come base per i protocolli di routing della

categoria ASON-compliant specificati della raccomandazione G.7715 mentre IETF resta ancora in una posizione incerta.