ITU-T J 172 SPANISH-2005 IPCablecom management event mechanism《个人间电缆通信(IPCablecom)管理事件机制 9号研究组》.pdf

《ITU-T J 172 SPANISH-2005 IPCablecom management event mechanism《个人间电缆通信(IPCablecom)管理事件机制 9号研究组》.pdf》由会员分享，可在线阅读，更多相关《ITU-T J 172 SPANISH-2005 IPCablecom management event mechanism《个人间电缆通信(IPCablecom)管理事件机制 9号研究组》.pdf（24页珍藏版）》请在麦多课文档分享上搜索。

1、 Unin Internacional de TelecomunicacionesUIT-T J.172SECTOR DE NORMALIZACIN DE LAS TELECOMUNICACIONES DE LA UIT (11/2005) SERIE J: REDES DE CABLE Y TRANSMISIN DE PROGRAMAS RADIOFNICOS Y TELEVISIVOS, Y DE OTRAS SEALES MULTIMEDIA IPCablecom Mecanismo de evento de gestin IPCablecom Recomendacin UIT-T J.

2、172 Rec. UIT-T J.172 (11/2005) i Recomendacin UIT-T J.172 Mecanismo de evento de gestin IPCablecom Resumen En esta Recomendacin se define el mecanismo de evento de gestin que los elementos IPCablecom pueden utilizar para informar eventos asncronos que indican situaciones de funcionamiento defectuoso

3、 y para notificar situaciones importantes en las que no hay averas. En esta Recomendacin se definen los eventos como condiciones que exigen la notificacin de informacin a sistemas de gestin y/o un registro local. Uno de los objetivos de IPCablecom es mantener la coherencia con el mecanismo de notifi

4、cacin de informacin de eventos de mdem de cable. Orgenes La Recomendacin UIT-T J.172 fue aprobada el 29 de noviembre de 2005 por la Comisin de Estudio 9 (2005-2008) del UIT-T por el procedimiento de la Recomendacin UIT-T A.8. ii Rec. UIT-T J.172 (11/2005) PREFACIO La UIT (Unin Internacional de Telec

5、omunicaciones) es el organismo especializado de las Naciones Unidas en el campo de las telecomunicaciones. El UIT-T (Sector de Normalizacin de las Telecomunicaciones de la UIT) es un rgano permanente de la UIT. Este rgano estudia los aspectos tcnicos, de explotacin y tarifarios y publica Recomendaci

6、ones sobre los mismos, con miras a la normalizacin de las telecomunica-ciones en el plano mundial. La Asamblea Mundial de Normalizacin de las Telecomunicaciones (AMNT), que se celebra cada cuatro aos, establece los temas que han de estudiar las Comisiones de Estudio del UIT-T, que a su vez producen

7、Recomendaciones sobre dichos temas. La aprobacin de Recomendaciones por los Miembros del UIT-T es el objeto del procedimiento establecido en la Resolucin 1 de la AMNT. En ciertos sectores de la tecnologa de la informacin que corresponden a la esfera de competencia del UIT-T, se preparan las normas n

8、ecesarias en colaboracin con la ISO y la CEI. NOTA En esta Recomendacin, la expresin “Administracin“ se utiliza para designar, en forma abreviada, tanto una administracin de telecomunicaciones como una empresa de explotacin reconocida de telecomunicaciones. La observancia de esta Recomendacin es vol

9、untaria. Ahora bien, la Recomendacin puede contener ciertas disposiciones obligatorias (para asegurar, por ejemplo, la aplicabilidad o la interoperabilidad), por lo que la observancia se consigue con el cumplimiento exacto y puntual de todas las disposiciones obligatorias. La obligatoriedad de un el

10、emento preceptivo o requisito se expresa mediante las frases “tener que, haber de, hay que + infinitivo“ o el verbo principal en tiempo futuro simple de mandato, en modo afirmativo o negativo. El hecho de que se utilice esta formulacin no entraa que la observancia se imponga a ninguna de las partes.

11、 PROPIEDAD INTELECTUAL La UIT seala a la atencin la posibilidad de que la utilizacin o aplicacin de la presente Recomendacin suponga el empleo de un derecho de propiedad intelectual reivindicado. La UIT no adopta ninguna posicin en cuanto a la demostracin, validez o aplicabilidad de los derechos de

12、propiedad intelectual reivindicados, ya sea por los miembros de la UIT o por terceros ajenos al proceso de elaboracin de Recomendaciones. En la fecha de aprobacin de la presente Recomendacin, la UIT no ha recibido notificacin de propiedad intelectual, protegida por patente, que puede ser necesaria p

13、ara aplicar esta Recomendacin. Sin embargo, debe sealarse a los usuarios que puede que esta informacin no se encuentre totalmente actualizada al respecto, por lo que se les insta encarecidamente a consultar la base de datos sobre patentes de la TSB en la direccin http:/www.itu.int/ITU-T/ipr/. UIT 20

14、06 Reservados todos los derechos. Ninguna parte de esta publicacin puede reproducirse por ningn procedimiento sin previa autorizacin escrita por parte de la UIT. Rec. UIT-T J.172 (11/2005) iii NDICE Pgina 1 Alcance . 1 2 Referencias . 1 2.1 Referencias normativas 1 2.2 Referencias informativas 1 3 T

15、rminos y definiciones . 2 4 Abreviaturas, siglas, acrnimos y convenios 2 4.1 Abreviaturas siglas o acrnimos. 2 4.2 Convenios. 2 5 Antecedentes. 3 6 Requisitos funcionales del mecanismo de evento de gestin IPCablecom 3 7 Mecanismo de informacin de eventos de gestin. 5 7.1 Categoras de notificacin de

16、eventos 5 7.2 Formato de evento de gestin IPCablecom 5 7.3 Mtodo de acceso al evento de gestin IPCablecom 6 7.4 ID del evento de gestin. 6 7.5 Severidades de los eventos de gestin 6 7.6 Mecanismo de notificacin. 7 7.7 Registro cronolgico local de eventos 7 7.8 Syslog . 8 8 Plantilla de datos de los

17、eventos de gestin IPCablecom. 11 Anexo A Eventos de aprovisionamiento definidos por IPCablecom 12 Anexo B Eventos de energa definidos por IPCablecom 15 Rec. UIT-T J.172 (11/2005) 1 Recomendacin UIT-T J.172 Mecanismo de evento de gestin IPCablecom 1 Alcance En esta Recomendacin se define el mecanismo

18、 de evento de gestin que los elementos IPCablecom pueden utilizar para informar eventos asncronos que indican situaciones de funcionamiento defectuoso y para notificar situaciones importantes en las que no hay averas. En esta Recomendacin se definen los eventos como condiciones que requieren la comu

19、nicacin de informacin a sistemas de gestin y/o a un registro cronolgico local. Uno de los objetivos de IPCablecom es mantener la coherencia con el mecanismo de informacin de evento de mdem de cable. 2 Referencias 2.1 Referencias normativas Las siguientes Recomendaciones del UIT-T y otras referencias

20、 contienen disposiciones que, mediante su referencia en este texto, constituyen disposiciones de la presente Recomendacin. Al efectuar esta publicacin, estaban en vigor las ediciones indicadas. Todas las Recomendaciones y otras referencias son objeto de revisiones por lo que se preconiza que los usu

21、arios de esta Recomendacin investiguen la posibilidad de aplicar las ediciones ms recientes de las Recomendaciones y otras referencias citadas a continuacin. Se publica peridicamente una lista de las Recomendaciones UIT-T actualmente vigentes. En esta Recomendacin, la referencia a un documento, en t

22、anto que autnomo, no le otorga el rango de una Recomendacin. Recomendacin UIT-T J.164 (2005), Requisitos de los mensajes de evento para el soporte de servicios en tiempo real transmitidos mediante redes de televisin por cable que utilizan mdems de cable. Recomendacin UIT-T J.166 (2005), Marco de las

23、 bases de informacin de gestin IPCablecom. Recomendacin UIT-T J.167 (2005), Requisitos del aprovisionamiento de un dispositivo adaptador de terminal de medios para la entrega de servicios en tiempo real por redes de televisin por cable que utilizan mdems de cable. Recomendacin UIT-T M.3100 (2005), M

24、odelo genrico de informacin de red. Recomendacin UIT-T X.733 (1992), Tecnologa de la informacin Interconexin de sistemas abiertos Gestin de sistemas: Funcin sealadora de alarmas. IEFT RFC 3164 (2001), The BSD syslog Protocol. 2.2 Referencias informativas Recomendacin UIT-T J.160 (2005), Arquitectura

25、 para la distribucin de servicios dependientes del tiempo por redes de televisin por cable que utilizan mdems de cable. Recomendacin UIT-T J.168 (2001), Requisitos de la base de informacin de gestin de un adaptador de terminal de medios IPCablecom. IETF RFC 2573 (1999), SNMP Applications. 2 Rec. UIT

26、-T J.172 (11/2005) IETF RFC 2670 (1999), Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces. ANSI/SCTE 23-3-2003, DOCSIS 1.1 Part 3: Operations Support System Interface. 3 Trminos y definiciones En esta Recomendacin no se definen nuevos trminos. 4 Abre

27、viaturas, siglas, acrnimos y convenios 4.1 Abreviaturas siglas o acrnimos En esta Recomendacin se utilizan las siguientes abreviaturas, siglas o acrnimos. CMS Servicio de gestin de llamadas (call management server) CMTS Sistema de terminacin de mdem de cable (cable modem termination system) FQDN Nom

28、bre de dominio totalmente cualificado (fully qualified domain name) (vase IETF RFC 821 para ms detalles) IANA Autoridad de asignacin de nmeros Internet (Internet assigned numbers authority) MAC Control de acceso a medios (media access control) MGC Controlador de pasarela de medios (media gateway con

29、troller) MIB Base de informacin de gestin (management information base) MTA Adaptador de terminal de medios (media terminal adapter) OSS Sistema de soporte de operaciones (operations support system) SNMP Protocolo simple de gestin de red (simple network management protocol) UDP Protocolo de datagram

30、a de usuario (user datagram protocol) 4.2 Convenios Al implementar esta Recomendacin, se tendr en cuenta que la obligatoriedad de la especificacin se expresa mediante el verbo modal “DEBER“ (verbo modal ingls MUST) o un verbo en tiempo futuro con valor imperativo, por ejemplo “expirar“ (verbo modal

31、ingls SHALL) o el adjetivo “OBLIGATORIO“ (REQUIRED). A continuacin, se indican otras expresiones que se aplican a determinados requisitos con significado de obligacin o posibilidad. “DEBER“ (MUST) Este verbo (u otros con significado de obligacin, como “tener que/de“, “haber que/de“) o un verbo en ti

32、empo futuro con valor imperativo o el adjetivo “OBLIGATORIO“ (REQUIRED, MANDATORY) indican que se tiene la obligacin de hacer lo que expresa la Recomendacin. “NO DEBER“ (MUST NOT) La negacin indica que se prohbe hacer lo que expresa la Recomendacin. “DEBERA“ (SHOULD) El modo condicional de estos ver

33、bos, u otros verbos con significado de conveniencia (aconsejar, recomendar, ser conveniente) o el adjetivo “RECOMENDADO“ (RECOMMENDED) indica que puede haber motivos fundados para que en determinadas circunstancias no se haga cierta cosa, pero que antes de hacer algo diferente, es preciso entender t

34、odas las consecuencias y sopesar el caso. Rec. UIT-T J.172 (11/2005) 3 “NO DEBERA“ (SHOULD NOT) La negacin indica la posibilidad de que haya motivos fundados para que en determinadas circunstancias la accin sea aceptable e incluso til, pero que antes de realizarla es preciso entender todas las conse

35、cuencias y sopesar el caso. “PODER“ (MAY) ste u otros verbos que indican posibilidad o probabilidad (deber de,) o el adjetivo “FACULTATIVO“ u “OPCIONAL“ (OPTIONAL) se refieren a la libertad de elegir. Un proveedor puede incluir un elemento porque el mercado lo exige o porque mejora el producto, mien

36、tras que otro puede optar por no hacerlo. 5 Antecedentes La arquitectura IPCablecom es una arquitectura de banda ancha de extremo a extremo que soporta servicios de voz, vdeo y otros servicios multimedia. Los componentes individuales que integran la arquitectura IPCablecom se definen en la Rec. UIT-

37、T J.160. El sistema de fondo de oficina, o de tareas administrativas, OSS contiene componentes comerciales, de servicio y de gestin de red que soportan los procesos comerciales fundamentales. En la serie de Recomendaciones sobre IPCablecom se define un conjunto limitado de componentes funcionales OS

38、S e interfaces que soportan el aprovisionamiento de dispositivos MTA, mensajera de eventos para transportar informacin de facturacin, y el mecanismo de evento de gestin definido en esa Recommendacin para transportar informes de averas y otros datos. Adems del mecanismo de evento de gestin, la arquit

39、ectura IPCablecom soporta los siguientes mecanismos de informacin adicionales: Mensajes de eventos IPCablecom de la Rec. UIT-T J.164. Este mecanismo de informacin utiliza el protocolo de transporte RADIUS, un conjunto predefinido de atributos de mensajes de eventos (por ejemplo, BillingCorrelationID

40、, CalledPartyNumber, TrunkGroupID, etc.), y el formato de datos de mensajes de eventos IPCablecom para transportar informacin de cada llamada entre elementos de red IPCablecom (CMS, CMTS, MGC) y un servidor de mantenimiento de registro (RKS, record keeping server). El RKS combina, para cada llamada,

41、 todos los mensajes de eventos asociados en un solo registro de detalles de la llamada (CDR, call detail record) el cual debe enviarse al sistema de tareas administrativas para efectos de facturacin, al sistema de deteccin de fraudes o a cualquier otro sistema. Es posible incluir atributos de datos

42、privados del vendedor junto con el conjunto de atributos definido para IPCablecom en un mensaje de evento IPCablecom. Otros mtodos de informacin. Es posible que los elementos de IPCablecom implementen mtodos de informacin especificados en MIB de mdem de cable, MIB de IPCablecom o en otras MIB normal

43、izadas. Tambin existe la posibilidad de que los elementos de IPCablecom empleen mtodos tales como SNMPv3, CMIP, TL1. Estos mecanismos de informacin de evento no se definen en esta Recomendacin. 6 Requisitos funcionales del mecanismo de evento de gestin IPCablecom Los requisitos funcionales tratados

44、en la Recomendacin sobre el mecanismo de evento de mensaje son los siguientes: 1) El informe de eventos DEBE proporcionar el FQDN o la direccin IP del dispositivo de informacin. NOTA 1 Se recomienda firmemente que el dispositivo proporcione el FQDN. 2) El mecanismo de informacin de eventos de gestin

45、 IPCablecom DEBE soportar dos tipos de eventos: los especficos de IPCablecom y los especficos del fabricante. 4 Rec. UIT-T J.172 (11/2005) 3) El mecanismo de informacin de eventos de gestin DEBE soportar la MIB de eventos de gestin de IpCablecom (anexo D/J.166). Deben incluirse en el cuadro pktcDevE

46、ventDescrTable de la MIB todos los eventos que el dispositivo IPCablecom est en capacidad de generar. 4) El mecanismo de informacin de los eventos de gestin IPCablecom DEBE soportar el protocolo SYSLOG de BSD con arreglo a la RFC 3164. 5) El mecanismo de informacin de eventos de gestin DEBE soportar

47、 TRAPS de SNMPv3/v2c e INFORMS de SNMPv3/v2c. 6) El mecanismo de informacin de eventos de gestin DEBE acatar SNMP Applications (RFC 3413) ya que estas MIB sealan el mecanismo para la distribucin de TRAMPAS e INFORMES SNMPv3. Los elementos DEBEN soportar un mecanismo que permita que el sistema de ges

48、tin de elementos haga corresponder cada evento a uno o ms mecanismos de notificacin informados. Por ejemplo: ninguno, local, SYSLOG, SNMPv3 TRAP, SNMPv3 INFORM. NOTA 2 La Recomendacin sobre aprovisionamiento de dispositivos adaptadores de terminal de medios de IPCablecom (Rec. UIT-T J.167) contiene

49、ms informacin sobre la configuracin de SNMP. 7) Cada evento DEBE identificarse en forma nica hasta el punto de origen tal como un determinado punto extremo en un MTA. 8) SE DEBERA disponer de la capacidad para hacer corresponder los ID de eventos a las prioridades en el sistema de tareas administrativas (o de fondo de oficina). 9) Los