Network Working Group T

Définitions des conventions textuelles pour la gestion
de la commutation d'étiquettes multi protocoles (MPLS)

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.

Le présent mémoire définit un module de base de données d'informations de gestion (MIB, Management Information Base) qui contient les conventions textuelles pour représenter les informations courantes de la gestion de la commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching). L'intention est que ces conventions textuelles (TC, TEXTUAL CONVENTIONS) soient importées et utilisées dans les modules de MIB en rapport avec MPLS qui sans cela définiraient leurs propres représentations.

Table des Matières

1. Introduction

2. Cadre de gestion des normes de l'Internet

3. Définitions de MIB de conventions textuelles MPLS

4. Références

4.1 Références normatives

4.2 Référence pour information

5. Considérations sur la sécurité

6. Considérations relatives à l'IANA

7. Contributeurs

8. Remerciements

9. Adresse des auteurs

10. Déclaration complète de droits de reproduction

Le présent document définit un module de MIB qui contient les conventions textuelles pour les réseaux de commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching). Ces conventions textuelles devraient être importées par les modules de MIB qui gèrent les réseaux MPLS.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Pour un survol détaillé des documents qui décrivent le cadre actuel de gestion des normes de l'Internet, prière de se reporter à la section 7 de la [RFC3410].

On accède aux objets gérés via un magasin d'informations virtuel, appelé base de données d'informations de gestion (MIB, Management Information Base). Les objets de MIB sont généralement accessibles par le protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol). Les objets de la MIB sont définis à l'aide des mécanismes définis dans la structure des informations de gestion (SMI, Structure of Management Information). Le présent mémoire spécifie un module de MIB qui se conforme à la SMIv2, qui est décrite dans le STD 58, [RFC2578], [RFC2579] et [RFC2580].

MODULE-IDENTITY, Unsigned32, Integer32, transmission : DE SNMPv2-SMI -- [RFC2578]

ORGANISATION "Groupe de travail IETF commutation d'étiquette multi protocoles (MPLS)".

Envoyer les commentaires par messagerie à la liste de diffusion du groupe de travail MPLS à mpls@uu.net."

"Copyright (C) The Internet Society (2004). La version initiale de ce module de MIB a été publiée dans la RFC 3811. Voir toutes les notices légales dans cette RFC elle-même ou à : http://www.ietf.org/copyrights/ianamib.html

Ce module de MIB définit les CONVENTIONS TEXTUELLES pour des concepts utilisés dans les réseaux de commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching)".

DESCRIPTION : "Un routeur de commutation d'étiquettes (LSR, Label Switching Router) qui crée des sessions LDP sur des interfaces ATM utilise le champ VCI ou VPI/VCI pour détenir l'étiquette LDP. Les valeurs de VCI NE DOIVENT PAS être dans la gamme de 0 à 31. Les valeurs de 0 à 31 sont réservées pour d'autres usages par l'UIT et le Forum ATM. La valeur 32 peut seulement être utilisée pour le circuit virtuel de contrôle, mais des valeurs supérieures à 32 peuvent être configurées pour le circuit virtuel de contrôle.

Si une valeur entre 0 et 31 est utilisée pour un VCI, l'entité de gestion qui contrôle le sous système LDP devrait rejeter cela avec une erreur "valeur incohérente". Aussi, si la valeur de 32 est utilisée pour un VC qui N'EST PAS le VC de contrôle, il devrait en résulter une erreur "valeur incohérente".

RÉFÉRENCE : "Utilisation de MPLS dans la commutation de circuit virtuel LDP et ATM, [RFC3035]".

DESCRIPTION : "Si la valeur de cet objet est supérieure à zéro, cela représente alors la bande passante de cette interface MPLS (ou chemin de commutation d'étiquettes) en unités de "1 000 bits par seconde".

La valeur, lorsque supérieure à zéro, représente la bande passante de cette interface MPLS (arrondie au millier le plus proche) en unités de 1 000 bits par seconde. Si la bande passante de l'interface MPLS est entre ((n * 1000) - 500) et ((n * 1000) + 499) la valeur de cet objet est n, avec n > 0. Si la valeur de cet objet est 0 (zéro) cela signifie que le trafic sur cette interface MPLS est considéré comme au mieux".

DESCRIPTION : "Nombre d'octets de données MPLS que le flux peut envoyer en boucle locale sans se soucier de régulation. La valeur de zéro indique qu'une mise en œuvre ne prend pas en charge la taille de salve".

DESCRIPTION : "Identifiant univoque de tunnel MPLS. Cela peut représenter une adresse IPv4 du LSR d'entrée ou de sortie du tunnel. Cette valeur est déduite de l'identifiant étendu de tunnel dans RSVP ou de l'identifiant de routeur d'entrée pour CR-LDP."

DESCRIPTION : "Cette valeur représente une étiquette MPLS comme définie dans les [RFC3031], [RFC3032], [RFC3034], [RFC3035] et [RFC3471]. Les contenus d'étiquettes sont spécifiques de l'étiquette représentée, comme :

* l'étiquette portée dans un en-tête shim MPLS (pour LDP, c'est l'étiquette générique) est un nombre de 20 bits représenté par 4 octets. Les bits 0-19 contiennent une valeur d'étiquette ou une valeur d'étiquette réservée. Les bits 20-31 DOIVENT être à zéro. Ce qui suit est cité directement de la [RFC3032]. Il y a plusieurs valeurs d'étiquette réservées :

i. Une valeur de 0 représente "l’étiquette NUL explicite IPv4". Cette valeur d’étiquette n’est légale qu’au bas de la pile d’étiquettes. Elle indique que la pile d’étiquettes doit être sautée, et que la transmission du paquet doit alors se fonder sur l’en-tête IPv4.

ii. Une valeur de 1 représente "l’étiquette d’alerte de routeur". Cette valeur d’étiquette est légale partout dans la pile d’étiquettes sauf en fin. Lorsque un paquet reçu contient cette valeur d’étiquette au sommet de la pile d’étiquettes, il est livré à un module logiciel local pour traitement. La transmission réelle du paquet est déterminée par l’étiquette qui se trouve en dessous de celle-ci dans la pile. Cependant, si le paquet est transmis plus loin, l’étiquette d’alerte de routeur devrait être repoussée en arrière dans la pile d’étiquettes avant la transmission. L’utilisation de cette étiquette est analogue à l’utilisation de "l’option d’alerte de routeur" dans les paquets IP [RFC2113]. Comme cette étiquette ne peut pas survenir au bas de la pile, elle n’est pas associée à un protocole de couche réseau particulier.

iii. Une valeur de 2 représente "l’étiquette NUL explicite IPv6". Cette valeur d’étiquette n’est légale qu’au bas de la pile d’étiquettes. Elle indique que la pile d’étiquettes doit être sautée, et que la transmission du paquet doit alors se fonder sur l’en-tête IPv6.

iv. Une valeur de 3 représente "l’étiquette NUL implicite". C’est une étiquette qu’un LSR peut allouer et distribuer, mais qui n’apparaît en fait jamais dans l’encapsulation. Lorsque un LSR remplacerait autrement l’étiquette au sommet de la pile par une nouvelle étiquette, mais que la nouvelle étiquette est "NUL implicite", le LSR va sauter la pile au lieu de faire le remplacement. Bien que cette valeur puisse ne jamais apparaître dans l’encapsulation, elle doit être spécifiée dans le protocole de distribution d’étiquettes, de sorte qu’une valeur lui est réservée.

* L'étiquette de relais de trame peut être de 10 bits ou de 23 bits selon la taille du champ DLCI, et les 22 bits supérieurs ou les 9 bits supérieurs doivent être à zéro, respectivement.

* Pour une étiquette ATM, les 16 bits inférieurs représentent le VCI, les 12 bits suivants représentent le VPI, et les bits restants DOIVENT être à zéro.

* L'étiquette MPLS généralisé (GMPLS) contient une valeur supérieure à 2^24-1 qui est utilisée dans GMPLS comme défini dans la [RFC3471]".

RÉFÉRENCE : "Architecture de commutation d'étiquettes multi protocoles, [RFC3031]. Codage de pile d'étiquettes MPLS, [RFC3032]. Spécification de l'utilisation de la commutation d'étiquettes sur les réseaux en relais de trame, [RFC3034]. Utilisation de MPLS dans la commutation de circuit virtuel LDP et ATM, [RFC3035]. Commutation d'étiquettes multi-protocoles généralisée (GMPLS) : description fonctionnelle de la signalisation, [RFC3471]".

DESCRIPTION : "Méthode de distribution d'étiquette qui est aussi appelée le mode d'annonce d'étiquette [RFC3036]. Chaque interface sur un LSR est configuré pour fonctionner soit en vers l'aval non sollicité, soit en vers l'aval à la demande".

RÉFÉRENCE : "Architecture de commutation d'étiquettes multi protocoles, [RFC3031]. Spécification de LDP, [RFC3036], paragraphe 2.6.3".

DESCRIPTION : "L'identifiant de LDP est une quantité de six octets qui est utilisée pour identifier un espace d'étiquette de routeur de commutation d'étiquettes (LSR, Label Switching Router).

Les quatre premiers octets identifient le LSR et doivent être une valeur unique au monde, comme un identifiant de routeur de 32 bits alloué au LSR, et les deux derniers octets identifient un espace d'étiquette spécifique au sein du LSR".

DESCRIPTION : "L'identifiant de routeur de commutation d'étiquette est les quatre premiers octets de l'identifiant du protocole de distribution d'étiquettes (LDP, Label Distribution Protocol)".

DESCRIPTION : "Les types d'étiquettes de couche 2 qui sont définis pour les LDP et/ou CD-LDP MPLS sont generic(1), atm(2), ou frameRelay(3)."

DESCRIPTION : "Identifiant unique au sein d'un réseau MPLS qui est alloué à chaque LSP. Il est alloué à l'extrémité de début du LSP et peut être utilisé par tous les LSR pour identifier ce LSP. Cette valeur est portée par le protocole de signalisation lorsque ce LSP est signalé dans le réseau. Cet identifiant peut alors être utilisé à chaque LSR pour identifier quelles étiquettes sont échangées avec d'autres étiquettes pour ce LSP. Cet objet peut aussi être utilisé pour distinguer les LSP qui partagent les mêmes sessions RSVP entre la même source et destination.

Pour les LSP établis en utilisant CR-LDP, le LSPID est composé de l'identifiant de routeur de LSR d'entrée (ou une de ses propres adresses IPv4) et d'un identifiant de CR-LSP localement unique pour ce LSR. Les deux premiers octets portent le CR-LSPID, et les quatre octets restant portent l'identifiant de routeur. Le LSPID est utile dans la gestion de réseau, dans la réparation de CR-LSP, et pour utiliser un CR-LSP déjà établi comme bond dans un ER-TLV.

Pour les LSP signalés en utilisant RSVP-TE, l'identifiant de LSP est défini comme un identifiant de 16 bits (2 octets) utilisé dans le SENDER_TEMPLATE et le FILTER_SPEC qui peuvent être changés pour permettre à un envoyeur de partager des ressources avec lui-même. La longueur de cet objet devrait être seulement de 2 ou 6 octets. Si la longueur de cette chaîne d'octets est de 2 octets, elle doit alors identifier un LSPID RSVP-TE, ou si elle est de 6 octets, elle doit contenir un LSPID de CR-LDP".

RÉFÉRENCE : "RSVP-TE : Extensions à RSVP pour les tunnels LSP, [RFC3209]. Établissement de LSP fondé sur la contrainte avec LDP, [RFC3212]."

DESCRIPTION : "Les types de chemins de commutation d'étiquettes (LSP) sur un routeur de commutation d'étiquettes (LSR) ou un routeur bordure d'étiquettes (LER, Label Edge Router) sont :

terminatingLsp(2) -- si le LSP se termine sur le LSR/LER, c'est alors un LSP sortant qui se termine sur le LSR/LER,

originatingLsp(3) -- si le LSP a son origine à ce LSR/LER, c'est alors un LSP entrant qui est l'extrémité de tête du LSP,

crossConnectingLsp(4) – si le LSP entre et sort sur le LSR, il s'interconnecte sur ce LSR".

SYNTAXE : ENTIER { unknown(1), terminatingLsp(2), originatingLsp(3), crossConnectingLsp(4) }

DESCRIPTION : "Cet objet indique le sous système réseau local qui a créé à l'origine l'objet en question. Les valeurs de cette énumération sont définies comme suit :

unknown(1) – le sous système de gestion du réseau local ne peut pas discerner quel composant a créé l'objet.

other(2) - le sous système de gestion du réseau local est capable de discerner quel composant a créé l'objet, mais le composant ne figure pas dans la liste des choix suivants, par exemple, interface de ligne de commande (cli).

snmp(3) - le protocole simple de gestion de réseau a été utilisé pour configurer initialement cet objet.

ldp(4) – le protocole de distribution d'étiquettes a été utilisé pour configurer initialement cet objet.

crldp(5) - le protocole de distribution d'étiquettes fondées sur la contrainte a été utilisé pour configurer initialement cet objet.

rsvpTe(6) - le protocole de réservation de ressource a été utilisé pour configurer initialement cet objet.

policyAgent(7) – un agent de politique (peut-être en combinaison avec un des protocoles ci-dessus) a été utilisé pour configurer initialement cet objet.

Un objet créé par un des choix ci-dessus PEUT être modifié ou détruit par le même choix ou un choix différent".

SYNTAXE : ENTIER { unknown(1), other(2), snmp(3), ldp(4), crldp(5), rsvpTe(6), policyAgent(7) }

DESCRIPTION : "Identifiant univoque utilisé pour identifier un chemin spécifique utilisé par un tunnel. Une valeur de 0 (zéro) signifie qu'aucun chemin n'est utilisé".

DESCRIPTION : "Valeur univoque pour indexer (par numéro de chemin) une entrée dans un tableau".

DESCRIPTION : "C'est le mode de rétention d'étiquette qui spécifie si un LSR conserve un lien d'étiquette pour une FEC apprise d'un voisin qui n'est pas le prochain bond pour la FEC. Si la valeur est conservative(1) les transpositions d'étiquettes annoncées ne sont conservées que si elles vont être utilisées pour transmettre des paquets, c'est-à-dire, si l'étiquette vient d'un prochain bond valide. Si la valeur est liberal(2) alors toutes les transpositions d'étiquette annoncées sont conservées qu'elles viennent d'un prochain bond valide ou non".

RÉFÉRENCE "Architecture de commutation d'étiquettes multi protocoles,[ RFC3031]. Spécification de LDP, [RFC3036], paragraphe 2.6.2".

DESCRIPTION : "Décrit la contrainte configurée de 32 bits Include-any, include-all, ou exclude-all pour le choix de liaison fondé sur la contrainte".

RÉFÉRENCE "RSVP-TE : Extensions à RSVP pour les tunnels LSP, [RFC3209], paragraphe 4.7.4".

DESCRIPTION : "Indice unique dans mplsTunnelTable. Pour la signalisation de tunnels utilisant RSVP, cette valeur devrait correspondre à l'identifiant de tunnel RSVP utilisé pour la session RSVP-TE".

DESCRIPTION : "L'entrée de tunnel qui a l'indice d'instance 0 devrait se référer à l'interface de tunnel configurée (si il en existe une). Les valeurs supérieures à 0, mais inférieures ou égales à 65 535, devraient être utilisées pour indiquer les instances de LSP tunnel signalées (ou de sauvegarde). Pour les LSP tunnels signalés en utilisant RSVP, cette valeur devrait correspondre à l'identifiant de LSP RSVP utilisé pour le LSP RSVP-TE. Les valeurs supérieures à 65 535 s'appliquent aux instances de FRR detour".

DESCRIPTION : "Valeur qui représente un type d'adresse pour un bond de tunnel d'ingénierie de trafic (TE).

unknown(0) Type d'adresse inconnu. Cette valeur DOIT être utilisée si la valeur de l'objet TeHopAddress correspondant est une chaîne de longueur zéro. Il peut aussi être utilisé pour indiquer une TeHopAddress qui n'est pas dans un des formats définis ci-dessous.

ipv4(1) Adresse réseau IPv4 comme défini par la convention textuelle InetAddressIPv4 [RFC3291].

ipv6(2) Adresse mondiale IPv6 comme défini par la convention textuelle InetAddressIPv6 [RFC3291].

asnumber(3) Numéro de système autonome (AS) comme défini par la convention textuelle TeHopAddressAS.

unnum(4) Indice d'interface non numérotée comme défini par la convention textuelle TeHopAddressUnnum.

lspid(5) ID de LSP pour tunnels TE (RFC3212) comme défini par la convention textuelle MplsLSPID.

Chaque définition d'une valeur concrète de TeHopAddressType doit être accompagnée d'une définition d'une convention textuelle à utiliser avec cette TeHopAddress.

Pour permettre de futures extensions, la convention textuelle TeHopAddressType NE DEVRAIT PAS être divisée en sous types dans les définitions de type d'objet. Elle PEUT être divisée en sous types dans des déclarations de conformité pour exiger seulement un sous ensemble de ces types d'adresses d'une mise en œuvre conforme.

Les mises en œuvre doivent s'assurer que les objets TeHopAddressType et tous objets qui en dépendent (par exemple, des objets TeHopAddress) sont cohérents. Une erreur "valeur incohérente" doit être générée si une tentative de changement d'un objet TeHopAddressType conduisait, par exemple, à une valeur indéfinie de TeHopAddress qui ne serait pas définie ici. En particulier, les paires TeHopAddressType/TeHopAddress doivent être changées ensemble si le type d'adresse change (par exemple, de ipv6(2) à ipv4(1))".

RÉFÉRENCE : "Conventions textuelles pour adresses réseau Internet, [FC3291]. Établissement de LSP fondé sur la contrainte avec LDP, [RFC3212]".

SYNTAXE : ENTIER { unknown(0), ipv4(1), ipv6(2), asnumber(3), unnum(4), lspid(5) }

DESCRIPTION : "Dénote une adresse générique de bond tunnel, c'est-à-dire, l'adresse d'un nœud que traverse un LSP, incluant les nœuds de source et de destination. Une adresse peut être très concrète, par exemple, une adresse d'hôte IPv4 (c'est-à-dire, avec une longueur de préfixe de 32) ; si cette adresse IPv4 est une adresse d'interface, cette interface particulière doit alors être traversée. Une adresse peut aussi spécifier un "nœud abstrait", par exemple, une adresse IPv4 avec une longueur de préfixe de moins de 32, auquel cas le LSP peut traverser tout nœud dont l'adresse tombe dans cette gamme. Une adresse peut aussi spécifier un système autonome (AS), auquel cas le LSP peut traverser tout nœud qui entre dans cet AS.

Une valeur TeHopAddress est toujours interprétée dans le contexte d'une valeur de TeHopAddressType. Il est exigé de chaque usage de la convention textuelle TeHopAddress qu'il spécifie l'objet TeHopAddressType qui fournit le contexte. Il est suggéré que l'objet TeHopAddressType soit enregistré logiquement avant le ou les objets qui utilisent la convention textuelle TeHopAddress si ils apparaissent dans la même rangée logique.

La valeur d'un objet TeHopAddress doit toujours être cohérente avec la valeur de l'objet TeHopAddressType associé. Les tentatives de réglage d'un objet TeHopAddress à une valeur qui ne serait pas cohérente avec le TeHopAddressType associé doivent échouer avec une erreur "Valeur incohérente".

DESCRIPTION : "Représente un numéro d'AS de deux ou quatre octets. Le numéro d'AS est représenté dans l'ordre des octets du réseau (octet de poids fort en premier). Un numéro d'AS de deux octets a les deux octets de poids fort à zéro".

RÉFÉRENCE : "Conventions textuelles pour adresses réseau Internet, [RFC3291]. La convention textuelle InetAutonomousSystemsNumber a une syntaxe de Unsigned32, tandis que celle-ci a une syntaxe de CHAINE D'OCTETS (TAILLE (4)). Toutes deux représentent un numéro de système autonome mais utilisent des syntaxes différentes pour le faire".

octets : 1-4 ; contenu : interface non numérotée ; codage : ordre des octets du réseau

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)

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

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

[RFC3291] M. Daniele et autres, "Conventions textuelles pour adresses réseau Internet", mai 2002. (Obsolète, voir RFC4001) (P.S.)

[RFC3410] J. Case et autres, "Introduction et déclarations d'applicabilité pour le cadre de gestion standard de l'Internet", décembre 2002. (Information)

Le présent module ne définit aucun objet de gestion. Il définit plutôt un ensemble de conventions textuelles qui peuvent être utilisées par d'autres modules de MIB MPLS pour définir des objets de gestion.

Des considérations significatives sur la sécurité ne peuvent être écrites que pour des modules de MIB qui définissent des objets de gestion. Donc, le présent document n'a pas d'impact sur la sécurité de l'Internet.

L'IANA a fait une allocation d'OID de MIB sous la branche transmission, c'est-à-dire, a alloué la mplsStdMIB sous { transmission 166 }. Ce sous identifiant est nécessaire parce que 166 est le ifType pour mpls(166) et il est disponible sous transmission.

À l'avenir, les modules de MIB en cours de normalisation qui se rapportent à MPLS devraient s'enraciner dans la sous arborescence mplsStdMIB. Il est demandé à l'IANA de gérer cet espace de noms. De nouvelles allocations ne peuvent être faites que par action de normalisation comme spécifié dans la [RFC2434].

L'IANA a aussi alloué { mplsStdMIB 1 } à la MPLS-TC-STD-MIB spécifiée dans ce document.

Le présent document a été créé en combinant les conventions textuelles provenant des MIB MPLS actuelle et une MIB du groupe de travail TE. Les coauteurs de chacune de ces MIB ont contribué aux conventions textuelles contenues dans la présente MIB et ont aussi largement contribué aux révisions du présent document. Les adresses de ces coauteurs sont incluses ici parce que ce sont de futurs contacts utiles pour des informations sur le présent document. Ces coauteurs sont :

Le présent document a été produit par le groupe de travail MPLS. Les éditeurs et les contributeurs remercient Mike MacFadden et Adrian Farrel de leurs utiles commentaires sur plusieurs relectures. Les éditeurs et contributeurs tiennent aussi à formuler des remerciements tout particuliers à Bert Wijnen pour ses nombreuses relectures détaillées. L'aide et les conseils de Bert sont très appréciés.

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis 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.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .

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

Groupe de travail Réseau	T. Nadeau, éd., Cisco Systems, Inc.
Request for Comments : 3811	J. Cucchiara, éd., Marconi Communications, Inc.
Catégorie : En cours de normalisation	juin 2004
Traduction Claude Brière de L'Isle

Cheenu Srinivasan	Arun Viswanathan	Hans Sjostrand	Kireeti Kompella
Bloomberg L.P.	Force10 Networks, Inc.	ipUnplugged	Juniper Networks
499 Park Ave.	1440 McCarthy Blvd	P.O. Box 101 60	1194 Mathilda Ave
New York, NY 10022	Milpitas, CA 95035	S-121 28 Stockholm, Sweden	Sunnyvale, CA 94089
tél : +1-212-893-3682	tél : +1-408-571-3516	tél : +46-8-725-5900	tél : +1-408-745-2000
cheenu@bloomberg.net	mél : arunv@force10networks.com	mél : hans@ipunplugged.com	kireeti@juniper.net

Thomas D. Nadeau	Joan E. Cucchiara
Cisco Systems, Inc.	Marconi Communications, Inc.
BXB300/2/	900 Chelmsford Street
300 Beaver Brook Road	Lowell, MA 01851
Boxborough, MA 01719	téléphone : +1-978-275-7400
téléphone : +1-978-936-1470	mél : jcucchiara@mindspring.com
mél : tnadeau@cisco.com