RFC 4379 - 3. Packet Format
3. Format des paquets (Packet Format)
Cette section définit les types de message, les modes de réponse, les codes de retour et les TLV utilisés par les messages MPLS echo.
Une MPLS echo request est un paquet UDP IPv4 ou IPv6 (éventuellement étiqueté) ; le contenu du paquet UDP a le format suivant :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Version Number est actuellement 1. (Remarque : le numéro de version doit être incrémenté chaque fois qu'une modification est apportée qui affecte la capacité d'une implémentation à analyser ou traiter correctement une MPLS echo request/reply. Ces modifications comprennent tout changement syntaxique ou sémantique apporté à l'un des champs fixes, ou à l'affectation ou au format d'un Type-Length-Value (TLV) ou sous-TLV défini à un certain numéro de version. Le numéro de version peut ne pas avoir besoin d'être modifié si un TLV ou sous-TLV facultatif est ajouté.)
Le champ Global Flags est un vecteur de bits au format suivant :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Un seul indicateur est défini pour l'instant, le bit V ; les autres bits doivent être mis à zéro à l'émission et sont ignorés à la réception (MUST).
L'indicateur V (Validate FEC Stack) est positionné à 1 si l'émetteur souhaite que le destinataire effectue une validation de la pile FEC (FEC Stack validation) ; si V vaut 0, le choix est laissé au destinataire.
Le Message Type est l'un des suivants :
| Valeur | Signification |
|---|---|
| 1 | MPLS echo request (demande d'écho MPLS) |
| 2 | MPLS echo reply (réponse d'écho MPLS) |
Le Reply Mode peut prendre l'une des valeurs suivantes :
| Valeur | Signification |
|---|---|
| 1 | Do not reply (ne pas répondre) |
| 2 | Reply via an IPv4/IPv6 UDP packet (répondre par un paquet UDP IPv4/IPv6) |
| 3 | Reply via an IPv4/IPv6 UDP packet with Router Alert (répondre par un paquet UDP IPv4/IPv6 avec Router Alert) |
| 4 | Reply via application level control channel (répondre via un canal de contrôle de couche application) |
Une MPLS echo request comportant 1 (ne pas répondre) dans le champ Reply Mode peut être utilisée pour des tests de connectivité unidirectionnels ; le routeur récepteur peut journaliser les lacunes dans les Sequence Number et/ou tenir des statistiques de délai et de gigue. Une MPLS echo request comportera normalement 2 (répondre par un paquet UDP IPv4/IPv6) dans le champ Reply Mode. Si le chemin de retour IP normal est jugé peu fiable, on peut utiliser 3 (répondre par un paquet UDP IPv4/IPv6 avec Router Alert). Notez que cela exige que tous les routeurs intermédiaires comprennent les MPLS echo reply et sachent les acheminer. L'echo reply utilise le même numéro de version IP que l'echo request reçue, c'est-à-dire qu'un echo reply encapsulé en IPv4 est envoyé en réponse à une echo request encapsulée en IPv4.
Certaines applications prennent en charge un canal de contrôle IP. Un exemple est le canal de contrôle associé (associated control channel) défini dans Virtual Circuit Connectivity Verification (VCCV) [VCCV]. Toute application qui prend en charge un canal de contrôle IP entre ses entités de contrôle peut positionner le Reply Mode à 4 (répondre via un canal de contrôle de couche application) pour garantir que les réponses utilisent ce même canal. Une définition plus poussée de ce codepoint est propre à l'application et donc hors du champ d'application de ce document.
Les codes et sous-codes de retour sont décrits dans la section suivante.
Le Sender's Handle est rempli par l'émetteur et renvoyé inchangé par le destinataire dans l'echo reply (le cas échéant). Aucune sémantique n'est associée à ce handle, bien qu'un émetteur puisse le trouver utile pour associer les requêtes aux réponses.
Le Sequence Number est attribué par l'émetteur de la MPLS echo request et peut être utilisé (par exemple) pour détecter les réponses manquantes.
Le TimeStamp Sent est l'heure du jour (en secondes et microsecondes, selon l'horloge de l'émetteur) au format NTP [NTP] au moment où la MPLS echo request est envoyée. Le TimeStamp Received dans un echo reply est l'heure du jour (selon l'horloge du destinataire) au format NTP à laquelle l'echo request correspondante a été reçue.
Les TLV (tuples Type-Length-Value) ont le format suivant :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Les types sont définis ci-dessous ; Length est la longueur du champ Value en octets. Le champ Value dépend du Type ; il est complété par des zéros pour être aligné sur une frontière de 4 octets. Les TLV peuvent être imbriqués dans d'autres TLV, auquel cas les TLV imbriqués sont appelés sous-TLV. Les sous-TLV ont des types indépendants et doivent également être alignés sur 4 octets (MUST).
Deux exemples suivent. Le sous-TLV LDP IPv4 FEC du Label Distribution Protocol (LDP) a le format suivant :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La Length de ce TLV est 5. Un TLV pile FEC cible contenant un sous-TLV LDP IPv4 FEC et un sous-TLV préfixe IPv4 VPN a le format suivant :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (FEC TLV) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 1 (LDP IPv4 FEC) | Length = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-Type = 6 (VPN IPv4 prefix)| Length = 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Une description des types et des valeurs (Types and Values) des TLV de niveau supérieur pour LSP ping est donnée ci-dessous :
| N° de type (Type #) | Champ valeur (Value Field) |
|---|---|
| 1 | Target FEC Stack (pile FEC cible) |
| 2 | Downstream Mapping (correspondance aval) |
| 3 | Pad (remplissage) |
| 4 | Not Assigned (non attribué) |
| 5 | Vendor Enterprise Number (numéro d'entreprise du fournisseur) |
| 6 | Not Assigned (non attribué) |
| 7 | Interface and Label Stack (pile interface et étiquettes) |
| 8 | Not Assigned (non attribué) |
| 9 | Errored TLVs (TLV erronés) |
| 10 | Reply TOS Byte (octet TOS de réponse) |
Les types inférieurs à 32768 (c'est-à-dire dont le bit de poids fort vaut 0) sont des TLV obligatoires (mandatory) qui doivent soit être pris en charge par une implémentation, soit entraîner l'envoi, dans la réponse echo, du code de retour 2 ("un ou plusieurs des TLV n'ont pas été compris") (MUST).
Les types supérieurs ou égaux à 32768 (c'est-à-dire dont le bit de poids fort vaut 1) sont des TLV facultatifs (optional) qui devraient être ignorés si l'implémentation ne les comprend pas ou ne les prend pas en charge (SHOULD).
3.1. Codes de retour (Return Codes)
Le code de retour est mis à zéro par l'émetteur. Le destinataire peut le positionner à l'une des valeurs listées ci-dessous. La notation
| Valeur | Signification |
|---|---|
| 0 | No return code (Aucun code de retour) |
| 1 | Malformed echo request received (echo request malformée reçue) |
| 2 | One or more of the TLVs was not understood (Un ou plusieurs TLV n'ont pas été compris) |
| 3 | Replying router is an egress for the FEC at stack-depth |
| 4 | Replying router has no mapping for the FEC at stack-depth |
| 5 | Downstream Mapping Mismatch (Non-concordance de la correspondance aval) (voir note 1) |
| 6 | Upstream Interface Index Unknown (Index d'interface amont inconnu) (voir note 1) |
| 7 | Reserved (Réservé) |
| 8 | Label switched at stack-depth |
| 9 | Label switched but no MPLS forwarding at stack-depth |
| 10 | Mapping for this FEC is not the given label at stack-depth |
| 11 | No label entry at stack-depth |
| 12 | Protocol not associated with interface at FEC stack-depth |
| 13 | Premature termination of ping due to label stack shrinking to a single label (Arrêt prématuré du ping dû à la réduction de la pile d'étiquettes à une seule étiquette) |
Note 1
Le sous-code de retour contient le point de la pile d'étiquettes où le traitement a été arrêté. Si le RSC vaut 0, aucune étiquette n'a été traitée. Sinon, le paquet aurait été commuté en étiquette à la profondeur RSC.
3.2. Pile FEC cible (Target FEC Stack)
Une pile FEC cible (Target FEC Stack) est une liste de sous-TLV. Le nombre d'éléments est déterminé en examinant les champs de longueur (Length) des sous-TLV.
| Sous-type (Sub-Type) | Longueur (Length) | Champ valeur (Value Field) |
|---|---|---|
| 1 | 5 | LDP IPv4 prefix (préfixe IPv4 LDP) |
| 2 | 17 | LDP IPv6 prefix (préfixe IPv6 LDP) |
| 3 | 20 | RSVP IPv4 LSP (LSP IPv4 RSVP) |
| 4 | 56 | RSVP IPv6 LSP (LSP IPv6 RSVP) |
| 5 | Not Assigned (non attribué) | |
| 6 | 13 | VPN IPv4 prefix (préfixe IPv4 VPN) |
| 7 | 25 | VPN IPv6 prefix (préfixe IPv6 VPN) |
| 8 | 14 | L2 VPN endpoint (point d'extrémité L2 VPN) |
| 9 | 10 | "FEC 128" Pseudowire ("FEC 128" pseudowire, obsolète) |
| 10 | 14 | "FEC 128" Pseudowire ("FEC 128" pseudowire) |
| 11 | 16+ | "FEC 129" Pseudowire ("FEC 129" pseudowire) |
| 12 | 5 | BGP labeled IPv4 prefix (préfixe IPv4 avec étiquette BGP) |
| 13 | 17 | BGP labeled IPv6 prefix (préfixe IPv6 avec étiquette BGP) |
| 14 | 5 | Generic IPv4 prefix (préfixe IPv4 générique) |
| 15 | 17 | Generic IPv6 prefix (préfixe IPv6 générique) |
| 16 | 4 | Nil FEC (Nil FEC) |
D'autres types de FEC seront définis au besoin.
Notez que ce TLV définit une pile de FEC, le premier élément FEC correspondant au sommet (top) de la pile d'étiquettes, et ainsi de suite.
Une MPLS echo request doit comporter une pile FEC cible qui décrit la pile FEC testée (MUST). Par exemple, si un LSR X dispose d'une correspondance LDP [LDP] pour 192.168.1.1 (disons l'étiquette 1001), alors, pour vérifier que l'étiquette 1001 atteint bien un LSR de sortie qui a annoncé ce préfixe via LDP, X peut envoyer une MPLS echo request avec un TLV de pile FEC contenant un seul FEC, de type LDP IPv4 prefix, de préfixe 192.168.1.1/32, et envoyer l'echo request avec l'étiquette 1001.
Supposons que le LSR X veuille vérifier que la pile d'étiquettes <1001, 23456> est bien la pile d'étiquettes à utiliser pour atteindre un préfixe IPv4 VPN (voir la section 3.2.5) 10/8 dans la VPN foo. Supposons en outre que le LSR Y, dont l'adresse de bouclage est 192.168.1.1, ait annoncé le préfixe 10/8 avec le Route Distinguisher RD-foo-Y (qui peut en général différer du Route Distinguisher que le LSR X utilise dans ses propres annonces pour la VPN foo), l'étiquette 23456 et le prochain saut BGP 192.168.1.1 [BGP]. Supposons enfin que le LSR X reçoive via LDP une liaison d'étiquette 1001 pour 192.168.1.1. X a deux possibilités pour envoyer une MPLS echo request : X peut envoyer une MPLS echo request avec un TLV de pile FEC contenant un seul FEC de type VPN IPv4 prefix, de préfixe 10/8 et de Route Distinguisher RD-foo-Y. Alternativement, X peut envoyer un TLV de pile FEC contenant deux FEC : le premier de type LDP IPv4 avec le préfixe 192.168.1.1/32, le second de type IP VPN avec le préfixe 10/8 et le Route Distinguisher RD-foo-Y. Dans les deux cas, la MPLS echo request aurait une pile d'étiquettes <1001, 23456>. (Note : dans cet exemple, 1001 est l'étiquette « externe » et 23456 l'étiquette « interne ».)
3.2.1. Préfixe IPv4 LDP (LDP IPv4 Prefix)
Le FEC préfixe IPv4 est défini dans [LDP]. Lorsqu'un préfixe IPv4 LDP est encodé dans une pile d'étiquettes, le format suivant est utilisé. La valeur est constituée de 4 octets d'un préfixe IPv4 suivis de 1 octet de longueur de préfixe en bits ; le format est donné ci-dessous. Le préfixe IPv4 est en ordre d'octets réseau ; si le préfixe est plus court que 32 bits, les bits de fin devraient être mis à zéro (SHOULD). Voir [LDP] pour un exemple de correspondance pour un FEC IPv4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.2. Préfixe IPv6 LDP (LDP IPv6 Prefix)
Le FEC préfixe IPv6 est défini dans [LDP]. Lorsqu'un préfixe IPv6 LDP est encodé dans une pile d'étiquettes, le format suivant est utilisé. La valeur est constituée de 16 octets d'un préfixe IPv6 suivis de 1 octet de longueur de préfixe en bits ; le format est donné ci-dessous. Le préfixe IPv6 est en ordre d'octets réseau ; si le préfixe est plus court que 128 bits, les bits de fin devraient être mis à zéro (SHOULD). Voir [LDP] pour un exemple de correspondance pour un FEC IPv6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.3. LSP IPv4 RSVP (RSVP IPv4 LSP)
La valeur a le format ci-dessous. Les champs de valeur sont tirés de la RFC 3209, sections 4.6.1.1 et 4.6.2.1. Voir [RSVP-TE].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.4. LSP IPv6 RSVP (RSVP IPv6 LSP)
La valeur a le format ci-dessous. Les champs de valeur sont tirés de la RFC 3209, sections 4.6.1.2 et 4.6.2.2. Voir [RSVP-TE].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel sender address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.5. Préfixe IPv4 VPN (VPN IPv4 Prefix)
Les informations de routage de couche réseau VPN-IPv4 (NLRI) sont définies dans [RFC4365]. Ce document utilise le terme VPN IPv4 prefix pour un NLRI VPN-IPv4 qui a été annoncé avec une étiquette MPLS dans BGP. Voir [BGP-LABEL].
Lorsqu'un préfixe IPv4 VPN est encodé dans une pile d'étiquettes, le format suivant est utilisé. Le champ valeur est constitué du Route Distinguisher annoncé avec le préfixe IPv4 VPN, du préfixe IPv4 (avec des bits de fin à 0 pour totaliser 32 bits) et d'une longueur de préfixe, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Route Distinguisher (RD) est un identifiant de 8 octets ; il ne contient aucune information intrinsèque. Le seul but du RD est de permettre de créer des routes distinctes vers un préfixe d'adresse IPv4 commun. L'encodage du RD n'a pas d'importance ici. Lors de la comparaison de ce champ avec les informations FEC locales, il est traité comme une valeur opaque.
3.2.6. Préfixe IPv6 VPN (VPN IPv6 Prefix)
Les informations de routage de couche réseau VPN-IPv6 (NLRI) sont définies dans [RFC4365]. Ce document utilise le terme VPN IPv6 prefix pour un NLRI VPN-IPv6 qui a été annoncé avec une étiquette MPLS dans BGP. Voir [BGP-LABEL].
Lorsqu'un préfixe IPv6 VPN est encodé dans une pile d'étiquettes, le format suivant est utilisé. Le champ valeur est constitué du Route Distinguisher annoncé avec le préfixe IPv6 VPN, du préfixe IPv6 (avec des bits de fin à 0 pour totaliser 128 bits) et d'une longueur de préfixe, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le Route Distinguisher est identique au RD du préfixe IPv4 VPN, sauf qu'il sert ici à permettre la création de routes distinctes vers des préfixes IPv6. Voir la section 3.2.5. Lors de la comparaison de ce champ avec les informations FEC locales, il est traité comme une valeur opaque.
3.2.7. Point d'extrémité L2 VPN (L2 VPN Endpoint)
VPLS signifie Virtual Private LAN Service. Les termes VPLS BGP NLRI et VE ID (VPLS Edge Identifier) sont définis dans [VPLS-BGP]. Ce document utilise le terme plus simple L2 VPN endpoint pour désigner un NLRI VPLS BGP. Le Route Distinguisher est un identifiant de 8 octets utilisé pour distinguer les informations relatives aux différents L2 VPN annoncés par un nœud. Le VE ID est un identifiant de 2 octets utilisé pour identifier un nœud particulier servant de point de raccordement de service au sein d'un VPLS. La structure de ces deux identifiants n'a pas d'importance ici ; lors de la comparaison de ces champs avec les informations FEC locales, ils sont traités comme des valeurs opaques. Le type d'encapsulation est identique au PW Type de la section 3.2.8 ci-dessous.
Lorsqu'un point d'extrémité L2 VPN est encodé dans une pile d'étiquettes, le format suivant est utilisé. Le champ valeur est constitué d'un Route Distinguisher (8 octets), du VE ID de l'émetteur (du ping) (2 octets), du VE ID du destinataire (2 octets) et d'un type d'encapsulation (2 octets), formatés 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's VE ID | Receiver's VE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulation Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.8. Pseudowire FEC 128 (obsolète) (FEC 128 Pseudowire (Deprecated))
FEC 128 (0x80) est défini dans [PW-CONTROL], tout comme les termes PW ID (Pseudowire ID) et PW Type (Pseudowire Type). Un PW ID est un identifiant de connexion de 32 bits non nul. Le PW Type est un nombre de 15 bits indiquant le type d'encapsulation. Il est transporté aligné à droite dans le champ appelé ci-dessous type d'encapsulation (encapsulation type), le bit de poids fort étant mis à zéro. Ces deux champs sont traités dans ce protocole comme des valeurs opaques.
Lorsqu'un FEC 128 est encodé dans une pile d'étiquettes, le format suivant est utilisé. Le champ valeur est constitué de l'adresse du PE distant (l'adresse de destination de la session LDP ciblée), du PW ID et du type d'encapsulation, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ce FEC est obsolète et n'est conservé que pour la compatibilité ascendante. Les implémentations de LSP ping devraient accepter et traiter ce TLV (SHOULD), mais devraient envoyer les echo requests de LSP ping avec le nouveau TLV (voir la section suivante), sauf si elles sont explicitement configurées pour utiliser l'ancien TLV (SHOULD).
Un LSR recevant ce TLV devrait utiliser l'adresse IP source de l'LSP echo request pour déduire l'adresse PE de l'émetteur (SHOULD).
3.2.9. Pseudowire FEC 128 (actuel) (FEC 128 Pseudowire (Current))
FEC 128 (0x80) est défini dans [PW-CONTROL], tout comme les termes PW ID (Pseudowire ID) et PW Type (Pseudowire Type). Un PW ID est un identifiant de connexion de 32 bits non nul. Le PW Type est un nombre de 15 bits indiquant le type d'encapsulation. Il est transporté aligné à droite dans le champ appelé ci-dessous type d'encapsulation (encapsulation type), le bit de poids fort étant mis à zéro.
Ces deux champs sont traités dans ce protocole comme des valeurs opaques. Lors de la comparaison de ces champs avec les informations FEC locales, la correspondance doit être exacte (MUST).
Lorsqu'un FEC 128 est encodé dans une pile d'étiquettes, le format suivant est utilisé. Le champ valeur est constitué de l'adresse du PE de l'émetteur (l'adresse source de la session LDP ciblée), de l'adresse du PE distant (l'adresse de destination de la session LDP ciblée), du PW ID et du type d'encapsulation, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.10. Pseudowire FEC 129 (FEC 129 Pseudowire)
FEC 129 (0x81) ainsi que les termes PW Type, Attachment Group Identifier (AGI), Attachment Group Identifier Type (AGI Type), Attachment Individual Identifier Type (AII Type), Source Attachment Individual Identifier (SAII) et Target Attachment Individual Identifier (TAII) sont définis dans [PW-CONTROL]. Le PW Type est un nombre de 15 bits indiquant le type d'encapsulation. Il est transporté aligné à droite dans le champ PW Type ci-dessous, le bit de poids fort étant mis à zéro. Tous les autres champs sont traités comme des valeurs opaques et copiés directement depuis le format FEC 129. Toutes ces valeurs ensemble définissent de manière unique le FEC dans le périmètre de la session LDP identifiée par les adresses PE source et distante.
Lorsqu'un FEC 129 est encodé dans une pile d'étiquettes, le format suivant est utilisé. La Length de ce TLV est 16 + longueur AGI + longueur SAII + longueur TAII. Un remplissage (padding) est utilisé pour rendre la longueur totale multiple de 4 ; la longueur du remplissage n'est pas incluse dans le champ Length.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type | AGI Type | AGI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | SAII Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | TAII Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TAII (cont.) | 0-3 octets of zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.11. Préfixe IPv4 avec étiquette BGP (BGP Labeled IPv4 Prefix)
Les préfixes IPv4 avec étiquette BGP sont définis dans [BGP-LABEL]. Lorsqu'un préfixe IPv4 avec étiquette BGP est encodé dans une pile d'étiquettes, le format suivant est utilisé. Le champ valeur est constitué du préfixe IPv4 (avec des bits de fin à 0 pour totaliser 32 bits) et de la longueur de préfixe, comme suit.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.12. Préfixe IPv6 avec étiquette BGP (BGP Labeled IPv6 Prefix)
Les préfixes IPv6 avec étiquette BGP sont définis dans [BGP-LABEL]. Lorsqu'un préfixe IPv6 avec étiquette BGP est encodé dans une pile d'étiquettes, le format suivant est utilisé. La valeur est constituée de 16 octets d'un préfixe IPv6 suivis de 1 octet de longueur de préfixe en bits ; le format est donné ci-dessous. Le préfixe IPv6 est en ordre d'octets réseau ; si le préfixe est plus court que 128 bits, les bits de fin devraient être mis à zéro (SHOULD).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.13. Préfixe IPv4 générique (Generic IPv4 Prefix)
La valeur est constituée de 4 octets d'un préfixe IPv4 suivis de 1 octet de longueur de préfixe en bits ; le format est donné ci-dessous. Le préfixe IPv4 est en ordre d'octets réseau ; si le préfixe est plus court que 32 bits, les bits de fin devraient être mis à zéro (SHOULD). Ce FEC est utilisé lorsque le protocole qui annonce l'étiquette est inconnu ou peut changer au cours de la vie du LSP. Un exemple est un LSP inter-AS qui peut être signalé par LDP dans un système autonome (AS), par RSVP-TE [RSVP-TE] dans un autre AS, et par BGP entre les AS, comme cela est courant pour les VPN inter-AS.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.14. Préfixe IPv6 générique (Generic IPv6 Prefix)
La valeur est constituée de 16 octets d'un préfixe IPv6 suivis de 1 octet de longueur de préfixe en bits ; le format est donné ci-dessous. Le préfixe IPv6 est en ordre d'octets réseau ; si le préfixe est plus court que 128 bits, les bits de fin devraient être mis à zéro (SHOULD).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 prefix |
| (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.15. Nil FEC (Nil FEC)
Il arrive que des étiquettes de la plage réservée, par exemple Router Alert et Explicit-null, soient ajoutées à la pile d'étiquettes à diverses fins de diagnostic, comme influencer la répartition de charge. Ces étiquettes peuvent n'avoir aucun FEC explicitement associé. La pile Nil FEC est définie pour permettre d'ajouter un sous-TLV de pile FEC cible à la pile FEC cible afin de tenir compte de ces étiquettes, de sorte qu'une validation correcte puisse malgré tout être effectuée.
La Length est 4. Les étiquettes sont des valeurs de 20 bits traitées comme des nombres.
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 | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label est la valeur d'étiquette réelle insérée dans la pile d'étiquettes ; les champs MBZ doivent être à zéro à l'émission (MUST) et sont ignorés à la réception.
3.3. Correspondance aval (Downstream Mapping)
L'objet correspondance aval (Downstream Mapping) est un TLV qui peut être inclus dans un message echo request (MAY). Un seul objet correspondance aval peut apparaître dans une echo request. La présence d'un objet correspondance aval est une demande pour que des objets correspondance aval soient inclus dans l'echo reply. Si le routeur qui répond est la destination du FEC, alors un TLV de correspondance aval ne devrait pas être inclus dans l'echo reply (SHOULD NOT). Sinon, le routeur qui répond devrait inclure un objet correspondance aval pour chaque interface par laquelle ce FEC pourrait être transféré (SHOULD). Pour une définition plus précise de la notion d'« aval », voir la section 3.3.2, « Routeur et interface aval (Downstream Router and Interface) ».
La Length est de K + M + 4*N octets, où M est la longueur multipath (Multipath Length) et N le nombre d'étiquettes aval (Downstream Label). Les valeurs de K figurent dans la description du type d'adresse (Address Type) ci-dessous. Le champ Value d'une correspondance aval a le format suivant.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Address Type | DS Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Interface Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multipath Type| Depth Limit | Multipath Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. (Multipath Information) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Downstream Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unité de transmission maximale (Maximum Transmission Unit, MTU)
L'MTU est la taille en octets de la plus grande trame MPLS (pile d'étiquettes incluse) qui tient sur l'interface vers le LSR aval.
Type d'adresse (Address Type)
Le type d'adresse indique si l'interface est numérotée (numbered) ou non numérotée (unnumbered). Il détermine également la longueur des champs Downstream IP Address et Downstream Interface. Le total résultant pour la partie initiale du TLV est indiqué dans le tableau ci-dessous sous « K Octets ». Le type d'adresse est positionné à l'une des valeurs suivantes.
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 16
2 IPv4 Unnumbered 16
3 IPv6 Numbered 40
4 IPv6 Unnumbered 28
DS Flags (drapeaux aval)
Le champ DS Flags est un vecteur de bits ayant le format suivant.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Rsvd(MBZ) |I|N|
+-+-+-+-+-+-+-+-+
Deux drapeaux sont actuellement définis, I et N. Les drapeaux restants doivent être mis à zéro à l'émission (MUST) et sont ignorés à la réception.
| Drapeau | Nom et signification |
|---|---|
| I | Interface and Label Stack Object Request (demande de l'objet interface et pile d'étiquettes) : lorsque ce drapeau est positionné, il indique que le routeur qui répond devrait inclure un objet Interface and Label Stack dans le message echo reply (SHOULD). |
| N | Treat as a Non-IP Packet (traiter comme un paquet non IP) : les messages echo request seront utilisés pour diagnostiquer des flux non IP. Toutefois, ces messages sont transportés dans des paquets IP. Pour un routeur qui modifie son algorithme ECMP en fonction du FEC ou d'un examen approfondi du paquet, ce drapeau demande que le routeur traite ce paquet comme il le ferait si la détermination d'une charge utile IP avait échoué. |
Downstream IP Address et Downstream Interface Address
Les adresses IPv4 et les index d'interface sont encodés sur 4 octets ; les adresses IPv6 sont encodées sur 16 octets.
Si l'interface vers le LSR aval est numérotée, le type d'adresse doit être positionné à IPv4 ou IPv6 (MUST), la Downstream IP Address doit être positionnée soit à l'identifiant de routeur (Router ID) du LSR aval, soit à l'adresse d'interface du LSR aval (MUST), et la Downstream Interface Address doit être positionnée à l'adresse d'interface du LSR aval (MUST).
Si l'interface vers le LSR aval n'est pas numérotée, le type d'adresse doit être IPv4 Unnumbered ou IPv6 Unnumbered (MUST), la Downstream IP Address doit être l'identifiant de routeur du LSR aval (MUST), et la Downstream Interface Address doit être positionnée à l'index attribué à l'interface par le LSR amont (MUST).
Si un LSR ne connaît pas l'adresse IP de son voisin, il doit positionner le type d'adresse à IPv4 Unnumbered ou IPv6 Unnumbered (MUST). Pour IPv4, il doit positionner la Downstream IP Address à 127.0.0.1 ; pour IPv6, l'adresse est positionnée à 0::1. Dans les deux cas, l'index d'interface doit être positionné à 0 (MUST). Si un LSR reçoit un paquet Echo Request comportant l'une de ces adresses dans le champ Downstream IP Address, cela indique qu'il doit contourner la vérification d'interface (MUST) mais poursuivre la validation des étiquettes.
Si l'émetteur d'un paquet Echo Request souhaite obtenir des informations de correspondance aval mais ne connaît pas la pile d'étiquettes attendue, il devrait positionner le type d'adresse à IPv4 Unnumbered ou IPv6 Unnumbered (SHOULD). Pour IPv4, il doit positionner la Downstream IP Address à 224.0.0.2 (MUST) ; pour IPv6, l'adresse doit être positionnée à FF02::2 (MUST). Dans les deux cas, l'index d'interface doit être positionné à 0 (MUST). Si un LSR reçoit un paquet Echo Request avec l'adresse multicast all-routers, cela indique qu'il doit contourner à la fois la validation de l'interface et celle de la pile d'étiquettes (MUST), mais renvoyer les TLV de correspondance aval en utilisant les informations fournies.
Type de multipath (Multipath Type)
Les types de multipath suivants sont définis.
| Clé | Type | Informations multipath |
|---|---|---|
| 0 | no multipath (pas de multipath) | Vide (Multipath Length = 0) |
| 2 | IP address (adresse IP) | Adresses IP |
| 4 | IP address range (plage d'adresses IP) | Paires d'adresses basse/haute |
| 8 | Bit-masked IP address set (ensemble d'adresses IP masquées par bits) | Préfixe d'adresse IP et masque de bits |
| 9 | Bit-masked label set (ensemble d'étiquettes masquées par bits) | Préfixe d'étiquette et masque de bits |
Le type 0 indique que tous les paquets seront transférés par cette seule interface.
Les types 2, 4, 8 et 9 spécifient que les informations multipath fournies serviront à solliciter (exercise) ce chemin.
Limite de profondeur (Depth Limit)
La limite de profondeur ne s'applique qu'à une pile d'étiquettes et correspond au nombre maximal d'étiquettes prises en compte dans le hachage ; elle devrait être positionnée à zéro si elle n'est pas spécifiée ou est illimitée (SHOULD).
Longueur multipath (Multipath Length)
La longueur en octets des informations multipath.
Informations multipath (Multipath Information)
Valeurs d'adresse ou d'étiquette encodées selon le type de multipath. Voir la section suivante pour les détails d'encodage.
Étiquettes aval (Downstream Label(s))
L'ensemble des étiquettes de la pile d'étiquettes tel qu'il aurait été si ce routeur avait transféré le paquet par cette interface. Les éventuelles étiquettes Implicit Null sont explicitement incluses. Les étiquettes sont traitées comme des nombres, c'est-à-dire qu'elles sont alignées à droite dans le champ.
Une étiquette aval (Downstream Label) fait 24 bits, au même format qu'une étiquette MPLS moins le champ TTL, c'est-à-dire que le MSBit de l'étiquette est le bit 0, le LSBit est le bit 19, les bits EXP sont les bits 20-22 et le bit 23 est le bit S. Le routeur qui répond devrait remplir les bits EXP et S (SHOULD) ; le LSR qui reçoit l'echo reply peut choisir d'ignorer ces bits (MAY).
Protocole (Protocol)
Le protocole est tiré du tableau suivant.
| Protocol # | Protocole de signalisation |
|---|---|
| 0 | Unknown (inconnu) |
| 1 | Static (statique) |
| 2 | BGP |
| 3 | LDP |
| 4 | RSVP-TE |
3.3.1. Encodage des informations de multipath (Multipath Information Encoding)
Les informations multipath (Multipath Information) encodent les étiquettes ou les adresses qui solliciteront ce chemin. Les informations multipath dépendent du type de multipath. Le contenu du champ est indiqué dans le tableau ci-dessus. Les adresses IPv4 sont prises dans la plage 127/8 ; les adresses IPv6 sont prises dans la plage 0:0:0:0:0:FFFF:127/104. Les étiquettes sont traitées comme des nombres, c'est-à-dire qu'elles sont alignées à droite dans le champ. Pour le type 4, les plages indiquées par les paires d'adresses ne doivent pas se chevaucher (MUST NOT) et doivent être en séquence croissante (MUST).
Le type 8 permet un encodage plus dense des adresses IP. Le préfixe IP est formaté comme une adresse IP de base dont les bits de poids faible hors préfixe sont mis à zéro. La longueur maximale du préfixe est 27. Le préfixe est suivi d'un masque de longueur 2^(32-longueur du préfixe) bits pour IPv4 et 2^(128-longueur du préfixe) bits pour IPv6. Chaque bit positionné à 1 représente une adresse valide. L'adresse est l'adresse IPv4 de base plus la position du bit dans le masque, les bits étant numérotés de gauche à droite en commençant par zéro. Par exemple, les adresses IPv4 127.2.1.0, 127.2.1.5-127.2.1.15 et 127.2.1.20-127.2.1.29 seraient encodées 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ces mêmes adresses intégrées dans IPv6 seraient encodées 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 1 1 1 1 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Le type 9 permet un encodage plus dense des étiquettes. Le préfixe d'étiquette est formaté comme une valeur d'étiquette de base dont les bits de poids faible hors préfixe sont mis à zéro. La longueur maximale du préfixe (y compris les zéros de tête dus à l'encodage) est 27. Le préfixe est suivi d'un masque de longueur 2^(32-longueur du préfixe) bits. Chaque bit positionné à un représente une étiquette valide. L'étiquette est l'étiquette de base plus la position du bit dans le masque, les bits étant numérotés de gauche à droite en commençant par zéro. Les valeurs d'étiquette de tous les nombres impairs entre 1152 et 1279 seraient encodées 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 +-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0| +-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 1 0 1 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| +-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note : dans l'original anglais (RFC 4379), la bitmap de cet exemple est coupée au niveau d'un retour à la ligne de composition. Elle est ici reproduite littéralement comme dans l'original anglais. Sa signification est que le début est le préfixe de l'étiquette de base 1152 (= 0b10010000000) et que la partie suivante est le masque des étiquettes impaires à bits alternés.
Si les informations multipath reçues ne sont pas nulles, les étiquettes et les adresses IP doivent être choisies dans l'ensemble fourni (MUST). Si aucune de ces étiquettes ou adresses ne correspond à une interface aval particulière, alors, pour cette interface, le type doit être positionné à 0 (MUST). Si les informations multipath reçues sont nulles (c'est-à-dire Multipath Length = 0, ou, pour les types 8 et 9, un masque entièrement à zéro), le type doit être positionné à 0 (MUST).
Par exemple, supposons que le LSR X, au saut 10, ait deux LSR aval, Y et Z, pour le FEC en question. Le LSR X qui reçoit pourrait renvoyer le type de multipath 4, avec les adresses IP basse/haute 127.1.1.1->127.1.1.255 pour le LSR aval Y et 127.2.1.1->127.2.1.255 pour le LSR aval Z. Le head end répercute cette information au LSR Y. Y, qui a trois LSR aval, U, V et W, calcule que 127.1.1.1->127.1.1.127 irait vers U et que 127.1.1.128->127.1.1.255 irait vers V. Y répondrait alors par 3 correspondances aval : vers U, avec le type de multipath 4 (127.1.1.1->127.1.1.127) ; vers V, avec le type de multipath 4 (127.1.1.127->127.1.1.255) ; et vers W, avec le type de multipath 0.
Notez que le calcul des informations multipath peut imposer une charge de traitement importante au destinataire. Un destinataire peut donc choisir de ne traiter qu'un sous-ensemble des préfixes reçus (MAY). L'émetteur, à la réception d'une réponse à une correspondance aval comportant des informations partielles, devrait supposer que les préfixes manquants dans la réponse ont été ignorés par le destinataire (SHOULD), et peut redemander des informations à leur sujet dans une nouvelle echo request (MAY).
3.3.2. Routeur et interface aval (Downstream Router and Interface)
La notion de « routeur aval » et d'« interface aval » mérite une explication. Considérons un LSR X. Si un paquet émis avec TTL n>1 arrivait au LSR X avec l'étiquette la plus externe L et TTL=1, X doit pouvoir calculer quels LSR pourraient recevoir le paquet s'il était émis avec TTL=n+1, par quelle interface la requête arriverait et quelle pile d'étiquettes ces LSR verraient. (La manière dont ce calcul est effectué sort du cadre de ce document.) L'ensemble de ces LSR/interfaces constitue les routeurs/interfaces aval (et leurs étiquettes correspondantes) pour X vis-à-vis de L. Chaque paire de routeur et d'interface aval nécessite l'ajout d'une correspondance aval distincte dans la réponse.
Le cas où X est le LSR qui émet l'echo request est un cas particulier. X doit déterminer quels LSR recevraient la MPLS echo request pour une pile FEC donnée que X émet avec TTL=1.
L'ensemble des routeurs aval au niveau de X peut être constitué de chemins alternatifs (voir la discussion sur l'ECMP ci-dessous) ou de chemins simultanés (par exemple pour le multicast MPLS). Dans le premier cas, les informations multipath servent d'indication à l'émetteur sur la manière dont il peut influencer le choix entre ces alternatives.
3.4. TLV de remplissage (Pad TLV)
La partie valeur du Pad TLV contient un nombre variable (>= 1) d'octets. Le premier octet prend les valeurs du tableau suivant ; tous les autres octets (s'il y en a) sont ignorés. Le destinataire devrait vérifier que le TLV est reçu dans son intégralité (SHOULD), mais ignore par ailleurs le contenu de ce TLV, hormis le premier octet.
| Valeur | Signification |
|---|---|
| 1 | Drop Pad TLV from reply (supprimer le Pad TLV de la réponse) |
| 2 | Copy Pad TLV to reply (copier le Pad TLV dans la réponse) |
| 3-255 | Réservé pour un usage futur |
3.5. Numéro d'entreprise du fournisseur (Vendor Enterprise Number)
Les SMI Private Enterprise Numbers sont gérés par l'IANA. La Length est toujours 4 ; la valeur est le code d'entreprise privée SMI du fournisseur, en ordre d'octets réseau, qui possède une extension privée de fournisseur (Vendor Private) sur l'un des champs de la partie fixe du message ; dans ce cas, ce TLV doit être présent (MUST). Si aucun des champs de la partie fixe du message ne comporte d'extension privée de fournisseur, l'inclusion de ce TLV est facultative (OPTIONAL). Des plages privées de fournisseur ont été définies pour les types de message, les modes de réponse et les codes de retour. Lorsque l'une de ces plages est utilisée, le TLV de numéro d'entreprise du fournisseur doit être inclus dans le message (MUST).
3.6. Pile interface et étiquettes (Interface and Label Stack)
Le TLV Interface and Label Stack peut être inclus dans un message de réponse pour signaler l'interface sur laquelle le message de requête a été reçu ainsi que la pile d'étiquettes qui se trouvait sur le paquet au moment de sa réception (MAY). Un seul objet de ce type peut apparaître. Le but de cet objet est de permettre au routeur amont d'obtenir les informations exactes d'interface et de pile d'étiquettes telles qu'elles apparaissent au niveau du LSR qui répond.
La Length est de K + 4*N octets ; N est le nombre d'étiquettes de la pile d'étiquettes. Les valeurs de K figurent dans la description du type d'adresse (Address Type) ci-dessous. Le champ Value d'une correspondance aval a le format suivant.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Type | Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. Label Stack .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type d'adresse (Address Type)
Le type d'adresse indique si l'interface est numérotée ou non numérotée. Il détermine également la longueur des champs IP Address et Interface. Le total résultant pour la partie initiale du TLV est indiqué dans le tableau ci-dessous sous « K Octets ». Le type d'adresse est positionné à l'une des valeurs suivantes.
Type # Address Type K Octets
------ ------------ --------
1 IPv4 Numbered 12
2 IPv4 Unnumbered 12
3 IPv6 Numbered 36
4 IPv6 Unnumbered 24
IP Address et Interface
Les adresses IPv4 et les index d'interface sont encodés sur 4 octets ; les adresses IPv6 sont encodées sur 16 octets.
Si l'interface sur laquelle le message echo request a été reçu est numérotée, le type d'adresse doit être positionné à IPv4 ou IPv6 (MUST), l'IP Address doit être positionnée soit à l'identifiant de routeur du LSR, soit à l'adresse d'interface (MUST), et l'Interface doit être positionnée à l'adresse d'interface (MUST).
Si l'interface n'est pas numérotée, le type d'adresse doit être IPv4 Unnumbered ou IPv6 Unnumbered (MUST), l'IP Address doit être l'identifiant de routeur du LSR (MUST), et l'Interface doit être positionnée à l'index attribué à l'interface (MUST).
Pile d'étiquettes (Label Stack)
La pile d'étiquettes du message echo request reçu. Si des valeurs TTL ont été modifiées par ce routeur, elles devraient être restaurées (SHOULD).
3.7. TLV erronés (Errored TLVs)
Le TLV suivant est un TLV qui peut être inclus dans un echo reply pour informer l'émetteur d'une echo request des TLV obligatoires (mandatory) soit non pris en charge par une implémentation, soit analysés et jugés erronés (MAY).
Le champ Value contient les TLV qui n'ont pas été compris, encodés sous forme de sous-TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. TLV octet TOS de réponse (Reply TOS Byte TLV)
Ce TLV peut être utilisé par l'émetteur de l'echo request pour demander qu'un echo reply soit envoyé avec l'octet TOS de l'en-tête IP positionné à la valeur spécifiée dans le TLV (MAY). Ce TLV a une longueur de 4 avec le champ valeur suivant.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply-TOS Byte| Must Be Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+