Passa al contenuto principale

6. Aree per studi futuri

I seguenti argomenti non trattati in questa versione di LDP sono possibili aree per studi futuri:

  • La sezione 2.16 dell'architettura MPLS [RFC3031] richiede che la negoziazione iniziale del protocollo di distribuzione delle etichette tra LSR peer consenta a ciascun LSR di determinare se il proprio peer è in grado di estrarre la pila di etichette. Questa versione di LDP presuppone che gli LSR supportino l'estrazione delle etichette per tutti i tipi di collegamento tranne ATM e Frame Relay. Una versione futura potrà specificare mezzi per rendere questa determinazione parte della negoziazione di avvio della sessione.

  • Il supporto LDP per CoS (Class of Service) non è specificato in questa versione. Il supporto CoS potrà essere affrontato in una versione futura.

  • Il supporto LDP per il multicast non è specificato in questa versione. Il supporto multicast potrà essere affrontato in una versione futura.

  • Il supporto LDP per la commutazione di etichette multipath non è specificato in questa versione. Il supporto multipath potrà essere affrontato in una versione futura.

  • Il supporto LDP per la segnalazione dell'unità di trasmissione massima non è specificato in questa versione. È discusso nel documento sperimentale [LDP-MTU].

  • La specifica attuale non affronta la scoperta di base dei peer su supporti Non-Broadcast Multi-Access (NBMA). La soluzione disponibile nella specifica attuale consiste nell'usare la scoperta estesa dei peer in tali configurazioni. La questione di definire un meccanismo semanticamente simile alla scoperta di base (limite di 1 hop, associare l'adiacenza hello a un'interfaccia) che usi indirizzi di vicini preconfigurati è lasciata a ulteriori studi.

  • La specifica attuale non supporta la disattivazione di un'adiacenza. La motivazione per farlo e i meccanismi per ottenerlo sono lasciati a ulteriori studi.

  • La specifica attuale non include un metodo per proteggere i messaggi Hello, per rilevare lo spoofing dei messaggi Hello. Gli scenari in cui ciò è necessario, nonché il meccanismo per ottenerlo, sono lasciati a studi futuri.

  • La specifica attuale non ha la capacità di rilevare un riavvio del piano di controllo veloce e senza stato. Il metodo per ottenerlo, possibilmente tramite un numero di "incarnation/instance" trasportato nel messaggio Hello, è lasciato a studi futuri.

  • La specifica attuale non supporta un messaggio di "end of LIB", analogo al messaggio "end of RIB" di BGP che un LSR LDP (che opera in modalità DU) userebbe dopo l'instaurazione della sessione. La discussione sulla necessità di un tale meccanismo e sulla sua implementazione è lasciata a studi futuri.

  • La specifica attuale non affronta situazioni in cui LSR diversi pubblicizzano lo stesso indirizzo. Tali situazioni si verificano tipicamente come risultato di errori di configurazione, e l'obiettivo in questo caso è fornire agli LSR che pubblicizzano lo stesso indirizzo informazioni sufficienti per consentire agli operatori di adottare azioni correttive. La specifica di questo meccanismo è lasciata a un documento separato.