Aperçu:
Le protocole de distribution d'étiquettes LDP est un protocole de contrôle pour la commutation d'étiquettes multiprotocole MPLS, qui équivaut au protocole de signalisation dans le réseau traditionnel. Il est chargé de transmettre la classification des FEC équivalentes (une route), la distribution des étiquettes, et l'établissement et l'établissement du chemin de commutation d'étiquettes LSP Maintenance et autres opérations. LDP spécifie divers messages et procédures de traitement associées dans le processus de distribution d'étiquettes.
Terme LDP:
- Homologues LDP Les homologues
LDP font référence à deux LSR qui ont des sessions LDP entre eux et utilisent LDP pour échanger des messages d'étiquette. Les homologues LDP obtiennent l'étiquette de l'autre via la session LDP entre eux. - Adjacence LDP La contiguïté LDP est établie
lorsqu'un LSR reçoit le message Hello de l'extrémité opposée. Il existe deux types de contiguïtés LDP:
• Adjacence locale: La contiguïté découverte en envoyant des messages Hello (c'est-à-dire des messages Hello de lien) sous forme de multidiffusion est appelée contiguïté locale.
• Remote Adjacency (Remote Adjacency): La contiguïté trouvée en envoyant le message Hello (c'est-à-dire le message Hello cible) sous forme de monodiffusion est appelée contiguïté distante.
LDP maintient l'existence de pairs par contiguïté, et le type d'homologue dépend du type de contiguïté qui le maintient. Un pair peut être maintenu par plusieurs contiguïtés. S'il est maintenu à la fois par une contiguïté locale et une contiguïté distante, le type d'homologue est l'homologue coexistant distant. - Session LDP La session
LDP est utilisée pour échanger des informations telles que le mappage d'étiquettes et la libération entre les LSR. Une session LDP ne peut être établie qu'en présence d'un pair Il existe deux types de sessions LDP:
• Session LDP locale: les deux LSR qui établissent la session sont directement connectés.
• Session LDP distante (Session LDP distante): les deux LSR qui établissent une session peuvent être connectés directement ou indirectement.
Les sessions LDP locales et les sessions LDP distantes peuvent coexister. - Espace d'étiquettes
L'un est l'espace d'étiquettes basé sur l'interface: la plage d'étiquettes annoncée par chaque interface est unique, comme le montre la figure, les étiquettes annoncées par LER1 sur différentes interfaces pour la même FEC sont différentes; l'
autre est l'espace d'étiquettes basé sur la plate-forme: l'allocation d'étiquettes n'est pas unique sous chaque interface, mais est allouée à partir de l'ensemble du LSR. Comme le montre la figure, LER1 annonce une étiquette pour le même FEC: les
appareils Huawei utilisent la méthode de la plate-forme pour allouer des étiquettes par défaut.
La plage de valeurs de l'espace d'étiquette est divisée comme suit:
- 0 ~ 15: étiquette spéciale. Par exemple, l'étiquette 3, appelée étiquette vide implicite, est utilisée pour afficher l'avant-dernier saut (analyse détaillée plus tard); l'étiquette 0, appelée étiquette vide d'affichage, si l'étiquette est 0, le LSR de l'avant-dernier saut doit être défini la valeur à 0 L'étiquette est normalement enfoncée dans le haut de la valeur d'étiquette du message et transmise au nœud. Lorsque le nœud sortant trouve que la valeur d'étiquette transportée dans le paquet est 0, il affichera l'étiquette directement (la différence avec l'étiquette ordinaire est qu'il n'est pas nécessaire de vérifier la table LFIB pour l'opération ici, ce qui économise le temps correspondant) Le but de l'utilisation de l'étiquette vide d'affichage est de faire QoS.
- 16 × 1023: LSP statique et CR-LSP statique (espace d'étiquette partagé).
- 1024 et plus: espace d'étiquette pour les protocoles de signalisation dynamique tels que LDP, RSVP-TE, MP-BGP.
Analyse du format des messages:
Le protocole LDP utilise principalement quatre types de messages:
- Message de découverte: utilisé pour annoncer et maintenir l'existence de voisins dans le réseau, tels que les messages Hello.
- Messages de session: utilisés pour établir, maintenir et terminer des sessions entre homologues LDP, tels que les messages d'initialisation et les messages Keepalive.
- Message d'annonce: utilisé pour créer, modifier et supprimer le mappage d'étiquettes FEC, tel que le message d'adresse et le message de mappage d'étiquettes.
- Message de notification: utilisé pour fournir des messages d'avertissement et des notifications d'erreur.
Format d'en-tête LDP PDU:
le message LDP est basé sur TCP (le message Hello est basé sur UDP), le numéro de port est 646 et le format du message est
encapsulé à la manière de TLV, le message LDP est divisé en en-tête et contenu du message Deux parties, le format d'en-tête LDP est indiqué dans la figure:
Les champs sont expliqués comme suit:
- Version: Valeur entière non signée de 2 octets, représentant le numéro de version du protocole LDP. Le numéro de version actuel du protocole LDP est Ox01.
- Longueur PDU: valeur entière de 2 octets, qui exprime la longueur de PDU en octets, à l'exclusion des champs de numéro de version et de longueur de PDU. La longueur maximale de la PDU est négociée lorsque la session est initialisée et la longueur maximale par défaut est de 4096 octets.
- LDP ldentifier: 6 octets, qui identifie de manière unique l'espace d'étiquette du LSR émetteur auquel appartient la PDU. Les 4 premiers octets représentent l'adresse LSR-ID et les 2 derniers octets spécifient l'espace d'étiquette spécifique dans le LSR.
Le format du message LDP est indiqué sur la figure:
les champs sont expliqués comme suit:
- U: 1 bit, bit TLV inconnu, U = 0 pour renvoyer la notification, U = 1 pour ignorer le message.
- Type de message: 14 bits, indiquant le type de message.
- Longueur du message: 2 octets, la longueur du message exprimée en octets, y compris l'identificateur de message, les paramètres obligatoires et les paramètres facultatifs.
- ID de message: identificateur de message, 4 octets, utilisé pour identifier le message.
- Paramètres obligatoires: Les paramètres obligatoires ont des longueurs variables, des ensembles de paramètres obligatoires. Paramètres d'option: longueur variable des paramètres facultatifs, jeu de paramètres facultatifs.
1. Message Hello
LDP Hello message est utilisé pour découvrir les voisins et utilisé pour maintenir la relation de voisinage dans la période ultérieure. Il est envoyé en fonction de UDP et l'adresse de destination est 224.0.0.2. Il sera envoyé périodiquement sur l'interface compatible LDP (Période par défaut = 5 s). Le format est le suivant: Le
paquet Hello porte certains paramètres communs, tels que le temps de maintien et l'adresse de transmission de l'expéditeur. Le temps d'attente est le temps d'attente avant de supprimer un voisin. La valeur par défaut est de 15 s (Bonjour * 3). Si le temps d'attente défini par les deux parties est différent, le temps le plus court sera utilisé. L'adresse de transport est l'adresse utilisée pour établir une connexion TCP. La valeur par défaut est la même que le LSR-ID. Par conséquent, par défaut, si deux LSR peuvent établir avec succès une relation de session de voisinage LDP, le LSR-ID respectif doit être accessible. L'adresse de transport peut être modifiée en d'autres adresses. La méthode de modification de l'équipement Huawei est la suivante:
[LSR1-GigabitEthernet0 / 0/0] interface d'adresse de transport ldp mpls
Cependant, la modification de l'adresse de transport entraînera l'interruption de la relation de voisinage LDP, ce qui affectera les services de couche supérieure, elle doit donc être configurée avec soin. Vous pouvez utiliser les méthodes suivantes pour afficher le temps de maintien et l'adresse de transmission, comme indiqué dans la sortie suivante:
2. Message d'
initialisation Le message d'initialisation est utilisé pour négocier les paramètres de session du voisin LDP, y compris le mode de distribution des étiquettes, le mécanisme anti-boucle et l'espace d'étiquettes, comme indiqué sur la figure Remarque: La
méthode de distribution des étiquettes sera analysée ultérieurement.
3. Message d'adresse Le message d'
adresse est utilisé pour annoncer toutes les adresses IP d'interface de l'extrémité locale au voisin LDP afin que le voisin puisse déterminer l'étiquette de sortie via l'adresse de saut suivant dans la table de transfert IP, comme indiqué dans la figure:
Si un routeur LDP commence à partir de Différents voisins reçoivent le mappage d'étiquettes de la même FEC, puis il est nécessaire
de sélectionner l'étiquette de meilleur sortie pour la FEC . Dans ce cas, il est nécessaire de vérifier de manière exhaustive les informations de la table de transfert IP et de la table d'étiquettes pour déterminer l'étiquette de sortie.
4. Message d'annonce d'étiquette Le message d'annonce d'
étiquette est utilisé pour annoncer le contenu de liaison de FEC et d'étiquette aux voisins LDP. Une annonce d'étiquette peut annoncer plusieurs informations d'étiquette, comme indiqué dans la figure: le
message d'annonce d'étiquette inclut également la demande d'étiquette et l'étiquette La révocation et les messages de libération d'étiquette ne sont pas décrits ici.
5. Messages Keepalive Une fois la
session LDP voisine établie, les deux parties échangeront périodiquement des messages KeepAlive pour la détection keepalive de la session TCP. La période de détection par défaut est de 15 s et le délai d'expiration est de 45 s. Le message KeepAlive n'a pas de contenu spécifique et le format est très simple, comme le montre la figure:
6. Message de
notification Les messages de notification sont divisés en notifications d'erreur ou notifications de requête. Un message de notification sera envoyé lorsque les événements suivants se produisent: le format du paquet de données reçu est incorrect, TLV non reconnu, délai de session, etc., le message signalera le type d'erreur spécifique au voisin, comme indiqué dans la figure:
utilisation du message organigramme comme suit:
Processus d'établissement de la relation de voisinage LDP:
1. Découverte de voisin:
Session LDP locale: les deux LSR qui établissent la session sont directement connectés.
Une fois le protocole LDP démarré, le routeur envoie des paquets Hello, et les routeurs voisins échangent des paquets Hello pour se compléter mutuellement. Via les paquets Hello, les informations de base du voisin, telles que l'adresse utilisée pour établir une session (adresse de transmission ) etc.
Les messages Hello LDP sont encapsulés dans UDP. UDP est un protocole sans connexion. Afin d'assurer la validité et la fiabilité des voisins, les messages Hello sont envoyés périodiquement avec une période d'envoi de 5 s. Le multicast 224.0.0.2 est utilisé comme adresse IP de destination, ce qui signifie "envoyé à tous les routeurs en le réseau."
Ensuite, le correspondant avec la plus grande adresse initie une connexion TCP et établit finalement une session voisine. Ce type de session LDP est appelé session locale. Si l'adresse du voisin est spécifiée manuellement, la session établie est appelée session LDP distante.
Session LDP distante (Session LDP distante): les deux LSR qui établissent une session peuvent être directement connectés ou indirectement connectés.
Si le voisin est un appareil non connecté directement, Hello sera échangé en mode monodiffusion pour terminer l'établissement d'une session LDP distante, comme illustré dans la figure ci-dessus.
2. Établissement de session: une fois que les
voisins LDP se découvrent ou spécifient directement l'adresse du voisin, ils commencent à établir une connexion TCP. Une fois la connexion TCP établie, ils s'envoient des messages d'initialisation pour la négociation des paramètres, comme indiqué dans la figure:
Si vous acceptez les paramètres de l'autre partie, il répondra avec un message KeepAlive pour terminer l'établissement de la session LDP; si une erreur se produit pendant la période, un message de notification sera envoyé pour signaler l'erreur correspondante, qui finira par provoquer la connexion à fermer. Vous pouvez utiliser la commande suivante pour vérifier l'établissement d'une session LDP: l'
état est Opérationnel, ce qui signifie que la session LDP a été établie avec succès, et les voisins peuvent échanger des messages tels que des annonces d'étiquettes. Une fois la session établie, les deux parties enverront périodiquement des paquets Hello pour détecter l'état du voisin, ainsi que périodiquement des paquets KeepAlive pour détecter l'état de la connexion TCP.
Machine d'état LDP:
Le protocole LDP est passé par quatre états, de la découverte des voisins à l'établissement de la session. La commutation entre les états est illustrée dans la figure suivante:
- État non existant: l'état initial du protocole LDP, similaire à l'état IDLE de BGP. Au début, les deux parties utilisent l'adresse multicast 224.0.0.2 pour envoyer des paquets Hello, et élisent les parties actives et passives (celle avec l'adresse IP LSR la plus élevée est sélectionnée comme partie active). Après avoir reçu le message Hello de l'autre, les deux parties commencent à établir une connexion TCP, suivie du processus de négociation à trois pour établir une connexion TCP. Lorsque la session TCP est établie avec succès, les deux parties passent à l'état Initialisé.
- État initialisé: dans cet état, le travail des parties actives et passives est un peu différent. La partie active envoie d'abord le message d'initialisation, puis elle passe à l'état OpenSent et attend que la partie passive réponde au message d'initialisation. Dans cet état, la partie passive attendra que la partie active envoie un message d’initialisation. Si les paramètres du message d’initialisation reçu sont acceptables, elle répondra à la partie active avec les messages d’initialisation et de KeepAlive, puis transférera à l’Openrec Etat. Dans cet état, les parties actives et passives passeront à l'état Non Existant lorsqu'elles recevront des paquets de non-initialisation ou attendront un délai d'expiration.
- Openent state: Cet état est l'état après que la partie active envoie un message d'initialisation. Dans cet état, il attend également l'initialisation du voisin et les messages KeepAlive. Si les paramètres du message d'initialisation reçu peuvent être acceptés, il répondra au voisin avec le message KeepAlive, et l'état passera à l'état Openrec; si les paramètres ne peuvent pas être acceptés ou si le temps d'attente expire, la connexion de session TCP sera être déconnecté et entré dans le statut Non Existant.
- État Openrec: qu'il s'agisse de la partie active ou de la partie passive, il entrera dans cet état après avoir reçu le message d'initialisation avec les paramètres corrects. Dans cet état, il a répondu à l'autre partie avec le message KeepAlive et attend que le voisin répondre au message KeepAlive. Si le message KeepAlive est reçu du voisin à l'heure, il passera à l'état opérationnel; si d'autres messages sont reçus ou si le temps d'attente expire, il passera à l'état non existant.
- État opérationnel: atteindre cet état signifie que la session LDP a été établie avec succès et que tous les autres paquets LDP peuvent être envoyés et échangés. Dans cet état, les deux parties maintiennent la session voisine via l'échange périodique de messages KeepAlive. Si KeepAlive expire, la session LDP sera immédiatement déconnectée et passera à l'état Non Existant; lorsqu'un message de notification d'erreur est reçu, la session LDP également être déconnecté et transféré. Entrez l'état Non existant.
Mise en place et maintenance du LSP:
Le processus d'établissement du LSP lie en fait la FEC et l'étiquette, et annonce cette liaison au LSR adjacent sur le LSP. Ce processus est mis en œuvre via LDP. Prenons l'exemple du mode DU et du contrôle d'étiquettes ordonnées. Les principales étapes sont les suivantes: La
topologie est illustrée dans la figure. Le processus d'établissement dynamique de LDP de LSP est le suivant:
- Il existe une route d'hôte de 100.1.1.1/32 sur le RTD. Comme le RTD est un nœud de sortie, il annonce directement la relation de liaison entre 100.1.1.1/32 et l'étiquette à son voisin en amont RTC.
- Une fois que le RTC reçoit la relation de liaison entre 100.1.1.1/32 et l'étiquette allouée par le RTD voisin en aval, il enregistre l'étiquette dans sa table LIB et annonce la relation de liaison entre 100.1.1.1/32 et l'étiquette au RTB voisin en amont . RTC vérifie si le prochain saut vers 100.1.1.1/32 dans sa table de routage IP est RTD. Si le prochain saut dans la table de routage IP est RTD, RTC utilise l'étiquette attribuée par RTD pour encapsuler les données atteignant 100.1.1.1/32 Si le saut suivant dans la table de routage IP n'est pas un RTD, le RTC réserve l'étiquette attribuée par le RTD comme étiquette de sauvegarde.
- Après avoir reçu la relation de liaison entre 100.1.1.1/32 et l'étiquette allouée par le voisin en aval RTC, RTB exécute les mêmes actions que RTC.
- Une fois que RTA reçoit la relation de liaison entre 100.1.1.1/32 et l'étiquette attribuée par le RTB voisin, il vérifie si le prochain saut vers 100.1.1.1/32 dans sa table de routage IP est RTB. Si le prochain saut dans la table de routage IP is Si le saut est RTB, RTA utilise l'étiquette allouée par RTB pour encapsuler les données atteignant 100.1.1.1/32; si le prochain saut dans la table de routage IP n'est pas RTB, RTA réserve l'étiquette allouée par RTB comme sauvegarde. Puisque RTA est une entrée, le LSP qui atteint finalement 100.1.1.1/32 est établi.
Annulation de session:
LDP juge la relation de contiguïté en détectant les messages Hello; il juge l'intégrité de la session en détectant les messages Keepalive.
LDP utilise différents minuteries pour maintenir la contiguïté et les sessions LDP:
- Minuterie de rétention Hello: les homologues LDP envoient périodiquement des messages Hello pour indiquer qu'ils souhaitent maintenir cette contiguïté. Si le minuteur Hello keep expire et qu'aucun nouveau message Hello n'est reçu, la contiguïté Hello est supprimée.
- Minuterie Keepalive: les homologues LDP maintiennent les sessions LDP via des messages Keepalive envoyés via des connexions de session LDP. Si le minuteur de conservation de session expire et qu'aucun message Keepalive n'est reçu, la connexion est fermée et la session LDP est terminée.
On peut voir que le paquet Hello contrôle la relation de voisinage et que Keepalive contrôle la relation de session.
Les règles de base de la distribution des étiquettes LDP:
L'établissement du LDP LSP est achevé en recevant l'étiquette allouée par le dispositif en aval pour la FEC (généralement une entrée de table de routage), et en établissant la relation de mappage entre l'étiquette FEC et MPLS et l'interface sortante. Par conséquent, pour établir un LSP basé sur FEC, vous devez d'abord attribuer une étiquette au FEC correspondant. La distribution des étiquettes doit respecter les principes suivants:
- L'allocation des étiquettes entrantes est de l'ordre du plus grand au plus petit (minimum 1024) et la plus petite étiquette actuellement non allouée est allouée.
- L'étiquette d'entrée attribuée au FEC par l'équipement en aval sur la même liaison doit correspondre à l'étiquette de sortie de l'équipement en amont.
- Il peut y avoir plusieurs étiquettes sortantes reçues pour la même FEC sur un appareil (elles peuvent être identiques ou différentes), qui proviennent de différents pairs en aval, c'est-à-dire qu'une FEC peut mapper plusieurs étiquettes sortantes et interfaces sortantes.
- Une seule étiquette entrante est allouée pour le même FEC sur un appareil, c'est-à-dire que pour les étiquettes entrantes, chaque FEC est unique sur le même appareil.
- Sur le nœud directement connecté au segment de réseau pour une certaine FEC (la valeur par défaut est uniquement une route hôte avec un masque 32 bits, vous pouvez utiliser la commande lsp-trigger pour modifier, et le supplément de notes de suivi) n'en créera qu'un LSP contenant l'étiquette d'entrée pour la FEC. Ce LSP n'a pas d'étiquette sortante et pas d'interface sortante, car c'est la fin du tunnel LSP.
- Sur les autres nœuds, deux LSP seront créés pour le FEC du segment de réseau non directement connecté en même temps: l'un d'eux est le LSP utilisé pour guider l'accès du nœud local à l'hôte de destination représenté par le FEC, y compris seulement l'étiquette sortante et l'interface sortante; l'autre est Le nœud local est le LSP du nœud de transit (Transit), qui est utilisé pour guider le périphérique en amont pour accéder à l'hôte de destination représenté par la FEC, et comprend l'étiquette entrante, sortante étiquette et interface sortante.
Libération et gestion des étiquettes LDP:
1. Méthode de publication d'étiquettes:
DU (méthode autonome aval non sollicitée en aval): pour un paquet arrivant à la même adresse de destination, le LSR peut effectuer l'allocation et la distribution d'étiquettes sans obtenir de message de demande d'étiquette de l'amont.
DoD (Downstream on Demand, Downstream on Demand): pour un paquet qui atteint la même adresse de destination, le LSR effectue l'allocation et la distribution d'étiquette après avoir obtenu le message de demande d'étiquette.
Topologie comme indiqué:
- La méthode DU est utilisée pour distribuer les étiquettes. Pour les paquets dont l'adresse de destination est 100.1.1.1/32, le RTD en aval (sortie) annonce activement l'étiquette de sa route hôte 100.1.1.1/32 au RTC en amont (transit) via un message de mappage d'étiquettes.
- Distribuez les étiquettes en mode DoD. Pour les paquets dont l'adresse de destination est 100.1.1.1/32, le RTC amont (Transit) envoie un message de demande d'étiquette vers l'aval, et le RTD aval (Sortie) envoie un message de mappage d'étiquette vers l'amont après réception du message de demande d'étiquette.
Les appareils Huawei utilisent la méthode DU pour publier des étiquettes par défaut. Le DU n'a pas besoin d'attendre les messages de demande en amont et peut directement attribuer des étiquettes aux voisins. Lorsque la topologie du réseau change, la méthode DU peut répondre rapidement à la distribution des étiquettes pour la nouvelle topologie et le temps de convergence est plus court que celui de la méthode DoD.
2. Mode de commande de distribution d'étiquette:
Indépendant (mode de commande de distribution d'étiquette indépendant): Le LSR local peut attribuer de manière autonome une étiquette à lier à un paquet IP et notifier le LSR en amont sans attendre l'étiquette en aval.
Ordonné (méthode de contrôle de distribution d'étiquette ordonnée): Ce n'est que lorsque le LSR a déjà l'étiquette du saut suivant du paquet IP, ou que le LSR est le nœud sortant du paquet IP, le LSR peut envoyer l'étiquette du paquet IP en amont.
Topologie comme indiqué:
En utilisant la méthode indépendante:
- Si le mode de distribution d'étiquette est DU et que le mode de contrôle de distribution d'étiquette est Indépendant, RTC (Transit) n'a pas besoin d'attendre l'étiquette du RTD aval (Sortie), et distribuera directement l'étiquette au RTB amont.
- Si le mode de distribution d'étiquette est DoD et que le mode de contrôle de distribution d'étiquette est indépendant, le RTC aval directement connecté (Transit) du RTB (Transit) qui envoie la demande d'étiquette répondra directement à l'étiquette sans attendre l'étiquette du RTD en aval. (Sortie).
En utilisant la méthode Ordered:
- Si le mode de distribution d'étiquettes est DU et que le mode de commande de distribution d'étiquettes est Ordonné, RTC (Transit) distribuera uniquement les étiquettes au RTB amont après avoir reçu l'étiquette du RTD aval (Sortie).
2. Si la méthode de distribution d'étiquette est DoD et que la méthode de contrôle de distribution d'étiquette est Ordonnée, le RTC en aval direct (Transit) du RTB (Transit) qui envoie la demande d'étiquette n'enverra l'étiquette que du RTD en aval (Sortie) vers l'amont RTB. Distribuez des étiquettes.
Les appareils Huawei utilisent la méthode ordonnée pour attribuer des étiquettes par défaut. En mode ordonné, l'étiquette ne peut être distribuée en amont que lorsque le LSR a déjà l'étiquette du saut suivant du paquet IP. Ceci afin d'éviter que l'étiquette du paquet IP en aval ne soit non allouée ou que le temps de convergence soit long, et l'étiquette amont est allouée Perte de données causée par le début de la transmission des données.
3. Comment conserver l'étiquette:
Libéral (mode de rétention d'étiquette libre): le mappage d'étiquette reçu du LSR voisin est réservé indépendamment du fait que le LSR voisin soit son prochain bond ou non. (Mais lorsque le LSP est finalement formé, seule l'étiquette envoyée par le prochain saut sera utilisée)
Conservateur (mode de rétention d'étiquette conservateur): le mappage d'étiquette reçu du LSR voisin est réservé uniquement lorsque le LSR voisin est son prochain bond.
La topologie indiquée dans la figure, lorsque la modification de la topologie du réseau entraîne la modification du voisin du saut suivant:
- En utilisant la méthode de rétention d'étiquette libre, le LSR peut utiliser directement l'étiquette envoyée par le voisin d'origine non suivant pour reconstruire rapidement le LSP, mais cela nécessite plus de mémoire et d'espace d'étiquette.
- En utilisant une rétention d'étiquette conservatrice, le LSR ne conserve que les étiquettes des voisins du prochain saut, économisant de la mémoire et de l'espace d'étiquette, mais la reconstruction LSP sera plus lente.
Les appareils Huawei utilisent la méthode gratuite de rétention des étiquettes pour enregistrer les étiquettes par défaut.
Actuellement, les paramètres Huawei prennent en charge les combinaisons suivantes:
- Mode autonome en aval (DU) + mode de contrôle de distribution d'étiquettes ordonnées (ordonné) + mode de rétention d'étiquettes libre (libéral), qui est le mode par défaut. C'est-à-dire qu'après avoir reçu le mappage d'étiquettes en aval, le LSR peut attribuer des étiquettes à l'amont de manière autonome, et toutes les étiquettes reçues sont réservées. (Flexible mais consomme plus de ressources)
- Mode à la demande en aval (DoD) + mode de contrôle de distribution d'étiquettes ordonné (ordonné) + mode de rétention d'étiquettes conservateur (conservateur). Autrement dit, après avoir reçu la demande d'étiquette en amont et le mappage d'étiquette en aval en même temps, le LSR alloue des étiquettes à l'amont, et ne conserve que les étiquettes allouées par son prochain bond. (Il consomme moins de ressources mais n'est pas flexible)
Organiser les sources de données: "HCIE Routing and Exchange Study Guide", matériel de formation Huawei HCIE