Groupe de travail Réseau

K. Kompella & Y. Rekhter, Juniper Networks

Request for Comments : 4201

L. Berger, Movaz Networks

RFC mises à jour : 3471, 3472, 3473

octobre 2005

Catégorie : Sur la voie de la normalisation

Traduction Claude Brière de L'Isle



Faisceaux de liaison dans l'ingénierie de trafic MPLS



Statut de ce mémoire

Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la 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 (2005).


Résumé

Pour les besoins de la signalisation de la commutation d'étiquettes multi protocole généralisée (GMPLS, Generalized Multi-Protocol Label Switching) dans certains cas, une combinaison de <identifiant de liaison, étiquette> n'est pas suffisante pour identifier sans ambiguïté la ressource appropriée utilisée par un chemin de commutation d'étiquettes (LSP, Label Switched Path). De tels cas sont traités en utilisant la construction d'un faisceau de liaisons, qui est décrite dans le présent document. Ce document met à jour les TLV d'identification d'interface qui sont définies dans la description fonctionnelle de la signalisation GMPLS.


Table des Matières

1. Introduction

1.1 Spécification des exigences

2. Faisceau de liaisons

2.1 Restrictions sur la mise en faisceaux

2.2 Considérations d'acheminement

2.3 Considérations de signalisation

3. Paramètres d'ingénierie du trafic pour liaisons en faisceaux

3.1 Type de liaison OSPF

3.2 Identifiant de liaison OSPF

3.3 Adresse IP d'interface locale et distante

3.4 Identifiants locaux et distants

3.5 Métrique d'ingénierie de trafic

3.6 Bande passante maximum

3.7 Bande passante maximum réservable

3.8 Bande passante non réservée

3.9. Classes de ressource (groupes administratifs)

3.10 Bande passante maximum de LSP

4. Comptabilité de bande passante

6. Considérations sur la sécurité

6. Considérations relatives à l'IANA

7. Références

7.1 Références normatives

7.2 Référence pour information

Adresse des auteurs

Déclaration complète de droits de reproduction


1. Introduction


Pour les besoins de la signalisation de la commutation d'étiquettes multi protocole généralisée (GMPLS, Generalized Multi-Protocol Label Switching) dans certains cas, une combinaison de <identifiant de liaison, étiquette> n'est pas suffisante pour identifier sans ambiguïté la ressource appropriée utilisée par un chemin de commutation d'étiquettes (LSP, Label Switched Path). De tels cas sont traités en utilisant la construction d'un faisceau de liaisons, qui est décrite dans le présent document. Ce document met à jour les TLV d'identification d'interface qui sont définies dans la description fonctionnelle de la signalisation GMPLS.


1.1 Spécification des exigences

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


2. Faisceau de liaisons


Comme défini dans la [RFC4202], une liaison d'ingénierie du trafic (TE, traffic engineering) est une construction logique qui représente un moyen de grouper/transposer des informations sur certaines ressources physiques (et leurs propriétés) qui interconnectent les routeurs à commutation par étiquettes (LSR, label switched router) avec des informations qui sont utilisées par des fonctions de traitement de la signalisation (SPF, Signalling Processing Function) contraintes (pour les besoins du calcul de chemin) et par la signalisation GMPLS.


Comme déclaré dans la [RFC4202], selon la nature des ressources qui forment une liaison TE particulière pour les besoins de la signalisation GMPLS, dans certains cas une combinaison de <identifiant de liaison TE, étiquette> est suffisante pour identifier sans ambiguïté les ressource appropriée utilisée par un LSP. Dans d'autres cas, une combinaison de <identifiant de liaison TE, étiquette> n'est pas suffisante. Considérons, par exemple, une liaison TE entre une paire d'interconnexions SONET/SDH, où cette liaison TE est composée de plusieurs fibres. Dans ce cas l'étiquette est un intervalle de temps de multiplexage par répartition dans le temps (MRT) et de plus, cet intervalle de temps n'est significatif que dans une fibre particulière. Donc, lorsque on fait la signalisation d'un LSP sur une telle liaison TE, on doit spécifier non seulement l'identité de la liaison, mais aussi l'identité d'une fibre particulière au sein de cette liaison TE, ainsi qu'une étiquette particulière (intervalle de temps) au sein de cette fibre. De tels cas sont traités en utilisant la construction de faisceau de liaison, qui est décrite dans le présent document.


Considérons une liaison TE telle que, pour les besoins de la signalisation GMPLS, une combinaison de <identifiant de liaison TE, étiquette> ne soit pas suffisante pour identifier sans ambiguïté la ressource appropriée utilisée par un LSP. Dans cette situation, la construction de faisceau de liaison suppose que l'ensemble de ressources qui forment la liaison TE pourrait être partagé en sous ensembles disjoints, tels que (a) la partition soit minimale, et (b) au sein de chaque sous ensemble, une étiquette soit suffisante pour identifier sans ambiguïté la ressource appropriée utilisée par un LSP. On se réfère à de tels sous ensembles comme à des "liaisons composantes", et à la liaison TE entière comme une "liaison en faisceau". De plus, on restreint les identifiants qui peuvent être utilisés pour identifier les liaisons composantes de façon à ce qu'ils soient uniques pour un certain nœud. Sur une liaison en faisceau, une combinaison de <identifiant de liaison composante, étiquette> est suffisante pour identifier sans ambiguïté la ressource appropriée utilisée par un LSP.


La partition de ressources qui forme une liaison en faisceau en liaisons composantes doit être faite de façon cohérente aux deux extrémités de la liaison en faisceau. Les deux extrémités de la liaison en faisceau doivent aussi comprendre les identifiants de liaison composante de l'autre extrémité.


L'objet de la mise en faisceau de liaisons est d'améliorer l'adaptabilité de l'acheminement en réduisant la quantité d'informations qui doit être traitée par OSPF et/ou IS-IS. Cette réduction est accomplie en effectuant l'agrégation/abstraction des informations. Comme avec toute autre agrégation/abstraction d'informations, cela résulte en la perte d'une partie des informations. Pour limiter la quantité de pertes, on doit restreindre le type des informations qui peuvent être agrégées/abstraites.


2.1 Restrictions sur la mise en faisceaux

Toutes les liaisons composantes dans un faisceau ont le même type de liaison (c'est-à-dire, point à point ou multi accès) la même métrique d'ingénierie du trafic, le même ensemble de classes de ressource à chaque extrémité des liaisons, et doivent commencer et se terminer sur la même paire de LSR.


Une adjacence de transmission peut être une liaison composante ; en fait, un faisceau peut consister en un mélange de liaisons point à point et d'adjacences de transmission (FA, Forwarding Adjacency).


Si les liaisons composantes sont toutes des liaisons multi accès, l'ensemble de routeurs IS-IS ou OSPF qui sont connectés à chaque liaison composante doit être le même, et le routeur désigné pour chaque liaison composante doit être le même. Si ces conditions ne peuvent être réunies, les liaisons multi accès ne doivent pas être mises en faisceau.


Les identifiants de liaisons composantes DOIVENT être uniques à la fois dans TE et parmi les identifiants de liaisons composantes sur un nœud particulier. Cela signifie que les identifiants non numérotés ont une portée de nœud, et que les identifiants numérotés ont la même portée que les adresses IP.


2.2 Considérations d'acheminement

Une liaison composante peut être numérotée ou non numérotée. Une liaison en faisceau peut elle-même être numérotée ou non numérotée, indépendamment de si les liaisons composantes de cette liaison en faisceau sont numérotées.


Le traitement des identifiants pour les liaisons composantes non numérotées, incluant le cas dans lequel une liaison est formée par une adjacence de transmission, suit les mêmes règles que celles pour une liaison TE non numérotée (voir la Section 2 "Identifiants de liaison " de la [RFC3477]/[RFC3480]). De plus, les identifiants de liaison locale pour toutes les liaisons non numérotées d'un certain LSR (que ce soit de liaisons composantes, d'adjacences de transmission, ou de liaisons en faisceau) DOIVENT être uniques dans le contexte de ce LSR.


La "vivacité" de la liaison en faisceau est déterminée par la vivacité de chacune des liaisons composantes au sein de la liaison en faisceau ; une liaison en faisceau est vivante lorsque au moins une de ses liaisons composantes est déterminée comme étant vivante. La vivacité d'une liaison composante peut être déterminée par divers moyens : des hellos IS-IS ou OSPF sur la liaison composante, un Hello RSVP, des hellos LMP (voir la [RFC4204]), ou par des indications de couche 1 ou de couche 2.


Une fois qu'une liaison en faisceau est déterminée comme vivante, elle peut être annoncée comme liaison TE et les informations TE peuvent être diffusées. Si des hellos IS-IS/OSPF sont envoyés sur les liaisons composantes, l'arrosage IS-IS/OSPF peut être restreint à juste une des liaisons composantes. Les procédures pour faire cela sortent du domaine d'application du présent document.


À l'avenir, si de nouveaux paramètres d'ingénierie du trafic sont ajoutés à IS-IS et OSPF, ils devraient être accompagnés de descriptions de la façon dont ils peuvent être mis en faisceau, et de possibles restrictions à la mise en faisceau.


2.3 Considérations de signalisation

Parce que les informations sur la liaison en faisceau sont arrosées, mais que les informations sur les liaisons composantes ne le sont pas, normalement, l'objet EXPLICIT_ROUTE (ERO, EXPLICIT_ROUTE object) d'un LSP va identifier la liaison en faisceau comme étant utilisée pour le LSP, mais pas la liaison composante. Bien que la découverte des identités de liaison composante à utiliser dans un ERO sorte du domaine d'application du présent document, il est envisagé que de telles informations puissent être fournies via configuration ou via de futures extensions de ERO. Lorsque la liaison en faisceau est identifiée dans un ERO ou est identifiée de façon dynamique, le choix de la liaison composante pour le LSP est une affaire locale entre les deux LSR à chaque extrémité de la liaison en faisceau.


La signalisation doit identifier la liaison composante et l'étiquette à utiliser. Le choix de la liaison composante à utiliser est toujours fait par l'envoyeur du message Path/REQUEST. Si un LSP est bidirectionnel [RFC3471], l'envoyeur choisit une liaison composante dans chaque direction. Le traitement des étiquettes n'est pas modifié par le présent document.


Les identifiants de liaison composante sont portés dans des messages RSVP, comme décrit à la Section 8 de la [RFC3473]. Les identifiants de liaison composante sont portés dans des messages CR-LDP, comme décrit à la Section 8 de la [RFC3473]. Le traitement supplémentaire relatif aux liaisons non numérotées est décrit dans les paragraphes "Traitement de l'objet IF_ID RSVP_HOP"/"Traitement du TLV IF_ID", et "Adjacences de transmission non numérotées" des [RFC3477]/[RFC3480].


La [RFC3471] définit les types de TLV (TLV, type-length-value) Interface Identification. Le présent document spécifie que les TLV de types 1, 2, et 3 DEVRAIENT être utilisées pour indiquer les liaisons composantes dans les objets IF_ID RSVP_HOP et les TLV IF_ID.


Les TLV de type 1 sont utilisées pour les identifiants de liaison composante IPv4 numérotée.


Les TLV de type 2 sont utilisées pour les identifiants de liaison composante IPv6 numérotée.


Les TLV de type 3 sont utilisées pour les identifiants de liaison composante non numérotée.


Les TLV Interface Composant, des types 4 et 5, NE DEVRAIENT PAS être utilisées. Noter que dans les messages Path et REQUEST, les identifiants de liaison DOIVENT être spécifiés du point de vue de l'envoyeur.


Sauf dans le cas particulier noté ci-dessous, pour un LSP unidirectionnel, une seule TLV DEVRAIT être utilisée dans un objet IF_ID RSVP_HOP ou TLV IF_ID. Cette TLV indique l'identifiant de liaison composante du canal de données aval sur lequel l'allocation d'étiquette doit être faite.


Sauf dans le cas particulier noté ci-dessous, pour un LSP bidirectionnel, seuls une ou deux TLV DEVRAIENT être utilisées dans un objet IF_ID RSVP_HOP ou TLV IF_ID. La première TLV indique toujours l'identifiant de liaison composante du canal de données aval sur lequel l'allocation d'étiquette doit être faite. Lorsque présente, la seconde TLV indique toujours l'identifiant de liaison composante du canal de données amont sur lequel l'allocation d'étiquette doit être faite. Lorsque une seule TLV est présente, elle indique l'identifiant de liaison composante pour les deux canaux de données, aval et amont.


Dans le cas particulier où la même étiquette est valide sur toutes les liaisons composantes, deux TLV DEVRAIENT être utilisées dans un objet IF_ID RSVP_HOP ou TLV IF_ID. La première TLV indique l'identifiant de la liaison TE du faisceau sur lequel l'allocation d'étiquette doit être faite. La seconde TLV indique une étiquette de portée faisceau. Pour les types 1 et 2 de TLV, cela est fait en utilisant la valeur binaire spéciale toute de uns (1) (par exemple, 0xFFFFFFFF pour une TLV de type 1). Selon la [RFC3471], pour les TLV des types 3, 4, et 5, cela est fait en réglant le champ Identifiant d'interface à la valeur spéciale de 0xFFFFFFFF. Noter que ce cas particulier s'applique aux LSP aussi bien unidirectionnels que bidirectionnels.


Bien qu'elle NE DEVRAIT PAS être utilisée, lorsque elle l'est, la TLV de type 5 NE DOIT PAS être la première TLV dans un objet IF_ID RSVP_HOP ou TLV IF_ID.


2.3.1. Format de TLV d'identification d'interface

Ce paragraphe modifie le paragraphe 9.1.1 de la [RFC3471]. La définition du champ Adresse IP des TLV des types 3, 4, et 5 est précisée.


Pour les types 3, 4, et 5, le champ Valeur a un format identique au contenu de l'objet C-Type 1 LSP_TUNNEL_INTERFACE_ID défini dans la [RFC3477]. Noter qu'il en résulte un changement du nom du champ Adresse IP défini dans la [RFC3471].


2.3.2 Identification de composant erroné

Lorsque des TLV Identification d'interface sont utilisées, les TLV sont aussi utilisées pour indiquer les composants spécifiques associés à une erreur. Pour RSVP, cela signifie que toute TLV reçue DEVRAIT être copiée dans l'objet IF_ID ERROR_SPEC (voir au paragraphe 8.2 de la [RFC3473]). Le champ Adresse du nœud erroné de l'objet DEVRAIT indiquer la liaison TE associée à l'erreur. Pour CR-LDP, cela signifie que toute TLV reçue DEVRAIT être copiée dans la TLV IF_ID (voir au paragraphe 8.2 de la [RFC3472]). Le champ Adresse de bond de la TLV DEVRAIT indiquer la liaison TE associée à l'erreur.


3. Paramètres d'ingénierie du trafic pour liaisons en faisceaux


Dans cette section, on définit les paramètres d'ingénierie du trafic à annoncer pour une liaison en faisceau, sur la base de la configuration des liaisons composantes et de la liaison en faisceau. La définition de ces paramètres pour les liaisons composantes a été entreprise dans la [RFC3784] et la [RFC3630] ; on utilise la terminologie de la [RFC3630].


3.1 Type de liaison OSPF

Le type de liaison d'une liaison en faisceau est le type de liaison (unique) des liaisons composantes. Noter que ce paramètre n'est pas présent dans IS-IS.


3.2 Identifiant de liaison OSPF

Pour les liaisons point à point, l'identifiant de liaison d'une liaison en faisceau est l'identifiant de routeur (unique) du voisin. Pour les liaisons multi accès, c'est l'adresse d'interface du routeur désigné (unique). Noter que ce paramètre n'est pas présent dans IS-IS.


3.3 Adresse IP d'interface locale et distante

Noter que dans IS-IS, l'adresse IP d'interface locale est connue comme Adresse d'interface IPv4 et que l'adresse IP d'interface distante est appelée Adresse de voisin IPv4.


Si la liaison en faisceau est numérotée, l'adresse IP d'interface locale est l'adresse locale de la liaison en faisceau ; de façon similaire, l'adresse IP d'interface distante est l'adresse distante de la liaison en faisceau.


3.4 Identifiants locaux et distants

Si la liaison en faisceau est non numérotée, l'identifiant local de liaison est réglé à l'identifiant choisi pour le faisceau par le LSR annonceur. L'identifiant distant de la liaison est réglé à l'identifiant choisi par le LSR voisin pour la liaison inverse correspondant à ce faisceau, si il est connu ; autrement, il est réglé à 0.


3.5 Métrique d'ingénierie de trafic

La métrique d'ingénierie de trafic pour une liaison en faisceau est celle des liaisons composantes.


3.6 Bande passante maximum

Ce paramètre n'est pas utilisé. La bande passante maximum du LSP (comme décrite ci-dessous) remplace la bande passante maximum pour les liaisons en faisceau.


3.7 Bande passante maximum réservable

Pour une certaine liaison en faisceau, on suppose que soit chacune de ses liaisons composantes est configurée avec la bande passante maximum réservable, soit que la liaison en faisceau est configurée avec la bande passante maximum réservable. Dans le premier cas, la bande passante maximum réservable de la liaison en faisceau est réglée à la somme des bandes passantes maximum réservables de toutes les liaisons composantes associées à la liaison en faisceau.


3.8 Bande passante non réservée

La bande passante non réservée d'une liaison en faisceau à la priorité p est la somme des bandes passantes non réservées à la priorité p de toutes les liaisons composantes associées à la liaison en faisceau.


3.9. Classes de ressource (groupes administratifs)

Les classes de ressource pour une liaison en faisceau sont les mêmes que celles des liaisons composantes.


3.10 Bande passante maximum de LSP

La bande passante maximum de LSP prend la place de la bande passante maximum. Pour une liaison qui n'est pas en faisceau, la bande passante maximum est définie dans la [RFC4202]. La bande passante maximum de LSP d'une liaison en faisceau à la priorité p est définie comme étant le maximum de la bande passante maximum de LSP à la priorité p de toutes ses liaisons composantes.


Les détails de la façon dont la bande passante maximum de LSP est portée dans IS-IS sont donnés dans la [RFC4205]. Les détails de la façon dont la bande passante maximum de LSP est portée dans OSPF sont donnés dans la [RFC4203].


4. Comptabilité de bande passante


Le module de contrôle de trafic RSVP (ou CR-LDP) ou son équivalent, sur un LSR avec des liaisons en faisceau doit appliquer le contrôle d'admission sur la base de la liaison composante. Un LSP avec une exigence de bande passante b et la priorité d'établissement p tient dans une liaison en faisceau si au moins une liaison composante a une bande passante maximum de LSP ≥ b à la priorité p. Si il y a plusieurs de ces liaisons, la mise en œuvre va choisir quelle liaison utiliser pour le LSP.


Afin de connaître la bande passante maximum de LSP (par priorité) de chaque liaison composante, le module de contrôle de trafic doit retracer la bande passante non réservée (par priorité) pour chaque liaison composante.


Un changement de la bande passante non réservée d'une liaison composante résulte en un changement de la bande passante non réservée de la liaison en faisceau. Il résulte aussi potentiellement en un changement de la bande passante maximum de LSP du faisceau ; donc, la bande passante maximum de LSP devrait être recalculée.


Si une des liaisons composantes a une défaillance, la liaison en faisceau associée reste active et continue d'être annoncée, pourvu qu'au moins une liaison composante associée à la liaison en faisceau soit active. La bande passante non réservée de la liaison composante qui est défaillante est réglée à zéro, et la bande passante non réservée et la bande passante maximum de LSP du faisceau doivent être recalculées. Si toutes les liaisons composantes associées à une certaine liaison en faisceau sont défaillantes, la liaison en faisceau NE DOIT PAS être annoncée dans OSPF/IS-IS.


6. Considérations sur la sécurité


Le présent document définit les moyens d'utiliser les procédures définies dans d'autres documents, référencés ici. Toutes les questions de sécurité relatives à ces procédures sont traitées dans les documents référencés. Donc, le présent document ne soulève aucune nouvelle question de sécurité pour RSVP-TE [RFC3209] ou CR-LDP [RFC3212].


6. Considérations relatives à l'IANA


Le présent document change l'usage recommandé de deux des types Interface_ID définis au paragraphe 9.11 de la [RFC3471]. Pour cette raison, le registre IANA des paramètres de signalisation GMPLS a été mis à jour de la façon suivante :

Type

Valeur

Signification

4

12

COMPONENT_IF_DOWNSTREAM - Déconseillé

5

12

COMPONENT_IF_UPSTREAM - Déconseillé


7. Références

7.1 Références normatives


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


[RFC3209] D. Awduche, et autres, "RSVP-TE : Extensions à RSVP pour les tunnels LSP", décembre 2001. (Mise à jour par RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC6790)


[RFC3212] B. Jamoussi et autres, "Établissement de LSP fondé sur la contrainte avec LDP", janvier 2002. (MàJ par RFC3468) (P.S.)


[RFC3471] L. Berger, éd., "Commutation d'étiquettes multi-protocoles généralisée (GMPLS) : description fonctionnelle de la signalisation", janvier 2003. (MàJ par RFC4201, RFC4328, RFC4872, RFC8359) (P.S.)


[RFC3472] P. Ashwood-Smith et L. Berger, éd., "Commutation d'étiquettes multi-protocoles généralisée (GMPLS) : extensions au protocole de distribution d'étiquettes acheminées sur la base des contraintes de signalisation (CR-LDP)", janvier 2003. (MàJ par RFC3468, RFC4201) (P.S.)


[RFC3473] L. Berger, "Extensions d'ingénierie de protocole - trafic de signalisation de réservation de ressource (RSVP-TE) de commutation d'étiquettes multi-protocoles généralisée (GMPLS)", janvier 2003. (P.S., MàJ par 4003, 4201, 4420, 4783, 4784, 4873, 4974, 5063, 5151, 8359)


[RFC3477] K. Kompella, Y. Rekhter, "Signalisation des liaisons non numérotées dans le protocole de réservation de ressource – ingénierie du trafic (RSVP-TE)", janvier 2003. (P.S.)


[RFC3480] K. Kompella, Y. Rekhter, A. Kullberg, "Signalisation des liaisons non numérotées dans le protocole de distribution d'étiquettes acheminées sur la base des contraintes de signalisation (CR-LDP)", février 2003. (P.S.)


[RFC3630] D. Katz, K. Kompella et D. Yeung, "Extensions d'ingénierie de trafic à OSPF version 2", septembre 2003.


[RFC3784] H. Smit, T. Li, "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour l'ingénierie du trafic (TE)", juin 2004. (Obsolète, voir RFC5305) (MàJ par RFC4205) (Information)


[RFC4202] K. Kompella et autres, "Extensions d'acheminement pour la prise en charge de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", octobre 2005. (P.S.)


[RFC4203] K. Kompella et autres, "Extensions OSPF pour la prise en charge de la commutation généralisée d'étiquettes multi-protocoles (GMPLS)", octobre 2005. (MàJ RFC3630) (P.S.)


[RFC4205] K. Kompella et Y. Rekhter, éd., "Extensions de système intermédiaire à système intermédiaire (IS-IS) pour la prise en charge de la commutation généralisée d'étiquettes multiprotocoles (GMPLS)", octobre 2005. (Obsolète, voir RFC5307) (MàJ RFC3784) (Information)


7.2 Référence pour information


[RFC4204] J. Lang, éd., "Protocole de gestion de liaison (LMP)", octobre 2005. (P.S.)


Adresse des auteurs


Kireeti Kompella

Yakov Rekhter

Lou Berger

Juniper Networks, Inc.

Juniper Networks, Inc.

Movaz Networks, Inc.

1194 N. Mathilda Ave.

1194 N. Mathilda Ave.

téléphone : +1 703-847-1801

Sunnyvale, CA 94089

Sunnyvale, CA 94089

mél : lberger@movaz.com

mél : kireeti@juniper.net

mél : yakov@juniper.net



Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2005).


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


Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait ê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 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 .


Remerciement

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