RFC 3209 - RSVP-TE: Estensioni a RSVP per Tunnel LSP
- Stato: Proposed Standard
- Pubblicato: December 2001
- Stream: IETF
- Errata: Nessun errata
Sommario (Abstract)
Questo documento descrive l'uso del protocollo di prenotazione delle risorse (RSVP) per stabilire percorsi a commutazione di etichetta (LSP) nelle reti MPLS (Multiprotocol Label Switching). Gli LSP stabiliti utilizzando RSVP possono essere utilizzati con o senza capacità di instradamento esplicito. Quando viene utilizzato l'instradamento esplicito, RSVP-TE consente l'istanziazione di LSP che differiscono dal percorso più breve calcolato dal protocollo di instradamento del livello di rete. Questa capacità è fondamentale per l'ingegneria del traffico e per fornire servizi differenziati.
1. Introduzione (Introduction)
Il Multiprotocol Label Switching (MPLS) [2] è una tecnologia che combina l'inoltro a commutazione di etichetta con l'instradamento del livello di rete. Un'applicazione fondamentale di MPLS è l'ingegneria del traffico (TE) [3]. L'ingegneria del traffico consente agli operatori di rete di controllare il percorso del traffico attraverso la rete per ottimizzare l'utilizzo delle risorse e le prestazioni della rete.
Per supportare l'ingegneria del traffico MPLS, è necessario un meccanismo per stabilire e mantenere i percorsi a commutazione di etichetta (LSP). RSVP [1] è un protocollo di segnalazione maturo che è stato esteso per supportare la creazione di LSP. Questo documento definisce le estensioni a RSVP per supportare la creazione di LSP MPLS, in particolare per le applicazioni di ingegneria del traffico.
Le estensioni definite in questo documento consentono di utilizzare RSVP per:
- Stabilire LSP instradati esplicitamente.
- Reinstradare gli LSP utilizzando il metodo "make-before-break" (stabilire prima di interrompere).
- Supportare il rilevamento dei loop LSP.
- Supportare la distribuzione delle etichette durante il processo di creazione dell'LSP.
2. Terminologia (Terminology)
Questo documento utilizza la terminologia definita nella RFC 3031 [2] e nella RFC 2205 [1]. Inoltre, vengono utilizzati i seguenti termini:
- Tunnel LSP (LSP Tunnel): Un tunnel stabilito da un percorso a commutazione di etichetta in una rete MPLS.
- LSP ID: Un identificatore utilizzato per identificare un particolare LSP.
- Tunnel ID: Un identificatore utilizzato per identificare un tunnel di ingegneria del traffico, che può contenere uno o più LSP.
- Extended Tunnel ID: Un identificatore utilizzato per identificare in modo univoco un tunnel a livello globale.
3. Panoramica delle estensioni RSVP (Overview of RSVP Extensions)
Il protocollo RSVP stabilisce e mantiene lo stato di prenotazione delle risorse tramite i messaggi Path e Resv. Per supportare i tunnel LSP, sono stati introdotti diversi nuovi oggetti:
- Oggetto LABEL_REQUEST: Trasportato nei messaggi Path, richiede l'assegnazione di un'etichetta ai nodi a valle.
- Oggetto LABEL: Trasportato nei messaggi Resv, distribuisce l'etichetta assegnata ai nodi a monte.
- Oggetto EXPLICIT_ROUTE (ERO): Trasportato nei messaggi Path, specifica il percorso esplicito che l'LSP deve seguire.
- Oggetto RECORD_ROUTE (RRO): Trasportato nei messaggi Path e Resv, registra il percorso effettivo e le etichette prese dall'LSP.
- Oggetto SESSION_ATTRIBUTE: Trasportato nei messaggi Path, controlla gli attributi dell'LSP come priorità, prelazione e affinità.
4. Definizioni degli oggetti (Object Definitions)
4.1. Oggetto LABEL
L'oggetto LABEL viene utilizzato per trasportare l'etichetta assegnata nei messaggi Resv.
Class = 16, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. Oggetto LABEL_REQUEST
L'oggetto LABEL_REQUEST viene utilizzato per richiedere un'associazione di etichetta nei messaggi Path.
Class = 19, C_Type = 1 (Senza intervallo di etichette)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L3PID identifica il protocollo di livello 3 trasportato su questo percorso (generalmente Ethertype).
4.3. Oggetto EXPLICIT_ROUTE (ERO)
L'ERO viene utilizzato per specificare percorsi espliciti. Contiene una serie di sotto-oggetti (Subobjects), ognuno dei quali rappresenta un nodo astratto sul percorso.
Class = 20, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I tipi di sotto-oggetti includono:
- Type 1: Prefisso IPv4
- Type 2: Prefisso IPv6
- Type 32: Numero di sistema autonomo (AS Number)
Ogni sotto-oggetto ha anche un bit L (Loose bit). Se L=0, indica un hop rigoroso (Strict hop); se L=1, indica un hop flessibile (Loose hop).
4.4. Oggetto RECORD_ROUTE (RRO)
L'RRO viene utilizzato per registrare il percorso effettivo preso dall'LSP. Può anche includere informazioni sull'etichetta.
Class = 21, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.5. Oggetto SESSION_ATTRIBUTE
Questo oggetto controlla gli attributi della sessione, come la priorità e l'affinità delle risorse.
Class = 207, C_Type = 7 (LSP_TUNNEL)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Il campo Flags definisce i seguenti flag:
- 0x01: Local protection desired (Protezione locale/reinstradamento rapido desiderato)
- 0x02: Label recording desired (Registrazione etichetta desiderata)
- 0x04: SE Style desired (Stile SE desiderato, per make-before-break)
4.6. Oggetti SESSION e SENDER_TEMPLATE
Sono definiti nuovi C-Type per supportare i tunnel LSP.
- LSP_TUNNEL_IPv4 Session Object (C-Type = 7)
- LSP_TUNNEL_IPv6 Session Object (C-Type = 8)
Contiene il Tunnel ID e l'Extended Tunnel ID.
- LSP_TUNNEL_IPv4 Sender Template Object (C-Type = 7)
- LSP_TUNNEL_IPv6 Sender Template Object (C-Type = 8)
Contiene l'LSP ID.
5. Estensione Hello (Hello Extension)
L'estensione RSVP Hello consente ai nodi RSVP di rilevare quando un nodo vicino non è raggiungibile. Ciò fornisce un meccanismo di rilevamento dei guasti da nodo a nodo.
Formato del messaggio Hello:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ] <HELLO>
L'oggetto HELLO (Class 22) ha due tipi:
- HELLO REQUEST (C-Type = 1)
- HELLO ACK (C-Type = 2)
Contengono i valori di istanza sorgente (Src_Instance) e istanza di destinazione (Dst_Instance) per rilevare riavvii dei nodi o perdite di comunicazione.
6. Considerazioni sulla sicurezza (Security Considerations)
In linea di principio, queste estensioni non comportano rischi per la sicurezza superiori a RFC 2205 [1]. Tuttavia, c'è un leggero cambiamento nel modello di fiducia. Poiché il traffico viene inoltrato in base alle etichette, un amministratore potrebbe voler limitare il dominio su cui possono essere stabiliti i tunnel LSP.
7. Considerazioni IANA (IANA Considerations)
Questo documento definisce nuovi numeri di classe oggetto (Class Numbers) e tipi (C-Types), nonché codici di errore.
8. Riferimenti (References)
[1] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205. [2] Rosen, E., et al., "Multiprotocol Label Switching Architecture", RFC 3031. [3] Awduche, D., et al., "Requirements for Traffic Engineering over MPLS", RFC 2702.
Nota del traduttore: Questo documento è una traduzione di riferimento in italiano della RFC 3209.