3.4. Encodages TLV pour les paramètres couramment utilisés
Plusieurs paramètres sont utilisés par plus d'un message LDP. Les encodages TLV de ces paramètres couramment utilisés sont spécifiés dans cette section.
3.4.1. FEC TLV
Les étiquettes sont liées à des classes d'équivalence de transfert (Forwarding Equivalence Class, FEC). Une FEC est une liste d'un ou plusieurs éléments de FEC. Le FEC TLV encode des éléments FEC.
Son encodage est :
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 Il existe plusieurs types d'éléments de FEC ; voir la section "FECs". L'encodage de l'élément de FEC dépend du type d'élément de FEC.
Une valeur d'élément de FEC est encodée sous la forme d'un champ de 1 octet qui spécifie le type de l'élément, et d'un champ de longueur variable qui est la valeur de l'élément dépendant du type. Notez que, bien que la représentation de la valeur de l'élément de FEC dépende du type, l'encodage de l'élément de FEC lui-même est un encodage dans lequel l'encodage TLV standard de LDP n'est pas utilisé.
L'encodage de la valeur d'un élément de FEC est :
FEC Element Type Value
type name
Wildcard 0x01 No value; i.e., 0 value octets;
see below.
Prefix 0x02 See below.
Notez que cette version de LDP ne prend en charge l'utilisation de plusieurs FEC Elements par FEC que pour le message Label Mapping. L'utilisation de plusieurs FEC Elements dans d'autres messages n'est pas autorisée dans cette version et constitue un sujet d'étude future.
Wildcard FEC Element
À utiliser uniquement dans les messages Label Withdraw et Label Release. Indique que le retrait/la libération doit s'appliquer à toutes les FEC associées à l'étiquette dans le Label TLV qui suit. Doit être le seul FEC Element du FEC TLV.
Encodage de la valeur du 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é de deux octets contenant une valeur issue de ADDRESS FAMILY NUMBERS dans [ASSIGNED_AF] qui encode la famille d'adresses du préfixe d'adresse dans le champ Prefix.
PreLen
Entier non signé d'un octet contenant la longueur en bits du préfixe d'adresse qui suit. Une longueur de zéro indique un préfixe qui correspond à toutes les adresses (la destination par défaut) ; dans ce cas, le Prefix lui-même fait zéro octet.
Prefix
Un préfixe d'adresse encodé conformément au champ Address Family, dont la longueur, en bits, a été spécifiée dans le champ PreLen, complété jusqu'à une limite d'octet.
3.4.1.1. Procédures FEC
Si, en décodant un FEC TLV, un LSR rencontre un FEC Element dont l'Address Family n'est pas prise en charge, il DEVRAIT (SHOULD) arrêter de décoder le FEC TLV, interrompre le traitement du message contenant le TLV, et envoyer à son pair LDP un message Notification "Unsupported Address Family" signalant une erreur.
S'il rencontre un type de FEC Element qu'il ne peut pas décoder, il DEVRAIT (SHOULD) arrêter de décoder le FEC TLV, interrompre le traitement du message contenant le TLV, et envoyer à son pair LDP un message Notification "Unknown FEC" signalant une erreur.
3.4.2. Label TLVs
Les Label TLVs encodent des étiquettes. Les Label TLVs sont transportés par les messages utilisés pour annoncer, demander, libérer et retirer des mappages d'étiquettes.
Il existe plusieurs sortes différentes de Label TLVs susceptibles d'apparaître dans des situations qui requièrent un Label TLV.
3.4.2.1. Generic Label TLV
Un LSR utilise les Generic Label TLVs pour encoder des étiquettes destinées à être utilisées sur des liaisons pour lesquelles les valeurs d'étiquettes sont indépendantes de la technologie de liaison sous-jacente. Des exemples de telles liaisons sont PPP et 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 Il s'agit d'une valeur d'étiquette de 20 bits représentée sous forme d'un nombre de 20 bits dans un champ de 4 octets comme suit :
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pour plus d'informations, voir [RFC3032].
3.4.2.2. ATM Label TLV
Un LSR utilise les ATM Label TLVs pour encoder des étiquettes destinées à être utilisées sur des liaisons 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 Ce champ est réservé. Il DOIT (MUST) être mis à zéro à l'émission et DOIT (MUST) être ignoré à la réception.
V-bits Indicateur de commutation sur deux bits. Si V-bits vaut 00, le VPI et le VCI sont tous deux significatifs. Si V-bits vaut 01, seul le champ VPI est significatif. Si V-bit vaut 10, seul le VCI est significatif.
VPI Virtual Path Identifier. Si le VPI fait moins de 12 bits, il DEVRAIT (SHOULD) être justifié à droite dans ce champ et les bits précédents DEVRAIENT (SHOULD) être mis à 0.
VCI Virtual Channel Identifier. Si le VCI fait moins de 16 bits, il DEVRAIT (SHOULD) être justifié à droite dans le champ et les bits précédents DOIVENT (MUST) être mis à 0. Si une commutation de Virtual Path est indiquée dans le champ V-bits, alors ce champ DOIT (MUST) être ignoré par le récepteur et mis à 0 par l'émetteur.
3.4.2.3. Frame Relay Label TLV
Un LSR utilise les Frame Relay Label TLVs pour encoder des étiquettes destinées à être utilisées sur des liaisons 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 Ce champ est réservé. Il DOIT (MUST) être mis à zéro à l'émission et DOIT (MUST) être ignoré à la réception.
Len Ce champ spécifie le nombre de bits du DLCI. Les valeurs suivantes sont prises en charge :
0 = 10 bits de DLCI
2 = 23 bits de DLCI
Les valeurs de Len 1 et 3 sont réservées.
DLCI Le Data Link Connection Identifier
Pour un DLCI de 10 bits, l'encodage est :
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pour un DLCI de 23 bits, l'encodage est :
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pour plus d'informations, voir [RFC3034].
3.4.3. Address List TLV
L'Address List TLV apparaît dans les messages Address et Address Withdraw.
Son encodage est :
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é de deux octets contenant une valeur issue de ADDRESS FAMILY NUMBERS dans [ASSIGNED_AF] qui encode les adresses contenues dans le champ Addresses.
Addresses Une liste d'adresses de la famille d'adresses spécifiée. L'encodage des adresses individuelles dépend de l'Address Family.
Les encodages d'adresses suivants sont définis par cette version du protocole :
Address Family Address Encoding
IPv4 4 octet full IPv4 address
IPv6 16 octet full IPv6 address
3.4.4. Hop Count TLV
Le Hop Count TLV apparaît comme champ optionnel dans les messages qui établissent des LSP. Il calcule le nombre de sauts de LSR le long d'un LSP au fur et à mesure de l'établissement du LSP.
Notez que les procédures d'établissement des LSP qui traversent des liaisons ATM et Frame Relay exigent l'utilisation du Hop Count TLV (voir [RFC3035] et [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 Valeur de nombre de sauts, entier non signé d'un octet.
3.4.4.1. Procédures Hop Count
Pendant l'établissement d'un LSP, un LSR R peut recevoir un message Label Mapping ou Label Request pour le LSP qui contient le Hop Count TLV. Si c'est le cas, il DEVRAIT (SHOULD) enregistrer la valeur du nombre de sauts.
Si le LSR R propage ensuite le message Label Mapping du LSP à un pair en amont, ou le message Label Request à un pair en aval, pour poursuivre l'établissement du LSP, il doit déterminer un nombre de sauts à inclure dans le message propagé de la manière suivante :
-
Si le message est un message Label Request, R DOIT (MUST) incrémenter le nombre de sauts reçu ;
-
Si le message est un message Label Mapping, R détermine le nombre de sauts comme suit :
o Si R est membre de l'ensemble de bordure d'un domaine de LSR dont les LSR n'effectuent pas de 'TTL-decrement' et que le pair en amont se trouve dans ce domaine, R DOIT (MUST) réinitialiser le nombre de sauts à 1 avant de propager le message.
o Sinon, R DOIT (MUST) incrémenter le nombre de sauts reçu.
Le premier LSR du LSP (ingress pour un message Label Request, egress pour un message Label Mapping) DEVRAIT (SHOULD) mettre la valeur du nombre de sauts à 1.
Par convention, une valeur de 0 indique un nombre de sauts inconnu. Le résultat de l'incrémentation d'un nombre de sauts inconnu est lui-même un nombre de sauts inconnu (0).
L'utilisation de la valeur de nombre de sauts inconnu réduit grandement la surcharge de signalisation lorsque le contrôle indépendant est utilisé. Lorsqu'un nouveau LSP est établi, chaque LSR commence avec un nombre de sauts inconnu. L'ajout d'un nouveau LSR dont le nombre de sauts est également inconnu ne provoque pas la propagation d'une mise à jour du nombre de sauts en amont, puisque le nombre de sauts reste inconnu. Lorsque l'egress est finalement ajouté au LSP, les LSR propagent alors les mises à jour du nombre de sauts en amont via des messages Label Mapping.
Sans utilisation du nombre de sauts inconnu, chaque fois qu'un nouveau LSR est ajouté au LSP, une mise à jour du nombre de sauts devrait être propagée en amont si le nouveau LSR est plus proche de l'egress que tous les autres LSR. Ces mises à jour constituent une surcharge inutile, puisqu'elles ne reflètent pas le nombre de sauts jusqu'à l'egress.
Du point de vue du nœud d'entrée, le fait que le nombre de sauts soit inconnu n'implique rien quant à la question de savoir si un paquet envoyé sur le LSP parviendra effectivement à l'egress. Tout ce qu'il implique est que la mise à jour du nombre de sauts provenant de l'egress n'a pas encore atteint le nœud d'entrée.
Si un LSR reçoit un message contenant un Hop Count TLV, il DOIT (MUST) vérifier la valeur du nombre de sauts pour déterminer si le nombre de sauts a dépassé sa valeur maximale autorisée configurée. Si c'est le cas, il DOIT (MUST) se comporter comme si le message conteneur avait traversé une boucle, en envoyant un message Notification signalant Loop Detected en réponse à l'émetteur du message.
Si la détection de boucles est configurée, le LSR DOIT (MUST) suivre les procédures spécifiées dans la section "Loop Detection".
3.4.5. Path Vector TLV
Le Path Vector TLV est utilisé conjointement avec le Hop Count TLV dans les messages Label Request et Label Mapping pour mettre en œuvre le mécanisme optionnel de détection de boucles LDP. Voir la section "Loop Detection". Son utilisation dans le message Label Request enregistre le chemin des LSR qu'a parcouru la demande. Son utilisation dans le message Label Mapping enregistre le chemin des LSR qu'a parcouru une annonce d'étiquettes pour établir un LSP. Son encodage est :
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 Une liste de router-ids indiquant le chemin des LSR que le message a parcourus. Chaque LSR Id correspond aux quatre premiers octets (router-id) du LDP Identifier du LSR correspondant. Cela garantit son unicité au sein du réseau de LSR.
3.4.5.1. Procédures Path Vector
Le Path Vector TLV est transporté dans les messages Label Mapping et Label Request lorsque la détection de boucles est configurée.
3.4.5.1.1. Path Vector du Label Request
La section "Loop Detection" spécifie les situations dans lesquelles un LSR doit inclure un Path Vector TLV dans un message Label Request.
Un LSR qui reçoit un Path Vector dans un message Label Request DOIT (MUST) exécuter les procédures décrites dans la section "Loop Detection".
Si le LSR détecte une boucle, il DOIT (MUST) rejeter le message Label Request.
Le LSR DOIT (MUST) :
-
Transmettre au LSR émetteur un message Notification signalant "Loop Detected".
-
Ne pas propager davantage le message Label Request.
Notez qu'un message Label Request portant un Path Vector TLV est transmis jusqu'à ce que :
-
Une boucle soit trouvée,
-
L'egress du LSP soit atteint, ou
-
La limite maximale de Path Vector ou la limite maximale de Hop Count soit atteinte. Ceci est traité comme si une boucle avait été détectée.
3.4.5.1.2. Path Vector du Label Mapping
La section "Loop Detection" spécifie les situations dans lesquelles un LSR doit inclure un Path Vector TLV dans un message Label Mapping.
Un LSR qui reçoit un Path Vector dans un message Label Mapping DOIT (MUST) exécuter les procédures décrites dans la section "Loop Detection".
Si le LSR détecte une boucle, il DOIT (MUST) rejeter le message Label Mapping afin d'empêcher une boucle de transfert. Le LSR DOIT (MUST) :
-
Transmettre au LSR émetteur un message Label Release portant un Status TLV pour signaler "Loop Detected".
-
Ne pas propager davantage le message.
-
Vérifier si le message Label Mapping concerne un LSP existant. Si c'est le cas, le LSR doit dé-épisser toute étiquette en amont qui est épissée à l'étiquette en aval pour la FEC.
Notez qu'un message Label Mapping portant un Path Vector TLV est transmis jusqu'à ce que :
-
Une boucle soit trouvée,
-
Un ingress de LSP soit atteint, ou
-
La limite maximale de Path Vector ou la limite maximale de Hop Count soit atteinte. Ceci est traité comme si une boucle avait été détectée.
3.4.6. Status TLV
Les messages Notification transportent des Status TLVs pour spécifier les événements signalés.
L'encodage du Status TLV est :
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 DEVRAIT (SHOULD) être 0 lorsque le Status TLV est envoyé dans un message Notification. DEVRAIT (SHOULD) être 1 lorsque le Status TLV est envoyé dans un autre message.
F-bit DEVRAIT (SHOULD) être identique au réglage du F-bit dans le champ Status Code.
Status Code Entier non signé de 32 bits encodant l'événement signalé. La structure d'un Status Code est :
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 Fatal error bit. S'il est à 1, il s'agit d'une Error Notification fatale. S'il est à 0, il s'agit d'une Advisory Notification.
F-bit Forward bit. S'il est à 1, la notification DEVRAIT (SHOULD) être transmise au LSR correspondant au next-hop ou au previous-hop du LSP, le cas échéant, associé à l'événement signalé. S'il est à 0, la notification NE DEVRAIT PAS (SHOULD NOT) être transmise.
Status Data Entier non signé de 30 bits qui spécifie les informations de statut.
Cette spécification définit des Status Codes (entiers non signés de 32 bits avec l'encodage ci-dessus).
Un Status Code de 0 signale un succès.
Message ID S'il est non nul, valeur de 32 bits qui identifie le message du pair auquel le Status TLV se réfère. S'il est nul, aucun message de pair spécifique n'est identifié.
Message Type S'il est non nul, le type du message du pair auquel le Status TLV se réfère. S'il est nul, le Status TLV ne se réfère à aucun type de message spécifique.
Notez que l'utilisation du Status TLV n'est pas limitée aux messages Notification. Un message autre qu'un message Notification peut transporter un Status TLV comme Optional Parameter. Lorsqu'un message autre qu'une Notification transporte un Status TLV, le U-bit du Status TLV DEVRAIT (SHOULD) être mis à 1 pour indiquer que le récepteur DEVRAIT (SHOULD) écarter silencieusement le TLV s'il n'est pas préparé à le traiter.