Groupe de travail Réseau	B. Niven-Jenkins, éditeur, BT	
Request for Comments: 5654	D. Brungard, éditeur, AT&T	
Catégorie : Sur la voie de la normalisation	M. Betts, éd., Huawei Technologies	
	N. Sprecher, Nokia Siemens Networks	
	S. Ueno, NTT Communications	
Traduction Claude Brière de L'Isle	septembre 2009	

Exigences pour un profil de transport MPLS

Résumé
Le présent document spécifie les exigences d'un profil de transport MPLS (MPLS-TP, MPLS Transport Profile). Ce document a été produit par un effort conjoint de l'Union Internationale des Télécommunications (UIT) et de l'IETF pour inclure un profil de transport MPLS dans les architectures de MPLS et PWE3 au sein de l'IETF pour prendre en charge les capacités et fonctionnalités d'un réseau de transport de paquets comme défini par le secteur de la normalisation de l'Union Internationale des Télécommunications (UIT-T).

Ce travail se fonde sur deux sources d'exigences : les architectures MPLS et PWE3 comme définies par l'IETF, et les réseaux de transport de paquets comme définis par l'UIT-T.

Les exigences exprimées dans le présent document portent sur le comportement des mécanismes et procédures de protocole qui constituent les blocs de construction à partir desquels est construit le profil de transport MPLS. Les exigences ne sont pas des exigences de mise en œuvre.

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 licence et 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. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.
Table des matières
1. Introduction	2
1.1 Langage des exigences	3
1.2 Terminologie	3
1.3 Vue d'ensemble du réseau de transport	5
1.4 Vue d'ensemble de la couche réseau	6
2. Exigences de MPLS-TP	7
2.1 Exigences générales	7
2.2 Exigences de mise en couche	8
2.3 Exigences du plan des données	9
2.4 Exigences du plan de contrôle	10
2.5 Exigences de récupération	10
3. Exigences discutées dans d'autres documents	16
3.1 Exigences de gestion de réseau	16
3.2 Exigences de fonctionnement, administration, et maintenance (OAM)	16
3.3 Exigences de performances/surveillance du réseau	16
3.4 Exigences de sécurité	16
4. Considérations sur la sécurité	16
5. Remerciements	16
6. Références	17
6.1 Références normatives	17
8.2 Références pour information	17
Adresse des auteurs	18

 	1.	Introduction

La demande de bande passante continue de croître dans le monde, stimulée par la croissance accélérée et la pénétration de nouveaux services fondés sur le paquet et les applications multimédia :

o	Les services fondés sur le paquet comme Ethernet, voix sur IP (VoIP), réseaux privés virtuels (VPN, Virtual Private Network) de couche 2 (L2) / couche 3 (L3) la télévision sur IP (IPTV), la transmission sur réseau d'accès radio (RAN, Radio Access Network) etc.

o	Les applications avec diverses exigences de bande passante et de qualité de service (QS).

Cette croissance de la demande a résulté en une augmentation dramatique des débits d'accès qui sont, à leur tour, à l'origine d'augmentations spectaculaires des exigences de bande passante des réseaux métropolitains et de cœur.

Ces vingt dernières années, l'évolution de l'infrastructure de transport optique (réseau optique synchrone (SONET, Synchronous Optical Networking) / hiérarchie numérique synchrone (SDH, Synchronous Digital Hierarchy), réseau de transport optique (OTN, Optical Transport Network)) a donné des transporteurs de grande qualité pour la fiabilité et la simplicité de fonctionnement.

Avec le mouvement vers les services fondés sur le paquet, le réseau de transport doit évoluer pour prendre en compte les dispositions des capacités de prise en charge des paquets tout en permettant aux transporteurs de s'appuyer sur leurs investissements d'infrastructure de transport installée et programmée.

Les transporteurs ont besoin de technologies capables de prendre efficacement en charge les services et applications fondés sur le paquet sur leurs réseaux de transport avec des accords de niveau de service garanti (SLA, Service Level Agreement). Le besoin d'augmenter les revenus tout en restant compétitifs force les opérateurs à chercher le plus bas coût total de possession (TCO, Total Cost of Ownership) du réseau. Les investissements en équipements et facilités (dépenses en capital) et les dépenses de fonctionnement devraient être minimisées.

Il y a un certain nombre d'options technologiques pour que les transporteurs répondent au défi de l'augmentation de la sophistication des services et de l'efficacité du transport, avec un usage accru de solutions hybrides de technologies de transport de paquets et de transport de circuits. Pour atteindre ces objectifs, il est essentiel que la technologie de transport de paquets soit disponible et puisse supporter le même classement de qualité pour la fiabilité et la simplicité de fonctionnement qu'atteint par les technologies de SDH/SONET et OTN.

De plus, il est important pour les transporteurs que le fonctionnement de ces réseaux de transport de paquets préserve le rendu et le ressenti auxquels les transporteurs ont été habitués en déployant leurs réseaux de transport optique, tout en fournissant des opérations multi couches courantes, la résilience, le contrôle, et la gestion multi technologies.

Les transporteurs exigent le contrôle et un usage déterministe des ressources du réseau. Ils ont besoin d'un contrôle de bout en bout pour l'ingénierie des chemins du réseau et pour utiliser efficacement les ressources du réseau. Ils exigent des capacités pour prendre en charge le provisionnement statique (fondé sur le plan de gestion) ou dynamique (fondé sur le plan de contrôle) de services déterministes, protégés, et sécurisés et leurs ressources associées.

Il est aussi important de s'assurer d'un inter fonctionnement en douceur du réseau de transport de paquets avec les autres réseaux de paquets existants/traditionnels, et de fournir des transpositions pour permettre le transfert du transport de paquets sur diverses infrastructures de réseau de transport. Ce dernier a été appelé un interfonctionnement vertical, et est aussi connu comme interfonctionnement client/serveur ou réseau. Le premier a été appelé interfonctionnement horizontal, et est aussi connu comme interfonctionnement de partage d'homologues ou de services. Pour les détails sur l'interfonctionnement et certains problèmes qui peuvent survenir (en particulier avec l'interfonctionnement horizontal) voir [G.805] et [Y.1401].

La commutation d'étiquettes multi protocoles (MPLS, Multi-Protocol Label Switching) est une technologie de paquets émergente qui joue déjà un rôle important dans les réseaux et services de transport. Cependant, toutes les capacités et mécanismes de MPLS ne sont pas nécessaires et/ou cohérents avec les opérations d'un réseau de transport. Il y a aussi des caractéristiques de la technologie de transport qui ne sont pas actuellement reflétées dans MPLS. Donc, il est nécesaire de définir un profil de transport MPLS (MPLS-TP) qui prenne en charge les capacités et fonctionnalités nécessaires pour les services et opérations de réseau de transport de paquet en combinant l'expérience de paquet de MPLS avec l'expérience et les pratiques de fonctionnement des réseaux de transport existants.

MPLS-TP va permettre le déploiement de réseaux de transport fondés sur le paquet qui vont s'adapter efficacement pour prendre en charge des services de paquet d'une façon simple et économique. MPLS-TP combine les capacités nécessaires existantes de MPLS avec des mécanismes supplémentaires minimaux afin qu'il puisse être utilisé dans un rôle de transport.

Le présent document spécifie les exigences d'un profil de transport MPLS (MPLS-TP). Les exigences sont sur le comportement des mécanismes et procédures de protocole qui constituent les blocs de construction sur lesquels le profil de transport MPLS est construit. C'est-à-dire, les exigences indiquent quelles caractéristiques doivent être disponibles dans la trousse à outils de MPLS pour être utilisées par MPLS-TP. Les exigences dans ce document ne décrivent pas quelles fonctions prennent en charge une mise en œuvre de MPLS-TP. Le but de ce document est d'identifier la trousse à outils et tout le nouveau travail exigé pour le protocole.

Le présent document est un produit conjoint de l'UIT-T et de l'IETF pour inclure un profil de transport MPLS dans les architectures MPLS et PWE3 de l'IETF pour prendre en charge les capacités et fonctionnalités d'un réseau de transport de paquets comme défini par l'UIT-T. Le document est une spécification des exigences, mais est présenté sur la voie de la normalisation afin qu'il puisse peut être plus facilement cité comme référence normative provenant du travail de l'UIT-T.

Ce travail se fonde sur deux sources d'exigences, les architectures MPLS et PWE3 comme définies par l'IETF et les réseaux de transport de paquets comme définis par l'UIT-T. Les exigences de MPLS-TP sont fournies ci-dessous. Les fonctions pertinentes de MPLS et PWE3 sont incluses dans MPLS-TP, sauf lorsque elles sont explicitement exclues. Toute nouvelle fonctionnalité qui est définie pour satisfaire les exigences pour MPLS-TP doit faire l'objet d'un accord au sein de l'IETF au moyen du processus de consensus de l'IETF de la [RFC4929].

Les chemins de transport MPLS-TP peuvent être établis en utilisant une configuration statique ou dynamique. On devrait noter que le réseau MPLS-TP et ses chemins de transport peuvent toujours fonctionner pleinement (y compris OAM et les capacités de protection) en l'absence de tout plan de contrôle.

 	1.1	Langage des exigences
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119]. Bien que ce document ne soit pas une spécification de protocole, l'utilisation de ce langage précise les instructions des concepteurs de protocole qui produisent des solutions satisfaisant les exigences établies dans ce document.

 	1.2	Terminologie
Note : la transposition entre les termes de cette section et la terminologie de l'UIT-T est décrite dans la [RFC7087].

Les exigences de récupération dans ce document utilisent la terminologie de récupération définie dans la [RFC4427] ; ceci est appliqué aux opérations fondées sur le plan de contrôle et sur le plan de gestion des chemins de transport MPLS-TP.

 	1.2.1	Abréviations
ASON (Automatically Switched Optical Network) : réseau optique à commutation automatique
ATM (Asynchronous Transfer Mode) : mode de transfert asynchrone
CAPEX (Capital Expenditure) : dépenses en capital
CE (Customer Edge) : côté consommateur
FR (Frame Relay) : relais de trame
GMPLS (Generalized Multi-Protocol Label Switching) : commutation d'étiquettes multi protocoles généralisée
IGP (Interior Gateway Protocol) : protocole de passerelle intérieure
IPTV (IP Television) : télévision IP
L2 (Layer 2) : couche 2
L3 (Layer 3) : couche 3
LSP (Label Switched Path) : chemin de commutation d'étiquettes
LSR (Label Switching Router) : routeur de commutation d'étiquettes
MPLS (Multi-Protocol Label Switching) : commutation d'étiquettes multi protocoles
OAM (Operations, Administration, and Maintenance) : opérations, administration et maintenance
OPEX (Operational Expenditure) : dépenses de fonctionnement
OSI (Open Systems Interconnection) : interconnexion des systèmes ouverts
OTN (Optical Transport Network) : réseau de transport optique
P2MP (Point to Multipoint) : point à multipoints (diffusion)
P2P (Point to Point) : point à point
PDU (Protocol Data Unit) : unité de données de protocole
PSC (Protection State Coordination) : coordination de l'état de protection
PW (Pseudowire) : pseudo-filaire
QS : qualité de service
SDH (Synchronous Digital Hierarchy) : hiérarchie numérique synchrone
SLA (Service Level Agreement) : accord de niveau de service
SLS (Service Level Specification) : spécification de niveau de service
S-PE (Switching Provider Edge) : commutation côté fournisseur
SONET (Synchronous Optical Network) : réseau optique synchrone
SRLG (Shared Risk Link Group) : groupe de liaisons à risque partagé
TCO (Total Cost of Ownership) : coût total de possession
T-PE (Terminating Provider Edge) : terminaison côté fournisseur
VoIP (Voice over IP) : voix sur IP
VPN (Virtual Private Network) : réseau privé virtuel
WDM (Wavelength Division Multiplexing) : multiplexage par répartition en longueur d'onde

 	1.2.2	Définitions
Note : la définition de "segment" dans un contexte GMPLS/ASON (c'est-à-dire, comme défini dans la [RFC4397]) englobe à la fois "segment" et "segment enchaîné" comme défini dans ce document.

Chemin bidirectionnel associé : un chemin qui prend en charge des flux de trafic dans les deux directions mais est construit à partir d'une paire de chemins unidirectionnels (un pour chaque direction) qui sont associés à un autre au point d'entrée/sortie du chemin. Les directions vers l'avant et vers l'arrière sont établies, surveillées, et protégées indépendamment. Par conséquent, elles peuvent ou non suivre le même chemin (liaisons et nœuds) à travers le réseau.

Réseau de couche client : dans une relation client/serveur (voir [G.805]) le réseau de couche client reçoit un service (transport) du réseau de couche serveur inférieur (généralement le réseau de couche considéré).

Segment enchaîné : connexion de liaison composée en série comme défini 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 interconnectants en séquence. Voir aussi "Segment".

Plan de contrôle : dans le domaine d'application du présent document, le plan de contrôle effectue les fonctions de contrôle de chemin de transport. Par la signalisation, le plan de contrôle établit, modifie et libère les chemins de transport, et peut récupérer un chemin de transport en cas de défaillance. Le plan de contrôle effectue aussi d'autres fonctions à l'appui du contrôle du chemin de transport, comme la dissémination des informations d'acheminement.

Chemin bidirectionnel co-acheminé : chemin où les directions vers l'avant et vers l'arrière suivent la même route (liaisons et nœuds) à travers le réseau. Les deux directions sont établies, surveillées et protégées comme une seule entité. Un chemin de réseau de transport est normalement co-acheminé.

Domaine : un domaine représente une collection d'entités (par exemple des éléments de réseau) qui sont groupés pour un objet particulier, dont des exemples sont des responsabilités administratives et/ou de gestion, des relations de confiance, des schémas d'adressage, des capacités d'infrastructure, d'agrégation, des techniques de survie, des distributions de fonctions de contrôle, etc. Des exemples de tels domaines incluent des zones IGP et des systèmes autonomes.

Réseau de couche : réseau de couche est défini dans [G.805]. Un réseau de couche fournit le transfert des informations de client et de fonctionnement indépendant d'OAM de client. Un réseau de couche peut être décrit dans un contexte de service comme suit : un réseau de couche peut fournir un service de transport à un réseau de couche client supérieure et peut, à son tour, être un client de réseau de couche inférieure. Un réseau de couche est une construction logique un peu indépendante de l'arrangement ou de la composition des éléments du réseau physique. Un élément particulier de réseau physique peut appartenir topologiquement à plus d'un réseau de couche, selon les actions qu'il effectue sur l'encapsulation associée aux couches logiques (par exemple, la pile d'étiquettes) et donc pourrait être modélisé comme plusieurs éléments logiques. Un réseau de couche peut consister en une ou plusieurs sous couches. Le paragraphe 1.4 fournit une vue d'ensemble plus détaillée de ce qui constitue un réseau de couche. Pour des explications supplémentaires sur la façon dont les réseaux de couche se rapportent au concept OSI de mise en couches, voir l'Appendice I de [Y.2611].

Liaison : connexion physique ou logique entre une paire de LSR qui sont adjacents à la (sous couche réseau considérée. Une liaison peut porter zéro, un, ou plusieurs LSP ou PW. Un paquet entrant sur une liaison va émerger avec les mêmes valeurs d'entrée de pile d'étiquettes.

Anneau logique MPLS-TP : il est construit à partir d'un ensemble de LSR et de liaisons de données logiques (comme des tunnels de LSP MPLS-TP ou des pseudo filaires MPLS-TP) et des liaisons de données physiques qui forment une topologie d'anneau.

Chemin : voir chemin de transport.

Anneau physique MPLS-TP : il est construit à partir d'un ensemble de LSR et de liaisons de données physiques qui forment une topologie d'anneau.

Topologie d'anneau MPLS-TP : dans une topologie d'anneau MPLS-TP, chaque LSR est connecté à exactement deux autres LSR, chacun via une seule liaison point à point bidirectionnelle à capacité MPLS-TP. Un anneau peut aussi être construit à partir de seulement deux LSR où il y a aussi exactement deux liaisons. Les anneaux peuvent être connecté à d'autres LSR pour former un plus grand réseau. Le trafic qui a son origine ou sa terminaison en dehors de l'anneau peut être porté sur l'anneau. Des nœuds de réseau client (comme des CE) peuvent être connectés directement à un LSR dans l'anneau.

Réseau de couche section : une couche section est une couche serveur (qui peut être MPLS-TP ou d'une technologie différente) qui assure le transfert des informations de client de couche section entre des nœuds adjacents dans le chemin de couche transport ou de couche de service de transport. Une couche de section peut fournir l'agrégation de plusieurs clients MPLS-TP. Noter que [G.805] définit la couche section comme un des deux réseaux de couche 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 : une connexion de liaison comme défini dans [G.805]. Un segment est la partie d'un LSP qui traverse une seule liaison ou la partie d'un PW qui traverse une seule liaison (c'est-à-dire, qui connecte une paire de côtés fournisseur de{commutation|terminaison} adjacents). Voir aussi "Segment enchaîné".

Réseau de couche serveur : dans une relation client/serveur (voir [G.805]), le réseau de couche serveur fournit un service (de transport) au réseau de couche client supérieure (généralement le réseau de couche considéré).

Sous couche : défini dans [G.805]. La distinction entre un réseau de couche et une sous couche est qu'une sous couche n'est pas directement accessible aux clients en dehors de son réseau de couche encapsulant et n'offre pas de service de transport direct pour un réseau (client) de couche supérieure.

Côté fournisseur de commutation (S-PE, Switching Provider Edge) : voir la [RFC5659].

Côté fournisseur de terminaison (T-PE, Terminating Provider Edge) : voir la [RFC5659].

Chemin de transport : connexion réseau comme défini dans [G.805]. Dans un environnement MPLS-TP, un chemin de transport correspond à un LSP ou à un PW.

Couche de chemin de transport : une (sous) couche réseau qui fournit des chemins de transport en point à point ou en point à multi points. Elle fournit une OAM indépendante des clients qu'elle transporte.

Couche de service de transport : couche réseau dans laquelle les chemins de transport sont utilisés pour porter le service d'un consommateur (individuel ou groupé) (peuvent être des services en point à point, en point à multi points, ou en multi points à multi points).

Couche de transport de transmission : couche réseau, consistant en un réseau de couche de section et un réseau de couche physique comme défini dans [G.805], qui fournit des sections (connexions de deux accès en point à point) pour porter l'agrégation de chemins de réseau de transport ou les couches de réseau de service sur divers supports physiques.

Chemin unidirectionnel : chemin qui prend en charge le flux de trafic dans une seule direction.

 	1.3	Vue d'ensemble du réseau de transport
Le service de connexité est le service de base fourni par un réseau de transport. L'objet d'un réseau de transport est de porter le trafic des consommateurs (c'est-à-dire, le flux des PDU de consommateur ou les bits de consommateur, incluant les frais généraux) entre les points d'extrémité dans le réseau de transport (normalement sur plusieurs nœuds intermédiaires). Les services de connexité offerts aux consommateurs sont normalement agrégés dans de grands chemins de transport avec de longs temps de garde et l'OAM qui est indépendante (de l'OAM de client) qui contribue à permettre le fonctionnement efficace et fiable du réseau de transport. Ces chemins de transport ne sont pas modifiés fréquemment.

Des mécanismes de qualité de service sont exigés dans le réseau de transport de paquets pour assurer la priorité des services critiques, pour garantir la bande passante, et pour contrôler la gigue et le délai. Un réseau de transport doit fournir le moyen de satisfaire les objectifs de qualité de service de ses clients. Ceci est réalisé en fournissant un mécanisme pour la démarcation du service de réseau client pour le chemin de réseau avec un mécanisme associé de résilience du réseau.

L'agrégation est bénéfique pour réaliser l'adaptabilité et la sécurité car :
1.	Elle réduit le nombre d'états de provisionnement et de transmission dans le cœur de réseau.
2.	Elle réduit la charge et le coût de mise en œuvre de l'assurance de service et de gestion des fautes.
3.	Le trafic de consommateur est encapsulé et les frais généraux d'OAM associés à la couche sont ajoutés. Cela permet un isolement complet du trafic de consommateur et de sa gestion des opérations du transporteur.

Un important attribut d'un réseau de transport est qu'il est capable de fonctionner sans considération des clients qui utilisent son service de connexion ou sur quel support de transmission il fonctionne. Du point de vue fonctionnel et opérationnel, le client, le réseau de transport, et les couches de serveur sont des réseaux de couche indépendants. Une autre caractéristique clé des réseaux de transport est la capacité de maintenir l'intégrité du client à travers le réseau de transport. Un réseau de transport doit aussi fournir une méthode de surveillance du service afin de vérifier la fourniture d'une qualité de service acceptée. Ceci est réalisé au moyen d'outils OAM au niveau du transporteur.

Le trafic de consommateur est d'abord encapsulé au sein du réseau de couche de service de transport. Les signaux du réseau de couche de service de transport peuvent alors être agrégés dans le réseau de couche de chemin de transport pour le transport à travers le réseau afin d'optimiser la gestion du réseau. L'OAM du réseau de couche de service de transport est utilisée pour surveiller l'intégrité du transport du trafic de consommateur, et l'OAM du réseau de couche de chemin de transport est utilisée pour surveiller l'intégrité du transport des agrégats. À tout bond, les signaux agrégés peuvent être encore agrégés dans les chemins de réseau de transport de couche inférieure pour le transport à travers les liaisons intermédiaires partagées. Les signaux du réseau de couche de service de transport sont extraits aux bordures des domaines d'agrégation, et sont soit livrés au consommateur, soit transmis à un autre domaine. Dans le cœur du réseau, seuls les signaux de réseau de couche de chemin de transport sont surveillés aux points intermédiaires ; les signaux du réseau de couche de service de transport individuels sont surveillés à la frontière du réseau. Bien que la connexité du réseau de couche de service de transport puisse être en point à point, en point à multi points, ou en multi points à multi points, le réseau de couche de chemin de transport fournit seulement des chemins de transport en point à point ou en point à multi points, qui sont utilisés pour porter des agrégats de trafic de réseau de couche de service de transport.

 	1.4	Vue d'ensemble de la couche réseau
Un réseau de couche fournit à ses clients un service de transport et le fonctionnement du réseau de couche est indépendant de ce que le client utilise le réseau de couche. Les informations qui passent entre tout client au réseau de couche sont communes à tous les clients et sont le minimum nécessaire pour être cohérent avec la définition du service de transport offert. Le réseau de couche client peut être sans connexion, à commutation de paquets en mode connexion, ou à commutation de circuits. Le service de transport transfère une charge utile de telle sorte que le client peut remplir la charge utile sans affecter aucune opération au sein du réseau de couche de desserte. Ici, charge utile signifie :
o	une charge utile de paquet individuel (pour les réseaux sans connexion)
o	une séquence de charges utiles de paquet (pour les réseaux à commutation de paquets en mode connexion) ou
o	une programmation déterministe de charges utiles (pour les réseaux à commutation de circuits).

Les opérations au sein d'un réseau de couche qui sont indépendantes de ses clients incluent le contrôle de la transmission, le contrôle de la réservation de ressources, le contrôle de la dés-agrégation de trafic, et l'OAM et la récupération du service de transport. Touts ces opérations sont internes à un réseau de couche. Par définition, un réseau de couche ne s'appuie sur aucune information de client pour effectuer ces opérations, et donc toutes les informations exigées pour effectuer ces opérations sont indépendantes du client qui utilise le réseau de couche.

Un réseau de couche va avoir des caractéristiques cohérentes afin de prendre en charge le contrôle de la transmission, la réservation de ressources, l'OAM, et la récupération. Par exemple, un réseau de couche va avoir un schéma d'adressage commun pour les points d'extrémité du service de transport et un ensemble commun de descripteurs de transport pour le service de transport. Cependant, un client peut utiliser un schéma d'adressage différent ou des descripteurs de trafic différents (cohérent avec l'historique de performances).

Il est parfois utile de surveiller indépendamment un plus petit domaine au sein d'un réseau de couche (ou les services de transport qui traversent ce plus petit domaine) mais le contrôle de la transmission ou le contrôle de la réservation de ressources impliqués conservent leurs éléments communs. Ces plus petits domaines surveillés sont des sous couches.

Il est parfois utile de contrôler indépendamment la transmission dans un plus petit domaine au sein d'un réseau de couche, mais le contrôle de la réservation de ressources et de l'OAM conservent leurs éléments communs. Ces plus petits domaines sont des partitions du réseau de couche.

 	2.	Exigences de MPLS-TP

Les exigences de MPLS-TP établies dans cette section sont pour le comportement des mécanismes de protocole et les procédures qui constituent des blocs de construction à partir desquels le profil de transport MPLS est construit. C'est-à-dire, les exigences indiquent quelles caractéristiques sont disponibles dans la boîte à outils MPLS pour l'usage de MPLS-TP.

 	2.1	Exigences générales
1	Le plan de données MPLS-TP DOIT être un sous ensemble du plan de données MPLS comme défini par l'IETF. Quand MPLS offre plusieurs options à cet égard, MPLS-TP DEVRAIT choisir le sous ensemble minimum (sous ensemble nécessaire et suffisant) applicable à une application de réseau de transport.

2	La conception de MPLS-TP DEVRAIT autant que raisonnablement possible réutiliser les normes MPLS existantes.

3	Les mécanismes et capacités DOIVENT être capables d'inter opérer avec les plans de contrôle et de données existants MPLS [RFC3031] et PWE3 [RFC3985] de l'IETF lorsque approprié.
A.	L'interopérabilité du plan des données NE DOIT PAS exiger une fonction de passerelle.

4	MPLS-TP et ses interfaces, internes et externes, DOIVENT être suffisamment bien définis pour que l'inter fonctionnement d'équipements fournis par plusieurs fabricants soit possible au sein d'un seul domaine et entre domaines.

5	MPLS-TP DOIT être une technologie en mode connexion de commutation de paquets avec des capacités d'ingénierie du trafic qui permette un contrôle déterministe de l'utilisation des ressources du réseau.

6	MPLS-TP DOIT prendre en charge des chemins de transport avec ingénierie du trafic en point à point (P2P) et en point à multipoint (P2MP).

7	MPLS-TP DOIT prendre en charge des chemins de transport unidirectionnels, bidirectionnels co-acheminés, et bidirectionnels associés en point à point.

8	MPLS-TP DOIT prendre en charge des chemins de transport unidirectionnels en point à multipoints.

9	Les points d'extrémité d'un chemin de transport bidirectionnel co-acheminé DOIVENT être informés de la relation d'appariement des chemins vers l'avant et inverse utilisés pour prendre en charge le service bidirectionnel.

10	Tous les nœuds sur le chemin d'un chemin de transport bidirectionnel co-acheminé dans la même (sous)couche que le chemin DOIVENT être informés de la relation d'appariement des directions vers l'avant et l'arrière du chemin de transport.

11	Les points d'extrémité d'un chemin de transport bidirectionnel associé DOIVENT être informés de la relation d'appariement des chemins vers l'avant et inverse utilisés pour prendre en charge le service bidirectionnel.

12	Les nœuds sur le chemin d'un chemin de transport bidirectionnel associé où les deux directions vers l'avant et vers l'arrière transitent par le même nœud dans la même (sous)couche que le chemin DEVRAIT être informés de la relation d'appariement des directions vers l'avant et vers l'arrière du chemin de transport.

13	MPLS-TP DOIT prendre en charge les chemins de transport bidirectionnels avec des exigences de bande passante symétriques, c'est-à-dire, la quantité de bande passante réservée est la même dans les directions vers l'avant et vers l'arrière.

14	MPLS-TP DOIT prendre en charge les chemins de transport bidirectionnels avec des exigences de bande passante asymétriques, c'est-à-dire, la quantité de bande passante réservée diffère entre les directions avant et arrière

15	MPLS-TP DOIT prendre en charge la séparation logique des plans de contrôle et de gestion du plan des données.

16	MPLS-TP DOIT prendre en charge la séparation physique des plans de contrôle et de gestion du plan des données. C'est-à-dire, il doit être possible de faire fonctionner les plans de contrôle et de gestion hors bande, et aucune hypothèse ne devrait être faite sur l'état des canaux de plan des données à partir des informations sur les canaux du plan de contrôle ou de gestion quand ils fonctionnent hors bande.

17	MPLS-TP DOIT prendre en charge le provisionnement statique des chemins de transport via le plan de gestion.

18	Une solution DOIT être définie pour prendre en charge le provisionnement et la restauration dynamique des chemins de transport MPLS-TP via un plan de contrôle.

19	Le provisionnement statique NE DOIT PAS dépendre de la présence d'un élément d'un plan de contrôle.

20	MPLS-TP DOIT prendre en charge la coexistence de chemins de transport MPLS-TP provisionnés/gérés de façon statique et dynamique au sein du même réseau de couche ou domaine.

21	Les mécanismes dans un réseau de couche MPLS-TP qui satisfont les exigences fonctionnelles communes aux réseaux généraux de couche de transport (c'est-à-dire, indépendantes de la technologie) DEVRAIENT fonctionner d'une façon similaire à celle des mécanismes équivalents dans les autres technologies de couche transport.

22	MPLS-TP DOIT prendre en charge la capacité de fonctionnement du réseau via le plan de gestion (sans l'utilisation de protocole de plan de contrôle). Cela inclut la configuration et le contrôle des fonctions d'OAM et de récupération.

23 	Le plan des données MPLS-TP DOIT être capable de
A.	transmettre les données indépendamment du plan de contrôle ou de gestion utilisé pour configurer et faire fonctionner le réseau de couche MPLS-TP,
B.	prendre des actions de récupération indépendantes du plan de contrôle ou de gestion utilisé pour configurer le réseau de couche MPLS-TP,
C.	fonctionner normalement (c'est-à-dire, la transmission, l'OAM, et la protection DOIVENT continuer d'opérer) si le plan de gestion ou le plan de contrôle qui ont configuré les chemins de transport sont défaillants.

24	MPLS-TP DOIT prendre en charge des mécanismes pour éviter ou minimiser l'impact sur le trafic (par exemple, retard, réarrangement, et perte des paquets) durant la reconfiguration de réseau.

25	MPLS-TP DOIT prendre en charge les chemins de transport à travers plusieurs domaines homogènes.

26	MPLS-TP DEVRAIT prendre en charge les chemins de transport à travers plusieurs domaines non homogènes.

27	MPLS-TP NE DOIT PAS imposer le déploiement d'une topologie de réseau particulière, physique ou logique, cependant :
A.	il DOIT être possible de déployer MPLS-TP en anneaux,
B.	il DOIT être possible de déployer MPLS-TP en anneaux arbitrairement interconnectés avec un ou deux points d'interconnexion,
C.	MPLS-TP DOIT prendre en charge des anneaux d'au moins 16 nœuds afin de prendre en charge la mise à niveau des anneaux existant de multiplexage à répartition dans le temps (TDM) en MPLS-TP. MPLS-TP DEVRAIT prendre en charge des anneaux avec plus de 16 nœuds.

28	MPLS-TP DOIT être capable de s'adapter au moins aussi bien que les technologies de transport existantes avec les topologies de réseau en croissance et de plus en plus complexes ainsi qu'avec des quantités croissantes de consommateurs, services, et demande de bande passante.

29	MPLS-TP DEVRAIT prendre en charge des mécanismes pour se garder contre le provisionnement de chemins de transport qui contiennent des boucles de transmission.

 	2.2	Exigences de mise en couche
30	Une solution générique et extensible DOIT être fournie pour prendre en charge le transport d'un ou plusieurs réseaux de couche client (par exemple, MPLS-TP, IP, MPLS, Ethernet, ATM, FR, etc.) sur un réseau de couche MPLS-TP.

31	Une solution générique et extensible DOIT être fournie pour prendre en charge le transport de chemins de transport MPLS-TP sur un ou plusieurs réseaux de couche serveur (comme MPLS-TP, Ethernet, SONET/SDH, OTN, etc.). Les exigences de gestion de bande passante au sein d'un réseau de couche serveur sortent du domaine d'application du présent document.

32	Dans un environnement où un réseau de couche MPLS-TP prend en charge un réseau de couche client, et où le réseau de couche MPLS-TP est pris en charge par un réseau de couche serveur, alors le fonctionnement du réseau de couche MPLS-TP DOIT être possible sans dépendre du réseau de couche serveur ou client.
A.	La couche serveur DOIT garantir que la charge de trafic imposée par les autres clients ne cause pas la chute du service de transport fourni à la couche MPLS-TP en dessous du niveau accepté. Les mécanismes pour réaliser cela sortent du domaine d'application de ces exigences.
B.	Il DOIT être possible d'isoler les plans de contrôle et de gestion du réseau de couche MPLS-TP des plans de contrôle et de gestion des réseaux de couche client et serveur.

33	Une solution DOIT être fournie pour prendre en charge le transport d'un client MPLS ou d'un réseau de couche MPLS-TP sur un serveur MPLS ou réseau de couche MPLS-TP.
A.	Le niveau de coordination exigé entre les réseaux de couche client et serveur MPLS(-TP) DOIT être minimisé (de préférence, aucune coordination ne va être exigée).
B.	Le réseau de couche serveur MPLS(-TP) DOIT être capable de transporter l'ensemble complet de paquets générés par le réseau de couche client MPLS(-TP) qui peut contenir des paquets qui ne sont pas des paquets MPLS (par exemple, des paquets IP ou de protocole de réseau sans connexion (CNLP, Connectionless Network Protocol) utilisés par le plan de contrôle/gestion du réseau de couche du client MPLS(-TP)).

34	Il DOIT être possible de faire fonctionner de façon autonome les couches d'un multi-réseaux de couche qui inclut une couche MPLS-TP.

Les exigences ci-dessus ne sont pas seulement des exigences de technologie, mais aussi des exigences opérationnelles. Des groupes administratifs différents peuvent être responsables du même réseau de couche ou de différents réseaux de couche.

35	Il DOIT être possible de cacher l'adressage et les autres informations d'un réseau de couche MPLS-TP (par exemple, la topologie) aux réseaux de couche clients. Cependant, il DEVRAIT être possible, à la discrétion de l'opérateur, de laisser fuir une quantité limitée d'informations résumées (comme les SRLG ou l'accessibilité) entre les couches.

 	2.3	Exigences du plan des données
36	Il DOIT être possible de faire fonctionner et configurer le plan de données MPLS-TP sans aucune capacité de transmission IP dans le plan des données MPLS-TP. C'est-à-dire, le plan des données opère seulement sur l'étiquette MPLS.

37	Il DOIT être possible aux points d'extrémité d'un chemin de transport MPLS-TP qui porte un agrégat de chemins de transport clients d'être capable de décomposer le chemin de transport agrégé en ses chemins de transport clients composants.

38	Un chemin de transport sur une liaison DOIT être identifiable de façon univoque par une seule étiquette sur cette liaison.

39	La source d'un chemin de transport DOIT être identifiable à sa destination au sein de son réseau de couche.

40	MPLS-TP DOIT être capable d'utiliser des capacités de (sous)couche serveur P2MP ainsi que P2P serveur quand des chemins de transport P2MP MPLS-TP sont pris en charge.

41	MPLS-TP DOIT être extensible afin de s'accommoder de nouveaux types de réseaux et services de couche client.

42	MPLS-TP DEVRAIT prendre en charge des mécanismes pour permettre d'augmenter la bande passante réservée associée à un chemin de transport sans impacter le trafic existant sur ce chemin de transport pourvu qu'assez de ressources soient disponibles.

43	MPLS-TP DEVRAIT prendre en charge des mécanismes pour permettre de diminuer la bande passante réservée associée à un chemin de transport sans impacter le trafic existant sur ce chemin de transport pourvu que le niveau de trafic existant soit inférieur à la bande passante réservée suite à la diminution.

44	MPLS-TP DOIT prendre en charge des mécanismes qui assurent l'intégrité du trafic de service du consommateur transporté comme exigé par son SLA associé. La perte d'intégrité peut être définie comme une corruption, réarrangement, ou perte de paquet durant les conditions normales du réseau.

45	MPLS-TP DOIT prendre en charge des mécanismes pour détecter quand la perte de l'intégrité du trafic de service du consommateur transporté s'est produite.

46	MPLS-TP DOIT prendre en charge un moyen sans ambiguïté et fiable de distinguer les paquets d'utilisateur (client) des paquets de contrôle MPLS-TP (par exemple, de plan de contrôle, de plan de gestion, d'OAM, et de commutation de protection).

 	2.4	Exigences du plan de contrôle
Ce paragraphe définit les exigences qui s'appliquent à un plan de contrôle MPLS-TP. Noter qu'il DOIT être possible de faire fonctionner un réseau MPLS-TP sans utiliser un plan de contrôle.

L'UIT-T a défini une architecture pour les réseaux optiques à commutation automatique (ASON, Automatically Switched Optical Network) dans [G.8080] et G.8080 Amendement 1 [G.8080.1]. Le plan de contrôle pour MPLS-TP DOIT tenir dans l'architecture ASON.

Une interprétation des exigences de signalisation et d'acheminement ASON dans le contexte de GMPLS s trouve dans les [RFC4139] et [RFC4258].

De plus:

47	Le plan de contrôle MPLS-TP DOIT prendre en charge l'indépendance de la topologie du plan de contrôle et du plan de données. Par conséquent, une défaillance du plan de contrôle n'implique pas qu'il y ait aussi une défaillance du plan des données.

48	Le plan de contrôle MPLS-TP DOIT être capable de fonctionner indépendamment de tout plan de contrôle de couche client ou serveur particulier.

49	MPLS-TP DEVRAIT définir une solution pour prendre en charge un plan de contrôle intégré englobant MPLS-TP avec ses réseaux de couche serveur et client quand ces réseaux de couche appartiennent au même domaine administratif.

50	Le plan de contrôle MPLS-TP DOIT prendre en charge l'établissement de tous les schémas de connexité définis pour le plan des données MPLS-TP (c'est-à-dire, P2P unidirectionnel, P2P bidirectionnel associé, P2P bidirectionnel co-acheminé, P2MP unidirectionnel) incluant la configuration des fonctions de protection et de toutes les fonctions de maintenance associées.

51	Le plan de contrôle MPLS-TP DOIT prendre en charge la configuration et la modification des points de maintenance OAM ainsi que l'activation/désactivation d'OAM quand le chemin de transport ou le service de transport est établi ou modifié.

52	Un plan de contrôle MPLS-TP DOIT prendre en charge le fonctionnement des opérations de récupération décrites au paragraphe 2.8.

53	Un plan de contrôle MPLS-TP DOIT s'adapter en douceur pour prendre en charge un grand nombre de chemins de transport, nœuds, et liaisons.

54	Si un plan de contrôle est utilisé pour MPLS-TP, à la suite d'une défaillance de plan de contrôle, le plan de contrôle DOIT être capable de redémarrer et de réapprendre son état précédent sans impacter la transmission.

55	Un plan de contrôle MPLS-TP DOIT fournir un mécanisme pour le transfert dynamique de possession du contrôle des chemins de transport MPLS-TP du plan de gestion au plan de contrôle et vice versa. Le nombre de reconfigurations exigées dans le plan des données DOIT être minimisé (de préférence aucune reconfiguration du plan des données ne sera exigée).

 	2.5	Exigences de récupération
La capacité de survie du réseau joue un rôle critique dans la fourniture de services fiables. La disponibilité du réseau est un contributeur significatif aux revenus et au profit. Les garanties de service sous la forme de SLA exigent un réseau résilient qui détecte rapidement les défaillances de facilité ou de nœud et restaure le fonctionnement du réseau en accord avec les termes du SLA.

56	MPLS-TP DOIT fournir des mécanismes de protection et restauration.
A.	Les techniques de récupération MPLS-TP DEVRAIENT être identiques (ou aussi similaires que possible) à celles déjà utilisées dans les réseaux de transport existants pour simplifier la mise en œuvre et le fonctionnement. Cependant, ceci NE DOIT PAS outrepasser d'autres exigences.
B.	Les techniques de récupération utilisées pour P2P et P2MP DEVRAIENT être identiques pour simplifier la mise en œuvre et le fonctionnement. Cependant, ceci NE DOIT PAS outrepasser d'autres exigences.

57	Les mécanismes de récupération MPLS-TP DOIVENT être applicables à divers niveaux à travers le réseau, y compris la prise en charge de la récupération de liaison, chemin de transport, segment, segment enchaîné, et de bout en bout.

58	Les chemins de récupération MPLS-TP DOIVENT satisfaire les objectifs de protection de SLA du service.
A.	MPLS-TP DOIT fournir des mécanismes pour garantir un temps de récupération de 50 ms entre le moment de détection de la faute dans les réseaux avec une portée de moins de 1200 km.
B.	Pour la protection il DOIT être possible d'exiger la protection de 100 % du trafic sur le chemin protégé.
C.	La récupération DOIT satisfaire les exigences de SLA sur plusieurs domaines.

59	Les objectifs de récupération DEVRAIENT être configurables par chemin de transport.

60	Les mécanismes de récupération DEVRAIENT être applicables à toute topologie.

61	Les mécanismes de récupération DOIVENT prendre en charge les moyens de fonctionner en synergie avec (incluant la synchronisation) des mécanismes de récupération présents dans tout réseau de transport client ou serveur (par exemple, Ethernet, SDH, OTN, WDM) pour éviter des conditions de concurrence entre les couches.

62	Les mécanismes MPLS-TP de récupération et inversion DOIVENT empêcher des fréquentes opérations de récupération en cas de défaut intermittent.

 	2.5.1	Exigences de comporement du plan des données
Les exigences générales de protection et de survie sont exprimées en termes de comportement au plan des données.

 	2.5.1.1	Protection
Note : seuls les nœuds qui connaissent la relation d'appariement entre les directions vers l'avant et vers l'arrière d'un chemin  de transport bidirectionnel associé peuvent être utilisés comme des points d'extrémité pour protéger tout ou partie de ce chemin de transport.

63	Il DOIT être possible de fournir la protection du plan des données MPLS-TP sans aucune capacité de transmission IP dans le plan des données MPLS-TP. C'est-à-dire, le plan des données opère seulement sur les étiquettes MPLS.

64	Les mécanismes de protection MPLS-TP DOIVENT prendre en charge un comportement réversible et non réversible.

65	MPLS-TP DOIT prendre en charge la protection 1+1.
A.	La protection bidirectionnelle 1+1 pour la connexité P2P DOIT être prise en charge.
B.	La protection unidirectionnelle 1+1 pour la connexité P2P DOIT être prise en charge.
C.	La protection unidirectionnelle 1+1 pour la connexité P2MP DOIT être prise en charge.

66	MPLS-TP DOIT prendre en charge la capacité de partager les ressources de protection entre un certain nombre de chemins de transport.

67	MPLS-TP DOIT prendre en charge la protection 1:n (incluant la protection 1:1).
A.	La protection bidirectionnelle 1:n pour la connexité P2P DOIT être prise en charge et DEVRAIT être le comportement par défaut pour la protection 1:n.
B.	La protection unidirectionnelle 1:n pour la connexité P2MP DOIT être prise en charge.
C.	La protection unidirectionnelle 1:n pour la connexité P2P n'est pas exigée et PEUT être omise des spécifications MPLS-TP.
D.	L'action de commutation de protection NE DOIT PAS causer l'entrée des données d'utilisateur dans une boucle incontrôlée. Le système de commutation de protection PEUT causer le passage du trafic sur une liaison données plus d'une fois, mais elle doit le faire de façon contrôlée afin que des boucles incontrôlées ne se forment pas.

Note: La prise en charge de trafic supplémentaire (comme défini dans la [RFC4427]) n'est pas exigée dans MPLS-TP et PEUT être omise des spécifications de MPLS-TP.

 	2.5.1.2	Partage des ressources de protection
68	MPLS-TP DEVRAIT prendre en charge la récupération de maillage partagé 1:n (incluant 1:1).

69	MPLS-TP DOIT prendre en charge le partage des ressources de protection telles que les chemins de protection qui sont connus pour être exigés concurremment puissent partager les mêmes ressources.

 	2.5.2	Restauration
70	La restauration de chemin de transport DOIT être capable de partager les ressources avec le chemin de transport remplacé (parfois appelé réacheminement en douceur).

71	La priorité de restauration DOIT être prise en charge de telle façon qu'une mise en œuvre puisse déterminer l'ordre dans lequel les chemins de transport devraient être restaurés (pour minimiser le temps de restauration de service ainsi que pour obtenir l'accès aux capacités de réserve disponibles sur les meilleurs chemins).

72	La priorité de préemption DOIT être prise en charge pour permettre à la restauration de déplacer les autres chemins de transport en cas de contraintes de ressources.

73	Les mécanismes de restauration de MPLS-TP DOIVENT prendre en charge le comportement réversible et non réversible.

 	2.5.3	Déclenchement de la protection, restauration, et inversion
Les actions de restauration peuvent être déclenchées à partir d'endroits différents comme suit :

74	MPLS-TP DOIT prendre en charge le déclenchement d'indication de faute à partir des couches inférieures. Cela inclut les fautes détectées et rapportées par les protocoles de couche inférieure, et les fautes rapportées directement par le support physique (par exemple, la perte de courant).

75	MPLS-TP DOIT prendre en charge les déclenchements fondés sur l'OAM.

76	MPLS-TP DOIT prendre en charge les déclenchements du plan de gestion (par exemple, commutations forcées, etc.).

77	Il DOIT y avoir un mécanisme pour distinguer les actions de récupération administrative des actions de récupération initiées par d'autres déclenchements.

78	Lorsque un plan de contrôle est présent, MPLS-TP DEVRAIT prendre en charge les déclenchement de restauration du plan de contrôle.

79	Les mécanismes de protection MPLS-TP DOIVENT prendre en charge la logique de priorité pour négocier et traiter des demandes coexistantes (c'est-à-dire, plusieurs demandes) de commutation de protection (par exemple, demandes administratives et demandes dues à des défaillances de liaison/nœud).

 	2.5.4	Fonctionnement au plan de gestion de la protection et de la restauration
Toutes les fonctions décrites ici sont sous le contrôle de l'opérateur.

80	Il DOIT être possible de configurer des chemins de protection et des relations de chemin de protection à chemin actif (parfois appelées de groupes de protection).

81	Le pré calcul des chemins de récupération DOIT être pris en charge.

82	Le pré-provisionnement des chemins de récupération DOIT être pris en charge.

83	Les contrôles externes comme définis dans la [RFC4427] DOIVENT être pris en charge.
A.	Les contrôles externes outrepassés par des demandes de priorité supérieure (par exemple, des demandes administratives et des demandes dues à des défaillances de liaison/nœud) ou incapables d'être signalés à l'extrémité distante (par exemple, dus à un échec de coordination de l'état de protection) DOIVENT être éliminés.

84	Il DOIT être possible de vérifier et valider tout mécanisme et protocole de protection/restauration :
A.	incluant l'intégrité du chemin de transport de protection/récupération,
B.	sans déclencher la protection/restauration réelle,
C.	pendant que le chemin actif est en service,
D.	pendant que le chemin actif est hors service.

85	La restauration de ressources PEUT être pré-planifiée et choisie à priori, ou calculée après l'occurrence d'une défaillance.

86	Quand la préemption est prise en charge pour les besoins de la restauration, il DOIT être possible à l'opérateur de la configurer.

87	Le plan de gestion DOIT fournir des indications des événements et déclencheurs de protection.

88	Le plan de gestion DOIT permettre de déterminer l'état de protection actuel de tous les chemins de transport.

 	2.5.5	Fonctionnement OAM au plan de contrôle et dans la bande de la récupération
89	Le plan de contrôle MPLS-TP (qui n'est pas obligatoire dans une mise en œuvre de MPLS-TP) DOIT être capable de prendre en charge :
A.	l'établissement et la maintenance de toutes les entités et fonctions de récupération,
B.	la signalisation du contrôle administratif,
C.	la coordination de l'état de protection (PSC). Comme la topologie du plan de contrôle du réseau est indépendante de celle du plan des données du réseau, la PSC prise en charge par le plan de contrôle MPLS-TP PEUT fonctionner sur des ressources différentes de celles du plan des données traitées au sein du mécanisme de récupération (par exemple, une sauvegarde).

90	L'OAM dans la bande DOIT être capable de prendre en charge :
A.	la signalisation du contrôle administratif,
B.	la coordination de l'état de protection (PSC). Comme les outils d'OAM dans la bande partagent le plan des données avec le service de transport porté, afin d'optimiser l'usage des ressources du réseau, la PSC prise en charge par l'OAM dans la bande DOIT fonctionner sur les ressources de protection.

 	2.5.6	Mécanismes de récupération spécifiques de la topologie
91	MPLS-TP PEUT prendre en charge des mécanismes de récupération qui sont optimisés pour des topologies de réseau spécifiques. Ces mécanismes DOIVENT être interopérables avec les mécanismes définis pour des réseaux de topologie arbitraire (maillés) pour permettre la protection de bout en bout des chemins de transport.

 	2.5.6.1	Protection d'anneau
Plusieurs fournisseurs de services ont exprimé un haut niveau d'intérêt pour fonctionner avec des topologies d'anneau MPLS-TP et exigent un haut niveau de fonctions de survie dans ces topologies. Les exigences mentionnées ci-dessous ont été collectées de ces fournisseurs de services et auprès de l'UIT-T.

Le principal objectif de l'examen d'une topologie spécifique (comme un anneau) est de déterminer si il est possible d'optimiser des mécanismes tels que les performances de ces mécanismes au sein de la topologie soient significativement meilleures que les performances des mécanismes génériques dans la même topologie. Les avantages de telles optimisations sont un compromis avec les coûts de développement, de mise en œuvre, de déploiement, et de fonctionnement des mécanismes optimisés supplémentaires en notant que les mécanismes génériques DOIVENT continuer d'être pris en charge.

Dans le contexte de la récupération dans les réseaux MPLS-TP, les critères d'optimisation considérés dans les topologies d'anneau sont les suivantes :

a.	Minimiser le nombre d'entités d'OAM nécessaires pour déclencher l'opération de récupération, de telle façon que ce soit moins que ce qui est exigé par les autres mécanismes de récupération.

b.	Minimiser le nombre d'éléments de récupération dans l'anneau, de telle façon que ce soit moins que ce qui est exigé par les autres mécanismes de récupération.

c.	Minimiser le nombre d'étiquettes exigé pour la protection des chemins à travers l'anneau, de telle façon que ce soit moins que ce qui est exigé par les autres mécanismes de récupération.

d.	Minimiser la quantité de transactions de plan de contrôle et de gestion durant une opération de maintenance (par exemple, une mise à niveau de l'anneau) de telle façon que ce soit moins que ce qui est exigé par les autres mécanismes de récupération.

e.	Quand un plan de contrôle est pris en charge, minimiser l'impact sur l'échange de signalisation et d'informations d'acheminement durant la protection, de telle façon qu'il y ait moins d'impact que celui causé par les autres mécanismes de récupération.

On peut observer que les exigences du paragraphe 2.5.6.1 sont pleinement compatibles avec les exigences génériques exprimées dans les paragraphes 2.5 à 2.5.6 inclus, et qu'aucune exigence spécifique des topologies d'anneau n'a été identifiée.

92	MPLS-TP DOIT inclure des mécanismes de récupération qui opèrent dans un seul anneau pris en charge dans MPLS-TP, et continuer de fonctionner au sein des mêmes anneaux même quand ils sont interconnectés.

93	Quand un réseau est construit à partir d'anneaux interconnectés, MPLS-TP DOIT prendre en charge des mécanismes de récupération qui protègent les données d'utilisateur traversant plus d'un anneau. Cela inclut la possibilité de défaillance des nœuds et liaisons de l'anneau interconnecté.

94	La récupération MPLS-TP dans un anneau DOIT protéger les chemins de transport P2P unidirectionnels et bidirectionnels.

95	La récupération MPLS-TP dans un anneau DOIT protéger les chemins de transport P2MP unidirectionnels.

96	La protection MPLS-TP 1+1 et 1:1 dans un anneau DOIT prendre en charge le temps de commutation dans les 50 ms à partir du moment de la détection de faute dans un réseau avec un anneau de 16 nœuds avec moins de 1200 km de fibre.

97	Le temps de commutation de protection dans un anneau DOIT être indépendant du nombre de LSP traversant l'anneau.

98	La configuration et le fonctionnement des mécanismes de récupération dans un anneau DOIVENT bien s'adapter avec:
A.	le nombre de chemins de transport (DOIT être meilleur qu'une adaptation linéaire)
B.	le nombre de nœuds dans l'anneau (DOIT être au moins aussi bon qu'une adaptation linéaire)
C.	le nombre d'anneaux interconnectés (DOIT être au moins aussi bon qu'une adaptation linéaire).

99	Les techniques de récupération utilisées dans un anneau NE DOIVENT PAS empêcher l'anneau d'être connecté à un réseau général MPLS-TP d'une façon arbitraire, et NE DOIVENT PAS empêcher le fonctionnement des techniques de récupération dans le reste du réseau.

100	Les techniques de récupération dans un anneau DEVRAIT être identiques (ou aussi similaires que possible) de celles des réseaux généraux de transport pour simplifier la mise en œuvre et les opérations. Cependant, ceci NE DOIT PAS outrepasser d'autres exigence.

101	Les techniques de récupération dans les anneaux logiques et physiques DEVRAIENT être identiques pour simplifier la mise en œuvre et le fonctionnement. Cependant, ceci NE DOIT PAS outrepasser d'autres exigences.

102	Le schéma de récupération par défaut dans un anneau DOIT être la récupération bidirectionnelle afin de simplifier l'opération de récupération.

103	Le mécanisme de récupération dans un anneau DOIT prendre en charge la commutation réversible, qui DOIT être le comportement par défaut. Cela permet l'optimisation de l'utilisation des ressources de l'anneau, et restaure les conditions de qualité préférées pour le trafic normal (par exemple, de délai) quand le mécanisme de récupération n'est plus nécessaire.

104	Les mécanismes de récupération dans un anneau DOIVENT prendre en charge la façon de distinguer la commutation de protection administrative de la commutation de protection initiée par d'autres déclencheurs.

105	Il DOIT être possible de verrouiller (désactiver) les mécanismes de protection sur des liaisons choisies (portées) dans un anneau (selon les besoins de l'opérateur). Cela peut exiger que les mécanismes de verrouillage soient appliqués aux  nœuds intermédiaires au sein d'un chemin de transport.

106	Les mécanismes MPLS-TP de récupération dans un anneau :
A.	DOIVENT inclure un mécanisme pour permettre à une mise en œuvre de traiter et coordonner les demandes ou déclencheurs coexistants pour la commutation de protection fondée sur la priorité. (Par exemple, cela inclut plusieurs demandes qui ne sont pas nécessairement arrivées simultanément et sont situées n'importe où dans l'anneau.) Noter qu'une telle coordination de l'anneau est équivalente à l'utilisation de groupes de protection partagés.
B.	DEVRAIENT protéger contre plusieurs défaillances

107	Les mécanismes MPLS-TP de récupération et d'inversion dans un anneau DOIVENT offrir un moyen d'empêcher de fréquentes opérations de récupération en cas de défaut intermittent.

108	MPLS-TP DOIT prendre en charge le partage de la bande passante de protection dans un anneau en permettant le trafic au mieux.

109	MPLS-TP DOIT prendre en charge le partage des ressources de protection de l'anneau de telle façon que les chemins de protection qui sont connus pour être exigés concurremment puissent partager les mêmes ressources.

 	2.6	Exigences de qualité de service
Les transporteurs exigent des capacités avancées de gestion du trafic pour appliquer et garantir les paramètres de QS des SLA des consommateurs.

Les mécanismes de qualité de service sont EXIGÉS dans un réseau MPLS-TP pour assurer :

110	La prise en charge de services différenciés et de types de trafic différents avec la séparation de classe de trafic associée aux différents trafics.

111	Permettre le provisionnement et la garantie des spécifications de niveau de service (SLS, Service Level Specification) avec la prise en charge de garantie de bande passante ferme et relative de bout en bout.

112	La prise en charge de services sensibles à la gigue et au délai.

113	La garantie d'un accès équitable, au sein d'une classe particulière, aux ressources partagées.

114	La garantie de ressources pour le trafic dans la bande de plan de contrôle et de gestion, sans considération de la quantité de trafic du plan de données.

l15	Les transporteurs ont la capacité de prendre efficacement en charge les demandes de service sur le réseau MPLS-TP.  Cela DOIT inclure la prise en charge d'un schéma d'allocation souple de bande passante.

 	3.	Exigences discutées dans d'autres documents
 	3.1	Exigences de gestion de réseau
Pour les exigences relatives à la fonction de gestion du réseau (le plan de gestion dans la terminologie de l'UIT-T) pour MPLS-TP, voir le document des exigences de gestion de réseau MPLS-TP [RFC5950].

 	3.2	Exigences de fonctionnement, administration, et maintenance (OAM)
Pour les exigences relatives à la fonction d'OAM pour MPLS-TP, voir le document des exigences d'OAM MPLS-TP [RFC5860].

 	3.3	Exigences de performances/surveillance du réseau
Pour les exigences relatives à la fonction de surveillance des performances pour MPLS-TP, voir le document des exigences d'OAM MPLS-TP [RFC5860].

 	3.4	Exigences de sécurité
Pour une description des menaces sur la sécurité pertinentes dans le contexte de MPLS et GMPLS et les techniques défensives pour combattre ces menaces, voir le "cadre de sécurité pour les réseaux MPLS et GMPLS" [RFC5920].

Pour une description des menaces supplémentaires sur la sécurité pertinentes dans le contexte de MPLS-TP et les techniques de défense pour combattre ces menaces, voir le "cadre de sécurité pour MPLS-TP" [RFC6941].

 	4.	Considérations sur la sécurité

Voir le paragraphe 3.4.

 	5.	Remerciements

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

Les auteurs tiennent aussi à remercier Loa Andersson, Dieter Beller, Lou Berger, Italo Busi, John Drake, Adrian Farrel, Annamaria Fulignoli, Pietro Grandi, Eric Gray, Neil Harrison, Jia He, Huub van Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Andy Malis, Alan McGuire, Julien Meuric, Greg Mirsky, Tom Nadeau, Hiroshi Ohta, Tom Petch, Andy Reid, Vincenzo Sestito, George Swallow, Lubo Tancevski, Tomonori Takeda, Yuji Tochio, Alexander Vainshtein, Eve Varma, et Maarten Vissers de leurs commentaires et améliorations au texte.

Un groupe de discussion ad hoc comprenant Stewart Bryant, Italo Busi, Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort, Feng Huang, Harald Kullman, Han Li, Hao Long, et Nurit Sprecher a fournit de précieux apports aux exigences pour le déploiement et la survie dans les topologies d'anneaux.

 	6.	Références
 	6.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. 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)

[RFC3985]	S. Bryant et autres, "Architecture d'émulation bord à bord pseudo-filaire (PWE3)", mars 2005. (Information)

[RFC4929]	L. Andersson et autres, "Processus de changement des protocoles et procédures du MPLS et GMPLS", juin 2007. (BCP0129)

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

[G.8080]	Recommandation UIT-T G.8080, "Architecture pour le réseau optique à commutation automatique (ASON)", juin 2006.

[G.8080.1]	Recommandation UIT-T G.8080, amendement 1, " Architecture pour le réseau optique à commutation automatique (ASON) amendement 1", mars 2008.

 	8.2	Références pour information

[RFC4139]	D. Papadimitriou et autres, "Exigences pour l'utilisation de la signalisation de MPLS généralisé (GMPLS) et extensions pour les réseaux optiques à commutation automatique (ASON)", juillet 2005. (Information)

[RFC4258]	D. Brungard, éd., "Exigences pour l'acheminement de la commutation généralisée d'étiquettes multiprotocoles (GMPLS) pour les réseaux optiques à commutation automatique (ASON)", novembre 2005. (Information)

[RFC4397]	I. Bryskin, A. Farrel, "Lexicographie pour l'interprétation de la terminologie de la commutation d'étiquettes multiprotocoles généralisée (GMPLS) dans le contexte de l'architecture de réseau optique à commutation automatique (ASON) de l'UIT-T", février 2006. (Information)

[RFC4427]	E. Mannie et autres, "Terminologie de récupération (protection et restauration) pour le protocole généralisé de commutation d'étiquettes multiprotocoles (GMPLS)", mars 2006. (Information)

[RFC5659]	M. Bocci, S. Bryant, "Architecture pour l'émulation de pseudo filaire multi-segment de bord à bord", octobre 2009. (Info.)

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

[RFC5920]	L. Fang, "Cadre de sécurité pour réseaux MPLS et GMPLS", juillet 2010. (Information)

[RFC5950]	S. Mansfield, E. Gray, K. Lam, "Cadre de gestion de réseau pour réseaux de transport fondés sur MPLS", septembre  2010. (Information) 

[RFC6941]	L. Fang et autres, "Cadre de sécurité du profil de transport MPLS (MPLS-TP)", avril 2013. (Information)

[RFC7087]	H. van Helvoort, L. Andersson, N. Sprecher, "Lexique pour l’interprétation de la terminologie utilisée dans les projets Internet de profil de transport MPLS (MPLS-TP) et les RFC dans le contexte des Recommandations de l’UIT-T sur le réseau de transport", décembre 2013. (Information)

[Y.1401]	Recommandation UIT-T Y.1401, "Principes d'inter fonctionnement", Union Internationale des Télécommunications, Genève, février 2008.

[Y.2611]	Recommandation UIT-T Y.2611, "Architecture de haut niveau pour les futurs réseaux de paquets", Union Internationale des Télécommunications, Genève, décembre 2006.

 	Adresse des auteurs

Ben Niven-Jenkins	Deborah Brungard	Malcolm Betts	
BT	AT&T	Huawei Technologies	
mél : benjamin.niven-jenkins@bt.com	mél : dbrungard@att.com	mél : malcolm.betts@huawei.com	

Nurit Sprecher	Satoshi Ueno	
Nokia Siemens Networks	NTT Communications	
mél : nurit.sprecher@nsn.com	mél : satoshi.ueno@ntt.com