ITU-T J 172 FRENCH-2005 IPCablecom management event mechanism《有线互联网络标准(IPCablecom)管理事件机制 9号研究组》.pdf

《ITU-T J 172 FRENCH-2005 IPCablecom management event mechanism《有线互联网络标准(IPCablecom)管理事件机制 9号研究组》.pdf》由会员分享，可在线阅读，更多相关《ITU-T J 172 FRENCH-2005 IPCablecom management event mechanism《有线互联网络标准(IPCablecom)管理事件机制 9号研究组》.pdf（26页珍藏版）》请在麦多课文档分享上搜索。

1、 Union internationale des tlcommunicationsUIT-T J.172SECTEUR DE LA NORMALISATION DES TLCOMMUNICATIONS DE LUIT (11/2005) SRIE J: RSEAUX CBLS ET TRANSMISSION DES SIGNAUX RADIOPHONIQUES, TLVISUELS ET AUTRES SIGNAUX MULTIMDIAS IPCablecom Mcanisme dvnement de gestion IPCablecomRecommandation UIT-T J.172

2、Rec. UIT-T J.172 (11/2005) i Recommandation UIT-T J.172 Mcanisme dvnement de gestion IPCablecom Rsum La prsente Recommandation dfinit le mcanisme dvnement de gestion que les lments IPCablecom peuvent utiliser afin de signaler des vnements asynchrones indiquant des situations de drangement et donnant

3、 notification dimportantes situations autres que de drangement. Dans la prsente Recommandation, les vnements sont dfinis comme des situations ncessitant la signalisation dinformations des systmes de gestion et/ou des journaux locaux. Un des objectifs du protocole IPCablecom est de maintenir la cohre

4、nce avec les mcanismes de signalisation dvnement par cblo-modem. Source La Recommandation UIT-T J.172 a t approuve le 29 novembre 2005 par la Commission dtudes 9 (2005-2008) de lUIT-T selon la procdure dfinie dans la Recommandation UIT-T A.8. ii Rec. UIT-T J.172 (11/2005) AVANT-PROPOS LUIT (Union in

5、ternationale des tlcommunications) est une institution spcialise des Nations Unies dans le domaine des tlcommunications. LUIT-T (Secteur de la normalisation des tlcommunications) est un organe permanent de lUIT. Il est charg de ltude des questions techniques, dexploitation et de tarification, et met

6、 ce sujet des Recommandations en vue de la normalisation des tlcommunications lchelle mondiale. LAssemble mondiale de normalisation des tlcommunications (AMNT), qui se runit tous les quatre ans, dtermine les thmes dtude traiter par les Commissions dtudes de lUIT-T, lesquelles laborent en retour des

7、Recommandations sur ces thmes. Lapprobation des Recommandations par les Membres de lUIT-T seffectue selon la procdure dfinie dans la Rsolution 1 de lAMNT. Dans certains secteurs des technologies de linformation qui correspondent la sphre de comptence de lUIT-T, les normes ncessaires se prparent en c

8、ollaboration avec lISO et la CEI. NOTE Dans la prsente Recommandation, lexpression “Administration“ est utilise pour dsigner de faon abrge aussi bien une administration de tlcommunications quune exploitation reconnue. Le respect de cette Recommandation se fait titre volontaire. Cependant, il se peut

9、 que la Recommandation contienne certaines dispositions obligatoires (pour assurer, par exemple, linteroprabilit et lapplicabilit) et considre que la Recommandation est respecte lorsque toutes ces dispositions sont observes. Le futur dobligation et les autres moyens dexpression de lobligation comme

10、le verbe “devoir“ ainsi que leurs formes ngatives servent noncer des prescriptions. Lutilisation de ces formes ne signifie pas quil est obligatoire de respecter la Recommandation. DROITS DE PROPRIT INTELLECTUELLE LUIT attire lattention sur la possibilit que lapplication ou la mise en uvre de la prse

11、nte Recommandation puisse donner lieu lutilisation dun droit de proprit intellectuelle. LUIT ne prend pas position en ce qui concerne lexistence, la validit ou lapplicabilit des droits de proprit intellectuelle, quils soient revendiqus par un membre de lUIT ou par une tierce partie trangre la procdu

12、re dlaboration des Recommandations. A la date dapprobation de la prsente Recommandation, lUIT navait pas t avise de lexistence dune proprit intellectuelle protge par des brevets acqurir pour mettre en uvre la prsente Recommandation. Toutefois, comme il ne sagit peut-tre pas de renseignements les plu

13、s 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 2006 Tous droits rservs. Aucune partie de cette publication ne peut tre reproduite, par quelque procd que ce soit, sans laccord crit pralable de lUIT. Rec. UIT

14、-T J.172 (11/2005) iii TABLE DES MATIRES Page 1 Domaine dapplication 1 2 Rfrences. 1 2.1 Rfrences normatives 1 2.2 Rfrences informatives . 1 3 Termes et dfinitions 2 4 Abrviations, acronymes et conventions 2 4.1 Abrviations et acronymes . 2 4.2 Conventions 2 5 Historique . 3 6 Exigences fonctionnell

15、es du mcanisme dvnement de gestion IPCablecom . 3 7 Mcanisme de signalisation dvnement de gestion . 5 7.1 Catgories de notification dvnements 5 7.2 Format dun vnement de gestion IPCablecom 6 7.3 Mthode daccs un vnement de gestion IPCablecom . 6 7.4 Identificateur dvnement de gestion 6 7.5 Svrits dvn

16、ement de gestion . 6 7.6 Mcanisme de notification . 7 7.7 Journalisation locale des vnements. 8 7.8 Syslog . 8 7.9 Ralentissement dadmission des vnements . 10 8 Gabarit de donnes dvnement de gestion IPCablecom 12 Annexe A Evnements dapprovisionnement dfinis dans IPCablecom 13 Annexe B Evnements dali

17、mentation dans IPCablecom . 17 Rec. UIT-T J.172 (11/2005) 1 Recommandation UIT-T J.172 Mcanisme dvnement de gestion IPCablecom 1 Domaine dapplication La prsente Recommandation dfinit le mcanisme dvnement de gestion que les lments IPCablecom peuvent utiliser afin de signaler des vnements asynchrones

18、indiquant des situations de drangement et donnant notification dimportantes situations autres que de drangement. Dans la prsente Recommandation, les vnements sont dfinis comme des situations ncessitant la signalisation dinformations des systmes de gestion et/ou des journaux locaux. Un des objectifs

19、du protocole IPCablecom est de maintenir la cohrence avec les mcanismes de signalisation dvnement par cblo-modem. 2 Rfrences 2.1 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 ve

20、rsions 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 l

21、iste des Recommandations de lUIT-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 dune Recommandation. Recommandation UIT-T J.164 (2005), Prescriptions relatives aux messages dvnement pour la pris

22、e en charge des services en temps rel sur les rseaux de tlvision par cble utilisant des cblo-modems. Recommandation UIT-T J.166 (2005), Structure des bases dinformations de gestion (MIB) IPCablecom. Recommandation UIT-T J.167 (2005), Prescriptions dinstallation des adaptateurs MTA pour la fourniture

23、 de services en temps rel sur les rseaux de tlvision par cble au moyen de cblo-modems. Recommandation UIT-T M.3100 (2005), Modle gnrique dinformation de rseau. Recommandation UIT-T X.733 (1992), Technologies de linformation Interconnexion des systmes ouverts Gestion-systmes: fonction de signalisatio

24、n des alarmes. IEFT RFC 3164 (2001), The BSD syslog Protocol. 2.2 Rfrences informatives Recommandation UIT-T J.160 (2005), Cadre architectural pour lacheminement de services temps critique sur des rseaux de tlvision par cble utilisant des cblo-modems. Recommandation UIT-T J.168 (2001), Caractristiqu

25、es de la base dinformations de gestion (MIB) de ladaptateur terminal de support du systme IPCablecom. IETF RFC 2573 (1999), SNMP Applications. 2 Rec. UIT-T J.172 (11/2005) IETF RFC 2670 (1999), Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces. ANSI/S

26、CTE 23-3-2003, DOCSIS 1.1 Part 3: Operations Support System Interface. 3 Termes et dfinitions La prsente Recommandation ne dfinit aucun nouveau terme. 4 Abrviations, acronymes et conventions 4.1 Abrviations et acronymes La prsente Recommandation utilise les abrviations et acronymes suivants: CMS ser

27、veur de gestion dappels (call management server) CMTS systme de terminaison de cblo-modem (cable modem termination system) FQDN nom de domaine complet (fully qualified domain name) (voir IETF RFC 821 pour plus de dtails) IANA Autorit charge de lassignation des numros Internet (Internet assigned numb

28、ers authority) MAC commande daccs au support (media access control) MGC contrleur de passerelle mdia (media gateway controller) MIB base dinformations de gestion (management information base) MTA adaptateur de terminal de mdia (media terminal adapter) OSS systme support dexploitation (operations sup

29、port system) SNMP protocole simple de gestion de rseau (simple network management protocol) UDP protocole datagramme dutilisateur (user datagram protocol) 4.2 Conventions Si la prsente Recommandation est implmente, les mots cls “DOIT“, “DOIVENT“ et “REQUIS(E)“ doivent tre interprts comme indiquant u

30、n aspect obligatoire de la prsente Recommandation. Les mots cls qui indiquent un certain niveau de porte dune exigence particulire, utilis dans toute la prsente Recommandation, sont rsums ci-dessous. “DOIT (DOIVENT)“ Cette forme verbale, ou ladjectif “REQUIS(E)“, signifie que llment est une exigence

31、 absolue de la prsente Recommandation. “NE DOIT (DOIVENT) PAS“ Cette forme verbale signifie que llment est une interdiction absolue de la prsente Recommandation. “DEVRAI(EN)T“ Cette forme verbale ou ladjectif “RECOMMANDE(E)“ signifie quil peut y avoir des raisons valables de ne pas tenir compte de c

32、et lment dans des circonstances particulires, mais que toutes les implications devraient tre comprises et que le cas devrait tre examin de prs avant de choisir une autre solution. Rec. UIT-T J.172 (11/2005) 3 “NE DEVRAI(EN)T PAS“ Cette forme verbale signifie quil peut y avoir des raisons valables, d

33、ans des circonstances particulires, pour considrer le comportement indiqu comme acceptable ou mme utile, mais que toutes les implications devraient tre comprises et que le cas devrait tre examin de prs avant dimplmenter un comportement faisant lobjet de cette mise en garde. “PEU(VEN)T“ Cette forme v

34、erbale ou ladjectif “FACULTATIF (FACULTATIVE)“ signifie que llment est vraiment facultatif. Un fournisseur particulier peut choisir dinclure llment parce quun march particulier en a besoin ou parce que, par exemple, il amliore le produit. Un autre fournisseur peut omettre le mme lment. 5 Historique

35、Larchitecture IPCablecom stend de bout en bout en large bande afin de prendre en charge la voix, la vido et dautres services multimdias. Les lments constituants de cette architecture sont dfinis individuellement dans la Rec. UIT-T J.160. Les applications administratives du systme OSS contiennent les

36、 composants dentreprise, de service et de gestion de rseau qui prennent en charge les processus conomiques centraux. La srie des Recommandations IPCablecom dfinit un ensemble limit de composants fonctionnels et dinterfaces de systme OSS assurant la fourniture du dispositif MTA, la messagerie dvnemen

37、ts afin de transporter les informations de facturation, et le mcanisme dvnement de gestion dfini dans la prsente Recommandation afin dacheminer les drangements et dautres donnes. En plus du mcanisme dvnement de gestion, larchitecture IPCablecom prend en charge le mcanisme supplmentaire de signalisat

38、ion suivant: messages dvnement IPCablecom selon la Rec. UIT-T J.164. Ce mcanisme de signalisation fait appel au protocole de transport RADIUS, un ensemble prdfini dattributs de messages vnementiels (comme BillingCorrelationID, CalledPartyNumber, TrunkGroupID, etc.) et au format de donnes de messages

39、 vnementiels IPCablecom afin de transporter des informations appel par appel entre des lments du rseau IPCablecom (serveur CMS, systme CMTS, contrleur MGC) et un serveur darchivage (RKS, record keeping server). Pour chaque communication, le serveur RKS combine tous les messages dvnement associs en u

40、n seul relev dtaill des communications (CDR, call detail record) qui peut tre envoy un systme administratif de facturation, un systme de dtection de fraude ou un autre systme. Les attributs de donnes dont un fournisseur est propritaire peuvent tre inclus dans un message dvnement IPCablecom en mme te

41、mps que lensemble dattributs IPCablecom dfini; autres mthodes de signalisation. Il est possible que des lments IPCablecom implmentent des mthodes de signalisation spcifies dans des bases MIB de cblo-modem, dans des bases MIB IPCablecom ou dans dautres bases MIB normalises. Il est possible que des lm

42、ents IPCablecom implmentent des mthodes telles que SNMPv3, CMIP, TL1. Ces mcanismes de signalisation dvnement ne sont pas dfinis dans la prsente Recommandation. 6 Exigences fonctionnelles du mcanisme dvnement de gestion IPCablecom Les exigences fonctionnelles traites par la prsente Recommandation su

43、r le mcanisme dvnement de gestion IPCablecom sont les suivantes: 1) le rapport dvnement DOIT fournir ladresse FQDN ou IP du dispositif de signalisation; NOTE 1 Il est hautement recommand que le dispositif fournisse ladresse FQDN. 4 Rec. UIT-T J.172 (11/2005) 2) le mcanisme de signalisation dvnement

44、de gestion IPCablecom DOIT prendre en charge deux types dvnement: les vnements propres IPCablecom et les vnements propres au fournisseur; 3) le mcanisme de signalisation dvnement de gestion DOIT prendre en charge la base MIB dvnements de gestion IPCablecom (Annexe D/J.166). Tous les vnements qui peu

45、vent tre produits par le dispositif IPCablecom DOIVENT figurer dans la table MIB pktcDevEventDescrTable; 4) le mcanisme de signalisation dvnement de gestion IPCablecom DOIT prendre en charge le protocole BSD SYSLOG (norme RFC 3164); 5) le mcanisme de signalisation dvnement de gestion DOIT prendre en

46、 charge les interruptions SNMPv3/v2c et les informations SNMPv3/v2c; 6) le mcanisme de signalisation dvnement de gestion DOIT tre conforme aux applications SNMP (norme RFC 3413) car ces bases MIB fournissent le mcanisme de distribution des interruptions et informations SNMPv3. Les lments DOIVENT pre

47、ndre en charge un mcanisme permettant au systme de gestion dlment de faire correspondre chaque vnement un ou plusieurs mcanismes de notification signals. Par exemple: nant, local, SYSLOG, interruption SNMPv3, information SNMPv3; NOTE 2 Se reporter la Recommandation relative aux adaptateurs terminaux de support IPCablecom (Rec. UIT-T J.167) pour plus dinformations sur la configuration SNMP. 7) chaque vnement DOIT tre identifiable de faon unique par un point dorigine comme une extrmit spcifique dun adaptateu