ITTO20060149A1 - Tecnica per l'instradamento ottimizzato di flussi di dati su una dorsale ip in una rete di computer. - Google Patents

Description

DESCRIZIONE dell'invenzione industriale dal titolo: "Tecnica per l'instradamento ottimizzato di flussi di dati su una dorsale IP in una rete di computer"

STATO DELLA TECNICA DELL'INVENZIONE

Settore dell'invenzione

La presente invenzione riguarda reti di computer e, più in particolare, l'instradamento ottimizzato di flussi dati di applicazione su una rete dorsale di protocollo Internet (IP) in una rete di computer.

Informazioni di stato della tecnica

Una rete di computer è una raccolta geograficamente distribuita di nodi interconnessi da collegamenti di comunicazione e segmenti per trasportare dati fra nodi terminali, quali ad esempio personal computer e postazioni di lavoro autonome. Sono disponibili molti tipi di reti, i tipi andando da reti locali (LAN) a reti ad ampio raggio (WAN). LAN tipicamente collegano i nodi su collegamenti di comunicazione privati appositi posti nello stesso sito fisico generale, quale ad esempio un edificio o campus. WAN, d'altro canto, tipicamente collegano nodi geografreamente dispersi su collegamenti di comunicazione a lunga distanza, quali ad esempio normali linee telefoniche a onda portante, cammini di luce ottici, reti ottiche sincrone (SONET) o collegamenti a gerarchia digitale sincrona (SDH). Internet è un esempio di una WAN che collega reti disparate per tutto il mondo, fornendo una comunicazione globale fra nodi su varie reti. I nodi, tipicamente, comunicano sulla rete scambiando trame o pacchetti di dati discreti conformemente a protocolli predefiniti, quali ad esempio il protocollo di controllo trasmissioni/protocollo Internet (TCP/IP). In questo contesto, un protocollo consiste in un set di regole che definiscono il modo di interazione dei nodi fra di loro. Le reti di computer possono essere ulteriormente interconnesse da un nodo di rete intermedio, quale ad esempio un dispositivo di instradamento, al fine di estendere la "dimensione" effettiva di ciascuna rete.

Dal momento che la gestione di reti di computer interconnesse si può rivelare gravosa, gruppi più piccoli di reti di computer possono essere mantenuti come domini di instradamento o sistemi autonomi. Le reti all'interno di un sistema autonomo (AS) sono tipicamente accoppiate fra loro mediante convenzionali dispositivi di instradamento "intradominio" configurati ad eseguire protocolli di instradamento intradominio, e generalmente sottoposti ad un'autorità comune. Al fine di migliorare la graduabilità di instradamento, un provider di servizi (ad esempio un provider di servizi Internet - ISP) può suddividere un AS in più "aree" o "livelli". Può essere tuttavia auspicabile aumentare il numero di nodi atti a scambiare dati; in questo caso, dispositivi di instradamento intradominio che eseguono protocolli di instradamento intradominio vengono usati per collegare fra loro nodi dei vari AS. Inoltre, può essere auspicabile collegare fra loro vari AS fatti funzionare in diversi domini amministrativi. Per come usato nel presente ambito, un'area o livello, o più in particolare un AS, è indicato in generale come "dominio".

Esempi di un protocollo di instradamento intradominio, o un protocollo di porta interna (IGP), sono il protocollo di instradamento Apri prima il percorso più breve (OSPF) ed il protocollo di instradamento Sistema intermedio - sistema intermedio (IS-IS). I protocolli PSF e IS-IS si basano su tecnologia di stato del collegamento, e pertanto sono normalmente indicati come protocolli di instradamento di stato del collegamento. Protocolli di stato del collegamento definiscono la maniera in cui informazioni di instradamento ed informazioni di topologia di rete vengono scambiate ed elaborate in un dominio. Queste informazioni sono generalmente indirizzate ad uno stato locale del dispositivo di instradamento intradominio (ad esempio le interfaccia utilizzabili del dispositivo di instradamento nonché suoi vicini o adiacenze raggiungibili). Il protocollo OSPF è descritto in RFC 2328, dal titolo OSPF Version 2, datato Aprile 1998 e il protocollo IS-IS usato nel contesto IP è descritto in RFC 1195, dal titolo Use of OSI IS-IS for routing in TCP/lP and Dual Environments, datato Dicembre 1990, entrambi i quali sono qui incorporati a mo' di riferimento.

Un nodo di rete intermedio spesso memorizza le sue informazioni di instradamento in una tabella di instradamento mantenuta e gestita da una base di informazioni di instradamento (RIB). La tabella di instradamento è una struttura dati esaminabile in cui indirizzi di rete sono mappati alle associate informazioni di instradamento. Tuttavia, i tecnici del ramo si renderanno conto che la tabella di instradamento non deve essere necessariamente organizzata come tabella e, in via alternativa, può essere un altro tipo di struttura dati esaminabile. Sebbene la tabella di instradamento del nodo di rete intermedio possa essere configurata con un predeterminato set di informazioni di instradamento, il nodo può anche acquisire dinamicamente ("apprendere") informazioni di instradamento di rete allorché invia e riceve pacchetti dati. Quando un pacchetto viene ricevuto in corrispondenza del nodo di rete intermedio, l'indirizzo di destinazione del pacchetto può essere usato per identificare un'immissione nella tabella di instradamento contenente informazioni di instradamento associate al pacchetto ricevuto. Fra l'altro, le informazioni di instradamento del pacchetto indicano l'indirizzo di salto successivo del pacchetto.

Al fine di garantire che la sua tabella di instradamento contenga informazioni di instradamento aggiornate, il nodo di rete intermedio può cooperare con altri nodi intermedi al fine di disseminare informazioni di instradamento rappresentative della corrente topologia di rete. Per esempio, si supponga che il nodo di rete intermedio rilevi che uno dei suoi nodi vicinali (ovvero nodi di rete adiacente) risultino indisponibili, ad esempio causa un'interruzione di collegamento o l'uscita dalla linea del nodo vicinale, ecc.. In questa situazione, il nodo di rete intermedio può aggiornare le informazioni di instradamento memorizzate nella sua tabella di instradamento al fine di garantire che pacchetti dati non vengano instradati al nodo di rete indisponibile. Inoltre, il nodo intermedio può anche comunicare la variazione di topologia di rete agli altri nodi di rete intermedi in maniera tale che anch'essi possano aggiornare le loro tabelle di instradamento locali e by-passare il nodo indisponibile. In questa maniera, ciascuno dei nodi di rete intermedi diventa "consapevole" della variazione di topologia.

Tipicamente, informazioni di instradamento vengono disseminate fra i nodi di rete intermedi conformemente ad un predeterminato protocollo di comunicazione di rete, quale ad esempio un protocollo di stato del collegamento (ad esempio IS-IS oppure OSPF). Convenzionali protocolli di stato del collegamento utilizzano pacchetti di stato del collegamento o avviso (ovvero avvisi IGP) per scambiare informazioni di instradamento fra nodi di rete intermedi interconnesi (nodi IGP). Per come usato nel presente ambito, un avviso IGP descrive in generale qualsiasi messaggio usato da un protocollo di instradamento IGP per comunicare informazioni di instradamento fra nodi IGP interconnessi, ovvero dispositivi di instradamento e commutatori. Operativamente, un primo nodo IGP può generare un avviso IGP e "spargere" (ovvero trasmettere) il pacchetto su ciascuna delle sue interfaccia di rete accoppiate ad altri nodi IGP. Successivamente, un secondo nodo IGP può ricevere l'avviso IGP sparso ed aggiornare la propria tabella di instradamento sulla base di informazioni di instradamento contenute nell'avviso IGP ricevuto. Quindi, il secondo nodo IGP può spargere l'avviso IGP ricevuto su ciascuna delle sue interfaccia di rete, con l'eccezione dell'interfaccia in cui è stato ricevuto l'avviso IGP. Questo processo di spargimento può essere ripetuto fino a che ciascun nodo IGP interconnesso non ha ricevuto l'avviso IGP ed aggiornato al propria tabella di instradamento locale.

In pratica, ciascun nodo IGP tipicamente genera e dissemina un avviso IGP le cui informazioni di instradamento includono una lista dei nodi di rete vicinali del nodo intermedio ed uno o più valori di "costo" associati a ciascun vicino. Per come usato nel presente ambito, un valore di costo associato ad un nodo vicinale è una misura arbitraria (una metrica del collegamento) usata per determinare la relativa facilità/difficoltà di comunicare con tale nodo. Per esempio, il valore di costo può essere misurato in termini di numero di salti necessari a raggiungere il nodo vicinale, tempo medio perché un pacchetto raggiunga il nodo vicinale, quantità di traffico di rete o larghezza di banda disponibile su un collegamento di comunicazione accoppiato al nodo vicinale, ecc. . Per la precisione, come evidente ai tecnici del ramo, estensioni di ingegneria del traffico (TE) ad avvisi IGP possono essere usate per trasportare varia metrica del collegamento, quale ad esempio utilizzo del collegamento, ecc. Esempi di estensioni TE per IGP possono essere reperiti in RFC 3784 dal titolo Intermediate-System-to-Intermediate-System (IS-IS) Extensions for Traffic Engineering (TE) datato Giugno 2004, e RFC 3630, dal titolo Traffic Engineering (TE) Extensions to OSPF Version 2 datato Settembre 2003, i contenuti di ambo i quali sono qui incorporati a mo' di riferimento nella loro interezza.

Come segnalato, avvisi IGP vengono solitamente sparsi fino a che ciascun nodo IGP di rete intermedio non ha ricevuto un avviso IGP da ciascuno degli altri nodi intermedi interconnessi. Quindi, ciascuno dei nodi IGP (ad esempio in un protocollo di stato del collegamento) può costruire la stessa "visione" della topologia di rete aggregando le liste ricevute di nodi vicinali e valori di costo. A tal fine, ciascun nodo IGP può immettere queste informazioni di instradamento ricevute ad un calcolo di "percorso più breve per primo" (SPF) che determina i cammini di rete più economici che accoppiano il nodo intermedio con ciascuno degli altri nodi di rete, ovvero calcolando in tal modo un "albero di percorso più breve" (SPT), come noto ai tecnici del ramo. Per esempio, l'algoritmo Dijkstra è una tecnica convenzionale per eseguire un tale calcolo SPF, come descritto più dettagliatamente nella sezione 12.2.4 del manuale Interconnections Second Edition, Radia Perlman, pubblicato nel Settembre 1999, qui incorporato a mo ' di riferimento come se esposto integralmente nel presente ambito. Ciascun nodo IGP aggiorna le informazioni di instradamento memorizzate nella sua tabella di instradamento locale sulla base dei risultati del suo calcolo di SPF. Più specificamente, il RIB aggiorna la tabella di instradamento in modo da correlare nodi di destinazione con le interfaccia di salto successivo associate ai cammini di costo minimo per raggiungere tali nodi, quali determinati mediante il calcolo SPF.

I pacchetti dati trasferiti fra i nodi di rete possono includere celle dati di dimensione fissa e/o trame dati di dimensione variabile. Ciascun pacchetto dati comprende tipicamente dati di "carico utile" incapsulati da almeno un'intestazione di rete formattata in conformità ad un protocollo di comunicazione di rete. Le intestazioni di rete includono informazioni che consentono ai nodi Client e nodi intermedi di instradare il pacchetto efficacemente attraverso la rete di computer. Spesso, intestazioni di rete del pacchetto includono almeno un'intestazione di collegamento dati (strato 2) ed un'intestazione di lavoro Internet (strato 3), quale definite dal modello di riferimento di interconnessione fra sistemi aperti (OSI). Il modello di riferimento OSI è generalmente descritto più dettagliatamente nella sezione 1.1 del manuale dal titolo Interconnections Second Edition, da Radia Perlman, pubblicato nel Settembre 1999, qui incorporato a mo' di riferimento come se esposto integralmente nel presente ambito.

Operativamente, un nodo Client può inviare un pacchetto dati ad un'interfaccia di rete di un nodo di rete intermedio. Successivamente, il nodo di rete intermedio riceve il pacchetto ed inoltra il pacchetto alla sua destinazione successiva. Per esempio, il nodo di rete intermedio può eseguire una funzione di commutazione di strato 2 che semplicemente reindirizza il pacchetto da un'interfaccia di rete ad un'altra sulla base dei contenuti dell'intestazione di collegamento dati del pacchetto. In via alternativa, il nodo di rete intermedio può eseguire una funzione di instradamento di strato 3, o decisione di inoltro, che seleziona l'interfaccia di rete più appropriata per inoltrare il pacchetto sulla base dei contenuti dell'intestazione di lavoro Internet del pacchetto.

I pacchetti dati vengono usati per trasportare molte forme di informazioni su reti e sottoreti. Per esempio, informazioni video possono essere trasmesse conformemente a standard Video a richiesta (VoD) noti ai tecnici del ramo. VoD si riferisce ad un gruppo di tecnologie usate per trasmettere informazioni video su reti di dati da un nodo sorgente (ad esempio un server di applicazione VoD) ad un nodo di destinazione (ad esempio un Client di applicazione VoD). I nodi sorgente e di destinazione impiegano agenti vocali che convertono informazioni video dalla sua forma tradizionale in una forma atta alla trasmissione di pacchetti. In altri termini, l'agente video nel nodo sorgente codifica, comprime ed incapsula le informazioni video in una pluralità di pacchetti dati, e l'agente vocale del nodo di destinazione esegue funzioni complementari per deincapsulare, decomprimere e decodificare i pacchetti VoD. Per esempio, un server di contenuto VoD può fornire flussi dati video ad una o più unità utente. Inoltre, informazioni musicali possono essere trasmesse in conformità a standard noti ai tecnici del ramo in maniera simile a VoD. Esempi di agenti musicali possono includere applicazioni musicali (ad esempio il programma musicale Apple<®>Corporation's iTunes<®>) che girano su personal computer (PC), dispositivi di rete che forniscono servizi musicali (ad esempio juke-box Internet), ecc.. Per la precisione, l'uso di VoD e servizi musicali sono esempi di applicazioni (ad esempio in corrispondenza di uno strato di applicazione) che possono essere fatte funzionare da un nodo all'interno della rete. I tecnici del ramo comprenderanno che anche altre applicazioni possono essere fatte funzionare in corrispondenza di nodi di rete.

Un nodo sorgente (mittente) può essere configurato a trasferire un flusso unidirezionale di pacchetti dati, o "flusso dati" ad un nodo di destinazione (destinatario) in una rete dati. Il flusso dati può comprendere, per esempio, dati o informazioni video/musicali. Il flusso dati è unidirezionale nel senso che dati viaggiano in un senso solo dal mittente al destinatario. La successione logica di nodi di rete intermedi che trasmettono e ricevono pacchetti dati dal mittente al destinatario definisce il percorso dati del flusso dati. Un primo nodo più vicino al destinatario nel percorso dati del flusso dati rispetto ad un secondo nodo nel flusso è detto "a valle" rispetto al secondo nodo. Parimenti, un primo nodo più vicino al mittente nel percorso dati del flusso dati rispetto ad un secondo nodo nel flusso è detto "a monte" rispetto al secondo nodo.

Generalmente, in configurazioni di rete attuali, più server di contenuti di applicazione (ad esempio VoD, musica, ecc.) possono essere dispersi in differenti parti della rete al fine di garantire la ridondanza dei dati e provvedere al bilanciamento/condivisione di carico rispetto a richieste da Client dell'applicazione. Per la precisione, comunque, quando si utilizza un convenzionale instradamento IP all'interno della rete (ad esempio una rete dorsale IP), non vi è comunicazione fra lo strato di instradamento e lo strato di applicazione al fine di provvedere ad un efficace bilanciamento di carico. Spesso ciò crea un'inconsistenza negli algoritmi usati dallo strato di applicazione per tentare di bilanciare in carico le richieste Client ai più server di applicazione.

Per esempio, un Client VoD può richiedere un flusso dati video da un server VoD, selezionato dall'applicazione VoD del Client. Tuttavia, l'applicazione VoD del Client non è consapevole delle risorse di rete utilizzate dal flusso dati dal server selezionato (ad esempio i collegamenti/nodi che il flusso video attraverserebbe dal server al Client). Per questa ragione, qualsiasi tentativo di bilanciare in carico richieste Client dallo strato di applicazione è inefficace senza la conoscenza delle risorse di rete e del loro stato corrente, in particolare quando si utilizza una rete dorsale IP. Inoltre, dal momento che lo strato di instradamento non è consapevole delle richieste di applicazione o dello stato dei server di applicazione, qualsiasi tentativo di bilanciare in carico richieste Client da parte dello strato di instradamento risulta anch'esso inefficace. Permane pertanto l'esigenza di una tecnica efficace che ottimizzi 1 'instradamento di flussi dati di applicazione su una rete dorsale IP sulla base sia di informazioni sullo strato di applicazione che di informazioni sullo strato di instradamento.

SOMMARIO DELL'INVENZIONE

La presente invenzione è mirata ad una tecnica per ottimizzare l'instradamento di flussi dati di applicazione su una rete dorsale di protocollo Internet (IP) in una rete di computer. Conformemente alla tecnica innovativa, un dispositivo di instradamento Client apprende stati di server (ad esempio numeri di richieste pendenti, ecc.) di una pluralità di server di applicazione ed inoltre determina la metrica di collegamenti intermedi fra i server di applicazione ed il dispositivo di instradamento Client (metrica dei collegamenti intermedi), ad esempio, in particolare, metrica dei collegamenti in una direzione dai server di applicazione al dispositivo di instradamento Client. All'atto della ricezione di una richiesta di applicazione da un Client dell'applicazione ("richiesta Client"), il dispositivo di instradamento Client determina a quali dei server di applicazione la richiesta Client vada inviata sulla base degli stati di server e della metrica dei collegamenti intermedi, e invia di conseguenza la richiesta Client.

Nella forma di realizzazione illustrativa descritta nel presente ambito, il dispositivo di instradamento Client apprende gli stati di server dei server di applicazione e la metrica dei collegamenti intermedi mediante messaggi di protocollo di porta interna (IGP) propagati ("annunciati") all'interno della rete (ad esempio un dominio), ad esempio inizializzati in corrispondenza di uno o più dispositivi di instradamento server collegati ai server di applicazione. I messaggi IGP possono essere, a titolo illustrativo, realizzati come pacchetti di stato del collegamento Sistema intermedio - sistema intermedio (IS-IS) ("avvisi IGP"). Per la precisione, gli avvisi IGP includono campi di lunghezza variabile, o formati codificati tipo/lunghezza/valore (TLV) usati per trasportare le informazioni di stato di server e metrica dei collegamenti.

In conformità ad un aspetto della presente invenzione, i dispositivo di instradamento server sono a conoscenza di un'identificazione (ID) di ciascun server di applicazione collegato (ID del server), nonché dello stato corrente di ciascun server (ad esempio numero di connessioni attive, numero di richieste pendenti, carico di CPU/memoria corrente, larghezza di banda utilizzata corrente, ecc.). I dispositivi di instradamento server annunciano l 'ID del serve e gli stati di server a dispositivi di instradamento del dominio, come ad esempio in un nuovo TLV di server di applicazione (APPL_SERVER) di un avviso IGP. Ciascun TLV APPL_SERVER può corrispondere all'ID di un singolo server, e ciascun TLV può avere uno o più sotto-TLV usati per trasportare le informazioni di stato di server del corrispondente server di applicazione.

In conformità ad un altro aspetto della presente invenzione, il dispositivo di instradamento Client riceve gli avvisi IGP e calcola, a titolo illustrativo, un SPT inverso da sé a ciascuno dei server di applicazione, ad esempio usando metrica dei collegamenti nella direzione del flusso dati da inviare dal server di applicazione al Client dell'applicazione che esegue la richiesta. Per la precisione, i SPT inversi sono calcolati sulla base di metrica dei collegamenti (ad esempio utilizzo del collegamento, ritardo del collegamento, tasso di errore, ecc.) ottenuta dagli avvisi IGP inviati dal dispositivo di instradamento server ed eventuali dispositivi di instradamento intermedi nella rete, ad esempio usando le estensioni di ingegneria del traffico (TE) IGP. Il dispositivo di instradamento Client mantiene un corrente SPT inverso sulla base di variazioni/aggiornamenti nella rete, ad esempio comprese variazioni dell'associata metrica dei collegamenti.

In conformità ad un ulteriore aspetto della presente invenzione, il dispositivo di instradamento Client riceve ("intercetta") una richiesta Client, ad esempio determinando che è presente una forma/tipo di pacchetto di richiesta, o che un ID di server è la destinazione della richiesta. In via alternativa, il dispositivo di instradamento Client può fungere da server proxy di applicazione per il Client dell'applicazione, nel qual caso il Client indirizza la richiesta al dispositivo di instradamento Client, come evidente ai tecnici del ramo. All'atto della ricezione della richiesta Client, il dispositivo di instradamento Client determina a quale server di applicazione vada inviata la richiesta sulla base degli stati di server, ad esempio carico corrente del server, e sulla base della metrica del collegamento, quale ad esempio dai SPT inversi. Il dispositivo di instradamento Client può quindi modificare la richiesta Client in modo da garantire che essa venga inviata al corrispondente server di applicazione (ad esempio cambiare l'indirizzo di destinazione), o, in via alternativa, può replicare al Client dell'applicazione con il corrispondente ID di server (ovvero in modo tale che il Client dell'applicazione possa rinviare la richiesta al corrispondente server di applicazione).

Vantaggiosamente, la tecnica innovativa ottimizza l'instradamento di flussi dati di applicazione su una rete dorsale IP in una rete di computer. Determinando dove inviare richieste Client sulla base di stati di server e metrica dei collegamenti intermedi (ad esempio dal SPT inverso), la tecnica innovativa consente l'invio di richieste da Client ad un server di applicazione ottimale, dunque bilanciando in carico le richieste. In particolare, le richieste possono essere bilanciate in carico senza conoscenza dell'instradamento e dell'utilizzo delle risorse in corrispondenza dello strato di applicazione, ovvero lo strato di rete ha informazioni sufficienti per ottimizzare i flussi dati di applicazione. Inoltre, la natura dinamica della tecnica innovativa allevia la necessità di una gravosa configurazione manuale.

BREVE DESCRIZIONE DEI DISEGNI

I precedenti ed altri vantaggi dell'invenzione possono essere meglio compresi facendo riferimento alla descrizione che segue in combinazione con i disegni allegati, in cui numeri di riferimento uguali indicano elementi identici o simili dal punto di vista funzionale, in cui:

La Figura 1 è uno schema a blocchi di una rete di computer esemplificativa che può essere vantaggiosamente usata con la presente invenzione;

La Figura 2 è uno schema a blocchi di un dispositivo di instradamento esemplificativo che può essere vantaggiosamente usato con la presente invenzione;

La Figura 3 è uno schema a blocchi di un avviso IGP esemplificativo che può essere sparso dai dispositivi di instradamento;

La Figura 4 è uno schema a blocchi di porzioni di una richiesta di applicazione Client che può essere vantaggiosamente usata con la presente invenzione;

La Figura 5 è uno schema a blocchi che illustra il formato di campo di lunghezza variabile che può essere vantaggiosamente usato con la presente invenzione;

La Figura 6 è uno schema a blocchi di un'esemplificativa tabella di server di applicazione che può essere vantaggiosamente usata con la presente invenzione;

La Figura 7 è uno schema a blocchi della rete di computer nella Figura 1, che mostra un albero di percorso più breve (SPT) inverso calcolato in conformità alla presente invenzione; e

La Figura 8 è un diagramma di flusso che illustra una procedura per ottimizzare 1'instradamento di flussi dati di applicazione su una rete dorsale IP in conformità alla presente invenzione.

DESCRIZIONE DETTAGLIATA DI UNA FORMA DI REALIZZAZIONE ILLUSTRATIVA

La figura 1 è uno schema a blocchi di una rete di computer esemplificativa 100 che può essere vantaggiosamente usata con la presente invenzione. La rete 100 comprende una pluralità di nodi di rete interconnessi, quali un Client di applicazione e due o più server di applicazione (ad esempio server di applicazione 1 e 2). A titolo illustrativo, il Client di applicazione può essere interconnesso ad un dispositivo di instradamento Client, e i server di applicazione possono essere interconnessi ad un corrispondente dispositivo di instradamento (ad esempio ai dispositivi di instradamento rispettivamente 1 e 2). Il dispositivo di instradamento Client e i dispositivi di instradamento server possono essere interconnessi mediante una rete intermedia di uno o più nodi intermedi (ad esempio, dispositivi di instradamento intermedi A e B), quali ad esempio, collegamenti di rete ad ampio raggio (WAN) (o collegamenti di rete locale, "LAN", collegamenti da punto a punto, LAN senza fili ecc.), per formare la rete 100. I nodi di rete interconnessi possono scambiarsi pacchetti di dati secondo insiemi predefiniti di protocolli di comunicazione di rete, quale ad esempio il Transmission Control Protocol/lnternet Protocol (TCP/lP). I tecnici del ramo comprenderanno che nella rete di computer 100 si può utilizzare qualsiasi numero di nodi, collegamenti ecc. che possono essere connessi in una varietà di modi, e che la vista mostrata nel presente documento è per semplicità. Ad esempio, il dispositivo di instradamento Client e i dispositivi di instradamento server possono essere interconnessi rispettivamente a più di un client o server di applicazione.

La figura 2 è uno schema a blocchi di un nodo esemplificativo 200, che è a titolo illustrativo un dispositivo di instradamento che può essere usato vantaggiosamente con la presente invenzione, ad esempio un dispositivo di instradamento client o di server. Il nodo comprende una pluralità di interfacce di rete 210, un processore 220, e una memoria 240 interconnessi mediante un bus di sistema 250. Le interfacce di rete 210 contengono la circuiteria meccanica, elettrica e di segnalazione per comunicare dati su collegamenti fisici accoppiati alla rete 100. Le interfacce di rete possono essere configurate per trasmettere e/o ricevere dati usando una varietà di protocolli di comunicazione diversi, ivi inclusi, tra gli altri, TCP/IP, UDP, ATM, reti ottiche sincrone (SONET), protocolli senza fili, Frame Relay, Ethernet, Fiber Distributed Data Interface (FDDI) ecc.

La memoria 240 comprende una pluralità di posizioni di memorizzazione che sono utilizzabili da parte del processore 220 e delle interfacce di rete 210 per memorizzare programmi software e strutture di dati associati alla presente invenzione. Il processore 220 può comprendere elementi necessari o logica atta ad eseguire i programmi software e a manipolare le strutture di dati, quali la tabella di instradamento 246, database di ingegnerizzazione del traffico (TE) 244, tabella di albero di percorso più breve inverso (SPT) 249, e tabella di server di applicazione 600. Un sistema operativo di dispositivo di instradamento 242 (ad esempio Internetworking Operating System, o IOS™, di Cisco Systems, Inc.), porzioni del quale sono tipicamente residenti nella memoria 240 ed eseguito dal processore, organizza in modo funzionale il dispositivo di instradamento, tra le altre cose, richiedendo operazioni di rete in supporto di processi software e/o servizi che si eseguono sul dispositivo di instradamento. Tali processi e/o servizi software possono comprendere servizi di instradamento 247, base di informazioni di instradamento (RIB) 245, servizi TE 243, e servizi di interfaccia di applicazione 248. Risulterà chiaro ai tecnici del ramo che si possono utilizzare altri mezzi di processore e memoria, ivi inclusi vari supporti leggibili al computer, per memorizzare ed eseguire istruzioni di programma pertinenti alla tecnica inventiva descritta nel presente documento.

Servizi di instradamento 247 contengono istruzioni eseguibili al computer eseguite dal processore 220 per svolgere funzioni fornite da uno o più protocolli di instradamento, quali IGP (ad esempio OSPF e IS-IS), BGP ecc. Queste funzioni possono essere configurate per gestire un database di informazioni di trasferimento in avanti (non mostrato) contenente, ad esempio, dati usati per compiere decisioni di trasferimento in avanti. I servizi di instradamento 247 possono anche eseguire funzioni correlate a protocolli di instradamento virtuali, quale il mantenimento di istanze VRF (non mostrato) come comprenderanno i tecnici del ramo.

Variazioni nella topologia della rete possono essere comunicate tra dispositivi di instradamento 200 usando un protocollo di stati di collegamento, quali i protocolli convenzionali IS-IS e OSPF. Si supponga, ad esempio, che un collegamento di comunicazione non funzioni all'interno di un AS oppure che un valore di costo associato ad un nodo di rete cambi. Una volta che il cambiamento nello stato della rete viene rilevato da uno dei dispositivi di instradamento, tale dispositivo di instradamento può spargere un avviso IGP comunicando il cambiamento agli altri dispositivi di instradamento nell'AS. In questo modo, ciascuno dei dispositivi di instradamento "converge" infine ad una vista identica della topologia di rete.

La figura 3 illustra un avviso IGP esemplificativo 300 che può essere sparso dai dispositivi di instradamento 200, (ad esempio un pacchetto di stato di collegamento IS-IS). Il pacchetto include un campo discriminatore di protocollo di instradamento intradominio 302 che memorizza un valore identificativo del protocollo specifico del messaggio (ad esempio IS-IS), e un campo indicatore di lunghezza 304 che memorizza un valore indicativo della lunghezza dell'intestazione standard per l'avviso. Inoltre, si può utilizzare un campo di estensione di versione/protocollo ID (ext) 306 per memorizzare ulteriormente un valore definente la particolare versione del protocollo. Il campo riservato 308 e campi "R" sono riservati per l'uso futuro con il protocollo, così come i campi ECO e User ECO 314 e 316, che vengono tutti ignorati dal dispositivo di instradamento ricevente fino a quando non vengono indirizzati per la codifica in versioni future del protocollo.

Un campo di tipo 310 (e campo di versione corrispondente 312) memorizza un valore che indica il tipo (e la versione) dell'avviso IGP 300 che viene trasmesso, che può definire l'esistenza di altri campi tipo-specifici 322 all'interno dell'avviso. Ad esempio, il tipo di avviso può essere un pacchetto "Hello", o un pacchetto "LSP", come sarà meglio compreso dai tecnici del ramo. Il campo di lunghezza PDU 318 memorizza un valore indicante la lunghezza dell'intera PDU (Protocol Data Unit, o avviso IGP 300), ivi inclusi l'intestazione, campi tipo-specifici, e campi di dati. Un campo sorgente ID 320 memorizza un valore che identifica il dispositivo di instradamento che ha generato e trasmesso originariamente l'avviso IGP 300.

Gli altri campi tipo-specifici 322 possono includere qualsiasi numero di campi come definiti dal protocollo, quali campi di somma di controllo, campi di indirizzo di area massima ecc., come comprenderanno i tecnici del ramo. Ad esempio, un campo di numero di sequenza (non mostrato) può memorizzare un numero di sequenza che indica la versione relativa dell'avviso IGP. Tipicamente, il numero di sequenza memorizzato nel campo è incrementato, ad esempio di uno, per ogni nuova versione dell'avviso IGP. L'avviso IGP 300 è pertanto considerato "inefficace" (invalido) se il suo numero di sequenza è inferiore al numero di sequenza memorizzato in una versione precedentemente ricevuta dell'avviso IGP, ovvero generata dallo stesso noto di emissione di avviso. Di conseguenza, i dispositivi di instradamento 200 possono essere configurati per memorizzare e trasferire solo la versione più recente di un avviso IGP, e ad esempio la versione avente il numero di sequenza maggiore. Un restante campo di durata (non mostrato) può anch'esso essere utilizzato per memorizzare un valore che può essere usato per determinare se l'avviso IGP 300 è valido. Il restante valore di durata è tipicamente inizializzato ad un valore intero diverso da zero, spesso in unità di secondi. Il restante valore di durata può essere decrementato, ad esempio di uno per ogni secondo, fino a che il restante valore di durata non raggiunge lo zero, indicando in tal modo che l'avviso IGP è diventato invalido. Ovvero, ogni dispositivo di instradamento 200 che memorizza o sparge l'avviso IGP 300 invecchia continuamente il pacchetto fino a che il valore di durata rimanente non corrisponde a zero. I tecnici del ramo apprezzeranno che si possono usare in alternativa altri meccanismi di invecchiamento, quali l'incremento del valore di durata rimanente dell'avviso IGP a partire da un valore iniziale, ad esempio uguale a zero, fino a quando il valore di durata rimanente non raggiunge un limite superiore noto .

La sezione di dati 330 include uno o più campi a lunghezza variabile 500 che hanno ciascuno un tipo (o codice), una lunghezza, e un valore (TLV) specifico come descritto ulteriormente nel presente documento. Ad esempio, per annunciare la topologia di rete, si possono usare una o più coppie di campi di nodo vicino (non mostrati) e campi di costo (non mostrati). I campi di nodo vicino possono memorizzare un valore, quale un indirizzo, che indica un nodo di rete che è direttamente accessibile dal nodo intermedio memorizzato nel campo di sorgente ID 320. Il campo di costo può memorizzare un valore che è stato associato, ad esempio dal nodo di avviso, con il nodo di rete identificato nel nodo di campo vicino. Occorre notare che in altre forme di realizzazione, un singolo nodo vicino può essere associato ad una pluralità di valori di costo. Anche altre informazioni di instradamento possono essere incluse nei campi di lunghezza variabile 500 dell'avviso IGP 300, quali valori di somma di controllo, campi di riempimento, campi proprietari ecc., e campi di informazioni di server di applicazione, quale un nuovo campo APPL_SERVER (descritto oltre). Generalmente, gli avvisi IGP ricevuti sono memorizzati in un Link-State Database (LSDB) del dispositivo di instradamento 200 (non mostrato).

Facendo di nuovo riferimento alla figura 2, servizi TE 243 contiene istruzioni eseguibili dal computer per eseguire funzioni TE secondo la presente invenzione. Esempi di ingegnerizzazione del traffico sono descritti in RFC 3784, e RFC 3630 come incorporati sopra. Si può usare un database TE (TED) 244 per memorizzare informazioni TE fornite dai protocolli di instradamento, quale IGP (ad esempio in campi TE a lunghezza variabile estesi 500) secondo la presente invenzione, e a titolo illustrativo viene mantenuto e gestito da servizi TE 243.

Servizi di interfaccia di applicazione 249 contengono istruzioni eseguibili dal computer eseguite dal processore 220 per eseguire funzioni relative a una o più applicazioni secondo la presente invenzione, quali ad esempio Video on Demand (VoD), servizi musicali ecc., come comprenderanno i tecnici del ramo. In particolare, tali funzioni possono essere configurate per cooperare con servizi di instradamento 247 e/o servizi TE 243, come in conformità con la presente invenzione descritta in questo documento.

Nel funzionamento, un Client di applicazione richiede generalmente contenuto di applicazione (ad esempio video/musica/ecc.) da un server di applicazione attraverso una "richiesta Client". La figura 4 è uno schema a blocchi di porzioni di una richiesta Client 400 che può essere usata vantaggiosamente con la presente invenzione. La richiesta 400 contiene, tra le altre cose, un'intestazione comune 410, e campi di richiesta di applicazione e/o oggetto delle informazioni 420. L'intestazione comune 410 può comprendere inoltre un indirizzo sorgente 412 (ad esempio del Client di applicazione che invia la richiesta) e un indirizzo di destinazione 414 a cui viene inviata la richiesta (ad esempio un server di applicazione). Tipicamente, i servizi di applicazione sul Client di applicazione possono essere configurati con la posizione di un server di applicazione appropriato ad esempio attraverso configurazione manuale o apprendimento dinamico, come comprenderanno i tecnici del ramo. Di conseguenza, l'indirizzo di tale server di applicazione configurato può essere incluso nell'indirizzo di destinazione 414 della richiesta Client 400. I campi di richiesta di applicazione e/o l'oggetto delle informazioni 420 possono comprendere informazioni di richiesta specifiche per l'applicazione convenzionali, quali tipi di richiesta, codici, campi specifici, dati, informazioni ecc., come comprenderanno anche i tecnici del ramo.

La presente invenzione è diretta ad una tecnica per ottimizzare 1'instradamento di flussi dati di applicazione su una dorsale IP in una rete di computer. Secondo la nuova tecnica, un dispositivo di instradamento Client apprende stati di server (ad esempio numero di richieste pendenti ecc.) di una pluralità di server di applicazione e determina anche la metrica di collegamenti intermedi tra i server di applicazione e il dispositivo di instradamento Client (metrica di collegamento intermedio), ad esempio in particolare metrica di collegamento in una direzione dai server di applicazione al dispositivo di instradamento Client. Alla ricezione di una richiesta Client, il dispositivo di instradamento Client determina a quale dei server di applicazione deve essere inviata la richiesta Client in base agli stati di server e alla metrica di collegamento intermedio, e invia di conseguenza la richiesta Client.

Nella forma di realizzazione illustrativa descritta nel presente documento, il dispositivo di instradamento Client apprende gli stati di server dei server di applicazione e la metrica di collegamento intermedio per mezzo di messaggi IGP propagati ("annunciati") all'interno della rete (ad esempio un dominio), ad esempio iniziato in corrispondenza di uno o più dispositivi di instradamento server connessi ai server di applicazione descritti sotto. I messaggi IGP possono essere realizzati a titolo illustrativo come pacchetti di stato di collegamento IS-IS (avvisi IGP 300). In particolare, gli avvisi IGP includono campi a lunghezza variabile, o formati codificati TLV usati per convogliare gli stati di server e le informazioni di metrica di collegamento.

Il formato codificato TLV viene usato per identificare un tipo (T) di informazioni che vengono comunicate (convogliate), una lunghezza (L) di informazioni da convogliare, e un valore (V) delle informazioni convogliate effettive. Il parametro di lunghezza (L) contenuto nel campo di lunghezza è tipicamente specifico per 1'implementazione e può indicare la lunghezza dall'inizio del campo tipo dell'oggetto fino alla fine. Tuttavia, la lunghezza indica generalmente la lunghezza del campo valore (V) e non i campi tipo (T) o lunghezza (L).

La figura 5 è un diagramma a blocchi che illustra il formato di un campo a lunghezza variabile 500 che può essere vantaggiosamente usato con la presente invenzione. Il campo a lunghezza variabile 500 è rappresentato a titolo illustrativo come un TLV contenuto in un avviso IGP 300 e viene esteso per trasportare informazioni riguardanti server di applicazione. A tal fine, il "TLV di server di applicazione" 500 ( "APPL_SERVER") è organizzato per includere un campo di tipo 505 contenente un valore di tipo predeterminato del nuovo APPL_SERVER TLV. Il campo di lunghezza 510 è un valore a lunghezza variabile. Il formato codificato TLV può anche comprendere uno o più sotto-TLV non ordinati 550 trasportati all'interno del "carico utile" di TLV (ad esempio campo di valore 515), aventi ciascuno un campo di tipo 555, campo di lunghezza 560, e campo di valore 565. I campi del TLV 500 e degli uno o più sotto-TLV 550 sono usati in una varietà di modi, ivi inclusi quelli descritti nel presente documento, secondo la presente invenzione. In particolare, il campo a lunghezza variabile 500 può anche essere esteso per trasportare informazioni riguardanti metrica di collegamento dei collegamenti di rete (ad esempio utilizzo di collegamento, ritardo di collegamento, tasso di errore ecc.) usando estensioni TE convenzionali, come verrà compreso dai tecnici del ramo.

Secondo un aspetto della presente invenzione, i dispositivi di instradamento server sono a conoscenza di un'identificazione (ID) (ad esempio un indirizzo IP) di ciascun server di applicazione connesso (ID di server), nonché dello stato attuale di ciascun server. Stati esemplificativi di un server possono comprendere, ad esempio, numerose connessioni di applicazione attive, numerose richieste di applicazione pendenti, attuale CPU/carico di memoria, attuale larghezza di banda utilizzata ecc.. In particolare, informazioni o attributi di server possono anche includere un'indicazione di flussi dati di applicazione disponibili, ad esempio contenuto VoD/musicale disponibile presso il server, come verrà compreso dai tecnici del ramo. I dispositivi di instradamento server possono essere a conoscenza delle informazioni di server di applicazione in base a comunicazione locale con il server di applicazione, ad esempio scambi di messaggi specifici tra il dispositivo di instradamento e il server come verrà compreso dai tecnici del ramo, o, in alternativa, il dispositivo di instradamento può mantenere stati del server in base al monitoraggio di richieste in entrata e di flussi dati in uscita. A titolo illustrativo, la comunicazione locale può essere realizzata in modo simile ai campi di lunghezza variabile 500 all'interno di un protocollo di comunicazione locale specifico.

I dispositivi di instradamento server annunciano l'ID del server e gli stati del server a dispositivi di instradamento del dominio, ad esempio in un nuovo APPL_SERVER TLV 500 di un avviso IGP 300. L'APPL_SERVER TLV 500 viene sparso a ciascun dispositivo di instradamento della rete 100 (ovvero all'interno di un dominio), ad esempio conformemente allo spargimento a livello di rete IS-IS, (o ad esempio di tipo OSPF 10 (a livello di area) o tipo 11 (a livello di AS) LSA opachi, come verrà compreso). A titolo illustrativo, ciascun APPL_SERVER TLV 500 può corrispondere ad un'unica ID di server. L'ID di server (ad esempio per il server di applicazione 1) può essere contenuta all'interno di un campo di ID di server 520 specifico all'interno del campo di valore 515 del TLV 500, o può invece essere contenuta all'interno di un sotto-TLV separato 550. Inoltre, ciascun TLV 500 può avere uno più sotto-TLV 550 usati per convogliare le informazioni di stato di server del corrispondente server di applicazione. Ad esempio, numerosi collegamenti attivi di un particolare server possono essere contenuti all'interno di un primo sotto-TLV corrispondente al TLV 500 per il server, e un secondo sotto-TLV 550 può contenere numerose richieste pendenti ecc.. In questo modo, i dispositivi di instradamento server immettono conoscenza di informazioni di server di applicazione (ID e stati) in avvisi IGP trasmessi a dispositivi di instradamento (ad esempio) della rete.

Ciascun dispositivo di instradamento della rete (ad esempio dispositivi di instradamento intermedi e dispositivi di instradamento Client/server) riceve gli avvisi IGP 300 aventi il APPL_SERVER TLV 500, e mantiene di conseguenza una tabella di informazioni di server di applicazione. La figura 6 è uno schema a blocchi di una tabella di server di applicazione esemplificativa 600 che può essere usata vantaggiosamente con la presente invenzione. La tabella di server di applicazione 600 è a titolo illustrativo una struttura di dati memorizzata nella memoria 240 dei dispositivi di instradamento e include una o più registrazioni 650, comprendenti ciascuna una pluralità di campi per memorizzare un server di applicazione ID 605, e uno o più campi di informazioni di stato di server, quali collegamenti attivi 610, richieste pendenti 615, carico di CPU 620, carico di memoria 625, larghezza di banda utilizzata 630, e altri stati 635. La tabella di server di applicazione 600 viene mantenuta a titolo illustrativo e gestita da servizi di interfaccia di applicazione 248. Alla ricezione di un APPL_SERVER TLV 500, un dispositivo di instradamento memorizza la ID di server di applicazione corrispondente (ad esempio Server 1-N) nel campo 605, e memorizza inoltre qualsiasi dato aggiuntivo (ad esempio Dati 1-N) in rispettivi campi di informazioni di server 610-635. In particolare, i dispositivi di instradamento mantengono valori attuali per i dati aggiornando la tabella ogni volta che viene ricevuto un APPL_SERVER TLV 500 nuovo/aggiornato in un avviso IGP 300. Peraltro, una tabella separata può essere mantenuta per ciascuna applicazione specifica (ad esempio per VoD, musica ecc.).

In conformità ad un altro aspetto della presente invenzione, il dispositivo di instradamento Client riceve gli avvisi IGP e calcola, a titolo illustrativo, un SPT inverso da sé a ciascuno dei server di applicazione, ad esempio usando metrica dei collegamenti nella direzione del flusso dati da inviare dal server di applicazione al Client dell'applicazione che esegue la richiesta. Per la precisione, i SPT inversi sono calcolati sulla base di metrica dei collegamenti (ad esempio utilizzo del collegamento, ritardo del collegamento, tasso di errore ecc.) ottenuta dagli avvisi IGP inviati dal dispositivo di instradamento server ed eventuali dispositivi di instradamento intermedi nella rete, ad esempio usando estensioni di TE IGP o altri procedimenti per convogliare la metrica di collegamento. Peraltro, oltre alla metrica di collegamento menzionata nel presente documento, i tecnici del ramo comprenderanno che qualsiasi metrica/attributo statico o dinamico associato ai collegamenti (ad esempio che possa riflettere lo stato in tempo reale del collegamento) può essere utilizzato secondo la presente invenzione.

L'SPT inverso fornisce al dispositivo di instradamento Client un insieme di percorsi più brevi da ciascun server di applicazione verso il dispositivo di instradamento Client stesso che contemplano la metrica di collegamento verso il dispositivo di instradamento Client. E' importante notare che gli SPT inversi vengono usati in modo ottimale secondo la presente invenzione poiché un algoritmo di bilanciamento del carico implementato dal Client dovrebbe considerare la metrica di collegamento sul percorso dal server al Client, e non dal Client al server. La figura 7 è uno schema a blocchi della rete di computer in figura 1 che mostra un SPT inverso calcolato secondo la presente invenzione. A titolo illustrativo, il dispositivo di instradamento Client calcola l'SPT inverso con sé stesso come radice, e determina il percorso più breve dal server di applicazione, ad esempio il server di applicazione 1 (o il dispositivo di instradamento server, ad esempio il dispositivo di instradamento server 1) che può essere usato dal flusso di dati di applicazione richiesto. Un SPT inverso (o "rSPT") è generalmente noto nell'arte, e può essere calcolato in modo simile a quello di un SPT convenzionale. In un SPT inverso, tuttavia, il nodo di calcolo (ad esempio il dispositivo di instradamento Client) utilizza la metrica di collegamento nella direzione da altri dispositivi di instradamento nella rete verso sé. In altre parole, un SPT inverso definisce l'insieme di percorsi più brevi da qualsiasi altro dispositivo di instradamento nella rete (ad esempio i server di applicazione) fino al dispositivo di instradamento che esegue il calcolo (ad esempio il dispositivo di instradamento Client). In particolare, varie diramazioni ad altri dispositivi di instradamento intermedi (non mostrati) non selezionate come le più brevi (migliori) per raggiungere il nodo di Client sono mostrate a titolo illustrativo. Il dispositivo di instradamento Client mantiene corrente l'SPT inverso in base a variazioni/aggiornamenti nella rete, ivi incluse, ad esempio, variazioni nella associata metrica di collegamento. Gli SPT inversi vengono mantenuti attuali cosicché il dispositivo di instradamento Client sia in grado di selezionare il server di applicazione migliore (ad esempio ottimale) a cui inviare richieste Client secondo criteri predefiniti, quali, ad esempio, un utilizzo di collegamento configurato del flusso di dati richiesto ecc., descritto sotto.

In conformità ad un ulteriore aspetto della presente invenzione, il dispositivo di instradamento Client riceve ("intercetta") una richiesta Client, ad esempio determinando che è presente una forma/tipo di pacchetto di richiesta, o che un ID di server è la destinazione della richiesta. Ad esempio, il dispositivo di instradamento Client può esaminare il contenuto di pacchetti ricevuti dal Client di applicazione ed elaborare il contenuto in corrispondenza dello strato di dispositivo di instradamento/rete. In particolare, il dispositivo di instradamento Client cerca un formato, tipo di pacchetto, o contenuto specifico che corrisponde ad una richiesta Client 400, come verrà compreso dai tecnici del ramo. Inoltre, correlando l'indirizzo di destinazione dei pacchetti all'elenco di ID di server di applicazione (ad esempio nel campo 605 della tabella del server di applicazione), il dispositivo di instradamento di Client può determinare che il pacchetto è una richiesta Client 400. L'intercettazione di pacchetti di strati di applicazione è generalmente nota e compresa dai tecnici del ramo e qualsiasi tecnica di intercettazione di questo tipo può essere utilizzata conformemente alla presente invenzione per determinare che il pacchetto è una richiesta Client 400. In via alternativa, il dispositivo di instradamento Client può fungere da server proxy di applicazione per il Client dell'applicazione. In altre parole, il dispositivo di instradamento client può annunciarsi al clienti di applicazione come server di applicazione al quale possono essere inviate richieste generalmente destinate a server di applicazione effettivi (ad esempio server 1 e 2). In questo caso, il client di applicazione indirizza la richiesta al dispositivo di instradamento client, ovvero supponendo che il dispositivo di instradamento client sia il server di applicazione, come verrà compreso dai tecnici del ramo.

All'atto della ricezione della richiesta Client, il dispositivo di instradamento Client determina a quale server di applicazione vada inviata la richiesta sulla base degli stati di server, ad esempio carico corrente del server (numero di connessioni/richieste, CPU/carico di memoria ecc.), e sulla base della metrica del collegamento (ad esempio utilizzo di collegamento), quale ad esempio dagli SPT inversi. Gli stati del server per i server disponibili possono essere determinati consultando la tabella di server di applicazione 600. Applicando un algoritmo di bilanciamento di carico ai server di applicazione in base agli stati di server e anche includendo metrica di collegamento intermedio nell'algoritmo, ad esempio dagli SPT inversi, la presente invenzione consente un instradamento più ottimale delle richieste Client e quindi dei risultanti flussi dati di applicazione.

Varie tecniche di bilanciamento di carico che saranno comprese dai tecnici del ramo possono essere adattate per l'uso con la presente invenzione per prendere in considerazione stati di server e metrica di collegamento. Ad esempio, in base a criteri predefiniti delle richieste, ad esempio, un aumento proiettato nell'utilizzo del collegamento in base al flusso di dati richiesto, il dispositivo di instradamento Client può determinare che l'SPT inverso da determinati server di applicazione (ad esempio il server di applicazione 2) presenta un livello di congestione superiore, e può non essere in grado di ricevere traffico aggiuntivo, rispetto ad altri server di applicazione (ad esempio il server di applicazione 1). Tuttavia, il dispositivo di instradamento Client deve anche considerare se gli altri server di applicazione (ad esempio il server 1) siano sovraccarichi in altri stati di server, quali, ad esempio CPU e/o carico di memoria. Altri confronti e tecniche di bilanciamento di carico verranno compresi dai tecnici del ramo, e quelli qui menzionati sono esempi meramente rappresentativi.

Una volta che il dispositivo di instradamento Client (seleziona) il migliore server di applicazione, il dispositivo di instradamento Client tenta di assicurare che la richiesta Client venga trasmessa al server di applicazione selezionato. Ad esempio, il dispositivo di instradamento Client può determinare se la richiesta Client 400 sia già destinata (ad esempio nell'indirizzo di destinazione 414) al server di applicazione selezionato (ad esempio il server di applicazione 1), nel qual caso la richiesta 400 viene inviata dal dispositivo di instradamento Client. D'altro canto, se la richiesta Client 400 è destinata a un server di applicazione diverso (ad esempio il server di applicazione 2), allora il dispositivo di instradamento Client cerca di correggere la destinazione della richiesta.

Per correggere la destinazione della richiesta Client 400, il dispositivo di instradamento client può modificare la richiesta client per assicurare che vanga inviata al corrispondente server di applicazione (ad esempio variare l'indirizzo di destinazione 414). Ad esempio, il dispositivo di instradamento client può incapsulare la richiesta client in una nuova intestazione IP 410 al server di applicazione selezionato, e inviare la richiesta per conto del client (ad esempio con l'indirizzo di sorgente 412 che rimane come indirizzo di client di applicazione), ovvero "sostituzione di identità". In via alternativa, il dispositivo di instradamento client può replicare al client dell'applicazione con il corrispondente ID di server, ad esempio, attraverso un protocollo di comunicazione locale, ad esempio IGP (strato di instradamento), o, a titolo illustrativo, per mezzo di un protocollo applicazione-specifico (strato di applicazione) come verrà compreso dai tecnici del ramo. Se così configurato, in questo caso, il Client di applicazione può rinviare la richiesta 400 al corrispondente server di applicazione, ovvero con l'indirizzo di server di applicazione selezionato nel campo di indirizzo di destinazione 414.

La Figura 8 è un diagramma di flusso che illustra una procedura per ottimizzare l'instradamento di flussi dati di applicazione su una rete dorsale IP in conformità alla presente invenzione. La procedura 800 ha inizio nella fase 805, e continua fino alla fase 810, dove i dispositivi di instradamento di server (ad esempio i dispositivi di instradamento di server 1 e 2) mantengono ID di server e stati di server di server di applicazione connessi (ad esempio server di applicazione 1 e 2 rispettivamente), come descritto sopra. Nella fase 815, i dispositivi di instradamento di server diffondono le ID di server e gli stati di server nella rete, ad esempio usando APPL_SERVER TLV 500 in avvisi IGP 300. Dispositivi di instradamento intermedi (ad esempio dispositivi di instradamento intermedi A e B) propagano metrica di collegamento (ad esempio utilizzo di collegamento) dei collegamenti all'interno della rete, ad esempio anche usando avvisi IGP 300, ad esempio attraverso estensioni TE, come descritto sopra. Il dispositivo di instradamento Client riceve gli avvisi IGP 300 nella fase 825, apprendendo così le informazioni, e nella fase 830 memorizza le ID di server e gli stati di server nella tabella di server di applicazione 600. Nella fase 835, per determinare in modo illustrativo la metrica di collegamento intermedio, il dispositivo di instradamento client può allora calcolare gli SPT da sé a ciascun server di applicazione (in base alla metrica di collegamento verso sé, come descritto sopra), e memorizzano gli SPT inversi, ad esempio, in una tabella di SPT inverso 249. In particolare, il dispositivo di instradamento client può aggiornare la tabella 600 o gli SPT inversi calcolati in risposta a variazioni/aggiornamenti ricevuti nella rete.

Nella fase 840, il dispositivo di instradamento client riceve una richiesta client 400, ad esempio attraverso l'intercettazione della richiesta o agendo come proxy di server di applicazione, entrambi i casi come descritti sopra. In risposta, il dispositivo di instradamento Client determina a quale server di applicazione debba essere inviata la richiesta in base a stati di server e metrica di collegamento intermedio, ad esempio, degli SPT inversi, nella fase 845, anche in questo caso come descritto sopra. Se sussiste le necessità di modificare la destinazione del server di applicazione della richiesta (ovvero si potrebbe usare in server più ottimale) nella fase 850, il dispositivo di instradamento Client può modificare la destinazione di richiesta Client (ad esempio cambiando l'indirizzo di destinazione 414), o può invece replicare al Client di applicazione con la corrispondente destinazione di server di applicazione (ad esempio l'indirizzo e/o ID di server del server più ottimale). Il dispositivo di instradamento Client, nella fase 860, può poi inviare la richiesta Client al corrispondente server di applicazione. In particolare, in risposta all'informazione del Client di applicazione della destinazione di server di applicazione corrispondente, il dispositivo di instradamento Client può trasmettere una richiesta restituita dal Client di applicazione con la destinazione di server di applicazione corrispondente (ad esempio una richiesta "ri-ricevuta"). La procedura 800 termina nella fase 865.

Vantaggiosamente, la nuova tecnica ottimizza 1'instradamento di flussi dati di applicazione su una dorsale di rete IP in una rete di computer. Determinando dove inviare richieste Client in base a stati di server e metrica di collegamento intermedio (ad esempio dall'SPT inverso), la nuova tecnica consente di inviare richieste Client ad un server di applicazione ottimale, bilanciando così le richieste in relazione al carico. In particolare, le richieste possono essere bilanciate in relazione al carico senza instradamento e conoscenza di utilizzo delle risorse in corrispondenza dello strato di applicazione, ovvero, lo strato di rete ha informazioni sufficienti per ottimizzare i flussi dati di applicazione. Inoltre, la natura dinamica della nuova tecnica allevia la necessità di una configurazione manuale scomoda.

Sebbene sia stata mostrata e descritta una forma di realizzazione illustrativa che ottimizza l'instradamento di flussi dati di applicazione su una dorsale di rete IP in una rete di computer, occorre comprendere che si possono apportare vari altri adattamenti e modifiche entro lo spirito e la portata della presente invenzione. Ad esempio, l'invenzione è stata mostrata e descritta nel presente documento usando pacchetti di stato di collegamento IS-IS come avvisi IGP 300. Tuttavia, l'invenzione nel suo senso più ampio non è limitata in questi termini, e può, di fatto, essere utilizzata con altri avvisi IGP, quali OSPF LSA (ad esempio tipo 10 o LAS opachi 11) come verrà compreso dai tecnici del ramo. Peraltro, sebbene la descrizione di cui sopra descriva l'applicazione della tecnica in corrispondenza di un dispositivo di instradamento Client connesso al Client di applicazione, la tecnica può essere applicata in corrispondenza di altri nodi all'interno della rete, quale il Client di applicazione stesso, data un'opportuna configurazione come verrà compreso anche dai tecnici del ramo. Inoltre, sebbene l'invenzione sia stata mostrata e descritta usando SPT inversi per gestire le informazioni di metrica di collegamento intermedio, i tecnici del ramo comprenderanno che si possono usare altre tecniche per raccogliere/utilizzare metrica di collegamento intermedio secondo la presente invenzione.

La precedente descrizione è stata rivolta a forme di realizzazione specifiche di questa invenzione. Risulterà evidente, tuttavia, che si possono apportare altre variazioni e modifiche alle forme di realizzazione descritte, con il conseguimento di alcuni o di tutti i loro vantaggi. Ad esempio, è espressamente contemplato che gli insegnamenti di questa invenzione possano essere implementati come software, ivi incluso un supporto leggile dal computer avente istruzioni di programma che vengono eseguite su un computer, hardware, firmware, o una loro combinazione. Inoltre, si possono generare segnali elettromagnetici per trasportare istruzioni eseguibili al computer che implementano aspetti della presente invenzione su, ad esempio, un collegamento dati senza fili o una rete di dati, quale Internet. Di conseguenza, questa descrizione deve essere considerata solo a titolo esemplificativo senza altrimenti limitare la portata dell'invenzione. Pertanto, l'obiettivo delle rivendicazioni allegate è quello di coprire tutte le variazioni e modifiche che rientrano nello spirito e nella portata reali dell'invenzione.

Claims (1)

1. RIVENDICAZIONE 1. Un metodo per ottimizzare l'instradamento di flussi dati di applicazione su di una dorsale di protocollo Internet in una rete di computer, il metodo comprendendo: apprendimento di stati di server di una pluralità di server di applicazione; determinazione della metrica di collegamenti intermedi fra i server di applicazione e un dispositivo di instradamento Client (metrica dei collegamenti intermedi); ricezione di una richiesta di applicazione da una applicazione Client in corrispondenza del dispositivo di instradamento Client; e determinazione di quale sia il server fra la pluralità di server di applicazione a cui va inviata la richiesta del Client in base agli stati di server e alla metrica dei collegamenti intermedi.