RFC3038 page - 12 - Nagami & autres

Groupe de travail Réseau

K. Nagami, Y. Katsube, Toshiba Corp.

Request for Comments : 3038

N. Demizu, WaterSprings.ORG

Catégorie : En cours de normalisation

H. Esaki, Univ. of Tokyo


P. Doolan, Ennovate Networks

Traduction Claude Btrière de L’Isle

janvier 2001



Notification du VCID sur liaison ATM pour LDP



Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.


Notice de copyright

Copyright (C) The Internet Society (2001). Tous droits réservés.


Résumé

Le routeur de commutation d’étiquettes en mode de transfert asynchrone (LSR ATM, Asynchronous Transfer Mode Label Switching Router) est une des applications majeures de la commutation d’étiquettes. Parce que les étiquettes de couche ATM (VPI et VCI) associées à un circuit virtuel (VC) sont réécrites avec une nouvelle valeur à chaque nœud de commutation ATM, il n’est pas possible de les utiliser pour identifier un VC dans les messages de transposition d’étiquettes. Le concept d’identifiant de connexion virtuelle (VCID, Virtual Connection Identifier) est introduit pour résoudre ce problème. Le VCID a la même valeur aux deux extrémités d’un VC. Le présent document spécifie les procédures pour la communication des valeurs des VCID entre les LSR ATM voisins qui doivent intervenir afin de garantir cette propriété.


Table des matières

1. Introduction 1

2. Vue générale des procédures de notification de VCID 2

2.1 Procédures de notification de VCID 2

2.2 Direction de VC 3

3. Procédures de notification de VCID 3

3.1 Procédures de notification dans la bande 3

3.2 Notification hors bande utilisant un champ de petite taille 4

3.3 Notification hors bande 6

4. Procédure de notification de VPID 6

5. Format de message VCID 7

5.1 Messages VCID 7

5.2 Objets 10

Considérations pour la sécurité 11

Remerciements 11

Références 11

Adresse des auteurs 11

Déclaration complète de droits de reproduction 11



1. Introduction


Plusieurs schémas de commutation d’étiquettes ont été proposés pour intégrer la couche 2 et la couche 3. Le routeur de commutation d’étiquettes ATM (LSR ATM) est une des applications majeures de la commutation d’étiquettes.


Dans le cas des VC ATM, les étiquettes VPI et VCI sont, en général, réécrites avec de nouvelles valeurs à chaque nœud de commutation à travers lequel passe le VC et elles ne peuvent pas être utilisées pour fournir l’identification de bout en bout d’un VC.


Dans le contexte de MPLS, les “flux” qui sont des classes de paquets avec des caractéristiques communes déductibles en examinant l’en-tête de couche 3 dans les paquets, sont liés aux "étiquettes" de couche 2. On parle de flux qui sont "liés" aux étiquettes. Ces liens sont convoyés entre LSR homologues au moyen du protocole de distribution d’étiquettes (LDP, Label Distribution Protocol) de la [RFC3036].


Afin d’appliquer MPLS aux liaisons ATM, on a besoin d’un moyen pour identifier les circuits virtuels ATM dans les messages de transposition de LDP. Un identifiant appelé Identifiant de connexion virtuelle (VCID, Virtual Connection ID) est introduit. Le VCID a la même valeur aux deux extrémités d’un VC. Le présent document spécifie les procédures de communication des valeurs des VCID entre des LSR ATM voisins qui doivent intervenir afin de garantir cette propriété.


2. Vue générale des procédures de notification de VCID

2.1 Procédures de notification de VCID


L’ATM a plusieurs types de VC (liaisons point à point transparentes/VP/PVC/SVC). Une liaison point à point transparente est définie comme celle qui a la même étiquette VPI/VCI aux deux extrémités d’un VC. Par exemple, deux nœuds sont directement connectés (c’est-à-dire, sans commutateur ATM interposé) ou sont connectés à travers un chemin virtuel (VP, Virtuel Path) avec la même valeur de VPI aux deux extrémités du VP.


Il y a deux grandes catégories de procédures de notification de VCID ; dans la bande et hors bande. La catégorisation se réfère à la connexion sur laquelle les messages de la procédure de notification de VCID sont transmis. Dans le cas des procédures dans la bande, ces messages sont transmis sur le VC auquel ils se réfèrent. À l’opposé, les procédures hors bande transmettent les messages sur une autre connexion (que le VC auquel ils se réfèrent).


On énumère ci-dessous les divers types de liaisons et on mentionne brièvement les procédures de notification de VCID employées et les raisons de ce choix. Les procédures elles mêmes sont exposées en détail dans les sections suivantes.


Liaison en point à point transparente : pas de notification de VCID

La procédure de notification de VCID n’est pas nécessaire parce que l’étiquette (c’est-à-dire, le VPI/VCI) est la même à chaque extrémité du VC.


VP : notification dans la bande, ou notification du VPID, ou pas de notification

- notification dans la bande

la notification du VCID est nécessaire parce que le VPI à chaque extrémité du VC peut n’être pas le même. La notification du VCID dans la bande est utilisée dans ce cas.

- notification du VPID

la notification du VCID est nécessaire parce que le VPI à chaque extrémité du VC peut n’être pas le même. La notification du VPID est utilisée dans ce cas.

- pas de notification

si un nœud a seulement un VP avec un nœud voisin, la procédure de notification de VCID n’est pas obligatoire. Le VCI peut être utilisé comme VCID. Cela parce que la valeur du VCI est la même à chaque extrémité du VP.


PVC : notification dans la bande

La notification dans la bande du VCID est utilisée dans ce cas parce que l’étiquette à chaque extrémité du VC peut n’être pas la même.


SVC : il y a trois possibilités

- notification hors bande

si un message de signalisation a un champ qui est assez grand pour porter une valeur de VCID (par exemple, GIT [RFC3033]) alors, le VCID est porté directement dedans.

- notification hors bande en utilisant un champ de petite taille

si un message de signalisation a un champ qui n’est pas assez grand pour porter une valeur de VCID, c’est cette procédure qui est utilisée.

- notification dans la bande

si un message de signalisation ne peut pas porter les informations de l’utilisateur, c’est cette procédure qui est utilisée.


Lorsque un LSP est un VC en point à multipoint et qu’un commutateur ATM dans un LSR n’est pas capable de fusion de VC, il peut causer des problèmes de performances et de qualité de service. Lorsque le LSR veut ajouter une nouvelle terminaison au LSP, il a besoin de partager temporairement le LSP actif pour envoyer un message de notification dans la bande.


2.2 Direction de VC


Un VC a une direction. La procédure de VCID pour un VC est toujours déclanchée à partir du nœud amont du VC, c’est-à-dire que le nœud amont notifie au nœud aval le VCID.


Si l’utilisation bidirectionnelle d’un VC de commutation d’étiquettes est permise, le VC de commutation d’étiquettes est dit être bidirectionnel. Dans ce cas, deux procédures de VCID sont entreprises, une pour chaque direction.


Si l’utilisation bidirectionnelle d’un VC à commutation d’étiquettes n’est pas permise, le VC à commutation d’étiquettes est dit être unidirectionnel. Dans ce cas, une seule procédure de VCID est entreprise pour la direction permise.


La capacité de direction des VC est communiquée au moyen de LDP.


3. Procédures de notification de VCID

3.1 Procédures de notification dans la bande

3.1.1 Notification dans la bande pour VC en point à point

La notification de VCID est effectuée en transmettant un message de contrôle à travers le VC nouvellement établi (par signalisation ou par gestion) à utiliser comme chemin à commutation d’étiquette (LSP, label switched path). La procédure de notification de VCID entre deux nœuds A et B est précisée ci-dessous.


0. Le nœud A établit un VC pour le nœud B de destination (par signalisation ou gestion).


1. Le nœud A choisit une valeur de VCID.


2. Le nœud A envoie au nœud B à travers le VC nouvellement établi un message PROPOSE VCID qui contient la valeur de VCID et un identifiant de message.


3. Le nœud A établit une association entre l’étiquette sortante (VPI/VCI) pour le VC et la valeur de VCID.


4. Le nœud B reçoit le message du VC et établit une association entre le VCID dans le message et l’étiquette entrante (VPI/VCI) pour le VC. Jusqu’à ce que le nœud B reçoive le message Demande LDP, le nœud B élimine tout paquet reçu sur le VC autre que le message PROPOSE VCID.


5. Le nœud B envoie un message ACK au nœud A. Ce message contient le même VCID et identifiant de message que spécifié dans le message reçu. Ce message est envoyé à travers le VC par LDP.


6. Lorsque le nœud A reçoit le message ACK, il vérifie si le VCID et l’identifiant de message sont les mêmes dans le message que ce qui est enregistré. Si ils sont les mêmes, le nœud A vérifie que le nœud B a établi l’association entre le VC et le VCID. Autrement, le message est ignoré. Si le nœud A ne reçoit pas le message avec l’identifiant de message et le VCID attendus pendant une période donnée, le nœud A envoie à nouveau le message PROPOSE VCID au nœud B.


7. Après avoir reçu le message ACK à PROPOSE, le nœud A envoie un message Demande LDP au nœud B. Il contient l’identifiant de message utilisé pour PROPOSE VCID. Lorsque le nœud B reçoit le message Demande LDP, il vérifie que le nœud A a reçu correctement l’accusé de réception. L’échange de messages qui utilise les messages PROPOSE VCID, ACK VCID et le message Demande LDP constitue une prise de contact en trois phases. Le mécanisme de prise de contact en trois phases est exigé car la transmission du message PROPOSE VCID n’est pas fiable. Une fois que la prise de contact en trois phases est terminée, le nœud B ignore tous les messages PROPOSE VCID reçus sur le VC. Le nœud B envoie un message Transposition LDP qui contient la valeur de VCID dans le TLV de l’étiquette.


Nœud A Nœud B

| |

|--------------->| PROPOSE VCID

| |

|<---------------| ACK VCID

| |

|--------------->| Demande d’étiquette LDP

| |

|<---------------| Transposition d’étiquette LDP


3.1.2 Notification dans la bande pour VC en point à multipoint

La spécification actuelle de LDP ne prend pas en charge la diffusion groupée. Mais la procédure de notification de VCID est définie pour être utilisée à l’avenir. La notification de VCID est effectuée par l’envoi d’un message de contrôle à travers le VC à utiliser comme un LSP. Le nœud amont alloue la valeur du VCID. La procédure par laquelle il notifie cette valeur au nœud aval est donnée ci-dessous. La procédure est utilisée lorsque un nouveau VC est créé ou qu’une nouvelle extrémité est ajoutée au VC.


On décrit d’abord la procédure pour établir le premier VC.


1. Le nœud amont alloue une valeur de VCID pour le VC. Lorsque la valeur de VCID est déjà allouée à un VC, elle est utilisée pour le VCID.


2. Le nœud amont envoie un message qui contient la valeur de VCID et un identifiant de message à travers le VC utilisé pour un LSP. Ce message est transféré à tous les nœuds d’extrémité.


3. Le nœud amont établit une association entre l’étiquette sortante pour le VC et la valeur de VCID.


4. Lorsque les nœuds aval qui reçoivent le message ont déjà reçu le message Demande LDP pour le VC, le message reçu est éliminé. Autrement, les nœuds aval établissent une association entre le VCID dans le message et le VC d’où le message a été reçu.


5. Les nœuds aval envoient un message d’accusé de réception (ACK) au nœud amont.


6. Après que le nœud amont a reçu les messages ACK, le nœud amont et les nœuds aval partagent le VCID. Le nœud amont envoie le message Demande LDP afin de faire une prise de contact en trois phases.


Amont aval 1 aval 2

| | |

|-----------+-->| | PROPOSE VCID

| +------------------>|

| | |

|<---------------| |

| ACK VCID | |

|<------------------------------| ACK VCID


Ensuite est décrite la procédure pour ajouter une extrémité au VC existant en point à multipoint.


0. Le nœud amont ajoute le nœud aval, en utilisant la signalisation ATM.


1. La valeur de VCID qui est déjà allouée au VC est utilisée.


2. Le nœud amont envoie un message qui contient la valeur du VCID et un identifiant de message à travers le VC utilisé pour un LSP. Ce message est transféré à tous les nœuds d’extrémité.


3. Lorsque les nœuds aval qui reçoivent le message ont déjà reçu le message Demande LDP pour le VC, le message reçu est éliminé. Autrement, les nœuds aval établissent une association entre le VCID dans le message et le VC d’où le message est reçu.


4. Après que le nœud amont a reçu les messages ACK, le nœud amont et les nœuds aval partagent le VCID. Le nœud amont envoie le message Demande LDP afin de faire une prise de contact en trois phases.


3.2 Notification hors bande utilisant un champ de petite taille


Cette méthode peut être appliquée lorsque un VC est établi en utilisant un message de signalisation ATM et que le message a un champ qui n’est pas assez grand pour porter une valeur de VCID.


Le message ÉTABLISSEMENT du Forum ATM UNI 3.1/4.0 a un champ obligatoire de 7 bits pour l’utilisateur. C’est un champ spécifique de l’utilisateur dans le champ protocole de couche 3 dans l’élément d’information Informations de couche basse large bande (BLLI IE, Broadband Low Layer Information Information Element).


La valeur de BLLI est utilisée comme identifiant temporaire pour un VC durant une procédure de notification de VCID. Ce mécanisme est défini comme "notification hors bande utilisant un champ de petite taille". La valeur de BLLI d’un nouveau VC ne doit pas être allouée à d’autres VC durant la procédure pour éviter un conflit d’identifiants. Lorsque l’association entre la valeur de BLLI, une valeur de VCID, et le VC correspondant est établie, la valeur de BLLI peut être réutilisée pour un nouveau VC. Les valeurs de VCID peuvent être allouées indépendamment des valeurs de BLLI.


Nœud A Nœud B

| |

|--------------->| Signalisation ATM avec BLLI

|<---------------|

| |

|--------------->| PROPOSE VCID avec BLLI

| |

|<---------------| ACK de VCID

| |

|--------------->| Demande d’étiquette LDP

| |

|<---------------| Transposition d’étiquette LDP


Un VC en point à multipoint peut aussi être établi en utilisant ADD_PARTY de la signalisation du Forum ATM. ADD_PARTY ajoute une nouvelle extrémité de VC à un VC existant ou à une arborescence de VC existante. Dans cette procédure, la valeur de BLLI de ADD_PARTY doit être la même valeur que celle utilisée pour établir le premier VC point à point de l’arborescence. La même valeur de BLLI ne peut être utilisée dans différentes arborescences de VC que lorsque ces arborescences de VC ne peuvent pas ajouter une extrémité en même temps. Il en résulte que la valeur de BLLI utilisée dans la signalisation doit être déterminée par le nœud racine de l’arborescence de diffusion groupée.


Note : La valeur de BLLI est unique au nœud d’envoi. Mais la valeur de BLLI n’est pas unique au nœud receveur parce que plusieurs nœuds envoyeurs peuvent allouer la même valeur de BLLI. De sorte que le nœud receveur doit reconnaître la valeur de BLLI et l’adresse de l’envoyeur. Les messages de signalisation ATM (ÉTABLISSEMENT et ADD_PARTY) portent à la fois le BLLI et l’adresse ATM de l’envoyeur. Le nœud receveur peut savoir quel nœud envoie le message BLLI.


3.2.1 Notification hors bande utilisant un champ de petite taille pour un VC en point à point

Ce paragraphe décrit les procédures d’établissement d’un VC et de notification de son VCID entre LSR voisins pour le trafic en envoi individuel.


La procédure employée lorsque le LSR amont alloue un VCID est la suivante :


1. Un LSR amont établit un VC avec le LSR aval en utilisant la signalisation ATM et il fournit une valeur dans le champ BLLI qu’il n’utilise pas actuellement pour une autre transaction (non achevée) de notification de VCID avec cet homologue.


2. Le LSR amont envoie le message PROPOSE VCID à travers le VC pour que LDP notifie au LSR aval l’association entre le BLLI et les valeurs de VCID.


3. Le LSR aval établit l’association entre le VC avec la valeur de BLLI et le VCID et envoie un message ACK au LSR amont.


4. Après que le LSR amont a reçu le message ACK, il établit l’association entre le VC et le VCID. Le VC est prêt à l’emploi. À ce moment, la valeur de BLLI employée dans cette transaction peut être réutilisée.


5. Après la notification du VCID, le nœud amont envoie le message Demande LDP au nœud aval. Le nœud aval envoie le message LDP Transposition, qui contient la valeur de VCID dans le TLV de l’étiquette de LDP.


3.2.2 Notification hors bande utilisant un champ de petite taille pour un VC en point à multipoint

Ce paragraphe décrit les procédures d’établissement du premier VC pour une arborescence de diffusion groupée et pour ajouter une nouvelle extrémité de VC à une arborescence existante de VC, incluant la notification de son VCID pour un flux de diffusion groupée utilisant des VC en point à multipoint.


Dans cette procédure, un LSR amont détermine à la fois le VCID et la valeur de BLLI dans le cas de diffusion groupée. La raison pour laquelle la valeur de BLLI est déterminée par un LSR amont a été décrite ci-dessus.


On décrit d’abord la procédure d’établissement du premier VC  :


1. Un LSR amont établit un VC par la signalisation de l’ATM Forum avec le LSR aval avec une valeur unique de BLLI à cet instant.


2. Le LSR amont notifie au LSR aval une valeur de BLLI appariée à un VCID en utilisant un message dédié à ce propos.


3. Le LSR aval établit l’association entre le VC avec la valeur de BLLI et le VCID et envoie un message ACK au LSR amont. Si le VCID est utilisé par un autre VC entre les LSR amont et aval, l’ancien VC est éliminé.


4. Après que le LSR amont a reçu le message ACK, le VC est prêt à l’emploi et la valeur de BLLI peut être utilisée pour un autre VC.


On décrit ensuite la procédure pour ajouter une extrémité au VC point à multipoint existant :


1. Le LSR amont établit un VC au moyen de la signalisation de l’ATM Forum avec le LSR aval avec la valeur de BLLI qui a été utilisée durant la première procédure de signalisation. Si un autre VC utilise la valeur de BLLI au même moment, le LSR amont attend l’achèvement de la procédure de signalisation qui utilise la valeur de BLLI.


2. On reprend à l’étape 2 de la procédure pour le premier VC.


3.3 Notification hors bande


Cette méthode peut être appliquée lorsque un VC est établi en utilisant un message de signalisation ATM et que le message a un champ (par exemple, GIT [RFC3033]) qui est assez grand pour porter une valeur de VCID. Le format du message est décrit dans la [RFC3033]. Après la notification du VCID, le nœud A envoie le message Demande LDP au nœud B. Puis, le nœud B envoie le message Transposition LDP au nœud A.


Nœud A Nœud B

| |

|--------------->| Signalisation ATM avec VCID

|<---------------|

| |

|--------------->| Demande d’étiquette LDP

| |

|<---------------| Transposition d’étiquette LDP


4. Procédure de notification de VPID


L’approche qui est utilisée pour la procédure de notification de VCID est aussi applicable pour partager le même identifiant entre deux extrémités pour un VP. La procédure de notification de VPID est définie à cette fin.

Une procédure de notification de VPID distincte est effectuée pour chaque direction de chaque VP.

Après que la notification du VPID est finie pour un VP, un VCID d’un VC dans le VP est construit avec le VPID(MSB) et le VCI(LSB) du VC. Le VCID peut être utilisé par LDP sans effectuer la procédure de notification de VCID. La séquence de messages est donnée ci-dessous.

1. Un nœud amont envoie le message PROPOSE VPID. Dans le cas d’un VC de commutation d’étiquettes bidirectionnel, les deux nœuds amont et aval utilisent VCI=33. Dans le cas de VC à commutation d’étiquette unidirectionnel, le nœud qui a le plus grand identifiant LDP utilise VCI=33 et l’autre nœud utilise VCI=34. Noter que VCI=32, qui est utilisé pour le transfert de paquets non étiquetés, n’est pas utilisé pour la procédure de notification de VPID, de sorte que la même méthode d’encapsulation peut être appliquée à la fois pour la procédure de VPID et pour la procédure de VCID dans la bande.

2. Le nœud aval envoie le message ACK VPID.

3. Le nœud amont envoie le message LDP Demande d’étiquette.

4. Le nœud aval envoie me message LDP Transposition d’étiquette.


5. Format de message VCID

5.1 Messages VCID


Un message LDP VCID consiste en un en-tête LDP [RFC3036] fixe suivi d’un ou plusieurs TLV. Un message PROPOSE VCID dans la bande et un message PROPOSE VPID sont envoyés comme paquet d’encapsulation nulle à travers un VC pour être utilisés comme un LSP. Il n’y a que l’en-tête de pile d’étiquettes devant la PDU LDP VCID. Une valeur d’étiquette dans l’entrée de pile d’étiquettes [RFC3032] pour le message PROPOSE VCID dans la bande et le message PROPOSE VPID est 4. Les autres messages sont envoyés comme paquets TCP. C’est la même chose qu’avec LDP.


Le champ Type de message de VCID est comme suit :


Message Propose VCID dans la bande = 0x0501

Message Propose VCID = 0x0502

Message ACK VCID = 0x0503

Message NACK VCID = 0x0504

Message Propose VPID dans la bande = 0x0505

Message ACK VPID = 0x0506

Message NACK VPID = 0x0507


5.1.1 Message Propose VCID dans la bande

Ce message est envoyé comme paquet à encapsulation nulle avec l’en-tête LDP et l’en-tête de pile d’étiquette à travers un VC pour être utilisé comme un LSP. La valeur de l’étiquette est 4. La valeur d’étiquette réservée est exigée parce que le nœud aval peut recevoir ce message après avoir reçu le message LDP Demande d’étiquette dans le cas de VC point à multipoint. Le nœud aval doit distinguer le message PROPOSE VCID des autres messages et ignorer le message PROPOSE VCID lorsque le nœud a déjà reçu le message LDP Demande d’étiquette pour le VC.


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|VCID Inband Propose (0x0501) | Longueur du message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV d’étiquette |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Paramètres facultatifs |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Identifiant de message : Entier de quatre octets utilisé pour identifier ce message.


TLV d’étiquette : Le TLV d’étiquette contient la valeur du VCID. Le TLV Type d’étiquette est VCID(0x0203).


5.1.2 Message Propose VCID

Un LSR utilise le message PROPOSE VCID pour la procédure de notification de VCID de la notification hors bande utilisant un champ de petite taille. Ce message est envoyé à travers le VC pour le LDP.


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| VCID Propose (0x0502) | Longueur du message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message |

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

| TLV d’étiquette |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV Identifiant temporaire |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Paramètres facultatifs |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Identifiant de message : Entier de quatre octets utilisé pour identifier ce message.


TLV d’étiquette : Le TLV d’étiquette contient la valeur du VCID. Le TLV Type d’étiquette est VCID(0x0203).


TLV Identifiant temporaire

La valeur portée dans le champ spécifique de l’utilisateur du champ Protocole de couche 3 de l’identifiant BLLI du TLV Type d’étiquette de l’ATM Forum UNI 3.1/4.0 est l’identifiant temporaire de VCID(0x0702).


5.1.3 Message ACK VCID

Un LSR envoie le message ACK VCID lorsque le LSR accepte le message PROPOSE VCID.


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| VCID ACK (0x0503) | Longueur de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV d’étiquette |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message VCID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Paramètres facultatifs |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Identifiant de message : Entier de quatre octets utilisé pour identifier ce message.


TLV d’étiquette : Le TLV d’étiquette contient la valeur de VCID du message PROPOSE VCID reçu. Le TLV Type d’étiquette est VCID(0x0203).


Identifiant de message VCID : Cette valeur est la même que celle du message PROPOSE VCID reçu.


5.1.4 Message NACK VCID

Un LSR envoie le message NACK VCID lorsque le LSR n’accepte pas le message PROPOSE VCID.


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| VCID NACK (0x0504) | Longueur du message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant du message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV d’étiquette |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message VCID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Paramètres facultatifs |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Identifiant de message : Entier de quatre octets utilisé pour identifier ce message.


TLV d’étiquette : Le TLV d’étiquette contient la valeur de VCID du message PROPOSE VCID reçu. Le TLV Type d’étiquette est VCID(0x0203).


Identifiant de message VCID : Cette valeur est la même que celle du message PROPOSE VCID reçu.


5.1.5 Message Propose VPID dans la bande

Ce message est envoyé comme paquet d’encapsulation nulle avec l’en-tête LDP et l’en-tête de pile d’étiquette à travers un VC à utiliser comme un LSP. La valeur de l’étiquette est 4. Le nœud aval doit distinguer le message PROPOSE VPID des autres messages et ignorer les messages PROPOSE VPID lorsque le nœud a déjà reçu le message LDP Demande d’étiquette pour le VC.


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|VPID Inband Propose (0x0505) | Longueur de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV VPID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Paramètres facultatifs |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Identifiant de message : Entier de quatre octets utilisé pour identifier ce message.


TLV VPID : Le TLV VPID contient la valeur du VPID. Le TLV Type d’étiquette est VPID(0x0703).


5.1.6 Message ACK VPID

Un LSR envoie le message ACK VPID lorsque le LSR accepte le message PROPOSE VPID.


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| VPID ACK (0x0506) | Longueur de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| TLV VPID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message VPID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Paramètres facultatifs |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Identifiant de message : Entier de quatre octets utilisé pour identifier ce message.


TLV VPID : Le TLV VPID contient la valeur de VPID du message PROPOSE VPID reçu.


Identifiant de message VCID : Cette valeur est la même que celle du message PROPOSE VCID reçu.


5.1.7 Message NACK VPID

Un LSR envoie le message NACK VPID lorsque le LSR n’accepte pas le message PROPOSE VPID.


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| VPID NACK (0x0507) | Longueur de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de message |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| VPID TLV |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de Mmessage VCID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Paramètrrs facultatifs |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Identifiant de message : Entier de quatre octets utilisé pour identifier ce message.


TLV VPID : Le TLV VPID contient la valeur de VPID du lessage PROPOSE VPID reçu.


Identifiant de message VCID : Cette valeur est la même que celle du message PROPOSE VCID reçu.


5.2 Objets

5.2.1 TLV Étiquette de VCID

Un LSR utilise le TLV Étiquette de VCID pour coder les étiquettes à utiliser sur la liaison qui n’a pas la même étiquette de liaison des données aux deux éxtrémités d’un VC.


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|VCID Label (0x0203) | Longueur |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| VCID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


VCID : C’est une valeur de VCID de quatre octets.


5.2.2 TLV Identifiant de message VCID


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|VCID Message ID(0x0701) | Longueur |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identifiant de Message VCID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Identifiant de message VCID : C’est un identifiant de message VCID de quatre octets.


5.2.3 TLV d’identifiant temporaire de VCID

Un LSR utilise le TLV Identifiant temporaire de VCID pour la procédure de notification de VCID de la notification hors bande qui utilise un champ de petite taille.


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| VCID Temporary ID (0x0702)| Longueur |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ID temporaire |

+-+-+-+-+-+-+-+-


ID temporaire : Valeur portée dans le champ spécifique d’utilisateur du champ Protocole de couche 3 de l’identifiant BLLI de l’ATM Forum UNI 3.1/4.0


5.2.4 TLV d’étiquette de VPID

Un LSR utilise le TLV de VPID pour la procédure de notification de VPID.


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| VPID (0x0703) | Longueur |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| VPID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


VPID : Valeur sur deux octets du VPID.


Considérations pour la sécurité


Le présent document n’introduit aucune problème de sécurité autre que ceux qui sont présents dans le protocole LDP et peut utiliser les mêmes mécanismes proposés pour cette technologie.


Remerciements


Les auteurs tiennent à remercier de leurs précieus commentaires techniques Yoshihiro Ohba, Shigeo Matsuzawa, Akiyoshi Mogi, Muneyoshi Suzuki, George Swallow et les membres du groupe de travail LAST du projet WIDE.


Références


[RFC3032] E. Rosen et autres, "Codage de pile d'étiquettes MPLS", janvier 2001.


[RFC3033] M. Suzuki, "Allocation d'identifiant de champ d'information et de protocole dans l'identifiant générique Q.2941 et la signalisation d'usager à usager Q.2957 pour le protocole Internet", janvier 2001. (P.S.)


[RFC3036] L. Andersson et autres, "Spécification de LDP", janvier 2001. (Rendue obsolète par la RFC5036)


Adresse des auteurs


Ken-ichi Nagami

Noritoshi Demizu

Hiroshi Esaki

Computer & Network Development Center,

WaterSprings.ORG

Computer Center, University of Tokyo,

Toshiba Corporation,

1-6-11-501, Honjo, Sumida-ku,

2-11-16 Yayoi, Bunkyo-ku,

1, Toshiba-cho, Fuchu-shi,

Tokyo, 130-0004,

Tokyo, 113-8658,

Tokyo, 183-8511, Japan

Japan

Japan

téléphone : 42-333-2884

mél : demizu@dd.iij4u.or.jp

téléphone : 3-3812-1111

mél : ken.nagami@toshiba.co.jp


mél : hiroshi@wide.ad.jp


Yasuhiro Katsube

Paul Doolan

Computer & Network Development Center,

Ennovate Networks

Toshiba Corporation,

60 Codman Hill Road

1, Toshiba-cho, Fuchu-shi,

Boxborough, MA

Tokyo, 183-8511, Japan

USA

téléphone : 42-333-2844

téléphone : 978-263-2002 x103

mél : yasuhiro.katsube@toshiba.co.jp

mél : pdoolan@ennovatenetworks.com


Déclaration complète de droits de reproduction


Copyright (c) The Internet Society (2001). Tous droits réservés.


Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society, ses successeurs ou ayant droits.


Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.


Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.