Vous êtes sur la page 1sur 18

Union internationale des tlcommunications

UIT-T
SECTEUR DE LA NORMALISATION DES TLCOMMUNICATIONS DE L'UIT

Y.2601
(12/2006)

SRIE Y: INFRASTRUCTURE MONDIALE DE L'INFORMATION, PROTOCOLE INTERNET ET RSEAUX DE PROCHAINE GNRATION Rseaux de prochaine gnration

Caractristiques fondamentales et spcifications des futurs rseaux de transmission par paquets

Recommandation UIT-T Y.2601

RECOMMANDATIONS UIT-T DE LA SRIE Y INFRASTRUCTURE MONDIALE DE L'INFORMATION, PROTOCOLE INTERNET ET RSEAUX DE PROCHAINE GNRATION INFRASTRUCTURE MONDIALE DE L'INFORMATION Gnralits Services, applications et intergiciels Aspects rseau Interfaces et protocoles Numrotage, adressage et dnomination Gestion, exploitation et maintenance Scurit Performances ASPECTS RELATIFS AU PROTOCOLE INTERNET Gnralits Services et applications Architecture, accs, capacits de rseau et gestion des ressources Transport Interfonctionnement Qualit de service et performances de rseau Signalisation Gestion, exploitation et maintenance Taxation RSEAUX DE PROCHAINE GNRATION Cadre gnral et modles architecturaux fonctionnels Qualit de service et performances Aspects relatifs aux services: capacits et architecture des services Aspects relatifs aux services: interoprabilit des services et rseaux dans les rseaux de prochaine gnration Numrotage, nommage et adressage Gestion de rseau Architectures et protocoles de commande de rseau Scurit Mobilit gnralise
Pour plus de dtails, voir la Liste des Recommandations de l'UIT-T.

Y.100Y.199 Y.200Y.299 Y.300Y.399 Y.400Y.499 Y.500Y.599 Y.600Y.699 Y.700Y.799 Y.800Y.899 Y.1000Y.1099 Y.1100Y.1199 Y.1200Y.1299 Y.1300Y.1399 Y.1400Y.1499 Y.1500Y.1599 Y.1600Y.1699 Y.1700Y.1799 Y.1800Y.1899 Y.2000Y.2099 Y.2100Y.2199 Y.2200Y.2249 Y.2250Y.2299 Y.2300Y.2399 Y.2400Y.2499 Y.2500Y.2599 Y.2700Y.2799 Y.2800Y.2899

Recommandation UIT-T Y.2601 Caractristiques fondamentales et spcifications des futurs rseaux de transmission par paquets

Rsum La prsente Recommandation contient les caractristiques fondamentales d'un futur rseau de transmission par paquets (FPBN, future packet based network). La prsente Recommandation contient les spcifications relatives au plan d'utilisateur, au plan de commande et au plan de gestion de l'architecture d'un rseau FPBN comportant des rseaux de couche conduit fonds sur les paquets de la strate de transport, comme dfini dans [G.805], [G.809], [X.200] et [Y.2011].

Source La Recommandation UIT-T Y.2601 a t approuve le 14 dcembre 2006 par la Commission d'tudes 13 (2005-2008) de l'UIT-T selon la procdure dfinie dans la Recommandation UIT-T A.8.

Rec. UIT-T Y.2601 (12/2006)

AVANT-PROPOS L'UIT (Union internationale des tlcommunications) est une institution spcialise des Nations Unies dans le domaine des tlcommunications. L'UIT-T (Secteur de la normalisation des tlcommunications) est un organe permanent de l'UIT. Il est charg de l'tude des questions techniques, d'exploitation et de tarification, et met ce sujet des Recommandations en vue de la normalisation des tlcommunications l'chelle mondiale. L'Assemble mondiale de normalisation des tlcommunications (AMNT), qui se runit tous les quatre ans, dtermine les thmes d'tude traiter par les Commissions d'tudes de l'UIT-T, lesquelles laborent en retour des Recommandations sur ces thmes. L'approbation des Recommandations par les Membres de l'UIT-T s'effectue selon la procdure dfinie dans la Rsolution 1 de l'AMNT. Dans certains secteurs des technologies de l'information qui correspondent la sphre de comptence de l'UIT-T, les normes ncessaires se prparent en collaboration avec l'ISO et la CEI.

NOTE Dans la prsente Recommandation, l'expression "Administration" est utilise pour dsigner de faon abrge aussi bien une administration de tlcommunications qu'une exploitation reconnue. Le respect de cette Recommandation se fait titre volontaire. Cependant, il se peut que la Recommandation contienne certaines dispositions obligatoires (pour assurer, par exemple, l'interoprabilit et l'applicabilit) et considre que la Recommandation est respecte lorsque toutes ces dispositions sont observes. Le futur d'obligation et les autres moyens d'expression de l'obligation comme le verbe "devoir" ainsi que leurs formes ngatives servent noncer des prescriptions. L'utilisation de ces formes ne signifie pas qu'il est obligatoire de respecter la Recommandation.

DROITS DE PROPRIT INTELLECTUELLE L'UIT attire l'attention sur la possibilit que l'application ou la mise en uvre de la prsente Recommandation puisse donner lieu l'utilisation d'un droit de proprit intellectuelle. L'UIT ne prend pas position en ce qui concerne l'existence, la validit ou l'applicabilit des droits de proprit intellectuelle, qu'ils soient revendiqus par un membre de l'UIT ou par une tierce partie trangre la procdure d'laboration des Recommandations. A la date d'approbation de la prsente Recommandation, l'UIT n'avait pas t avise de l'existence d'une proprit intellectuelle protge par des brevets acqurir pour mettre en uvre la prsente Recommandation. Toutefois, comme il ne s'agit peut-tre pas de renseignements les plus rcents, il est vivement recommand aux dveloppeurs de consulter la base de donnes des brevets du TSB sous http://www.itu.int/ITU-T/ipr/.

UIT 2007 Tous droits rservs. Aucune partie de cette publication ne peut tre reproduite, par quelque procd que ce soit, sans l'accord crit pralable de l'UIT. ii Rec. UIT-T Y.2601 (12/2006)

TABLE DES MATIRES Page 1 2 3 4 5 6 7 Domaine d'application .................................................................................................. Rfrences normatives.................................................................................................. Dfinitions .................................................................................................................... Abrviations.................................................................................................................. Futurs rseaux de transmission par paquets ................................................................. Caractristiques fondamentales .................................................................................... Spcifications................................................................................................................ 7.1 Adressage ....................................................................................................... 7.2 Commande...................................................................................................... 7.3 Qualit de service ........................................................................................... 7.4 Gestion de la performance du rseau.............................................................. 7.5 Protection........................................................................................................ 7.6 Charge utile .................................................................................................... 7.7 Gestion, exploitation et maintenance ............................................................. 7.8 Scurit ........................................................................................................... 7.9 Plan de commande.......................................................................................... 7.10 Plan de gestion................................................................................................ 7.11 Services de base de la strate de transport ....................................................... 7.12 Services volus de la strate de transport ....................................................... 1 1 1 2 3 3 4 4 4 5 5 5 5 6 6 6 7 7 7 8 8 10

Appendice I Problmes concernant les rseaux de transmission par paquets existants....... I.1 Problmes rencontrs par les oprateurs de rseau ........................................ BIBLIOGRAPHIE ...................................................................................................................

Rec. UIT-T Y.2601 (12/2006)

iii

Recommandation UIT-T Y.2601 Caractristiques fondamentales et spcifications des futurs rseaux de transmission par paquets
1 Domaine d'application

La prsente Recommandation contient les caractristiques fondamentales d'un futur rseau de transmission par paquets (FPBN, future packet based network). Elle contient aussi les spcifications relatives au plan d'utilisateur, au plan de commande et au plan de gestion de l'architecture d'un rseau FPBN comportant des rseaux de couche conduit fonds sur les paquets de la strate de transport, comme dfini dans [G.805], [G.809], [X.200] et [Y.2011]. 2 Rfrences normatives

La prsente Recommandation se rfre certaines dispositions des Recommandations UIT-T et textes suivants qui, de ce fait, en sont partie intgrante. Les versions indiques taient en vigueur au moment de la publication de la prsente Recommandation. Toute Recommandation ou tout texte tant sujet rvision, les utilisateurs de la prsente Recommandation sont invits se reporter, si possible, aux versions les plus rcentes des rfrences normatives suivantes. La liste des Recommandations de l'UIT-T en vigueur est rgulirement publie. La rfrence un document figurant dans la prsente Recommandation ne donne pas ce document, en tant que tel, le statut d'une Recommandation. [G.805] [G.809] [X.200] Recommandation UIT-T G.805 (2000), Architecture fonctionnelle gnrique des rseaux de transport. Recommandation UIT-T G.809 (2003), Architecture fonctionnelle des rseaux de couche sans connexion. Recommandation UIT-T X.200 (1994) | ISO/CEI 7498-1:1994, Technologies de l'information Interconnexion des systmes ouverts Modle de rfrence de base: le modle de rfrence de base. Recommandation UIT-T Y.2011 (2004), Principes gnraux et modle de rfrence gnral pour les rseaux de prochaine gnration. Recommandation UIT-T Y.2111 (2006), Fonctions de contrle des ressources et d'admission dans les rseaux de prochaine gnration.

[Y.2011] [Y.2111]

3 3.1 3.2 3.3 point. 3.4 3.5 3.6 3.7

Dfinitions QS absolue: voir [Y.2111]. groupe d'accs: voir [G.805]. adresse: identificateur d'un point de terminaison particulier, utilis pour le routage vers ce connexion: voir [G.805]. plan de commande: voir [Y.2011]. flux: voir [G.809]. domaine de flux: voir [G.809].

La prsente Recommandation utilise et dfinit les termes suivants:

Rec. UIT-T Y.2601 (12/2006)

3.8 identificateur: suite de chiffres, de caractres, de symboles ou de toute autre forme de donnes, utilise pour identifier un ou plusieurs abonns, utilisateurs ou des lments de rseau, fonctions, entits de rseau fournissant des services ou des applications, ou toute autre entit (par exemple des objets physiques ou logiques).
NOTE Les identificateurs peuvent tre utiliss pour l'enregistrement ou l'autorisation. Ils peuvent tre publics (totalit des rseaux), partags (nombre limit de rseaux) ou privs (un seul rseau donn) (les identificateurs privs ne sont normalement pas divulgus des tiers).

3.9 plan d'utilisateur: catgorie d'objets dont la principale fonction est d'assurer le transfert des informations d'utilisateur final: les informations d'utilisateur peuvent tre un contenu d'utilisateur utilisateur ou des donnes prives d'utilisateur utilisateur. 3.10 importance: capacit de survie d'un paquet donn par rapport tous les autres paquets lorsque le rseau n'a pas assez de ressources pour acheminer la totalit du trafic.
NOTE L'importance d'un paquet donn est indpendante du dlai requis (urgence) pour ce paquet.

3.11

plan de gestion: voir [Y.2011].

3.12 hors conduit: dans un rseau en mode connexion, dsigne l'utilisation d'un chemin distinct. Dans un rseau en mode sans connexion, dsigne l'utilisation d'un chemin de couche serveur distinct. 3.13 3.14 3.15 3.16 QS relative: voir [Y.2111]. sous-rseau: voir [G.805]. chemin: voir [G.805]. urgence: rapidit avec laquelle un paquet doit tre trait afin de respecter la QS requise.

NOTE L'urgence d'un paquet est exprime en termes de performance (dlai) requise. Elle est indpendante de la capacit de survie (importance) de ce paquet.

4 ATM CAPEX cl-ps co-cs co-ps DoS FPBN FR IP

Abrviations mode de transfert asynchrone (asynchronous transfer mode) dpenses d'investissement (capital expenditure) commutation par paquets en mode sans connexion (connectionless packet switched) commutation de circuits en mode connexion (connection-oriented circuit switched) commutation par paquets en mode connexion (connection-oriented packet switched) dni de service (denial of service) futur rseau de transmission par paquets (future packet based network) relais de trames (frame relay) protocole Internet (Internet protocol) multipoint multipoint (multipoint-to-multipoint) unit de transmission maximale (maximum transmission unit) gestion, exploitation et maintenance (operations, administration and maintenance) dpenses d'exploitation (operational expenditure) comportement par saut (per-hop behaviour) gestion de la performance (performance management)
Rec. UIT-T Y.2601 (12/2006)

La prsente Recommandation utilise les abrviations et acronymes suivants:

mp-t-mp MTU OAM OPEX PHB PM


2

p-t-mp p-t-p QS RTPC SLA SLS VPN 5

point multipoint (point-to-multipoint) point point (point-to-point) qualit de service rseau tlphonique public commut accord sur le niveau de service (service level agreement) spcification de niveau de service (service level specification) rseau priv virtuel (virtual private network) Futurs rseaux de transmission par paquets

Les futurs rseaux de transmission par paquets (FPBN, future packet based network) constituent la ou les couches les plus hautes de la strate de transport dfinie dans [Y.2011]. D'autres Recommandations et documents de l'UIT-T devraient contenir davantage de dtails sur les spcifications, l'architecture et les protocoles sur la base des caractristiques fondamentales et des spcifications des FPBN nonces dans la prsente Recommandation. 6 Caractristiques fondamentales

Le prsent paragraphe contient les objectifs applicables un FPBN en termes de caractristiques fondamentales. Les principaux objectifs sont les suivants. Un FPBN devrait: assurer des services en mode sans connexion (cl-ps) et des services en mode connexion (co-ps) pour plusieurs types de client; prendre en charge efficacement les services point point (p-t-p) et les services point multipoint (p-t-mp); prendre en charge au moins la qualit de service (QS) absolue en mode co-ps (si ce mode est assur); interfonctionner et coexister avec les rseaux existants de transmission par paquets cl-ps et co-ps; prendre en charge des topologies de rseau arbitraires et pouvoir prendre en charge une expansion progressive de la largeur de bande, de la topologie, du nombre d'abonns et du nombre de services; dtecter les dfaillances de fonctionnalit et d'quipement ainsi que les dgradations de performance et assurer le retour la normale, en fonction des spcifications du service; offrir les fonctions de gestion, d'exploitation et de maintenance (OAM, operations, administration and maintenance) appropries pour chaque plan; scuriser compltement le trafic interne du plan de commande et du plan de gestion contre les attaques externes et faire en sorte qu'il reste scuris et stable dans les situations de contraintes extrmes; scuriser le plan de gestion afin d'interdire aux utilisateurs non autoriss d'accder aux fonctions de commande et de gestion; pouvoir prendre en charge de nouveaux types de trafic; prendre en charge des mcanismes de multiplexage statistique dans un souci d'efficacit; prendre en charge l'interception licite pour les services FPBN. Les spcifications applicables l'interception licite dans les NGN sont dcrites dans d'autres Recommandations de l'UIT-T;
Rec. UIT-T Y.2601 (12/2006) 3

prendre en charge des fonctions de comptabilit fondes sur la surveillance, au minimum, de paramtres de performance et d'utilisation du rseau; permettre de faire la distinction entre urgence (dlai) et importance (capacit de survie); prendre en charge des services ncessitant que les paquets soient fournis dans l'ordre; offrir des moyens harmoniss et cohrents pour se rfrer aux points d'accs dans le plan d'utilisateur; prendre en charge une dtection et un traitement des dfauts lis au trafic dans le plan d'utilisateur (OAM) qui ne dpendent pas des plans de commande et/ou de gestion et qui ne soient pas fonction de la nature du client transport; prendre en charge des mcanismes permettant d'harmoniser l'tablissement et la libration de chemin ou de connexion avec l'activation et la dsactivation OAM; prendre en charge des mcanismes permettant d'viter toute incidence sur le trafic pendant les reconfigurations; tenter de maintenir l'coulement du trafic lors du retour la normale aprs une dfaillance; acheminer le trafic uniquement depuis la source/entre prvue et vers la ou les destinations/sorties prvues sauf dans le cas de dfaillances multiples extrmement rares; prendre en charge les services d'urgence; tre modulable et fiable; prendre en charge des mcanismes de maintien de la sparation entre les flux de trafic d'utilisateur, suivant le service FPBN qui est offert.

En outre, un FPBN: devrait prendre en charge efficacement des services multipoint multipoint (mp-t-mp); devrait remplacer progressivement les rseaux existants de transmission par paquets cl-ps et co-ps; devrait assurer la sparation logique des plans de commande, de gestion et d'utilisateur; devrait prendre en charge des plans de commande et de gestion hors conduit. 7 Spcifications

Le prsent paragraphe contient les spcifications fondes sur les objectifs noncs au 6. 7.1 Adressage

Le prsent paragraphe contient les spcifications lies l'adressage pour un FPBN. Ces spcifications s'appliquent au rseau, pas ncessairement aux paquets proprement dits. Un FPBN devrait prendre en charge: l'identification de l'origine d'un paquet et de sa destination dans le FPBN et ce, en mode cl-ps; l'identification, au niveau de la destination d'une connexion, de la source de cette connexion dans le FPBN et ce, en mode co-ps. En outre, un FPBN: devrait assurer un adressage FPBN qui est distinct de tout adressage client. 7.2 Commande

Le prsent paragraphe contient les spcifications lies la commande pour un FPBN.

Rec. UIT-T Y.2601 (12/2006)

Un FPBN devrait prendre en charge: des mcanismes de sauvegarde contre les units de trafic persistantes (c'est--dire de bouclage) en mode cl-ps; des mcanismes de sauvegarde contre les connexions co-ps contenant des boucles de retransmission; des mcanismes permettant de garantir l'intgrit des informations de commande (par exemple somme de contrle d'en-tte). En outre, un FPBN: devrait faciliter la fourniture des units de trafic dans l'ordre. 7.3 Qualit de service

Le prsent paragraphe contient les spcifications lies la qualit de service (QS) pour un FPBN. Un FPBN: peut prendre en charge un mcanisme de priorits de mise en file d'attente, qui peut tre implicite ou explicite; peut prendre en charge un mcanisme de priorits de rejet, qui peut tre implicite ou explicite. 7.4 Gestion de la performance du rseau

Le prsent paragraphe contient les spcifications lies la gestion de la performance pour un FPBN. Un FPBN devrait: suspendre toute mesure de la performance de rseau sur les deux sens d'une connexion ou d'un chemin bidirectionnel si l'un ou l'autre sens passe l'tat d'indisponibilit; prendre en charge la surveillance de la performance de rseau (disponibilit, perte de paquets, dlai et gigue) entre deux points du rseau, quels qu'ils soient. En outre, un FPBN: devrait assurer la journalisation de l'utilisation du FPBN, suivant les services FPBN qui sont pris en charge; peut fournir des informations d'utilisation au niveau des liaisons et des nuds. 7.5 Protection

Le prsent paragraphe contient les spcifications lies la protection pour un FPBN. Un FPBN: peut prendre en charge des mcanismes permettant d'assurer le retour la normale aprs une dfaillance d'quipement ou de fonctionnalit. 7.6 Charge utile

Le prsent paragraphe contient les spcifications lies la charge utile pour un FPBN. Un FPBN devrait: fournir les paquets dans l'ordre en mode connexion. En outre, un FPBN: peut prendre en charge des mcanismes de dcouverte dynamique de l'unit de transmission maximale (MTU, maximum transmission unit) d'un conduit ou d'une connexion dans un FPBN;
Rec. UIT-T Y.2601 (12/2006) 5

7.7

peut prendre en charge des mcanismes permettant de fournir les paquets dans l'ordre en mode sans connexion; peut prendre en charge des mcanismes garantissant l'intgrit des informations adaptes. Gestion, exploitation et maintenance

Le prsent paragraphe contient les spcifications lies la gestion, l'exploitation et la maintenance (OAM) pour un FPBN. Un FPBN devrait prendre en charge: des mcanismes OAM simples de dtection et de traitement des dfauts; des mcanismes OAM indpendants de la couche client prise en charge par le FPBN (en d'autres termes, la gestion de la couche serveur est indpendante du client transport); la dtection et le traitement des dfauts OAM concernant le trafic dans le plan d'utilisateur; la dtection et le traitement unidirectionnels des dfauts OAM (par exemple indication de dfaut la terminaison de chemin) concernant le trafic dans le plan d'utilisateur en mode co-ps; les mesures conscutives voulues (aprs la dtection d'un dfaut) au niveau d'un puits de terminaison de chemin (par exemple suppression de trafic de client, indication de dfaut au client et indication de dfaut la source de terminaison de chemin) pour les clients co-ps et co-cs. 7.8 Scurit

Le prsent paragraphe contient les spcifications lies la scurit pour un FPBN. Le but est de dtecter et d'assurer la protection contre les terminaux non autoriss. Le but n'est pas de dtecter et d'assurer la protection contre les utilisateurs non autoriss de terminaux autoriss. Un FPBN devrait mettre en uvre: des mcanismes de protection des communications dans le plan de commande contre les menaces de scurit; des mcanismes de protection des communications dans le plan de gestion contre les menaces de scurit. 7.9 Plan de commande

Le prsent paragraphe contient les spcifications lies au plan de commande pour un FPBN. Un FPBN devrait: prendre en charge un plan de commande qui est indpendant du plan de commande d'une couche client donne; permettre de faire la distinction de faon non ambigu et fiable entre, d'une part, les paquets du plan de commande et, d'autre part, les paquets du plan d'utilisateur et les paquets du plan de gestion; attribuer des ressources pour les paquets du plan de commande de sorte que le trafic du plan d'utilisateur, quel que soit son volume, ne puisse pas empcher le fonctionnement des fonctions de commande; dtecter les dfaillances et les dgradations dans le plan de commande et assurer le retour la normale, suivant les spcifications du service.

Rec. UIT-T Y.2601 (12/2006)

7.10

Plan de gestion

Le prsent paragraphe contient les spcifications lies au plan de gestion pour un FPBN. Un FPBN devrait: prendre en charge un plan de gestion qui est indpendant du plan de gestion d'une couche client donne; permettre de faire la distinction de faon non ambigu et fiable entre, d'une part, les paquets du plan de gestion et, d'autre part, les paquets du plan d'utilisateur et les paquets du plan de commande; attribuer des ressources pour les paquets du plan de gestion de sorte que le trafic du plan d'utilisateur, quel que soit son volume, ne puisse pas empcher le fonctionnement des fonctions de gestion. 7.11 Services de base de la strate de transport

Le prsent paragraphe contient les spcifications lies aux services de base de la strate de transport pour un FPBN. Un FPBN devrait prendre en charge: des services de strate de transport point point sans adaptation; des services de strate de transport point point incluant des fonctions d'adaptation; des services de strate de transport point multipoint incluant des fonctions d'adaptation. 7.12 Services volus de la strate de transport

Le prsent paragraphe contient les spcifications lies aux services volus de la strate de transport pour un FPBN. Un FPBN devrait prendre en charge: des services de strate de transport en mode connexion avec garantie de QS absolue; des services de strate de transport avec QS relative. En outre, un FPBN: devrait prendre en charge des services de strate de transport multipoint multipoint incluant des fonctions d'adaptation.

Rec. UIT-T Y.2601 (12/2006)

Appendice I Problmes concernant les rseaux de transmission par paquets existants


Actuellement, les nombreuses plates-formes de rseau des oprateurs de rseau ddies divers services (par exemple RTPC, ATM, FR, rseau dorsal Internet, VPN IP, etc.) sont en train d'voluer radicalement vers des rseaux plus simples qui offrent des services communs en mode connexion ou en mode sans connexion prsentant une plus grande convergence. Ce type de rseaux devrait tre robuste, modulable et souple, et, dans le mme temps, les dpenses d'investissement (CAPEX, capital expenditures) et les dpenses d'exploitation (OPEX, operational expenditures) concernant ce type de rseau devraient tre optimises. I.1 Problmes rencontrs par les oprateurs de rseau

Les rseaux cl-ps existants ont pour avantage de prsenter un modle d'exploitation relativement simple et pour inconvnient de ne pas pouvoir offrir de fortes garanties de QS de bout en bout de faon rentable. Les rseaux co-ps existants ont pour avantage de pouvoir offrir une performance garantie, mais ventuellement au prix d'une complexit d'exploitation relativement plus grande. Les oprateurs escomptent donc que les deux modes (cl-ps et co-ps) soient pris en charge afin de pouvoir offrir la totalit des services dont leurs abonns ont besoin. I.1.1 Prise en charge de diffrents types de trafic

Les oprateurs de rseau escomptent disposer d'une architecture volutive qui: permette de mettre en uvre et de garantir des spcifications de niveau de service (SLS, service level specifications); "s'adapte l'incertitude"; prenne en charge diffrents types de trafic et leurs mcanismes de diffrenciation de service associs. En outre, pour pouvoir offrir ces services fonds sur une certaine QS, un rseau devrait mettre en uvre un mcanisme (virtuel ou autre) de sparation logique des diffrentes classes de trafic associes chaque type de trafic. I.1.2 Protection des plans de commande et de gestion vis--vis du trafic de plan d'utilisateur

Les oprateurs de rseau escomptent que leur infrastructure de commande et de gestion soit protge vis--vis du trafic d'utilisateur. Voir le paragraphe I.1.5 pour plus d'lments concernant la scurit. Une architecture de rseau devrait donc permettre de sparer les divers plans dans un mode particulier (par exemple cl-ps, co-ps ou co-cs). A titre d'exemple, on peut citer la sparation du plan de donnes et du plan de commande dans l'architecture SS7. I.1.3 Offre de garanties et taxation concernant les accords sur le niveau de service (SLA)

A mesure que l'accs large bande se gnralise et que de nouvelles applications apparaissent, il devient de plus en plus important de savoir comment fournir des services fonds sur une certaine QS et de dterminer les mcanismes de taxation de ces services. A cette fin, les oprateurs de rseau souhaiteront (au minimum): garantir un accs quitable aux ressources partages dans le rseau d'accs; contrler la rpartition de la charge afin d'viter une concentration des surcharges dans le rseau central;

Rec. UIT-T Y.2601 (12/2006)

offrir de fortes garanties aux abonns; offrir diffrentes catgories tarifaires.

Toute architecture de QS est cense mettre en uvre ces fonctions. Il est important de noter qu'en gnral, les fonctions lies la QS dcrites ci-dessus sont caractrises par leur comportement de bout en bout. Toutefois, des architectures de QS telles que l'architecture de l'IETF relative aux services diffrencis (DS, differentiated services) [b-RFC2475] dfinissent un modle de QS de bout en bout, mais le modle DS proprement dit est dcrit en termes de comportements par saut (PHB, per-hop behaviour) et de conditionnement priphrique du trafic, et les oprateurs de rseau peuvent estimer que le modle DS est insuffisant pour offrir les garanties requises de QS de bout en bout. I.1.4 Ncessit de garantir que les services d'urgence sont assurs sans tre coups

Les oprateurs de rseau sont censs garantir que les services d'urgence (par exemple numros d'urgence 112 et 911) sont assurs et ne sont pas coups en cas de manque de ressources. Dans les mthodes existantes relatives la QS, se pose le problme de l'incapacit faire la distinction entre urgence et importance. I.1.5 Prise en charge d'une scurit adquate

Les oprateurs de rseau escomptent que leur infrastructure soit scurise. Toutefois, dans les architectures dans lesquelles les informations de plan de commande et de plan de gestion sont achemines dans la bande dans un plan d'utilisateur partag (par exemple dans les rseaux IP), le risque d'attaques contre l'infrastructure de rseau d'un oprateur est plus lev. Ces attaques comprennent les attaques classiques contre la scurit (dtournement, confidentialit, non-rpudiation, etc.) ainsi que les attaques visant la disponibilit du rseau (par exemple les attaques par dni de service (DoS)). I.1.6 Identification, localisation et relve des drangements (OAM)

Il va de soi que les oprateurs de rseau escompteront pouvoir assurer une dtection, une localisation et une relve rapides des drangements se produisant dans le rseau (de prfrence de faon proactive, c'est--dire avant que l'abonn ne les remarque). Toutefois, dans le cadre de certains choix architecturaux, il peut tre difficile voire impossible de procder une relve rapide des drangements. Par exemple, considrons le cas des rseaux IP, dans lesquels les informations de commande et de gestion sont achemines dans la bande. Dans ce cas, il peut tre difficile voire impossible de procder une localisation, un diagnostic et une rparation rapides pour certaines catgories de drangements (en particulier les drangements qui ont pour caractristique d'empcher leur dtection, leur localisation ou leur relve). I.1.7 Surveillance de la performance

Les oprateurs de rseau escomptent aussi pouvoir surveiller la performance de leurs rseaux et des services qu'ils offrent. Les mmes choix architecturaux qui font qu'il peut tre difficile (voire impossible) de procder la relve des drangements peuvent entraner des problmes analogues en termes de surveillance de la performance.

Rec. UIT-T Y.2601 (12/2006)

BIBLIOGRAPHIE
[b-RFC 2475] IETF RFC 2475 (1998), An Architecture for Differentiated Services.

10

Rec. UIT-T Y.2601 (12/2006)

SRIES DES RECOMMANDATIONS UIT-T


Srie A Srie D Srie E Srie F Srie G Srie H Srie I Srie J Srie K Srie L Srie M Srie N Srie O Srie P Srie Q Srie R Srie S Srie T Srie U Srie V Srie X Srie Y Srie Z Organisation du travail de l'UIT-T Principes gnraux de tarification Exploitation gnrale du rseau, service tlphonique, exploitation des services et facteurs humains Services de tlcommunication non tlphoniques Systmes et supports de transmission, systmes et rseaux numriques Systmes audiovisuels et multimdias Rseau numrique intgration de services Rseaux cbls et transmission des signaux radiophoniques, tlvisuels et autres signaux multimdias Protection contre les perturbations Construction, installation et protection des cbles et autres lments des installations extrieures Gestion des tlcommunications y compris le RGT et maintenance des rseaux Maintenance: circuits internationaux de transmission radiophonique et tlvisuelle Spcifications des appareils de mesure Qualit de transmission tlphonique, installations tlphoniques et rseaux locaux Commutation et signalisation Transmission tlgraphique Equipements terminaux de tlgraphie Terminaux des services tlmatiques Commutation tlgraphique Communications de donnes sur le rseau tlphonique Rseaux de donnes, communication entre systmes ouverts et scurit Infrastructure mondiale de l'information, protocole Internet et rseaux de prochaine gnration Langages et aspects gnraux logiciels des systmes de tlcommunication

Imprim en Suisse Genve, 2007