Groupe de travail Réseau

A. Fredette, éditeur, Hatteras Networks

Request for Comments : 4209

J. Lang, éditeur, Sonos Inc.

Catégorie : Sur la voie de la normalisation

octobre 2005

Traduction Claude Brière de L'Isle




Protocole de gestion de liaisons (LMP) pour systèmes de ligne optique à multiplexage par répartition en longueur d’onde à haute densité (DWDM)



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é

Le protocole de gestion de liaisons (LMP, Link Management Protocol) est défini pour gérer les liaisons d'ingénierie du trafic (TE, traffic engineering). Sous sa forme actuelle, LMP se concentre sur les nœuds homologues, c'est-à-dire, les nœuds qui échangent du trafic de signalisation et/ou d'acheminement. Le présent document propose des extensions à LMP pour lui permettre d'être utilisé entre un nœud homologue et un système de ligne optique (OLS, optical line system) adjacent. Ces extensions sont destinées à satisfaire aux "Exigences pour les interfaces de liaisons optiques" décrites dans un document d'accompagnement.


Table des Matières

1. Introduction

1.1 Terminologie

1.2 Portée du protocole LMP-WDM

2. Extensions à LMP pour les systèmes à ligne optique

2.1 Gestion du canal de contrôle

2.2 Vérification de liaison

2.3 Résumé de liaison

2.4 Gestion des fautes

3. Considérations sur la sécurité

4. Considérations relatives à l'IANA

5. Contributeurs

6. Références

6.1 Références normatives

6.2 Référence pour information

Adresse des éditeurs

Déclaration complète de droits de reproduction


1. Introduction


Des réseaux sont développés avec des routeurs, des commutateurs, des brasseurs optiques (OXC, optical cross-connect), des systèmes de lignes optiques (OLS, optical line system) à multiplexage par répartition en longueur d’onde à haute densité (DWDM, dense wavelength division multiplexing) et des multiplexeurs d'insertion/extraction (ADM, add-drop multiplexor) qui utilisent un plan de contrôle commun (par exemple, la commutation multi protocole avec étiquetage des flux généralisée (GMPLS, Generalized MPLS)) pour provisionner de façon dynamique des ressources et assurer la survie du réseau en utilisant des techniques de protection et de restauration.


Le protocole de gestion de liaisons (LMP) est développé au titre de la suite de protocoles GMPLS pour gérer les liaisons à ingénierie du trafic (TE, traffic engineering) [RFC4204]. Sous sa forme actuelle, LMP se concentre sur les nœuds homologues, c'est-à-dire, les nœuds qui échangent du trafic de signalisation et/ou d'acheminement (par exemple, d'OXC à OXC, comme l'illustre la Figure 1). Dans le présent document, les extensions à LMP sont proposées pour lui permettre d'être utilisé entre un nœud homologue et un système de ligne optique (OLS, optical line system) adjacent. Ces extensions sont destinées à satisfaire les "exigences pour les interfaces de liaisons optiques" décrites dans [OLI]. On suppose le lecteur familiarisé avec LMP, défini dans la [RFC4204].


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

| | ----- | | | | ----- | |

| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |

| | ----- | | | | ----- | |

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

^ ^

| |

+---------------------LMP---------------------+


Figure 1 : Modèle LMP


Considérons deux nœuds homologues (par exemple, deux OXC) interconnectés par une liaison multiplexée en longueur d'onde, c'est-à-dire, une liaison optique DWDM (voir la Figure 1). Les informations sur la configuration de cette liaison et son état actuel sont connues par les deux OLS (OLS1 et OLS2). Leur permettre de communiquer ces informations aux nœuds homologues correspondants (OXC1 et OXC2) via LMP peut améliorer la capacité d'utilisation du réseau en réduisant la configuration manuelle requise et en améliorant la détection et la récupération des fautes.


Les informations sur l'état des LSP qui utilisent la liaison optique DWDM sont connues par les nœuds homologues (OXC1 et OXC2) et leur permettre de communiquer ces informations aux OLS correspondants (OLS1 et OLS2) est utile pour la gestion des alarmes et la surveillance des liaisons. La gestion des alarmes est importante parce que l'état administratif d'un LSP, connu des nœuds homologues (par exemple, via l'objet "Admin Status" de la signalisation GMPLS [RFC3471]), peut être utilisé pour supprimer les alarmes parasites qui font rapport de ces OLS.


Le modèle pour l'extension de LMP aux OLS est montré à la Figure 2.


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

| | ----- | | | | ----- | |

| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |

| | ----- | | | | ----- | |

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

^ ^ ^ ^ ^ ^

| | | | | |

| +-----LMP-----+ +-----LMP-----+ |

| |

+----------------------LMP-----------------------+


Figure 2 : Modèle LMP étendu


Dans ce modèle, un nœud homologue peut avoir des sessions LMP avec les OLS adjacents, ainsi qu'avec les nœuds homologues adjacents. Dans la Figure 2, par exemple, la session LMP OXC1-OXC2 peut être utilisée pour construire des liaisons d'ingénierie du trafic (TE) pour la signalisation et l'acheminement GMPLS, comme décrit dans la [RFC4204]. Les sessions LMP OXC1-OLS1 et OXC2-OLS2 sont utilisées pour échanger des informations sur la configuration de la liaison optique DWDM et son état actuel et des informations sur l'état des LSP qui utilisent cette liaison.


Ce dernier type de sessions LMP est discuté dans le présent document. Il est important de noter qu'un nœud homologue peut avoir des sessions LMP avec un ou plusieurs OLS et qu'un OLS peut avoir des sessions LMP avec un ou plusieurs nœuds homologues.


Bien qu'il y ait de nombreuses similarités entre une session LMP entre deux nœuds homologues et une session LMP entre un nœud homologue et un OLS, il y a aussi quelques différences. Le premier type de session LMP est utilisé pour servir de base à la signalisation et l'acheminement GMPLS. Le dernier type de session LMP est utilisé pour augmenter les connaissances sur les liaisons entre les nœuds homologues.


Un nœud homologue maintient de façon indépendante ses sessions LMP de nœud homologue à OLS et ses sessions LMP de nœud homologue à nœud homologue. Cela signifie qu'il DOIT être possible aux sessions LMP de s'activer dans n'importe quel ordre. En particulier, il DOIT être possible à une session LMP de nœud homologue à nœud homologue de s'activer en l'absence de toute session LMP de nœud homologue à OLS, et vice versa.


1.1 Terminologie

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


Le lecteur est supposé s'être familiarisé avec la terminologie de la [RFC4204].


DWDM (Dense Wavelength Division Multiplexing) : multiplexage par répartition en longueur d’onde à haute densité ;


OLS (Optical line system) : système de ligne optique


Opaque : un appareil est appelé X-opaque si il examine ou modifie l'aspect X du signal en transmettant un signal entrant de l'entrée à la sortie.


OXC (Optical Cross-Connect) : brasseur optique


Transparent : comme défini dans la [RFC4204], un appareil est appelé X-transparent si il transmet les signaux entrant d'entrée en sortie sans examiner ou modifier l'aspect X du signal. Par exemple, un commutateur de relais de trame est transparent à la couche réseau ; un commutateur tout optique est électriquement transparent.


1.2 Portée du protocole LMP-WDM

Le présent document se concentre sur les extensions requises pour l'utilisation des OLS opaques. En particulier, il est destiné à l'utilisation avec des OLS qui ont des accès d'utilisateur SONET, SDH, et Ethernet. Au moment de sa rédaction, des travaux sont en cours dans le domaine de l'acheminement en longueur d'onde pleinement transparent ; cependant, il serait prématuré d'identifier les informations qu'il est nécessaire d'échanger entre un nœud homologue et un OLS dans ce contexte. Néanmoins, le protocole décrit dans le présent document donne le cadre nécessaire dans lequel échanger les informations supplémentaires qui sont estimées appropriées.


2. Extensions à LMP pour les systèmes à ligne optique


LMP consiste actuellement en quatre procédures principales, dont les deux premières sont obligatoires et les deux dernières sont facultatives :

1. Gestion du canal de contrôle

2. Corrélation des propriétés de liaison

3. Vérification de liaison

4. Gestion des fautes


Ces quatre fonctions sont prises en charge dans LMP-WDM.


2.1 Gestion du canal de contrôle

Comme dans la [RFC4204], on ne spécifie pas la mise en œuvre exacte du canal de contrôle ; il pourrait être, par exemple, une longueur d'onde séparée, une fibre, une liaison Ethernet, un tunnel IP acheminé sur un réseau de gestion séparé, un réseau IP multi bonds, ou les octets d'enveloppe d'une liaison de données. La gestion d'un canal de contrôle pour une liaison de nœud homologue à OLS est la même que pour une liaison de nœud homologue à nœud homologue, comme décrit dans la [RFC4204]. Pour distinguer entre une session LMP de nœud homologue à OLS et une session LMP de nœud homologue à nœud homologue, un nouvel objet LMP-WDM CONFIG est défini (C-Type = 2). Le format de l'objet CONFIG est le suivant :


Classe = 6

C-Type = 2, LMP-WDM_CONFIG


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

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

|W|O| (Réservé) |

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


Le champ Réservé devrait être envoyé à zéro et ignoré à réception.


W : 1 bit. Ce bit indique la prise en charge des extensions LMP-WDM définies dans ce document.


O : 1 bit. S'il est établi à 1, il indique que l'envoyeur est un système de ligne optique (OLS). S'il est à zéro, il indique que l'envoyeur est un nœud homologue.


Les extensions LMP-WDM sont conçues pour les sessions LMP de nœud homologue à OLS. Le bit OLS permet à un nœud de s'identifier comme un OLS ou un nœud homologue. C'est utilisé pour détecter une mauvaise configuration d'une session LMP de nœud homologue à OLS entre deux nœuds homologues ou d'une session LMP de nœud homologue à nœud homologue entre un nœud homologue et un OLS.


Si le nœud ne prend pas en charge les extensions LMP-WDM, il DOIT répondre au message Config par un message ConfigNack.


Si un nœud homologue qui est configuré pour fonctionner avec LMP-WDM reçoit un message Config avec le bit OLS à zéro dans l'objet LMP-WDM_CONFIG, il DOIT répondre au message Config avec le message ConfigNack.


2.2 Vérification de liaison

La procédure d'essai utilisée avec les OLS est la même que celle décrite dans la [RFC4204]. Le VerifyTransportMechanism (inclus dans les messages BeginVerify et BeginVerifyAck) est utilisé pour permettre aux nœuds de négocier une méthode de vérification de liaison et est essentiel pour les systèmes de lignes qui ont accès aux octets d'enveloppe plutôt qu'à la charge utile. Le VerifyId (fourni par le nœud distant dans le message BeginVerifyAck et utilisé dans tous les messages Test suivants) est utilisé pour différencier les messages Test provenant de différentes procédures de vérification de liaison LMP. En plus de la procédure Test décrite dans la [RFC4204], la fonction de surveillance de trace de la [RFC4207] peut être utilisée pour la vérification de liaison lorsque les accès d'utilisateurs de l'OLS sont SONET ou SDH.

Dans un contexte de LMP et LMP-WDM combinés, il y a une interaction entre les liaisons de données gérées par des sessions LMP de nœud homologue à nœud homologue et des sessions LMP de nœud homologue à OLS. Par exemple, dans la Figure 2, la session LMP OXC1-OLS1 gère les liaisons de données entre OXC1 et OLS1, et la session LMP OXC2-OLS2 gère les liaisons de données entre OXC2 et OLS2. Cependant, la session LMP OXC1-OXC2 gère les liaisons de données entre OXC1 et OXC2, qui sont en fait un enchaînement des liaisons de données entre OXC1 et OLS1, de l'espace DWDM entre OLS1 et OLS2, et des liaisons de données entre OXC2 et OLS2. Ce sont ces liaisons enchaînées qui constituent les liaisons TE annoncées dans la base de données d'état de liaisons TE GMPLS.

Cela implique que quand les liaisons de données entre OXC1 et OXC2 sont vérifiées, en utilisant la procédure de vérification de liaison LMP, OLS1 et OLS2 doivent se rendre transparents par rapport à ces liaisons de données enchaînées. La coordination des vérifications des liaisons de données OXC1-OLS1 et OXC2-OLS2 pour assurer cette transparence est de la responsabilité des nœuds homologues, OXC1 et OXC2. Il est aussi nécessaire que ces nœuds homologues comprennent les transpositions entre les liaisons de données de la session LMP de nœud homologue à OLS et les liaisons de données enchaînées de la session LMP de nœud homologue à nœud homologue.


2.3 Résumé de liaison

Comme dans la [RFC4204], le message LinkSummary est utilisé pour synchroniser les identifiants d'interface et corréler les propriétés de la liaison TE. (Noter que le terme "liaison TE" vient des applications d'acheminement/signalisation de LMP, et ce concept ne s'applique pas nécessairement à un OLS. Cependant, le terme est utilisé ici pour rester cohérent avec la terminologie LMP.) Le message LinkSummary inclut un ou plusieurs objets DATA_LINK. Le contenu de l'objet DATA_LINK consiste en une série d'éléments de données de longueur variable appelés sous objets de liaison de données qui décrivent les capacités des liaisons de données.


Dans ce document, plusieurs sous objets de liaison de données supplémentaires sont définis pour décrire des caractéristiques supplémentaires de liaison. Les caractéristiques de liaison sont, en général, celles qui sont nécessaires pour que le CSPF choisisse le chemin pour un LSP particulier. Ces caractéristiques de liaison décrivent la liaison de données de nœud homologue à OLS spécifiée, ainsi que la portée DWDM associée entre les deux OLS.

Le format des sous objets de liaison de données suit celui décrit dans la [RFC4204] et est répété ici :


0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+

| Type | Longueur | (contenu du sous objet) |

+---------------+---------------+---------------//--------------+


Type : 8 bits. Indique le type de contenu du sous objet.


Longueur : 8 bits. Contient la longueur totale en octets du sous objet, incluant les champs Type et Longueur. La longueur DOIT être d'au moins 4, et DOIT être un multiple de 4.


Les caractéristiques de liaison suivantes sont échangées sur la base de la liaison.


2.3.1 Identifiant de groupe de liaisons

Le principal objet de l'identifiant de groupe de liaison (Link Group ID) est de réduire le trafic de contrôle durant les défaillances qui affectent de nombreuses liaisons de données. Un identifiant local peut être alloué à un groupe de liaisons de données. Cet identifiant peut être utilisé pour réduire le trafic de contrôle en cas de défaillance en permettant d'utiliser un seul message ChannelStatus avec l'objet LINK GROUP CHANNEL_STATUS (voir au paragraphe 2.4.1) pour un groupe de liaisons de données au lieu de messages ChannelStatus individuels pour chaque liaison de données. Une liaison de données peut être membre de plusieurs groupes. On fait cela en incluant plusieurs sous objets Identifiant de groupe de liaison dans le message LinkSummary.


La caractéristique Identifiant de groupe de liaison permet d'allouer les groupes de liaison sur la base des types de corrélation et agrégation de fautes acceptés par un certain OLS. D'un point de vue pratique, l'identifiant de groupe de liaisons est utilisé pour transposer des liaisons de données (ou groupe) en "entités faillibles" connues principalement de l'OLS. Si une de ces entités faillibles a une défaillance, toutes les liaisons de données associées sont défaillantes et le nœud homologue est notifié par un seul message.


Par exemple, un OLS pourrait créer un groupe de liaisons pour chaque laser dans l'OLS. Les liaisons de données associées à chaque laser seraient alors chacune allouée à l'identifiant de groupe de liaisons pour ce laser. Si un laser a une défaillance, l'OLS va alors rapporter une seule défaillance affectant toutes les liaisons de données avec l'identifiant de groupe de liaisons du laser défaillant. Le nœud homologue qui reçoit cette seule notification de défaillance sait alors quelles liaisons de données sont affectées. De même, un OLS pourrait créer un identifiant de liaison pour une fibre, pour rapporter une défaillance affectant toutes les liaisons de données associées à cette fibre si une perte de signal (LOS) est détectée pour cette fibre.


Le format du sous objet Identifiant de groupe de liaison (Type = 3, Longueur = 8) est le suivant :


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

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

| Type | Longueur | (Réservé) |

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

| Identifiant de groupe de liaisons |

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


Le champ Réservé devrait être envoyé à zéro et ignoré à réception.


Identifiant de groupe de liaisons : 32 bits. L'identifiant 0xFFFFFFFF est réservé et indique toutes les liaisons de données dans une liaison TE. Toutes les liaisons de données sont membres du groupe de liaisons 0xFFFFFFFF par défaut.


2.3.2 Identifiant de groupe de liaisons à risque partagé (SRLG)

Il identifie le groupe de liaisons à risques partagés (SRLG, Shared Risk Link Group) dont est membre la liaison de données. Cette information peut être configurée sur un OLS par l'utilisateur et utilisée pour divers calculs de chemin (voir la [RFC4202]).


Le format du sous objet SRLG (Type = 4, Longueur = (N+1)*4 où N est le nombre de valeurs de SRLG ) est le suivant :


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

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

| Type | Longueur | (Réservé) |

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

| valeur de SRLG n° 1 |

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

| valeur de SRLG n° 2 |

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

// ... //

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

| valeur de SRLG n° (N-1) |

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

| valeur de SRLG n° N |

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


Le champ Réservé devrait être envoyé à zéro et ignoré à réception.


Valeur de groupe de liaisons à risque partagé : 32 bits. Voir la [RFC4202]. On énumère autant de SRLG qu'il s'en applique.


2.3.3 Estimation du taux d'erreurs binaires

Cet objet donne une estimation du taux d'erreurs binaires (BER, bit error rate) pour la liaison de données.


Le taux d'erreurs binaires (BER) est la proportion de bits qui ont des erreurs par rapport au nombre total de bits reçus dans une transmission, généralement exprimée comme dix à une puissance négative. Par exemple, une transmission peut avoir un BER de "10 moins 13", ce qui signifie que, sur 10 000 000 000 000 bits transmis, un bit peut être erroné. Le BER est une indication de la qualité globale du signal.


Le format du sous objet Estimation de BER (Type = 5 ; Longueur = 4) est le suivant :


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

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

| Type | Longueur | BER | (Réservé) |

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


Le champ Réservé devrait être envoyé à zéro et ignoré à réception.


BER : 8 bits. L'exposant de la représentation de BER décrite ci-dessus. C'est-à-dire, si le BER est 10 à la puissance moins X, le champ BER est réglé à X.


2.3.4 Protection optique

Cela indique si la liaison est protégée par l'OLS. Cette information peut être utilisée comme mesure de capacité de liaison. Elle peut être annoncée par l'acheminement et utilisée par la signalisation comme critère de choix, comme décrit dans la [RFC3471].


Le format du sous objet Protection optique (Type = 6 ; Longueur = 4) est le suivant :


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

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

| Type | Longueur | (Réservé) | Fanions |

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


Le champ Réservé devrait être envoyé à zéro et ignoré à réception.


Fanions : 6 bits. Le codage des fanions de liaison est défini à la Section 7 de la [RFC3471].


2.3.5 Longueur de portée totale

Cela indique la distance totale de fibre dans l'OLS. Ce peut être utilisée comme métrique d'acheminement ou pour estimer le délai.


Le format du sous objet Longueur de portée totale (Type = 7, Longueur = 8) est le suivant :


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

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

| Type | Longueur | (Réservé) |

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

| Longueur de portée |

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


Le champ Réservé devrait être envoyé à zéro et ignoré à réception.


Longueur de portée : 32 bits. Cette valeur représente la longueur totale de la portée de WDM en mètres, exprimée par un entier (long) non signé.


2.3.6 Groupe (couleur) administratif

Le groupe administratif (ou couleur) à laquelle appartient la liaison de données.


Le format du sous objet Groupe administratif (Type = 8, Longueur = 8) est le suivant :


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

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

| Type | Longueur | (Réservé) |

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

| Groupe administratif |

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


Le champ Réservé devrait être envoyé à zéro et ignoré à réception.


Groupe administratif : 32 bits. Valeur de 32 bits, comme défini dans la [RFC3630].


2.4 Gestion des fautes

La procédure de gestion des fautes utilisée entre un homologue et un OLS suit celle décrite dans la [RFC4204] ; quelques extensions supplémentaires sont définies ici. Les informations apprises des procédures de gestion de faute entre OLS et l'homologue peuvent être utilisées pour déclancher la gestion de fautes LMP d'homologue à homologue, ou peuvent être utilisées pour déclancher directement les procédures de signalisation/acheminement GMPLS.


La gestion de fautes comporte trois fonctions majeures :

1. Détection de faute

2. Localisation de faute

3. Notification de faute


Le mécanisme de détection de faute est de la responsabilité des nœuds individuels et n'est pas spécifié au titre du présent protocole.


Les mécanismes de détection de faute peuvent inclure le dépassement d'un seuil par le BER, et la perte du signal ainsi que les erreurs de niveau SONET/SDH. Il est de la responsabilité de l'OLS de traduire ces défaillances en (Signal) OK, défaillance de signal (SF, Signal Failure), ou signal dégradé (SD, Signal Degrade), comme décrit dans la [RFC4204].


C'est-à-dire qu'un OLS utilise les messages définis dans les procédures de localisation de faute LMP (les messages ChannelStatus, ChannelStatusAck, ChannelStatusRequest, et ChannelStatusResponse) pour informer le nœud homologue adjacent des défaillances qu'il a détectées, afin d'initier les procédures de localisation de faute LMP entre nœuds homologues, mais il ne participe pas à ces procédures.


L'OLS peut aussi exécuter son propre processus de localisation de faute pour lui permettre de déterminer la localisation de la faute le long de la portée DWDM. Par exemple, l'OLS peut être capable d'épingler la faute sur un certain amplificateur dans une portée de plusieurs milliers de kilomètres.


Pour rapporter les défaillances de liaison de données et les conditions de récupération, LMP-WDM utilise les messages ChannelStatus, ChannelStatusAck, ChannelStatusRequest, et ChannelStatusResponse définis dans la [RFC4204].


Chaque liaison de données est identifiée par un Identifiant d'interface. De plus, un identifiant de groupe de liaisons peut être alloué à un groupe de liaisons de données (voir au paragraphe 2.3.1). L'identifiant de groupe de liaison peut être utilisé pour réduire le trafic de contrôle en fournissant des informations d'état de canal pour un groupe de liaisons de données. Un nouvel objet LINK GROUP CHANNEL_STATUS est défini ci-dessous à cette fin. Cet objet peut être utilisé à la place des objets CHANNEL_STATUS décrits dans la [RFC4204] dans le message ChannelStatus.


2.4.1 Objet LINK_GROUP CHANNEL_STATUS

L'objet LINK_GROUP CHANNEL_STATUS est utilisé pour indiquer l'état de la liaison de données appartenant à un certain groupe de liaisons. La corrélation des liaisons de données à l'identifiant de groupe est faite avec le sous objet Identifiant de groupe de liaison de l'objet DATA_LINK.


Le format de l'objet LINK_GROUP CHANNEL_STATUS est le suivant (Classe = 13, C-Type = 4) :


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

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

| Identifiant de groupe de liaisons |

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

|A|D| État du canal |

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

| : |

// : //

| : |

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

| Identifiant de groupe de liaisons |

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

|A|D| État du canal |

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


Identifiant de groupe de liaisons : 32 bits. L'identifiant de groupe de liaisons 0xFFFFFFFF est réservé et indique toutes les liaisons de données dans une liaison TE. Toutes les liaisons de données sont membres du groupe de liaisons 0xFFFFFFFF par défaut.


État du canal : 32 bits. Les valeurs pour le champ État du canal sont définies dans la [RFC4204].


Cet objet est non négociable.


3. Considérations sur la sécurité


La sécurité du message LMP utilise IPsec, comme décrit dans la [RFC4204]. Le présent document définit seulement de nouveaux objets LMP qui sont portés dans les messages LMP existants. À ce titre, le présent document n'introduit pas de nouvelles considérations de sécurité qui ne soient pas couvertes dans la [RFC4204].


4. Considérations relatives à l'IANA


LMP [RFC4204] définit les espaces de noms suivants et les façons dont l'IANA peut faire des allocations de ces espaces de noms :

- Type de message LMP

- Classe d'objet LMP

- Type de classe d'objet LMP (C-Type) unique au sein de la classe d'objet

- Type de classe de sous objet LMP (Type) unique au sein de la classe d'objet


Ce mémoire introduit les nouvelles allocations suivantes :


Types de classe d'objet LMP :

o sous le nom de classe CONFIG (comme défini dans la [RFC4204])

- LMP-WDM_CONFIG (C-Type = 2)

o sous le nom de classe CHANNEL_STATUS (comme défini dans la [RFC4204])

- LINK_GROUP (C-Type = 4)


Noms de classe de sous objet LMP :

o sous le nom de classe DATA_LINK (comme défini dans la [RFC4204])

- Link_GroupId (Type de sous objet = 3)

- SRLG (Type de sous objet = 4)

- BER_Estimate (Type de sous objet = 5)

- Optical_Protection (Type de sous objet = 6)

- Total_Span_Length (Type de sous objet = 7)

- Administrative_Group (Type de sous objet = 8)


5. Contributeurs


Les auteurs tiennent à exprimer leur reconnaissance à Osama S. Aboul-Magd, Stuart Brorson, Sudheer Dharanikota, John Drake, David Drysdale, W. L. Edwards, Adrian Farrel, Rohit Goyal, Hirokazu Ishimatsu, Monika Jaeger, Ram Krishnan, Raghu Mannam, Eric Mannie, Dimitri Papadimitriou, Jagan Shantigram, Ed Snyder, George Swallow, Gopala Tumuluri, Yong Xue, Lucy Yong, et John Yu.


6. Références

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


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


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


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


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


[RFC4207] J. Lang, D. Papadimitriou, "Codages de réseau optique synchrone (SONET)/hiérarchie numérique synchrone (SDH) pour les messages d'essai du protocole de gestion de liaisons (LMP)", octobre 2005. (P.S.)


6.2 Référence pour information


[OLI] Fredette, A., Editor, "Optical Link Interface Requirements", Travail en cours.


Adresse des éditeurs


Andre Fredette

Jonathan P. Lang

Hatteras Networks

Sonos, Inc.

P.O. Box 110025

223 E. De La Guerra St.

Research Triangle Park

Santa Barbara, CA 93101

NC 27709-0025, USA

USA

mél : Afredette@HatterasNetworks.com

mél : jplang@ieee.org


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.