3.4. Codifiche TLV per parametri di uso comune
Diversi parametri sono usati da più di un messaggio LDP. Le codifiche TLV per questi parametri di uso comune sono specificate in questa sezione.
3.4.1. TLV FEC
Le etichette sono associate alle Forwarding Equivalence Class (FEC). Una FEC è un elenco di uno o più FEC element. Il TLV FEC codifica gli elementi FEC.
La sua codifica è:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FEC (0x0100) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Element 1 to FEC Element n Esistono diversi tipi di FEC element; vedere la sezione "FECs". La codifica del FEC element dipende dal tipo di FEC element.
Il valore di un FEC Element è codificato come un campo di 1 ottetto che specifica il tipo di elemento, e un campo di lunghezza variabile che è il valore dell'elemento, dipendente dal tipo. Si noti che, sebbene la rappresentazione del valore del FEC element dipenda dal tipo, la codifica del FEC element stesso è una in cui la codifica TLV standard di LDP non viene usata.
La codifica del valore del FEC Element è:
FEC Element Type Value
type name
Wildcard 0x01 No value; i.e., 0 value octets;
see below.
Prefix 0x02 See below.
Si noti che questa versione di LDP supporta l'uso di più FEC Elements per FEC solo per il messaggio Label Mapping. L'uso di più FEC Elements in altri messaggi non è consentito in questa versione ed è oggetto di studi futuri.
Wildcard FEC Element
Da usare solo nei messaggi Label Withdraw e Label Release. Indica che il ritiro/rilascio deve essere applicato a tutte le FEC associate all'etichetta all'interno del seguente TLV label. Deve essere l'unico FEC Element nel TLV FEC.
Codifica del valore del Prefix FEC Element:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family
Quantità di due ottetti contenente un valore tratto da ADDRESS FAMILY NUMBERS in [ASSIGNED_AF] che codifica l'address family per il prefisso di indirizzo nel campo Prefix.
PreLen
Intero senza segno di un ottetto contenente la lunghezza in bit del prefisso di indirizzo che segue. Una lunghezza di zero indica un prefisso che corrisponde a tutti gli indirizzi (la destinazione predefinita); in questo caso, il Prefix stesso è di zero ottetti).
Prefix
Un prefisso di indirizzo codificato secondo il campo Address Family, la cui lunghezza, in bit, è stata specificata nel campo PreLen, con riempimento fino a un confine di byte.
3.4.1.1. Procedure FEC
Se, decodificando un TLV FEC, un LSR incontra un FEC Element con un'Address Family che non supporta, DOVREBBE (SHOULD) smettere di decodificare il TLV FEC, interrompere l'elaborazione del messaggio che contiene il TLV e inviare al proprio peer LDP un messaggio Notification "Unsupported Address Family" segnalando un errore.
Se incontra un tipo di FEC Element che non riesce a decodificare, DOVREBBE (SHOULD) smettere di decodificare il TLV FEC, interrompere l'elaborazione del messaggio che contiene il TLV e inviare al proprio peer LDP un messaggio Notification "Unknown FEC" segnalando un errore.
3.4.2. TLV Label
I TLV Label codificano le etichette. I TLV Label sono trasportati dai messaggi usati per pubblicizzare, richiedere, rilasciare e ritirare mappature di etichette.
Esistono diversi tipi di TLV Label che possono comparire in situazioni che richiedono un TLV Label.
3.4.2.1. TLV Generic Label
Un LSR usa i TLV Generic Label per codificare le etichette da usare su collegamenti per i quali i valori delle etichette sono indipendenti dalla tecnologia di collegamento sottostante. Esempi di tali collegamenti sono PPP ed Ethernet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Questo è un valore di etichetta a 20 bit rappresentato come numero a 20 bit in un campo di 4 ottetti come segue:
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Per ulteriori informazioni, vedere la [RFC3032].
3.4.2.2. TLV ATM Label
Un LSR usa i TLV ATM Label per codificare le etichette da usare sui collegamenti ATM.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| ATM Label (0x0201) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| V | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res Questo campo è riservato. DEVE (MUST) essere posto a zero alla trasmissione e DEVE (MUST) essere ignorato alla ricezione.
V-bits Indicatore di commutazione a due bit. Se V-bits è 00, sia il VPI sia il VCI sono significativi. Se V-bits è 01, solo il campo VPI è significativo. Se V-bit è 10, solo il VCI è significativo.
VPI Virtual Path Identifier. Se il VPI è inferiore a 12 bit, DOVREBBE (SHOULD) essere allineato a destra in questo campo e i bit precedenti DOVREBBERO (SHOULD) essere posti a 0.
VCI Virtual Channel Identifier. Se il VCI è inferiore a 16 bit, DOVREBBE (SHOULD) essere allineato a destra nel campo e i bit precedenti DEVONO (MUST) essere posti a 0. Se nel campo V-bits è indicata la commutazione di Virtual Path, allora questo campo DEVE (MUST) essere ignorato dal ricevitore e posto a 0 dal mittente.
3.4.2.3. TLV Frame Relay Label
Un LSR usa i TLV Frame Relay Label per codificare le etichette da usare sui collegamenti Frame Relay.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res Questo campo è riservato. DEVE (MUST) essere posto a zero alla trasmissione e DEVE (MUST) essere ignorato alla ricezione.
Len Questo campo specifica il numero di bit del DLCI. Sono supportati i seguenti valori:
0 = 10 bits of DLCI
2 = 23 bits of DLCI
I valori Len 1 e 3 sono riservati.
DLCI Il Data Link Connection Identifier
Per un DLCI a 10 bit, la codifica è:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| 0 | 10-bit DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Per un DLCI a 23 bit, la codifica è:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| 23-bit DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Per ulteriori informazioni, vedere la [RFC3034].
3.4.3. TLV Address List
Il TLV Address List compare nei messaggi Address e Address Withdraw.
La sua codifica è:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Addresses |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family Quantità di due ottetti contenente un valore tratto da ADDRESS FAMILY NUMBERS in [ASSIGNED_AF] che codifica gli indirizzi contenuti nel campo Addresses.
Addresses Un elenco di indirizzi della Address Family specificata. La codifica dei singoli indirizzi dipende dall'Address Family.
Le seguenti codifiche di indirizzo sono definite da questa versione del protocollo:
Address Family Address Encoding
IPv4 4 octet full IPv4 address
IPv6 16 octet full IPv6 address
3.4.4. TLV Hop Count
Il TLV Hop Count compare come campo opzionale nei messaggi che configurano gli LSP. Calcola il numero di hop LSR lungo un LSP mentre l'LSP viene configurato.
Si noti che le procedure di configurazione degli LSP che attraversano collegamenti ATM e Frame Relay richiedono l'uso del TLV Hop Count (vedere [RFC3035] e [RFC3034]).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Hop Count (0x0103) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC Value |
+-+-+-+-+-+-+-+-+
HC Value Valore di hop count come intero senza segno di 1 ottetto.
3.4.4.1. Procedure del Hop Count
Durante la configurazione di un LSP, un LSR R può ricevere un messaggio Label Mapping o Label Request per l'LSP che contiene il TLV Hop Count. In tal caso, DOVREBBE (SHOULD) registrare il valore di hop count.
Se poi l'LSR R propaga il messaggio Label Mapping per l'LSP a un peer a monte o il messaggio Label Request a un peer a valle per continuare la configurazione dell'LSP, deve determinare un hop count da includere nel messaggio propagato come segue:
-
Se il messaggio è un messaggio Label Request, R DEVE (MUST) incrementare l'hop count ricevuto;
-
Se il messaggio è un messaggio Label Mapping, R determina l'hop count come segue:
o Se R è un membro dell'edge set di un dominio LSR i cui LSR non effettuano il 'TTL-decrement' e il peer a monte è all'interno di quel dominio, R DEVE (MUST) reimpostare l'hop count a 1 prima di propagare il messaggio.
o In caso contrario, R DEVE (MUST) incrementare l'hop count ricevuto.
Il primo LSR nell'LSP (ingress per un messaggio Label Request, egress per un messaggio Label Mapping) DOVREBBE (SHOULD) porre il valore di hop count a 1.
Per convenzione, un valore di 0 indica un hop count sconosciuto. Il risultato dell'incremento di un hop count sconosciuto è esso stesso un hop count sconosciuto (0).
L'uso del valore di hop count sconosciuto riduce notevolmente il sovraccarico di segnalazione quando si usa il controllo indipendente. Quando viene stabilito un nuovo LSP, ciascun LSR parte con un hop count sconosciuto. L'aggiunta di un nuovo LSR il cui hop count è anch'esso sconosciuto non provoca la propagazione a monte di un aggiornamento dell'hop count, poiché l'hop count rimane sconosciuto. Quando l'egress viene finalmente aggiunto all'LSP, gli LSR propagano gli aggiornamenti dell'hop count a monte tramite messaggi Label Mapping.
Senza l'uso dell'hop count sconosciuto, ogni volta che un nuovo LSR viene aggiunto all'LSP un aggiornamento dell'hop count dovrebbe essere propagato a monte se il nuovo LSR è più vicino all'egress rispetto a qualsiasi altro LSR. Questi aggiornamenti sono sovraccarico inutile, poiché non riflettono l'hop count verso l'egress.
Dal punto di vista del nodo ingress, il fatto che l'hop count sia sconosciuto non implica nulla circa la possibilità che un pacchetto inviato sull'LSP arrivi effettivamente all'egress. Tutto ciò che implica è che l'aggiornamento dell'hop count dall'egress non ha ancora raggiunto l'ingress.
Se un LSR riceve un messaggio contenente un TLV Hop Count, DEVE (MUST) verificare il valore di hop count per determinare se l'hop count ha superato il proprio valore massimo consentito configurato. In tal caso, DEVE (MUST) comportarsi come se il messaggio contenitore avesse attraversato un loop, inviando un messaggio Notification che segnala Loop Detected in risposta al mittente del messaggio.
Se il rilevamento dei loop è configurato, l'LSR DEVE (MUST) seguire le procedure specificate nella sezione "Loop Detection".
3.4.5. TLV Path Vector
Il TLV Path Vector è usato insieme al TLV Hop Count nei messaggi Label Request e Label Mapping per implementare il meccanismo opzionale di LDP Loop Detection. Vedere la sezione "Loop Detection". Il suo uso nel messaggio Label Request registra il percorso degli LSR attraversati dalla richiesta. Il suo uso nel messaggio Label Mapping registra il percorso degli LSR attraversati da un advertisement di etichette per configurare un LSP. La sua codifica è:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Path Vector (0x0104) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One or more LSR Ids Un elenco di router-id che indica il percorso degli LSR attraversati dal messaggio. Ciascun LSR Id è costituito dai primi quattro ottetti (router-id) dell'LDP Identifier del corrispondente LSR. Ciò ne garantisce l'unicità all'interno della rete LSR.
3.4.5.1. Procedure del Path Vector
Il TLV Path Vector è trasportato nei messaggi Label Mapping e Label Request quando il rilevamento dei loop è configurato.
3.4.5.1.1. Path Vector nel Label Request
La sezione "Loop Detection" specifica le situazioni in cui un LSR deve includere un TLV Path Vector in un messaggio Label Request.
Un LSR che riceve un Path Vector in un messaggio Label Request DEVE (MUST) eseguire le procedure descritte nella sezione "Loop Detection".
Se l'LSR rileva un loop, DEVE (MUST) rifiutare il messaggio Label Request.
L'LSR DEVE (MUST):
-
Trasmettere all'LSR mittente un messaggio Notification che segnala "Loop Detected".
-
Non propagare ulteriormente il messaggio Label Request.
Si noti che un messaggio Label Request con un TLV Path Vector viene inoltrato finché:
-
non viene trovato un loop,
-
non si raggiunge l'egress dell'LSP, oppure
-
non si raggiunge il limite massimo di Path Vector o il limite massimo di Hop Count. Ciò è trattato come se fosse stato rilevato un loop.
3.4.5.1.2. Path Vector nel Label Mapping
La sezione "Loop Detection" specifica le situazioni in cui un LSR deve includere un TLV Path Vector in un messaggio Label Mapping.
Un LSR che riceve un Path Vector in un messaggio Label Mapping DEVE (MUST) eseguire le procedure descritte nella sezione "Loop Detection".
Se l'LSR rileva un loop, DEVE (MUST) rifiutare il messaggio Label Mapping al fine di prevenire un loop di inoltro. L'LSR DEVE (MUST):
-
Trasmettere all'LSR mittente un messaggio Label Release che trasporta un TLV Status per segnalare "Loop Detected".
-
Non propagare ulteriormente il messaggio.
-
Verificare se il messaggio Label Mapping è per un LSP esistente. In tal caso, l'LSR deve rimuovere lo splicing di qualsiasi etichetta a monte che è collegata (spliced) all'etichetta a valle per la FEC.
Si noti che un messaggio Label Mapping con un TLV Path Vector viene inoltrato finché:
-
non viene trovato un loop,
-
non si raggiunge un ingress dell'LSP, oppure
-
non si raggiunge il limite massimo di Path Vector o il limite massimo di Hop Count. Ciò è trattato come se fosse stato rilevato un loop.
3.4.6. TLV Status
I messaggi Notification trasportano i TLV Status per specificare gli eventi segnalati.
La codifica del TLV Status è:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U-bit DOVREBBE (SHOULD) essere 0 quando il TLV Status viene inviato in un messaggio Notification. DOVREBBE (SHOULD) essere 1 quando il TLV Status viene inviato in qualche altro messaggio.
F-bit DOVREBBE (SHOULD) essere uguale all'impostazione del bit F nel campo Status Code.
Status Code Intero senza segno a 32 bit che codifica l'evento segnalato. La struttura di uno Status Code è:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|F| Status Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-bit Bit di errore fatale. Se posto (=1), questa è una Notification di errore fatale. Se azzerato (=0), questa è una Notification indicativa.
F-bit Bit di inoltro. Se posto (=1), la notifica DOVREBBE (SHOULD) essere inoltrata all'LSR per il next-hop o previous-hop per l'LSP, se esiste, associato all'evento segnalato. Se azzerato (=0), la notifica NON DOVREBBE (SHOULD NOT) essere inoltrata.
Status Data Intero senza segno a 30 bit che specifica le informazioni di stato.
Questa specifica definisce gli Status Code (interi senza segno a 32 bit con la codifica di cui sopra).
Uno Status Code di 0 indica successo.
Message ID Se non nullo, valore a 32 bit che identifica il messaggio del peer a cui il TLV Status si riferisce. Se nullo, non viene identificato alcun messaggio specifico del peer.
Message Type Se non nullo, il tipo del messaggio del peer a cui il TLV Status si riferisce. Se nullo, il TLV Status non si riferisce ad alcun tipo di messaggio specifico.
Si noti che l'uso del TLV Status non è limitato ai messaggi Notification. Un messaggio diverso da un messaggio Notification può trasportare un TLV Status come parametro opzionale. Quando un messaggio diverso da un Notification trasporta un TLV Status, il bit U del TLV Status DOVREBBE (SHOULD) essere posto a 1 per indicare che il ricevitore DOVREBBE (SHOULD) scartare silenziosamente il TLV se non è preparato a gestirlo.