Groupe de travail Réseau	M. Bocci, éd., Alcatel-Lucent	
Request for Comments: 5586	M. Vigoureux, éd., Alcatel-Lucent	
RFC mises à jour : 3032, 4385, 5085	S. Bryant, éd., Cisco Systems	
Catégorie : Sur la voie de la normalisation 	juin 2009	
Traduction Claude Brière de L'Isle		

Canal associé générique MPLS

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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 droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 

Résumé
Le présent document généralise l'applicabilité de l'en-tête de canal associé (ACH, Associated Channel Header) de pseudo-filaire (PW, pseudowire) permettant la réalisation d'un canal de contrôle associé aux chemins de commutation d'étiquettes (LSP, Label Switched Path) MPLS et aux sections MPLS en plus des pseudo-filaires MPLS. Afin d'identifier la présence de cet en-tête de canal associé dans la pile d'étiquettes, le présent document alloue aussi une des valeurs d'étiquette MPLS réservées à l'étiquette de canal associé générique (GAL, Generic Associated Channel Label) à utiliser comme mécanisme d'exception fondé sur l'étiquette.
Table des matières
1. Introduction	2
1.1 Objectifs	2
1.2 Domaine d'application	3
1.3 Langage des exigences et terminologie	3
2. En-tête de canal associé générique	3
2.1 Définition	3
2.2 Allocation des types de canaux	4
3. TLV ACH	4
3.1 Structure de charge utile de TLV ACH	4
3.2 En-tête de TLV ACH	5
3.3 Objet TLV ACH	5
4. Mécanisme d'exception généralisé	5
4.1 Relations avec les mécanismes existants d'alerte OAM MPLS	6
4.2 Applicabilité et usage de GAL	6
4.3 Relations avec la RFC 3429	8
5. Compatibilité	8
6. Considérations d'encombrement	9
7. Contributeurs majeurs	9
8. Remerciements	9
9. Considérations sur la sécurité	9
10. Considérations relatives à l'IANA	9
11. Références	10
11.1 Références normatives	10
11.2 Références pour information	11
Adresse des auteurs	11

 	1.	Introduction

Il y a un besoin de mécanismes d'opérations, administration, et maintenance (OAM) qui puissent être utilisés pour la détection de fautes, les diagnostics, la maintenance, et autres fonctions sur un pseudo-filaire (PW, pseudowire) et un chemin de commutation d'étiquettes (LSP, Label Switched Path). Ces fonctions peuvent être utilisées entre deux routeurs bordures d'étiquettes (LER, Label Edge Router)/routeurs de commutation d'étiquettes (LSR, Label Switching Router) ou routeurs de terminaison côté fournisseur (T-PE, Terminating Provider Edge router)/routeur de commutation côté fournisseur (S-PE, Switching Provider Edge router) le long du chemin d'un LSP ou PW, respectivement [RFC5921]. Certaines de ces fonctions peuvent être prises en charge en utilisant des outils existants comme la vérification de connexité de circuit virtuel (VCCV, Virtual Circuit vérification de connexité) [RFC5085], la détection de transmission bidirectionnelle pour LSP MPLS (BFD-MPLS, Bidirectional Forwarding Detection for MPLS LSPs) [RFC5884], le ping de LSP [RFC4379], ou la BFD-VCCV [RFC5885]. Cependant, une exigence a été indiquée pour augmenter cet ensemble de fonctions de maintenance, en particulier quand des réseaux MPLS sont utilisés pour des services de transport de paquet et des opérations de réseau de transport [RFC5860]. Des exemples de ces fonctions incluent la surveillance de performances, la commutation automatique de protection, et la prise en charge des canaux de communication de gestion et de signalisation. Ces outils DOIVENT être applicables, et fonctionner essentiellement de la même manière (d'un point de vue opérationnel) sur les PW MPLS, les LSP MPLS, et les sections MPLS. Ils DOIVENT aussi opérer dans la bande sur le PW ou LSP de telle façon qu'ils ne dépendent pas de l'acheminement du réseau de commutation de paquets (PSN, Packet Switched Network) ou du trafic d'utilisateur, et NE DOIVENT PAS dépendre de fonctions dynamiques du plan de contrôle.

VCCV [RFC5085] peut utiliser un en-tête de canal associé (ACH, Associated Channel Header) pour fournir un canal de contrôle associé au PW entre les points d'extrémité d'un PW, sur lequel les messages OAM et autres messages de contrôle peuvent être échangés. Le présent document généralise l'applicabilité de l'ACH pour permettre que le même mécanisme de canal de contrôle associé soit utilisé pour les sections, les LSP, et les PW. Le canal de contrôle associé ainsi généralisé est appelé le canal associé générique (G-ACh, Generic Associated Channel). Le ACH, spécifié dans la [RFC4385], peut être utilisé avec des codets supplémentaires pour prendre en charge des fonctions supplémentaires de maintenance MPLS sur le G-ACh.

Généraliser l'applicabilité de l'ACH aux LSP et aux sections exige aussi une méthode pour identifier qu'un paquet contient un ACH suivi par une charge utile non de service. Donc, le présent document définit aussi un mécanisme d'exception fondé sur l'étiquette qui sert à informer un LSR (ou LER) qu'un paquet qu'il reçoit sur un LSP ou une section appartient à un canal de contrôle associé. L'étiquette utilisée à cette fin est une des étiquettes MPLS réservées et est appelée l'étiquette de canal associé générique (GAL, G-ACh Label). Le mécanisme de GAL est défini pour fonctionner avec le ACH pour les LSP et les sections MPLS.

La [RFC4379] et BFD-MPLS [RFC5884] définissent des mécanismes d'alerte qui permettent à un LSR MPLS d'identifier et traiter les paquets d'OAM MPLS quand ils sont encapsulés dans un en-tête IP. Ces mécanismes d'alerte sont fondés, par exemple, sur l'expiration de la durée de vie (TTL, Time To Live) et/ou sur l'utilisation d'une adresse de destination IP dans la gamme de 127.0.0.0/8 ou 0:0:0:0:0:FFFF:127.0.0.0/104 pour IPv4 et IPv6, respectivement. Ces mécanismes sont les mécanismes par défaut pour identifier les paquets d'OAM MPLS quand ils sont encapsulés dans un en-tête IP. Cependant, il peut n'être pas toujours possible d'utiliser ces mécanismes dans certaines applications MPLS, par exemple, le profil de transport MPLS (MPLS-TP, MPLS Transport Profile) [RFC5921], en particulier quand le démultiplexage fondé sur IP ne peut pas être utilisé. Le présent document définit un mécanisme qui est RECOMMANDÉ pour identifier et encapsuler les messages d'OAM MPLS et autres messages de maintenance quand les mécanismes fondés sur IP tels que ceux utilisés dans les [RFC4379] et [RFC5884] ne sont pas disponibles. Ce mécanisme PEUT aussi être utilisé en plus des mécanismes fondés sur IP.

Noter que, dans le présent document, les fonctions et paquets de maintenance devraient être compris au sens large. C'est-à-dire, un ensemble de mécanismes de maintenance et de gestion qui inclut les messages d'OAM, de commutation automatique de protection (APS, Automatic Protection Switching) de canal de communication de signalisation (SCC, Signaling Communication Channel) et de canal de communication de gestion (MCC, Management Communication Channel).

Noter aussi que le GAL et ACH sont applicables à MPLS et aux PW en général. Le présent document spécifie le mécanisme général et utilise MPLS-TP comme exemple d'application. L'application du GAL et ACH à d'autres utilisations spécifiques de MPLS sort du domaine d'application de ce document.

 	1.1	Objectifs
Le présent document définit un mécanisme qui fournit une solution aux besoins d'extension de maintenance des applications émergentes pour MPLS. Il crée un mécanisme générique de canal de contrôle qui peut être appliqué aux LSP et sections MPLS, tout en maintenant la compatibilité avec le canal associé au PW. Il normalise aussi l'utilisation du ACH pour les PW dans un contexte de transport, et définit un mécanisme d'exception fondé sur l'étiquette pour alerter les LER/LSR de la présence d'un ACH après le fond de la pile d'étiquettes.

 	1.2	Domaine d'application
Le présent document définit l'en-tête d'encapsulation pour les messages de canal de contrôle associé de section, LSP, et PW.

Le présent document ne définit pas comment les capacités de canal de contrôle associé sont signalées ou négociées entre les LER/LSR ou entre les PE, ni ne définit le fonctionnement des diverses fonctions d'OAM.

Le présent document ne déconseille pas les mécanismes existants d'OAM MPLS et PW.

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

Le présent document utilise la terminologie supplémentaire suivante :

ACH (Associated Channel Header) : en-tête de canal associé

G-ACh (Generic Associated Channel) : canal associé générique

GAL (G-ACh Label) : étiquette de canal associé générique

Paquet G-ACh : tout paquet contenant un message qui appartient à un protocole porté sur un canal de contrôle associé d'un PW, LSP, ou section MPLS. Les exemples incluent des protocoles de maintenance comme les fonctions d'OAM, de communications de signalisation, ou communications de gestion.

Les termes de "section" et "segment enchaîné" sont définis dans la [RFC5654] comme suit (noter que les termes "section" et "réseau de couche section" sont synonymes) :

Réseau de couche section : une couche section est une couche serveur (qui peut être MPLS-TP ou une technologie différente) qui fournit le transfert des informations de client de couche section entre les nœuds adjacents dans la couche du chemin de transport ou la couche de service de transport. Noter que [G.805] définit la couche section comme une des deux couches réseau dans un réseau de couche de support de transmission. L'autre réseau de couche est le réseau de couche de support physique.

Segment enchaîné : connexion de liaison de série composée, comme définie dans [G.805]. Un segment enchaîné est une partie contiguë d'un LSP ou d'un PW multi segments qui comporte un ensemble de segments et leurs nœuds d'interconnexion en séquence.

 	2.	En-tête de canal associé générique

VCCV [RFC5085] définit trois types de canal de contrôle (CC, Control Channel) qui peuvent être utilisés pour échanger des messages d'OAM à travers un PW. Le CC de type 1 utilise un ACH et est appelé un "VCCV dans la bande" ; le CC de type 2 utilise l'étiquette d'alerte de routeur MPLS pour indiquer les paquets VCCV et est appelé un "VCCV hors bande" ; le CC de type 3 utilise le TTL pour forcer le traitement du paquet par le plan de contrôle du routeur ciblé et est appelé une "Étiquette de PW MPLS avec TTL == 1".

 	2.1	Définition
L'utilisation du ACH, limitée précédemment aux PW, est généralisée ici pour s'appliquer aussi aux LSP et aux sections. Noter que pour les PW, le mot de contrôle PWE3 [RFC4385] DOIT être présent dans l'encapsulation des paquets d'utilisateur quand le ACH est utilisé pour réaliser le canal de contrôle associé.

Le ACH utilisé par le CC de type 1 est décrit dans la figure ci-dessous :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version|   Réservé     |         Type de canal         |
+-------+-------+---------------+---------------+---------------+

Figure 1 : En-tête de canal associé

Dans la figure ci-dessus, le premier quartier est réglé à 0001b pour indiquer un canal de contrôle associé à un PW, LSP, ou section. Le champ Version est réglé à 0, comme spécifié dans la [RFC4385]. Les bits 8 à 15 du ACH sont réservés et DOIVENT être réglés à 0 et ignorés à réception. Les bits 16 à 31 sont utilisés pour coder les types de canal possibles. Ce champ de 16 bits est dans l'ordre des octets du réseau.

Noter que VCCV [RFC5085] inclut aussi des mécanismes pour négocier les types de canal de contrôle et de vérification de connexité (c'est-à-dire, fonction d'OAM) entre les PE. Il est prévu que des mécanismes similaires seront appliqués aux LSP.  Une telle application exigera plus de spécification. Cependant, cela sort du domaine d'application du présent document.

Le G-ACh NE DOIT PAS être utilisé pour transporter du trafic d'utilisateur.

 	2.2	Allocation des types de canaux
Le champ Type de canal indique le type du message porté sur le canal de contrôle associé, par exemple, IPv4 ou IPv6 si le démultiplexage IP est utilisé pour les messages envoyés sur le canal de contrôle associé, ou OAM ou autre fonction de maintenance si le démultiplexage IP n'est pas utilisé. Pour les paquets de canal de contrôle associé où IP n'est pas utilisé comme multiplexeur, le type de canal indique le protocole spécifique porté dans le canal de contrôle associé.

Les valeurs pour le champ Type de canal actuellement utilisé pour VCCV sont spécifiés ailleurs, par exemple, dans la [RFC4446] et la [RFC4385]. Des valeurs de type de canal supplémentaires et la fonction de maintenance associée seront définies dans d'autres documents. Chaque document, spécifiant une solution de protocole s'appuyant sur le ACH, DOIT aussi spécifier la valeur applicable de champ Type de canal.

Noter que ces valeurs sont allouées dans le registre des types de canal associé de PW [RFC4446], mais le présent document modifie la politique existante pour permettre un niveau d'expérimentation. Voir les détails à la Section 10.

 	3.	TLV ACH

Dans certaines applications du canal de contrôle associé généralisé, il est nécessaire d'inclure un ou plusieurs TLV ACH pour fournir des informations de contexte supplémentaires au paquet G-ACh. Une utilisation de ces TLV ACH pourrait être d'identifier la source et/ou la destination prévue du message de canal associé. Cependant, l'utilisation de cette construction n'est pas limitée à la fourniture des informations d'adressage, pas plus que l'applicabilité n'est restreinte aux applications de  réseau de transport.

Si le message G-ACh PEUT être précédé de un ou plusieurs TLV ACH, alors cela DOIT être explicitement spécifié dans la définition d'un type de canal ACH. Si la définition du type de canal ACH ne déclare pas qu'un ou plusieurs TLV ACH PEUVENT précéder le message G-ACh, un en-tête de TLV ACH DOIT suivre le ACH. Si aucun TLV ACH n'est exigé dans un paquet de canal associé spécifique, mais si le type de canal définit néanmoins que les TLV ACH PEUVENT être utilisés, un en-tête de TLV ACH DOIT être présent mais avec un champ Longueur réglé à zéro pour indiquer qu'aucun TLV ACH ne suit cet en-tête.

Si une spécification de type de canal ACH ne spécifie pas explicitement que les TLV ACH PEUVENT être utilisés, alors l'en-tête de TLV ACH NE DOIT PAS être utilisé.

 	3.1	Structure de charge utile de TLV ACH
Ce paragraphe définit et décrit la structure d'une charge utile ACH quand un en-tête de TLV ACH est présent.
La figure suivante (Figure 2) montre la structure d'une charge utile de paquet G-ACh.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ACH                              |
+---------------+---------------+---------------+---------------+
|                       En-tête de TLV ACH                      |
+---------------+---------------+---------------+---------------+
|                                                               ~
~                     zéro, un ou plusieurs TLV ACH             ~
~                                                               |
+---------------+---------------+---------------+---------------+
~                       Message G-ACh                           ~
~                                                               |
+---------------+---------------+---------------+---------------+

Figure 2 : Charge utile de paquet G-ACh

 	3.2	En-tête de TLV ACH
L'en-tête de TLV ACH définit la longueur de l'ensemble des TLV ACH qui 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Longueur             |            Réservé            |
+---------------+---------------+---------------+---------------+

Figure 3: En-tête de TLV ACH

Le champ Longueur spécifie la longueur en octets de l'ensemble complet de TLV incluant les sous TLV qui suivent l'en-tête de TLV ACH. Une longueur de zéro indique qu'aucun TLV ACH ne suit cet en-tête. Noter qu'aucun bourrage n'est exigé pour l'ensemble des TLV ACH.
Le champ Réservé est pour une utilisation future et DOIT être réglé à zéro à l'émission et ignoré à réception.

 	3.3	Objet TLV ACH
Des TLV ACH PEUVENT suivre un en-tête de TLV ACH. La structure des TLV ACH est définie et décrite dans ce paragraphe.
Un TLV ACH consiste en un champ Type de 16 bits, suivi par un champ Longueur de 16 bits spécifiant le nombre d'octets du champ Valeur, qui suit le champ Longueur. Ce mot de 32 bits est suivi par zéro, un ou plusieurs octets d'informations de valeur. Le format et la signification des informations de valeur sont définis par le type de TLV comme enregistré dans le registre des types de TLV. Voir les détails à la Section 10. Noter que le champ Valeur des TLV ACH PEUT contenir des sous TLV. Noter qu'aucun bourrage n'est requis pour les TLV ou sous TLV individuels.

 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 TLV          |        Longueur               |
+---------------+---------------+---------------+---------------+
|                                                               ~
~                             Valeur                            ~
~                                                               |
+---------------+---------------+---------------+---------------+

Figure 4 : Format de TLV ACH

 	4.	Mécanisme d'exception généralisé

Généraliser le mécanisme de canal de contrôle associé aux LSP et sections exige aussi une méthode pour identifier qu'un paquet contient un ACH suivi par une charge utile non de service. Le présent document spécifie qu'une étiquette est utilisée à cette fin et appelle cette étiquette spéciale l'étiquette G-ACh (GAL). Une des valeurs d'étiquette réservées définies dans la [RFC3032] est allouée à cette fin. L'IANA a alloué la valeur 13 à GAL.

GAL fournit un mécanisme d'exception fondé sur l'alerte pour :
o	différencier les paquets spécifiques (c'est-à-dire, les paquets G-ACh) des autres, comme ceux du plan d'utilisateur ;
o	indiquer que le ACH apparaît immédiatement après le fond de la pile d'étiquettes.

Le GAL DOIT seulement être utilisé lorsque ces deux objets s'appliquent.

 	4.1	Relations avec les mécanismes existants d'alerte OAM MPLS
La [RFC4379] et BFD-MPLS [RFC5884] définissent des mécanismes d'alerte qui permettent à un LSR MPLS d'identifier et traiter les paquets d'OAM MPLS quand ils sont encapsulés dans un en-tête IP. Ces mécanismes d'alerte se fondent, par exemple, sur l'expiration de la durée de vie (TTL, Time To Live) et/ou sur l'utilisation d'une adresse de destination IP dans la gamme de 127.0.0.0/8 ou 0:0: 0:0:0:FFFF:127.0.0.0/104 pour IPv4 et IPv6, respectivement.

Ces mécanismes sont les mécanismes par défaut pour identifier les paquets d'OAM MPLS quand ils sont encapsulés dans un en-tête IP, bien que le mécanisme défini dans le présent document PUISSE aussi être utilisé.

 	4.2	Applicabilité et usage de GAL
Dans MPLS-TP, le GAL DOIT être utilisé avec les paquets sur un G-ACh sur les LSP, les segments enchaînés des LSP, et avec les sections, et NE DOIT PAS être utilisé avec les PW. Il DOIT toujours être au bas de la pile d'étiquettes (c'est-à-dire, le bit S réglé à 1). Cependant, dans d'autres environnements MPLS, le présent document ne fait aucune restriction sur où le GAL peut apparaître au sein de la pile d'étiquettes ou sur son utilisation avec des PW. Lorsque le GAL est au bas de la pile d'étiquettes (c'est-à-dire, quand le bit S est réglé à 1) il DOIT alors toujours être suivi par un ACH.

Le GAL NE DOIT PAS apparaître dans la pile d'étiquettes quand on transporte des paquets normaux de plan d'utilisateur.  De plus, quand il est présent, le GAL NE DOIT PAS apparaître plus d'une fois dans la pile d'étiquettes.

Un LSR, LER, ou PE receveur NE DOIT PAS transmettre un paquet G-ACh à un autre nœud sur la base de l'étiquette de GAL.

 	4.2.1	Traitement de GAL
Le champ Classe de trafic (TC, Traffic Class) (anciennement appelé champ EXP) de l'entrée de pile d'étiquettes (LSE, Label Stack Entry) contenant le GAL suit la définition et les règles de traitement spécifiées et référencées dans la [RFC5462].

Le champ Durée de vie (TTL, Time-To-Live) de la LSE qui contient le GAL suit la définition et les règles de traitement spécifiées dans la [RFC3443].

 	4.2.1.1	Chemins et segments de commutation d'étiquette MPLS
La Figure 5 décrit deux LER (A et D) et deux LSR (B et C) pour un LSP donné qui est établi de A à D et commuté dans B et C.

        +---+             +---+             +---+             +---+
        | A |-------------| B |-------------| C |-------------| D |
        +---+             +---+             +---+             +---+

Figure 5 : Maintenance sur un LSP

Dans cet exemple, un G-ACh existe sur le LSP qui s'étend entre les LER A et D, via les LSR B et C. Seul A et D peuvent initier de nouveaux paquets G-ACh. A, B, C, et D peuvent traiter et répondre aux paquets G-ACh.

La Figure 6 décrit le format d'un paquet G-ACh MPLS-TP utilisé pour un LSP.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Étiquette de LSP                |  TC |S|       TTL     |
+---------------+---------------+-------+-----+-+---------------+
|                  GAL                  |  TC |S|       TTL     |
+---------------+---------------+-------+-----+-+---------------+
|                              ACH                              |
+---------------+---------------+---------------+---------------+
|                  En-tête de TLV ACH (si présent)              |
+---------------+---------------+---------------+---------------+
|                                                               ~
~                     Zéro, un ou plusieurs TLV ACH             ~
~                           (si présent)                        |
+---------------+---------------+---------------+---------------+
|                                                               ~
~                         Message G-ACh                         ~
~                                                               |
+---------------+---------------+---------------+---------------+

Figure 6 : Format de paquet G-ACh pour un LSP

Noter qu'il est possible que le LSP puisse être tunnelé dans un autre LSP (par exemple, si un tunnel MPLS existe entre B et C) et à ce titre, d'autres LSE peuvent être présentes dans la pile d'étiquettes.

Pour envoyer un message G-ACh sur le canal de contrôle associé du LSP, le LER (A) génère un message G-ACh, auquel il PEUT ajouter devant un en-tête de TLV ACH et les TLV ACH appropriés. Il ajoute ensuite un ACH, sur lequel il pousse une LSE GAL. Finalement, la LSE d'étiquette de LSP est poussée sur le paquet résultant.

o	Le champ TTL de la LSE de GAL DOIT être réglé au moins à 1. La valeur exacte du TTL est spécifique de l'application. Voir au paragraphe 4.2.1 la définition et les règles de traitement.

o	Le bit S du GAL DOIT être réglé en accord avec sa position dans la pile d'étiquettes (voir le paragraphe 4.2).

o	Le réglage du champ TC du GAL est spécifique de l'application. Voir au paragraphe 4.2.1 la définition et les règles de traitement.

Les LSR NE DOIVENT PAS modifier le message G-ACh, le ACH ou le GAL vers la destination ciblée.

Note : C'est parce que une fois qu'un paquet G-ACh a été envoyé sur un LSP, aucun nœud n'a de visibilité sur lui sauf si le TTL de l'étiquette de LSP arrive à expiration ou si le GAL est exposé quand l'étiquette de LSP est activée. Si c'est à la destination ciblée, par exemple, indiquée par une adresse dans un TLV ACH, alors le traitement peut se faire comme spécifié ci-dessous. Si ce n'est pas la destination ciblée, mais si le nœud a accepté de traiter les paquets sur ce canal de ACH, alors le traitement appliqué au paquet sort du domaine d'application du présent document.

À réception du paquet étiqueté, la destination ciblée, après avoir vérifié les deux champs Étiquette de LSP et LSE de GAL, DEVRAIT passer tout le paquet à l'entité de traitement appropriée.

 	4.2.1.2	Section MPLS
La Figure 7 décrit un exemple de section MPLS.

                          +---+             +---+
                          | A |-------------| Z |
                          +---+             +---+

Figure 7 : Maintenance sur une section MPLS

À l'égard de la section MPLS, un G-ACh existe entre A et Z. Seuls A et Z peuvent insérer, extraire, ou traiter les paquets sur ce G-ACh.

La Figure 8 décrit le format d'un paquet G-ACh quand il est utilisé pour une section MPLS. Le GAL PEUT fournir le mécanisme d'exception pour un canal de contrôle de son plein droit sans être associé à un LSP spécifique, fournissant donc des communications relatives à la maintenance sur une liaison spécifique qui interconnecte deux LSR. Dans ce cas, le GAL est la seule étiquette dans la pile.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  GAL                  |  TC |S|       TTL     |
+---------------+---------------+-------+-----+-+---------------+
|                             ACH                               |
+---------------+---------------+---------------+---------------+
|                  En-tête de TLV ACH (si présent)              |
+---------------+---------------+---------------+---------------+
|                                                               ~
~                     Zéro, un ou plusieurs TLV ACH             ~
~                         (si présent)                          |
+---------------+---------------+---------------+---------------+
|                                                               ~
~                         Message G-ACh                         ~
~                                                               |
+---------------+---------------+---------------+---------------+

Figure 8 : Format de paquet G-ACh pour une section MPLS

Pour envoyer un message G-ACh sur un canal de contrôle associé à la section, le LSR d'extrémité de tête (A) de la section génère un message G-ACh, auquel il PEUT ajouter devant un en-tête de TLV ACH et les TLV ACH appropriés. Ensuite, le LSR ajoute un ACH. Finalement, il pousse une LSE GAL.

o	Le champ TTL du GAL DOIT être réglé au moins à 1. La valeur exacte du TTL est spécifique de l'application. Voir au paragraphe 4.2.1 la définition et les règles de traitement.

o	Le bit S du GAL DOIT être réglé en accord avec sa position dans la pile d'étiquettes. (Voir le paragraphe 4.2).

o	Le réglage du champ TC du GAL est spécifique de l'application. Voir au paragraphe 4.2.1 la définition et les règles de traitement.

Les nœuds intermédiaires de la section MPLS NE DOIVENT PAS modifier le message G-ACh, le ACH et le GAL vers le LSR d'extrémité de queue (Z). À réception du paquet G-ACh, le LSR d'extrémité de queue (Z) après avoir vérifié les champ de LSE du GAL, DEVRAIT passer tout le paquet à l'entité de traitement appropriée.

 	4.3	Relations avec la RFC 3429
La [RFC3429] décrit l'allocation d'une des valeurs d'étiquette réservées, définies dans la [RFC3032], à l'étiquette "Alerte d'OAM" qui est utilisée par les fonctions d'OAM de plan d'utilisateur MPLS pour l'identification des paquets d'OAM MPLS. La valeur 14 est utilisé à cette fin.

Le présent document et la [RFC3429] décrivent donc l'allocation des valeurs d'étiquettes réservées pour des objets similaires. La raison de l'allocation d'une nouvelle étiquette réservée peut être résumée comme suit :

o	À la différence des mécanismes décrits et référencés dans la [RFC3429] les messages G-ACh ne vont pas résider immédiatement après le GAL mais plutôt derrière le ACH, qui lui-même réside après la fin de la pile d'étiquettes.

o	L'ensemble de fonctions de maintenance potentiellement gérées dans le contexte du G-ACh est plus large que l'ensemble de fonctions OAM référencé dans la [RFC3429].

o	Il a été rapporté qu'il existe des mises en œuvre et des déploiements en cours qui utilisent une "étiquette d'alerte OAM" comme décrit dans la [RFC3429]. Il n'est donc pas possible de modifier l'allocation, l'objet, ou l'usage d"une "étiquette d'alerte OAM". Néanmoins, il est RECOMMANDÉ qu'aucune autre extension d'OAM fondée sur l'usage de "étiquette d'alerte OAM" (étiquette 14) ne soit spécifiée ou développée.

 	5.	Compatibilité

Les procédures pour traiter un paquet reçu avec une étiquette entrante invalide sont spécifiées dans la [RFC3031].

Un LER, LSR, ou PE DOIT éliminer les paquets de canal associé reçus sur lesquels toutes les étiquettes MPLS ou PW ont été activées si une des conditions suivantes est vraie :
o	Il n'est pas capable de traiter les paquets sur le type de canal indiqué par le ACH du paquet reçu.
o	Il n'a pas, par des moyens qui sortent du domaine d'application du présent document, indiqué au LSR, LER, ou PE envoyeur qu'il va traiter les paquets du canal associé sur le type de canal indiqué par le ACH du paquet reçu.
o	Le paquet est reçu sur un type de canal expérimental qui est désactivé en local.
o	Si le ACH était indiqué par la présence d'un GAL, et si le premier quartier de l'ACH du paquet reçu n'est pas 0001b.
o	La version de ACH n'est pas reconnue.

De plus, le LER, LSR, ou PE PEUT incrémenter un compteur d'erreurs et PEUT aussi produire une notification du système et/ou du protocole simple de gestion de réseau (SNMP).

 	6.	Considérations d'encombrement

Les considérations d'encombrement détaillées dans la [RFC5085] s'appliquent.

 	7.	Contributeurs majeurs

Les éditeurs tiennent à remercier George Swallow, David Ward, et Rahul Aggarwal qui ont fait une contribution majeure au développement du présent document.

George Swallow, Cisco Systems, mél : swallow@cisco.com
David Ward, Cisco Systems, mél : dward@cisco.com
Rahul Aggarwal, Juniper Networks, mél : rahul@juniper.net

 	8.	Remerciements

Les éditeurs remercient de leurs contributions Sami Boutros, Italo Busi, Marc Lasserre, Lieven Levrau, et Siva Sivabalan.

Les auteurs tiennent aussi à remercier Malcolm Betts, le groupe d'études 15 de l'UIT-T, et tous les membres des équipes (l'équipe de travail conjointe, l'équipe de conception de l'interopérabilité MPLS de l'IETF et l'équipe ad hoc MPLS-TP de l'UIT-T) impliquées dans la définition et la spécification du profil de transport MPLS.

 	9.	Considérations sur la sécurité

Les considérations sur la sécurité pour le canal de contrôle associé sont décrites dans la [RFC4385]. D'autres considérations sur la sécurité DOIVENT être décrites dans la spécification pertinente de type de canal associé.

La [RFC5085] fournit des considérations sur la sécurité relative au plan des données. Elles s'appliquent aussi à un G-ACh, que le mécanisme d'alerte utilise un GAL ou seulement un ACH.

 	10.	Considérations relatives à l'IANA

L'IANA a alloué la valeur d'étiquette 13 au GAL dans le réservoir des étiquettes réservées dans le registre des "Valeurs d'étiquettes de l'architecture de commutation d'étiquettes multi protocoles (MPLS, Multiprotocol Label Switching)".

Les types de canal pour l'en-tête de canal associé sont allouées dans le registre de l'IANA "Type de canal associé de PW" [RFC4446]. Le registre de type de canal associé de PW est actuellement alloué sur la base du processus de consentement de l'IETF (appelé "revue de l'IETF" dans la [RFC5226]). Ce processus d'allocation a été choisi sur la base du consensus obtenu dans le groupe de travail PWE3 que les mécanismes de canal associé de pseudo filaire devraient être revus par l'IETF et seuls ceux qui sont cohérents avec l'architecture et les exigences de PWE3 devraient recevoir un codet.

Cependant, une exigence est apparue (voir la [RFC5860]) de permettre que des optimisations ou extensions aux protocoles d'OAM et autres protocoles de contrôle fonctionnant dans un canal associé soient expérimentés sans relever du processus de normalisation de l'IETF, en prenant en charge des codets expérimentaux. Cela empêcherait que des codets utilisés pour de telles fonctions soient utilisés dans la gamme allouée dans les normes de l'IETF et donc protégerait une base installée d'équipements d'une potentielle surcharge involontaire de codets. Afin de prendre en charge cette exigence, l'IANA a changé le schéma d'allocation des codets de type de canal associé comme suit :

0 - 32751 : revue de l'IETF
32760 - 32767 : expérimental

Les codets dans la gamme expérimentale DOIVENT être utilisés en accord avec les lignes directrices de la [RFC3692]. Les fonctions qui utilisent des codets de G-ACh expérimentaux DOIVENT être désactivées par défaut. La valeur de type de canal utilisée pour une fonction d'OAM expérimentale donnée DOIT être configurable, et on DOIT veiller à s'assurer que différentes fonctions d'OAM qui ne sont pas inter-opérables sont configurées à utiliser des valeurs différentes de type de canal.

Le registre des types de canal associé de PW a été mis à jour pour inclure une colonne indiquant si le ACH est suivi d'un en-tête de TLV ACH (Oui/Non). Il y a deux codets de type de canal ACH actuellement alloués et dans les deux cas, aucun en-tête de TLV ACH n'est utilisé. Donc, le nouveau format du registre de type ce canal de PW est :

Registre :
Valeur	Description	TLV suit	Référence
0x21	ACH porte un paquet IPv4	Non	[RFC4385]
0x57	ACH porte un paquet IPv6	Non	[RFC4385]

Figure 9 : Registre de type de canal PW

L'IANA a créé un nouveau registre appelé Registre de TLV d'en-tête de canal associé. La politique d'allocation pour ce registre est la revue de l'IETF. Ce registre DOIT comporter les informations suivantes. Il n'y a pas d'entrée initiale.

Nom	Type	Longueur (octets)	Description	Référence

Figure 10 : Registre des TLV ACH

 	11.	Références
 	11.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. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC3031]	E. Rosen, A. Viswanathan, R. Callon, "Architecture de commutation d'étiquettes multi protocoles", janvier 2001. (P.S.) (MàJ par la RFC6790)

[RFC3032]	E. Rosen et autres, "Codage de pile d'étiquettes MPLS", janvier 2001. (Info. ; MàJ par 9017)

[RFC3443]	P. Agarwal, B. Akyol, "Traitement de la durée de vie (TTL) dans les réseaux à commutation d'étiquettes multi-protocoles (MPLS)", janvier 2003. (P.S.)

[RFC3692]	T. Narten, "L'allocation de numéros expérimentaux et d'essai est considérée comme utile", janvier 2004. (BCP0082)

[RFC4385]	S. Bryant et autres, "Mot de contrôle d'émulation bord à bord pseudo filaire (PWE3) à utiliser sur un PSN MPLS", février 2006. (P.S.)

[RFC4446]	L. Martini, "Allocations de l'IANA pour l'émulation de bord à bord pseudo filaire (PWE3)", avril 2006. (BCP0116)

[RFC5085]	T. Nadeau et C. Pignataro, éditeurs, "Vérification de connexité de circuit virtuel pseudo filaire (VCCV) : un canal de contrôle pour les pseudo filaires", décembre 2007. (MàJ par RFC5586) 

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5462]	L. Andersson, R. Asati, "Entrée de pile d'étiquettes de commutation d'étiquettes multiprotocoles (MPLS) : le champ "EXP" est renommé champ "Traffic Class"", février 2009. (MàJ RFC3032, RFC3270, RFC3272, RFC3443, RFC3469, RFC3564, RFC3985, RFC4182, RFC4364, RFC4379, RFC4448, RFC4761, RFC5129) (P.S.)

 	11.2	Références pour information
[G.805]	Recommandation UIT-T G.805, "Architecture fonctionnelle générique des réseaux de transport", mars 2000.

[RFC3429]	H. Ohta, "Allocation de 'l'étiquette d'alerte OAM' pour les fonctions de fonctionnement et de maintenance (OAM) de l'architecture de commutation d'étiquettes multiprotocoles (MPLS)", novembre 2002. (Info.)

[RFC4379]	K. Kompella et G. Swallow, "Détection des défaillances de plan des données en commutation d'étiquettes multi protocole (MPLS)", février 2006. (MàJ par la RFC6424  ; Rendue obsolète par RFC8029) (P.S.)

[RFC5654]	B. Niven-Jenkins et autres, "Exigences pour un profil de transport MPLS", septembre 2009. (P. S.)

[RFC5860]	M. Vigoureux, D. Ward, M. Betts, "Exigences pour le fonctionnement, l'administration, et la maintenance (OAM) dans les réseaux de transport MPLS", mai 2010. (P. S.)

[RFC5884]	R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow, "Détection de transmission bidirectionnelle (BFD) pour chemins à commutation d'étiquette (LSP) MPLS", juin 2010. (MàJ RFC1122). (P. S.)

[RFC5885]	T. Nadeau, C. Pignataro, "Détection de transmission bidirectionnelle (BFD) pour la vérification de connexité de pseudo circuit virtuel (VCCV)", juin 2010. (P. S. ; MàJ par  RFC6478, RFC7885)

[RFC5921]	M. Bocci, S. Bryant, D. Frost, L. Levrau, L. Berger, "Cadre pour MPLS dans les réseaux de transport", juillet 2010. (Inf.)

 	Adresse des éditeurs

Matthew Bocci	Martin Vigoureux	Stewart Bryant	
Alcatel-Lucent	Alcatel-Lucent	Cisco Systems	
Voyager Place, Shoppenhangers Road	Route de Villejust	mél : stbryant@cisco.com	
Maidenhead, Berks  SL6 2PJ	Nozay,   91620		
UK	France		
mél : matthew.bocci@alcatel-lucent.com	mél : martin.vigoureux@alcatel-lucent.com