<reference title="RSVP-TE: Extensions to RSVP for LSP Tunnels" url="https://www.rfc-editor.org/rfc/rfc3209.txt" rfc="3209" lang="it" translators="["AI"]" />
RFC 3209
Estensioni RSVP per tunnel LSP (RSVP-TE: Extensions to RSVP for LSP Tunnels)
Questa traduzione è basata sul testo originale in inglese https://www.rfc-editor.org/rfc/rfc3209.txt e tradotta paragrafo per paragrafo, conservando tutte le sezioni, i diagrammi di bit, i blocchi di codice e le tabelle.
Metadati del testo originale in inglese
- Titolo del documento: RSVP-TE: Extensions to RSVP for LSP Tunnels
- Categoria: Standards Track
- Stato: Proposed Standard
- Autori: D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow
- Data: dicembre 2001
Network Working Group
| Network Working Group | D. Awduche |
| Request for Comments (RFC): 3209 | Movaz Networks |
| Categoria: Standards Track | L. Berger |
| MPLS Network Working Group | |
| D. Gan | |
| Juniper Networks, Inc. | |
| T. Li | |
| Procket Networks | |
| V. Srinivasan | |
| G. Swallow | |
| Cisco Systems, Inc. | |
| dicembre 2001 |
Estensioni RSVP per tunnel LSP (RSVP-TE: Extensions to RSVP for LSP Tunnels)
Stato di questo memorandum
Questo memorandum definisce un protocollo di livello standard Internet per la comunità Internet. La sua distribuzione non è soggetta a restrizioni.
Avviso sul copyright
Copyright (C) The Internet Society (2001). Tutti i diritti riservati.
Il presente documento e le sue traduzioni possono essere copiati e forniti ad altre persone e sono considerati privi di costi quando copiati, presentati, citati o utilizzati per altri scopi, a condizione che tutte le suddette copie e opere derivate contengano il presente avviso di copyright e i diritti, le restrizioni e le esclusioni di responsabilità enunciate nel presente documento. Tuttavia, il documento stesso non può essere modificato in alcun modo, ad esempio rimuovendo l'avviso di copyright o i riferimenti all'Internet Society o ad altre organizzazioni Internet, salvo quando ciò sia necessario ai fini del processo degli standard Internet, nel qual caso devono essere seguite le procedure di copyright definite negli standard Internet, o quando ciò sia richiesto per tradurlo in una lingua diversa dall'inglese.
Le limitate autorizzazioni concesse sopra sono permanenti e non saranno revocate dall'Internet Society o dai suoi successori o cessionari.
Il presente documento e le informazioni in esso contenute sono forniti "COSÌ COME SONO" (AS IS) e L'INTERNET SOCIETY E L'INTERNET ENGINEERING TASK FORCE DECLINANO OGNI GARANZIA, ESPLICITA O IMPLICITA, INCLUSO, SENZA LIMITAZIONE, OGNI GARANZIA SECONDO CUI L'USO DELLE INFORMAZIONI QUI CONTENUTE NON VIOLERÀ ALCUN DIRITTO O QUALSIASI GARANZIA IMPLICITA DI COMMERCIABILITÀ O DI IDONEITÀ PER UN PARTICOLARE SCOPO.
Riconoscimenti
Il finanziamento della funzione di editor RFC è attualmente fornito dall'Internet Society.
Sommario
Il presente documento descrive estensioni al "Resource Reservation Protocol" (RSVP) (versione 1) per stabilire, in reti IP e reti a commutazione di etichetta multi-protocollo (MPLS), percorsi di commutazione di etichette (LSP) che possono seguire un instradamento esplicitamente specificato e possono essere vincolati da vincoli di traffic engineering. Questi percorsi sono detti "tunnel LSP per il traffic engineering" o, più semplicemente, "TE LSP". La capacità di un percorso di commutazione di etichette di essere stabilito seguendo un instradamento esplicito e di essere potenzialmente vincolato da vincoli di traffic engineering è un importante elemento costitutivo di molte strategie di traffic engineering dei fornitori di servizi ed è inoltre richiesta dall'architettura MPLS. Il presente documento propone un'estensione RSVP per stabilire tunnel LSP a instradamento esplicito vincolati da traffic engineering. Definisce inoltre oggetti aggiuntivi per registrare e supportare la specifica di un instradamento esplicito nei messaggi RSVP, nonché diversi oggetti per controllare ulteriormente i criteri di stabilimento dei tunnel LSP. Inoltre, il presente documento definisce un messaggio "Hello" per testare la raggiungibilità tra vicini RSVP.
1. Introduzione
Il presente documento descrive estensioni al Resource Reservation Protocol (RSVP, versione 1 [RFC 2205]) per supportare l'instaurazione di "tunnel LSP per il traffic engineering" (di seguito "TE LSP" o "tunnel LSP") in reti IP e MPLS. Per una panoramica su MPLS, si veda [RFC 3031]; per una panoramica sul traffic engineering (TE) MPLS, si veda [RFC 2702]. La sezione 2 fornisce una panoramica. La sezione 3 descrive i formati dei messaggi RSVP per stabilire i tunnel LSP. La sezione 4 descrive gli oggetti RSVP estesi per stabilire i tunnel LSP. La sezione 5 descrive l'estensione "Hello". La sezione 6 descrive le considerazioni sulla sicurezza. La sezione 7 descrive l'elaborazione dei messaggi RSVP da parte dei router di commutazione di etichette (LSR) MPLS. La sezione 8 definisce le opzioni di segnalazione per i tunnel LSP. La sezione 9 descrive la compatibilità con RSVP. La sezione 10 indica le aree in cui la presente specifica potrebbe essere estesa in futuro. La sezione 11 fornisce i riferimenti. L'appendice A fornisce la gestione degli errori. L'appendice B fornisce l'elaborazione dei messaggi RSVP negli LSR con supporto multi-protocollo. La sezione 12 è un ringraziamento. La sezione 13 riporta gli indirizzi degli autori. La sezione 14 riporta l'avviso di copyright di questo memorandum.
1.1 Terminologia
I termini e le convenzioni utilizzati nel presente documento sono forniti in [RFC 3031] e [RFC 2702]. Per comodità del lettore, alcune di queste definizioni sono ripetute di seguito.
Router di commutazione di etichette (LSR): router o switch in grado di comprendere la commutazione di etichette e di inoltrare i pacchetti in base al valore dell'etichetta.
Percorso di commutazione di etichette (LSP): per un dato insieme di pacchetti, definito dal percorso attraversato dai pacchetti e dall'insieme di LSR su cui è stato stabilito il comportamento di commutazione/inoltro delle etichette. Il percorso di commutazione di etichette di un pacchetto è identificato dallo stack di etichette applicato al pacchetto dal LSR di ingresso. Un LSP utilizzato per il traffic engineering e che segue un instradamento esplicito è spesso anche chiamato "tunnel LSP".
Downstream (A valle): su un LSP o percorso di commutazione di etichette, la direzione che va dall'ingresso all'uscita.
Upstream (A monte): su un LSP o percorso di commutazione di etichette, la direzione che va dall'uscita all'ingresso.
Tunnel LSP: percorso di commutazione di etichette avviato dal LSR di ingresso, i cui pacchetti sono incapsulati in modo tale che gli LSR lungo il LSP non esaminino l'intestazione IP dei pacchetti durante l'inoltro. In altre parole, gli LSR nel mezzo del tunnel sono "accecati" riguardo alle informazioni sui pacchetti incapsulati al suo interno. In RSVP-TE, il tunnel LSP è identificato dall'oggetto SESSION.
LSR di ingresso (Ingress LSR): LSR che applica il primo livello di etichetta al tunnel LSP. Il LSR di ingresso è anche l'iniziatore del stabilimento del tunnel LSP.
LSR di uscita (Egress LSR): LSR che rimuove il livello di etichetta più esterno del tunnel LSP. Il LSR di uscita è il punto terminale finale del tunnel LSP.
Traffic engineering: il processo di mappatura del traffico sulla topologia fisica della rete dopo aver considerato metriche di vincolo tecniche o commerciali (inclusi, senza limitazione, la gestione della larghezza di banda, le metriche di utilizzo, la gestione della congestione e il soddisfacimento dei requisiti di qualità del servizio).
Instradamento esplicito (Explicit Route): un elenco di nodi o nodi astratti (ad esempio, un sistema autonomo) pre-specificato dal LSR di ingresso all'avvio del stabilimento di un tunnel LSP. Questo elenco specifica l'insieme di nodi e/o interfacce che un tunnel LSP deve attraversare durante il suo stabilimento.
Nodo astratto (Abstract Node): una sequenza di zero o più nodi semplici (ovvero host o router) senza nodi intermedi tra essi.
Oggetto Explicit Route (ERO): composto da un elenco ordinato di elementi di instradamento esplicito (sotto-oggetti), ciascuno dei quali può essere di tipo strict (rigido) o loose (lasco), che indica un instradamento esplicito lungo una sequenza di nodi astratti. L'ERO è trasportato nel messaggio Path.
Oggetto Record Route (RRO): composto da un elenco ordinato di elementi di instradamento (sotto-oggetti), che registra il percorso reale del tunnel LSP. L'RRO è trasportato nei messaggi Path e Resv.
Tunnel di traffic engineering: tunnel LSP stabilito e mantenuto a fini di traffic engineering. Un tunnel di traffic engineering non deve seguire il percorso più breve IGP e può essere soggetto a molteplici vincoli.
1.2 Panoramica del documento
Il presente documento descrive le estensioni a RSVP che consentono di stabilire tunnel LSP in reti IP e MPLS. In particolare, il presente documento descrive gli oggetti RSVP per i seguenti scopi:
- richiedere un'etichetta durante il stabilimento di un tunnel LSP;
- trasportare informazioni di instradamento esplicito durante il stabilimento di un tunnel LSP;
- trasportare specifiche di traffic engineering (larghezza di banda, colore, affinità di classe di risorsa, ecc.);
- trasportare informazioni di policy e preemption (priorità, preempibilità);
- trasportare gli attributi di identificazione della sessione del tunnel LSP.
Inoltre, il presente documento definisce le regole di elaborazione dei messaggi RSVP per stabilire tunnel LSP vincolati da traffic engineering, inclusi stabilimento, smantellamento, re-instradamento e preemption.
2. Panoramica
RSVP [RFC 2205] è un protocollo utilizzato per stabilire e mantenere alberi di distribuzione nelle reti a protocollo Internet (IP) per la trasmissione di dati multicast o unicast. I messaggi RSVP sono trasportati lungo l'albero di distribuzione (unicast o multicast) nella direzione del percorso del flusso di dati. Nel modello di prenotazione RSVP avviato dal ricevitore, il ricevitore invia un messaggio "Resv" al mittente, prenotando risorse lungo il percorso. Nel modello RSVP avviato dal mittente, il mittente invia un messaggio "Path" al ricevitore per stabilire lo stato lungo il percorso e caratterizzare il traffico.
Il presente documento descrive estensioni a RSVP per supportare lo stabilimento di percorsi di commutazione di etichette (LSP) sotto forma di tunnel. Queste estensioni consentono a RSVP di stabilire percorsi di commutazione di etichette nelle reti MPLS e consentono inoltre, nelle reti IP, di stabilire TE LSP "simbolici" (ovvero, sebbene nelle reti IP non esista una vera commutazione di etichette, RSVP può comunque stabilire e mantenere uno stato a instradamento esplicito e vincolato la cui semantica è la stessa di un tunnel TE LSP MPLS).
Il presente documento definisce le seguenti estensioni a RSVP:
- trasportare una richiesta di etichetta e un binding di etichetta nei messaggi RSVP;
- trasportare un instradamento esplicito nei messaggi RSVP;
- trasportare specifiche di traffic engineering nei messaggi RSVP;
- trasportare attributi di sessione per il controllo delle policy e la preemption nei messaggi RSVP;
- trasportare un messaggio "Hello" tra vicini RSVP per testare la raggiungibilità.
Le sezioni seguenti descrivono in dettaglio queste estensioni.
2.1 Stabilimento di un tunnel LSP
Per stabilire un tunnel LSP, il LSR di ingresso invia un messaggio Path al LSR di uscita. Il messaggio Path trasporta:
- l'oggetto LABEL_REQUEST, utilizzato per richiedere l'assegnazione di un'etichetta al tunnel LSP;
- l'oggetto EXPLICIT_ROUTE (ERO) (opzionale), utilizzato per specificare l'instradamento esplicito che il tunnel LSP deve seguire;
- l'oggetto SESSION_ATTRIBUTE (opzionale), utilizzato per trasportare informazioni di policy di sessione (ad esempio la priorità e gli attributi di preemption del tunnel LSP);
- l'oggetto RECORD_ROUTE (RRO) (opzionale), utilizzato per registrare il percorso reale;
- gli oggetti standard di descrittore del mittente e di specifica di traffico RSVP.
Il messaggio Path viene propagato hop-by-hop lungo il percorso verso il LSR di uscita (oppure, in presenza di un ERO, lungo il percorso specificato dall'ERO). Ciascun LSR, alla ricezione di un messaggio Path, stabilisce uno "stato Path" per il suo vicino a monte (ovvero il vicino nella direzione di provenienza del messaggio Path).
Quando il LSR di uscita riceve il messaggio Path, invia un messaggio Resv lungo il percorso inverso (ovvero verso il LSR di ingresso). Il messaggio Resv trasporta:
- l'oggetto LABEL, contenente l'etichetta assegnata al tunnel LSP dal LSR di uscita (l'etichetta è assegnata dal downstream all'upstream del LSP);
- l'oggetto RECORD_ROUTE (RRO) (opzionale);
- l'oggetto di stile e il descrittore di flusso.
Il messaggio Resv viene propagato hop-by-hop lungo il percorso inverso dello stato Path. Ciascun LSR, alla ricezione di un messaggio Resv, stabilisce uno "stato Resv" per il suo vicino a valle (ovvero il vicino nella direzione di provenienza del messaggio Resv) e propaga a monte l'etichetta che ha assegnato al suo vicino a valle nell'oggetto LABEL.
Quando il LSR di ingresso riceve il messaggio Resv, lo stabilimento del tunnel LSP è completo. A questo punto il LSR di ingresso può iniziare a inoltrare pacchetti attraverso il tunnel LSP.
2.2 Re-instradamento di un tunnel LSP
Durante la vita di un tunnel LSP, potrebbe essere necessario modificarne il percorso (ad esempio, in risposta a cambiamenti nella topologia di rete, per il bilanciamento del carico o per ottimizzare l'utilizzo delle risorse). Il presente documento supporta il re-instradamento di un tunnel LSP senza interrompere il traffico trasportato. Un metodo raccomandato è il "make-before-break" (stabilisci prima di interrompere), ovvero: si stabilisce prima un nuovo LSP (con un LSP ID diverso) in parallelo al vecchio, quindi, dopo il commutazione del traffico sul nuovo LSP, si smantella il vecchio LSP. Con lo stile di prenotazione Shared Explicit (SE), i vecchi e nuovi LSP possono coesistere sulle risorse di link condivise senza causare un doppio utilizzo della larghezza di banda.
2.3 Preemption di un tunnel LSP
Ai tunnel LSP può essere assegnata una priorità. Quando le risorse di rete non sono sufficienti per ospitare simultaneamente tutti i tunnel LSP stabiliti, un tunnel LSP con priorità più alta può preemptire (ovvero smantellare e restabilire) un tunnel LSP con priorità più bassa. Il presente documento supporta la preemption tramite i campi "Setup Priority" (priorità di stabilimento) e "Holding Priority" (priorità di mantenimento) nell'oggetto SESSION_ATTRIBUTE.
2.4 Stili di prenotazione delle risorse
RSVP supporta molteplici stili di prenotazione delle risorse, tra cui:
- stile Fixed Filter (FF): crea una prenotazione indipendente per ciascun flusso (mittente, ricevitore);
- stile Wildcard Filter (WF): una singola prenotazione è condivisa da un insieme (possibilmente sconosciuto) di mittenti;
- stile Shared Explicit (SE): una singola prenotazione è condivisa da un insieme di mittenti esplicitamente elencate.
Per i tunnel LSP viene di norma utilizzato lo stile SE, poiché consente ai vecchi e nuovi LSP di condividere la prenotazione delle risorse durante un re-instradamento (make-before-break).
3. Format dei messaggi RSVP per lo stabilimento di tunnel LSP
3.1 Messaggio Path
Il messaggio Path è utilizzato, avviato dal LSR di ingresso, per stabilire un tunnel LSP. Il formato del messaggio RSVP Path è il seguente:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
[ <LABEL_REQUEST> ]
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
LABEL_REQUEST ed EXPLICIT_ROUTE sono oggetti nuovamente introdotti dal presente documento. Anche SESSION_ATTRIBUTE è un oggetto nuovamente introdotto dal presente documento. RECORD_ROUTE è definito in [RFC 2205], ma il presente documento ne specifica l'utilizzo nello stabilimento dei tunnel LSP.
3.2 Messaggio Resv
Il messaggio Resv è avviato dal LSR di uscita, inviato lungo il percorso inverso dello stato Path, per completare lo stabilimento del tunnel LSP. Il formato del messaggio RSVP Resv è il seguente:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ]
[ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor list>
<FF flow descriptor list> ::= <FF flow descriptor>
| <FF flow descriptor list> <FF flow descriptor>
<FF flow descriptor> ::= [ <FLOW_SPEC> ] <FILTER_SPEC> <LABEL>
<SE flow descriptor list> ::= <SE flow descriptor>
| <SE flow descriptor list> <SE flow descriptor>
<SE flow descriptor> ::= [ <FLOW_SPEC> ] <SE filter spec list>
<SE filter spec list> ::= <FILTER_SPEC> <LABEL>
| <SE filter spec list> <FILTER_SPEC> <LABEL>
LABEL è un oggetto nuovamente introdotto dal presente documento, utilizzato per trasportare l'etichetta assegnata al tunnel LSP.
4. Oggetti per lo stabilimento di tunnel LSP
Questa sezione descrive gli oggetti RSVP estesi per lo stabilimento di tunnel LSP. Ciascun oggetto è composto da un "intestazione di oggetto" e da un "corpo di oggetto", dove l'intestazione di oggetto è definita in [RFC 2205].
4.1 Oggetto LABEL
L'oggetto LABEL è utilizzato per trasportare il valore di etichetta assegnato al tunnel LSP. L'oggetto LABEL è trasportato nel messaggio Resv.
Il formato dell'oggetto LABEL è il seguente:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 16 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Il campo Label Value è un valore di etichetta a 20 bit (per un LSR con capacità di commutazione di pacchetti). Per un LSR con capacità ATM o Frame Relay, la codifica del valore di etichetta è diversa; per i dettagli si veda l'appendice B.
4.1.1 Gestione dell'oggetto LABEL nel messaggio Resv
Quando un LSR riceve un messaggio Resv trasportante l'oggetto LABEL, utilizza il valore di etichetta dell'oggetto LABEL per il binding di etichetta della sua interfaccia a monte (ovvero, il LSR a monte utilizzerà questo valore di etichetta come etichetta in uscita quando invia pacchetti a questo LSR).
4.1.2 Mancato supporto dell'oggetto LABEL
Se un LSR non supporta l'oggetto LABEL, deve produrre un messaggio ResvErr con il codice di errore "classe di oggetto sconosciuta" alla ricezione di un messaggio Resv trasportante l'oggetto LABEL. L'oggetto LABEL appartiene alla classe di oggetto "riconoscibile" (due bit più significativi della classe = 0b10), pertanto deve restituire un errore se sconosciuto.
4.2 Oggetto LABEL_REQUEST
L'oggetto LABEL_REQUEST è utilizzato per richiedere l'assegnazione di un'etichetta durante lo stabilimento di un tunnel LSP. È trasportato nel messaggio Path. L'oggetto LABEL_REQUEST può inoltre trasportare un identificatore di protocollo di livello 3 (L3PID) e un intervallo di etichette opzionale (per link ATM o Frame Relay).
Il formato dell'oggetto LABEL_REQUEST è il seguente (forma senza intervallo di etichette):
Class = 19, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 19 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3PID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Il formato dell'oggetto LABEL_REQUEST con intervallo di etichette ATM è il seguente:
Class = 19, C-Type = 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 19 | C-Type = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3PID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI/VCI Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Il formato dell'oggetto LABEL_REQUEST con intervallo di etichette Frame Relay è il seguente:
Class = 19, C-Type = 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 19 | C-Type = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3PID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI Range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Il campo L3PID identifica il protocollo di livello 3 trasportato dal tunnel LSP (ad esempio IPv4 = 0x0800, IPv6 = 0x86DD).
4.2.1 Gestione di LABEL_REQUEST nel messaggio Path
Quando un LSR riceve un messaggio Path trasportante LABEL_REQUEST, deve (se supportato) assegnare un'etichetta per il tunnel LSP e annunciarla nell'oggetto LABEL del messaggio Resv inviato a monte. Se il LSR non supporta l'L3PID richiesto, deve produrre un messaggio PathErr.
4.2.2 Mancato supporto dell'oggetto LABEL_REQUEST
Se un LSR non supporta l'oggetto LABEL_REQUEST, deve produrre un messaggio PathErr con il codice di errore "classe di oggetto sconosciuta" alla ricezione di un messaggio Path trasportante LABEL_REQUEST. L'oggetto LABEL_REQUEST appartiene alla classe di oggetto "riconoscibile" (due bit più significativi della classe = 0b10), pertanto deve restituire un errore se sconosciuto.
4.3 Oggetto EXPLICIT_ROUTE (ERO)
L'oggetto EXPLICIT_ROUTE (ERO) consente al LSR di ingresso di specificare l'instradamento esplicito che il tunnel LSP deve seguire durante il suo stabilimento. L'ERO compare nel messaggio Path. L'ERO è composto da un elenco ordinato di sotto-oggetti, ciascuno dei quali può essere di tipo strict (rigido) o loose (lasco).
Il formato dell'oggetto ERO è il seguente:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 20 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Subobjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Il formato di ciascun sotto-oggetto è il seguente:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
dove il bit L (bit Loose) indica se il sotto-oggetto è di tipo loose (L=0) o strict (L=1).
I tipi di sotto-oggetti definiti nell'ERO includono:
- Tipo 1: prefisso IPv4
- Tipo 2: prefisso IPv6
- Tipo 3: numero di sistema autonomo (ASN)
- Tipo 4: LSPID versione 4 (obsoleto)
- Tipo 5: interfaccia non numerata (Unnumbered Interface)
- Tipo 6: prefisso IPv4 (con flag di prefisso)
- Tipo 7: prefisso IPv6 (con flag di prefisso)
- Tipo 8: numero di sistema autonomo (4 ottetti)
- Tipo 9: LSPID versione 4 (esteso)
- Tipo 10: SRLG (Shared Risk Link Group)
- Tipo 11: tipo di protezione di nodo o link
- Tipo 12: tipo di protezione di banda
4.3.1 Sotto-oggetto prefisso IPv4
Il sotto-oggetto prefisso IPv4 è utilizzato per specificare un prefisso di indirizzo IPv4 come elemento di instradamento. Il suo formato è il seguente:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 1 | Length | IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved (zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.2 Sotto-oggetto prefisso IPv6
Il sotto-oggetto prefisso IPv6 è utilizzato per specificare un prefisso di indirizzo IPv6 come elemento di instradamento. Il suo formato è il seguente:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 2 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| IPv6 address (16 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.3 Sotto-oggetto numero di sistema autonomo
Il sotto-oggetto numero di sistema autonomo (ASN) è utilizzato per specificare un sistema autonomo come nodo astratto. Il suo formato è il seguente (ASN a 2 ottetti):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type = 3 | Length | Reserved | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.4 Gestione dell'ERO nel messaggio Path
Quando un LSR riceve un messaggio Path trasportante un ERO, esamina il sotto-oggetto in cima all'ERO per determinare il prossimo hop. Per un sotto-oggetto strict, il prossimo hop deve essere un nodo direttamente adiacente; per un sotto-oggetto loose, il prossimo hop può essere un nodo raggiungibile tramite l'instradamento IGP. Dopo l'elaborazione del sotto-oggetto in cima, il LSR lo rimuove (pop) dall'ERO e propaga l'ERO modificato a valle.
4.3.5 Cicli nell'ERO
L'elaborazione dell'ERO deve essere in grado di rilevare cicli. Quando un LSR rileva che un ERO causerà un ciclo, deve produrre un messaggio PathErr e rifiutare il tunnel LSP. L'oggetto RECORD_ROUTE (RRO) può essere utilizzato anche per supportare il rilevamento dei cicli.
4.4 Oggetto SESSION_ATTRIBUTE
L'oggetto SESSION_ATTRIBUTE è utilizzato per trasportare gli attributi di sessione del tunnel LSP, inclusi il nome della sessione, le priorità di setup e di mantenimento, il desiderio di protezione locale, il desiderio di registrazione dell'etichetta, ecc. Il suo formato è il seguente:
Class = 207, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num=207 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I bit del campo Flags sono definiti come segue:
- 0x01: protezione locale desiderata (Local protection desired)
- 0x02: registrazione etichetta desiderata (Label recording desired)
- 0x04: stile SE desiderato (SE Style desired)
- 0x08: protezione di banda (Bandwidth protection)
- 0x10: protezione di nodo (Node protection)
4.5 Oggetto RECORD_ROUTE (RRO)
L'oggetto RECORD_ROUTE (RRO) è utilizzato per registrare il percorso reale del tunnel LSP. L'RRO è trasportato sia nei messaggi Path che Resv. L'RRO è composto da una serie di sotto-oggetti, ciascuno dei quali registra un nodo o un link sul percorso. L'RRO può essere utilizzato per il rilevamento di cicli, il calcolo della diversità di percorso e la diagnostica dei guasti.
4.6 Oggetto SESSION
L'oggetto SESSION è utilizzato per identificare la sessione del tunnel LSP. Per un tunnel LSP, il "Tunnel Endpoint Address" (indirizzo del punto terminale del tunnel) nell'oggetto SESSION è impostato sull'indirizzo del LSR di uscita, il "Tunnel ID" è assegnato dal LSR di ingresso e l'"Extended Tunnel ID" è normalmente impostato sull'indirizzo del LSR di ingresso.
4.7 Oggetto SENDER_TEMPLATE
L'oggetto SENDER_TEMPLATE è utilizzato per identificare il mittente (ovvero il LSR di ingresso) del tunnel LSP. Per un tunnel LSP, l'oggetto SENDER_TEMPLATE trasporta il "Tunnel ID" e il "LSP ID". L'LSP ID è utilizzato per distinguere i vecchi e nuovi LSP durante un re-instradamento (make-before-break).
5. Estensione Hello
Il presente documento definisce l'estensione RSVP "Hello" utilizzata per testare la raggiungibilità tra vicini RSVP. Il meccanismo Hello integra il meccanismo di aggiornamento basato su soft state e può attivare un rilevamento di guasto del vicino più rapido del rilevamento di guasto IGP, supportando così una protezione o un re-instradamento più rapido dei tunnel LSP.
Il formato del messaggio RSVP Hello è il seguente:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
Il formato dell'oggetto HELLO è il seguente:
Class = 8, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num = 8 | C-Type = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Instance | Destination Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I messaggi Hello sono scambiati periodicamente tra vicini RSVP adiacenti. Se entro un intervallo configurabile non viene ricevuto alcun messaggio Hello dalla controparte, il vicino è considerato non raggiungibile e viene attivata la gestione degli errori corrispondente (ad esempio, la revoca di tutti gli stati Path e Resv che transitano per quel vicino e l'attivazione del re-instradamento del tunnel LSP).
6. Considerazioni sulla sicurezza
I messaggi RSVP sono utilizzati per stabilire e mantenere i tunnel LSP, influenzando direttamente lo stato di inoltro e le risorse di rete. Di conseguenza, il piano di controllo RSVP-TE affronta molteplici minacce alla sicurezza, tra cui:
- messaggi Path o Resv contraffatti che causano binding di etichette errati o esaurimento delle risorse;
- instradamenti espliciti non autorizzati che indirizzano il traffico attraverso link sensibili;
- attacchi di aggiornamento o di stato che causano l'esaurimento della CPU del piano di controllo;
- perdita di informazioni sulla topologia di rete tramite l'oggetto RECORD_ROUTE.
Per mitigare queste minacce, l'implementazione DOVREBBE (should) utilizzare l'autenticazione RSVP (ad esempio l'oggetto RSVP INTEGRITY o IPsec), filtrare i peer del piano di controllo (ad esempio limitando i vicini RSVP tramite ACL) e limitare l'esposizione del database di traffic engineering. Inoltre, dovrebbe essere implementata una limitazione di velocità per resistere agli attacchi di negazione del servizio. Per il modello di minaccia dettagliato e le misure di mitigazione, si vedano i documenti di sicurezza correlati e i successivi BCP.
7. Elaborazione dei messaggi RSVP da parte dei router di commutazione di etichette (LSR)
Questa sezione descrive le regole dettagliate di elaborazione dei messaggi RSVP da parte di un LSR con capacità MPLS per lo stabilimento di tunnel LSP.
7.1 Elaborazione del messaggio Path
Quando un LSR riceve un messaggio Path, esegue le seguenti operazioni:
- Se il messaggio Path contiene l'oggetto LABEL_REQUEST, il LSR deve assegnare un'etichetta per il tunnel LSP (a meno che non sia il LSR di uscita, nel qual caso l'etichetta è determinata dall'uscita in base all'L3PID).
- Se il messaggio Path contiene l'oggetto EXPLICIT_ROUTE, il LSR seleziona il prossimo hop secondo le regole dell'ERO.
- Se il messaggio Path contiene l'oggetto RECORD_ROUTE, il LSR aggiunge il proprio indirizzo o identificatore di interfaccia all'RRO.
- Il LSR propaga il messaggio Path modificato (con l'ERO poppato/aggiornato e l'RRO al quale è stato aggiunto questo nodo) a valle.
7.2 Elaborazione del messaggio Resv
Quando un LSR riceve un messaggio Resv, esegue le seguenti operazioni:
- Il LSR estrae dal messaggio Resv, dall'oggetto LABEL, l'etichetta assegnata dal suo vicino a valle.
- Il LSR assegna un'etichetta per sé stesso (destinata al suo vicino a monte) e la inserisce nell'oggetto LABEL per propagarla a monte.
- Se il messaggio Resv contiene l'oggetto RECORD_ROUTE, il LSR aggiunge il proprio record di etichetta all'RRO (quando il flag "registrazione etichetta desiderata" in SESSION_ATTRIBUTE è impostato).
- Il LSR invia il messaggio Resv a monte lungo il percorso inverso dello stato Path.
7.3 Smantellamento di un tunnel LSP
Un tunnel LSP può essere smantellato inviando un messaggio PathTear o ResvTear. Il messaggio PathTear è inviato nella direzione dello stato Path e rimuove tutti gli stati Path lungo il percorso. Il messaggio ResvTear è inviato nella direzione dello stato Resv e rimuove tutti gli stati Resv lungo il percorso. Quando il LSR di ingresso non ha più bisogno del tunnel LSP, invia un messaggio PathTear; quando il LSR di uscita decide di terminare il tunnel LSP, invia un messaggio ResvTear.
7.4 Gestione degli errori
Quando un LSR incontra un errore (ad esempio, ERO non soddisfabile, assegnazione di etichetta fallita, risorse insufficienti o oggetto sconosciuto) durante l'elaborazione di un messaggio RSVP, deve generare un messaggio di errore corrispondente (PathErr o ResvErr) e trasportare il codice di errore e le informazioni sul nodo in errore. Il LSR di ingresso può utilizzare queste informazioni per selezionare un percorso alternativo o adottare altre misure correttive. Le regole dettagliate di gestione degli errori sono fornite nell'appendice A.
8. Opzioni per la segnalazione dei tunnel LSP
Questa sezione descrive alcuni meccanismi opzionali che possono essere utilizzati per potenziare le capacità di segnalazione dei tunnel LSP, tra cui:
- preemption e gestione delle priorità;
- affinità di classe di risorsa (gruppi amministrativi e esclusione di gruppi amministrativi);
- traffic engineering sensibile ai DiffServ;
- segnalazione LSP punto-a-multi-punto (P2MP) (definita in documenti successivi).
Queste opzioni sono realizzate impostando i flag e i campi corrispondenti nell'oggetto SESSION_ATTRIBUTE e in altri oggetti estesi.
9. Compatibilità con RSVP
Le estensioni RSVP definite nel presente documento sono progettate per essere compatibili con le implementazioni RSVP esistenti. Un nodo RSVP che non supporta le estensioni per tunnel LSP elaborerà i nuovi oggetti secondo la semantica dei due bit più significativi della classe di oggetto (class-num):
- se i due bit più significativi sono 0b01 (ignorabile), il nodo può ignorare l'oggetto sconosciuto e continuare l'elaborazione del messaggio;
- se i due bit più significativi sono 0b10 (riconoscibile), il nodo deve restituire un errore (PathErr o ResvErr), poiché l'oggetto sconosciuto potrebbe influenzare il corretto funzionamento.
LABEL_REQUEST, LABEL ed EXPLICIT_ROUTE appartengono tutti alla classe "riconoscibile" (0b10), pertanto i nodi che non li supportano restituiscono un errore, prevenendo così lo stabilimento di un tunnel LSP incompleto.
10. Sviluppi futuri
La presente specifica potrebbe essere estesa nei seguenti ambiti:
- supporto per LSP punto-a-multi-punto (P2MP) e multi-punto-a-multi-punto (MP2MP);
- supporto per GMPLS (Generalized MPLS), inclusi link a multiplazione a divisione di tempo (TDM), commutazione di lunghezza d'onda e commutazione a fibra ottica;
- meccanismi potenziati di Fast Reroute (FRR);
- integrazione più stretta con Differentiated Services (DiffServ) e traffic engineering.
11. Riferimenti
11.1 Riferimenti normativi
- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, marzo 1997.
- [RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. e S. Jamin, "Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification", RFC 2205, settembre 1997.
- [RFC 2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. e J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, settembre 1999.
- [RFC 3031] Rosen, E., Viswanathan, A. e R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, gennaio 2001.
11.2 Riferimenti
- [RFC 3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. e A. Conta, "MPLS Label Stack Encoding", RFC 3032, gennaio 2001.
- [RFC 3212] Jamoussi, B. et al., "Constraint-Based LSP Setup using LDP", RFC 3212, gennaio 2002.
- altri RFC successivi (documenti che definiscono Fast Reroute, GMPLS, P2MP, ecc.).
Appendice A. Gestione degli errori
La presente appendice descrive le regole di gestione degli errori durante lo stabilimento di un tunnel LSP.
A.1 Messaggio PathErr
Quando un LSR incontra un errore durante l'elaborazione di un messaggio Path, genera un messaggio PathErr contenente:
- il codice di errore (ad esempio, classe di oggetto sconosciuta, ERO non soddisfabile, risorse insufficienti, assegnazione di etichetta fallita);
- il sottocodice di errore (che fornisce informazioni più dettagliate);
- l'identificatore del nodo in errore (normalmente l'indirizzo del LSR che ha generato l'errore).
Il messaggio PathErr è inviato lungo il percorso inverso del messaggio Path e raggiunge infine il LSR di ingresso.
A.2 Messaggio ResvErr
Quando un LSR incontra un errore durante l'elaborazione di un messaggio Resv, genera un messaggio ResvErr contenente codici di errore, sottocodici e informazioni sul nodo in errore simili. Il messaggio ResvErr è inviato lungo il percorso inverso del messaggio Resv e raggiunge infine il LSR di uscita.
A.3 Codici di errore comuni
La seguente tabella elenca i codici di errore comuni durante lo stabilimento di un tunnel LSP.
| Codice di errore | Significato |
|---|---|
| Classe di oggetto sconosciuta | Ricezione di un oggetto riconoscibile sconosciuto |
| ERO non soddisfabile | Impossibile stabilire l'LSP secondo il percorso specificato dall'ERO |
| Risorse insufficienti | Larghezza di banda o risorse di etichette insufficienti |
| Assegnazione di etichetta fallita | Impossibile assegnare l'etichetta richiesta |
| L3PID non supportato | Protocollo L3 richiesto non supportato |
Appendice B. Elaborazione dei messaggi RSVP negli LSR con supporto multi-protocollo
La presente appendice descrive le considerazioni particolari per l'elaborazione dei messaggi RSVP negli LSR che possiedono sia capacità di commutazione di pacchetti (PSC) che capacità di commutazione di circuito (ad esempio ATM, Frame Relay).
B.1 Codifica delle etichette su interfaccia ATM
Su un'interfaccia ATM, il valore di etichetta dell'oggetto LABEL è codificato come coppia VPI/VCI. L'oggetto LABEL_REQUEST utilizza C-Type = 2 e trasporta l'intervallo VPI/VCI.
B.2 Codifica delle etichette su interfaccia Frame Relay
Su un'interfaccia Frame Relay, il valore di etichetta dell'oggetto LABEL è codificato come DLCI. L'oggetto LABEL_REQUEST utilizza C-Type = 3 e trasporta l'intervallo DLCI.
B.3 Interfacce non numerate
Per le interfacce non numerate (Unnumbered), un sotto-oggetto speciale (tipo 5) è utilizzato nell'ERO e nell'RRO per identificare l'interfaccia. Un'interfaccia non numerata è identificata dal suo "Router ID" e dal suo "Interface Index".
12. Riconoscimenti
Gli autori ringraziano i numerosi revisori per i loro contributi e feedback su questo documento, inclusi diversi membri del gruppo di lavoro MPLS.
13. Indirizzi degli autori
Daniel O. Awduche
Movaz Networks
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Lou Berger
MPLS Network Working Group
Der-Hwa Gan
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043
Tony Li
Procket Networks
1100 Cadillac Court
Milpitas, CA 95035
Vijay Srinivasan
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
14. Avviso sul copyright
Copyright (C) The Internet Society (2001). Tutti i diritti riservati.
Il presente documento e le sue traduzioni possono essere copiati e forniti ad altre persone e sono considerati privi di costi quando copiati, presentati, citati o utilizzati per altri scopi, a condizione che tutte le suddette copie e opere derivate contengano il presente avviso di copyright e i diritti, le restrizioni e le esclusioni di responsabilità enunciate nel presente documento. Tuttavia, il documento stesso non può essere modificato in alcun modo, ad esempio rimuovendo l'avviso di copyright o i riferimenti all'Internet Society o ad altre organizzazioni Internet, salvo quando ciò sia necessario ai fini del processo degli standard Internet, nel qual caso devono essere seguite le procedure di copyright definite negli standard Internet, o quando ciò sia richiesto per tradurlo in una lingua diversa dall'inglese.
Le limitate autorizzazioni concesse sopra sono permanenti e non saranno revocate dall'Internet Society o dai suoi successori o cessionari.
Il presente documento e le informazioni in esso contenute sono forniti "COSÌ COME SONO" (AS IS) e L'INTERNET SOCIETY E L'INTERNET ENGINEERING TASK FORCE DECLINANO OGNI GARANZIA, ESPLICITA O IMPLICITA, INCLUSO, SENZA LIMITAZIONE, OGNI GARANZIA SECONDO CUI L'USO DELLE INFORMAZIONI QUI CONTENUTE NON VIOLERÀ ALCUN DIRITTO O QUALSIASI GARANZIA IMPLICITA DI COMMERCIABILITÀ O DI IDONEITÀ PER UN PARTICOLARE SCOPO.
Riconoscimenti
Il finanziamento della funzione di editor RFC è attualmente fornito dall'Internet Society.