Groupe de travail Réseau	E. Mannie, Perceval	
Request for Comments : 4606	D. Papadimitriou, Alcatel	
RFC rendue obsolète : 3946	août 2006	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Extensions de commutation généralisée d'étiquettes multi protocoles (GMPLS) pour le contrôle de réseau optique synchrone (SONET) et de hiérarchie numérique synchrone (SDH)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation 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 "Protocoles officiels de l’Internet" (STD 1) pour voir 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 (2006).

Résumé
Le présent document apporte des précisions mineures à la RFC 3946. Il accompagne le document de signalisation de la commutation d'étiquette généralisée multi protocoles (GMPLS). Il définit les informations spécifiques de la technologie de réseau optique synchrone (SONET, Synchronous Optical Network)/hiérarchie numérique synchrone (SDH, Synchronous Digital Hierarchy) nécessaires quand la signalisation GMPLS est utilisée.
Table des matières
1. Introduction	1
2. Paramètres de trafic SONET et SDH	2
2.1 Paramètres de trafic SONET/SDH	2
2.2 Détails de RSVP-TE	5
2.3 Détails de CR-LDP	6
3. Étiquettes SONET et SDH	6
4. Remerciements	10
5. Considérations sur la sécurité	10
6. Considérations relatives à l'IANA	10
Contributeurs	10
Appendice 1. Extension de valeurs de type de signal pour VC-3	11
Références normatives	12
Adresse des auteurs	13
Déclaration complète de droits de reproduction	13

 	1.	Introduction

Comme décrit dans la [RFC3945], MPLS généralisé (GMPLS, Generalized MPLS) étend MPLS de la prise en charge des interfaces à capacité de commutation de paquet (PSC, Packet Switching Capable) et de la commutation à la prise en charge de quatre nouvelles classes d'interfaces et de commutation : la capacité de commutation de couche 2 (L2SC, Layer-2 Switch Capable) le multiplexage à division dans le temps (TDM, Time-Division Multiplex), la capacité de commutation lambda (LSC, Lambda Switch Capable) et la capacité de commutation de fibre (FSC, Fiber-Switch Capable). Une description fonctionnelle des extensions à la signalisation MPLS nécessaires pour prendre en charge les nouvelles classes d'interfaces et de commutateurs est fournie dans la [RFC3471]. La [RFC3473] décrit les formats et mécanismes spécifiques de RSVP-TE nécessaires pour prendre en charge les cinq classes d'interfaces, et les extensions à CR-LDP se trouvent dans la [RFC3472].

Le présent document présente des détails spécifiques de réseau optique synchrone (SONET, Synchronous Optical Network)/hiérarchie numérique synchrone (SDH, Synchronous Digital Hierarchy). Selon la [RFC3471], les paramètres spécifiques de SONET/SDH sont portés dans le protocole de signalisation dans des objets spécifiques des paramètres de trafic.

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

De plus, le lecteur est supposé être familier de la terminologie de l'Institut national des normes américaines (ANSI, American National Standards Institute) [T1.105] et de l'UIT-T [G.707], ainsi que des [RFC3471], [RFC3472], et [RFC3473]. Les abréviations suivantes sont utilisées dans ce document :

DCC (Data Communications Channel) : canal de communication de données
LOVC (Lower-Order Virtual Container) : conteneur virtuel d'ordre inférieur
HOVC (Higher-Order Virtual Container) : conteneur virtuel d'ordre supérieur
MS (Multiplex Section) : section de multiplexage
MSOH (Multiplex Section OverHead) : sur-débit de section de multiplexage
POH (Path OverHead) : sur-débit de chemin
RS (Regenerator Section) : section de régénérateur
RSOH (Regenerator Section Overhead) : sur-débit de section de régénérateur
SDH (Synchronous Digital Hierarchy) : hiérarchie numérique synchrone
SOH (Section overhead) : sur-débit de section
SONET (Synchronous Optical Network) : réseau optique synchrone
SPE (Synchronous Payload Envelope) : enveloppe de charge utile synchrone
STM(-N) (Synchronous Transport Module (-N)) : module de transport synchrone de niveau N
STS(-N) (Synchronous Transport Signal-Level N) : signal de transport synchrone de niveau N
VC-n (Virtual Container-n) : conteneur virtuel de niveau n
Vtn (Virtual Tributary-n) : tributaire virtuel de niveau n

 	2.	Paramètres de trafic SONET et SDH

Cette section définit les paramètres de trafic GMPLS pour SONET/SDH. Les formats spécifiques du protocole pour les objets RSVP-TE spécifiques de SONET/SDH et les TLV CR-LDP, sont décrits respectivement aux paragraphes 2.2 et 2.3.

Ces paramètres de trafic spécifient un ensemble de base de capacités pour SONET ANSI [T1.105] et SDH UIT-T [G.707], comme l'enchaînement et la transparence. D'autres documents peuvent encore améliorer cet ensemble de capacités à l'avenir. Par exemple, la signalisation pour SDH sur des interfaces PDH UIT-T G.832 ou sous STM-0 UIT-T G.708 pourrait être définie.

Les paramètres de trafic définis ici (paragraphe 2.1) DOIVENT être utilisés quand l'étiquette est codée comme SUKLM comme défini dans le présent mémoire (voir la Section 3). Ils DOIVENT aussi être utilisés pour demander un des signaux de Section/RS ou Ligne/MS à sur-débit transparent STS-1/STM-0, STS-3*N/STM-N (N=1, 4, 16, 64, 256).

Le codage des paramètres de trafic et étiquettes défini au paragraphe 3.2 de la [RFC3471] DOIT être utilisé pour les demandes de signaux pleinement transparents STS-1/STM-0, STS-3*N/STM-N (N=1, 4, 16, 64, 256). Un signal pleinement transparent est celui pour lequel tout le sur-débit est laissé non modifié par les nœuds intermédiaires ; c'est-à-dire, quand tous les bits Transparence (T) définis seraient établis si les paramètres de trafic définis au paragraphe 2.1 étaient utilisés.

 	2.1	Paramètres de trafic SONET/SDH
Les paramètres de trafic pour SONET/SDH sont organisés comme suit :

 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 de signal |      RCC      |              NCC              |
+---------------+---------------+---------------+---------------+
|              NVC              |        Multiplicateur (MT)    |
+---------------+---------------+---------------+---------------+
|                       Transparence (T)                        |
+---------------+---------------+---------------+---------------+
|                           Profil  (P)                         |
+---------------+---------------+---------------+---------------+

L'Annexe 1 donne des exemples de codage de signal SONET et SDH.

o) Type de signal (ST, Signal Type) : 8 bits
Ce champ indique le type de signal élémentaire qui constitue le chemin de commutation d'étiquette (LSP, Label Switched Path) demandé. Plusieurs transformations peuvent être appliquées successivement sur le signal élémentaire pour construire le signal final réellement demandé pour le LSP.

Chaque application de transformation est facultative et doit être ignorée si elle est zéro, sauf le multiplicateur (MT) qui ne peut pas être zéro et est ignoré si il est égal à un.

Les transformations doivent être appliquées strictement dans l'ordre suivant :
-	D'abord, l'enchaînement contigu (en utilisant les champs RCC et NCC) peut être facultativement appliqué sur le signal élémentaire, résultant en un signal enchaîné de façon contiguë.
-	Ensuite, l'enchaînement virtuel (en utilisant le champ NVC) peut être facultativement appliqué sur le signal élémentaire, résultant en un signal virtuellement enchaîné.
-	En troisième lieu, une certaine transparence (en utilisant le champ Transparence) peut être facultativement spécifiée quand une trame est demandée comme signal plutôt que comme signal fondé sur SPE ou VC.
-	Enfin, une multiplication (en utilisant le champ Multiplicateur) peut être facultativement appliquée directement sur le signal élémentaire, sur le signal enchaîné de façon contiguë obtenu de la première phase, sur le signal virtuellement enchaîné obtenu de la seconde phase, ou sur ces signaux combinés avec une certaine transparence.

Les valeurs de type de signal permises pour SONET/SDH sont

Valeur	Type (signal élémentaire)
     1	VT1.5  SPE / VC-11
     2	VT2     SPE / VC-12
     3	VT3     SPE
     4	VT6     SPE / VC-2
     5	STS-1  SPE / VC-3
     6	STS-3c SPE / VC-4
     7	STS-1    / STM-0   (seulement quand transparence est demandé)
     8	STS-3    / STM-1   (seulement quand transparence est demandé)
     9	STS-12   / STM-4   (seulement quand transparence est demandé)
   10	STS-48   / STM-16  (seulement quand transparence est demandé)
   11	STS-192 / STM-64  (seulement quand transparence est demandé)
   12	STS-768 / STM-256 (seulement quand transparence est demandé)

Un type de signal dédié est alloué à une SPE SONET STS-3c au lieu d'être codée comme un enchaînement contigu de trois SPE STS-1. Ceci est fait afin de fournir un inter fonctionnement aisé entre la signalisation SONET et SDH.

L'Appendice 1 ajoute un type de signal (facultatif) aux valeurs ci-dessus.

o) Enchaînement contigu demandé (RCC, Requested Contiguous Concatenation) : 8 bits
Ce champ est utilisé pour demander l'enchaînement contigu SONET/SDH facultatif du signal élémentaire.
Ce champ est a vecteur de fanions. Chaque fanion indique la prise en charge d'un type particulier d'enchaînement contigu. Plusieurs fanions peuvent être établis en même temps pour indiquer un choix.
Ces fanions permettent à un nœud amont d'indiquer à un nœud aval les différents types d'enchaînement contigu qu'il prend en charge. Cependant, le nœud aval décide lequel utiliser selon ses propres règles.

Un nœud aval qui reçoit simultanément plus d'un fanion choisit un type particulier d'enchaînement contigu, si il en est de pris en charge, et en accord avec des critères qui sortent du domaine d'application de ce document. Un nœud aval qui ne prend pas en charge les types d'enchaînement indiqués par le champ doit refuser la demande de LSP. En particulier, il doit refuser la demande de LSP si il ne prend pas du tout en charge l'enchaînement contigu.

Quand plusieurs fanions sont été établis, le nœud amont restitue le type (le seul) d'enchaînement contigu que le nœud aval a choisi en cherchant la position indiquée par la première étiquette et le nombre d'étiquettes comme retourné par le nœud aval (voir aussi la Section 3).

Le champ entier est réglé à zéro pour indiquer qu'aucun enchaînement contigu n'est demandé (valeur par défaut). Un champ non zéro indique qu'un enchaînement contigu est demandé.

Le fanion suivant est défini :

Fanion 1 (bit 1) : enchaînement contigu standard.
Fanion 1 indique que l'enchaînement contigu SONET/SDH standard, comme défini dans [T1.105]/[G.707], est pris en charge. Noter que le bit 1 est le bit de moindre poids. Les autres fanions sont réservés pour des extensions ; si ils ne sont pas utilisés, ils doivent être réglés à zéro à l'envoi et devraient être ignorés à réception.

Voir la note 1 ci-dessous sur le nombre de composants contigus sur l'enchaînement contigu SONET de SPE STS-1 quand le nombre de composants est un multiple de trois.

o) Nombre de composants contigus (NCC) : 16 bits
Ce champ indique le nombre de VC SPE/SDH SONET identiques (c'est-à-dire, signal élémentaire) qu'il est demandé d'enchaîner, comme spécifié dans le champ RCC.

Note 1 : Quand un SPE SONET STS-Nc avec N=3*X est demandé, le signal élémentaire à utiliser doit toujours être un type de signal STS-3c_SPE, et la valeur de NCC doit toujours être égale à X. Cela permet de faciliter l'inter fonctionnement entre SONET et SDH. En particulier, cela signifie que l'enchaînement contigu de trois SPE STS-1 ne peut pas être demandé, car conformément à la présente spécification, ce type de signal doit être codé en utilisant le type de signal SPE STS-3c.

Note 2 : Quand un signal transparent STS-N/STM-N est demandé qui est limité à un seul STS-Nc_SPE/VC-4-Nc à enchaînement contigu, le type de signal doit être STS-N/STM-N, RCC avec le fanion 1, NCC réglé à 1. La valeur de NCC doit être cohérente avec le type d'enchaînement contigu demandé dans le champ RCC. En particulier, ce champ n'est pas pertinent si aucun enchaînement contigu n'est demandé (RCC = 0). Dans ce cas, il doit être réglé à zéro à l'envoi et devrait être ignoré à réception. Une valeur de RCC différente de 0 implique un certain nombre de composants contigus supérieurs ou égaux à 1.

Note 3 : Suivant ces règles, quand un signal VC-4 est demandé, les valeurs de RCC et de NCC DEVRAIENT être réglées à 0, tandis que pour un signal de SPE STS-3c, les valeurs de RCC et de NCC DEVRAIENT être réglées à 1. Cependant, si les conditions locales le permettent, comme le réglage des valeurs de RCC et NCC est piloté en local, le nœud amont demandeur PEUT régler les valeurs de RCC et NCC aux réglages SDH ou SONET sans impacter la fonction. De plus, le nœud aval DEVRAIT accepter les valeurs demandées si les conditions locales le permettent. Si ces valeurs ne peuvent pas être prises en charge, le nœud aval receveur DEVRAIT générer un message PathErr/NOTIFICATION (voir respectivement les paragraphes 2.2 et 2.3,).

o) Nombre de composants virtuels (NVC) : 16 bits
Ce champ indique le nombre de signaux qu'il est demandé d'enchaîner virtuellement. Ces signaux sont tous du même type par définition. Ce sont des signaux élémentaires de SPE/VC pour lesquels les types de signaux sont définis dans ce document, c'est-à-dire, VT1.5_SPE/VC-11, VT2_SPE/VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3, ou STS-3c_SPE/VC-4.
Ce champ est réglé à 0 (valeur par défaut) pour indiquer qu'aucun enchaînement virtuel n'est demandé.

o) Multiplicateur (MT) : 16 bits
Ce champ indique le nombre de signaux identiques qui sont demandés pour le LSP; c'est-à-dire, qui forment le signal final. Ces signaux peuvent être des signaux élémentaires identiques, des signaux enchaînés contigüment identiques, ou des signaux identiques virtuellement enchaînés. Noter que tous ces signaux appartiennent donc au même LSP.

La distinction entre les composants de plusieurs signaux virtuellement enchaînés est faite via l'ordre des étiquettes qui sont spécifiées dans la signalisation. Le premier jeu d'étiquettes doit décrire le premier composant (ensemble des signaux individuels appartenant au premier signal virtuellement enchaîné) ; le second jeu doit décrire le second composant (jeu de signaux individuels appartenant en second signal virtuellement enchaîné) et ainsi de suite.

Ce champ est réglé à un (valeur par défaut) pour indiquer que exactement une instance d'un signal est demandée. Les nœuds intermédiaires et de sortie DOIVENT vérifier que le nœud lui-même et les interfaces sur lesquelles le LSP va être établi peuvent prendre en charge la valeur de multiplicateur demandée. Si les valeurs demandées ne peuvent pas être prises en charge, le nœud receveur DOIT générer un message PathErr/NOTIFICATION (voir respectivement les paragraphes 2.2 et 2.3).

Zéro est une valeur invalide. Si un zéro est reçu, le nœud DOIT générer un message PathErr/NOTIFICATION (voir respectivement les paragraphes 2.2 et 2.3)..

Note : quand un signal transparent STS-N/STM-N est demandé qui est limité à un seul STS-Nc-SPE/VC-4-Nc à enchaînement contigu, le champ multiplicateur DOIT être égal à 1 (seule valeur valide).

Transparence (T) : 32 bits
Ce champ est un vecteur de fanions qui indique le type de transparence demandée. Plusieurs fanions peuvent être combinés pour fournir différents types de transparence. Toutes les combinaisons ne sont pas nécessairement valides. La valeur par défaut pour ce champ est zéro, c'est-à-dire, aucune transparence n'est demandée.

La transparence, comme définie du point de vue de cette spécification de signalisation, est seulement applicable aux champs dans les sur-débits de trame SONET/SDH. Dans le cas de SONET, ce sont les champs Sur-débit de section (SOH, Section Overhead) et Sur-débit de ligne (LOH, Line Overhead). Dans le cas de SDH, ce sont les champs Sur-débit de section de régénérateur (RSOH, Regenerator Section Overhead), Sur-débit de section de multiplexage (MSOH, Multiplex Section overhead) et les champs de pointeur entre les deux. Avec SONET, les champs de pointeur font partie du LOH.

Noter aussi que la transparence est seulement applicable quand les types de signaux suivants sont utilisés : STS-1/STM-0, STS-3/STM-1, STS-12/STM-4, STS-48/STM-16, STS-192/STM-64, et STS-768/STM-256. Au moins un type de transparence doit être spécifié quand un tel type de signal est demandé.

La transparence indique précisément quels champs dans ces sur-débits doivent être livrés non modifiés à l'autre extrémité du LSP. Un routeur de commutation d'étiquettes (LSR, Label Switching Router) d'entrée qui demande la transparence va passer ces champs de sur-débit qui doivent être livrés au LSR de sortie sans aucun changement. Du point de vue des LSR d'entrée et de sortie, ces champs doivent être vus comme étant non modifiés.

La transparence n'est pas appliquée aux interfaces avec les LSR d'initiation et de terminaison mais seulement entre les LSR intermédiaires. Le champ Transparence est utilisé pour demander un LSP qui prend en charge le type de transparence demandé ; il peut aussi être utilisé pour établir le processus de transparence à appliquer à chaque LSR intermédiaire.

Les différents fanions de transparence sont comme suit :

Fanion 1 (bit 1) : couche de section Section/Régénérateur
Fanion 2 (bit 2) : couche de section Ligne/Multiplexage

où le bit 1 est le bit de moindre poids. Les autres fanions sont réservés ; ils devraient être réglés à zéro à l'émission et ignorés à réception. Un fanion est réglé à un pour indiquer que la transparence correspondante est demandée.

Les nœuds intermédiaires et de sortie DOIVENT vérifier que le nœud lui-même et les interfaces sur lesquelles le LSP va être établi peuvent supporter la transparence demandée. Si les fanions demandés ne peuvent pas être pris en charge, le nœud receveur DOIT générer un message PathErr/NOTIFICATION (voir respectivement les paragraphes 2.2 et 2.3).

La transparence de couche de section Section/Régénérateur signifie que les trames entières doivent être livrées non modifiées. Cela implique que les pointeurs ne peuvent pas être ajustés. Quand la transparence de couche de section Section/Régénérateur est utilisée, tous les autres fanions DOIVENT être ignorés.

La transparence de couche de section Ligne/Multiplexage signifie que le LOH/MSOH doit être livré non modifié. Cela implique que les pointeurs ne peuvent pas être ajustés.

Profil (P) : 32 bits
Ce champ est destiné à indiquer des capacités particulières qui doivent être prises en charge pour le LSP ; par exemple, des capacités de surveillance. Aucun profil standard n'est actuellement défini, et ce champ DEVRAIT être réglé à zéro à l'émission et ignoré à réception.

À l'avenir, des extensions fondées sur les TLV pourraient être créées.

 	2.2	Détails de RSVP-TE
Pour RSVP-TE, les paramètres de trafic SONET/SDH sont portés dans les objets SONET/SDH SENDER_TSPEC et FLOWSPEC. Le même format est utilisé pour l'objet SENDER_TSPEC et pour les objets FLOWSPEC. Le contenu des objets est défini ci-dessus, au paragraphe 2.1. Les objets ont les classes et types suivants pour SONET ANSI T1.105 et SDH UIT-T G.707 :

Objet SONET/SDH SENDER_TSPEC : classe = 12, C-Type = 4
Objet SONET/SDH FLOWSPEC : classe = 9, C-Type = 4

Il n'y a pas d'Adspec associée à SENDER_TSPEC SONET/SDH. Soit l'Adspec est omise, soit une Adspec int-serv avec le fragment Paramètres de caractérisation générale par défaut et Service garanti est utilisée ; voir la [RFC2210].

Pour un envoyeur particulier dans une session, le contenu de l'objet FLOWSPEC reçu dans un message Resv DEVRAIT être identique au contenu de l'objet SENDER_TSPEC reçu dans le message Path correspondant. Si les objets ne correspondent pas, un message ResvErr avec une erreur "Erreur de contrôle de trafic/mauvaise valeur de Flowspec" DEVRAIT être générée.

Les nœuds intermédiaires et de sortie DOIVENT vérifier que le nœud lui-même et les interfaces sur lesquelles le LSP va être établi peuvent supporter le type de signal demandé, RCC, NCC, NVC et Multiplicateur (comme défini au paragraphe 2.1). Si la ou les valeurs demandées ne peuvent pas être prises en charge, le nœud receveur DOIT générer un message PathErr avec une indication "Erreur de contrôle de trafic/Service non pris en charge" (voir la [RFC2205]).

De plus, si le champ MT est reçu avec une valeur de zéro, le nœud DOIT générer un message PathErr message avec une indication "Erreur de contrôle de trafic/Mauvaise valeur de Tspec" (voir la [RFC2205]).

Les nœuds intermédiaires DOIVENT aussi vérifier que le nœud lui-même et les interfaces sur lesquelles le LSP va être établi peuvent supporter la transparence demandée (comme défini au paragraphe 2.1). Si la ou les valeurs demandées ne peuvent pas être prises en charge, le nœud receveur DOIT générer un message PathErr avec une indication "Erreur de contrôle de trafic/service non pris en charge" (voir la [RFC2205]).

 	2.3	Détails de CR-LDP
Pour CR-LDP, les paramètres de trafic SONET/SDH sont portés dans la TLV SONET/SDH Paramètres de trafic. Le contenu de la TLV est défini ci-dessus au paragraphe 2.1. L'en-tête de la TLV a le format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F|          Type             |      Longueur                 |
+-+-+-----------+---------------+---------------+---------------+

Le champ Type pour la TLV SONET/SDH Paramètres de trafic est 0x0838.

Les nœuds intermédiaires et de sortie DOIVENT vérifier que le nœud lui-même et les interfaces sur lesquelles le LSP va être établi peuvent supporter le type de signal demandé, RCC, NCC, NVC, et Multiplicateur (comme défini au paragraphe 2.1). Si la ou les valeurs demandées ne peuvent pas être prises en charge, le nœud receveur DOIT générer un message NOTIFICATION avec un code d'état "Ressource indisponible" (voir la [RFC3212]).

De plus, si le champ MT est reçu avec une valeur de zéro, le nœud DOIT générer un message NOTIFICATION avec un code d'état "Ressource indisponible" (voir la [RFC3212]).

Les nœuds intermédiaires DOIVENT aussi vérifier que le nœud lui-même et les interfaces sur lesquelles le LSP va être établi peuvent supporter la transparence demandée (comme défini au paragraphe 2.1). Si la ou les valeurs demandées ne peuvent pas être prises en charge, le nœud receveur DOIT générer un message NOTIFICATION avec un code d'état "Ressource indisponible" (voir la [RFC3212]).

 	3.	Étiquettes SONET et SDH

SONET et SDH définissent chacun une structure de multiplexage. Les deux structures sont des arborescences dont les racines sont, respectivement, un STS-N ou un STM-N et dont les feuilles sont les signaux qui peuvent être transportés via les intervalles de temps et commutés entre les intervalles de temps dans un accès d'entrée et les intervalles de temps dans un accès de sortie ; c'est-à-dire, un SPE VTx, un SPE STS-x, ou un VC-x. Une étiquette SONET/SDH va identifier la position exacte (c'est-à-dire, le premier intervalle de temps) d'un signal SPE VTx, STS-x, ou VC-x particulier dans une structure de multiplexage. Les étiquettes SONET et SDH sont portées dans l'étiquette généralisée conformément aux [RFC3473] et [RFC3472].

Noter que par intervalle de temps on signifie les intervalles de temps qui apparaissent logiquement et en séquence dans le multiplex, et non comme ils apparaissent après un éventuel entrelaçage.

Ces structures de multiplexage vont être utilisées comme arborescences de désignation pour créer des noms ou étiquettes d'entrée de multiplex uniques. Le même format d'étiquette est utilisé pour SONET et SDH. Comme l'explique la [RFC3471], une étiquette n'identifie pas la "classe" à laquelle appartient l'étiquette. Celle-ci est implicitement déterminée par la liaison sur laquelle l'étiquette est utilisée.

En cas d'enchaînement ou multiplication de signal, une liste d'étiquettes peut apparaître dans le champ Étiquette d'une étiquette généralisée.

En cas d'enchaînement contigu, seulement une étiquette apparaît dans le champ Étiquette. Cette étiquette unique est codée comme une seule valeur d'étiquette de 32 bits (comme défini dans cette section) de l'objet Étiquette généralisée (Class-Num  = 16, C-Type = 2)/TLV (0x0825). Cette étiquette identifie le plus bas intervalle de temps occupé par le signal à enchaînement contigu. Par plus bas intervalle de temps, on signifie celui qui a la plus faible étiquette (valeur) en termes de valeur d'entier ; c'est-à-dire, l'intervalle de temps occupé par le premier composant de signal du signal enchaîné rencontré en descendant l'arborescence.

En cas d'enchaînement virtuel, on donne la liste ordonnée explicite de toutes les étiquettes dans l'enchaînement. Cette liste ordonnée d'étiquettes est codée comme une séquence de valeurs d'étiquettes de 32 bits (comme défini dans cette section) de l'objet Étiquette généralisée (Class-Num = 16, C-Type = 2)/TLV (0x0825). Chaque étiquette indique le premier intervalle de temps occupé par un composant du signal virtuellement enchaîné. L'ordre des étiquettes doit refléter l'ordre des charges utiles à enchaîner (pas l'ordre physique des intervalles de temps). Cette représentation limite l'enchaînement virtuel à rester dans une seule liaison (composant) ; elle impose à ce titre une restriction par rapport aux recommandations de l'ANSI [T1.105] et de l'UIT-T [G.707]. La définition standard pour l'enchaînement virtuel permet à chaque composant d'enchaînement virtuel de voyager sur un chemin différent. Dans GMPLS, les composants d'enchaînement virtuel doivent voyager sur la même liaison (composant) si ils font partie du même LSP. Ceci est dû à la façon dont les étiquettes sont liées à une liaison (composant). Noter cependant que l'acheminement des composants sur des chemins différents est bien sûr équivalent à établir des LSP différents, ayant chacun son propre chemin. Plusieurs LSP peuvent être initiés et terminés entre les mêmes nœuds, et leurs composants correspondants peuvent alors être associés (c'est-à-dire, enchaînés virtuellement).

En cas de multiplication (c'est-à-dire, en utilisant la transformation de multiplication) on donne la liste ordonnée explicite de toutes les étiquettes qui font partie du signal final. Cette liste ordonnée d'étiquettes est codée comme une séquence de valeurs d'étiquette de 32 bits (comme défini dans cette section) de l'objet Étiquette généralisée (Class-Num = 16, C-Type = 2)/TLV (0x0825). En cas de multiplication de signaux virtuellement enchaînés, on donne la liste explicite ordonnée de l'ensemble des étiquettes qui font partie du signal final. Le premier ensemble d'étiquettes indique les intervalles de temps occupés par le premier signal virtuellement enchaîné, le second ensemble d'étiquettes indique les intervalles de temps occupés par le second signal virtuellement enchaîné, et ainsi de suite. La représentation ci-dessus limite la multiplication aux limites d'une seule liaison (composant).

Le format de l'étiquette pour une liaison SONET et/ou SDH TDM-LSR est

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               S               |   U   |   K   |   L   |   M   |
+---------------+---------------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C'est une extension du schéma de numérotation défini aux paragraphes 7.3.7 à 7.3.13 de [G.707] c'est-à-dire, de la numérotation (K, L, M). Noter que le schéma de numérotation d'ordre supérieur défini aux paragraphes 7.3.1 à 7.3.6 de [G.707] n'est pas utilisé ici.

Chaque lettre indique un possible numéro de branche commençant au nœud parent dans la structure de multiplexage. Les branches sont considérées comme numérotées en ordre croissant, en partant du sommet de la structure de multiplexage. La numérotation commence à 1 ; zéro est utilisé pour indiquer un champ non significatif ou ignoré.

Quand un champ est non significatif ou ignoré dans un contexte particulier, il DOIT être réglé à zéro à l'émission et ignoré à réception.

Quand une hiérarchie de LSP SONET/SDH est utilisée, un LSP d'ordre supérieur avec une certaine bande passante peut être utilisé pour porter un LSP d'ordre inférieur. On se rappelle qu'un LSP d'ordre supérieur est établi à travers un chemin de réseau de couche SONET/SDH d'ordre supérieur, et un LSP d'ordre inférieur à travers un chemin de réseau de couche SONET/SDH d'ordre inférieur (voir aussi à la Section 3 de la Recommandation UIT-T G.803 les définitions correspondantes). Dans ce contexte, le LSP SONET/SDH d'ordre supérieur se comporte comme une "liaison virtuelle" avec une bande passante donnée (par exemple, VC-3) ; il peut aussi être utilisé comme adjacence de transmission. Un LSP SONET/SDH d'ordre inférieur peut être établi à travers un LSP d'ordre supérieur. Comme une étiquette est locale pour une liaison (virtuelle) la partie supérieure de cette étiquette (c'est-à-dire, les champs S, U, et K) est non significative et est réglée à zéro ; c'est-à-dire, l'étiquette est "0,0,0,L,M". De même, si la structure du LSP d'ordre inférieur est inconnue ou non pertinente, la partie inférieure de cette étiquette (c'est-à-dire, les champs L et M) est non significative et est réglée à zéro ; c'est-à-dire, l'étiquette est "S,U,K,0,0".

Par exemple, un LSP VC-3 peut être utilisé pour porter un LSP d'ordre inférieur. Dans ce cas, les étiquettes allouées entre les deux extrémités du LSP VC-3 pour le LSP d'ordre inférieur vont avoir S, U, et K réglés à zéro (c'est-à-dire, non significatifs) tandis que L et M vont être utilisés pour indiquer le signal alloué dans ce VC-3.

En cas de tunnelage, comme VC-4 contenant VC-3 contenant VC-12/VC-11, lorsque la structure SUKLM n'est pas adéquate pour représenter la structure de signal complète, une approche hiérarchique doit être utilisée, c'est-à-dire, une signalisation par couche réseau.

Les valeurs possibles de S, U, K, L, et M sont définies comme suit :

1. S=1->N est l'indice d'un STS-3/AUG-1 particulier à l'intérieur d'un multiplex STS-N/STM-N. S n'est significatif que pour SONET STS-N (N>1) et SDH STM-N (N>0). S doit être 0 et ignoré pour STS-1 et STM-0.

2. U=1->3 est l'indice d'un STS-1_SPE/VC-3 particulier dans un STS-3/AUG-1. U n'est significatif que pour SONET STS-N (N>1) et SDH STM-N (N>0). U doit être 0 et ignoré pour STS-1 et STM-0.

3. K=1->3 est l'indice d'un TUG-3 particulier au sein d'un VC-4. K n'est significatif que pour un VC-4 SDH structuré en TUG-3. K doit être 0 et ignoré dans tous les autres cas.

4. L=1->7 est l'indice d'un VT_Group/TUG-2 particulier dans un STS-1_SPE/TUG-3 ou VC-3. L doit être 0 et ignoré dans tous les autres cas.

5. M est l'indice d'un VT1.5_SPE/VC-11, VT2_SPE/VC-12, ou VT3_SPE particulier au sein d'un VT_Group/TUG-2. M=1->2 indique un VT3 SPE spécifique au sein du groupe VT correspondant ; ces valeurs NE DOIVENT PAS être utilisées pour SDH, car il n'y a pas d'équivalent de VT3 avec SDH. M=3->5 indique un VT2_SPE/VC-12 spécifique dans le VT_Group/TUG-2 correspondant. M=6->9 indique un VT1.5_SPE/VC-11 spécifique au sein du VT_Group/TUG-2 correspondant.

Noter qu'une étiquette doit toujours être interprétée conformément aux paramètres de trafic SONET/SDH ; c'est-à-dire, une étiquette par elle-même ne permet pas de savoir quel signal est demandé (une étiquette est sensible au contexte).

Le format d'étiquette défini dans cette section, appelé SUKLM, DOIT être utilisé pour toute demande de signal SONET/SDH qui n'est pas transparente ; c'est-à-dire, quand tous les bits Transparence (T) définis au paragraphe 2.1 sont réglés à zéro. Toute demande de signal transparent STS-1/STM-0/STS-3*N/STM-N (N=1, 4, 16, 64, 256) DOIT utiliser un format d'étiquette défini dans la [RFC3471].

Le codage S est résumé dans le tableau suivant :

S	SDH	SONET
0	autre	autre
1	1er AUG-1	1er STS-3
2	2ème AUG-1	2ème STS-3
3	3ème AUG-1	3ème STS-3
4	4ème AUG-1	4ème STS-3
:	:	:
N	Nème AUG-1	Nème STS-3

Le codage U est résumé dans le tableau suivant :

U	AUG-1 SDH	STS-3 SONET
0 	autre	autre
1	1er VC-3	1er STS-1 SPE
2	2ème VC-3	2ème STS-1 SPE
3	3ème VC-3	3ème STS-1 SPE

Le codage K est résumé dans le tableau suivant :

K	VC-4 SDH
0	autre
1	1er TUG-3
2	2ème TUG-3
3	3ème TUG-3

Le codage L est résumé dans le tableau suivant :

L	TUG-3 SDH	VC-3 SDH	SPE SONET STS-1
0	autre	autre	autre
1	1er TUG-2	1er TUG-2	1er VTG
2	2ème TUG-2	2ème TUG-2	2ème VTG
3	3ème TUG-2	3ème TUG-2	3ème VTG
4	4ème TUG-2	4ème TUG-2	4ème VTG
5	5ème TUG-2	5ème TUG-2	5ème VTG
6	6ème TUG-2	6ème TUG-2	6ème VTG
7	7ème TUG-2	7ème TUG-2	7ème VTG

Le codage M est résumé dans le tableau suivant :

M	TUG-2 SDH	VTG SONET
0 	autre	autre
1	-	1er SPE VT3
2	-	2ème SPE VT3
3	1er VC-12	1er SPE VT2
4	2ème VC-12	2ème SPE VT2
5	3ème VC-12	3ème SPE VT2
6	1er VC-11	1er SPE VT1.5
7	2ème VC-11	2ème SPE VT1.5
8	3ème VC-11	3ème SPE VT1.5
9	4ème VC-11	4ème SPE VT1.5

Exemples d'étiquettes

Exemple 1 : l'étiquette pour le STS-3c_SPE/VC-4 dans le Sème STS-3/AUG-1 est : S>0, U=0, K=0, L=0, M=0.

Exemple 2 : l'étiquette pour le VC-3 dans le Kème-1 TUG-3 dans le VC-4 dans le Sème AUG-1 est : S>0, U=0, K>0, L=0, M=0.

Exemple 3 : l'étiquette pour le Uème-1 STS-1_SPE/VC-3 dans le Sème STS-3/AUG-1 est : S>0, U>0, K=0, L=0, M=0.

Exemple 4 : l'étiquette pour le VT6/VC-2 dans le Lème-1 VT Group/TUG-2 dans le Uème-1 STS-1_SPE/VC-3 dans le Sème STS-3/AUG-1 est : S>0, U>0, K=0, L>0, M=0.

Exemple 5 : l'étiquette pour le 3ème VT1.5_SPE/VC-11 dans le Lème-1 VT Groupe/TUG-2 au sein du Uème-1 STS-1_SPE/VC-3 dans le Sème STS-3/AUG-1 est : S>0, U>0, K=0, L>0, M=8.

Exemple 6 : l'étiquette pour le STS-12c SPE/VC-4-4c qui utilise le 9ème STS-3/AUG-1 comme premier intervalle de tempst est : S=9, U=0, K=0, L=0, M=0.

Dans le cas d'enchaînement contigu, l'étiquette qui est utilisée est la plus faible étiquette (valeur) du signal à enchaînement contigu, comme expliqué plus haut. La partie supérieure de l'étiquette indique où commence le signal, et la partie inférieure n'est pas significative.

Dans le cas de STM-0/STS-1, les valeurs de S, U, et K doivent être égales à zéro, conformément aux règles de codage de champ. Par exemple, quand un VC-3 dans un STM-0 est demandé, l'étiquette est S=0, U=0, K=0, L=0, M=0. Quand un VC-11 dans un VC-3 dans un STM-0 est demandé, l'étiquette est S=0, U=0, K=0, L>0, M=6..9.

Note : quand un signal transparent Section/RS ou Ligne/MS STS-1/STM-0/ STS-3*N/STM-N (N=1, 4, 16, 64, 256) est demandé, le format d'étiquette et codage SUKLM n'est pas applicable, et le codage d'étiquette DOIT suivre les règles définies au paragraphe 3.2 de la [RFC3471].

 	4.	Remerciements

Des commentaires et apports précieux ont été reçus sur la liste de diffusion CCAMP, où ont eu lieu les discussions.
Les auteurs tiennent à remercier Richard Rabbat de ses précieux apports, qui ont conduit à la présente révision.

 	5.	Considérations sur la sécurité

Le présent document n'introduit aucune nouvelle considération de sécurité à la [RFC3473] ou la [RFC3472]. La sécurité de GMPLS est décrite à la Section 11 de la [RFC3471] et se réfère à la [RFC3209] pour RSVP-TE et à la [RFC3212] pour CR-LDP.

 	6.	Considérations relatives à l'IANA

Trois valeurs définies par l'IANA pour la RFC 3946 s'appliquent maintenant au présent document.

Deux C-Types RSVP dans le registre http://www.iana.org/assignments/rsvp-parameters 
- un objet SONET/SDH SENDER_TSPEC : classe = 12, C-Type = 4 (voir le paragraphe 2.2).
- un objet SONET/SDH FLOWSPEC : classz = 9, C-Type = 4 (voir le paragraphe 2.2).

Un type de TLV LDP dans le registre http://www.iana.org/assignments/ldp-namespaces 
- un champ Type pour la TLV Paramètres de trafic SONET/SDH (voir le paragraphe 2.3).

 	Contributeurs

Stefan Ansorge (Alcatel)	Peter Ashwood-Smith (Nortel)	Ayan Banerjee (Calient)	
Lorenzstrasse 10	PO. Box 3511 Station C,	5853 Rue Ferrari	
70435 Stuttgart, Germany	Ottawa, ON K1Y 4H7, Canada	San Jose, CA 95138, USA	
mél : stefan.ansorge@alcatel.de 	mél : petera@nortelnetworks.com 	mél : abanerjee@calient.net 	

Lou Berger (Movaz)	Greg Bernstein (Ciena)	Angela Chiu (Celion)	
7926 Jones Branch Drive	10480 Ridgeview Court	One Sheila Drive, Suite 2	
McLean, VA 22102, USA	Cupertino, CA 94014, USA	Tinton Falls, NJ 07724-2658	
mél : lberger@movaz.com 	mél : greg@ciena.com 	mél : angela.chiu@celion.com 	

John Drake (Calient)	Yanhe Fan (Axiowave)	Michele Fontana (Alcatel)	
5853 Rue Ferrari	100 Nickerson Road	Via Trento 30,	
San Jose, CA 95138, USA	Marlborough, MA 01752, USA	I-20059 Vimercate, Italy	
mél : jdrake@calient.net 	mél : yfan@axiowave.com 	mél : michele.fontana@alcatel.it 	

Gert Grammel (Alcatel)	Juergen Heiles (Siemens)	Suresh Katukam (Cisco)	
Lorenzstrasse, 10	Hofmannstr. 51	1450 N. McDowell Blvd,	
70435 Stuttgart, Germany	D-81379 Munich, Germany	Petaluma, CA 94954-6515, USA	
mél : gert.grammel@alcatel.de 	mél : juergen.heiles@siemens.com 	mél : suresh.katukam@cisco.com 	

Kireeti Kompella (Juniper)	Jonathan P. Lang (Calient)	Zhi-Wei Lin (Lucent)	
1194 N. Mathilda Ave.	25 Castilian	101 Crawfords Corner Rd	
Sunnyvale, CA 94089, USA	Goleta, CA 93117, USA	Holmdel, NJ  07733-3030, USA	
mél : kireeti@juniper.net 	mél : jplang@calient.net 	mél : zwlin@lucent.com 	

Fong Liaw (Solas Research)	Ben Mack-Crane (Tellabs)	Mike Raftelis (White Rock)
mél : fongliaw@yahoo.com	mél : ben.mack-crane@tellabs.com	18111 Preston Road
		Dallas, TX 75252, USA

Dimitrios Pendarakis (Tellium)	Bala Rajagopalan (Tellium)	Yakov Rekhter (Juniper)	
2 Crescent Place, P.O. Box 901	2 Crescent Place, P.O. Box 901	1194 N. Mathilda Ave.	
Oceanport, NJ 07757-0901, USA	Oceanport, NJ 07757-0901, USA	Sunnyvale, CA 94089, USA	
mél :dpendarakis@tellium.com 	mél : braja@tellium.com 	mél : yakov@juniper.net 	

Debanjan Saha (Tellium)	Vishal Sharma (Metanoia)	George Swallow (Cisco)	
2 Crescent Place, P.O. Box 901	335 Elan Village Lane	250 Apollo Drive	
Oceanport, NJ 07757-0901, USA	San Jose, CA 95134, USA	Chelmsford, MA 01824, USA	
mél : dsaha@tellium.com 	mél : vsharma87@yahoo.com 	mél : swallow@cisco.com 	

Z. Bo Tang (Tellium)	Eve Varma (Lucent)	Yangguang Xu (Lucent)	
2 Crescent Place, P.O. Box 901	101 Crawfords Corner Rd	21-2A41, 1600 Osgood Street	
Oceanport, NJ 07757-0901, USA	Holmdel, NJ  07733-3030, USA	North Andover, MA 01845, USA	
mél : btang@tellium.com 	mél : evarma@lucent.com 	mél : xuyg@lucent.com 	

 	Appendice 1.	Extension de valeurs de type de signal pour VC-3

Cet appendice définit la valeur de type de signal supplémentaire facultatif pour le champ Type de signal du paragraphe 2.1 :

Valeur	Type
20	"VC-3 via AU-3 à la fin"

Conformément à la Recommandation UIT-T [G.707], un VC-3 dans la branche TU-3/TUG-3/VC-4/AU-4 du multiplex SDH ne peut pas être structuré en TUG-2 ; cependant, un VC-3 dans la branche AU-3 le peut. De plus, un VC-3 pourrait être commuté entre les deux branches, si nécessaire.

Un circuit VC-3 pourrait être terminé sur une interface de sortie d'un LSR (par exemple, en formant une adjacence de transmission VC-3). Ce LSR pourrait alors vouloir démultiplexer ce VC-3 et commuter les LSP internes d'ordre inférieur. Pour des raisons de mise en œuvre, cela pourrait n'être seulement possible que si le LSR reçoit le VC-3 dans la branche AU-3. Par exemple, pour un LSR qui n'est pas capable de commuter en interne d'une branche TU-3 à une branche AU-3 sur son interface entrante avant de démultiplexer et ensuite de commuter le contenu avec son moteur de commutation.

Dans ce cas, il est utile d'indiquer que le LSP VC-3 doit être terminé à la fin de la branche AU-3 au lieu de la branche TU-3.

Ceci est réalisé en utilisant le type de signal "VC-3 via AU-3 à la fin". Cette information peut être utilisée, par exemple, par l'avant dernier LSR à commuter un VC-3 entrant reçu dans toute branche sur la branche AU-3 de l'interface sortante au LSR de destination.

Le type de signal "VC-3 via AU-3 à la fin" n'implique pas que le VC-3 doit être commuté via la branche AU-3 à d'autre point du réseau. Le type de signal VC-3 indique juste qu'un VC-3 dans une branche quelconque est convenable.

Exemples :

Cette annexe définit des exemples de codage de signal SONET et SDH. L'objectif est d'aider le lecteur à comprendre comment fonctionne le codage de paramètre de trafic et non de donner des exemples de signaux SONET ou SDH typiques.

Comme déclaré précédemment, les types de signaux sont des signaux élémentaires auxquels des transformations successives d'enchaînement, multiplication, et transparence peuvent être appliquées pour obtenir les signaux finaux.

1.	Un signal VC-4 signal est formé par l'application de RCC avec la valeur 0, NCC avec la valeur 0, NVC avec la valeur 0, MT avec la valeur 1, et T avec la valeur 0 à un signal élémentaire VC-4.

2.	Un signal VC-4-7v est formé par l'application de RCC avec la valeur 0, NCC avec la valeur 0, NVC avec la valeur 7 (enchaînement virtuel de 7 composants) MT avec la valeur 1, et T avec la valeur 0 à un signal élémentaire VC-4.

3.	Un signal VC-4-16c est formé par l'application de RCC avec la valeur 1 (enchaînement standard contigu) NCC avec la valeur 16, NVC avec la valeur 0, MT avec la valeur 1, et T avec la valeur 0 à un signal élémentaire VC-4.

4.	Un signal STM-16 avec transparence de la couche Section de multiplexage est formé par l'application de RCC avec la valeur 0, NCC avec la valeur 0, NVC avec la valeur 0, MT avec la valeur 1, et T avec le fanion 2 à un signal élémentaire STM-16.

5. 	Un signal STM-4 avec transparence de la couche Section de multiplexage est formé par l'application de RCC avec la valeur 0, NCC avec la valeur 0, NVC avec la valeur 0, MT avec la valeur 1, et T avec le fanion 2 appliqué à un signal élémentaire STM-4.

6.	Un signal STM-256 avec transparence de la couche Section de multiplexage est formé par l'application de RCC avec la valeur 0, NCC avec la valeur 0, NVC avec la valeur 0, MT avec la valeur 1, et T avec le fanion 2 appliqué à un signal élémentaire STM-256.

7.	Un signal SPE STS-1 est formé par l'application de RCC avec la valeur 0, NCC avec la valeur 0, NVC avec la valeur 0, MT avec la valeur 1, et T avec la valeur 0 à un signal élémentaire SPE STS-1.

8.	Un signal SPE STS-3c est formé par l'application de RCC avec la valeur 1 (enchaînement contigu standard) NCC avec la valeur 1, NVC avec la valeur 0, MT avec la valeur 1, et T avec la valeur 0 à un signal élémentaire SPE STS-3c.

9.	Un signal SPE STS-48c est formé par l'application de RCC avec la valeur 1 (enchaînement contigu standard) NCC avec la valeur 16, NVC avec la valeur 0, MT avec la valeur 1, et T avec la valeur 0 à un signal élémentaire SPE STS-3c.

10.	Un signal SPE STS-1-3v est formé par l'application de RCC avec la valeur 0, NVC avec la valeur 3 (enchaînement virtuel de 3 composants) MT avec la valeur 1, et T avec la valeur 0 à un signal élémentaire SPE STS-1.

11	Un signal SPE STS-3c-9v est formé par l'application de RCC avec la valeur 1, NCC avec la valeur 1, NVC avec la valeur 9 (enchaînement virtuel de 9 STS-3c) MT avec la valeur 1, et T avec la valeur 0 à un signal élémentaire SPE STS-3c.

12.	Un signal STS-12 avec transparence de couche Section (pleine) est formé par l'application de RCC avec la valeur 0, NCC avec la valeur 0, NVC avec la valeur 0, MT avec la valeur 1, et T avec le fanion 1 à un signal élémentaire STS-12.

13.	Un signal SPE 3 x STS-768c est formé par l'application de RCC avec la valeur 1, NCC avec la valeur 256, NVC avec la valeur 0, MT avec la valeur 3, et T avec la valeur 0 à un signal élémentaire SPE STS-3c.

14.	Un signal composé 5 x VC-4-13v est formé par l'application de RCC avec la valeur 0, NVC avec la valeur 13, MT avec la valeur 5, et T avec la valeur 0 à un signal élémentaire VC-4.

Le codage de ces exemples est résumé dans le tableau suivant :

Signal	ST	RCC	NCC	NVC	MT	T
VC-4 	6	0	0	0	1	0
VC-4-7v	6	0	0	7	1	0
VC-4-16c	6	1	16	0	1	0
STM-16 MS transparent	10	0	0	0	1	2
STM-4 MS transparent	9	0	0	0	1	2
STM-256 MS transparent	12	0	0	0	1	2
SPE STS-1	5	0	0	0	1	0
SPE STS-3c	6	1	1	0	1	0
SPE STS-48c	6	1	16	0	1	0
SPE STS-1-3v	5	0	0	3	1	0
SPE STS-3c-9v	6	1	1	9	1	0
STS-12 Section transparent	9	0	0	0	1	1
SPE 3 x STS-768c	6	1	256	0	3	0
5 x VC-4-13v	6	0	0	13	5	0

 	Références normatives

[G.707]	Recommandation UIT-T G.707, "Interface de nœud réseau pour la hiérarchie numérique synchrone (SDH)", octobre 2000.

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

[RFC2205]	R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ par RFC2750, RFC3936, RFC4495, RFC6780)) (P.S.)

[RFC2210]	J. Wroclawski, "Utilisation de RSVP avec les services intégrés de l'IETF", septembre 1997. (P.S.)

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

[RFC3945]	E. Mannie, éd., "Architecture de commutation d'étiquettes multi-protocoles généralisée (GMPLS)", octobre 2004. (P.S.)

[T1.105]	"Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, and Formats", ANSI T1.105, octobre 2000.

 	Adresse des auteurs
Eric Mannie	Dimitri Papadimitriou	
Perceval	Alcatel	
Rue Tenbosch, 9	Copernicuslaan 50	
1000 Brussels	B-2018 Antwerpen, Belgique	
Belgique	téléphone : +32 3 240-8491	
téléphone : +32-2-6409194	mél : dimitri.papadimitriou@alcatel.be	
mél : eric.mannie@perceval.net 		

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

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 encloses ne viole 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 fourni par l'activité de soutien administratif (IASA) de l'IETF.