ITMI20012122A1 - Connessione lan-to-lan trasparente tra due locazioni clienti attraverso una rete rpr di trasporto dati - Google Patents

Description

DESCRIZIONE

La presente invenzione riguarda le reti di trasporto dati ed in particolare riguarda un metodo ed un apparato per fornire una funzionalità trasparente di connessione LAN-to-LAN tra due locazioni pluri-cliente attraverso una rete di trasporto dati, ad esempio una rete del tipo RPR.

Come è noto, le reti locali per telecomunicazioni (LAN, Locai Area Networks) sono reti a pacchetto commutate (packet-switched networks) che sono ottimizzate per il traffico dati usando la tecnologia Ethernet. Le strutture Ethernet sono tra le più consolidate per interconnettere computer in una rete LAN e sono basate su una topologia a bus.

Sono altresì note le reti di trasporto dati, come ad esempio le reti RPR (Resilient Packet Ring) ad anello, atte ad ottimizzare l'utilizzo della banda disponibile per il trasporto di pacchetti su reti chiuse. I meccanismi che regolamentano il funzionamento delle reti RPR sono in corso di standardizzazione presso l'ente intemazionale IEEE.

La tecnologia ad anello può ad esempio essere basata su livelli fisici di trasporto SDH, SONET o Ethernet, su cui vengono fisicamente trasportate le trame delle reti RPR. Una rete RPR nota è basata su di una configurazione a due anelli controrotanti, rispettivamente identificati come anello interno e anello esterno. Entrambi gli anelli sono usati per trasportare trame RPR di dati e/o di controllo tra una serie di nodi RPR. Per trama RPR si intende una trama di layer-2 della nota pila ISO-OSI oppure TCP -IP. Le trame RPR di controllo sono preposte a svolgere le funzioni RPR note cosiddette di "topology discovery", "protection switching" e "bandwidth management".

La funzione di "topology discovery" si basa su di un meccanismo che consente ad ogni nodo RPR dell'anello di identificare e localizzare tutti gli altri nodi e le loro distanze. Quando un nodo RPR inserisce una nuova trama RPR nell'anello, seleziona l'anello interno o esterno in modo da seguire il percorso più corto (ad esempio in termini di numero di nodi RPR da attraversare) verso il nodo RPR destinazione secondo la particolare topologia della rete.

La funzione di "protection switching" consente di assicurare la cosiddetta "resiliency", cioè la capacità di protezione a livello di pacchetto RPR, reagendo entro un determinato tempo dalla rilevazione di un guasto.

Anche se nell'ambito della standardizzazione RPR non è ancora stato definito nel dettaglio, il formato di una trama RPR comprende una parte di intestazione (RPR Header) ed una di payload (contenuto informativo vero e proprio). La parte di payload contiene l'informazione di livello superiore da trasportare. Tra i vari campi dell'intestazione vi sono comunque i seguenti:

identificativo del nodo RPR di destinazione;

- identificativo del nodo RPR sorgente; e

tipo di protocollo, per identificare il protocollo che caratterizza la parte seguente della trama/pacchetto RPR, cioè l'informazione di livello superiore trasportata nel payload.

In corrispondenza di ogni nodo di un anello RPR, viene letto l'Header RPR e viene identificato il nodo RPR di destinazione: se l'identificativo del nodo di destinazione corrisponde proprio all'identificativo del nodo RPR che ha ricevuto il pacchetto in questione, il pacchetto viene estratto dalla rete RPR, altrimenti viene fatto proseguire trasparentemente senza effettuare alcuna elaborazione su di esso fino a raggiungere il nodo RPR di destinazione. Una caratteristica intrinseca delle reti RPR è quella di trasportare fino a destinazione anche le trame errorate, fintanto che l'errore non impedisca ai nodi RPR intermedi di identificare il nodo RPR destinatario. Quest'ultimo sarà libero di decidere, in base al tipo e alla "pesantezza" dell'errore, se scartare il pacchetto o passarlo al livello superiore.

Tipicamente, su ogni nodo di ingresso/uscita sono attestate più porte connesse a diversi customers (clienti). Questo significa che un nodo RPR riceve trame Ethernet generate da più porte, deve introdurle nella rete RPR e trasportarle fino a destinazione dove, naturalmente, le varie trame Ethernet dovranno essere riassegnate alle rispettive porte di uscita. Purtroppo, il meccanismo RPR non prevede questo tipo di funzionalità dal momento che considera unicamente, per ogni nodo RPR, un singolo ingresso ed una singola uscita.

In linea teorica, questo tipo di problema potrebbe essere risolto utilizzando un protocollo di incapsulamento tipo GFP (Generic Framing Procedure) la cui definizione è in corso presso l'ente di standardizzazione intemazionale ITU-T. Tuttavia, pur consentendo di portare a destinazione i pacchetti errorati, il limite di questo protocollo è che non è applicabile alle reti dati ma solo alle reti SDH/SONET o alle reti di trasporto ottiche OTN. Nel "mondo dati", in particolare per reti magliaie, è anche nota la tecnologia MPLS (Multi Protocol Label Switching) utilizzata nell’ambito dell'architettura delle Layer 2 MPLS VPN descritte in un Internet-Draft presentato in IETF (PPPVPN Working Group). Il problema intrinseco di questa architettura è che le trame Ethernet eventualmente errorate, correttamente trasportate da una rete ad anello RPR, vengono scartate non appena fuori dalla rete RPR e non possono raggiungere la porta di uscita finale.

Scopo pertanto della presente invenzione è quello di fornire un metodo per interfacciare efficacemente il livello RPR e il livello cliente in una rete di trasporto dati, in particolare per gestire pacchetti provenienti da / indirizzati verso più interfacce cliente senza che questi, qualora siano errorati, possano essere scartati.

Questo scopo viene ottenuto attraverso un metodo secondo la rivendicazione 1 e un apparato secondo la rivendicazione 6. Ulteriori caratteristiche vantaggiose della presente invenzione vengono indicate nelle rispettive rivendicazioni dipendenti. Tutte le rivendicazioni si intendono una parte integrante della presente descrizione.

L'idea alla base della presente invenzione consiste nel definire un nuovo layer, layer TLS (Transparent LAN Service), la cui presenza viene segnalata da un opportuno valore nell'intestazione da stabilirsi del layer RPR.

La presente invenzione diverrà certamente chiara alla luce della descrizione dettagliata che segue, data a puro titolo esemplificativo e non limitativo, da leggersi con riferimento alle annesse tavole di figure, in cui:

Fig. 1 mostra una rete ad anello RPR con una pluralità di nodi RPR interconnessi da tratte per formare due anelli controrotanti;

Fig. 2 mostra schematicamente un nodo o elemento di rete RPR che riceve trame Ethernet da più porte e, analogamente, smista trame RPR a più porte;

Fig. 3A mostra un nodo RPR convenzionale a cui è stato associato un blocco di elaborazione aggiuntivo;

Fig. 3B mostra un nodo RPR in cui è integrato un blocco di elaborazione aggiuntivo;

Fig. 4 mostra una trama RPR secondo la presente invenzione;

Fig. 5 mostra l'assegnazione dei bit nel TLS Header; e

Fig. 6 mostra una rete ad anello RPR in cui sono state evidenziate un'interfaccia cliente di ingresso ed un'interfaccia cliente di uscita.

La Fig. 1 mostra una rete ad anello RPR con i due anelli controrotanti e una pluralità di nodi RPR (A, B, ...G). Uno qualsiasi dei nodi RPR dell'anello RPR di Fig. 1 viene riportato schematicamente ma in maggiore dettaglio in Fig. 2. Da questa rappresentazione è chiaro che, benché il nodo RPR presenti un unico ingresso (IN) di trame Ethernet, riceve trame Ethernet da una pluralità (n) di porte di ingresso. Analogamente, pur avendo un'unica uscita (OUT), quest'uscita distribuisce trame Ethernet a diverse (1, 2, ..., n) porte di uscita.

Un nodo RPR secondo la presente invenzione viene schematicamente illustrato nelle Fig. 3A e 3B. In entrambe le Figure, è presente un blocco di elaborazione aggiuntivo esterno ad un esistente nodo RPR (vedi Fig. 3A) o integrato in un nuovo nodo RPR (vedi Fig. 3B, rettangolo tratteggiato).

Nel blocco di elaborazione, vengono ricevute le trame Ethernet provenienti da porte diverse (1, 2, ...n) e vengono effettuati i processamenti standard quali ad esempio: Ethernet frame delineation, flow control e buffering. Nel blocco TLS di elaborazione viene anche costruito il payload delle trame RPR (RPR Frame) da trasportare nell'anello RPR (RPRNTW).

Secondo la presente invenzione, il blocco TLS provvede ad aggiungere alle trame Ethernet da trasportare un'intestazione aggiuntiva (TLS Header), ad esempio convenientemente costituita da 32 bits. Nell'intestazione aggiuntiva (TLS Header) vengono inserite informazioni riguardanti la porta di destinazione della trama Ethernet (OUT,, OUT2, ... OUTn). Convenientemente, per garantire una maggiore sicurezza nella fase di smistamento dei pacchetti in ricezione (cioè per evitare errati smistamenti), vengono riservati bit per effettuare, in ricezione, un controllo (HEC) degli eventuali errori accumulati nell’Header TLS durante il trasporto nell'anello RPR. In testa all'Header TLS aggiuntivo viene convenzionalmente aggiunto un Header RPR. In quest'ultimo, il campo denominato "protocol type" e riservato per indicare il tipo di protocollo utilizzato, viene riempito con un valore corrispondente.

La trama RPR costruita come detto sopra è illustrata schematicamente in Fig. 4. In Fig. 5 viene invece riportata una possibile implementazione di TLS Header. Naturalmente, il numero di bit assegnati ai vari campi (e/o il loro ordine) potrebbe cambiare senza nulla togliere alla generalità della presente invenzione. Alcuni bit non utilizzati (come i bit 21-24, tratteggiati di Fig. 5) potrebbero essere lasciati per utilizzi futuri.

La presente invenzione verrà descritta ancora più nel dettaglio con riferimento a Fig. 6. Il nodo RPR A riceve una trama Ethernet da una porta attestata a quel nodo (ne viene mostrata solo una per maggiore chiarezza), cioè la generica porta connessa all'interfaccia X (INX). Questa trama Ethernet deve essere recapitata ad urialtra locazione del customer connessa all'interfaccia Y del nodo di terminazione D (OUTY). Il fornitore di servizi ha già assegnato un certo canale tra A e D, con il suo corrispondente identificativo per effettuare questo trasporto. La trama Ethernet ricevuta viene incapsulata in una trama TLS, cioè viene aggiunto alla trama Ethernet l'Header aggiuntivo TLS. L'identificativo del canale nell'Header aggiuntivo TLS viene settato secondo il valore assegnato alla comunicazione TLS dalla porta X del nodo RPR A alla porta Y del nodo RPR D. Se non altrimenti richiesto, i bits 21-24 vengono convenzionalmente settati a "0000" e il campo HEC viene riempito con il valore calcolato sull'Header TLS. L'algoritmo utilizzato per calcolare l'HEC non verrà descritto ulteriormente dal momento che non forma oggetto della presente invenzione.

A questo punto, la trama TLS viene incapsulata nel pacchetto del layer di trasporto dati (trama RPR) che verrà utilizzato dalla rete del Service provider per trasportare il pacchetto dal nodo A al nodo D. In questo caso specifico, il campo "source address ID" conterrà l'identificativo del nodo A; il campo "destination address ID" conterrà l'identificativo del nodo D; e il campo "payload type" conterrà il valore assegnato al protocollo TLS (da stabilire).

I nodi RPR B e C, leggendo l'identificativo del nodo di destinazione, riconosceranno che la trama RPR proveniente dal nodo A non deve essere estratto da loro ma deve proseguire. Il nodo RPR B (e successivamente il C) non scartano la trama eventualmente riconosciuta come errorata ma la lasciano passare trasparentemente almeno che l'errore non impedisca di identificare con certezza il nodo destinatario.

Alla fine, il nodo D riceve la trama RPR trasmessa dal nodo A. Poiché il nodo D è proprio il nodo di destinazione della trama, la termina e passa il suo payload al layer superiore (layer TLS) specificato nel campo "protocol type".

II layer TLS controlla il campo HEC dell’Header TLS. Se l'HEC è corretto (nessun errore nell'Header TLS), il suo payload viene inviato, così com'è all'interfaccia di uscita (OUTY) associata a quell'identificativo di canale Se l'HEC dell’Header TLS non è corretto ma presenta errori, non sarà possibile identificare con certezza l'interfaccia di uscita giusta e la trama deve essere necessariamente scartata. In ogni caso viene assicurato lo smistamento corretto delle trame alle interfacce giuste (in tutti i casi in cui è possibile identificare l'interfaccia di destinazione giusta). In tutti i casi in cui si riceva una trama TLS corretta ma con CHID non assegnato, la trama TLS deve essere scartata.

Le fasi del metodo secondo la presente invenzione possono a questo punto essere riassunte come segue:

in trasmissione: ricevere una trama Ethernet da un'interfaccia cliente; processare convenzionalmente la trama Ethernet ricevuta; aggiungere un'intestazione aggiuntiva (TLS Header) per formare una trama TLS e, infine, aggiungere alla trama TLS così formata un'intestazione RPR per formare una trama dati RPR da trasportare in un anello RPR. L'intestazione aggiuntiva a livello TLS contiene informazioni (CHID INX-

OUTY) relative al canale assegnato per trasportare il pacchetto dall’ interfaccia di ingresso X del nodo A all’interfaccia di uscita Y del nodo D. L'intestazione aggiuntiva a livello TLS contiene bit (HEC) riservati al controllo delle informazioni relative all’Header TLS. Preferibilmente, le informazioni relative al canale di ingresso/uscita occupano i primi 20 bits, quelle per il controllo (HEC) gli ultimi 8 bits dell'Header TLS. L'RPR Header contiene un campo di "Source Node ID" che identifica il nodo A, un campo di "Destination Node ID" che identifica il nodo De un campo di "Protocol Type", settato con un valore corrispondente al protocollo TLS.

in ricezione: ricevere una trama RPR; leggere l'intestazione RPR della trama, toglierla dall’anello RPR e passarla al layer superiore (nel nostro caso al layer TLS) nel caso il campo "Destination Node ID" corrisponda al Node ID del nodo RPR che ha ricevuto la trama; una volta passati al layer TLS, leggere l'Header TLS; controllare l'esattezza dell'Header TLS (verifica dell’ HEC); in caso di controllo positivo, smistare il contenuto informativo della trama ricevuta all'interfaccia cliente identificata da un identificativo di canale riportato nell'intestazione TLS, ovvero, in caso di controllo negativo, essendo impossibile identificare con certezza l'interfaccia cliente destinataria, scartare la trama ricevuta.

La presente invenzione riguarda anche un apparato per realizzare il metodo ed un nodo RPR comprendente l'apparato in questione. Formano oggetto della presente invenzione anche una trama TLS costruita come descritto sopra ed illustrato nelle figure e una trama (o pacchetto) RPR comprendente la trama TLS di cui sopra.

La presente invenzione potrebbe indifferentemente essere implementata via hardware o software. In questo caso, essa si estende ad un programma per elaboratore comprendente mezzi di codifica atti ad eseguire tutte le fasi del metodo quando detto programma viene fatto girare su un elaboratore. Inoltre, include un mezzo leggibile tramite elaboratore avente un programma registrato su di esso, detto mezzo leggibile tramite elaboratore comprendendo mezzi di codifica atti ad eseguire tutte le fasi del metodo quando detto programma viene fatto girare su un elaboratore.

È evidente che alla presente invenzione potranno essere apportate numerose modificazioni, adattamenti e sostituzioni di parti con altre funzionalmente equivalenti, senza peraltro fuoriuscire dalfambito di protezione definito unicamente dalle seguenti rivendicazioni.

Claims (15)

1. RIVENDICAZIONI 1. Metodo per fornire una funzionalità trasparente di connessione LAN-to-LAN tra una prima locazione pluri-cliente di partenza e una seconda locazione pluricliente di destinazione attraverso una rete RPR (RPRNTW) di trasporto dati, detta rete RPR comprendendo una pluralità di nodi RPR (A, B, ..., G) interconnessi da tratte per formare due anelli in cui trame RPR (RPR Frame) viaggiano con versi opposti/controrotanti, le locazioni di partenza e di destinazione comprendendo rispettivamente un nodo RPR di partenza (A) e un nodo RPR di destinazione (D), il metodo comprendendo, in corrispondenza del nodo RPR di destinazione (D), le fasi di: ricevere una trama Ethernet da un'interfaccia cliente; processare convenzionalmente la trama Ethernet ricevuta; aggiungere un'intestazione aggiuntiva (TLS Header) per formare una trama TLS; e aggiungere alla trama TLS così formata un'intestazione RPR (RPR Header) per formare una trama dati RPR da trasportare nella rete RPR.
2. 2. Metodo secondo la rivendicazione 1, caratterizzato dal fatto che la fase di aggiungere un'intestazione aggiuntiva (TLS Header) comprende la fase di aggiungere un'intestazione comprendente informazioni relative al canale assegnato per trasportare la trama RPR da un'interfaccia di ingresso (X) del nodo di partenza (A) ad un'interfaccia di uscita (Y) del nodo di destinazione (D).
3. 3. Metodo secondo la rivendicazione 1 , caratterizzato dal fatto che la fase di aggiungere un'intestazione aggiuntiva (TLS Header) comprende la fase di aggiungere un'intestazione comprendente bit (HEC) riservati al controllo delle informazioni relative all’ intestazione aggiuntiva.
4. 4. Metodo secondo la rivendicazione 2 e 3, caratterizzato dal fatto che le informazioni relative al canale di trasporto di trama RPR occupano 20 bit, quelle per il controllo (HEC) 8 bit.
5. 5. Metodo secondo la rivendicazione 1, caratterizzato dal fatto di comprendere le fasi, eseguite in corrispondenza del nodo RPR di destinazione (D), di: ricevere una trama RPR; leggere l'intestazione RPR della trama (RPR Header); estrarre la trama RPR dalla rete RPR e passarla ad un layer superiore TLS; leggere l'intestazione aggiuntiva (TLS Header); controllare (HEC) l'esattezza dell'intestazione aggiuntiva (TLS Header) e, in caso di controllo positivo, smistare il contenuto informativo della trama RPR ricevuta all'interfaccia cliente (Y) identificata da un identificativo di canale riportato nell'intestazione TLS, ovvero, in caso di controllo negativo, scartare la trama RPR ricevuta.
6. 6. Apparato per fornire una funzionalità trasparente di connessione LAN-to-LAN tra una prima locazione pluri-cliente di partenza e una seconda locazione pluricliente di destinazione attraverso una rete RPR (RPRNTW) di trasporto dati, detta rete RPR comprendendo una pluralità di nodi RPR (A, B, ..., G) interconnessi da tratte per formare due anell in cui trame RPR viaggiano con versi opposti/controrotanti, le locazioni di partenza e di destinazione comprendendo rispettivamente un nodo RPR di partenza (A) e un nodo RPR di destinazione (D), l'apparato comprendendo: almeno un'interfaccia cliente per ricevere una trama Ethernet; un processatore di trame Ethernet per processare convenzionalmente la trama Ethernet ricevuta; un blocco di elaborazione (Blocco TLS) atto ad aggiungere un'intestazione aggiuntiva (TLS Header) per formare una trama TLS.
7. 7. Apparato secondo la rivendicazione 6, caratterizzato dal comprendere un'uscita per passare la trama TLS ad un nodo RPR (A) atto ad aggiungere alla trama TLS così formata un'intestazione RPR (RPR Header) per formare una trama dati RPR (RPR Frame) da trasportare nella rete RPR (RPRNTW).
8. 8. Apparato secondo la rivendicazione 6, caratterizzato dal fatto che detto blocco di elaborazione (Blocco TLS) aggiunge alla trama TLS un'intestazione RPR (RPR Header) per formare una trama dati RPR (RPR Frame) da trasportare nella rete RPR (RPRNTW).
9. 9. Apparato secondo una qualsiasi delle rivendicazioni 6-8, caratterizzato dal fatto che detto blocco di elaborazione comprende: un lettore di intestazione per leggere l'intestazione aggiuntiva (TLS Header); mezzi per controllare (HEC) l'esattezza dell'intestazione aggiuntiva (TLS Header)in modo tale che, in caso di controllo positivo, il contenuto informativo (payload) della trama RPR ricevuta (RPR frame) venga smistato all'inter¬ faccia cliente (Y) identificata da un identificativo di canale

   riportato nell'intestazione TLS, ovvero, in caso di controllo negativo, la. trama RPR ricevuta (RPR frame) venga scartata.
10. 10. Apparato secondo una qualsiasi delle rivendicazioni 6-9, caratterizzato dal fatto di comprendere inoltre: una porta d'ingresso per ricevere direttamente una trama RPR (RPR Frame); mezzi per leggere l'intestazione RPR della trama (RPR Header); e mezzi per estrarre la trama RPR dalla rete RPR e passarla al layer superiore TLS.
11. 11. Trama di segnale (TLS frame) da mappare in una trama del tipo RPR per il trasporto di informazioni da una prima locazione pluri-cliente (A) di partenza ad una seconda locazione (D) pluricliente di destinazione in una rete RPR (RPRNTW) di trasporto dati, la trama (TLS ffame) comprendendo una parte di contenuto informativo (payload) ed essendo caratterizzata dal comprendere una parte di intestazione (TLS Header) comprendente informazioni relative al canale assegnato per trasportare la trama RPR da un'interfaccia di ingresso (X) del nodo di partenza (A) ad un'interfaccia di uscita (Y) del nodo di destinazione (D).
12. 12. Trama di segnale (TLS frame) secondo la rivendicazione 11, caratterizzata dal fatto che detta parte di intestazione (TLS Header) comprende inoltre bit (HEC) riservati al controllo delle informazioni relative alTintestazione stessa (TLS Header).
13. 13. Trama di segnale del tipo RPR (RPR ffame) per il trasporto di informazioni da una prima locazione pluri-cliente (A) di partenza ad una seconda locazione (D) pluricliente di destinazione in una rete RPR (RPRNTW) di trasporto dati, la trama RPR comprendendo un'intestazione (RPR header) ed una parte successiva ad essa associata, caratterizzata dal fatto che nella parte successiva viene mappata una trama di segnale di livello superiore (TLS frame) secondo una qualsiasi delle rivendicazioni 11 o 12.
14. 14. Programma per elaboratore comprendente mezzi di codifica atti ad eseguire tutte le fasi delle rivendicazioni 1 -5 quando detto programma viene fatto girare su un elaboratore.
15. 15. Mezzo leggibile tramite elaboratore avente un programma registrato su di esso, detto mezzo leggibile tramite elaboratore comprendendo mezzi di codifica atti ad eseguire tutte le fasi delle rivendicazioni 1-5 quando detto programma viene fatto girare su un elaboratore,