RFC 7274 - Allocazione e ritiro delle etichette MPLS per scopi speciali

Internet Engineering Task Force (IETF) — K. Kompella, Juniper Networks; L. Andersson, Huawei; A. Farrel, Juniper Networks. Giugno 2014. Categoria: Standards Track. Aggiorna: RFC 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478 e 6790.

Abstract

Alcune etichette MPLS sono state assegnate a scopi specifici. A tale fine è stato riservato un blocco di etichette (0-15), comunemente denominate "etichette riservate"; nel presente documento sono chiamate "etichette per scopi speciali".

Poiché esistono soltanto 16 etichette di questo tipo, occorre prudenza nell'assegnarne di nuove; al tempo stesso, quando una nuova assegnazione è necessaria, deve essere possibile progredire.

Il presente memo definisce nuove procedure per l'assegnazione e il ritiro delle etichette per scopi speciali, un metodo per estendere il relativo spazio e il modo in cui le etichette estese devono essere gestite nel piano dati. Rinomina inoltre il registro IANA in "Special-Purpose MPLS Label Values" e crea il nuovo registro "Extended Special-Purpose MPLS Label Values".

Il documento aggiorna le RFC 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478 e 6790, che utilizzano il termine "reserved label".

Stato di questo memo

Questo è un documento Internet Standards Track, prodotto dalla Internet Engineering Task Force (IETF). Rappresenta il consenso della comunità IETF, è stato sottoposto a revisione pubblica ed è stato approvato per la pubblicazione dall'Internet Engineering Steering Group (IESG). Ulteriori informazioni sugli standard Internet sono disponibili nella Sezione 2 della RFC 5741.

Lo stato corrente, le errata e le modalità per inviare osservazioni sono disponibili all'indirizzo http://www.rfc-editor.org/info/rfc7274.

Avviso di copyright

Copyright (c) 2014 IETF Trust e le persone identificate come autori del documento. Tutti i diritti riservati.

Il documento è soggetto al BCP 78 e alle Legal Provisions Relating to IETF Documents dell'IETF Trust (http://trustee.ietf.org/license-info) in vigore alla data di pubblicazione. I componenti di codice estratti dal documento devono includere il testo della Simplified BSD License descritto nella Sezione 4.e delle disposizioni e sono forniti senza garanzia secondo tale licenza.

Indice

• 1. Introduzione
  • 1.1. Convenzioni utilizzate nel documento
• 2. Domande
• 3. Risposte
  • 3.1. Valori estesi delle etichette MPLS per scopi speciali
    • 3.1.1. Inoltro di pacchetti con etichette estese per scopi speciali
    • 3.1.2. Scelta di una nuova etichetta per scopi speciali
  • 3.2. Processo di ritiro delle etichette per scopi speciali
• 4. RFC aggiornate
• 5. Considerazioni IANA
• 6. Considerazioni sulla sicurezza
• 7. Ringraziamenti
• 8. Riferimenti
  • 8.1. Riferimenti normativi
  • 8.2. Riferimenti informativi

1. Introduzione

La specifica MPLS Label Stack Encoding [RFC3032] ha definito quattro valori di etichetta per scopi speciali (da 0 a 3) e ha riservato i valori da 4 a 15 per uso futuro. Queste etichette hanno un significato speciale sia nel piano di controllo sia nel piano dati. Da allora sono stati assegnati altri tre valori: 7, 13 e 14, rispettivamente in [RFC6790], [RFC5586] e [RFC3429]. Restano quindi nove valori non assegnati dei sedici originari.

L'assegnazione, in circa 12 anni, di tre dei dodici valori che rimanevano non è di per sé preoccupante; lo è invece la scarsità complessiva delle etichette per scopi speciali. Molte di esse richiedono inoltre un'elaborazione specifica da parte dell'hardware di inoltro, le cui modifiche sono spesso costose e talvolta impossibili. È pertanto importante documentare ogni nuovo valore assegnato.

Il presente memo illustra alcuni problemi relativi all'assegnazione e al ritiro di tali valori, definisce i meccanismi per affrontarli ed estende lo spazio delle etichette per scopi speciali.

1.1. Convenzioni utilizzate nel documento

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

Sono introdotti due nuovi acronimi:

• XL (Extension Label): etichetta che indica che segue un'etichetta estesa per scopi speciali.
• ESPL (Extended Special-Purpose Label): etichetta per scopi speciali posta nello stack dopo la Extension Label. La combinazione di XL ed ESPL può essere considerata una nuova forma di "etichetta composta", costituita da più voci consecutive nello stack.

2. Domande

Nel riesaminare le etichette MPLS per scopi speciali emergono le domande seguenti:

1. Quali politiche deve applicare IANA per assegnarle? Deve essere consentita l'assegnazione anticipata (Early Allocation) [RFC7120]? Devono esistere etichette per uso sperimentale o privato [RFC5226]?
2. Quale documentazione è richiesta per le assegnazioni future?
3. Un'etichetta per scopi speciali può essere ritirata? Quali criteri sono pertinenti? Può essere riassegnata a uno scopo diverso? Quali procedure e tempi sono appropriati?
4. Il valore 3, "Implicit NULL Label" [RFC3032], è usato soltanto nella segnalazione e mai nel piano dati. Potrebbe o dovrebbe essere usato nel piano dati? In caso affermativo, come e a quale scopo?
5. Quale meccanismo praticabile può estendere lo spazio qualora diventi necessario?
6. Le etichette estese per scopi speciali devono essere utilizzate per il bilanciamento del carico?

3. Risposte

La presente sezione risponde alle domande precedenti.

1. 1. L'assegnazione di etichette MPLS per scopi speciali avviene mediante "Standards Action".
   2. Il registro IANA è rinominato "Special-Purpose MPLS Label Values".
   3. L'assegnazione anticipata può essere consentita caso per caso.
   4. Lo spazio corrente di 16 valori è troppo piccolo per riservarne alcuni all'uso sperimentale o privato. Il registro "Extended Special-Purpose MPLS Label Values" creato dal documento è invece abbastanza ampio e comprende un intervallo per uso sperimentale.
2. Una richiesta di assegnazione soggetta a Standards Action deve essere accompagnata da una RFC Standards Track, conformemente a [RFC5226].
3. Il ritiro di un valore deve seguire un processo rigoroso e ben documentato, per evitare di rendere orfani gli impieghi già distribuiti. Il processo è descritto nella Sezione 3.2.
4. Per il momento non è consentito usare nel piano dati l'"Implicit NULL Label" (valore 3). Un'eventuale revisione richiederà una RFC Standards Track che descriva l'uso dell'etichetta, le possibili confusioni fra segnalazione e piano dati e le relative mitigazioni.
5. Il valore 15 è riservato come "Extension Label" (XL) per estendere lo spazio. I dettagli sono nella Sezione 3.1.
6. [RFC6790] stabilisce che le etichette per scopi speciali MUST NOT essere usate per il bilanciamento del carico. La stessa regola vale per le ESPL, che quindi MUST NOT essere usate a tale fine. Le implementazioni esistenti non riconoscono XL come qualcosa di diverso da una singola etichetta per scopi speciali e non si aspettano che sia seguita da una ESPL; di conseguenza, se alcuni pacchetti di un flusso contengono ESPL, potrebbero percorrere cammini diversi ed essere riordinati. È tuttavia importante specificare il comportamento corretto per le implementazioni future, da cui l'uso di "MUST NOT".

Occorreva inoltre stabilire se una normale etichetta per scopi speciali conservi il proprio significato quando segue XL. La risposta è fornita nella Sezione 3.1.

3.1. Valori estesi delle etichette MPLS per scopi speciali

XL MUST essere seguita da un'altra etichetta L e quindi MUST avere il bit bottom-of-stack azzerato. L MUST essere interpretata come ESPL secondo il nuovo registro creato dal documento (Sezione 5). Il bit bottom-of-stack di L dipende dalla presenza di ulteriori etichette. XL attribuisce un significato speciale soltanto a L. Un'etichetta successiva a L, se presente, viene analizzata normalmente e può essere un'etichetta ordinaria o per scopi speciali; nel secondo caso può essere XL e quindi essere seguita da un'altra ESPL.

Il valore 15 è riservato a XL come indicato nella Sezione 5.

I valori 0-15 del registro "Extended Special-Purpose MPLS Label Values" sono riservati. Inoltre, i valori 0-6 e 8-15 MUST NOT comparire nel piano dati dopo una XL; un LSR che elabora un pacchetto con XL in cima allo stack seguita da un'etichetta con valore 0-6 o 8-15 MUST scartare il pacchetto.

Quando viene ricevuta, l'etichetta 7 conserva il significato di Entropy Label Indicator (ELI), sia come normale etichetta per scopi speciali sia come ESPL. Ciò mantiene la compatibilità con codice e hardware già distribuiti che cercano ELI senza verificare se l'etichetta precedente sia XL. Tuttavia, quando un LSR inserisce un'etichetta di entropia, MUST inserire ELI come normale etichetta per scopi speciali e non come ESPL.

3.1.1. Inoltro di pacchetti con etichette estese per scopi speciali

Se un LSR incontra XL in cima allo stack e non comprende le etichette di estensione, MUST scartare il pacchetto secondo la procedura di [RFC3031] per un'etichetta in ingresso non valida. Se incontra in cima allo stack una ESPL successiva a XL che non comprende, MUST scartare il pacchetto con la stessa procedura. In entrambi i casi l'LSR MAY registrare l'evento, ma tale registrazione MUST essere limitata in frequenza.

Un LSR SHOULD NOT prendere decisioni di inoltro in base a etichette che non sono in cima allo stack. Per il bilanciamento del carico si veda la risposta 6 nella Sezione 3.

3.1.2. Scelta di una nuova etichetta per scopi speciali

Nell'assegnare una nuova etichetta per scopi speciali, i progettisti di protocolli dovrebbero valutare se sia possibile utilizzare una ESPL. Ciò contribuirebbe a preservare le scarse etichette "normali" per i casi in cui è particolarmente importante ridurre al minimo la dimensione dello stack.

3.2. Processo di ritiro delle etichette per scopi speciali

La procedura seguente è definita per completezza, ma il ritiro è difficile e si raccomanda di ricorrervi con parsimonia.

1. Un valore assegnato dal registro "Special-Purpose MPLS Label Values" può essere deprecato per consenso IETF, previa revisione del gruppo di lavoro MPLS o di esperti designati qualora il gruppo o un suo successore non esista. È richiesta una RFC almeno Informational. La RFC ordina a IANA di contrassegnare il valore come "deprecated", senza liberarlo in questa fase. La deprecazione impedisce di documentare ulteriori specifiche che usino il valore e indica ai fornitori di non includerlo nelle nuove implementazioni e agli operatori di evitarlo nelle nuove distribuzioni.
2. Dodici mesi dopo la pubblicazione della RFC di deprecazione, può essere condotta un'indagine a livello IETF per stabilire se il valore sia ancora in uso. Se lo è, l'indagine può essere ripetuta dopo altri sei mesi.
3. Se l'indagine indica che il valore non è in uso, 24 mesi dopo la RFC di deprecazione può essere richiesta la pubblicazione di un Internet-Draft IETF Standards Track che ritiri il valore. Il documento richiederà a IANA di liberarlo per un impiego e un'assegnazione futuri.

4. RFC aggiornate

Le RFC seguenti contengono riferimenti al termine "reserved labels":

• [RFC3032], "MPLS Label Stack Encoding"
• [RFC3038], "VCID Notification over ATM link for LDP"
• [RFC3209], "RSVP-TE: Extensions to RSVP for LSP Tunnels"
• [RFC3811], "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management"
• [RFC4182], "Removing a Restriction on the use of MPLS Explicit NULL"
• [RFC4928], "Avoiding Equal Cost Multipath Treatment in MPLS Networks"
• [RFC5331], "MPLS Upstream Label Assignment and Context-Specific Label Space"
• [RFC5586], "MPLS Generic Associated Channel"
• [RFC5921], "A Framework for MPLS in Transport Networks"
• [RFC5960], "MPLS Transport Profile Data Plane Architecture"
• [RFC6391], "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network"
• [RFC6478], "Pseudowire Status for Static Pseudowires"
• [RFC6790], "MPLS Entropy Labels"

Tutti questi riferimenti devono essere letti come "special-purpose labels".

5. Considerazioni IANA

IANA ha apportato le modifiche e le aggiunte seguenti alla registrazione delle etichette MPLS:

1. Il registro "Multiprotocol Label Switching Architecture (MPLS) Label Values" è stato rinominato "Special-Purpose MPLS Label Values".
2. La politica di assegnazione del registro è stata modificata in Standards Action.
3. Il valore 15 è stato assegnato come "Extension Label", con il presente documento come riferimento.
4. È stato creato il registro "Extended Special-Purpose MPLS Label Values". La procedura di registrazione è Standards Action e gli intervalli sono quelli della Tabella 1, secondo la terminologia di [RFC5226]. L'assegnazione anticipata secondo [RFC7120] è consentita soltanto per valori assegnati mediante Standards Action.

Intervallo	Politica di assegnazione
0-15	Riservato; non deve mai essere reso disponibile per l'assegnazione.
16-239	Non assegnato.
240-255	Riservato per uso sperimentale.
256-1048575	Riservato; non disponibile senza una nuova RFC Standards Track che definisca una politica di assegnazione.

6. Considerazioni sulla sicurezza

Il documento non introduce grandi modifiche al funzionamento del piano dati MPLS; le considerazioni di sicurezza restano sostanzialmente quelle dell'architettura MPLS [RFC3031] e del framework di sicurezza MPLS/GMPLS [RFC5920].

L'aumento dello stack di etichette può tuttavia causare frammentazione e rendere i pacchetti non elaborabili da alcune implementazioni. Il documento offre un modo conforme al protocollo per far crescere lo stack mediante coppie aggiuntive {XL,ESPL} con maggiore frequenza rispetto all'inserimento di singole etichette "rogue". Ciò potrebbe consentire di attaccare nodi capaci di elaborare soltanto stack di dimensione limitata senza violare le regole del protocollo.

Il documento descrive inoltre eventi che potrebbero indurre un LSR a produrre registri alla frequenza di un evento per pacchetto. È essenziale che le implementazioni limitino la frequenza di tali registrazioni.

7. Ringraziamenti

Si ringraziano Pablo Frank e Lizhong Jin per le discussioni utili, nonché Curtis Villamizar, Mach Chen, Alia Atlas, Eric Rosen, Maria Napierala, Roni Even, Stewart Bryant, John Drake, Andy Malis e Tom Yu per i commenti.

8. Riferimenti

8.1. Riferimenti normativi

• [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, marzo 1997.
• [RFC3031] E. Rosen, A. Viswanathan e R. Callon, "Multiprotocol Label Switching Architecture", gennaio 2001.
• [RFC3032] E. Rosen et al., "MPLS Label Stack Encoding", gennaio 2001.
• [RFC3038] K. Nagami et al., "VCID Notification over ATM link for LDP", gennaio 2001.
• [RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", dicembre 2001.
• [RFC3811] T. Nadeau e J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", giugno 2004.
• [RFC4182] E. Rosen, "Removing a Restriction on the use of MPLS Explicit NULL", settembre 2005.
• [RFC4928] G. Swallow, S. Bryant e L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, giugno 2007.
• [RFC5226] T. Narten e H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, maggio 2008.
• [RFC5331] R. Aggarwal, Y. Rekhter ed E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", agosto 2008.
• [RFC5960] D. Frost, S. Bryant e M. Bocci, "MPLS Transport Profile Data Plane Architecture", agosto 2010.
• [RFC6391] S. Bryant et al., "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", novembre 2011.
• [RFC6478] L. Martini et al., "Pseudowire Status for Static Pseudowires", maggio 2012.
• [RFC6790] K. Kompella et al., "The Use of Entropy Labels in MPLS Forwarding", novembre 2012.
• [RFC7120] M. Cotton, "Early IANA Allocation of Standards Track Code Points", BCP 100, gennaio 2014.

8.2. Riferimenti informativi

• [RFC3429] H. Ohta, "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", novembre 2002.
• [RFC5586] M. Bocci, M. Vigoureux e S. Bryant, "MPLS Generic Associated Channel", giugno 2009.
• [RFC5920] L. Fang, "Security Framework for MPLS and GMPLS Networks", luglio 2010.
• [RFC5921] M. Bocci et al., "A Framework for MPLS in Transport Networks", luglio 2010.

Indirizzi degli autori

Kireeti Kompella — Juniper Networks, 1194 N. Mathilda Ave, Sunnyvale, CA 94089, US — [email protected]

Loa Andersson — Huawei — [email protected]

Adrian Farrel — Juniper Networks — [email protected]