1. Panoramica di LDP

L'architettura MPLS [RFC3031] definisce un protocollo di distribuzione delle etichette (label distribution protocol) come un insieme di procedure mediante le quali un router a commutazione di etichette (Label Switched Router, LSR) informa un altro del significato delle etichette usate per inoltrare il traffico tra loro e attraverso di essi.

L'architettura MPLS non presuppone un unico protocollo di distribuzione delle etichette. In effetti, sono in corso di standardizzazione diversi protocolli di distribuzione delle etichette. I protocolli esistenti sono stati estesi in modo che la distribuzione delle etichette possa essere trasportata al loro interno. Sono stati inoltre definiti nuovi protocolli allo scopo esplicito di distribuire etichette. L'architettura MPLS discute alcune delle considerazioni relative alla scelta di un protocollo di distribuzione delle etichette da usare in particolari applicazioni MPLS, come l'ingegneria del traffico (Traffic Engineering) [RFC2702].

Il protocollo di distribuzione delle etichette (Label Distribution Protocol, LDP) è un protocollo definito per distribuire etichette. È stato originariamente pubblicato come RFC 3036 nel gennaio 2001. È stato prodotto dal gruppo di lavoro MPLS dell'IETF ed è stato scritto congiuntamente da Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette e Bob Thomas.

LDP è un protocollo definito per distribuire etichette. È l'insieme delle procedure e dei messaggi mediante i quali i router a commutazione di etichette (Label Switched Router, LSR) stabiliscono percorsi a commutazione di etichette (Label Switched Path, LSP) attraverso una rete, mappando direttamente le informazioni di instradamento del livello di rete su percorsi commutati del livello di collegamento dati. Tali LSP possono avere un estremo presso un vicino direttamente collegato (paragonabile all'inoltro IP hop-by-hop), oppure possono avere un estremo presso un nodo di uscita della rete, consentendo la commutazione attraverso tutti i nodi intermedi.

LDP associa una classe di equivalenza di inoltro (Forwarding Equivalence Class, FEC) [RFC3031] a ciascun LSP che crea. La FEC associata a un LSP specifica quali pacchetti sono "mappati" su quel LSP. Gli LSP vengono estesi attraverso una rete man mano che ciascun LSR "giunziona" le etichette in ingresso di una FEC all'etichetta in uscita assegnata al next hop per la data FEC.

Maggiori informazioni sull'applicabilità di LDP sono disponibili in [RFC3037].

Il presente documento presuppone (ma non richiede) la familiarità con l'architettura MPLS [RFC3031]. Si noti che la [RFC3031] include un glossario della terminologia MPLS, come ingress, label switched path, ecc.

1.1. Peer LDP

Due LSR che usano LDP per scambiare informazioni di mappatura etichetta/FEC sono noti come "LDP Peer" rispetto a tali informazioni, e si parla dell'esistenza di una "LDP Session" tra di essi. Una singola sessione LDP consente a ciascun peer di apprendere le mappature di etichette dell'altro; vale a dire, il protocollo è bidirezionale.

1.2. Scambio di messaggi LDP

Esistono quattro categorie di messaggi LDP:

1. Messaggi di discovery, usati per annunciare e mantenere la presenza di un LSR in una rete.

2. Messaggi di sessione, usati per stabilire, mantenere e terminare le sessioni tra peer LDP.

3. Messaggi di advertisement, usati per creare, modificare ed eliminare mappature di etichette per le FEC.

4. Messaggi di notifica, usati per fornire informazioni indicative e per segnalare informazioni di errore.

I messaggi di discovery forniscono un meccanismo mediante il quale gli LSR indicano la loro presenza in una rete inviando periodicamente un messaggio Hello. Questo viene trasmesso come pacchetto UDP alla porta LDP all'indirizzo multicast di gruppo 'all routers on this subnet'. Quando un LSR sceglie di stabilire una sessione con un altro LSR appreso tramite il messaggio Hello, utilizza la procedura di inizializzazione LDP sul trasporto TCP. Al completamento con successo della procedura di inizializzazione, i due LSR sono peer LDP e possono scambiare messaggi di advertisement.

Quando richiedere un'etichetta o pubblicizzare una mappatura di etichette a un peer è in gran parte una decisione locale presa da un LSR. In generale, l'LSR richiede una mappatura di etichette da un LSR vicino quando ne ha bisogno, e pubblicizza una mappatura di etichette a un LSR vicino quando desidera che il vicino usi un'etichetta.

Il corretto funzionamento di LDP richiede una consegna affidabile e in ordine dei messaggi. Per soddisfare tali requisiti, LDP usa il trasporto TCP per i messaggi di sessione, advertisement e notifica, cioè per tutto tranne il meccanismo di discovery basato su UDP.

1.3. Struttura dei messaggi LDP

Tutti i messaggi LDP hanno una struttura comune che usa uno schema di codifica tipo-lunghezza-valore (Type-Length-Value, TLV); vedere la sezione "Type-Length-Value Encoding". La parte Value di un oggetto codificato come TLV, o TLV in breve, può essa stessa contenere uno o più TLV.

1.4. Gestione degli errori LDP

Gli errori LDP e altri eventi di interesse sono segnalati a un peer LDP mediante messaggi di notifica.

Esistono due tipi di messaggi di notifica LDP:

1. Notifiche di errore, usate per segnalare errori fatali. Se un LSR riceve una notifica di errore da un peer per una sessione LDP, termina la sessione LDP chiudendo la connessione di trasporto TCP per la sessione e scartando tutte le mappature di etichette apprese tramite la sessione.

2. Notifiche indicative, usate per trasmettere informazioni sull'LSR relative alla sessione LDP o sullo stato di qualche messaggio precedente ricevuto dal peer.

1.5. Estensibilità e compatibilità futura di LDP

Funzionalità potranno essere aggiunte a LDP in futuro. È probabile che le funzionalità future utilizzino nuovi messaggi e nuovi tipi di oggetto (TLV). Può essere desiderabile impiegare tali nuovi messaggi e TLV all'interno di una rete che usa implementazioni più vecchie che non li riconoscono. Sebbene non sia possibile rendere ogni miglioramento futuro retrocompatibile, una certa pianificazione preventiva può agevolare l'introduzione di nuove capacità. La presente specifica definisce regole per la gestione di tipi di messaggio sconosciuti e TLV sconosciuti a questo scopo.

1.6. Linguaggio della specifica

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" nel presente documento devono essere interpretate come descritto nella [RFC2119].