Groupe de travail Réseau	D. Papadimitriou, éditeur, Alcatel	
Request for Comments : 4328		
RFC mise à jour : 3471	janvier 2006	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Extensions de signalisation à la commutation 
d'étiquettes multi-protocoles généralisée (GMPLS) 
pour le contrôle de réseau de transport optique G.709

Statut de ce mémoire
Le présent document spécifie un protocole de l’Interne en cours de normalisationt 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 (2006).

Résumé
Le présent document accompagne les documents de signalisation de la commutation d'étiquettes multi protocoles généralisée (GMPLS, Generalized Multi-Protocol Label Switching). Il décrit les informations spécifiques de la technologie nécessaires pour étendre la signalisation GMPLS au contrôle des réseaux de transport optiques (OTN, Optical Transport Network) ; il inclut aussi ce qu'on appelle les développements pré OTN.
Table des matières
1. Introduction	1
1.1 Conventions utilisées dans le document	2
2. Extensions à GMPLS pour G.709 - généralités	2
3. Demande d'étiquete généralisée	3
3.1 Partie commune	3
3.2 Paramètres de trafic G.709	5
4. Étiquette généralisée	6
4.1 Espace d'étiquette ODUk	7
4.2 Règles de distribution d'étiquettes	8
4.3 Espace d'étiquette de canal optique	8
5. Exemples	9
6. Extensions au protocole de signalisation RSVP-TE	9
7. Considérations sur la sécurité	10
8. Considérations relatives à l'IANA	10
9. Remerciements	11
10. Références	11
10.1 Références normatives	11
10.2 Références pour information	11
11. Contributeurs	12
Appendice A. Abréviations	12
Appendice B. Indices G.709	13
Adresse de l'éditeur	13
Déclaration complète de droits de reproduction	13
 	1.	Introduction

La commutation d'étiquettes multi protocoles généralisée (GMPLS, Generalized Multi-Protocol Label Switching) [RFC3945] étend MPLS de la prise en charge d'interfaces et de commutateurs à capacité de commutation de paquets (PSC, Packet Switching Capable) pour y inclure la prise en charge de quatre nouvelles classes d'interfaces et commutateurs : à capacité de commutation de couche 2 (L2SC, couche-2 Switching Capable), multiplexage à division temporelle (TDM, Time-Division Multiplex), à capacité de commutation lambda (LSC, Lambda Switch Capable), et à capacité de commutation optique (FSC, Fiber-Switch Capable). Une description fonctionnelle des extensions à la signalisation MPLS qui sont nécessaires pour prendre en charge ces 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 quatre classes d'interfaces.

Le présent document présente les détails de la technologie qui sont spécifiques des réseaux de transport optique (OTN, Optical Transport Network) G.709 comme spécifié dans la Recommandation UIT-T G.709 [G709] (et les documents référencés) incluant les développements pré OTN. Selon la [RFC3471], les paramètres spécifiques de la technologie de G.709 sont portés à travers le protocole de signalisation dans des objets de paramètres de trafic dédiés.

Les paramètres de trafic G.709 définis ci-après (paragraphe 3.2) DOIVENT être utilisés quand l'étiquette est codée comme défini dans le présent document. De plus, l'étiquette DOIT être codée comme défini à la Section 4 quand ces paramètres de trafic G.709 sont utilisés.

Dans le contexte du présent mémoire, par "développements pré OTN", on se réfère aux solutions de canal optique, d'enveloppe numérique et de correction d'erreur directe (FEC, Forward Error Correction) qui ne sont pas totalement conformes à G.709. Les détails concernant les solutions pré OTN fondées sur la hiérarchie numérique synchrone (SDH, Synchronous Digital Hierarchy) et le réseau optique synchrone (SONET, Synchronous Optical Network) incluant la redondance de section (SOH, Section OverHead) le régénérateur de redondance de section (RSOH, Regenerator Section OverHead) la transparence de la redondance de ligne (LOH, Line overhead) et la redondance de section de multiplexage (MSOH, Multiplex Section overhead) sont couverts dans la [RFC3946].

*** Note sur la Recommendation UIT-T G.709 ***
Les aspects de la Recommandation UIT-T G.709 sur les OTN présentés dans ce document se restreignent intentionnellement à la perspective de GMPLS dans le contexte du groupe de travail CCAMP de l'IETF. Donc, l'objectif du présent document n'est pas de dupliquer le contenu des Recommandations UIT-T sur les OTN. Les lecteurs intéressés par les détails concernant les technologies correspondantes sont donc invités à consulter les documents correspondants de l'UIT-T (référencés dans le présent mémoire).

 	1.1	Conventions utilisées dans le document
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 utilisée dans [G709], ainsi que dans les [RFC3471] et [RFC3473]. Les abréviations utilisées dans le présent document sont récapitulées à l'Appendice 1.

 	2.	Extensions à GMPLS pour G.709 - généralités

[G709] définit plusieurs couches de réseautage qui constituent la hiérarchie de transport optique :
-	avec pleines fonctionnalités :
- section de transmission optique (OTS, Optical Transmission Section)
- section de multiplexage optique (OMS, Optical Multiplex Section)
- canal optique (OCh, Optical Channel)
-	avec fonctionnalités réduites :
- section physique optique (OPS, Optical Physical Section)
- canal optique avec fonctionnalité réduite (OChr, Optical Channel with reduced functionality)

Il définit aussi deux couches constituant la hiérarchie de transport numérique :
-	unité de transport de canal optique (OTUk, Optical Channel Transport Unit)
-	unité de données de canal optique (ODUk, Optical Channel Data Unit)

Cependant, seules les couches OCh et ODUk sont définies comme couches de commutation. Les deux couches OCh (mais pas OChr) et ODUk incluent la redondance pour la supervision et la gestion. La redondance d'OCh est transportée de façon non associée (aussi appelée la redondance non associée (naOH, non-associated overhead) dans le signal de redondance du module de transport optique (OTM, Optical Transport Module) (OOS, OTM Overhead Signal)) avec la redondance non associée d'OTS et d'OMS. L'OOS est transportée via une longueur d'onde dédiée, appelée le canal de supervision optique (OSC, Optical Supervisory Channel). On remarquera que la naOH n'est spécifiée que fonctionnellement et à ce titre, est ouverte à des solutions spécifiques de fabricants. La redondance ODUk est transportée de façon associée au titre de la trame numérique ODUk.

Comme décrit dans [G709], en plus de la prise en charge de la transposition de ODUk en OTUk (k = 1, 2, 3), G.709 prend en charge le multiplexage d'ODUk. Elle se réfère au multiplexage de ODUj (j = 1, 2) en un signal ODUk (k > j) en particulier :
- multiplexage de ODU1 en ODU2 
- multiplexage de ODU1 en ODU3
- multiplexage de ODU2 en ODU3
- multiplexage de ODU1 et ODU2 en ODU3

On peut réaliser l'adaptation de GMPLS pour contrôler l'OTN G.709 en créant :
- une couche de chemin numérique, en étendant l'enveloppe numérique précédemment définie dans la [RFC3471] correspondant à la couche de chemin ODUk (numérique) ;
- une couche de chemin optique, en étendant le concept "Lambda" (défini dans la [RFC3471]) à la couche de chemin OCh (optique) ;
- une structure d'espace d'étiquettes, en considérant une arborescence dont la racine est un signal OTUk et les feuilles les signaux ODUj (k ≥ j) ; cela permet l'identification de la position exacte d'un signal ODUj particulier dans une structure de multiplexage ODUk.

Donc, les extensions de signalisation GMPLS pour G.709 doivent couvrir la demande d'étiquette généralisée, l'étiquette généralisée ainsi que les objets dépendants de la technologie spécifique inclus dans les paramètres de trafic, comme spécifié dans la [RFC3946] pour les réseaux SONET/SDH. De plus, comme le multiplexage dans le domaine numérique (comme le multiplexage ODUk) a été spécifié dans la version amendée de la Recommandation UIT-T G.709 (octobre 2001) le présent document propose aussi une définition d'espace d'étiquettes convenable pour ce faire. On remarquera aussi qu'on utilise les couches ODUk (c'est-à-dire, chemin numérique) et OCh (c'est-à-dire, chemin optique) G.709 directement afin de définir les espaces d'étiquettes correspondants.

 	3.	Demande d'étiquete généralisée

Le demande d'étiquette généralisée, comme définie dans la [RFC3471], comporte une partie commune (c'est-à-dire, utilisée pour toutes les technologies de commutation) et une partie qui dépend de la technologie (c'est-à-dire, les paramètres de trafic). Dans cette section, les deux parties sont étendues pour adapter la signalisation GMPLS à la recommandation du plan de transport de G.709 (voir [G709]).

 	3.1	Partie commune
Comme défini dans la [RFC3471], le type de codage de LSP, le type de commutation et l'identifiant de protocole généralisé (PID généralisé) constituent la partie commune de la demande d'étiquette généralisée. Le codage de l'objet RSVP-TE GENERALIZED_LABEL_REQUEST est spécifié au paragraphe 2.1 de la [RFC3473].

Comme mentionné plus haut, le présent document étend le type de codage de LSP, le type de commutation et les valeurs de G-PID (PID généralisé) pour s'accommoder de la Recommandation [G709].

 	3.1.1	Type de codage de LSP
Parce que la Recommandation G.709 définit deux couches de réseautage (les couches ODUk et OCh) les codets Type de codage de LSP peuvent refléter ces deux couches définies au paragraphe 3.1 de la [RFC3471] comme les codes "Enveloppe numérique" et "Lambda". Le type de codage de LSP est spécifié selon la couche de réseautage, ou plus précisément, par groupe de couches fonctionnelles de réseautage : les couches ODUk et OCh.

Donc, il est défini un codet supplémentaire de type de codage de LSP pour la couche de chemin numérique G.709 ; il élargit le codet existant "Enveloppe numérique" défini dans la [RFC3471]. Le premier DOIT être généré quand l'interface ou tunnel sur lequel le trafic sera transmis prend en charge le codage de couche Chemin numérique conforme à G.709. Le dernier ne DOIT être utilisé que pour le codage de couche Enveloppe numérique non conforme à G.709. Un nœud de transit ou de sortie (recevant un message Path contenant un objet GENERALIZED_LABEL_REQUEST) DOIT générer un message PathErr avec une indication "problème d'acheminement/codage non pris en charge", si le type de codage de LSP demandé ne peut pas être pris en charge sur l'interface entrante correspondante.

De la même façon est défini un codet supplémentaire de type de codage de LSP pour la couche Canal optique de G.709 ; il élargit le codet "Lambda" existant défini dans la [RFC3471]. Le premier DOIT être généré quand l'interface ou tunnel sur lequel le trafic sera transmis prend en charge le codage de couche de canal optique conforme à G.709. Le dernier DOIT être utilisé seulement pour le codage de couche Lambda non conforme à G.709. Un nœud de transit ou de sortie (recevant un message Path qui contient un objet GENERALIZED_LABEL_REQUEST) DOIT générer un message PathErr avec une indication "problème d'acheminement/codage non pris en charge", si le type de codage de LSP demandé ne peut être pris en charge sur l'interface entrante correspondante.

Par conséquent, les codets supplémentaires suivants sont définis pour le type de codage de LSP :

Valeur	Type
12	ODUk G.709 (chemin numérique)
13	Canal optique G.709

De plus, le codet pour la couche Canal optique G.709 (OCh) va indiquer la capacité demandée à un système d'extrémité pour utiliser la redondance G.709 non associée (naOH), c'est-à-dire, le signal de  redondance OTM (OOS) multiplexé dans le signal d'interface OTM-n.m.

 	3.1.2	Type de commutation
Le type de commutation indique le type de commutation qui devrait être effectuée à la terminaison d'une certaine liaison (voir la [RFC4202]).

Aucune valeur supplémentaire de type de commutation n'est à envisager pour s'accommoder des types de commutation de G.709, parce que un commutateur ODUk (et donc les LSP) appartient à la classe TDM, tandis qu'un commutateur OCh (et donc les LSP) appartient à la classe Lambda (c'est-à-dire, LSC).

Les nœuds intermédiaires et de sortie DOIVENT vérifier que la valeur indiquée dans le champ Type de commutation est pris en charge sur l'interface entrante correspondante. Si la valeur requise ne peut pas être prise en charge, le nœud DOIT générer un message PathErr avec une indication "problème d'acheminement/type de commutation".

 	3.1.3	PID généralisé (G-PID)
Le G-PID (champ de 16 bits) défini dans la [RFC3471], identifie la charge utile portée par un LSP, c'est-à-dire, un identifiant de la couche client de ce LSP. Cet identifiant est utilisé par les points d'extrémité du LSP G.709.

Le G-PID peut prendre une des valeurs suivantes quand la charge utile du client est transportée sur la couche Chemin numérique, en plus des identifiants de charge utile définis dans la [RFC3471] :
- CBRa : débit binaire asynchrone constant (c'est-à-dire, transposition de STM-16/OC- 48, STM-64/OC-192 et STM-256/OC-768)
- CBRb : débit binaire constant de bits synchrones (c'est-à-dire, transposition de STM-16/OC-48, STM-64/OC-192 et STM-256/OC-768)
- ATM : transposition à 2,5, 10 et 40 Gbit/s
- BSOT: flux binaire non spécifique du client avec synchronisation d'octet (c'est-à-dire, transposition de flux binaire à 2,5, 10 et 40 Gbit/s)
- BSNT : flux binaire non spécifique du client sans synchronisation d'octet (c'est-à-dire, transposition de flux binaire à 2,5, 10 et 40 Gbit/s)
- ODUk : transport de chemins numériques à 2,5, 10 et 40 Gbit/s
- ESCON : connexion de systèmes d'entreprise
- FICON : connexion en fibre optique

Le G-PID peut prendre une des valeurs suivantes quand la charge utile de client est transportée sur la couche Canal optique, en plus des identitifants de charge utile définis dans la [RFC3471] :
- CBR (Constant Bit Rate) : débit binaire constant (c'est-à-dire, transposition de STM-16/OC-48, STM-64/OC-192 et STM-256/OC-768)
- OTUk/OTUkV : transport de section numérique à 2,5, 10 et 40 Gbit/s

Aussi, quand des charges utiles de client comme Ethernet MAC/PHY et IP/PPP sont encapsulées au moyen de la procédure de tramage générique (GFP, Generic Framing Procedure), comme décrite dans la Recommandation UIT-T G.7041, des valeurs de G-PID dédiées sont définies.

Afin d'inclure les développements pré OTN, le champ G-PID peut prendre une des valeurs (actuellement définies dans la [RFC3471]) quand les charges utiles de client suivantes sont transportées sur un LSP lambda :
- Ethernet PHY (1 Gbit/s et 10 Gbit/s)
- Canal fibre

Le tableau suivant résume les G-PID par rapport au type de codage de LSP :

Valeur	Type G-PID	Type de codage de LSP
47	G.709 ODUj	ODUk G.709 (avec k > j)
48	G.709 OTUk(v)	ODUk OCh G.709 transposé en OTUk(v)
49	CBR/CBRa	ODUk G.709, OCh G.709
50	CBRb	ODUk G.709
51	BSOT	ODUk G.709
52	BSNT	ODUk G.709
53	IP/PPP (GFP)	ODUk G.709 (et SDH)
54	MAC Ethernet (GFP tramé)	ODUk G.709 (et SDH)
55	PHY Ethernet (GFP transparent)	ODUk G.709 (et SDH)
56	ESCON	ODUk G.709, Lambda, Fibre
57	FICON	ODUk G.709, Lambda, Fibre
58	Canal fibre	ODUk G.709, Lambda, Fibre

Note : les valeurs 49 et 50 incluent la transposition de la SDH.

Le tableau suivant résume la mise à jour des valeurs de G-PID définies dans la [RFC3471] :

Valeur	Type de G-PID	Type de codage de LSP
32	Transposition ATM	SDH, ODUk G.709
33	Ethernet PHY	SDH, OCh G.709, Lambda, Fibre
34	Sonet/SDH	OCh G.709, Lambda, Fibre
35	Réservé (SONET Dep.)	OCh G.709, Lambda, Fibre

 	3.2	Paramètres de trafic G.709
Quand la couche Chemin numérique ou Canal optique G.709 est spécifiée dans le champ Type de codage de LSP, les informations référencées comme dépendantes de la technologie (ou simplement les paramètres de trafic) sont portées en plus de celles incluses dans la demande d'étiquette généralisée.

Les paramètres de trafic G.709 sont définis 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|   Réservé     |              NMC              |
+---------------+---------------+---------------+---------------+
|              NVC              |        Multiplicateur (MT)    |
+---------------+---------------+---------------+---------------+
|                           Réservé                             |
+---------------+---------------+---------------+---------------+

Dans cette trame, NMC est l'abrégé de "nombre de composants multiplexés", NVC de "nombre de composants virtuels", et MT "multiplicateur". Chacun de ces champs est dessiné pour prendre en charge les demandes de LSP G.709.

Le codage RSVP-TE des paramètres de trafic G.709 est détaillé à la Section 6.

 	3.2.1	Type de signal (ST)
Ce champ (8 bits) indique le type de signal élémentaire G.709 qui comporte le LSP demandé. Les valeurs permises sont :

Valeur	Type
0	non significatif
1	ODU1 (c'est-à-dire, 2.5 Gbit/s)
2	ODU2 (c'est-à-dire, 10  Gbit/s)
3	ODU3 (c'est-à-dire, 40  Gbit/s)
4	réservé (pour utilisation future)
5	réservé (pour utilisation future)
6	OCh à 2,5 Gbit/s
7	OCh à 10 Gbit/s
8	OCh à 40 Gbit/s
9-255	réservé (pour utilisation future )

La valeur du champ Type de signal dépend de la valeur du type de codage de LSP définie au paragraphe 3.1.1 et dans la [RFC3471] :
- si la valeur de type de codage de LSP est la couche Chemin numérique G.709, les valeurs valides sont les signaux ODUk (k = 1, 2 ou 3) ;
- si la valeur du type de codage de LSP est la couche Canal optique G.709, les valeurs valides sont alors le OCh à 2,5, 10, ou 40 Gbit/s ;
- si le type de codage de LSP est "Lambda" (ce qui inclut la couche Canal optique pré OTN) la valeur valide n'est pas pertinente (type de signal = 0) ;
- si le type de codage de LSP est "Enveloppe numérique", la valeur valide n'est alors pas pertinente (Type de signal = 0).

Plusieurs transformations peuvent être appliquées en séquence sur le signal élémentaire pour construire de signal final qui est effectivement demandé pour le LSP. Chaque application de transformation est facultative et doit être ignorée si elle est zéro ; cela n'inclut pas le multiplicateur (MT), qui ne peut pas être zéro et doit être ignoré si il est égal à un. Les transformations doivent être appliquées strictement dans l'ordre suivant :
- D'abord, un enchaînement virtuel (en utilisant le champ NVC) peut être facultativement appliqué directement sur le signal élémentaire pour former un signal composé ;
- Ensuite, une multiplication (en utilisant le champ Multiplicateur) peut être facultativement appliquée soit directement sur le signal élémentaire, soit sur le signal virtuellement enchaîné obtenu de la première phase. Le signal résultant est appelé le signal final.

 	3.2.2	Nombre de composants multiplexés (NMC)
Le champ NMC (16 bits) indique le nombre de créneaux ODU tributaires utilisés par un ODUj quand il est multiplexé dans un ODUk (k > j) pour le LSP demandé. Ce champ n'est pas applicable quand un ODUk est transposé dans un OTUk et n'est pas pertinent à la couche Canal optique. Dans les deux cas, il DOIT être réglé à zéro (NMC = 0) à l'envoi et devrait être ignoré en réception.

Quand il est appliqué à la couche Chemin numérique, en particulier pour les connexions ODU2 multiplexées dans une charge utile ODU3, le champ NMC spécifie le nombre de créneaux individuels tributaires (NMC = 4) qui constituent la connexion demandée. Ces componsants sont quand même traités dans le contexte d'une seule entité de connexion. Pour tous les autres cas de multiplexage actuellement définis (voir la Section 2) le champ NMC est réglé à 1.

 	3.2.3	Nombre de composants virtuels (NVC)
Le champ NVC (16 bits) est dédié aux besoins de l'enchaînement virtuel d'ODUk (c'est-à-dire, au multiplexage inverse d'ODUk). Il indique le nombre de signaux élémentaires ODU1, ODU2, ou ODU3 qui sont demandés pour être virtuellement enchaînés pour former un signal ODUk-Xv. Par définition, ces signaux DOIVENT être du même type.

Ce champ est réglé à "valeur par défaut" pour indiquer qu'aucun enchaînement virtuel n'est demandé.

Noter que l'usage courant de ce champ ne s'applique qu'aux LSP G.709 ODUk, c'est-à-dire, les valeurs supérieures à zéro, ne sont acceptables que pour le type de signal ODUk. Donc, il DOIT être réglé à zéro (NVC = 0), et devrait être ignoré à réception, quand un LSP OCh G.709 est demandé.

 	3.2.4	Multiplicateur (MT)
Le champ Multiplicateur (16 bits) indique le nombre de signaux élémentaires ou de signaux composés identiques qui est demandé pour le LSP, c'est-à-dire, pour former le signal final. Un signal composé est le signal résultant de l'application des champs NMC et NVC à un type de signal élémentaire. La signalisation GMPLS impliqe actuellement que tous les signaux composés fassent partie du même LSP.

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 (voir la Section 6).

Zéro est une valeur invalide pour le champ MT. Si elle est reçue, le nœud DOIT générer un message PathErr (voir la Section 6).

 	3.2.5	Champs réservés
Les champs réservés (8 bits dans la rangée 1 et 32 bits dans la rangée 3) sont dédiés à une utilisation future. Les bits réservés DEVRAIENT être réglés à zéro à l'envoi et DOIVENT être ignorés à réception.

 	4.	Étiquette généralisée

Cette section décrit l'espace de valeurs de l'étiquette généralisée pour les chemins numériques et les canaux optiques. L'étiquette généralisée est définie dans la [RFC3471]. Le format de l'objet RSVP-TE correspondant GENERALIZED_LABEL est spécifié au paragraphe 2.3 de la [RFC3473].

Les règles de distribution d'étiquette détaillées au paragraphe 4.2 suivent (lorsque applicables) celles définies dans la [RFC3946].

 	4.1	Espace d'étiquette ODUk
À la couche Chemin numérique (c'est-à-dire, les couches ODUk) G.709 définit trois débits binaires différents de charge utile de client. Une trame d'unité de données optique (ODU, Optical Data Unit) a été définie pour chacun de ces débits binaires. ODUk se réfère à la trame au débit binaire k, où k = 1 (pour 2,5 Gbit/s), 2 (pour 10 Gbit/s), ou 3 (pour 40 Gbit/s).

En plus de la prise en charge de la transposition d'ODUk en OTUk, l'espace d'étiquette G.709 prend en charge les sous niveaux du multiplexage ODUk. Le multiplexage ODUk se réfère au multiplexage de ODUj (j = 1, 2) en un ODUk (k > j), en particulier :
- multiplexage ODU1 en ODU2
- multiplexage ODU1 en ODU3
- multiplexage ODU2 en ODU3
- multiplexage ODU1 et ODU2 en ODU3

Plus précisément, le multiplexage ODUj en ODUk (k > j) est défini quand un ODUj est multiplexé en un groupe d'unités tributaires d'ODUk (c'est-à-dire, un ODTUG constituté par des créneaux tributaires d'ODU) qui est transposé en un OPUk. L'OPUk résultant est transposé en un ODUk, et l'ODUk est transposé en un OTUk.

Donc, la structure d'espace d'étiquettes est une arborescence dont la racine est un signal OTUk et dont les feuilles sont les signaux ODUj (k ≥ j) qui peuvent être transportés via les créneaux tributaires et commutés entre ces créneaux. Une étiquette de couche Chemin numérique G.709 identifie la position exacte d'un signal ODUj particulier dans une structure de multiplexage ODUk.

L'étiquette de couche Chemin numérique G.709 ou étiquette ODUk 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Réservé                 |    t3     | t2 |t1|
+---------------+---------------+-----------+---+---------------+

Les bits réservés DOIVENT être réglés à zéro à l'envoi et DEVRAIENT être ignorés à réception.

La spécification des champs t1, t2, et t3 caractérise l'espace d'étiquettes ODUk. L'espace de valeurs pour les champs t1, t2, et t3 est définie comme suit :
1. t1 (1 bit) :
- t1 = 1 indique un signal ODU1.
- t1 n'est pas significatif pour les autres types de signal ODUk (c'est-à-dire, la valeur t1 DOIT être réglée à 0 et ignorée).

2. t2 (3 bits) :
- t2 = 1 indique un signal ODU2 qui n'a pas d'autre subdivision.
- t2 = [2..5] indique le créneau tributaire (t2ème-2) utilisé par l'ODU1 dans un ODTUG2 transposé en un ODU2 (via OPU2).
- t2 n'est pas significatif pour un ODU3 (c'est-à-dire, la valeur t2 DOIT être réglée à 0 et ignorée).

3. t3 (6 bits) :
- t3 = 1 indique un signal ODU3 qui n'a pas d'autre subdivision.
- t3 = [2..17] indique le créneau tributaire (t3ème-1) utilisé par l'ODU1 dans un ODTUG3 transposé en un ODU3 (via OPU3).
- t3 = [18..33] indique le créneau tributaire (t3ème-17) utilisé par le ODU2 dans un ODTUG3 transposé en un ODU3 (via OPU3).

Note : dans le cas de multiplexage de ODU2 dans ODU3, quatre  étiquettes sont requises pour identifier les quatre créneaux tributaires utilisés par l'ODU2 ; ces intervalle de temps tributaires doivent être alloués en ordre ascendant.

Si la valeur de sous champ d'étiquette t[i] = 1 (i, j = 1, 2 ou 3) et t[j] = 0 (j > i), le signal ODUk correspondant ODU[i] est directement transposé en le signal OTUk (k = i) correspondant. Ceci est appelé la transposition d'un signal ODUk en un OTUk de même ordre. Donc, la numérotation commence à 1 ; zéro est utilisé pour indiquer un champ non significatif. Un champ d'étiquette égal à zéro est une valeur invalide.

Exemples :

- t3 = 0, t2 = 0, t1 = 1 indique un ODU1 transposé en un OTU1
- t3 = 0, t2 = 1, t1 = 0 indique un ODU2 transposé en un OTU2
- t3 = 1, t2 = 0, t1 = 0 indique un ODU3 transposé en un OTU3
- t3 = 0, t2 = 3, t1 = 0 indique le ODU1 dans le second créneau tributaire du ODTUG2 transposé en un ODU2 (via OPU2) transposé en un OTU2
- t3 = 5, t2 = 0, t1 = 0 indique le ODU1 dans le quatrième créneau tributaire du ODTUG3 transposé en un ODU3 (via OPU3) transposé en un OTU3

 	4.2	Règles de distribution d'étiquettes
Dans le cas d'une transposition de ODUk en OTUk, une seule étiquette peut apparaître dans l'étiquette généralisée. L'étiquette unique est codée comme une seule valeur d'étiquette de 32 bits (comme défini au paragraphe 4.1) de l'objet GENERALIZED_LABEL (Class-Num = 16, C-Type = 2).

Dans le cas du multiplexage de ODUj dans ODUk (k > j) la liste ordonnée explicite des étiquettes dans le multiplex est donnée (cette liste peut se restreindre à une seule étiquette quand NMC = 1). Chaque étiquette indique un composant (créneau tributaire ODUj) du signal multiplexé. L'ordre des étiquettes doit refléter l'ordre de l'ODUj dans le multiplex (pas l'ordre physique des créneaux tributaires). Cette liste ordonnée d'étiquettes est codée comme une séquence de valeurs d'étiquettes de 32 bits (comme défini au paragraphe 4.1) de l'objet GENERALIZED_LABEL (Class-Num = 16, C-Type = 2).

Dans le cas d'un enchaînement virtuel d'ODUk, la liste ordonnée explicite de toutes les étiquettes dans l'enchaînement est donnée. Chaque étiquette indique un composant du signal virtuellement enchaîné. L'ordre des étiquettes doit refléter l'ordre d'encahînement de l'ODUk (et non l'ordre physique des intervalles de temps). Cette représentation limite l'enchaînement virtuel à rester au sein d'une seule liaison (composante). Dans le cas de signaux multiplexés virtuellement enchaînés, le premier ensemble d'étiquettes indique les composants (créneaux tributaires d'ODUj) du premier signal virtuellement enchaîné, le second ensemble d'étiquettes indique les composants (créneaux tributaires d'ODUj) du second signal virtuellement enchaîné, et ainsi de suite. Cette liste ordonnée d'étiquettes est codée comme une séquence de valeurs d'étiquette de 32 bits (comme défini en 4.1) de l'objet GENERALIZED_LABEL (Class-Num = 16, C-Type = 2).
Dans le cas d'un enchaînement virtuel d'ODUk, le nombre de valeurs d'étiquettes est déterminé par la valeur de NVC. L'enchaînement virtuel d'ODUk multiplexé utilise en plus la valeur de NMC pour déterminer le nombre d'étiquettes par ensemble (égaux en taille).

Dans le cas de multiplication (c'est-à-dire, quand on utilise le champ MT) la liste explicitement ordonnée de toutes les étiquettes qui prennent part au signal composé est donnée. La représentation ci-dessus limite la multiplication à rester au sein d'une seule liaison (composante). En cas de multiplication de signaux multiplexés virtuellement enchaînés, le premier ensemble d'étiquettes indique les composants du premier signal multiplexé virtuellement enchaîné, le second ensemble d'étiquettes indique les composants du second signal multiplexé virtuellement enchaîné, et ainsi de suite. Cette liste ordonnée d'étiquettes est codée comme une séquence de valeurs d'étiquettes de 32 bits (comme défini au paragraphe 4.1) de l'objet GENERALIZED_LABEL (Class-Num = 16, C-Type = 2). En cas de multiplication de signaux (égaux) ODUk virtuels enchaînés, le nombre de valeurs d'étiquettes par signal est déterminé par la valeur de NVC. La multiplication d'enchaînements de ODUk multiplexés (égaux) virtuels utilise de plus la valeur de NMC pour déterminer le nombre d'étiquettes par ensemble (égaux en taille).

 	4.3	Espace d'étaiquette de canal optique
À la couche Canal optique, l'espace d'étiquettes doit être défini de façon cohérente comme un espace plat dont les valeurs reflètent l'allocation locale des identifiants d'OCh qui correspond aux signaux de sous interface OTM-n.m (m = 1, 2 ou 3). Noter que ces identifiants ne couvrent pas OChr parce que la fonction de connexion correspondante (OChr-CF) entre OTM-nr.m/OTM-0r.m n'est pas définie dans [G798].

Les valeurs d'espace d'étiquettes OCh sont définies par des valeurs absolues (c'est-à-dire, des identifiants de canal (Channel ID) aussi appelés des identifiants de longueur d'onde) ou par des valeurs relatives (espacement de canaux, aussi appelés espacement inter longueur d'onde). Ces dernières sont strictement confinées à un espace d'étiquettes par accès, tandis que les premières pourraient être définies comme un espace d'étiquettes local ou global (par nœud). Un tel espace d'étiquettes OCh est applicable aussi bien à la couche Canal optique OTN qu'à la couche et Canal optique pré OTN.

Les règles de codage d'étiquette de canal optique (et de distribution) sont définies dans la [RFC3471]. Elles DOIVENT être utilisées pour l'étiquette amont, l'étiquette suggérée, et l'étiquette généralisée.

 	5.	Exemples

Les exemples suivants sont données afin d'illustrer le traitement décrit dans les sections précédentes de ce document.

1. Transposition ODUk dans OTUk : quand un signal ODU1 (ODU2 ou ODU3) est directement transporté dans un OTU1 (OTU2 ou OTU3) le nœud amont demande les résultats simplement dans une demande de signal ODU1 (ODU2 ou ODU3).

Dans ces conditions, le nœud aval doit retourner une étiquette unique parce que le ODU1 (ODU2 ou ODU3) est directement transposé dans l'OTU1 (OTU2 ou OTU3) correspondant. Parce qu'un seul signal ODUk est demandé (type de signal = 1, 2 ou 3) le nœud aval doit retourner une seule étiquette ODUk, qui peut être, par exemple, une des suivantes quand le type de signal = 1 :
- t3 = 0, t2 = 0, t1 = 1 indiquant un seul ODU1 transposé dans un OTU1
- t3 = 0, t2 = 1, t1 = 0 indiquant un seul ODU2 transposé dans un OTU2
- t3 = 1, t2 = 0, t1 = 0 indiquant un seul ODU3 transposé dans un OTU3

2. Multiplexage de ODU1 dans ODUk (k > 1) : quand un ODU1 est multiplexé dans la charge utile d'un ODU2 (ou ODU3) structuré, le nœud amont demande les résultats simplement dans une demande de signal ODU1.

Dans ces conditions, le nœud aval doit retourner une étiquette unique parce que le ODU1 est multiplexé dans un ODTUG2 (ou ODTUG3). Ce dernier est ensuite transposé dans le ODU2 (ou ODU3) via OPU2 (ou OPU3) et ensuite transposé dans le OTU2 (ou OTU3) correspondant. Comme un seul signal ODU1 multiplexé est demandé (type de signal = 1 et NMC = 1) le nœud aval doit retourner une seule étiquette ODU1, qui peut prendre, par exemple, une des valeurs suivantes :
- t3 = 0, t2 = 4, t1 = 0 indique le ODU1 dans le troisième TS de l'ODTUG2
- t3 = 2, t2 = 0, t1 = 0 indique le ODU1 dans le premier TS de l'ODTUG3
- t3 = 7, t2 = 0, t1 = 0 indique l'ODU1 dans le sixième TS de l'ODTUG3

3. Multiplexage ODU2 dans ODU3 : quand un ODU2 non structuré est multiplexé dans la charge utile d'un ODU3 structuré, le nœud amont demande les résultats simplement dans une demande de signal ODU2.

Dans ces conditions, le nœud aval doit retourner quatre étiquettes car le ODU2 est multiplexé dans un ODTUG3. Ce dernier est transposé dans un ODU3 (via OPU3) et ensuite transposé dans un OTU3. Comme un signal multiplexé ODU2 est demandé (type de signal = 2, et NMC = 4) le nœud aval doit retourner quatre étiquettes ODU qui peuvent prendre, par exemple, les valeurs suivantes :
- t3 = 18, t2 = 0, t1 = 0 (première  partie de ODU2 dans le premier TS de ODTUG3)
- t3 = 22, t2 = 0, t1 = 0 (seconde partie de ODU2 dans le cinquième TS de ODTUG3)
- t3 = 23, t2 = 0, t1 = 0 (troisième partie de ODU2 dans le sixième TS de ODTUG3)
- t3 = 26, t2 = 0, t1 = 0 (quatrième partie de ODU2 dans le neuvième TS de ODTUG3)

4. Quand un seul signal OCh de 40 Gbit/s est demandé (type de signal = 8) le nœud aval doit retourner une seule étiquette de longueur d'onde comme spécifié dans la [RFC3471].

5. Quand on demande plusieurs LSP ODUk (c'est-à-dire, avec une valeur de multiplicateur (MT) > 1), une liste explicite d'étiquettes est retournée au nœud demandeur.

Quand le nœud aval reçoit une demande pour un signal 4 x ODU1 (type de signal = 1, NMC = 1 et MT = 4) multiplexé dans un ODU3, il retourne une liste ordonnée de quatre étiquettes au nœud amont : la première étiquette ODU1 correspond au premier signal du LSP, la seconde étiquette ODU1 correspond au second signal du LSP, etc. Par exemple, les étiquettes correspondantes peuvent prendre les valeurs suivantes :
- Premier ODU1 : t3 = 2, t2 = 0, t1 = 0 (dans le premier TS de ODTUG3)
- Second ODU1 : t3 = 10, t2 = 0, t1 = 0 (dans le neuvième TS de ODTUG3)
- Troisième ODU1 : t3 = 7, t2 = 0, t1 = 0 (dans le sixième TS de ODTUG3)
- Quatrième ODU1 : t3 = 6, t2 = 0, t1 = 0 (dans le cinquième TS de ODTUG3)

 	6.	Extensions au protocole de signalisation RSVP-TE

Cette section spécifie les extensions de protocole [RFC3473] nécessaires pour s'accommoder des paramètre de trafic G.709.

Les paramètres de trafic G.709 sont portés dans les objets G.709 SENDER_TSPEC et FLOWSPEC. Le même format est utilisé pour les deux objets SENDER_TSPEC et FLOWSPEC. Le contenu de ces objets est défini au paragraphe 3.2. Les objets ont la classe et le type suivants pour G.709 :
- Objet G.709 SENDER_TSPEC : Classe = 12, C-Type = 5
- Objet G.709 FLOWSPEC : Classe = 9, C-Type = 5

Il n'y a pas de Adspec associée au SENDER_TSPEC G.709. Soit la 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 certain envoyeur 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 prendre en charge les valeurs de type de signal, de NMC, et de NVC demandées (comme défini au paragraphe 3.2). Si 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 avec une indication "Erreur de contrôle de trafic/mauvaise valeur de Tspec" (voir la [RFC2205]).

 	7.	Considérations sur la sécurité

Le présent document n'introduit pas de nouvelles considérations de sécurité par rapport à la [RFC3473].

 	8.	Considérations relatives à l'IANA

Deux valeurs ont été définies par l'IANA pour le présent document :

Deux C-Types RSVP dans le registre http://www.iana.org/assignments/rsvp-parameters 
- Objet G.709 SENDER_TSPEC : Classe = 12, C-Type = 5 - voir la Section 6.
- Objet G.709 FLOWSPEC : Classe = 9, C-Type = 5 - voir la Section 6.

L'IANA va aussi enregistrer les espaces de codets étendus et/ou mis à jour par le présent document. À cette fin, les nouvelles entrées de registre ont été ajoutées dans les nouvelles demandes d'entrées du registre http://www.iana.org/assignments/gmpls-sig-parameters 

- Type de codage de LSP
Nom : Type de codage de LSP 
Format : nombre de huit bits
Valeurs :
1 à 11 : définies dans la [RFC3471]
12 : définie au paragraphe 3.1.1
13 : définie au paragraphe 3.1.1
Politique d'allocation :
0 à 239 : allouées par l'IANA via une RFC de l'IETF sur la voie de la normalisation
240 à 255 : allouées temporairement pour usage expérimental. Elles ne seront pas enregistrées par l'IANA.

- Type de commutation
Nom : Type de commutation
Format : nombre de 8 bits
Valeurs : définies dans la [RFC3471]
Politique d'allocation :
0 à 255 : allouées par l'IANA via une RFC de l'IETF sur la voie de la normalisation

- PID généralisé (G-PID) 
Nom : G-PID
Format : nombre de 16 bits
Valeurs :
0 à 31 : définies dans la [RFC3471]
32à 35 : définies dans la [RFC3471] et mises à jour par le paragraphe 3.1.3
36à 46 : définies dans la [RFC3471]
47à 58 : définies au paragraphe 3.1.3
Politique d'allocation :
0 à 31  743 : allouées par l'IANA via une RFC de l'IETF sur la voie de la normalisation.
31  744 à 32  767 : allouées temporairement pour usage expérimental.
32  768 à 65  535 : non allouées. Avant toute allocation dans cette gamme, il DOIT y avoir une RFC sur la voie de la normalisation qui spécifie des considérations relatives à l'IANA qui couvrent cette gamme.

Note : selon le paragraphe 3.1.1 de la [RFC3471], les valeurs standard d'Ethertype sont utilisées comme G-PID pour les LSP de paquet et Ethernet.

 	9.	Remerciements

Les auteurs tiennent à remercier Jean-Loup Ferrant, Mathieu Garnot, Massimo Canali, Germano Gasparini, et Fong Liaw de leurs commentaires constructifs et de leurs apports ainsi que James Fu, Siva Sankaranarayanan, et Yangguang Xu pour leurs utiles retours. Un grand merci à Adrian Farrel pour sa relecture attentive du présent document.

Le présent document incorpore (avec son accord) des matériaux et des idées provenant d'un travail en cours, "Common Label et Label Request Specification for Automatic Switched Transport Network", par Zhi Lin.

 	10.	Références
 	10.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)

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

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

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

[RFC3946]	E. Mannie, D. Papadimitriou, "Extensions de commutation d'étiquettes multi-protocoles généralisée (GMPLS) pour le contrôle de réseau optique synchrone (SONET) et de hiérarchie numérique synchrone (SDH)", octobre 2004. (Obsolète, voir RFC4606) (P.S.)

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

 	10.2	Références pour information

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

Des informations sur la disponibilité des documents qui suivent se trouvent à http://www.itu.int 

[G709]	Recommandation UIT-T G.709, "Interface pour le réseau de transport optique", février 2001 (et Amendement 1, octobre 2001).

[G798]	Recommandation UIT-T G.798, "Caractéristiques des blocs fonctionnels des équipements de la hiérarchie de réseau de transport optique", octobre 2001.

 	11.	Contributeurs

Alberto Bellato (Alcatel)	Sudheer Dharanikota 	Michele Fontana (Alcatel)	Nasir Ghani (Sorrento Networks)	
Via Trento 30,	(Consult)	Via Trento 30,	9990 Mesa Rim Road,	
I-20059 Vimercate, Italy	mél : sudheer@ieee.org 	I-20059 Vimercate, Italy	San Diego, CA 92121, USA	
mél : alberto.bellato@alcatel.it 		mél : michele.fontana@alcatel.it 	mél : nghani@sorrentonet.com 	

Gert Grammel (Alcatel)	Dan Guo (Turin Networks)	Juergen Heiles (Siemens)	
Lorenzstrasse, 10,	1415 N. McDowell Bvd,	Hofmannstr. 51,	
70435 Stuttgart, Germany	Petaluma, CA 94954, USA	D-81379 Munich, Germany	
mél : gert.grammel@alcatel.de 	mél : dguo@turinnetworks.com 	mél : juergen.heiles@siemens.com 	

Jim Jones (Alcatel)	Zhi-Wei Lin (Lucent)	Eric Mannie (Consult)	
3400 W. Plano Parkway,	101 Crawfords Corner Rd, Rm 3C-512	mél : eric_mannie@hotmail.com 	
Plano, TX 75075, USA	Holmdel, New Jersey 07733-3030, USA		
mél : jim.d.jones@alcatel.com 	mél : zwlin@lucent.com 		

Maarten Vissers (Alcatel)	Yong Xue (WorldCom)	
Lorenzstrasse, 10,	22001 Loudoun County Parkway,	
70435 Stuttgart, Germany	Ashburn, VA 20147, USA	
mél : maarten.vissers@alcalel.de 	mél : yong.xue@wcom.com 	

 	Appendice A.	Abréviations

BSNT (Bit Stream without Octet Timing) flux binaire sans synchronisation des octets
BSOT (Bit Stream with Octet Timing) flux binaire avec synchronisation des octets
CBR (Constant Bit Rate) = débit binaire constant
ESCON (Enterprise Systems Connection) = connexion de systèmes d'entreprise
FC (Fiber Channel) = canal fibre (optique)
FEC (Forward Error Correction) = correction d'erreur directe
FICON (Fiber Connection) = connexion optique
FSC (Fiber Switch Capable) = à capacité de commutation optique
GCC (General Communication Channel) = canal de communication général
GFP (generic framing procedure) = procédure générique de verrouillage de trames 
LSC (Lambda Switch Capable) = à capacité de commutation Lambda (par longueur d’onde) 
LSP (Label Switched Path) = chemin commuté par étiquettes
MS (Multiplex Section) = section de multiplexage
naOH (non-associated Overhead) = redondance non associée
NMC (Number of Multiplexed Components) = nombre de composants multiplexés
NVC (Number of Virtual Components) = nombre de composants virtuels
OCC (Optical Channel Carrier) =porteuse de canal optique
OCG (Optical Carrier Group) = groupe de porteuses optiques
OCh (Optical Channel (with full functionality)) = canal optique (à pleine capacité)
OChr (Optical Channel (with reduced functionality)) = canal optique (à capacité réduite)
ODTUG (Optical Data Tributary Unit Group) = groupe d'unités tributaires de données optiques
ODU (optical channel data unit) = unité de données de canal optique
OH (Overhead) = redondance
OMS (Optical Multiplex Section) = section de multiplexage optique
OMU (Optical Multiplex Unit) = unité multiplex optique
OOS (OTM Overhead Signal) = signal de redondance de module de transport optique
OPS (Optical Physical Section) = section physique optique
OPU (Optical Channel Payload Unit) = unité de charge utile de canal optique
OSC (Optical Supervisory Channel) = canal optique superviseur
OTH (optical transport hierarchy) = hiérarchie de transport optique
OTM (Optical Transport Module) = module de transport optique
OTN (optical transport network) = réseau de transport optique
OTS (Optical Transmission Section) = section de transmission optique
OTU (Optical Channel Transport Unit) = unité de transport de canal optique
OTUkV (Functionally Standardized OTUk) = OTUk fonctionnellement normalisé 
PPP (Point to Point Protocol) = protocole point à point
PSC (Packet Switch Capable) = à capacité de commutation par paquets
RES = réservé
RS (Regenerator Section) = section de régénération
TDM (Time Division Multiplex) = muliplexage temporel
TTI (Trail Trace Identifier) = identifiant de trace de chemin

 	Appendice B.	Indices G.709

- Indice k : l'indice "k" est utilisé pour représenter un débit binaire pris en charge et les différentes versions de OPUk, ODUk et OTUk. k = 1 représente un débit binaire approximatif de 2,5 Gbit/s ; k = 2 représente un débit binaire approximatif de 10 Gbit/s ; k = 3 un débit binaire approximatif de 40 Gbit/s et k = 4 un débit binaire approximatif de 160 Gbit/s (selon la définition). Les valeurs exactes de débit binaire sont, en kbits/s:
- OPU : k = 1 : 2 488 320,000 ; k = 2 : 9 995 276,962 ; k = 3 : 40 150 519,322
- ODU : k = 1 : 2 498 775,126 ; k = 2 : 10 037 273,924 ; k = 3 : 40 319 218,983
- OTU : k = 1 : 2 666 057,143 ; k = 2 : 10 709 225,316 ; k = 3 : 43 018 413,559

- Indice m : l'indice "m" est utilisé pour représenter le débit binaire ou ensemble de débits binaires pris en charge sur l'interface.C'est un ou plusieurs chiffres "k", où chaque "k" représente un débit binaire particulier. Les valeurs valides pour m sont (1, 2, 3, 12, 23, 123).

- Indice n : l'indice "n" est utilisé pour représenter l'ordre de OTM, OTS, OMS, OPS, OCG et OMU. Cet indice représente le nombre maximum de longueurs d'ondes qui peut être pris en charge au plus faible débit binaire supporté sur la longueur d'onde. Il est possible qu'un nombre réduit de longueurs d'ondes de débit supérieur soit pris en charge. Le cas de n = 0 représente un seul canal sans longueur d'onde spécifique allouée au canal.

- Indice r : l'indice "r", si il est présent, est utilisé pour indiquer une fonctionnalité réduite de OTM, OCG, OCC et OCh (la redondance non associée n'est pas prise en charge). Noter que pour n = 0, l'indice n'est pas exigé car cela implique toujours une fonctionnalité réduite.

 	Adresse de l'éditeur

Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium

téléphone : +32 3 240-8491
mél : dimitri.papadimitriou@alcatel.be 

 	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2006). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant 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 violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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