2. Funzionamento di LDP

2.1. FEC

È necessario specificare con precisione quali pacchetti possono essere mappati su ciascun LSP. Ciò si ottiene fornendo una specifica FEC per ciascun LSP. La FEC identifica l'insieme dei pacchetti IP che possono essere mappati su quell'LSP.

Ciascuna FEC è specificata come un insieme di uno o più FEC element. Ciascun FEC element identifica un insieme di pacchetti che possono essere mappati sul corrispondente LSP. Quando un LSP è condiviso da più FEC element, quell'LSP viene terminato presso (o prima de) il nodo in cui i FEC element non possono più condividere lo stesso percorso.

Questa specifica definisce un unico tipo di FEC element, l'"Address Prefix FEC element". Questo elemento è un prefisso di indirizzo di qualsiasi lunghezza da 0 a un indirizzo completo, inclusi gli estremi.

Altri FEC element possono essere definiti, secondo necessità, da altre specifiche.

Nel resto di questa sezione forniamo le regole da usare per mappare i pacchetti sugli LSP che sono stati configurati usando un Address Prefix FEC element.

Diciamo che un particolare indirizzo "corrisponde" a un particolare prefisso di indirizzo se e solo se quell'indirizzo inizia con quel prefisso. Diciamo inoltre che un particolare pacchetto corrisponde a un particolare LSP se e solo se quell'LSP ha un Address Prefix FEC element che corrisponde all'indirizzo di destinazione del pacchetto. Rispetto a un particolare pacchetto e a un particolare LSP, chiamiamo "matching prefix" qualsiasi Address Prefix FEC element che corrisponde al pacchetto.

La procedura per mappare un particolare pacchetto su un particolare LSP usa le seguenti regole. Ciascuna regola viene applicata in sequenza finché il pacchetto può essere mappato su un LSP.

• Se un pacchetto corrisponde esattamente a un LSP, il pacchetto è mappato su quell'LSP.

• Se un pacchetto corrisponde a più LSP, è mappato sull'LSP il cui matching prefix è il più lungo. Se non vi è un unico LSP il cui matching prefix sia il più lungo, il pacchetto è mappato su uno dell'insieme di LSP il cui matching prefix è più lungo degli altri. La procedura per selezionare uno di tali LSP esula dallo scopo del presente documento.

• Se è noto che un pacchetto deve attraversare un particolare router egress, e esiste un LSP che ha un Address Prefix FEC element che è un indirizzo /32 di quel router, allora il pacchetto è mappato su quell'LSP. La procedura per ottenere questa conoscenza esula dallo scopo del presente documento.

La procedura per determinare che un pacchetto deve attraversare un particolare router egress esula dallo scopo del presente documento. (Ad esempio, se si esegue un algoritmo di instradamento link state, può essere possibile ottenere questa informazione dal database link state. Come altro esempio, se si esegue BGP, può essere possibile ottenere questa informazione dall'attributo BGP next hop della rotta del pacchetto.)

2.2. Spazi di etichette, identificatori, sessioni e trasporto

2.2.1. Spazi di etichette

La nozione di "spazio di etichette" (label space) è utile per discutere l'assegnazione e la distribuzione delle etichette. Esistono due tipi di spazi di etichette:

• Spazio di etichette per interfaccia. Le etichette in ingresso specifiche dell'interfaccia sono usate per interfacce che usano risorse dell'interfaccia per le etichette. Un esempio di tale interfaccia è un'interfaccia ATM controllata da etichette che usa i VCI (Virtual Channel Identifier) come etichette, oppure un'interfaccia Frame Relay che usa i DLCI (Data Link Connection Identifier) come etichette.

  Si noti che l'uso di uno spazio di etichette per interfaccia ha senso solo quando i peer LDP sono "direttamente collegati" su un'interfaccia e l'etichetta sarà usata solo per il traffico inviato su quell'interfaccia.

• Spazio di etichette per piattaforma. Le etichette in ingresso valide per l'intera piattaforma sono usate per interfacce che possono condividere le stesse etichette.

2.2.2. LDP Identifier

Un LDP Identifier è una quantità di sei ottetti usata per identificare uno spazio di etichette di un LSR. I primi quattro ottetti identificano l'LSR e devono essere un valore globalmente univoco, come un router Id a 32 bit assegnato all'LSR. Gli ultimi due ottetti identificano uno specifico spazio di etichette all'interno dell'LSR. Gli ultimi due ottetti degli LDP Identifier per spazi di etichette validi per l'intera piattaforma sono sempre entrambi zero. Il presente documento usa la seguente rappresentazione stampata per gli LDP Identifier:

  <LSR Id> : <label space id>

ad esempio, lsr171:0, lsr19:2.

Si noti che un LSR che gestisce e pubblicizza più spazi di etichette usa un LDP Identifier diverso per ciascuno di tali spazi di etichette.

Una situazione in cui un LSR dovrebbe pubblicizzare più di uno spazio di etichette a un peer e quindi usare più di un LDP Identifier si verifica quando l'LSR ha due collegamenti verso il peer ed entrambi sono ATM (e usano etichette per interfaccia). Un'altra situazione sarebbe quella in cui l'LSR ha due collegamenti verso il peer, uno dei quali è Ethernet (e usa etichette per piattaforma) e l'altro è ATM.

2.2.3. Sessioni LDP

Esistono sessioni LDP tra LSR per supportare lo scambio di etichette tra di essi.

Quando un LSR usa LDP per pubblicizzare più di uno spazio di etichette a un altro LSR, usa una sessione LDP separata per ciascuno spazio di etichette.

2.2.4. Trasporto LDP

LDP usa TCP come trasporto affidabile per le sessioni.

Quando sono necessarie più sessioni LDP tra due LSR, vi è una sessione TCP per ciascuna sessione LDP.

2.3. Sessioni LDP tra LSR non direttamente collegati

Le sessioni LDP tra LSR che non sono direttamente collegati a livello di collegamento possono essere desiderabili in alcune situazioni.

Ad esempio, si consideri un'applicazione di "ingegneria del traffico" in cui LSRa invia traffico che soddisfa alcuni criteri tramite un LSP a LSRb non direttamente collegato, invece di inoltrare il traffico lungo il suo percorso normalmente instradato.

Il percorso tra LSRa e LSRb includerebbe uno o più LSR intermedi (LSR1,...LSRn). Una sessione LDP tra LSRa e LSRb consentirebbe a LSRb di commutare le etichette del traffico che arriva sull'LSP da LSRa, fornendo a LSRb i mezzi per pubblicizzare etichette a questo scopo a LSRa.

In questa situazione, LSRa applicherebbe due etichette al traffico che inoltra sull'LSP a LSRb: un'etichetta appresa da LSR1 per inoltrare il traffico lungo il percorso dell'LSP da LSRa a LSRb; e un'etichetta appresa da LSRb per consentire a LSRb di commutare le etichette del traffico che arriva sull'LSP.

LSRa aggiunge innanzitutto alla pila di etichette del pacchetto l'etichetta appresa tramite la sua sessione LDP con LSRb (sostituendo con essa l'etichetta in cima alla pila di etichette del pacchetto se il pacchetto arriva etichettato, oppure inserendola se il pacchetto arriva non etichettato). Poi inserisce nella pila di etichette l'etichetta per l'LSP appresa da LSR1.

2.4. LDP Discovery

LDP discovery è un meccanismo che consente a un LSR di scoprire potenziali peer LDP. La discovery rende non necessario configurare esplicitamente i peer di commutazione di etichette di un LSR.

Esistono due varianti del meccanismo di discovery:

• Un meccanismo di Basic Discovery usato per scoprire vicini LSR direttamente collegati a livello di collegamento.

• Un meccanismo di Extended Discovery usato per individuare LSR non direttamente collegati a livello di collegamento.

2.4.1. Meccanismo di Basic Discovery

Per avviare la LDP Basic Discovery su un'interfaccia, un LSR invia periodicamente LDP Link Hello su quell'interfaccia. Gli LDP Link Hello sono inviati come pacchetti UDP indirizzati alla porta di discovery LDP nota, all'indirizzo multicast di gruppo "all routers on this subnet".

Un LDP Link Hello inviato da un LSR trasporta l'LDP Identifier per lo spazio di etichette che l'LSR intende usare per l'interfaccia e possibilmente informazioni aggiuntive.

La ricezione di un LDP Link Hello su un'interfaccia identifica una "Hello adjacency" con un potenziale peer LDP raggiungibile a livello di collegamento su quell'interfaccia, nonché lo spazio di etichette che il peer intende usare per l'interfaccia.

2.4.2. Meccanismo di Extended Discovery

Le sessioni LDP tra LSR non direttamente collegati sono supportate dalla LDP Extended Discovery.

Per avviare la LDP Extended Discovery, un LSR invia periodicamente LDP Targeted Hello a un indirizzo specifico. Gli LDP Targeted Hello sono inviati come pacchetti UDP indirizzati alla porta di discovery LDP nota, all'indirizzo specifico.

Un LDP Targeted Hello inviato da un LSR trasporta l'LDP Identifier per lo spazio di etichette che l'LSR intende usare e possibilmente informazioni opzionali aggiuntive.

La Extended Discovery differisce dalla Basic Discovery nei seguenti modi:

• Un Targeted Hello è inviato a un indirizzo specifico anziché all'indirizzo multicast di gruppo "all routers" per l'interfaccia in uscita.

• A differenza della Basic Discovery, che è simmetrica, la Extended Discovery è asimmetrica.

  Un LSR avvia la Extended Discovery con un altro LSR target, e l'LSR target decide se rispondere o ignorare il Targeted Hello. Un LSR target che sceglie di rispondere lo fa inviando periodicamente Targeted Hello all'LSR che ha avviato la procedura.

La ricezione di un LDP Targeted Hello identifica una "Hello adjacency" con un potenziale peer LDP raggiungibile a livello di rete e lo spazio di etichette che il peer intende usare.

2.5. Instaurazione e mantenimento delle sessioni LDP

2.5.1. Instaurazione della sessione LDP

Lo scambio di LDP Discovery Hello tra due LSR innesca l'instaurazione della sessione LDP. L'instaurazione della sessione è un processo in due fasi:

• Instaurazione della connessione di trasporto
• Inizializzazione della sessione

Quanto segue descrive l'instaurazione di una sessione LDP tra gli LSR LSR1 e LSR2 dal punto di vista di LSR1. Si presuppone lo scambio di Hello che specificano lo spazio di etichette LSR1:a per LSR1 e lo spazio di etichette LSR2:b per LSR2.

2.5.2. Instaurazione della connessione di trasporto

Lo scambio di Hello determina la creazione di una Hello adjacency presso LSR1 che serve ad associare il collegamento (L) e gli spazi di etichette LSR1:a e LSR2:b.

1. Se LSR1 non ha già una sessione LDP per lo scambio degli spazi di etichette LSR1:a e LSR2:b, tenta di aprire una connessione TCP per una nuova sessione LDP con LSR2.

   LSR1 determina gli indirizzi di trasporto da usare alla propria estremità (A1) e all'estremità di LSR2 (A2) della connessione TCP LDP. L'indirizzo A1 è determinato come segue:

   a. Se LSR1 usa l'oggetto opzionale Transport Address (TLV) negli Hello che invia a LSR2 per pubblicizzare un indirizzo, A1 è l'indirizzo che LSR1 pubblicizza tramite l'oggetto opzionale;

   b. Se LSR1 non usa l'oggetto opzionale Transport Address, A1 è l'indirizzo sorgente usato negli Hello che invia a LSR2.

   Analogamente, l'indirizzo A2 è determinato come segue:

   a. Se LSR2 usa l'oggetto opzionale Transport Address, A2 è l'indirizzo che LSR2 pubblicizza tramite l'oggetto opzionale;

   b. Se LSR2 non usa l'oggetto opzionale Transport Address, A2 è l'indirizzo sorgente negli Hello ricevuti da LSR2.

2. LSR1 determina se svolgerà il ruolo attivo o passivo nell'instaurazione della sessione confrontando gli indirizzi A1 e A2 come interi senza segno. Se A1 > A2, LSR1 svolge il ruolo attivo; altrimenti è passivo.

   La procedura per confrontare A1 e A2 come interi senza segno è:

   • Se A1 e A2 non appartengono alla stessa address family, sono incomparabili e non può essere instaurata alcuna sessione.

   • Sia U1 l'intero senza segno astratto ottenuto trattando A1 come una sequenza di byte, dove il byte che compare per primo nel messaggio è il byte più significativo dell'intero e il byte che compare per ultimo nel messaggio è il byte meno significativo dell'intero.

     Sia U2 l'intero senza segno astratto ottenuto da A2 in modo analogo.

   • Confronta U1 con U2. Se U1 > U2, allora A1 > A2; se U1 < U2, allora A1 < A2.

3. Se LSR1 è attivo, tenta di stabilire la connessione TCP LDP collegandosi alla porta LDP nota all'indirizzo A2. Se LSR1 è passivo, attende che LSR2 stabilisca la connessione TCP LDP verso la propria porta LDP nota.

Si noti che, quando un LSR invia un Hello, seleziona l'indirizzo di trasporto per la propria estremità della connessione di sessione e usa l'Hello per pubblicizzare l'indirizzo, esplicitamente includendolo in un TLV Transport Address opzionale oppure implicitamente omettendo il TLV e usando tale indirizzo come indirizzo sorgente dell'Hello.

Un LSR DEVE (MUST) pubblicizzare lo stesso indirizzo di trasporto in tutti gli Hello che pubblicizzano lo stesso spazio di etichette. Questo requisito garantisce che due LSR collegati da più Hello adjacency che usano gli stessi spazi di etichette svolgano lo stesso ruolo nell'instaurazione della connessione per ciascuna adiacenza.

2.5.3. Inizializzazione della sessione

Dopo che LSR1 e LSR2 hanno stabilito una connessione di trasporto, negoziano i parametri di sessione scambiandosi messaggi LDP Initialization. I parametri negoziati comprendono la versione del protocollo LDP, il metodo di distribuzione delle etichette, i valori dei timer, gli intervalli VPI/VCI (Virtual Path Identifier / Virtual Channel Identifier) per ATM controllato da etichette, gli intervalli DLCI (Data Link Connection Identifier) per Frame Relay controllato da etichette, ecc.

La negoziazione riuscita completa l'instaurazione di una sessione LDP tra LSR1 e LSR2 per la pubblicizzazione degli spazi di etichette LSR1:a e LSR2:b.

Quanto segue descrive l'inizializzazione della sessione dal punto di vista di LSR1.

Dopo che la connessione è stata stabilita, se LSR1 svolge il ruolo attivo, avvia la negoziazione dei parametri di sessione inviando un messaggio Initialization a LSR2. Se LSR1 è passivo, attende che LSR2 avvii la negoziazione dei parametri.

In generale, quando vi sono più collegamenti tra LSR1 e LSR2 e più spazi di etichette da pubblicizzare da ciascuno, l'LSR passivo non può sapere quale spazio di etichette pubblicizzare su una connessione TCP appena stabilita finché non riceve il messaggio LDP Initialization sulla connessione. Il messaggio Initialization trasporta sia l'LDP Identifier per lo spazio di etichette del mittente (LSR attivo) sia l'LDP Identifier per lo spazio di etichette del destinatario (LSR passivo).

Attendendo il messaggio Initialization dal proprio peer, l'LSR passivo può far corrispondere lo spazio di etichette che il peer deve pubblicizzare (come determinato dall'LDP Identifier nell'intestazione della PDU del messaggio Initialization) con una Hello adjacency creata in precedenza al momento dello scambio di Hello.

1. Quando LSR1 svolge il ruolo passivo:

   a. Se LSR1 riceve un messaggio Initialization, tenta di far corrispondere l'LDP Identifier trasportato dalla PDU del messaggio con una Hello adjacency.

   b. Se esiste una Hello adjacency corrispondente, l'adiacenza specifica lo spazio di etichette locale per la sessione.

   Poi LSR1 verifica se i parametri di sessione proposti nel messaggio sono accettabili. Se lo sono, LSR1 risponde con un proprio messaggio Initialization per proporre i parametri che desidera usare e con un messaggio KeepAlive per segnalare l'accettazione dei parametri di LSR2. Se i parametri non sono accettabili, LSR1 risponde inviando un messaggio Notification Session Rejected/Parameters Error e chiudendo la connessione TCP.

   c. Se LSR1 non riesce a trovare una Hello adjacency corrispondente, invia un messaggio Notification Session Rejected/No Hello Error e chiude la connessione TCP.

   d. Se LSR1 riceve un KeepAlive in risposta al proprio messaggio Initialization, la sessione è operativa dal punto di vista di LSR1.

   e. Se LSR1 riceve un messaggio Error Notification, LSR2 ha rifiutato la sessione proposta e LSR1 chiude la connessione TCP.

2. Quando LSR1 svolge il ruolo attivo:

   a. Se LSR1 riceve un messaggio Error Notification, LSR2 ha rifiutato la sessione proposta e LSR1 chiude la connessione TCP.

   b. Se LSR1 riceve un messaggio Initialization, verifica se i parametri di sessione sono accettabili. In tal caso, risponde con un messaggio KeepAlive. Se i parametri di sessione non sono accettabili, LSR1 invia un messaggio Notification Session Rejected/Parameters Error e chiude la connessione.

   c. Se LSR1 riceve un messaggio KeepAlive, LSR2 ha accettato i parametri di sessione proposti.

   d. Quando LSR1 ha ricevuto sia un messaggio Initialization accettabile sia un messaggio KeepAlive, la sessione è operativa dal punto di vista di LSR1.

   Finché la sessione LDP non è instaurata, non possono essere scambiati altri messaggi oltre a quelli elencati nelle procedure precedenti, e le regole per l'elaborazione del bit U nei messaggi LDP sono sostituite. Se viene ricevuto un messaggio diverso da quelli elencati nelle procedure precedenti, DEVE (MUST) essere trasmesso un messaggio Shutdown e la connessione di trasporto DEVE (MUST) essere chiusa.

È possibile che una coppia di LSR configurati in modo incompatibile, che non concordano sui parametri di sessione, si impegni in una sequenza infinita di messaggi, poiché ciascuno risponde NAK ai messaggi Initialization dell'altro con messaggi Error Notification.

Un LSR DEVE (MUST) limitare i propri tentativi di ripetizione dell'instaurazione della sessione con un backoff esponenziale nelle situazioni in cui i messaggi Initialization ricevono una risposta NAK. Si raccomanda inoltre che un LSR che rileva tale situazione intraprenda azioni per avvisare un operatore.

Il tentativo di instaurazione della sessione successivo a un messaggio Initialization che ha ricevuto NAK DEVE (MUST) essere ritardato di non meno di 15 secondi, e i ritardi successivi DEVONO (MUST) crescere fino a un ritardo massimo non inferiore a 2 minuti. L'azione specifica di instaurazione della sessione che deve essere ritardata è il tentativo di aprire la connessione di trasporto della sessione da parte dell'LSR che svolge il ruolo attivo.

La sequenza limitata di NAK agli Initialization difficilmente cesserà finché un intervento dell'operatore non riconfigura uno degli LSR. Dopo tale azione di configurazione, non vi è più necessità di limitare i tentativi successivi di instaurazione della sessione (finché i loro messaggi Initialization non ricevono NAK).

A causa della natura asimmetrica dell'instaurazione della sessione, la riconfigurazione dell'LSR passivo passerà inosservata all'LSR attivo senza qualche ulteriore azione. La sezione "Hello Message" descrive un meccanismo opzionale che un LSR può usare per segnalare a potenziali peer LDP di essere stato riconfigurato.

2.5.4. Macchina a stati dell'inizializzazione

È conveniente descrivere il comportamento della negoziazione della sessione LDP in termini di macchina a stati. Definiamo la macchina a stati LDP come dotata di cinque possibili stati e presentiamo il comportamento come tabella di transizione di stato e come diagramma di transizione di stato. Si noti che un messaggio Shutdown è implementato come un messaggio Notification con un TLV Status che indica un errore fatale.

        Session Initialization State Transition Table

STATE EVENT NEW STATE

NON EXISTENT Session TCP connection established INITIALIZED established

INITIALIZED Transmit Initialization msg OPENSENT (Active Role)

          Receive acceptable                  OPENREC
                Initialization msg
                (Passive Role)
            Action: Transmit Initialization
                    msg and KeepAlive msg

          Receive Any other LDP msg           NON EXISTENT
            Action: Transmit Error Notification msg
                    (NAK) and close transport connection

OPENREC Receive KeepAlive msg OPERATIONAL

          Receive Any other LDP msg           NON EXISTENT
            Action: Transmit Error Notification msg
                    (NAK) and close transport connection

OPENSENT Receive acceptable OPENREC Initialization msg Action: Transmit KeepAlive msg

          Receive Any other LDP msg           NON EXISTENT
            Action: Transmit Error Notification msg
                    (NAK) and close transport connection

OPERATIONAL Receive Shutdown msg NON EXISTENT Action: Transmit Shutdown msg and close transport connection

          Receive other LDP msgs              OPERATIONAL
          Timeout                             NON EXISTENT
            Action: Transmit Shutdown msg and
                    close transport connection

       Session Initialization State Transition Diagram

                           +------------+
                           |            |
             +------------>|NON EXISTENT|<--------------------+
             |             |            |                     |
             |             +------------+                     |
             | Session        |    ^                          |
             |   connection   |    |                          |
             |   established  |    | Rx any LDP msg except    |
             |                V    |   Init msg or Timeout    |
             |            +-----------+                       |
Rx Any other |            |           |                       |
   msg or    |            |INITIALIZED|                       |
   Timeout / |        +---|           |-+                     |
Tx NAK msg   |        |   +-----------+ |                     |
             |        | (Passive Role)  | (Active Role)       |
             |        | Rx Acceptable   | Tx Init msg         |
             |        |    Init msg /   |                     |
             |        | Tx Init msg     |                     |
             |        |    Tx KeepAlive |                     |
             |        V    msg          V                     |
             |   +-------+        +--------+                  |
             |   |       |        |        |                  |
             +---|OPENREC|        |OPENSENT|----------------->|
             +---|       |        |        | Rx Any other msg |
             |   +-------+        +--------+    or Timeout    |
Rx KeepAlive |        ^                |     Tx NAK msg       |
   msg       |        |                |                      |
             |        |                | Rx Acceptable        |
             |        |                |    Init msg /        |
             |        +----------------+ Tx KeepAlive msg     |
             |                                                |
             |      +-----------+                             |
             +----->|           |                             |
                    |OPERATIONAL|                             |
                    |           |---------------------------->+
                    +-----------+     Rx Shutdown msg
             All other  |   ^            or Timeout /
               LDP msgs |   |         Tx Shutdown msg
                        |   |
                        +---+

2.5.5. Mantenimento delle Hello adjacency

Una sessione LDP con un peer ha una o più Hello adjacency.

Una sessione LDP ha più Hello adjacency quando una coppia di LSR è collegata da più collegamenti che condividono lo stesso spazio di etichette; ad esempio, più collegamenti PPP tra una coppia di router. In questa situazione, gli Hello che un LSR invia su ciascuno di tali collegamenti trasportano lo stesso LDP Identifier.

LDP include meccanismi per monitorare la necessità di una sessione LDP e delle sue Hello adjacency.

LDP usa la ricezione regolare degli LDP Discovery Hello per indicare l'intenzione di un peer di usare lo spazio di etichette identificato dall'Hello. Un LSR mantiene un hold timer con ciascuna Hello adjacency, che riavvia quando riceve un Hello che corrisponde all'adiacenza. Se il timer scade senza la ricezione di un Hello corrispondente dal peer, LDP conclude che il peer non desidera più commutare etichette usando quello spazio di etichette per quel collegamento (o target, nel caso dei Targeted Hello), oppure che il peer ha avuto un guasto. L'LSR elimina quindi la Hello adjacency. Quando l'ultima Hello adjacency di una sessione LDP viene eliminata, l'LSR termina la sessione LDP inviando un messaggio Notification e chiudendo la connessione di trasporto.

2.5.6. Mantenimento delle sessioni LDP

LDP include meccanismi per monitorare l'integrità della sessione LDP.

LDP usa la ricezione regolare di PDU LDP sulla connessione di trasporto della sessione per monitorare l'integrità della sessione. Un LSR mantiene un KeepAlive Timer per ciascuna sessione con un peer, che reimposta ogni volta che riceve una PDU LDP dal peer della sessione. Se il KeepAlive Timer scade senza la ricezione di una PDU LDP dal peer, l'LSR conclude che la connessione di trasporto è difettosa o che il peer ha avuto un guasto, e termina la sessione LDP chiudendo la connessione di trasporto.

Dopo che una sessione LDP è stata instaurata, un LSR deve fare in modo che il proprio peer riceva da esso una PDU LDP almeno ogni periodo KeepAlive time, per garantire che il peer riavvii il KeepAlive Timer della sessione. L'LSR può inviare qualsiasi messaggio del protocollo per soddisfare questo requisito. Nelle circostanze in cui un LSR non ha altre informazioni da comunicare al proprio peer, invia un messaggio KeepAlive.

Un LSR può scegliere di terminare una sessione LDP con un peer in qualsiasi momento. Se sceglie di farlo, informa il peer con un messaggio Shutdown.

2.6. Distribuzione e gestione delle etichette

L'architettura MPLS [RFC3031] consente a un LSR di distribuire un'associazione di etichette per una FEC in risposta a una richiesta esplicita di un altro LSR. Ciò è noto come distribuzione di etichette Downstream On Demand. Consente inoltre a un LSR di distribuire associazioni di etichette a LSR che non le hanno richieste esplicitamente. La [RFC3031] chiama questo metodo di distribuzione delle etichette Unsolicited Downstream; il presente documento usa il termine Downstream Unsolicited.

Entrambe queste tecniche di distribuzione delle etichette possono essere usate nella stessa rete contemporaneamente. Tuttavia, per una data sessione LDP, ciascun LSR deve essere consapevole del metodo di distribuzione delle etichette usato dal proprio peer, per evitare situazioni in cui un peer che usa la distribuzione di etichette Downstream Unsolicited presuma che anche il proprio peer la usi. Vedere la sezione "Downstream on Demand Label Advertisement".

2.6.1. Modalità di controllo della distribuzione delle etichette

Il comportamento della configurazione iniziale degli LSP è determinato dal fatto che l'LSR operi con controllo LSP indipendente o ordinato. Un LSR può supportare entrambi i tipi di controllo come opzione configurabile.

2.6.1.1. Controllo indipendente della distribuzione delle etichette

Quando si usa il controllo LSP indipendente, ciascun LSR può pubblicizzare mappature di etichette ai propri vicini in qualsiasi momento lo desideri. Ad esempio, quando opera in modalità Downstream on Demand indipendente, un LSR può rispondere immediatamente alle richieste di mappature di etichette, senza attendere una mappatura di etichette dal next hop. Quando opera in modalità Downstream Unsolicited indipendente, un LSR può pubblicizzare una mappatura di etichette per una FEC ai propri vicini ogni volta che è pronto a commutare le etichette per quella FEC.

Una conseguenza dell'uso della modalità indipendente è che un'etichetta a monte può essere pubblicizzata prima che venga ricevuta un'etichetta a valle.

2.6.1.2. Controllo ordinato della distribuzione delle etichette

Quando si usa il controllo LSP ordinato, un LSR può avviare la trasmissione di una mappatura di etichette solo per una FEC per cui dispone di una mappatura di etichette per il next hop della FEC, oppure per cui l'LSR è l'egress. Per ciascuna FEC per cui l'LSR non è l'egress e non esiste alcuna mappatura, l'LSR DEVE (MUST) attendere che venga ricevuta un'etichetta da un LSR a valle prima di mappare la FEC e passare le etichette corrispondenti agli LSR a monte. Un LSR può essere l'egress per alcune FEC e un non-egress per altre.

Un LSR può agire come LSR egress, rispetto a una particolare FEC, in ognuna delle seguenti condizioni:

1. La FEC si riferisce all'LSR stesso (incluse una delle sue interfacce direttamente collegate).

2. Il router di next hop per la FEC è all'esterno della Label Switching Network.

3. I FEC element sono raggiungibili attraversando un confine di dominio di instradamento, come un'altra area per le reti OSPF summary, oppure un altro sistema autonomo per gli OSPF AS external e le rotte BGP [RFC2328] [RFC4271].

Si noti che il fatto che un LSR sia un egress per una data FEC può cambiare nel tempo, a seconda dello stato della rete e delle impostazioni di configurazione dell'LSR.

2.6.2. Modalità di conservazione delle etichette

L'architettura MPLS [RFC3031] introduce la nozione di modalità di conservazione delle etichette (label retention mode), che specifica se un LSR mantiene un'associazione di etichette per una FEC appresa da un vicino che non è il suo next hop per la FEC.

2.6.2.1. Modalità di conservazione conservativa delle etichette

In modalità di advertisement Downstream Unsolicited, gli advertisement di mappatura di etichette per tutte le rotte possono essere ricevuti da tutti gli LSR peer. Quando si usa la conservazione conservativa (Conservative Label retention), gli advertisement di mappatura di etichette ricevuti vengono mantenuti solo se saranno usati per inoltrare pacchetti (cioè se sono ricevuti da un next hop valido in base all'instradamento). Se si opera in modalità Downstream on Demand, un LSR richiederà mappature di etichette solo all'LSR di next hop in base all'instradamento. Poiché la modalità Downstream on Demand è usata principalmente quando si desidera la conservazione delle etichette (ad esempio, uno switch ATM con spazio di cross connect limitato), essa è tipicamente usata con la modalità di conservazione conservativa delle etichette.

Il vantaggio principale della modalità conservativa è che vengono allocate e mantenute solo le etichette necessarie per l'inoltro dei dati. Ciò è particolarmente importante negli LSR in cui lo spazio di etichette è intrinsecamente limitato, come in uno switch ATM. Uno svantaggio della modalità conservativa è che, se l'instradamento cambia il next hop per una data destinazione, deve essere ottenuta una nuova etichetta dal nuovo next hop prima che i pacchetti etichettati possano essere inoltrati.

2.6.2.2. Modalità di conservazione liberale delle etichette

In modalità di advertisement Downstream Unsolicited, gli advertisement di mappatura di etichette per tutte le rotte possono essere ricevuti da tutti i peer LDP. Quando si usa la conservazione liberale (Liberal Label retention), ogni mappatura di etichette ricevuta da un LSR peer viene mantenuta indipendentemente dal fatto che l'LSR sia il next hop per la mappatura pubblicizzata. Quando si opera in modalità Downstream on Demand con conservazione liberale delle etichette, un LSR potrebbe scegliere di richiedere mappature di etichette per tutti i prefissi noti a tutti gli LSR peer. Si noti, tuttavia, che la modalità Downstream on Demand è tipicamente usata da dispositivi come gli LSR basati su switch ATM, per i quali è raccomandato l'approccio conservativo.

Il vantaggio principale della modalità di conservazione liberale delle etichette è che la reazione ai cambiamenti di instradamento può essere rapida, perché le etichette esistono già. Lo svantaggio principale della modalità liberale è che mappature di etichette non necessarie vengono distribuite e mantenute.

2.6.3. Modalità di advertisement delle etichette

Ciascuna interfaccia di un LSR è configurata per operare in modalità di advertisement Downstream Unsolicited o Downstream on Demand. Gli LSR si scambiano le modalità di advertisement durante l'inizializzazione. La differenza principale tra le modalità Downstream Unsolicited e Downstream on Demand sta in quale LSR si assume la responsabilità di avviare le richieste di mapping e gli advertisement di mapping.

2.7. LDP Identifier e indirizzi di next hop

Un LSR mantiene le etichette apprese in una Label Information Base (LIB). Quando opera in modalità Downstream Unsolicited, la voce LIB per un prefisso di indirizzo associa al prefisso una raccolta di coppie (LDP Identifier, label), una coppia di questo tipo per ciascun peer che pubblicizza un'etichetta per il prefisso.

Quando il next hop per un prefisso cambia, l'LSR deve recuperare dalla LIB l'etichetta pubblicizzata dal nuovo next hop per usarla nell'inoltro. Per recuperare l'etichetta, l'LSR deve essere in grado di mappare l'indirizzo di next hop del prefisso su un LDP Identifier.

Analogamente, quando l'LSR apprende un'etichetta per un prefisso da un peer LDP, deve essere in grado di determinare se quel peer è attualmente un next hop per il prefisso, per determinare se deve iniziare a usare l'etichetta appena appresa nell'inoltro dei pacchetti che corrispondono al prefisso. Per prendere tale decisione, l'LSR deve essere in grado di mappare un LDP Identifier sugli indirizzi del peer, per verificare se qualcuno di essi è un next hop per il prefisso.

Per consentire agli LSR di mappare tra un LDP Identifier di un peer e gli indirizzi del peer, gli LSR pubblicizzano i propri indirizzi usando messaggi LDP Address e Withdraw Address.

Un LSR invia un messaggio Address per pubblicizzare i propri indirizzi a un peer. Un LSR invia un messaggio Withdraw Address per ritirare indirizzi precedentemente pubblicizzati da un peer.

2.8. Rilevamento dei loop

Il rilevamento dei loop (Loop Detection) è un'opzione configurabile che fornisce un meccanismo per individuare gli LSP in loop e per impedire che i messaggi Label Request entrino in loop in presenza di LSR non capaci di merge.

Il meccanismo fa uso dei TLV Path Vector e Hop Count trasportati dai messaggi Label Request e Label Mapping. Si basa sulle seguenti proprietà di base di questi TLV:

• Un TLV Path Vector contiene un elenco degli LSR attraversati dal messaggio che lo contiene. Un LSR è identificato in un elenco Path Vector dal suo LSR Identifier (Id) univoco, che è costituito dai primi quattro ottetti del suo LDP Identifier. Quando un LSR propaga un messaggio contenente un TLV Path Vector, aggiunge il proprio LSR Id all'elenco Path Vector. Un LSR che riceve un messaggio con un Path Vector che contiene il proprio LSR Id rileva che il messaggio ha attraversato un loop. LDP supporta la nozione di lunghezza massima consentita del Path Vector; un LSR che rileva che un Path Vector ha raggiunto la lunghezza massima si comporta come se il messaggio che lo contiene avesse attraversato un loop.

• Un TLV Hop Count contiene un conteggio degli LSR attraversati dal messaggio che lo contiene. Quando un LSR propaga un messaggio contenente un TLV Hop Count, incrementa il conteggio. Un LSR che rileva che un Hop Count ha raggiunto un valore massimo configurato si comporta come se il messaggio che lo contiene avesse attraversato un loop. Per convenzione, un conteggio di 0 è interpretato come hop count sconosciuto. L'incremento di un valore di hop count sconosciuto dà come risultato un valore di hop count sconosciuto (0).

I paragrafi seguenti descrivono le procedure di LDP Loop Detection. Per questi paragrafi, e solo per questi paragrafi, "MUST" è ridefinito per significare "MUST if configured for Loop Detection". I paragrafi specificano i messaggi che DEVONO (MUST) trasportare i TLV Path Vector e Hop Count. Si noti che il TLV Hop Count e le sue procedure sono usati senza il TLV Path Vector nelle situazioni in cui il rilevamento dei loop non è configurato (vedere [RFC3035] e [RFC3034]).

2.8.1. Messaggio Label Request

L'uso del TLV Path Vector e del TLV Hop Count impedisce ai messaggi Label Request di entrare in loop in ambienti che includono LSR non capaci di merge.

Le regole che disciplinano l'uso del TLV Hop Count nei messaggi Label Request da parte dell'LSR R quando il rilevamento dei loop è abilitato sono le seguenti:

• Il messaggio Label Request DEVE (MUST) includere un TLV Hop Count.

• Se R invia il Label Request perché è un FEC ingress, DEVE (MUST) includere un TLV Hop Count con valore di hop count 1.

• Se R invia il Label Request in seguito alla ricezione di un Label Request da un LSR a monte, e se il Label Request ricevuto contiene un TLV Hop Count, R DEVE (MUST) incrementare di 1 il valore di hop count ricevuto e DEVE (MUST) passare il valore risultante in un TLV Hop Count al proprio next hop insieme al messaggio Label Request.

Le regole che disciplinano l'uso del TLV Path Vector nei messaggi Label Request da parte dell'LSR R quando il rilevamento dei loop è abilitato sono le seguenti:

• Se R invia il Label Request perché è un FEC ingress, allora se R non è capace di merge, DEVE (MUST) includere un TLV Path Vector di lunghezza 1 contenente il proprio LSR Id.

• Se R invia il Label Request in seguito alla ricezione di un Label Request da un LSR a monte, allora se il Label Request ricevuto contiene un TLV Path Vector oppure se R non è capace di merge:

  R DEVE (MUST) aggiungere il proprio LSR Id al Path Vector e DEVE (MUST) passare il Path Vector risultante al proprio next hop insieme al messaggio Label Request. Se il Label Request non contiene alcun TLV Path Vector, R DEVE (MUST) includere un TLV Path Vector di lunghezza 1 contenente il proprio LSR Id.

Si noti che, se R riceve un messaggio Label Request per una particolare FEC, e R ha precedentemente inviato un messaggio Label Request per quella FEC al proprio next hop e non ha ancora ricevuto una risposta, e se R intende fondere (merge) il Label Request appena ricevuto con il Label Request esistente in sospeso, allora R non propaga il Label Request al next hop.

Se R riceve un messaggio Label Request dal proprio next hop con un TLV Hop Count che supera il valore massimo configurato, oppure con un TLV Path Vector che contiene il proprio LSR Id o che supera la lunghezza massima consentita, allora R rileva che il messaggio Label Request ha viaggiato in un loop.

Quando R rileva un loop, DEVE (MUST) inviare un messaggio Notification Loop Detected alla sorgente del messaggio Label Request e scartare il messaggio Label Request.

2.8.2. Messaggio Label Mapping

L'uso del TLV Path Vector e del TLV Hop Count nel messaggio Label Mapping fornisce un meccanismo per individuare e terminare gli LSP in loop. Quando un LSR riceve un messaggio Label Mapping da un next hop, il messaggio è propagato a monte come specificato di seguito finché non si raggiunge un LSR ingress o non viene trovato un loop.

Le regole che disciplinano l'uso del TLV Hop Count nei messaggi Label Mapping inviati da un LSR R quando il rilevamento dei loop è abilitato sono le seguenti:

• R DEVE (MUST) includere un TLV Hop Count.

• Se R è l'egress, il valore di hop count DEVE (MUST) essere 1.

• Se il messaggio Label Mapping viene inviato per propagare a un peer a monte un messaggio Label Mapping ricevuto dal next hop, il valore di hop count DEVE (MUST) essere determinato come segue:

  o Se R è un membro dell'edge set di un dominio LSR i cui LSR non effettuano il 'TTL-decrement' (ad esempio, un dominio LSR ATM o un dominio LSR Frame Relay) e il peer a monte è all'interno di quel dominio, R DEVE (MUST) reimpostare l'hop count a 1 prima di propagare il messaggio.

  o In caso contrario, R DEVE (MUST) incrementare l'hop count ricevuto dal next hop prima di propagare il messaggio.

• Se il messaggio Label Mapping non viene inviato per propagare un messaggio Label Mapping, il valore di hop count DEVE (MUST) essere il risultato dell'incremento della conoscenza corrente di R dell'hop count appresa dai precedenti messaggi Label Mapping. Si noti che questo valore di hop count sarà sconosciuto se R non ha ricevuto un messaggio Label Mapping dal next hop.

Qualsiasi messaggio Label Mapping PUÒ (MAY) contenere un TLV Path Vector. Le regole che disciplinano l'uso obbligatorio del TLV Path Vector nei messaggi Label Mapping inviati dall'LSR R quando il rilevamento dei loop è abilitato sono le seguenti:

• Se R è l'egress, il messaggio Label Mapping non deve includere un TLV Path Vector.

• Se R invia il messaggio Label Mapping per propagare a un peer a monte un messaggio Label Mapping ricevuto dal next hop, allora:

  o Se R è capace di merge e se R non ha precedentemente inviato un messaggio Label Mapping al peer a monte, allora DEVE (MUST) includere un TLV Path Vector.

  o Se il messaggio ricevuto contiene un hop count sconosciuto, allora R DEVE (MUST) includere un TLV Path Vector.

  o Se R ha precedentemente inviato un messaggio Label Mapping al peer a monte, allora DEVE (MUST) includere un TLV Path Vector se il messaggio ricevuto segnala un aumento dell'hop count dell'LSP, un cambiamento dell'hop count da sconosciuto a noto, oppure un cambiamento da noto a sconosciuto.

Se le regole precedenti richiedono che R includa un TLV Path Vector nel messaggio Label Mapping, R lo calcola come segue:

o Se il messaggio Label Mapping ricevuto includeva un Path Vector, il Path Vector inviato a monte DEVE (MUST) essere il risultato dell'aggiunta dell'LSR Id di R al Path Vector ricevuto.

o Se il messaggio ricevuto non aveva alcun Path Vector, il Path Vector inviato a monte DEVE (MUST) essere un Path Vector di lunghezza 1 contenente l'LSR Id di R.

• Se il messaggio Label Mapping non viene inviato per propagare a monte un messaggio ricevuto, il messaggio Label Mapping DEVE (MUST) includere un Path Vector di lunghezza 1 contenente l'LSR Id di R.

  Se R riceve un messaggio Label Mapping dal proprio next hop con un TLV Hop Count che supera il valore massimo configurato, oppure con un TLV Path Vector che contiene il proprio LSR Id o che supera la lunghezza massima consentita, allora R rileva che il corrispondente LSP contiene un loop.

  Quando R rileva un loop, DEVE (MUST) smettere di usare l'etichetta per l'inoltro, scartare il messaggio Label Mapping e segnalare lo stato Loop Detected alla sorgente del messaggio Label Mapping.

2.8.3. Discussione

Se si desidera il rilevamento dei loop in un dominio MPLS, allora dovrebbe essere abilitato in TUTTI gli LSR all'interno di quel dominio MPLS, altrimenti il rilevamento dei loop non funzionerà correttamente e può dar luogo a loop non rilevati o a loop rilevati erroneamente.

Non ci si aspetta che gli LSR configurati per il rilevamento dei loop memorizzino i Path Vector come parte dello stato dell'LSP.

Si noti che in una rete in cui sono presenti solo LSR non capaci di merge, i Path Vector sono passati a valle dall'ingress all'egress e non sono passati a monte. Anche quando il merge è supportato, i Path Vector non devono essere passati a monte lungo un LSP che è noto raggiungere l'egress. Quando un LSR subisce un cambiamento di next hop, deve passare i Path Vector a monte solo quando non può dedurre dall'hop count che il cambiamento di next hop non dà luogo a un loop.

Nel caso della distribuzione ordinata delle etichette, i messaggi Label Mapping sono propagati dall'egress verso l'ingress, creando naturalmente il Path Vector lungo il percorso. Nel caso della distribuzione indipendente delle etichette, un LSR può originare un messaggio Label Mapping per una FEC prima di ricevere dal proprio peer a valle un messaggio Label Mapping per quella FEC. In questo caso, il successivo messaggio Label Mapping per la FEC ricevuto dal peer a valle è trattato come un aggiornamento degli attributi dell'LSP, e il messaggio Label Mapping deve essere propagato a monte. Pertanto, si raccomanda di configurare il rilevamento dei loop in combinazione con la distribuzione ordinata delle etichette, per minimizzare il numero di messaggi di aggiornamento Label Mapping.

2.9. Autenticità e integrità dei messaggi LDP

Questa sezione specifica un meccanismo per proteggersi dall'introduzione di segmenti TCP falsificati nei flussi di connessione delle sessioni LDP. L'uso di questo meccanismo DEVE (MUST) essere supportato come opzione configurabile.

Il meccanismo si basa sull'uso della TCP MD5 Signature Option specificata nella [RFC2385] per l'uso da parte di BGP [RFC4271]. Vedere la [RFC1321] per una specifica della funzione di hash MD5. Dal punto di vista della maturità degli standard, il presente documento si rapporta alla [RFC2385] allo stesso modo in cui la [RFC4271] si rapporta alla [RFC2385]. Ciò è spiegato nella [RFC4278].

2.9.1. TCP MD5 Signature Option

Le seguenti citazioni dalla [RFC2385] delineano le proprietà di sicurezza ottenute usando la TCP MD5 Signature Option e riassumono il suo funzionamento:

"IESG Note

  This document describes current existing practice for securing
  BGP against certain simple attacks.  It is understood to have
  security weaknesses against concerted attacks."

"Abstract

  This memo describes a TCP extension to enhance security for
  BGP.  It defines a new TCP option for carrying an MD5 [RFC1321]
  digest in a TCP segment.  This digest acts like a signature for
  that segment, incorporating information known only to the
  connection end points.  Since BGP uses TCP as its transport,
  using this option in the way described in this paper
  significantly reduces the danger from certain security attacks
  on BGP."

"Introduction

  The primary motivation for this option is to allow BGP to
  protect itself against the introduction of spoofed TCP segments
  into the connection stream.  Of particular concern are TCP
  resets.

  To spoof a connection using the scheme described in this paper,
  an attacker would not only have to guess TCP sequence numbers,
  but would also have had to obtain the password included in the
  MD5 digest.  This password never appears in the connection
  stream, and the actual form of the password is up to the
  application.  It could even change during the lifetime of a
  particular connection so long as this change was synchronized
  on both ends (although retransmission can become problematical
  in some TCP implementations with changing passwords).

  Finally, there is no negotiation for the use of this option in
  a connection, rather it is purely a matter of site policy
  whether or not its connections use the option."

"MD5 as a Hashing Algorithm

  Since this memo was first issued (under a different title), the
  MD5 algorithm has been found to be vulnerable to collision
  search attacks [Dobb], and is considered by some to be
  insufficiently strong for this type of application.

  This memo still specifies the MD5 algorithm, however, since the
  option has already been deployed operationally, and there was
  no "algorithm type" field defined to allow an upgrade using the
  same option number.  The original document did not specify a
  type field since this would require at least one more byte, and
  it was felt at the time that taking 19 bytes for the complete
  option (which would probably be padded to 20 bytes in TCP
  implementations) would be too much of a waste of the already
  limited option space.

  This does not prevent the deployment of another similar option
  which uses another hashing algorithm (like SHA-1).  Also, if
  most implementations pad the 18 byte option as defined to 20
  bytes anyway, it would be just as well to define a new option
  which contains an algorithm type field.

  This would need to be addressed in another document, however."

End of quotes from [RFC2385].

2.9.2. Uso della TCP MD5 Signature Option da parte di LDP

LDP usa la TCP MD5 Signature Option come segue:

• L'uso della MD5 Signature Option per le connessioni TCP LDP è un'opzione configurabile dell'LSR.

• Un LSR che usa la MD5 Signature Option è configurato con una password (shared secret) per ciascun potenziale peer LDP.

• L'LSR applica l'algoritmo MD5 come specificato nella [RFC2385] per calcolare il digest MD5 di un segmento TCP da inviare a un peer. Questo calcolo fa uso sia della password del peer sia del segmento TCP.

• Quando l'LSR riceve un segmento TCP con un digest MD5, convalida il segmento calcolando il digest MD5 (usando la propria registrazione della password) e confronta il digest calcolato con quello ricevuto. Se il confronto fallisce, il segmento viene scartato senza alcuna risposta al mittente.

• L'LSR ignora gli LDP Hello provenienti da qualsiasi LSR per il quale non sia stata configurata una password. Ciò garantisce che l'LSR stabilisca connessioni TCP LDP solo con gli LSR per i quali è stata configurata una password.

2.10. Distribuzione delle etichette per LSP instradati esplicitamente

Si prevede che l'ingegneria del traffico (Traffic Engineering) [RFC2702] sarà un'applicazione MPLS importante. Il supporto MPLS per l'ingegneria del traffico usa LSP instradati esplicitamente, che non devono seguire percorsi normalmente instradati (hop-by-hop) come determinato dai protocolli di instradamento basati sulla destinazione. CR-LDP [CRLDP] definisce estensioni a LDP per usare LDP allo scopo di configurare LSP instradati esplicitamente.