1、UNION INTERNATIONALE DES TLCOMMUNICATIONSUIT-T I.376SECTEUR DE LA NORMALISATION (03/95)DES TLCOMMUNICATIONSDE LUITRSEAU NUMRIQUE AVEC INTGRATIONDES SERVICES (RNIS)ASPECTS GNRAUX ET FONCTIONSGLOBALES DU RSEAUCAPACITS DE COUCHE RSEAUPOUR LE SUPPORT DES SERVICESDE TLACTION PAR LE RNISRecommandation UIT
2、-T I.376(Antrieurement Recommandation du CCITT)AVANT-PROPOSLUIT-T (Secteur de la normalisation des tlcommunications) est un organe permanent de lUnion internationale destlcommunications (UIT). Il est charg de ltude des questions techniques, dexploitation et de tarification, et met cesujet des Recomm
3、andations en vue de la normalisation des tlcommunications lchelle mondiale.La Confrence mondiale de normalisation des tlcommunications (CMNT), qui se runit tous les quatre ans, dtermineles thmes dtudes traiter par les Commissions dtudes de lUIT-T lesquelles laborent en retour desRecommandations sur
4、ces thmes.Lapprobation des Recommandations par les Membres de lUIT-T seffectue selon la procdure dfinie dans laRsolution n 1 de la CMNT (Helsinki, 1er-12 mars 1993).La Recommandation UIT-T I.376, que lon doit la Commission dtudes 13 (1993-1996) de lUIT-T, a t approuve le19 mars 1995 selon la procdur
5、e dfinie dans la Rsolution n 1 de la CMNT._NOTEDans la prsente Recommandation, lexpression Administration est utilise pour dsigner de faon abrge aussi bienune administration de tlcommunications quune exploitation reconnue de tlcommunications. UIT 1995Droits de reproduction rservs. Aucune partie de c
6、ette publication ne peut tre reproduite ni utilise sous quelque formeque ce soit et par aucun procd, lectronique ou mcanique, y compris la photocopie et les microfilms, sans laccordcrit de lUIT.TABLE DES MATIRESRecommandation I.376 (03/95)Page0 Champ dapplication. 11 Introduction 12 Abrviations . 13
7、 Objectifs de tlaction 14 Prescriptions fonctionnelles . 25 Architecture fonctionnelle 35.1 Configuration de rfrence pour la tlaction. 35.2 Communications de service et communications de gestion 45.3 Attribut du service de tlaction . 56 Aspects relatifs au service 56.1 Services supports et services
8、complmentaires 56.2 Qualit de service . 76.3 Niveaux de scurit. 87 Capacits de couche rseau 87.1 Fonctions relatives la connexion 87.2 Supervision et contrle de bout en bout 97.3 Description des diverses techniques dinterrogation priodique . 98 Interfonctionnement . 108.1 Interfonctionnement avec de
9、s systmes spcialiss 108.2 Interfonctionnement avec des rseaux privs/publics. 108.3 Interfonctionnement avec des services mobiles10Appendice I Table des attributs du service de tlaction . 10Appendice II Applications spcifiques. 12Recommandation I.376 (03/95) i RSUMLa tlaction par RNIS permettra doffr
10、ir les mmes services que les rseaux dalarme spcialiss et que les solutions base de modem daujourdhui, qui sont pour la plupart non transparents. Lharmonisation des paramtres de service et desclasses de scurit na pas t spcifie par lUIT-T (ex-CCITT) mais elle la t par la Commission lectrotechniqueinte
11、rnationale (CEI). Les rseaux spcialiss de tlaction ont t conus de faon offrir une meilleure sret de serviceque les solutions fondes sur les techniques du rseau tlphonique public commut (RTPC).Les avantages dune mise en oeuvre de ces applications dans un RNIS sont les suivants: laccs client est cens
12、tre moins coteux en cas dutilisation de laccs RNIS pour plusieurs services; le sous-systme dexploitation, administration et maintenance peut tre intgr plus facilement dautresservices; linterface usager-rseau sera normalise; les applications de tlaction pourront tre combines avec dautres services du
13、RNIS pour les intgrer de nouvelles applications (par exemple, tlaction et vidophonie).Lobjet de la prsente Recommandation est de dcrire les capacits de couche rseau dun RNIS qui sont requises pour lafourniture du tlservice de tlaction dans un environnement de rseau avec intgration des services.ii Re
14、commandation I.376 (03/95) Recommandation I.376Recommandation I.376 (03/95)CAPACITS DE COUCHE RSEAU POUR LE SUPPORTDES SERVICES DE TLACTION PAR LE RNIS(Genve, 1994)0 Champ dapplicationLobjet de la prsente Recommandation est de dcrire les capacits de couche rseau dun RNIS qui sont requises pour lafou
15、rniture du tlservice de tlaction dans un environnement de rseau avec intgration des services.1 IntroductionLa tlaction par RNIS permettra doffrir les mmes services que les rseaux dalarme spcialiss et que les solutions base de modem daujourdhui, qui sont pour la plupart non transparents. Lharmonisati
16、on des paramtres de service et desclasses de scurit na pas t spcifie par lUIT-T (ex-CCITT) mais elle la t par la Commission lectrotechniqueinternationale (CEI). Les rseaux spcialiss de tlaction ont t conus de faon offrir une meilleure sret de serviceque les solutions fondes sur les techniques du rse
17、au tlphonique public commut (RTPC).Les avantages dune mise en oeuvre de ces applications dans un RNIS sont les suivants: laccs client est cens tre moins coteux en cas dutilisation de laccs RNIS pour plusieurs services; le sous-systme dexploitation, administration et maintenance peut tre intgr plus f
18、acilement dautresservices; linterface usager-rseau sera normalise; les applications de tlaction pourront tre combines avec dautres services du RNIS pour les intgrer de nouvelles applications (par exemple, tlaction et vidophonie).2 AbrviationsPour les besoins de la prsente Recommandation, les abrviat
19、ions suivantes sappliquent:CRF Fonctions lies la connexion (connection related functions)DSS1 Systme n 1 de signalisation dabonn numrique (digital subscriber signalling system No. 1)EUT Terminal dutilisateur final (end user terminal)FMBS Service support en mode trame (frame mode bearer service)HLF F
20、onctions de couche suprieure (high layer functions)RNIS Rseau numrique avec intgration des servicesSPT Terminal du fournisseur de services (service provider terminal)TMF Fonction de gestion de tlaction (teleaction management function)USBS service support de signalisation dusager (user signalling bea
21、rer service)3 Objectifs de tlactionLe tlservice de tlaction se compose dune classe dapplications caractrises par un certain nombre de propritsfondamentales: il sagit dapplications interactives; ces applications ont normalement un dbit utile assez faible par rapport au dbit de transfert dinformation(
22、cadence) des canaux RNIS; ces applications changent des messages trs courts entre les terminaux et ne comportent habituellementquun seul centre de rattachement; ces applications comportent un grand nombre de terminaux faible prix de revient;Recommandation I.376 (03/95) 1 ces applications ncessitent
23、une protection contre laccs non autoris et contre la modification desmessages; ces applications ncessitent un mode de supervision pour le transfert des informations, avec au moins unecertaine fonction de protection contre les erreurs; ces applications ont des exigences svres en termes de temps de rp
24、onse des transactions individuelleset de disponibilit/fiabilit du service.Les applications du tlservice de tlaction dans le RNIS peuvent tre subdivises en deux grandes catgories possdantchacune ses propres caractristiques de couche rseau et ses propres fonctions de sret. Ces deux catgories sont less
25、uivantes:1) les applications sans exigences spcifiques concernant la fiabilit et la sret autres que les fonctionsoffertes par le service support, appeles ci-aprs applications non sensitives; et2) les applications avec exigences supplmentaires concernant la fiabilit et la sret, appeles ci-aprsapplica
26、tions sensitives.Les applications du service de tlaction sont par exemple les suivantes: tlmtrie; tlcommande de processus; relev de compteurs; surveillance dalarmes; et transactions financires.Plusieurs niveaux de scurit devront tre pris en considration lors de la fourniture du service de tlaction d
27、ansun RNIS, pour assurer des voies de communication fiables entre utilisateurs finals et entre ces derniers et les fournisseursde service, de faon empcher tout accs non autoris des donnes protges. Cela peut ncessiter lintroduction dunefonction de gestion de tlaction (TMF) dans la couche rseau du RNI
28、S de base. Larticle 4 dcrit cette fin les fonctionsde base dans la couche rseau et les protocoles de transport de message dans les couches suprieures.4 Prescriptions fonctionnellesPour certaines applications de tlaction, une unit distincte, appele fonction de gestion de tlaction (TMF) et situedans l
29、a couche rseau du RNIS public, rpond deux grandes exigences de scurit. La TMF veille ce que le terminalou lapplication en cause soit en fonctionnement et que toute interruption de service soit immdiatement signale auterminal du fournisseur de service ou au terminal de lutilisation final associ. La T
30、MF vrifie galement les droitsdaccs au terminal usager comme au terminal fournisseur. A lheure actuelle, le RNIS noffre aucun mcanismespcialis qui puisse garantir que le terminal (EUT ou SPT) na pas t remplac par un autre, illgitime. En outre, laTMF peut offrir au SPT des informations sur ltat du rse
31、au.Si le fournisseur de service exploite le RNIS par lintermdiaire dun rseau de donnes commutation parpaquets (RDCP) ou dun rseau spcialis, la TMF est considre comme tant lunit dinterfonctionnement et estappele effectuer la conversion de protocole approprie. Le prsent article dcrit les prescriptions
32、 fonctionnelles quisont considres comme importantes pour les applications de tlaction, quel que soit le lieu daffectation de cesfonctions. Les fonctions de base suivantes ont t releves:1) service, indpendant de lapplication, de remise sre de message de tlaction entre un terminal et unfournisseur de
33、service et vice versa;2) protection contre les attaques actives de type remplacement de terminal, mulation de terminal,modification ou effacement de message, tablissement de connexion illgitime;3) diffusion de messages par un fournisseur de service vers un nombre prdfini de destinations, parexemple
34、pour la surveillance et la commande de la consommation dnergie;4) notification au fournisseur de service de toute ventuelle perte, modification ou suppression de message;5) surveillance sre et permanente du terminal, par exemple dtection de toute dconnexion de ligne due un acte dlibr dintrus entre l
35、e terminal et la TMF, avec notification immdiate au fournisseur de servicedu fait quun terminal est maintenant considr comme inactif;6) remise rapide des messages, selon des niveaux de priorit prdfinis, avec par exemple, prsance de toutmessage dalarme sur des messages de transaction financire ou dal
36、arme faible priorit;7) protection contre la divulgation du contenu des messages des tierces parties, en fonction dun niveauprdfini de confidentialit des messages;2 Recommandation I.376 (03/95) 8) dtournement de secours en cas de panne dquipement rseau, de quelque type que ce soit (CRF, TMF,transmiss
37、ion, etc.);9) notification dun autre fournisseur de service en cas de panne de communication avec le fournisseur deservice primaire;10) journalisation du trafic aux fins daudit et de statistique.NOTE Certains critres permettent dtablir une distinction entre messagerie de tlaction et messagerie X.400
38、conventionnelle: il sagira, par exemple, du trs bref temps jusqu remise, qui doit normalement tre compris entre 10 secondes et30 secondes, de la limitation de lensemble des services de remise, ce qui diminue la longueur de len-tte de message, de lasurveillance fiable et permanente des terminaux par
39、le SPT ou par le rseau, ce qui peut imposer un important trafic non porteurdinformations, et des prescriptions prcises en cas de dtection dun seul point de panne.5 Architecture fonctionnelleCet article dcrit larchitecture fonctionnelle, la configuration de rfrence, les interfaces et les attributs du
40、 service detlaction, conformment aux Recommandations des sries I.200 et I.300.La configuration de rfrence est conforme aux prescriptions du modle architectural de base dcrit dans 2/I.324. Lesinterfaces et les attributs de service sont conformes aux prescriptions de la Recommandation I.210.5.1 Config
41、uration de rfrence pour la tlactionLa Figure 1 dcrit une configuration gnrique de rfrence pour le support du service de tlaction par un RNIS.Elle montre les relations fonctionnelles mises en jeu, sans entrer dans les dtails des nombreuses variantes permises parles attributs figurant dans la Recomman
42、dation I.340, qui peuvent conduire un grand nombre de chanes de connexiondiffrentes.T1302920-94/d01TMFTerminaisonnumriquede rseauPoint S ou TIWFIWFRNISTMFPoint PMKxEUTRseau de base, avec CRF et HLFsi ncessaireRseau spcialis detlaction (Note 2)NOTES 1 Cette figure ninterdit pas que le SPT soit connec
43、t un rseau spcialis de tlaction. 2 Un rseau spcialis de tlaction peut tre un maillage physique ou virtuel superpos , par exemple, un RTPC ou un RPDCP.FIGURE 1/I.376Configuration de rfrence pour le support du service de tlaction par un RNISPoint S ou TTerminaisonnumriquede rseauSPT ou rseau local du
44、fournisseur deservice (Note 1)FIGURE 1/I.376.D01 = 11.5 cmRecommandation I.376 (03/95) 3 Les points de rfrence sont indiqus dans la Figure 1 ci-dessus. Si aucun fournisseur de service extrieur au RNIS debase nest impliqu, le service de tlaction sera support par la concatnation de deux types de conne
45、xion, lune entrelEUT et la TMF, lautre entre la TMF et le SPT. La concatnation logique/physique de ces connexions est ralise parla TMF.La TMF fait appel des ressources supplmentaires de couche rseau, qui peuvent tre fournies dans le cadre du RNISou en dehors de celui-ci, le point de rfrence entre RN
46、IS et TMF tant, conformment la Recommandation I.324,point P si la TMF est intgre dans le rseau en tant que ressource spcialise et le point M si la TMF est offerte par unfournisseur de service spcialis.Dans un cas comme dans lautre, le terminal dutilisateur final (EUT) et le terminal du fournisseur de service (SPT)accdent au RNIS de base par le point de rfrence S ou T. Des r
