Union internationale des tlcommunications

UIT-T

Y.2601

SECTEUR DE LA NORMALISATION
DES TLCOMMUNICATIONS
DE L'UIT

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

(12/2006)

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

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

4
4
4
5
5
5
5
6
6
6
7
7
7

Appendice I Problmes concernant les rseaux de transmission par paquets existants.......

I.1
Problmes rencontrs par les oprateurs de rseau ........................................

8
8

BIBLIOGRAPHIE ...................................................................................................................

10

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]

Recommandation UIT-T G.805 (2000), Architecture fonctionnelle gnrique des

rseaux de transport.

[G.809]

Recommandation UIT-T G.809 (2003), Architecture fonctionnelle des rseaux de

couche sans connexion.

[X.200]

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.

[Y.2011]

Recommandation UIT-T Y.2011 (2004), Principes gnraux et modle de rfrence

gnral pour les rseaux de prochaine gnration.

[Y.2111]

Recommandation UIT-T Y.2111 (2006), Fonctions de contrle des ressources et

d'admission dans les rseaux de prochaine gnration.

Dfinitions

La prsente Recommandation utilise et dfinit les termes suivants:

3.1

QS absolue: voir [Y.2111].

3.2

groupe d'accs: voir [G.805].

3.3
point.

adresse: identificateur d'un point de terminaison particulier, utilis pour le routage vers ce

3.4

connexion: voir [G.805].

3.5

plan de commande: voir [Y.2011].

3.6

flux: voir [G.809].

3.7

domaine de flux: voir [G.809].

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

QS relative: voir [Y.2111].

3.14

sous-rseau: voir [G.805].

3.15

chemin: voir [G.805].

3.16

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.

Abrviations

La prsente Recommandation utilise les abrviations et acronymes suivants:

ATM

mode de transfert asynchrone (asynchronous transfer mode)

CAPEX

dpenses d'investissement (capital expenditure)

cl-ps

commutation par paquets en mode sans connexion (connectionless packet switched)

co-cs

commutation de circuits en mode connexion (connection-oriented circuit switched)

co-ps

commutation par paquets en mode connexion (connection-oriented packet switched)

DoS

dni de service (denial of service)

FPBN

futur rseau de transmission par paquets (future packet based network)

FR

relais de trames (frame relay)

IP

protocole Internet (Internet protocol)

mp-t-mp

multipoint multipoint (multipoint-to-multipoint)

MTU

unit de transmission maximale (maximum transmission unit)

OAM

gestion, exploitation et maintenance (operations, administration and maintenance)

OPEX

dpenses d'exploitation (operational expenditure)

PHB

comportement par saut (per-hop behaviour)

PM

gestion de la performance (performance management)

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

p-t-mp

point multipoint (point-to-multipoint)

p-t-p

point point (point-to-point)

QS

qualit de service

RTPC

rseau tlphonique public commut

SLA

accord sur le niveau de service (service level agreement)

SLS

spcification de niveau de service (service level specification)

VPN

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)

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)

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.

7.7

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

Organisation du travail de l'UIT-T

Srie D

Principes gnraux de tarification

Srie E

Exploitation gnrale du rseau, service tlphonique, exploitation des services et facteurs

humains

Srie F

Services de tlcommunication non tlphoniques

Srie G

Systmes et supports de transmission, systmes et rseaux numriques

Srie H

Systmes audiovisuels et multimdias

Srie I

Rseau numrique intgration de services

Srie J

Rseaux cbls et transmission des signaux radiophoniques, tlvisuels et autres signaux

multimdias

Srie K

Protection contre les perturbations

Srie L

Construction, installation et protection des cbles et autres lments des installations extrieures

Srie M

Gestion des tlcommunications y compris le RGT et maintenance des rseaux

Srie N

Maintenance: circuits internationaux de transmission radiophonique et tlvisuelle

Srie O

Spcifications des appareils de mesure

Srie P

Qualit de transmission tlphonique, installations tlphoniques et rseaux locaux

Srie Q

Commutation et signalisation

Srie R

Transmission tlgraphique

Srie S

Equipements terminaux de tlgraphie

Srie T

Terminaux des services tlmatiques

Srie U

Commutation tlgraphique

Srie V

Communications de donnes sur le rseau tlphonique

Srie X

Rseaux de donnes, communication entre systmes ouverts et scurit

Srie Y

Infrastructure mondiale de l'information, protocole Internet et rseaux de prochaine

gnration

Srie Z

Langages et aspects gnraux logiciels des systmes de tlcommunication

Imprim en Suisse
Genve, 2007