RFC3034 page - 14 - Conta, Doolan & Malis

Groupe de travail Réseau

A. Conta, Transwitch Corporation

Request for Comments : 3034

P. Doolan, Ennovate

Catégorie : En cours de normalisation

A. Malis, Vivace Networks, Inc.

Traduction Claude Brière de L’Isle

janvier 2001



Spécification de l’utilisation de la commutation d’étiquettes
sur les réseaux en relais de trame



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 présent document définit le modèle et les mécanismes génériques pour la commutation d’étiquettes multiprotocoles sur les réseaux en relais de trame. De plus, il étend et précise les portions de l’architecture de commutation d’étiquettes multiprotocoles décrite dans la [RFC3031] et du protocole de distribution d’étiquettes (LDP, Label Distribution Protocol) décrit dans la [RFC3036] qui se rapportent aux réseaux en relais de trame. MPLS permet l’usage des commutateurs de relais de trame comme routeurs de commutation d’étiquettes (LSR, Label Switching Router).


Table des matières

1. Introduction 1

2. Terminologie 2

3. Caractéristiques particulières des commutateurs de relais de trame 3

4. Encapsulation d’étiquette 3

5. Traitement de la commutation d’étiquette en relais de trame 4

5.1 Utilisation des DLCI 4

5.2 LSP homogènes 4

5.3 LSP hétérogènes 4

5.4 Prévention et contrôle de boucle de commutation d’étiquette en relais de trame 5

5.5 Traitement d’étiquettes par les FR-LSR d’entrée 7

5.6 Traitement d’étiquettes par les FR-LSR de cœur 8

5.7 Traitement d’étiquettes par les FR-LSR de sortie 8

6. Composant de contrôle de commutation d’étiquette pour le relais de trame 8

6.1 Commutateurs hybrides (vaisseaux dans la nuit) 9

7. Procédures d’allocation et de maintenance des étiquettes 9

7.1 Comportement de LSR de bordure 9

7.2 Utilisation efficace de l’espace d’étiquettes – fusion des FR-LSR 10

7.3 Messages LDP spécifiques du relais de trame 11

8. Considérations pour la sécurité 12

9. Remerciements 13

10. Références 13

11. Adresse des auteurs 13

12. Déclaration complète de droits de reproduction 13


1. Introduction


L’architecture de la commutation d’étiquettes multiprotocoles est décrite dans la [RFC3031]. Il est possible d’utiliser des commutateurs de relais de trame comme routeurs de commutation d’étiquettes (LSR, Label Switching Router). De tels commutateurs de relais de trame utilisent des algorithmes d’acheminement de couche réseau (tels que OSPF, IS-IS, etc.) et leur transmission se fonde sur le résultat de ces algorithmes d’acheminement. Aucun acheminement spécifique du relais de trame n’est nécessaire.


Lorsque un commutateur de relais de trame est utilisé pour la commutation d’étiquettes, l’étiquette du sommet (l’étiquette en cours) sur laquelle sont fondées les décisions de transmission, est portée dans le champ DLCI de l’en-tête Relais de trame de couche liaison des données d’une trame. Des informations supplémentaires portées avec l’étiquette du sommet (en cours) mais non traitées par la commutation de relais de trame, ainsi que les autres étiquettes, si le paquet est multi étiqueté, sont portées dans l’encapsulation générique MPLS définie dans la [RFC3032].


Les circuits virtuels permanents (PVC, permanent virtual circuit) en relais de trame pourraient être configurés pour porter du trafic fondé sur la commutation d’étiquettes. Les DLCI seraient utilisés comme des étiquettes MPLS et les commutateurs de relais de trame deviendraient des routeurs de commutation d’étiquettes en relais de trame, tandis que le trafic MPLS serait encapsulé conformément à la présente spécification, et serait transmis sur la base des informations d’acheminement de la couche réseau.


Les mots clés DOIT, NE DOIT PAS, PEUT, FACULTATIF, EXIGE, RECOMMANDE, DEVRA, NE DEVRA PAS, DEVRAIT, NE DEVRAIT PAS sont à interpréter comme défini dans la RFC 2119.


Le présent document est un document d’accompagnement des [RFC3032] et [RFC3035].


2. Terminologie


LSR

Un routeur de commutation d’étiquettes (LSR, Label Switching Router) est un appareil qui met en œuvre le contrôle de commutation d’étiquettes et les composants de transmission décrits dans la [RFC3031].


LC-FR

Une interface de contrôle de commutation d’étiquettes en relais de trame (LC-FR, Label Switching controlled Frame Relay) est une interface en relais de trame contrôlée par le composant de contrôle de commutation d’étiquettes. Les paquets qui traversent une telle interface portent des étiquettes dans le champ DLCI.


FR-LSR

Un FR-LSR est un LSR avec une ou plusieurs interfaces LC-FR qui transmet des trames entre deux de ces interfaces en utilisant des étiquettes portées dans le champ DLCI.


domaine FR-LSR

Un domaine FR-LSR est un ensemble de FR-LSR, qui sont mutuellement interconnectés par des interfaces LC-FR.


Ensemble bordure

L’ensemble bordure d’un domaine FR-LSR est l’ensemble des LSR qui sont connectés au domaine par des interfaces LC-FR.


Encapsulation de transmission

L’encapsulation de transmission est le type d’encapsulation MPLS (relais de trame, ATM, générique) d’un paquet qui détermine la transmission MPLS du paquet, ou l’encapsulation de couche réseau si ce paquet est transmis sur la base de l’en-tête de couche réseau (IP, etc...).


Encapsulation d’entrée

L’encapsulation d’entrée est le type d’encapsulation MPLS (relais de trame, ATM, générique) d’un paquet lorsque ce paquet est reçu sur une interface d’un LSR, ou l’encapsulation de couche réseau (IP, etc...) si ce paquet n’a pas d’encapsulation MPLS.


Encapsulation de sortie

L’encapsulation de sortie est le type d’encapsulation MPLS (relais de trame, ATM, générique) d’un paquet lorsque ce paquet est transmis sur l’interface d’un LSR, ou l’encapsulation de couche réseau (IP, etc...) si ce paquet n’a pas d’encapsulation MPLS.


TTL d’entrée

Le TTL d’entrée est le TTL MPLS du sommet de la pile lorsque un paquet étiqueté est reçu sur une interface de LSR, ou le TTL de la couche réseau (IP) si le paquet n’est pas étiqueté.


TTL de sortie

Le TTL de sortie est le TTL MPLS du sommet de la pile lorsque un paquet étiqueté est transmis sur une interface de LSR, ou le TTL de la couche réseau (IP) si le paquet n’est pas étiqueté.


De plus, le présent document utilise la terminologie de la [RFC3031].


3. Caractéristiques particulières des commutateurs de relais de trame


Alors que l’architecture de commutation d’étiquettes permet une souplesse considérable dans la mise en œuvre d’un LSR, un FR-LSR est restreint par les capacités du matériel (éventuellement préexistantes) et les restrictions sur des questions telles que le format de trame imposé par l’interconnexion multiprotocole sur le relais de trame [RFC2427], ou les normes de relais de trame [FRF], etc.... À cause de ces contraintes, certaines procédures spéciales sont exigées pour les FR-LSR.


Certaines des caractéristiques clés des commutateurs de relais de trame qui affectent leur comportement comme LSR sont :

- La fonction d’échange d’étiquettes est effectuée sur des champs (DLCI) dans l’en-tête de liaison de données de relais de trame de la trame ; cela impose la taille et le placement de la ou des étiquettes dans un paquet. La taille du champ DLCI peut être de 10 (par défaut) ou de 23 bits, et elle peut s’étendre sur deux ou quatre octets dans l’en-tête.

- Il n’y a généralement pas de capacité d’effectuer une fonction de "diminution de TTL" comme c’est effectué sur les en-têtes IP dans les routeurs.

- Le contrôle de l’encombrement est effectué par chaque nœud sur la base de paramètres qui sont passés à la création du circuit. Des fanions dans les en-têtes de trame peuvent être établis par suite d’encombrement, ou de dépassement de paramètres contractuels du circuit.

- Bien que dans un commutateur standard il soit possible de configurer plusieurs DLCI d’entrée pour un DLCI de sortie, résultant en un circuit multipoint à point, les circuits virtuels en multipoint à multipoint ne sont généralement pas pleinement pris en charge.


Le présent document décrit les façons d’appliquer la commutation d’étiquettes aux commutateurs de relais de trame, qui fonctionnent avec ces contraintes.


4. Encapsulation d’étiquette


Par défaut, tous les paquets étiquetés devraient être transmis avec l’encapsulation générique d’étiquette comme défini dans la [RFC3032], en utilisant le mécanisme d’encapsulation nul du relais de trame:


0 1 (Octets)

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

(Octets)0 | |

/ Adresse Q.922 /

/ (la longueur 'n' égale 2 ou 4) /

| |

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

n | . |

/ . /

/ paquet MPLS /

| . |

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


"n" est la longueur de l’adresse Q.922 qui peut être de 2 ou 4 octets.


La représentation de Q.922 [ITU] d’un DLCI (en ordre canonique - le premier bit est mémorisé comme bit de moindre poids, c’est-à-dire, le bit le plus à droite d’un octet en mémoire ) est le suivant :


7 6 5 4 3 2 1 0 (ordre des bits)

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

(octet) 0 | DLCI(poids fort) | 0 | 0 |

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

1 | DLCI(moindre poids) | 0 | 0 | 0 | 1 |

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

DLCI de 10 bits



7 6 5 4 3 2 1 0 (ordre des bits)

+-----+-----+-----+-----+-----+-----+-----+-----00

(octet) 0 | DLCI(poids fort) | 0 | 0 |

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

1 | DLCI | 0 | 0 | 0 | 0 |

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

2 | DLCI | 0 |

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

3 | DLCI (moindre poids) | 0 | 1 |

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

DLCI de 23 bits


L’utilisation de l’encapsulation nulle de relais de trame implique que les étiquettes codent implicitement le type de protocole réseau.


Les règles concernant la construction de la pile d’étiquettes, et les messages d’erreur retournés à la source de la trame sont aussi décrites dans la [RFC3032].


L’encapsulation générique contient "n" étiquettes pour une pile d’étiquettes de profondeur "n" [RFC3032], où l’entrée du sommet de la pile porte les valeurs significatives pour les champs EXP, S , et TTL [RFC3032] mais pas pour l’étiquette, qui est plutôt portée dans le champ DLCI de l’en-tête de liaison de données du relais de trame codé en format d’adresse Q.922 [ITU].


5. Traitement de la commutation d’étiquette en relais de trame

5.1 Utilisation des DLCI


La commutation d’étiquette est réalisée en associant des étiquettes à des chemins et en utilisant la valeur de l’étiquette pour transmettre les paquets, y compris en déterminant la valeur de toute étiquette de remplacement. Voir d’autres précisions dans la [RFC3031]. Dans un FR-LSR, l’étiquette MPLS du sommet (en cours) est portée dans le champ DLCI de l’en-tête de couche liaison des données de relais de trame de la trame. L’étiquette du sommet porte des informations implicites sur le type de protocole réseau.


Pour deux FR-LSR connectés, une connexion bidirectionnelle doit être disponible pour LDP. Le DLCI pour le VC LDP reçoit une valeur par configuration, similaire à la configuration du DLCI utilisé pour faire fonctionner les protocoles d’acheminement IP entre les commutateurs.


À l’exception de cette valeur configurée, les valeurs de DLCI utilisées pour MPLS dans les deux directions de la liaison peuvent être traitées comme appartenant à deux espaces indépendants, c’est-à-dire que les VC peuvent être unidirectionnels, chaque direction avec son propre DLCI.


Les gammes admises de DLCI, la taille des DLCI, et la prise en charge de la fusion des VC DOIVENT être communiquées par des messages LDP. Noter que la gamme des DLCI utilisés pour les étiquettes dépend de la taille du champ DLCI.


5.2 LSP homogènes


Si <LSR1, LSR2, LSR3> est un LSP, il est possible que LSR1, LSR2, et LSR3 utilisent le même codage de la pile d’étiquettes lors de la transmission du paquet P du LSR1 au LSR2, puis au LSR3. Un tel LSP est homogène.


5.3 LSP hétérogènes


Si <LSR1, LSR2, LSR3> est un LSP, il est possible que LSR1 utilise un codage de la pile d’étiquettes lorsque il transmet le paquet P au LSR2, mais que le LSR2 utilise un codage différent lors de la transmission d’un paquet P au LSR3. En général, l’architecture MPLS accepte les LSP avec des codages différents de pile d’étiquettes sur les différents bonds. Lorsque un paquet étiqueté est reçu, le LSR doit le décoder pour déterminer la valeur actuelle de la pile d’étiquettes, puis doit opérer sur la pile d’étiquettes pour déterminer la nouvelle valeur d’étiquette de la pile, et ensuite coder de façon appropriée la nouvelle valeur avant de transmettre le paquet étiqueté à son prochain bond.


Naturellement il y aura des réseaux MPLS qui contiendront une combinaison de commutateurs de relais de trame fonctionnant comme des LSR, et d’autres LSR, qui fonctionneront en utilisant d’autres encapsulations MPLS, comme l’encapsulation générique (en-tête MPLS de calage) ou l’encapsulation ATM. Dans de tels réseaux, il peut y avoir des LSR qui ont des interfaces de relais de trame aussi bien que des interfaces génériques MPLS ("cale MPLS"). C’est un exemple de LSR avec différents codages de pile d’étiquettes sur différents bonds du même LSP. Un tel LSR peut changer une étiquette codée en relais de trame sur une interface entrante et la remplacer par une étiquette codée en en-tête MPLS générique (cale MPLS) sur l’interface sortante.


5.4 Prévention et contrôle de boucle de commutation d’étiquette en relais de trame


Les FR-LSR DEVRAIENT fonctionner sur des FR-LSP ou des segments de LSP en relais de trame sans boucle. Donc, les FR-LSR DEVRAIENT utiliser la détection de boucle et PEUVENT utiliser le mécanisme de prévention de boucle décrit dans les [RFC3031] et [RFC3036].


5.4.1 Contrôle de boucle des FR-LSR – traitement MPLS du TTL

Le TTL MPLS codé dans la pile d’étiquettes MPLS est un mécanisme utilisé pour :

(a) supprimer les boucles;

(b) limiter la portée d’un paquet.


Lorsque un paquet voyage le long d’un LSP, il devrait émerger avec la même valeur de TTL qu’il aurait eue si il avait traversé la même séquence de routeurs sans avoir subi la commutation d’étiquettes. Si le paquet voyage le long d’une hiérarchie de LSP, le nombre total de LSR/bonds traversés devrait se refléter dans sa valeur de TTL lorsque il émerge de la hiérarchie de LSP [RFC3031].


La valeur initiale du TTL MPLS est chargée dans une entrée de pile d’étiquettes nouvellement poussée à partir de la valeur de TTL précédente, que ce soit à partir de l’en-tête de couche réseau lorsque il n’existait pas de précédente pile d’étiquettes, ou à partir d’une entrée préexistante de pile d’étiquettes de niveau inférieur.


Un FR-LSR qui commute des paquets étiquetés de même niveau ne décrémente pas le TTL MPLS. Une séquence de ces FR-LSR est un "segment sans TTL".


Lorsque un paquet émerge d’un "segment de LSP sans TTL", il devait cependant refléter dans le TTL le nombre de LSR/bonds qu’il a traversés. Dans le cas de l’envoi individuel, cela peut être réalisé par la propagation d’une longueur de LSP significative ou d’une longueur de segment de LSP en relais de trame aux nœuds d’entrée du FR-LSR, permettant à l’entrée de décrémenter la valeur du TTL avant de transmettre les paquets dans un segment de LSP sans TTL [RFC3031].


Lorsque un FR-LSR d’entrée détermine en décrémentant le TTL MPLS que le TTL d’un certain paquet va arriver à expiration avant que le paquet atteigne la sortie du "segment de LSP sans TTL", le FR-LSR NE DOIT PAS utiliser la commutation d’étiquette sur le paquet, mais plutôt suivre les spécifications de la [RFC3032] en tentant de retourner un message d’erreur à la source du paquet :

- il traite le paquet comme expiré et retourne un message ICMP à sa source.

- il transmet le paquet, comme paquet non étiqueté, avec un TTL qui reflète la transmission IP (couche réseau).


Si le TTL entrant est 1, seule la première option s’applique.


Dans le cas de diffusion groupée, une longueur significative de LSP ou une longueur de segment de LSP est propagée au nœud de sortie du FR-LSR, permettant à la sortie de décrémenter la valeur de TTL avant de transmettre les paquets hors du segment de LSP sans TTL.


5.4.2 Effectuer les calculs de TTL MPLS


Le calcul appliqué au "TTL d’entrée" qui donne le "TTL de sortie" dépend (i) de "l’encapsulation d’entrée", (ii) de "l’encapsulation de transmission", et (iii) de "l’encapsulation de sortie". La relation entre (i) (ii) et (iii) peut être définie comme une fonction "D" de "l’encapsulation d’entrée" (ee), de "l’encapsulation de transmission" (et), et de "l’encapsulation de sortie" (es). Par conséquent, les calculs appliqués au "TTL d’entrée" pour donner le "TTL de sortie" peuvent être décrits par : TTL de sortie = TTL d’entrée - D(es, ee, et), ou en notation abrégée : TTL de sortie = TTL d’entrée – d, où "d" a trois valeurs possibles : "0", "1", ou "le nombre de bonds du segment de LSP".



Pour la transmission en envoi individuel :


d

Type d’encapsulation d’entrée

Type d’encapsulation de transmission

Type d’encapsulation de sortie

0

Relais de trame

Relais de trame

Relais de trame

1

n’importe lequel

MPLS générique

MPLS générique

nombre de bonds du segment de LSP

n’importe lequel

MPLS générique
ou IP (couche réseau)

Relais de trame


Le "nombre de bonds du segment de LSP" est la valeur du "compte de bonds" qui est attaché à l’étiquette utilisée lorsque le paquet est transmis, si LDP [RFC3036] a fourni une valeur d’un tel "compte de bonds" lorsque il a distribué l’étiquette pour ce LSP, c’est-à-dire que le message LDP avait un "objet Compte de bonds". Si LDP n’a pas fourni un "compte de bonds", ou si il a fourni une valeur "inconnue", la valeur par défaut du "nombre de bonds du segment" est 1.

Lors de l’envoi d’un lien d’étiquette vers l’amont, le "compte de bonds" associé au lien correspondant provenant de l’aval, s’il est différent de la valeur "inconnue", DOIT être incrémenté de 1, et le résultat transmis vers l’amont comme compte de bonds associé au nouveau lien (la valeur "inconnue" est transmise inchangée). Si la valeur du nouveau "compte de bonds" excède la valeur "maximum", le FR-LSR NE DOIT PAS passer le lien en amont, mais plutôt DOIT envoyer une erreur en amont [RFC3036], [RFC3031].


Pour une transmission en diffusion groupée :


d

Type d’encapsulation d’entrée

Type d’encapsulation de transmission

Type d’encapsulation de sortie

0

Relais de trame

Relais de trame

Relais de trame

1

n’importe lequel

MPLS générique
ou IP (couche réseau)

Relais de trame

nombre de bonds du segment de LSP

Relais de trame

MPLS générique
ou IP (couche réseau)

n’importe lequel


En se référant à "l’encapsulation de transmission" avec l’abréviation "I" pour IP (couche réseau), "G" pour MPLS générique, et "F" pour relais de trame MPLS, en se référant à une interface de LSR avec l’abréviation "i" si l’encapsulation MPLS d’entrée ou de sortie est IP et qu’il n’y a pas d’encapsulation MPLS, avec "g" si l’encapsulation MPLS d’entrée ou de sortie est MPLS générique, avec "f" si c’est le relais de trame, avec "a" si c’est ATM, et en considérant de plus les symboles "iIf", "gGf", "fFf", etc... comme les LSR avec les encapsulations d’entrée, de transmission, et de sortie comme mentionné ci-dessus, ce qui suit décrit des exemples de calcul de TTL pour des LSP homogènes et hétérogènes présentés dans les paragraphes précédents :


LSP homogène

---------------

IP_ttl = n IP_ttl=mpls_ttl-1 = n-6

--------->iIf fIi--------->

| mpls_ttl = n-5 ^

| |

nombre de bonds 1| Relais de trame |5

| |

V 2 3 4 |

fFf--->fFf--->fFf--->fFf


"iIf" est le "LSR d’entrée" dans le LSP en relais de trame et calcule : mpls_ttl = IP_TTL - nombre de bonds = n-5

"fIi" est le "LSR de sortie" du LSP en relais de trame, et calcule : IP_ttl = mpls_ttl-1 = n-6


LSP hétérogène

-----------------

LSR d’entrée LSR de sortie

IP_ttl = n IP_ttl = n - 15

liens LAN PPP FR ATM PPP FR LAN

--->iIg-->gGg-->gGf fGa aGg-->gGf fGg-->gIi--->

bonds 1 2 | 6 | | 9 | 10 | 13 ^ 14 15

|1 4| |1 3| |1 3|

V 2 3 | V 2 | V 2 |

fFf-->fFf-->fFf aAa-->aAa fFf-->fFf

mpls_ttl

n-1 n-2 (n-2)-4=n-6 (n-6)-3=n-9 n-10 n-13 n-14


"iIg" est le "LSR d’entrée" dans le LSP ; il calcule : mpls_ttl = n-1

"gGf" est le "LSR de sortie" du segment MPLS générique, et le "LSR d’entrée" dans le segment en relais de trame, et il calcule : mpls_ttl = n-6

"fGa" est le "LSR de sortie" du segment en relais de trame, et le "LSR d’entrée" dans le segment ATM, et il calcule : mpls_ttl = n-9

"gGf" est le "LSR de sortie" du segment MPLS générique, et le "LSR d’entrée" dans le segment en relais de trame et il calcule : mpls_ttl = n-13

"fGg" est le "LSR de sortie" du segment en relais de trame, et le "LSR d’entrée" dans le segment MPLS générique et calcule : mpls_ttl = n-14

"gIi" est le "LSR de sortie" du LSP et calcule : IP_ttl = n-15


Autres exemples :


Relais de trame en envoi individuel -- TTL calculé à l’entrée


(LSR d’entrée) 1 2 3 4

x--->---+--->---+--->>--+-->>---x (LSR de sortie)

o.ttl=i.ttl-4 | 2 3

^

bonds 1|

|

x (LSR d’entrée)

o.ttl=i.ttl-3


Relais de trame en diffusion groupée -- TTL calculé à la sortie


(LSR de sortie)x o.ttl=i.ttl-3

bonds |

^3

(LSR d’entrée) | o.ttl=i.ttl-4

x--->---+--->---+--->---+--->---x (LSR de sortie)

1 2 3 4


5.5 Traitement d’étiquettes par les FR-LSR d’entrée

Lorsque un paquet entre pour la première fois dans un domaine MPLS, le paquet est transmis par les opérations normales de transmission de couche réseau à l’exception près que l’encapsulation sortante va inclure une pile d’étiquettes MPLS [RFC3032] avec au moins une entrée. L’encapsulation nulle de relais de trame va porter des informations implicites sur le protocole de couche réseau dans l’étiquette, qui DOIVENT être associées à ce seul protocole réseau. Le champ TTL dans l’entrée du sommet de la pile d’étiquettes est rempli avec le TTL de couche réseau (ou la limite de bonds) qui résulte de la transmission à la couche réseau [RFC3032]. Le traitement ultérieur du FR-LSR est similaire dans les deux cas possibles :


(a) le LSP est homogène – seulement en relais de trame – et le FR-LSR est l’entrée ;


(b) le LSP est hétérogène – des segments en relais de trame, PPP, Ethernet, ATM, etc... forment le LSP – et le FR-LSR est l’entrée dans un segment en relais de trame.


Pour les paquets en envoi individuel, le TTL MPLS DEVRAIT être décrémenté du nombre de bonds du LSP qui sont en relais de trame (s’il est homogène) ou du segment en relais de trame du LSP (hétérogène). Un LDP qui construit le LSP DEVRAIT passer les informations significatives au FR-LSR d’entrée en ce qui concerne le nombre de bonds du "segment sans TTL".


Pour les paquets en diffusion groupée, le TTL MPLS DEVRAIT être décrémenté de 1. Un LDP qui construit le LSP DEVRAIT passer les informations significatives au FR-LSR de sortie en ce qui concerne le nombre de bonds du "segment sans TTL".


Ensuite, le paquet encapsulé MPLS est repassé au pilote de liaison de données de relais de trame avec l’étiquette du sommet comme DLCI de sortie. La trame de relais de trame qui porte le paquet encapsulé MPLS est transmise sur le circuit virtuel de relais de trame jusqu’au prochain LSR.


5.6 Traitement d’étiquettes par les FR-LSR de cœur

Dans un FR-LSR, l’étiquette MPLS en cours (du sommet) est portée dans le champ DLCI de l’en-tête de couche liaison des données de relais de trame de la trame. Tout comme en relais de trame conventionnel, pour une trame qui arrive à une interface, le DLCI porté par l’en-tête de liaison de données de relais de trame est recherché dans la base de données d’informations de DLCI, remplacé par le DLCI de sortie correspondant, et transmis sur l’interface de sortie (transmis au nœud de prochain bond).


Les informations d’étiquette actuelles sont aussi portées au sommet de la pile d’étiquettes. Dans l’entrée de niveau supérieur, tous les champs, sauf les informations d’étiquette, qui sont portés et commutés dans l’en-tête de couche de liaison des données de la trame de relais de trame, ont la signification qu’ils affichent.


5.7 Traitement d’étiquettes par les FR-LSR de sortie

Lorsque il atteint la fin d’un LSP en relais de trame, le FR-LSR saute la pile d’étiquettes [RFC3031]. Si l’étiquette sautée est la dernière étiquette, il est nécessaire de déterminer le protocole de couche réseau particulier qui est porté. La pile d’étiquettes ne porte pas d’information explicite pour identifier le protocole de couche réseau. Cela doit être déduit de la valeur de l’étiquette qui est sautée dans la pile.


Si l’étiquette sautée n’est pas la dernière étiquette, le TTL MPLS de niveau supérieur précédent est propagé à la nouvelle entrée du sommet de la pile d’étiquettes.


Si le FR-LSR est le commutateur de sortie d’un segment en relais de trame d’un LSP hybride, et si la fin du segment en relais de trame n’est pas la fin du LSP, le paquet MPLS sera traité pour transmission sur le prochain segment du LSP sur la base des informations contenues dans l’entrée de transmission de l’étiquette du prochain bond (NHLFE, Next Hop Label Forwarding Entry) [RFC3031]. L’étiquette de sortie est réglée à la valeur tirée de la NHLFE, et le TTL MPLS est décrémenté de la valeur appropriée selon le type de l’interface de sortie et le type d’opération de transmission (voir au paragraphe 6.3). De plus, le paquet MPLS est transmis conformément aux spécifications MPLS pour la liaison particulière du prochain segment du LSP.


Pour les paquets en envoi individuel, le TTL MPLS DEVRAIT être décrémenté de un si l’interface de sortie est générique, ou du nombre de bonds du prochain segment ATM du LSP (hétérogène) si l’interface de sortie est une interface ATM (sans TTL).


Pour les paquets en diffusion groupée, le TTL MPLS DEVRAIT être décrémenté du nombre de bonds du segment en relais de trame dont il sort. Un LDP construisant le LSP DEVRAIT passer les informations significatives au FR-LSR de sortie en ce qui concerne le nombre de bonds du segment en relais de trame "sans TTL".


6. Composant de contrôle de commutation d’étiquette pour le relais de trame


Pour prendre en charge la commutation d’étiquettes, un commutateur de relais de trame DOIT mettre en œuvre le composant de contrôle de commutation d’étiquettes, qui consiste principalement en procédures d’allocation et de maintenance d’étiquettes. Les informations de liens d’étiquettes PEUVENT être communiqués par plusieurs mécanismes, dont l’un est le protocole de distribution d’étiquettes (LDP, Label Distribution Protocol) [RFC3036].


Comme le composant de contrôle de commutation d’étiquettes utilise des informations apprises directement des protocoles d’acheminement de couche réseau, cela implique que le commutateur DOIT participer comme un homologue à ces protocoles (par exemple, OSPF, IS-IS).


Dans certains cas, les LSR peuvent utiliser d’autres protocoles (par exemple, RSVP, PIM, BGP) pour distribuer les liens d’étiquettes. Dans ces cas, un LSR de relais de trame devrait participer à ces protocoles.


Dans le cas où les circuits de relais de trame sont établis via LDP, ou RSVP, ou autres, sans implication des mécanismes traditionnels de relais de trame, on suppose que les informations contractuelles d’établissement de circuit telles que la taille maximum de trame d’entrée/sortie, le débit d’entrée/sortie demandé/accepté, le débit d’entrée/sortie acceptable, la taille de salve d’entrée/sortie, le taux de trame d’entrée/sortie, utilisées dans la transmission, et le contrôle d’encombrement, PEUVENT être passées aux FR-LSR par RSVP, ou peuvent être statiquement configurées. On suppose aussi que le contrôle d’encombrement et l’établissement de fanions d’en-tête de trame par suite d’encombrement, seront faits par les FR-LSR de façon similaire à celle des circuits traditionnels de relais de trame. Avec l’objectif d’émuler un routeur au mieux comme routeur par défaut, les paramètres de circuit virtuel par défaut, en l’absence de LDP, RSVP, ou autres mécanismes participant au réglage de tels paramètres, devraient être un CIR zéro, afin que la régulation d’entrée établisse le bit DE dans les trames entrantes, mais qu’aucune trame ne soit abandonnée.


Les informations de contrôle et d’état pour les circuits fondés sur MPLS PEUVENT être communiquées par LDP.


La prise en charge de la commutation d’étiquettes sur un commutateur de relais de trame exige seulement la conformité à [FRF] (tramage, bourrage de bits, en-têtes, FCS) sauf pour le paragraphe 2.3 (procédures de signalisation de contrôle de PVC, autrement dit LMI). La signalisation Q.933 pour les PVC et/ou SVC n’est pas exigée. La signalisation de PVC et/ou SVC peut être utilisée pour les PVC et/ou SVC non MPLS (relais de trame standard) lorsque tous deux fonctionnent sur la même interface que MPLS, comme exposé au paragraphe suivant.


6.1 Commutateurs hybrides (vaisseaux dans la nuit)


L’existence du composant de contrôle de commutation d’étiquettes sur un commutateur de relais de trame n’empêche pas la capacité à prendre en charge le composant de contrôle de relais de trame défini par l’UIT et le Forum Relais de trame sur le même commutateur et les mêmes interfaces (NIC). Les deux composants de contrôle, de commutation d’étiquettes et ceux définis par l’UIT/Forum Relais de trame, vont fonctionner indépendamment.


La définition de la façon dont fonctionne un tel appareil sort du domaine d’application du présent document. Cependant, seule une petite quantité d’informations a besoin d’être coordonnée entre les deux composants de contrôle, comme les portions de l’espace de DLCI qui sont disponibles pour chaque composant.


7. Procédures d’allocation et de maintenance des étiquettes


Les mécanismes et les formats de message d’un protocole de distribution d’étiquettes sont documentés dans les [RFC3031] et [RFC3036]. Le mécanisme d’allocation et de maintenance d’étiquettes "vers l’aval à la demande" exposé dans la présente section DOIT être utilisé par les FR-LSR qui ne prennent pas en charge la fusion de VC, et il PEUT aussi être utilisé par les FR-LSR qui prennent en charge la fusion de VC (noter que ce mécanisme s’applique au trafic acheminé bond par bond):


7.1 Comportement de LSR de bordure


Considérons un membre de l’ensemble bordure d’un domaine FR-LSR. Supposons que, par suite de ses calculs d’acheminement, il choisisse un FR-LSR comme prochain bond d’un certain chemin (FEC), et que le prochain bond soit accessible via une interface LC-FR. Supposons que le FR-LSR de prochain bond soit un "homologue LDP" [RFC3031], [RFC3036]. Le LSR bordure envoie un message de "demande" LDP pour un lien d’étiquette à partir du LSR aval de prochain bond. Lorsque le LSR bordure reçoit en réponse du LSR aval les informations de lien d’étiquette dans un message LDP "transposition", l’étiquette est mémorisée dans la base de données d’informations d’étiquettes (LIB, Label Information Base) comme étiquette sortante pour cette FEC. Le message "transposition" peut contenir l’objet "compte de bonds", qui représente le nombre de bonds qu’il faudra à un paquet pour traverser le domaine FR-LSR jusqu’au FR-LSR de sortie quand on utilise cette étiquette. Ces informations peuvent être mémorisées pour le calcul du TTL. Une fois que c’est fait, le LSR peut utiliser la transmission MPLS pour transmettre les paquets dans cette FEC.


Lorsque un membre de l’ensemble bordure du domaine FR-LSR reçoit un message "demande" LDP d’un FR-LSR pour une FEC, cela signifie qu’il est le FR-LSR de sortie. Il alloue une étiquette, crée une nouvelle entrée dans sa base de données d’informations d’étiquettes (LIB), place cette étiquette dans le composant d’étiquette entrante de l’entrée, et retourne (via LDP) un message "transposition" contenant l’étiquette allouée vers l’amont à l’homologue LDP qui a généré la demande. Le message "transposition" contient la valeur de l’objet "compte de bonds" réglée à 1.


Lorsque un calcul d’acheminement cause un changement du prochain bond d’un chemin pour un LSR bordure, et que l’ancien prochain bond était dans le domaine FR-LSR, le LSR bordure devrait notifier à l’ancien prochain bond (via un message "libérer" LDP) que le lien d’étiquette associé à ce chemin n’est plus nécessaire.


Lorsque un LSR en relais de trame reçoit un message "demande" LDP pour un certain chemin (FEC) à partir d’un homologue LDP connecté au FR-LSR par une interface LC-FR, le FR-LSR entreprend les actions suivantes :

- il alloue une étiquette, crée une nouvelle entrée dans sa LIB, et place cette étiquette dans le composant d’étiquette entrante de l’entrée ;

- il propage la "demande", en envoyant un message LDP "demande" au LSR de prochain bond, en aval de ce chemin (cette FEC);


Dans le mode "contrôle ordonné" [RFC3031], le FR-LSR va attendre que sa "demande" reçoive une réponse de la part de l’aval avec un message "transposition" avant de retourner la "transposition" vers l’amont en réponse à une "demande" (approche "contrôle ordonné" de la [RFC3031]). Dans ce cas, le FR-LSR incrémente le compte de bonds qu’il a reçu de l’aval et utilise cette valeur dans la "transposition" qu’il retourne vers l’amont.


Autrement, le FR-LSR peut retourner le lien vers l’amont sans attendre qu’arrive un lien de l’aval (c’est l’approche du contrôle "indépendant" de la [RFC3031]). Dans ce cas, il utilise une valeur réservée pour le compte de bonds dans la "transposition", indiquant qu’il est "inconnu". La valeur correcte pour le compte de bonds sera retournée plus tard, comme on le décrit ci-dessous.


Comme le contrôle "ordonné" et "indépendant" présentent tous deux des avantages et des inconvénients, ils restent au choix de la mise en œuvre, ou de la configuration.


Une fois que le FR-LSR a reçu en réponse le lien d’étiquette dans un message LDP "transposition" de la part du prochain bond, il place l’étiquette dans le composant d’étiquette sortante de l’entrée de la LIB.


Noter qu’un FR-LSR, ou un membre de l’ensemble bordure d’un domaine FR-LSR, peut recevoir plusieurs demandes de lien pour le même chemin (la même FEC) de la part du même FR-LSR. Il doit générer une nouvelle "transposition" pour chaque "demande" (en supposant des ressources adéquates pour le faire) et conserver toutes les transpositions existantes. Pour chaque "demande" reçue, un FR-LSR devrait aussi générer une nouvelle "demande" de lien vers le prochain bond pour ce chemin (cette FEC).


Lorsque un calcul de chemin cause le changement du prochain bond d’un chemin (d’une FEC) chez un FR-LSR, celui-ci devrait notifier à l’ancien prochain bond (via un message LDP "libérer") que le lien d’étiquette associé au chemin n’est plus nécessaire.


Lorsque un LSR reçoit une notification qu’un certain lien d’étiquette n’est plus nécessaire, le LSR peut résilier l’association de l’étiquette et du lien, et détruire le lien. Ce mode est le "mode prudent de rétention d’étiquette" de la [RFC3031]. Dans le cas où un FR-LSR reçoit de telles notifications et détruit les liens, il devrait notifier au prochain bond pour ce chemin que le lien d’étiquette n’est plus nécessaire. Si un LSR ne détruit pas le lien (le FR-LSR est configuré dans le mode "libéral de rétention d’étiquette" de la [RFC3031]) il ne peut réutiliser le lien que si il reçoit une demande pour le même chemin avec le même compte de bonds que celui de la demande qui a causé à l’origine la création du lien.


Lorsque un chemin change, les liens d’étiquettes sont rétablis à partir du point où le chemin diverge du chemin précédent. Les LSR en amont de ce point vont (à une exception près, indiquée ci-dessous) oublier ce changement. Chaque fois qu’un LSR change son prochain bond pour un certain chemin, si le nouveau prochain bond est un FR-LSR ou un membre de l’ensemble bordure accessible via une interface de LC-FR, alors pour chaque entrée de sa LIB associée au chemin, le LSR devrait demander (via LDP) un lien à partir du nouveau prochain bond.


Lorsque un FR-LSR reçoit un lien d’étiquette d’un voisin vers l’aval, il peut avoir déjà fourni un lien d’étiquette correspondant pour ce chemin à un voisin vers l’amont, soit parce qu’il utilise le "contrôle indépendant", soit parce que le nouveau lien provenant de l’aval est le résultat d’un changement d’acheminement. Dans ce cas, il devrait extraire le compte de bonds du nouveau lien et l’incrémenter de un. Si le nouveau compte de bonds est différent de celui qui avait été précédemment convoyé au voisin amont (y compris dans le cas où le voisin amont avait donné la valeur 'inconnu') le FR-LSR doit notifier le changement au voisin amont. Chaque FR-LSR incrémente à son tour le compte de bonds et le passe en amont jusqu’à ce qu’il atteigne le LSR bordure d’entrée.


Chaque fois qu’un FR-LSR génère une demande de lien d’étiquette à son LSR de prochain bond par suite de la réception d’une demande de lien d’étiquette de la part d’un autre LSR (amont) et que la demande au LSR de prochain bond n’est pas satisfaite, le FR-LSR devrait détruire le lien créé en réponse à la demande reçue, et le notifier au demandeur (via un message LDP "retrait").


Lorsque un LSR détermine qu’il a perdu sa session LDP avec un autre LSR, les actions suivantes sont effectuées :

- il DOIT éliminer toutes les informations de liens apprises via cette connexion ;

- pour tout lien d’étiquette qui a été créé par suite de la réception de demandes de lien d’étiquettes de la part de l’homologue, le LSR peut détruire ces liens (et désallouer les étiquettes associées à ces liens).


7.2 Utilisation efficace de l’espace d’étiquettes – fusion des FR-LSR


L’exposé ci-dessus suppose qu’un LSR bordure va demander une étiquette pour chaque préfixe de son tableau d’acheminement qui a un prochain bond dans le domaine FR-LSR. En fait, il est possible de réduire de façon significative le nombre d’étiquettes nécessaires en faisant que le LSR bordure ne demande plutôt qu’une seule étiquette pour plusieurs chemins. L’utilisation de transpositions de plusieurs en une entre les chemins (entre les préfixes d’adresse) et les étiquettes en utilisant la notion de classe d’équivalence de transmission (FEC, Forwarding Equivalence Classe) (comme décrit dans la [RFC3031]) donne un mécanisme pour conserver le nombre d’étiquettes.


Noter que la conservation de l’espace d’étiquettes (fusion de VC) peut être restreinte dans le cas où le trafic de trame exige la fragmentation de relais de trame. Le problème est que les fragments de relais de trame doivent être transmis en séquence, c’est-à-dire que les fragments de trames distinctes ne doivent pas être entrelacés. Si la fragmentation de FR-LSR assure la transmission en séquence de tous les fragments d’une trame, sans entrelacement avec les fragments d’autres trames, la conservation d’étiquette (fusion de VC) peut être effectuée.


Lorsque la conservation d’étiquette est utilisée, lorsque un FR-LSR reçoit une demande de lien d’un LSR amont pour une certaine FEC, et qu’il a déjà un lien d’étiquette sortante pour cette FEC, il n’a pas besoin de produire une demande de lien vers l’aval. Il peut plutôt allouer une étiquette entrante, et retourner au demandeur amont cette étiquette dans un lien. Les paquets reçus du demandeur, avec cette étiquette comme étiquette de sommet, seront transmis après remplacement de l’étiquette par l’étiquette sortante existante pour cette FEC. Si le FR-LSR n’a pas de lien d’étiquette sortante pour cette FEC, mais s’il a une demande en instance pour en avoir une, il n’a pas besoin de produire une autre demande. Cela signifie que dans un cas de conservation d’étiquette, un FR-LSR doit répondre par un nouveau lien pour chaque demande de l’amont, mais il peut avoir besoin d’envoyer une demande de lien vers l’aval.


Dans le cas de conservation d’étiquette, si un changement dans le tableau d’acheminement cause la sélection par le FR-LSR d’un nouveau prochain bond pour une de ses FEC, il PEUT libérer le lien pour ce chemin à partir de l’ancien prochain bond. S’il n’a pas déjà un lien correspondant pour le nouveau prochain bond, il doit en demander un (noter que le choix dépend du mode de rétention d’étiquette [RFC3031]).


Si un nouveau lien est obtenu, qui contient un compte de bonds qui diffère de celui de l’ancien lien, le FR-LSR doit traiter le nouveau compte de bonds : l’incrémenter de 1, si il est différent de "inconnu", et notifier la nouvelle valeur aux voisins amont qui ont des liens d’étiquettes pour cette FEC. Pour s’assurer que les boucles seront détectées, si le nouveau compte de bonds excède la valeur "maximum", la valeur de l’étiquettes pour cette FEC doit être retirée de tous les voisins amont à qui un lien a été envoyé précédemment.


7.3 Messages LDP spécifiques du relais de trame


Les messages du protocole de distribution d’étiquettes [RFC3036] échangés entre des LSR "homologues LDP" en relais de trame peuvent contenir des informations spécifiques du relais de trame telles que :


"Gamme d’étiquettes de relais de trame" :


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

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

| Réservé |Lon| DLCI minimum |

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

| Réservé | DLCI maximum |

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


avec les champs suivants :


Réservé : Ces champs sont réservés. Il doivent être réglés à zéro à l’émission et ignorés à la réception.


Lon(gueur)

Ce champ spécifie le nombre de bits du DLCI. Les valeurs suivantes sont acceptées :

Lon bits du DLCI

0 10

2 23

Les valeurs de Lon 1 et 3 sont réservée pour un usage futur.


DLCI minimum

Ce champ de 23 bits est la valeur binaire de la limite inférieure d’un bloc d’identifiants de connexion de liaison de données (DLCI, Data Link Connection Identifier) qui est acceptée par le FR-LSR d’origine. Le DLCI minimum devrait être justifié à droite dans ce champ et les bits précédents devraient être réglés à 0.


DLCI maximum

Ce champ de 23 bits est la valeur binaire de la limite supérieure d’un bloc d’identifiants de connexion de liaison de données (DLCI) qui est acceptée par le FR-LSR d’origine. Le DLCI maximum devrait être justifié à droite dans ce champ et les bits précédents devraient être réglés à 0.


"Fusion de relais de trame" :


0 1 2 3 4 5 6 7

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

| Réservé |F|

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


avec les champs suivants :


F(usion)

Champ d’un bit qui spécifie les capacités de fusion du FR-LSR :

Valeur Signification

0 Fusion non acceptée

1 Fusion acceptée


Un FR-LSR qui accepte la fusion de VC DOIT s’assurer que les trames fragmentées provenant de DLCI distincts ne sont pas entrelacées sur le DLCI sortant.


Réservé

Ce champ est réservé. Il doit être réglé à zéro à l’émission et ignoré à réception.


"Étiquette de relais de trame" :


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

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

| Réservé |Lon| DLCI |

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


avec les champs suivants :


Réservé

Ce champ est réservé. Il doit être réglé à zéro à l’émission et ignoré à réception.


Lon

Ce champ spécifie le nombre de bits du DLCI. Les valeurs suivantes sont acceptées :

Lon bits du DLCI

0 10

2 23

Les valeurs de Lon(gueur) 1 et 3 sont réservée pour une utilisation future.


DLCI

C’est la valeur binaire de l’étiquette de relais de trame. Le nombre significatif de bits (10 ou 23) de la valeur de l’étiquette est à coder dans le champ d’identifiant de connexion de liaison de données (DLCI) lorsque il fait partie de l’en-tête de liaison de données de relais de trame (voir la Section 4.).


8. Considérations pour la sécurité


Cette section examine les aspects de la sécurité (a) du trafic de trames, (b) de la distribution. des étiquettes.


L’encapsulation MPLS n’a pas d’effet sur les paquets de couche réseau authentifiés ou chiffrés, c’est-à-dire que les paquets IP qui sont authentifiés ou chiffrés ne vont subir aucun changement.


Le protocole MPLS n’a pas de mécanisme propre pour protéger contre la mauvaise orientation des paquets ou l’erreur d’identité sur un LSR par accident ou intention malveillante.


L’altération accidentelle ou malveillante d’un étiquette existante dans le champ DLCI de l’en-tête Relais de trame de couche de liaison des données d’une trame ou d’un ou plusieurs champs dans une pile d’étiquettes éventuellement suivante affecte la transmission de cette trame.


Le mécanisme de distribution d’étiquettes peut être sécurisé en appliquant le niveau de sécurité approprié au protocole sous-jacent qui porte les informations d’étiquettes – authentification ou chiffrement – voir la [RFC3036].


9. Remerciements


La version initiale du présent document a été déduite du document sur la commutation d’étiquettes en ATM [RFC3035].


Merci de leur relecture attentive et de leurs commentaires constructifs à (en ordre alphabétique) Dan Harrington, Milan Merhar, Martin Mueller, Eric Rosen. Merci aussi à George Swallow pour sa suggestion d’utiliser l’encapsulation nulle, et à Eric Gray pour sa relecture.


Des remerciements sont aussi dus à Nancy Feldman et Bob Thomas pour leur collaboration à l’inclusion des messages de LDP spécifiques des LSR en relais de trame.


10. Références


[FRF] Frame Relay Forum, “User-to-Network Implementation Agreement (UNI)”, FRF 1.1, 19 janvier 1996.


[ITU] Union Internationale des Télécommunications, "Spécification de la couche de liaison des données RNIS pour les services support en mode relais de trame", Recommandation UIT-T Q.922, 1992.


[RFC2427] C. Brown, A. Malis, "Interconnexion multi protocole sur relais de trame", septembre 1998. (STD0055)


[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Architecture de commutation d'étiquettes multi protocoles", janvier 2001. (P.S.)


[RFC3032] E. Rosen, Y. Rehter, D. Tappan, D. Farinacci, G. Fedorkow, T. Li, et A. Conta, "Codage de pile d'étiquettes MPLS", janvier 2001.


[RFC3035] B. Davie et autres, "Utilisation de MPLS dans la commutation de circuit virtuel LDP et ATM", janvier 2001.


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


11. Adresse des auteurs


Alex Conta

Paul Doolan

Andrew G. Malis

Transwitch Corporation

Ennovate Networks

Vivace Networks, Inc.

3 Enterprise Drive

60 Codman Hill Rd

2730 Orchard Parkway

Shelton, CT 06484

Boxborough MA 01719

San Jose, CA 95134

téléphone : 1-203-929-8810

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

téléphone: 1-408-383-7223

mél : aconta@txc.com

mél : pdoolan@ennovatenetworks.com

mél : Andy.Malis@vivacenetworks.com


12. 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.