IT201800010791A1

IT201800010791A1 - Misura di prestazioni in una rete di comunicazioni a commutazione di pacchetto

Info

Publication number: IT201800010791A1
Application number: IT102018000010791A
Authority: IT
Inventors: Mauro Cociglio; Giuseppe Fioccola
Original assignee: Telecom Italia Spa
Priority date: 2018-12-04
Filing date: 2018-12-04
Publication date: 2020-06-04
Also published as: EP3891916A1; US11784895B2; WO2020114971A1; CN113169832A; US20220029898A1; CN113169832B; EP3891916B1

Description

DESCRIZIONE

Della Domanda di Brevetto per Invenzione Industriale dal Titolo:

“Misura di prestazioni in una rete di comunicazioni a commutazione di pacchetto”

Settore tecnico

La presente invenzione riguarda il settore delle reti di comunicazioni. In particolare, la presente invenzione riguarda un metodo per eseguire una misura di prestazioni in una rete di comunicazioni a commutazione di pacchetto. Inoltre, la presente invenzione riguarda un rete di comunicazioni configurata per implementare tale metodo.

Stato della tecnica

In una rete di comunicazioni a commutazione di pacchetto, flussi di pacchetti sono trasmessi da nodi sorgente a nodi destinazione attraverso eventuali nodi intermedi. Esempi di reti a commutazione di pacchetto sono reti IP (Internet Protocol), reti Ethernet e reti MPLS (Multi-Protocol Label Switching).

I Pacchetti non sempre raggiungono i loro nodi destinazione, ossia essi possono essere persi durante la trasmissione attraverso la rete. La perdita di pacchetti è dovuta a diversi motivi. Per esempio, un nodo o un collegamento potrebbe guastarsi, o pacchetti potrebbero essere scartati da un nodo a causa della congestione delle sue porte. Inoltre, i pacchetti potrebbero essere scartati da un nodo perché essi contengono errori di bit.

Inoltre, ciascun pacchetto è trasmesso ad un tempo di trasmissione dal nodo sorgente ed è ricevuto ad un tempo di ricezione dal nodo destinazione (se non viene perso). Il tempo trascorso tra il tempo di trasmissione ed il tempo di ricezione è tipicamente chiamato “ritardo monodirezionale”. Il ritardo monodirezionale di un pacchetto dipende principalmente dal numero di possibili nodi intermedi attraversati dal pacchetto dalla sorgente alla destinazione, dal tempo di permanenza di un pacchetto presso ciascun nodo e dal tempo di propagazione lungo i collegamenti.

Inoltre, i pacchetti possono avere ritardi monodirezionali diversi. La differenza tra i ritardi monodirezionali di due pacchetti di uno stesso flusso di pacchetti è denominata “interarrival jitter” (o, brevemente, “jitter”).

Quando un servizio di comunicazione (in particolare, un servizio voce in tempo reale o un servizio dati come chiamate, teleconferenze, videoconferenze, ecc) è fornito per mezzo di una rete a commutazione di pacchetto, una misura di prestazioni in termini di perdita di pacchetti, ritardo monodirezionale e jitter su flussi di pacchetti che trasportano il servizio fornisce una indicazione della qualità del servizio (Quality of Service, QoS) percepita dagli utenti finali del servizio. In aggiunta, la perdita di pacchetti e ritardo/jitter elevato possono richiedere la ritrasmissione e quindi ridurre l’efficienza della rete di comunicazioni. Pertanto, misurare la perdita di pacchetti, il ritardo monodirezionale e/o il jitter di flussi di pacchetti in una rete di comunicazioni è di particolare interesse per gli operatori di rete.

WO 2010/072251 a nome della stessa Richiedente descrive un metodo per misurare la perdita di pacchetti di un flusso di pacchetti trasmessi da un nodo trasmittente ad un nodo ricevente, che utilizza una tecnica di marcatura alternata. Il flusso di pacchetti è un flusso di pacchetti punto-punto i cui pacchetti seguono uno stesso percorso tra il nodo trasmittente ed il nodo ricevente.

WO 2017/186302 a nome della stessa Richiedente descrive un metodo per eseguire una misura di prestazioni su un flusso di pacchetti multipunto i cui pacchetti seguono due o più percorsi da estremità ad estremità almeno parzialmente non sovrapposti attraverso la rete. Tutti i pacchetti del flusso di pacchetti multipunto sono soggetti a marcatura alternata da parte dei rispettivi nodi sorgente. Una pluralità di punti di misura è implementata nella sottorete che supporta la trasmissione del flusso di pacchetti multipunto. Ciascun punto di misura fornisce parametri di prestazioni (ad esempio contatori) relativi ai pacchetti ricevuti. Per fornire una misura di prestazioni, è identificato un cluster, ossia un insieme di punti di misura che mostra la proprietà che l’insieme di pacchetti ricevuti presso i punti di misura di ingresso del cluster è lo stesso dell’insieme dei pacchetti ricevuti presso i punti di misura di uscita del cluster, se non si verifica perdita di pacchetti. I parametri di prestazione forniti da tutti i punti di misura di ingresso e uscita del cluster sono poi combinati per fornire una misura di prestazioni del flusso di pacchetti multipunto nel cluster.

Riassunto dell’invenzione

La Richiedente ha notato che l’implementazione della misura di prestazioni di WO 2010/072251 presso i nodi di una rete di comunicazione potrebbe presentare problemi di scalabilità, quando il numero di flussi di pacchetti da misurare aumenta. Per identificare i pacchetti di ciascun flusso di pacchetti da misurare, infatti, ciascun nodo dovrebbe essere configurato con un filtro adeguato capace di discriminare i pacchetti appartenenti al flusso di pacchetti desiderato dai pacchetti che non appartengono ad esso. Per identificare uno specifico flusso di pacchetti punto-punto (per esempio che trasporta un certo servizio specifico, per esempio un servizio voce), il filtro dovrebbe essere basato su molti campi dell’intestazione (“Header”) del pacchetto (source address, destination address, ecc) ed è quindi molto complesso. Implementare molti filtri (per esempio 1000 o più) di questo tipo presso i nodi della rete di comunicazioni per identificare corrispondenti flussi di pacchetti da misurare è estremamente costoso e, in alcuni casi, praticamente non fattibile.

Al contrario, secondo la tecnica di WO 2017/186302 l’identificazione di tutti i pacchetti del flusso di pacchetti multipunto potrebbe richiedere un singolo filtro o un numero ridotto di filtri, ciascun filtro essendo inoltre molto più semplice di qualsiasi filtro necessario per identificare i pacchetti di un singolo flusso di pacchetti punto-punto. Per esempio, tutti i pacchetti di un flusso di pacchetti multipunto possono essere identificati in base a un singolo campo dell’intestazione, per esempio il source address. Tuttavia, le misure di prestazioni fornite da WO 2017/186302 sono indicative del comportamento dell’intero flusso di pacchetti multipunto all’interno del cluster selezionato. Se un operatore di rete desidera ottenere una misura di prestazioni solo su una porzione del flusso di pacchetti multipunto – per esempio su un singolo flusso di pacchetti punto-punto compreso nel flusso di pacchetti multipunto e che trasporta un certo servizio specifico (ad esempio un servizio voce) –non può estrapolare tale misura dai parametri di prestazioni forniti dai punti di misura del cluster.

Alla luce di quanto sopra, la Richiedente ha affrontato il problema di fornire un metodo per eseguire una misura di prestazioni in una rete di comunicazioni a commutazione di pacchetto, che supera i suddetti inconvenienti.

In particolare, la Richiedente ha affrontato il problema di fornire un metodo per eseguire una misura di prestazioni in una rete di comunicazioni a commutazione di pacchetto, che permette ad un operatore di rete di ottenere misure di prestazioni relative ad una qualsiasi porzione desiderata (per esempio qualsiasi flusso di pacchetti punto-punto) di un flusso di pacchetti multipunto, senza richiedere l’implementazione di filtri complessi e costosi in corrispondenza dei nodi della rete di comunicazioni.

Nella presente descrizione e nelle rivendicazioni, l’espressione “flusso di pacchetti multipunto” designerà un flusso di pacchetti comprendente pacchetti che sono trasmessi lungo due, o più, percorsi da estremità ad estremità almeno parzialmente non sovrapposti, in modo che diversi pacchetti del flusso di pacchetti multipunto possono essere ricevuti presso diversi punti di misura implementati lungo quei percorsi. Per esempio, un flusso di pacchetti multipunto può comprendere due o più flussi di pacchetti punto-punto con diversi nodi sorgente e/o diversi nodi destinazione. In alternativa o in aggiunta, un flusso di pacchetti multipunto può comprendere un flusso di pacchetti punto-punto i cui pacchetti, per esempio a causa di un algoritmo di bilanciamento del carico, sono trasmessi da uno stesso nodo sorgente ad uno stesso nodo destinazione attraverso nodi intermedi diversi. Inoltre, nella presente descrizione e nelle rivendicazioni, l’espressione “sotto-flusso di pacchetti” designerà una porzione arbitraria del flusso di pacchetti multipunto, che può comprendere un singolo flusso di pacchetti punto-punto del flusso di pacchetti multipunto o l’aggregazione di due o più flussi di pacchetti punto-punto del flusso di pacchetti multipunto (ad eccezione dell’aggregazione di tutti i flussi di pacchetti punto-punto dei flussi di pacchetti multipunto).

Inoltre, nella seguente descrizione e nelle rivendicazioni, l’espressione “eseguire una misura di prestazioni su un flusso di pacchetti” designerà una operazione di misurare:

- un ritardo monodirezionale, un ritardo bidirezionale o un jitter indotto su pacchetti di detto flusso di pacchetti dalla trasmissione tra i due punti di misura; e/o

- una perdita di pacchetti indotta su pacchetti di detto flusso di pacchetti dalla trasmissione tra i due punti di misura.

Inoltre, nella presente descrizione e nelle rivendicazioni, l’espressione “contenuto del pacchetto” designerà l’insieme del contenuto della sua intestazione e del contenuto del suo carico utile.

Secondo forme di realizzazione della presente invenzione, il suddetto problema è risolto da un metodo per eseguire una misura di prestazioni in una rete di comunicazioni in cui ciascun punto di misura di un numero di punti di misura implementati nella rete di comunicazioni identifica pacchetti di un flusso di pacchetti multipunto e seleziona da essi un numero di pacchetti campione, in base al valore di una firma di campionamento calcolata applicando una funzione di hash ad una predeterminata maschera di bit in ciascun pacchetto identificato. In seguito, per ciascun pacchetto campione, ciascun punto di misura fornisce ad un server di gestione un parametro di prestazioni campione e almeno una porzione del contenuto del pacchetto (a titolo di esempio non limitativo, almeno una porzione della sua intestazione). Per fornire una misura di prestazioni, il server di gestione identifica un cluster di punti di misura in cui, se non avviene perdita di pacchetti, ciascun pacchetto identificato del flusso di pacchetti multipunto ricevuto da un punto di misura di ingresso del cluster è ricevuto anche presso un punto di misura di uscita del cluster. Quindi, tra i parametri di prestazioni campione forniti dai punti di misura del cluster, il server di gestione identifica i parametri di prestazioni campione relativi a pacchetti campione che appartengono ad un certo sotto-flusso di pacchetti compreso nel flusso di pacchetti multipunto, in base all’almeno una porzione di detto contenuto del pacchetto. Il server di gestione quindi esegue la misura di prestazioni sul sotto-flusso di pacchetti, sulla base dei parametri di prestazioni campione identificati.

Pertanto, vantaggiosamente, elaborando le porzioni del contenuto dei pacchetti campione ricevuti dai punti di misura (a titolo di esempio non limitativo, le intestazioni dei pacchetti campione), il server di gestione può, in qualsiasi momento, fornire una misura di prestazioni off-line o a posteriori sui pacchetti campione di qualsiasi sotto-flusso di pacchetti compreso nel flusso di pacchetti multipunto. Avendo a sua disposizione le intestazioni dei pacchetti campione, per esempio, il server di gestione può applicare un filtraggio off-line alle intestazioni dei pacchetti campione basandosi su diversi campi dell’intestazione, estrapolando quindi - tra tutti i parametri di prestazioni relativi ai pacchetti campione del flusso di pacchetti multipunto -solo quelli che si riferiscono ad uno specifico sotto-flusso di pacchetti compreso nel flusso di pacchetti multipunto. Tale filtraggio off-line può essere fatto per ciascuno dei sotto-flussi di pacchetti che formano il flusso di pacchetti multipunto e con qualsiasi granularità desiderata, modificando opportunamente i criteri di filtraggio. Ad esempio, in uno scenario in cui sono presenti diversi servizi trasportati da rispettivi flussi di pacchetti punto-punto, all’operatore di rete è vantaggiosamente data la capacità di ottenere misure di prestazioni separate per ciascuno dei servizi forniti.

A tale riguardo, si deve notare che l’uso della firma di campionamento di hash in combinazione con le proprietà del cluster garantisce che un pacchetto campione identificato da un punto di misura di ingresso del cluster sia ricevuto e correttamente identificato come pacchetto campione anche in un punto di misura di uscita del cluster (a condizione che non venga perso durante la trasmissione attraverso il cluster) e quindi che i parametri di prestazioni forniti al server di gestione siano coerenti tra loro. Il server di gestione ha quindi a sua disposizione una banca dati di parametri di prestazioni campione commensurabile e coerente (per esempio, con le rispettive intestazioni di pacchetto), che il server di gestione può sottoporre a filtraggio off-line come descritto sopra per estrapolare la misura di prestazioni per qualsiasi sotto-flusso di pacchetti desiderato.

Inoltre, vantaggiosamente, nessun filtro complesso e costoso deve essere implementato nei punti di misura della rete di comunicazioni. I punti di misura identificano infatti cumulativamente tutti i pacchetti che formano il flusso di pacchetti multipunto, cosa che può essere fatta usando un filtro molto semplice, per esempio basato su un singolo campo dell’intestazione del pacchetto. I filtri più complessi che consentono l’identificazione dei parametri di prestazioni campione relativi a pacchetti campione di qualsiasi sotto-flusso di pacchetti desiderato sono invece applicati dal server di gestione, che quindi ha in carico la maggior parte del carico computazionale necessario per identificare i singoli sotto-flussi di pacchetti.

Secondo un primo aspetto, la presente invenzione fornisce un metodo per eseguire una misura di prestazioni in una rete di comunicazioni, il metodo comprendendo, presso ciascun punto di misura di un numero di punti di misura implementati nella rete di comunicazioni:

a) identificare pacchetti di un flusso di pacchetti multipunto;

b) tra i pacchetti identificati del flusso di pacchetti multipunto selezionare un numero di pacchetti campione, la selezione essendo basata sul valore di una firma di campionamento calcolata applicando una funzione di hash ad una predeterminata maschera di bit in ciascun pacchetto identificato; c) per ciascun pacchetto campione, fornire ad un server di gestione un parametro di prestazioni campione e almeno una porzione del contenuto del pacchetto;

il metodo comprendendo inoltre, presso il server di gestione:

d) tra il numero di punti di misura, identificare un cluster di punti di misura in cui, se non si verifica alcuna perdita di pacchetti, ciascun pacchetto identificato del flusso di pacchetti multipunto ricevuto da un punto di misura di ingresso del cluster è anche ricevuto presso un punto di misura di uscita del cluster.

e) tra i parametri di prestazioni campione forniti dai punti di misura del cluster, identificare parametri di prestazioni campione relativi a pacchetti campione che appartengono ad un sotto-flusso di pacchetti compreso nel flusso di pacchetti multipunto, sulla base dei parametri di prestazione campione.

f) Eseguire la misura di prestazioni sul sottoflusso di pacchetti sulla base dei parametri di prestazioni campione identificati.

Preferibilmente, i pacchetti di un flusso di pacchetti multipunto sono marcati prima di essere iniettati nella rete di comunicazioni, la marcatura comprendendo impostare il valore di un campo di marcatura compreso in ciascun pacchetto del flusso di pacchetti multipunto ad uno di almeno due valori di marcatura alternativi e ciclicamente commutare il valore del campo di marcatura con un periodo di marcatura Tm.

Preferibilmente, alla fase c) l’almeno una porzione del contenuto del pacchetto comprende almeno una porzione dell’intestazione del pacchetto che comprende almeno un campo di identificazione del sotto-flusso di pacchetti, diverso da uno o più campi di identificazione utilizzati nella fase a) per identificare il flusso di pacchetti multipunto.

In aggiunta o alternativamente, alla fase c) l’almeno una porzione del contenuto del pacchetto comprende almeno una porzione del carico utile del pacchetto che comprende almeno un campo di identificazione del sottoflusso di pacchetti, diverso da uno o più campi di identificazione utilizzati nella fase a) per identificare il flusso di pacchetti multipunto.

Preferibilmente, alla ricezione del parametro di prestazioni campione e dell’almeno una porzione del contenuto del pacchetto presso il server di gestione, il parametro di prestazioni campione e l’almeno una porzione del contenuto del pacchetto sono memorizzati in una banca dati.

Preferibilmente, le fasi d), e) e f) sono eseguite off-line dopo la memorizzazione, al verificarsi di un evento rilevato dal server di gestione. Preferibilmente, alla fase e) identificare i parametri di prestazioni campione relativi a pacchetti campione che appartengono al sotto-flusso di pacchetti comprende:

- determinare almeno un campo di identificazione compreso nell’almeno una porzione del contenuto del pacchetto il cui valore identifica il sottoflusso di pacchetti;

- leggere nella banca dati l’almeno una porzione del contenuto del pacchetto che accompagna ciascun parametro di prestazioni campione memorizzato e, se comprende il valore che identifica il sotto-flusso di pacchetti nell’almeno un campo di identificazione, recuperare il corrispondente parametro di prestazioni campione dalla banca dati.

Secondo una variante:

- la fase c) comprende, per ciascun pacchetto campione, fornire al server di gestione anche un identificativo del pacchetto campione, e

- la fase f) comprende, in base agli identificatori, identificare i parametri di prestazioni campione relativi ad uno stesso pacchetto campione e forniti da diversi punti di misura del cluster.

Opzionalmente, il metodo comprende inoltre, dopo la fase a), aggiornare un parametro di prestazioni cumulativo indicativo del comportamento del flusso di pacchetti multipunto nel suo insieme e la fase f) comprende anche fornire una misura di prestazioni cumulativa in base ai parametri di prestazioni cumulativi ricevuti dai punti di misura del cluster.

Preferibilmente, la misura di prestazioni cumulativa è eseguita dal server di gestione sostanzialmente in tempo reale.

Secondo un secondo aspetto, la presente invenzione fornisce un sistema per eseguire una misura di prestazioni in una rete di comunicazioni, il sistema comprendendo un numero di punti di misura implementati nella rete di comunicazioni e un server di gestione, in cui ciascun punto di misura è configurato per:

a) identificare pacchetti di un flusso di pacchetti multipunto;

b) tra i pacchetti identificati del flusso di pacchetti multipunto, selezionare un numero di pacchetti campione, la selezione essendo basata sul valore di una firma di campionamento calcolata applicando una funzione di hash ad una predeterminata maschera di bit in ciascun pacchetto identificato; c) per ciascun pacchetto campione, fornire al server di gestione un parametro di prestazioni campione e almeno una porzione del contenuto del pacchetto;

e in cui il server di gestione è configurato per:

d) tra il numero di punti di misura, identificare un cluster di punti di misura in cui, se non si verifica alcuna perdita di pacchetti, ciascun pacchetto identificato del flusso di pacchetti multipunto ricevuto da un punto di misura di ingresso del cluster è anche ricevuto presso un punto di misura di uscita del cluster;

e) tra i parametri di prestazione campione forniti dai punti di misura del cluster, identificare parametri di prestazioni campione relativi a pacchetti campione che appartengono ad un sotto-flusso di pacchetti compreso nel flusso di pacchetti multipunto, in base all’almeno una porzione del contenuto del pacchetto; e

f) eseguire la misura di prestazioni sul sotto-flusso di pacchetti, in base a detti parametri di prestazioni campione identificati.

Breve descrizione dei disegni

La presente invenzione diverrà più chiara dalla seguente descrizione dettagliata, fornita a titolo di esempio e non di limitazione, da leggersi con riferimento ai disegni allegati, in cui:

- la Figura 1 mostra schematicamente una rete di comunicazioni esemplificativa che supporta la trasmissione di un flusso di pacchetti multipunto;

- la Figura 2 mostra la struttura dell’intestazione di un pacchetto IP;

- la Figura 3 è un diagramma di flusso che mostra il funzionamento di un punto di misura secondo una forma di realizzazione della presente invenzione;

- la Figura 4 è un diagramma di flusso che mostra il funzionamento del server di gestione, secondo una forma di realizzazione della presente invenzione;

- la Figura 5 è un diagramma di flusso che mostra in ulteriore dettaglio una delle fasi del diagramma di flusso di Figura 4, secondo una forma di realizzazione della presente invenzione.

Descrizione dettagliata di forme di realizzazione preferite dell’invenzione

La Figura 1 mostra schematicamente una porzione di una rete di comunicazioni CN a commutazione di pacchetto esemplificativa in cui il metodo per eseguire una misura di prestazioni è implementato secondo forme di realizzazione della presente invenzione. La rete di comunicazioni CN a commutazione di pacchetto può essere una rete IP o qualsiasi altro tipo di rete a commutazione di pacchetto (ad esempio MPLS o Ethernet).

La rete di comunicazioni CN a commutazione di pacchetto comprende una pluralità di nodi interconnessi reciprocamente da collegamenti secondo una qualsiasi topologia nota. In particolare, la rete CN comprende nodi N0, N1, N2, N3, … NK (con K intero e maggiore di 2, preferibilmente maggiore di 10, per esempio 100, 500, 1000 o 5000) che, a titolo di esempio non limitativo, sono reciprocamente interconnessi secondo una topologia ad albero. In particolare, il nodo N0 è connesso a ciascuno dei nodi N1, N2, N3, … NK. Il collegamento tra il nodo N0 e ciascun nodo N1, N2, N3, … NK può essere un collegamento diretto o può comprendere uno o più nodi intermedi, che per semplicità non sono mostrati in Figura 1.

La rete di comunicazioni CN supporta la trasmissione di un flusso di pacchetti multipunto PF. Il flusso di pacchetti multipunto PF può comprendere diversi sotto-flussi di pacchetti, per esempio diversi flussi di pacchetti punto-punto originati da N=1 nodi sorgente e indirizzati a M>1 nodi destinazione. Questo è il caso dello scenario esemplificativo illustrato in Figura 1, dove il flusso di pacchetti PF comprende K flussi di pacchetti puntopunto PF1, PF2, PF3, …, PFk aventi N=1 nodi sorgente N0 e M=K nodi destinazione N1, N2, N3, … NK. In particolare secondo lo scenario esemplificativo di Figura 1 il flusso di pacchetti multipunto PF nel suo complesso viene iniettato nella rete di comunicazioni CN attraverso il nodo N0 e quindi suddiviso, in modo tale che ciascun flusso di pacchetti puntopunto PF1, PF2, PF3, …, PFK raggiunge un rispettivo nodo destinazione N1, N2, N3, … NK.

Lo scenario di Figura 1 non è limitativo. Il flusso di pacchetti multipunto PF può avere N>1 nodi sorgente e M=1 nodi destinazione. Alternativamente, il flusso di pacchetti multipunto può avere N>1 nodi sorgente e M>1 nodi destinazione. In questo caso, il flusso di pacchetti multipunto PF può avere pochi nodi sorgente e molti nodi destinazione, ossia N << M. Questo è il caso ad esempio di flussi di pacchetti multipunto che trasportano il traffico di un servizio internet OTT nella direzione di downstream, ossia da pochi server OTT a multipli utenti finali, o quelli che trasportano il traffico LTE (Long Term Evolution) nella direzione di downstream, ossia da pochi gateway di pacchetto a diversi eNodeB. Alternativamente, il flusso di pacchetti multipunto PF può avere molti nodi sorgente e pochi nodi destinazione, ossia N >> M. Questo è il caso ad esempio di flussi di pacchetti multipunto che trasportano il traffico di un servizio internet OTT nella direzione di upstream, ossia da molteplici utenti finali a pochi server OTT, o quelli che trasportano il traffico LTE nella direzione di upstream, ossia da diversi eNodeB a pochi gateway di pacchetto.

Preferibilmente, ciascun pacchetto del flusso di pacchetti multipunto PF comprende una intestazione (“header”) ed un carico utile (“payload”). Preferibilmente l’intestazione comprende informazioni che i nodi della rete di comunicazioni CN utilizzano per instradare il pacchetto. Il formato dell’intestazione dipende dal protocollo secondo il quale i pacchetti sono formattati. A titolo di esempio non limitativo, la Figura 2 mostra l’intestazione H di un pacchetto formattato secondo il noto protocollo TCP (Transmission Control Protocol) su IPv4 (Internet Protocol version 4). L’intestazione H comprende 40 byte divisi in 20 byte per l’intestazione IP e 20 byte per l’intestazione TCP.

Preferibilmente, il flusso di pacchetti multipunto PF è definito (e quindi distinguibile tra tutto il traffico trasmesso nella rete di comunicazioni CN) da uno o più valori di uno o più campi dell’intestazione di cui sopra, che sono chiamati nel seguito “campi di identificazione”. In particolare, nel caso del protocollo IPv4, i campi di identificazione possono comprendere uno o più tra: Source Address, Destination Address, Protocol e DSCP dell’intestazione IP e Source Port e Destination Port dell’intestazione TCP. Selezionando in modo adeguato i campi di identificazione e i loro valori, diversi tipi di flussi di pacchetti multipunto possono essere definiti.

Per esempio, il flusso di pacchetti multipunto PF dello scenario mostrato in Figura 1 può essere definito da un singolo valore del campo Source Address (ossia, l’indirizzo IP del dispositivo host direttamente o indirettamente connesso al nodo sorgente N1). In generale, definendo un flusso di pacchetti multipunto con un singolo valore del campo Source Address si ottiene un flusso di pacchetti multipunto che ha N=1 nodi sorgente (come PF in Figura 1), mentre definendo un flusso di pacchetti multipunto con un singolo valore del campo Destination Address si ottiene un flusso di pacchetti multipunto che ha M=1 nodi destinazione.

Preferibilmente, una pluralità di punti di misura sono implementati nella rete di comunicazioni CN. Ciascun punto di misura può essere incorporato all’interno di un rispettivo nodo, o implementato come una macchina separata connessa ad un rispettivo nodo. Per esempio, con riferimento alla Figura 1, un punto di misura MP0 è implementato presso il nodo N0 (in particolare sulla sua interfaccia di ingresso attraverso la quale viene iniettato il flusso di pacchetti PF nella rete di comunicazione CN) mentre i punti di misura MP1, MP2, MP3, …, MPK sono implementati presso i nodi N1, N2, N3, …, NK (per esempio, alle loro interfacce di ingresso attraverso le quali ricevono il rispettivo flusso di pacchetti punto-punto PF1, PF2, PF3, ... PFK). Preferibilmente, la rete di comunicazioni CN è anche fornita di un server di gestione MS, che può essere per esempio un controllore SDN (Software Defined Network) o un server dedicato per l’analisi di big data. Il server di gestione MS preferibilmente coopera con i punti di misura MP0, MP1, MP2, MP3, …, MPK e con una banca dati DB per memorizzare informazioni raccolte dai punti di misura MP0, MP1, MP2, MP3, …, MPK.

Secondo forme di realizzazione preferite della presente invenzione, i pacchetti del flusso di pacchetti multipunto PF sono marcati prima di essere iniettati nella rete di comunicazioni CN. Per esempio, con riferimento allo scenario di Figura 1, i pacchetti del flusso di pacchetti multipunto PF possono essere marcati presso il nodo N0 o prima che raggiungano il nodo N0.

A scopo di marcatura, ciascun pacchetto del flusso di pacchetti multipunto PF preferibilmente include un campo di marcatura MF comprendente almeno un bit, il cui valore è impostato ad uno di almeno due valori di marcatura alternativi MA, MB. Il campo di marcatura MF è preferibilmente compreso nell’intestazione H del pacchetto. Il campo di marcatura MF può essere ad esempio un campo al quale il protocollo in base al quale il pacchetto è stato formattato non ha ancora assegnato una funzione specifica. In alternativa, il campo di marcatura MF può essere compreso in un campo avente altri usi. Per esempio, nel caso di pacchetti IP (si veda Figura 2), il campo di marcatura MF può comprendere un bit del campo TOS (Type of Service) a 8 bit o il bit RSV del campo Flags, e i suoi due valori di marcatura alternativi MA e MB possono essere 1 e 0, rispettivamente.

Il valore del campo di marcatura MF è commutato alternativamente (ad esempio periodicamente) tra MA e MB con un periodo Tm, che sarà definito qui in seguito “periodo di marcatura”. Il periodo di marcatura Tm può essere impostato dall’operatore di rete, secondo il frequenza di misura di tempo desiderata (come verrà descritto in dettaglio nel seguito, il periodo di marcatura Tm è anche correlato al periodo di misura). Ad esempio il periodo di marcatura Tm può essere pari a 5 min. Il periodi di marcatura Tm può essere non costante, ossia la commutazione del valore di marcatura tra gli almeno due valori MA, MB può avvenire con una frequenza non periodica, come nel caso di marcatura alternata che è influenzata da eventi relativi alla rete.

Se, diversamente dallo scenario mostrato in Figura 1, i K flussi di pacchetti punto-punto PF1, PF2, …, PFK hanno diversi nodi sorgente, la marcatura di tutti i K flussi di pacchetti punto-punto PF1, PF2, PF3,… PFK del flusso multipunto PF è preferibilmente sostanzialmente sincronizzata, ossia il valore di marcatura è modificato sostanzialmente nello stesso tempo (ossia con un disallineamento massimo di Tm/2) per tutti i K flussi di pacchetti punto-punto del flusso di pacchetti multipunto PF. In questo modo, i pacchetti del flusso di pacchetti multipunto PF che sono trasmessi durante un certo periodo di marcatura sono sostanzialmente tutti marcati con uno stesso valore di marcatura MA o MB.

Il comportamento di ciascun punto di misura MP0, MP1, MP2, MP3, …, MPK (anche indicato genericamente come MPk con k= 0, 1, 2, 3, … K nella seguente descrizione) secondo una forma di realizzazione dell’invenzione sarà ora descritta in dettaglio con riferimento al diagramma di flusso di Figura 3.

Durante ciascun periodo di marcatura, ciascun punto di misura MPk riceve tutto il traffico (o una sua copia) ricevuto presso il rispettivo nodo (fase 300). Il punto di misura MPk quindi filtra tutto il traffico in arrivo, in modo da identificare i pacchetti del flusso di pacchetti multipunto PF (fase 301). Per eseguire la fase 301 di filtraggio, il punto di misura MPk preferibilmente legge il valore (o i valori) del campo (o campi) di identificazione compreso nell’intestazione H di ciascun pacchetto ricevuto e controlla se è (o sono) uguale (uguali) a quello o quelli che definiscono il flusso di pacchetti multipunto PF come sopra descritto. Assumendo che il flusso di pacchetti PF mostrato nello scenario esemplificativo di Figura 1 sia definito dal valore dell’indirizzo IP del nodo sorgente N0, alla fase 301 ciascun punto di misura MPk preferibilmente verifica se il Source Address di ciascun pacchetto in arrivo è uguale a tale valore. Può essere apprezzato che il filtraggio eseguito alla fase 301 richiede l’implementazione di uno stesso filtro molto largo e semplice presso ciascuno dei punti di misura MPk.

Quindi, opzionalmente, ciascun punto di misura MPk aggiorna un parametro di prestazioni cumulativo indicativo del comportamento del flusso di pacchetti multipunto PF nel suo insieme (fase 302). In particolare, ciascun punto di misura MPk preferibilmente implementa una coppia di parametri di prestazioni cumulativi CPP(k)<A>, CPP(k), uno relativo ai pacchetti marcati con MA e uno relativo ai pacchetti marcati con MB. Tale coppia di parametri di prestazioni cumulativi CPP(k)<A>, CPP(k)può comprendere, per esempio: - una coppia di contatori CC(k)<A>, CC(k)che contano il numero di pacchetti identificati del flusso di pacchetti PF marcati con MA e MB rispettivamente; e/o

- una coppia di timestamp medi AT(k)<A >, AT(k)che indicano il tempo medio di ricezione, presso il punto di misura MPk, dei pacchetti identificati del flusso di pacchetti PF marcati con MA e MB, rispettivamente.

Siccome – durante ciascun periodo di marcatura – solo i pacchetti con uno stesso valore di marcatura MA o MB sono trasmessi, le iterazioni della fase 302 durante periodi di marcatura in cui i pacchetti sono marcati con MA risultano nel fatto che il parametro di prestazioni cumulativo CPP(k)<A >viene aggiornato e il parametro di prestazioni cumulativo CPP(k)è invece in stato di riposo, ossia ha un valore costante uguale a quello raggiunto alla fine del periodo di marcatura precedente. Al contrario, le iterazioni della fase 302 durante periodi di marcatura in cui i pacchetti sono marcati con MB risulta nel fatto che il parametro di prestazioni cumulativo CPP(k)viene aggiornato ed il parametro di prestazioni cumulativo CPP(k)<A >è invece in stato di riposo. Quindi, tra i pacchetti del flusso di pacchetti multipunto PF come identificati alla fase 301, ciascun punto di misura MPk preferibilmente identifica un numero di pacchetti campione basandosi sul valore di una firma di campionamento SS calcolata per ciascun pacchetto del flusso di pacchetti PF come identificato alla fase 301 (fase 303). La firma di campionamento SS è preferibilmente calcolata applicando una funzione di hash a una predeterminata maschera di bit nel pacchetto, preferibilmente nell’intestazione H del pacchetto.

Secondo una forma di realizzazione preferita, presso ciascun punto di misura MPk l’identificazione dei pacchetti campione basata sulla firma di campionamento SS è eseguita secondo WO 2018/072828 a nome della stessa Richiedente. In breve, per ciascun pacchetto identificato alla fase 301 ciascun punto di misura MPk preferibilmente calcola una firma di campionamento SS di Smax bit (per esempio Smax=32). Quindi, il punto di misura MPk identifica i pacchetti campione come quelli le cui firme di campionamento SS comprendono una porzione di S bit (per esempio gli S bit più significativi) uguale ad un certo valore di campionamento Hs*. L’hash inutilizzato dei bit Smax- S viene memorizzato dal punto di misura MPk e verrà utilizzato per identificare in modo univoco il pacchetto campione, come verrà descritto in dettaglio nel seguito. Opzionalmente, mentre il punto di misura MPk sta eseguendo la selezione del campione, conta il numero di pacchetti campione selezionati e regola retroattivamente la lunghezza S della porzione di firma di campionamento usata per selezionare i pacchetti campione in base a questo numero.

Secondo altre forme di realizzazione, presso ciascun punto di misura MPk l’identificazione dei pacchetti campione in base alla firma di campionamento SS è eseguita secondo WO 2017/07177 a nome della stessa Richiedente. In questo caso, la firma di campionamento è calcolata applicando una funzione di hash ad una certa maschera di bit in ciascun pacchetto campione e ha una lunghezza fissa S e, per identificare univocamente ciascun pacchetto campione, è utilizzata una firma di identificazione, che ciascun punto di misura MPk calcola applicando un’ulteriore funzione di hash ad un’ulteriore maschera di bit in ciascun pacchetto campione.

Preferibilmente, tutti i punti di misura MP0, MP1, MP2, MP3, … MPK usano una stessa maschera di bit, una stessa funzione di hash ed uno stesso valore di campionamento (o corrispondenti valori di campionamento, se ciascun punto di misura MPk ha la capacità di regolare la lunghezza S della porzione di firma di campionamento da utilizzare per selezionare i pacchetti campione) come una discriminante per determinare quando un pacchetto è un pacchetto campione o no. Quindi, se uno stesso pacchetto del multipunto PF è intercettato da due punti di misura, entrambi i punti di misura lo selezioneranno anche come un pacchetto campione.

Dunque, all’identificazione di ogni campione di misura, ciascun punto di misura MPk preferibilmente fornisce un parametro di prestazioni campione SPPi(k) relativo ad esso (fase 304), “i” essendo un indice di campione. Per esempio, alla fase 304 ciascun punto di misura MPk può fornire un timestamp campione STi(k) che indica il tempo al quale il pacchetto campione è stato ricevuto dal punto di misura MPk.

Preferibilmente, alla fase 304 ciascun punto di misura MPk associa a ciascun parametro di prestazioni campione SPPi(k) uno o più di:

- La firma di campionamento SS del pacchetto campione come calcolata alla fase 303 o, almeno, l’hash non utilizzato della firma di campionamento SS, ossia gli Smax- S bit meno significativi della firma di campionamento SS che non sono stati utilizzati per selezionare i pacchetti campione alla fase 303;

- Il campo (i campi) di marcatura usato alla fase 301, che identifica il flusso di pacchetti multipunto PF (questa informazione è quindi la stessa per tutti i parametri di prestazioni campione STi(k) forniti da tutti i punti di misura);

- un identificativo del punto di misura Mk; e

- un identificativo del periodo di marcatura Tm durante il quale il pacchetto campione è stato identificato (per esempio, il tempo di avvio del periodo di marcatura Tm come rilevato dal punto di misura MPk come un cambio del valore di marcatura MA, MB dei pacchetti ricevuti). Oltre a queste informazioni, secondo forme di realizzazione della presente invenzione, ciascun parametro di prestazioni campione SPPi(k) è anche associato ad una porzione del contenuto del pacchetto campione PCi(k) che comprende informazioni che permettono di distinguere pacchetti campione compresi in sotto-flussi di pacchetti differenti del flusso di pacchetti multipunto PF.

Per esempio, la porzione del contenuto del pacchetto campione PCi(k) che accompagna il parametro di prestazioni campione SPPi(k) fornito dal punto di misura MPk può comprendere l’intestazione H del pacchetto o, almeno, una porzione dell’intestazione H del pacchetto che comprende uno o più campi di identificazione diversi da quello(i) usato(i) nella fase 301 per identificare i pacchetti del flusso di pacchetti multipunto PF. Per esempio se il flusso di pacchetti multipunto PF è identificato dal campo Source Address (in particolare, l’indirizzo IP del nodo N0, nello scenario esemplificativo di Figura 1), quindi la porzione di contenuto del pacchetto PCi(k) che è associata al parametro di prestazioni campione SPPi(k) relativo ad un pacchetto campione può comprendere almeno il campo Destination Address della sua intestazione. In questo modo, parametri di prestazioni campione SPPi(k) relativi ai pacchetti campione di ciascun flusso di pacchetti punto-punto PF1, PF2, PF3, …, PFK sono accompagnati da rispettivi valori del campo Destination Address, ossia gli indirizzi IP dei nodi N1, N2, N3, .. NK.

Questo è un esempio non limitativo. Secondo altre forme di realizzazione, per esempio, la porzione del contenuto del pacchetto campione PCi(K) associata al parametro di prestazioni campione SPPi(k) relativo ad un certo pacchetto campione può comprendere almeno una porzione del carico utile del pacchetto o il pacchetto intero. Questo può essere utile per esempio, se i pacchetti del flusso di pacchetti multipunto PF sono formattati secondo diversi protocolli impilati. In questo caso, l’intestazione H del pacchetto corrisponde al protocollo di livello più basso, mentre la parte più significativa del carico utile comprende le intestazioni dei protocolli di livello più alto. La porzione di contenuto di pacchetto PCi(k) associata al parametro di prestazioni campione SPPi(k) di un pacchetto campione può quindi comprendere la parte più significativa del carico utile che comprende le intestazioni dei protocolli di livello più alto.

Preferibilmente, alla fase 304 ciascun punto di misura MPk memorizza localmente i parametri di prestazioni campione SPPi(k) e le informazioni associate a ciascun parametro di prestazioni SPPi(k), per esempio in una memoria temporanea locale o buffer.

In seguito, ciascun punto di misura MPk preferibilmente invia al server di gestione MS sia il(i) parametro(i) di prestazioni cumulativo(i) CPP(k)<A>, CPP(k)sia i parametri di prestazione campione SPPi(k) (fase 305).

Per quanto riguarda il(i) parametro(i) di prestazioni cumulativo(i) CPP(k)<A>, CPP(k)come sopra descritto, a causa dell’applicazione della marcatura alternata ai pacchetti del flusso di pacchetti multipunto PF, durante ciascun periodo di marcatura Tm uno dei parametri di prestazioni cumulativi (per esempio CPP(k)<A>) è attivo mentre l’altro (per esempio CPP(k)) è non attivo. In seguito, alla fine di ciascun periodo di marcatura, ciascun punto di misura MPk preferibilmente invia al server di gestione MS il(i) valore(i) del parametro (o dei parametri) di prestazioni cumulativo(i) attualmente non attivo(i).

Per quanto riguarda i parametri di prestazioni campione, preferibilmente, alla fine di ciascun periodo di marcatura Tm ciascun punto di misura MPk preferibilmente invia al server di gestione MS un numero di nk parametri di prestazioni campione SPPi(k) (i= 1, 2, … nk) relativi agli nk pacchetti campione che sono stati identificati alle iterazioni della fase 303 che sono state eseguite durante quel periodo di marcatura. Per esempio, secondo una forma di realizzazione, alla fase 305 ciascun punto di misura MPk preferibilmente invia al server di gestione MS una sequenza di nk timestamp campione STi(k) (i= 1, 2, … nk).

Preferibilmente, ciascun parametro di prestazioni campione STi(k) inviato al server di gestione MS è accompagnato dalla rispettiva porzione del contenuto del pacchetto PCi(k) ed eventualmente dalle altre informazioni di accompagnamento come descritto sopra.

Tutti i parametri di prestazioni cumulativi CC(k)<A>, CC(k)e i parametri di prestazioni campione SPPi(k) con la rispettiva porzione del contenuto del pacchetto PCi(k) ed eventualmente le altre informazioni di accompagnamento come descritto sopra sono ricevute presso il server di gestione MS, che preferibilmente le memorizza nella banca dati DB.

Le fasi 300-305 sono iterate da ciascun punto di misura MPk, fino alla fine della sessione di misura (fase 306).

Quindi, il server di gestione MS può utilizzare le informazioni memorizzare nella banca dati DB per fornire misure di prestazioni relative al flusso di pacchetti multipunto PF e i K flussi di pacchetti punto-punto PF1, PF2, PF3, … PFK compresi nello stesso.

Con riferimento al diagramma di flusso di Figura 4, per fornire una misura di prestazioni sul flusso di pacchetti multipunto PF, il server di gestione MS preferibilmente identifica prima di tutto almeno un cluster di punti di misura tra tutti i punti di misura impiegati nella rete di comunicazioni CN e dai quali esso riceve parametri di prestazioni cumulativi e/o campione (fase 400). Un cluster è preferibilmente definito come un insieme di punti di misura che hanno la proprietà che l’insieme dei pacchetti del flusso multipunto PF ricevuti dal/dai punto/i di misura di ingresso del cluster è lo stesso dell’insieme dei pacchetti del flusso di pacchetti multipunto PF ricevuti presso il/i punto/i di misura di uscita del cluster, se non si è verificata perdita di pacchetti.

Il server di gestione MS può identificare diversi cluster di dimensione diversa, per esempio applicando l’algoritmo descritto da WO 2017/186302 a nome della stessa Richiedente. Tuttavia, sarà apprezzato che i punti di misura MP0, MP1, MP2, MP3, … MPK formano loro stessi un cluster, il cui unico punto di misura di ingresso è MP0 e i cui punti di misura di uscita sono MP1, MP2, MP3, … MPK. Infatti, siccome il flusso di pacchetti multipunto PF è stato definito come l’aggregazione di K flussi di pacchetti punto-punto originati presso il nodo N0 ed indirizzati ai nodi N1, N2, N3, … NK, rispettivamente, è evidente che l’insieme dei pacchetti del flusso di pacchetti multipunto PF ricevuti presso il punto di misura di ingresso MP0 è lo stesso dell’insieme di pacchetti del flusso di pacchetti multipunto PF ricevuti presso i punti di misura di uscita MP1, MP2, MP3, … MPK se non si verifica alcuna perdita di pacchetto.

Dopo di che, il server di gestione MS può fornire una misura di prestazioni cumulativa basata sui parametri di prestazioni cumulativi CC(k)<A>, CC(k)ricevuti dai punti di misura MP0, MP1, MP2, MP3, … MPK del cluster (fase 401).

Ad esempio, se i parametri di prestazioni cumulativi sono contatori CC(k)<A>, CC(k)che contano il numero di pacchetti identificati del flusso di pacchetti PF marcati con MA e MB, alla fase 401 il server di gestione MS può eseguire una misura di perdita di pacchetto cumulativa, ossia una misura del numero di pacchetti del flusso di pacchetti multipunto PF nel suo complesso che sono stati persi durante la trasmissione attraverso il cluster. La perdita di pacchetti cumulativa PLCUM del flusso di pacchetti multipunto PF può essere calcolata per un periodo di marcatura come:

PLCUM= CCUM<in >– CCUM<out >[1]

in cui:

(i) CCUM<in >è la sommatoria degli N contatori forniti dagli N punti di misura di ingresso del cluster alla fine di quel periodo di marcatura, e

(ii) CCUM<out >è la sommatoria degli M contatori forniti dagli M punti di misura di uscita del cluster alla fine di quel periodo di marcatura.

Nello scenario esemplificativo di Figura 1, CCUM<in >è uguale al contatore fornito dall’unico punto di misura di ingresso MP0 (ossia CC(0)<A >o CC(0)), mentre CCUM<out >è uguale alla sommatoria dei contatori forniti dai K punti di misura di uscita MP1, MP2, MP3, … MPK del cluster.

Come altro esempio, se i parametri di prestazioni cumulativi sono i timestamp medi AT(k)<A>, AT(k)che indicano il tempo di ricezione medio di pacchetti identificati del flusso di pacchetti PF marcati con MA e MB, alla fase 401 il server di gestione MS può eseguire una misura di tempo cumulativo, come descritto da WO 2017/186302 a nome della stessa Richiedente.

Le misure di prestazioni cumulative possono essere eseguite dal server di gestione MS sostanzialmente in tempo reale. Questo significa che, quando il server di gestione MS riceve dai punti di misura MP0, MP1, MP2, MP3, … MPK i valori per esempio dei contatori CC(k)<A >(k= 0, 1, 2, 3, … K) relativi ad un certo periodo di marcatura, esso può quindi eseguire un calcolo della perdita di pacchetti per quel periodo di marcatura applicando la precedente equazione [1] immediatamente, o comunque prima di ricevere i contatori CC(k)(k= 0, 1, 2, 3, … K) relativi al prossimo periodo di marcatura. In questo modo, il server di gestione MS può monitorare le prestazioni cumulative del flusso di pacchetti multipunto PF sostanzialmente in tempo reale.

Le misure di perdita di pacchetti cumulative tuttavia forniscono una indicazione complessiva delle prestazioni del flusso di pacchetti multipunto PF nel cluster nel suo insieme. Quindi, se una perdita di pacchetti si verifica durante un periodo di marcatura, la misura di PLCUM non fornisce alcuna indicazione dello specifico flusso di pacchetti punto-punto PF1, PF2, PF3, … PFK nel quale la perdita di pacchetti si è verificata.

Secondo una forma di realizzazione della presente invenzione, fintanto che le misure di prestazioni cumulative forniscono risultati positivi (fase 402), il server di gestione MS può continuare a fornire solo tale tipo di misura.

Se, ad un certo punto, i risultati delle misure di prestazioni cumulative indicano un deterioramento di prestazione, il server di gestione MS preferibilmente fornisce misure di prestazioni punto-punto relative ad almeno uno dei K flussi di pacchetti punto-punto compresi nel flusso di pacchetti multipunto PF (fase 403).

Questo è solo esemplificativo. Le misure di prestazioni punto-punto possono essere eseguite off-line – ossia in qualsiasi momento dopo la ricezione dei parametri di prestazioni cumulativi CC(k)<A>, CC(k)e i parametri di prestazioni campione SPPi(k) dai punti di misura MP0, MP1, MP2, MP3, … MPK- e possono essere innescate da eventi di diverso tipo. Per esempio, l’operatore di rete può decidere di avviare una misura di prestazioni puntopunto relativa ad un flusso di pacchetti punto-punto che trasporta un certo servizio (per esempio un servizio voce) a seguito di un reclamo da parte di un cliente che ha rilevato un peggioramento della sua QoS.

Il diagramma di flusso di Figura 5 mostra in maggior dettaglio la fase 403 di eseguire una misura di prestazioni punto-punto su almeno uno dei K flussi di pacchetti punto-punto compresi nel flusso di pacchetti multipunto PF, secondo una forma di realizzazione della presente invenzione.

Prima di tutto, il server di gestione MS dovrebbe essere fornito con una indicazione del flusso di pacchetti punto-punto PFk* (con k* uguale a qualsiasi tra 1, 2, 3, … K) da sottoporre alla misura di prestazioni puntopunto (fase 500).

Il flusso di pacchetti punto-punto PFk* è definito (e quindi distinguibile dagli altri flussi di pacchetti punto-punto compresi nel flusso di pacchetti multipunto PF) dal/i valore/i di uno o più campi di identificazione diversi da quello utilizzato nella fase 301 per identificare i pacchetti del flusso di pacchetti multipunto PF. Quindi, alla fase 500 il server di gestione MS praticamente riceve (per esempio, dall’operatore di rete) il/i valore/i dell’uno o più campi di identificazione che definisce il flusso di pacchetti punto-punto PFk* da sottoporre a misure di prestazioni punto-punto.

Per esempio, se il flusso di pacchetti multipunto PF è definito da un valore del campo Source Address (ossia, l’indirizzo IP del nodo N0, nello scenario esemplificativo di Figura 1), il flusso di pacchetti punto-punto PFk* può quindi essere definito da un particolare valore del campo Destination Address (ossia, l’indirizzo IP del nodo Nk*, nello scenario esemplificativo di Figura 1). Questo è un esempio molto semplice, non limitativo. Più in generale, il flusso di pacchetti punto-punto PFk* da sottoporre a misure punto-punto può essere definito in base al/i valore/i di qualsiasi campo compreso nella porzione del contenuto del pacchetto PCi(k) che accompagna ciascun parametro di prestazioni campione SPPi(k) inviato da ciascun punto di misura MPk (k= 0, 1, 2, 3, … K) al server di gestione MS (si veda fase 304 in Figura 3 e relativa descrizione di cui sopra).

Quindi, alla fase 501, il server di gestione MS preferibilmente recupera dalla banca dati DB, tra tutti i parametri di prestazioni campione SPPi(k) relativi al flusso di pacchetti PF che sono stati ricevuti dai punti di misura di ingresso e uscita del cluster, quelli che si riferiscono a pacchetti campione del flusso di pacchetti PFk* (fase 501).

A questo scopo, alla fase 501 il server di gestione MS preferibilmente legge nella banca dati DB la porzione del contenuto del pacchetto PCi(k) che accompagna ciascun parametro di prestazioni campione SPPi(k) inviata da ciascun punto di misura MPk e, se essa comprende il/i valore/i di uno o più campi di identificazione che definiscono il flusso di pacchetti punto-punto PFk*, recupera quindi il corrispondente parametro di prestazioni campione SPPi(k). Con riferimento allo scenario di Figura 1, per esempio, l’applicazione della fase 501 fornisce un numero di timestamp campione STi(0) forniti dal punto di misura MP0 per i pacchetti campione del flusso di pacchetti PFk* e un numero di timestamp campione STj(k*) forniti dal punto di misura MPk* per lo stesso pacchetto campione (se non si verifica nessuna perdita di pacchetto). Se l’uno o più campi di identificazione che definisce il flusso di pacchetti punto-punto PFk* sono compresi nel carico utile del pacchetto (come descritto sopra, questa situazione può accadere quando i pacchetti del flusso di pacchetti multipunto PF sono formattati secondo diversi protocolli impilati), il server di gestione MS preferibilmente li legge applicando una tecnica di ispezione profonda dei pacchetti ("deep packet inspection").

Preferibilmente, assieme al parametro di prestazioni campione SPPi(k), alla fase 501 il server di gestione MS recupera inoltre dalla banca dati DB altre informazioni che accompagnano il parametro di prestazioni campione, in particolare un identificativo del pacchetto campione (per esempio, la firma di campionamento SS del pacchetto campione come calcolata alla fase 303 o, almeno, l’hash non utilizzato della firma di campionamento SS, ossia gli Smax-S bit meno significativi della firma di campionamento SS che non sono stati utilizzati per selezionare i pacchetti campione alla fase 303), l’identificativo del punto di misura Mk che fornisce il parametro di prestazioni campione SPPi(k) e l’identificativo del periodo di marcatura Tm durante il quale il pacchetto campione è stato identificato.

Dopo di che, il server di gestione MS può eseguire misure di prestazioni campione sui pacchetti campione del flusso di pacchetti PFk*, in base ai parametri di prestazioni campione relativi al flusso di pacchetti PFk* come forniti dalla fase 501.

Per esempio, con riferimento allo scenario di Figura 1, possono essere fornite misure di temporali campione, in base ai timestamp campione STi(0) forniti dal punto di misura MP0 e ai timestamp campione STj(k*) forniti dal punto di misura MPk*. In particolare, il server di gestione MS può eseguire misure di tempo individuali su ciascun pacchetto campione del flusso di pacchetti PFk*. Per esempio, alla fase 502 il server di gestione MS può calcolare un ritardo monodirezionale OWDi dal nodo N0 al nodo Nk* per ciascun pacchetto campione di PFk* applicando la seguente equazione:

OWDi= STj(k*) - STi(0) [2]

dove i e j sono indici campione che indicano lo stesso pacchetto campione come identificato dal punto di misura MP0 e dal punto di misura MPk*, rispettivamente.

Preferibilmente, per identificare timestamp campione forniti da diversi punti di misura per lo stesso pacchetto campione, il server di gestione MS può usare l’hash non utilizzato della firma di campionamento SS calcolata per il pacchetto campione che, come descritto sopra, è inviato al server di gestione MS e memorizzato nella banca dati DB assieme ai parametri di prestazioni campione SPPi(k) relativi a ciascun pacchetto campione. A questo scopo, può essere utilizzata la tecnica descritta da WO 2018/072828 a nome della stessa Richiedente.

Inoltre o alternativamente alle misure di tempo relative ai pacchetti campione del flusso di pacchetti punto-punto PFk*, possono anche essere effettuate misure di perdita di pacchetti. A differenza dalle misure di perdita di pacchetti cumulative che possono essere eseguite alla fase 401, tuttavia, le misure di perdita di pacchetti relative al flusso di pacchetti punto-punto PFk* sono statistiche, ossia esse sono calcolate unicamente sui pacchetti campione, e non su tutti i pacchetti del flusso di pacchetti punto-punto PFk*. Pertanto, vantaggiosamente, elaborando le porzioni di contenuto CPi(k) dei pacchetti campione ricevuti dai punti di misura MP1, MP2, MP3, … MPK (a titolo di esempio non limitativo, l’intestazione dei pacchetti campione), il server di gestione MS può, in qualsiasi momento, fornire per esempio un misura di prestazioni off-line o a posteriori sui pacchetti campione di qualsiasi dei K flussi di pacchetti punto-punto PF1, PF2, PF3, … PFK compresi nel flusso di pacchetti multipunto PF. Avendo a sua disposizione le porzioni di contenuto CPi(k) dei pacchetti campione, infatti, il server di gestione MS può applicare un filtraggio off-line in base a uno o più campi della porzione del contenuto del pacchetto CPi(k), estrapolando in tal modo - tra tutti i parametri di prestazione campione SPPi(k) relativi ai pacchetti campione del flusso di pacchetti multipunto PF – solo quelli che riguardano uno specifico flusso di pacchetti punto-punto compreso nel flusso di pacchetti multipunto PF.

Tale filtraggio off-line può essere eseguito per ciascuno dei sotto-flussi di pacchetti (ossia, i K flussi di pacchetti punto-punto PF1, PF2, PF3, … PFK nello scenario esemplificativo descritto) che formano il flusso di pacchetti multipunto PF, modificando in modo opportuno i criteri di filtraggio. La granularità dell’analisi punto-punto può essere quella desiderata, a condizione che la porzione del contenuto dei pacchetti CPi(k) comprenda le informazioni necessarie per fornire un filtro adatto. In uno scenario dove diversi servizi trasportati da rispettivi flussi di pacchetti punto-punto sono presenti, per esempio, l’operatore di rete ha vantaggiosamente la capacità di ottenere misure di prestazioni separate per ciascun servizio fornito, con la granularità desiderata.

A tal riguardo, si deve notare che l’uso della firma di campionamento di hash SS in combinazione con le proprietà del cluster garantisce che un pacchetto campione identificato da qualsiasi punto di misura di ingresso del cluster sia ricevuto e correttamente identificato come pacchetto campione anche da un punto di misura di uscita del cluster e quindi che i parametri di prestazioni forniti al server di gestione siano coerenti tra loro. Il server di gestione MS ha quindi a sua disposizione una banca dati DB di parametri di prestazioni campione SPPi(k) commensurabile e coerente, che il server di gestione MS può sottoporre a filtraggio off-line come descritto sopra per estrapolare misure di prestazioni per qualsiasi flusso di pacchetti punto-punto PF1, PF2, PF3, … PFK desiderato.

Inoltre, vantaggiosamente, non è necessario implementare filtri costosi e complessi presso i punti di misura MP0, MP1, MP2, MP3, …, MPK della rete di comunicazioni CN. I punti di misura MP0, MP1, MP2, MP3, …, MPK infatti identificano in modo cumulativo i pacchetti che formano il flusso di pacchetti multipunto PF, cosa che è effettuata alla fase 301 usando un filtro molto semplice, ad esempio in base ad un singolo campo dell’intestazione H del pacchetto. I filtri più complessi che consentono l’identificazione dei parametri di prestazioni campione SPPi(k) relativi a pacchetti campione di qualsiasi sotto-flusso di pacchetti desiderato sono invece applicati dal server di gestione MS che pertanto ha in carico la maggior parte del carico computazionale necessario per identificare i singoli sotto-flussi di pacchetti. Anche se sopra è stato fatto riferimento all’elaborazione off-line o a posteriori dei parametri di prestazioni campione SPPi(k), tale elaborazione può anche essere eseguita in tempo quasi reale, vale a dire immediatamente dopo la ricezione dei parametri di prestazioni campione SPPi(k) presso il server di gestione MS, in modo da fornire misure in tempo quasi reale sui sotto-flussi desiderati.

Secondo altre varianti, il server di gestione MS può raccogliere dai vari punti di misura i parametri di prestazioni campione sul flusso di pacchetti multipunto PF con le relative informazioni come descritto sopra e semplicemente memorizzarli nella banca dati DB. Quindi, in qualsiasi momento, il server di gestione MS può utilizzare i dati memorizzati per fornire analisi statistiche del flusso di pacchetti multipunto PF, non solo dal punto di vista delle prestazioni, ma anche da altri punti di vista come tracciare i vari sotto-flussi di pacchetti, determinare la composizione del flusso di pacchetti multipunto PF per quanto riguarda il tipo di servizi trasportati (per esempio video, chiamate, ecc.) e così via.

Inoltre, ai fini della presente invenzione si deve notare che associare a ciascun parametro di prestazioni campione SPPi(k) la rispettiva porzione di contenuto del pacchetto campione PCi(k) e inviarli al server di gestione MS è considerato equivalente ad associare a ciascun parametro di prestazioni campione SPPi(k) dati che sono ottenuti applicando una funzione biiettiva al contenuto del pacchetto campione PCi(k) e inviare questi dati al server di gestione MS.

Claims

RIVENDICAZIONI 1. Un metodo per eseguire una misura di prestazioni in una rete di comunicazioni (CN), detto metodo comprendendo, presso ciascun punto di misura (MPk) di un numero di punti di misura (MP10, MP1, MP2, MP3, … MPK) implementati in detta rete di comunicazioni (CN): a) identificare pacchetti di un flusso di pacchetti multipunto (PF); b) tra detti pacchetti identificati di detto flusso di pacchetti multipunto (PF) selezionare un numero di pacchetti campione, detta selezione essendo basata sul valore di una firma di campionamento (SS) calcolata applicando una funzione di hash ad una predeterminata maschera di bit in ciascun pacchetto identificato; c) per ciascun pacchetto campione, fornire ad un server di gestione (MS) un parametro di prestazioni campione (SPPi(k)) e almeno una porzione del contenuto del pacchetto (PCi(k)); detto metodo comprendendo inoltre, presso detto server di gestione (MS): d) tra detto numero di punti di misura (MP0, MP1, MP2, MP3, …, MPK), identificare un cluster di punti di misura in cui, se non si verifica alcuna perdita di pacchetti, ciascun pacchetto identificato di detto flusso di pacchetti multipunto (PF) ricevuto da un punto di misura di ingresso (MP0) di detto cluster è ricevuto anche presso un punto di misura di uscita (MP1, MP2, MP3, …, MPK) di detto cluster; e) tra i parametri di prestazioni campione forniti dai punti di misura del cluster, identificare parametri di prestazioni campione relativi a pacchetti campione che appartengono ad un sotto-flusso di pacchetti (PFk*) compreso in detto flusso di pacchetti multipunto (PF), in base a detta almeno una porzione di detto contenuto del pacchetto (PCi(k));e f) eseguire detta misura di prestazioni su detto sotto-flusso di pacchetti (PFk*), in base a detti parametri di prestazioni campione identificati.
2. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui detti pacchetti di detto flusso di pacchetti multipunto (PF) sono marcati prima di essere iniettati in detta rete di comunicazioni (CN), detta marcatura comprendendo impostare il valore di un campo di marcatura (MF) compreso in ciascun pacchetto di detto flusso di pacchetti multipunto (PF) ad uno di almeno due valori di marcatura alternativi (MA, MB) e ciclicamente commutare detto valore di detto campo di marcatura (MF) con un periodo di marcatura Tm.
3. Il metodo secondo la rivendicazione 1 o 2, in cui alla fase c) detta almeno una porzione di contenuto del pacchetto comprende almeno una porzione dell’intestazione del pacchetto che comprende almeno un campo di identificazione di detto sotto-flusso di pacchetti (PFk*), diverso da uno o più campi di identificazione utilizzati nella fase a) per identificare detto flusso di pacchetti multipunto (PF).
4. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui alla fase c) detta almeno una porzione del contenuto del pacchetto comprende almeno una porzione del carico utile del pacchetto comprendente almeno un campo di identificazione di detto sotto-flusso di pacchetti (PFk*), diverso da uno o più campi di identificazione utilizzati nella fase a) per identificare detto flusso di pacchetti multipunto (PF).
5. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui esso comprende inoltre, alla ricezione di detto parametro di prestazioni campione (SPPi(k)) e detta almeno una porzione del contenuto del pacchetto presso detto server di gestione (MS), memorizzare detto parametro di prestazioni campione (SPPi(k)) e detta almeno una porzione del contenuto del pacchetto in una banca dati(DB).
6. Il metodo secondo la rivendicazione 5, in cui le fasi d), e) e f) sono eseguite off-line dopo detta memorizzazione, al verificarsi di un evento rilevato da detto server di gestione (MS).
7. Il metodo secondo la rivendicazione 5 o 6, in cui alla fase e) detto identificare detti parametri di prestazioni campione relativi a pacchetti campione che appartengono a detto sotto-flusso di pacchetti (PFk*) comprende: - determinare almeno un campo di identificazione compreso in detta almeno una porzione del contenuto del pacchetto (PCi(k)) il cui valore identifica detto sotto-flusso di pacchetti (PFk*); - leggere in detta banca dati (DB) l’almeno una porzione del contenuto del pacchetto (PCi(k)) che accompagna ciascun parametro di prestazioni campione (SPPi(k)) memorizzato e, se comprende detto valore che identifica detto sotto-flusso di pacchetti (PFk*) in detto almeno un campo di identificazione, recuperare il corrispondente parametro di prestazioni campione (SPPi(k)) da detta banca dati (DB).
8. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui: - la fase c) comprende, per ciascun pacchetto campione, fornire a detto server di gestione (MS) anche un identificativo di detto pacchetto campione, e - la fase f) comprende, in base a detti identificatori, identificare i parametri di prestazioni campione relativi ad uno stesso pacchetto campione e forniti da diversi punti di misura (MP0, MP1, MP2, MP3, … MPK) di detto cluster.
9. Il metodo secondo una qualsiasi delle rivendicazioni precedenti, in cui esso comprende inoltre, dopo la fase a), aggiornare un parametro di prestazioni cumulativo (CPP(k)<A>, CPP(k)) indicativo del comportamento del flusso di pacchetti multipunto (PF) nel suo insieme e in cui la fase f) comprende anche fornire una misura di prestazioni cumulativa in base a detti parametri di prestazioni cumulativi (CC(k)<A>, CC(k)) ricevuti dai punti di misura (MP0, MP1, MP2, MP3, … MPK) di detto cluster.
10. Il metodo secondo la rivendicazione 9, in cui dette misure di prestazioni cumulative sono eseguite da detto server di gestione (MS) sostanzialmente in tempo reale.
11. Un sistema per eseguire una misura di prestazioni in una rete di comunicazioni, il sistema comprendendo un numero di punti di misura (MP10, MP1, MP2, MP3, … MPK) implementati in detta rete di comunicazioni (CN) e un server di gestione (MS), in cui ciascun punto di misura (MPk) è configurato per: a) identificare pacchetti di un flusso di pacchetti multipunto (PF); b) tra detti pacchetti identificati del flusso di pacchetti multipunto (PF), selezionare un numero di pacchetti campione, detta selezione essendo basata su un valore di una firma di campionamento (SS) calcolata applicando una funzione di hash ad una predeterminata maschera di bit in ciascun pacchetto identificato; c) per ciascun pacchetto campione, fornire a detto server di gestione (MS) un parametro di prestazioni campione (SPPi(k)) e almeno una porzione del contenuto del pacchetto; ed in cui detto server di gestione (MS) è configurato per: d) tra detto numero di punti di misura (MP0, MP1, MP2, MP3, … MPK), identificare un cluster di punti di misura in cui, se non si verifica alcuna perdita di pacchetti, ciascun pacchetto identificato di detto flusso di pacchetti multipunto (PF) ricevuto presso un punto di misura di ingresso (MP0) di detto cluster è anche ricevuto presso un punto di misura di uscita (MP1, MP2, MP3, … MPK) di detto cluster; e) tra i parametri di prestazione campione forniti dai punti di misura del cluster, identificare parametri di prestazioni campione relativi a pacchetti campione che appartengono ad un sotto-flusso di pacchetti (PFk*) compreso in detto flusso di pacchetti multipunto (PF), in base a detta almeno una porzione di detto contenuto del pacchetto; e f) eseguire detta misura di prestazioni su detto sotto-flusso di pacchetti (PFk*), sulla base di detti parametri di prestazioni campione identificati.