1、UNIN INTERNACIONAL DE TELECOMUNICACIONESUIT-T Addndum 1SECTOR DE NORMALIZACIN Q.1400DE LAS TELECOMUNICACIONESDE LA UIT (02/95)RED INTELIGENTEMARCO DE ARQUITECTURAPARA DESARROLLAR PROTOCOLOSDE SEALIZACIN Y DE OPERACIONES,ADMINISTRACIN Y MANTENIMIENTOUTILIZANDO CONCEPTOS DE LAINTERCONEXIN DE SISTEMAS
2、ABIERTOSAddndum 1 a laRecomendacin UIT-T Q.1400(Anteriormente Recomendacin del CCITT)PREFACIOEl UIT-T (Sector de Normalizacin de las Telecomunicaciones) es un rgano permanente de la Unin Internacional deTelecomunicaciones (UIT). Este rgano estudia los aspectos tcnicos, de explotacin y tarifarios y p
3、ublica Recomen-daciones sobre los mismos, con miras a la normalizacin de las telecomunicaciones en el plano mundial.La Conferencia Mundial de Normalizacin de las Telecomunicaciones (CMNT), que se celebra cada cuatro aos,establece los temas que han de estudiar las Comisiones de Estudio del UIT-T, que
4、 a su vez producen Recomendacionessobre dichos temas.La aprobacin de Recomendaciones por los Miembros del UIT-T es el objeto del procedimiento establecido en laResolucin N. 1 de la CMNT (Helsinki, 1 al 12 de marzo de 1993).El addndum 1 a la Recomendacin UIT-T Q.1400 ha sido preparada por la Comisin
5、de Estudio 11 (1993-1996) delUIT-T, y fue aprobada por el procedimiento de la Resolucin N. 1 de la CMNT el 7 de febrero de 1995._NOTAEn esta Recomendacin, la expresin Administracin se utiliza para designar, en forma abreviada, tanto unaadministracin de telecomunicaciones como una empresa de explotac
6、in reconocida de telecomunicaciones. UIT 1995Es propiedad. Ninguna parte de esta publicacin puede reproducirse o utilizarse, de ninguna forma o por ningn medio,sea ste electrnico o mecnico, de fotocopia o de microfilm, sin previa autorizacin escrita por parte de la UIT.Addndum 1 a la Recomendacin (0
7、2/95) 1Addndum 1 a la Recomendacin Q.1400Addndum 1 a la Recomendacin (02/95)MARCO DE ARQUITECTURA PARA DESARROLLARPROTOCOLOS DE SEALIZACIN Y DE OPERACIONES,ADMINISTRACIN Y MANTENIMIENTO UTILIZANDO CONCEPTOSDE LA INTERCONEXIN DE SISTEMAS ABIERTOS(Ginebra, 1995)Se han acordado nuevas reglas sobre la c
8、ompatibilidad con respecto a anteriores y futuros protocolos especificados enASN.1 (compatibilidad hacia adelante y hacia atrs). Estas reglas son sencillas de utilizarse y se basan en lasltimas Recomendaciones de la serie X.680. Sobre ASN.1 la subclusula 12.5/Q.1400 (1993) se sustituye por el textos
9、iguiente:12.5 Reglas de compatibilidad para protocolos de capa de aplicacin especificados en ASN.1Se prev que de vez en cuando ser necesario introducir pequeas ampliaciones a un Protocolo de Aplicacin. Unasintaxis abstracta se ampla cuando se ampla su tipo asociado (es decir, si se trata de un tipo
10、seleccin, puede ampliarseaadiendo un nuevo componente o ampliando un componente existente). Un modo de ampliar una PDU (o cualquier tipoestructura) consiste en ampliar el tipo de cualquiera de sus componentes. Para soportar tales ampliaciones, es precisoasegurarse de que, en efecto son de carcter me
11、nor. Pueden considerarse menores las extensiones siguientes: adicin de un elemento de informacin que puede potenciar una actividad pero no es esencial pararealizar la actividad bsica (por ejemplo, lista de opciones de encaminamiento adicionales); adicin de un elemento de informacin para aadir una ca
12、pacidad que no es esencial para la capacidadbsica (por ejemplo, adicin de Nombre adems de Nmero a efectos de la visualizacin en elterminal).En los casos citados, no es necesario definir un nuevo nombre de Contexto de Aplicacin, pero el proceso de aplicacinreceptor debe incluir procedimientos de comp
13、atibilidad hacia adelante para tratar la informacin desconocida.Pueden considerarse mayores los siguientes tipos de ampliaciones: adicin de un nuevo procedimiento; cambio fundamental de un procedimiento (por ejemplo, aplicar este procedimiento dos veces).En los casos mencionados, debe definirse un n
14、uevo nombre de Contexto de Aplicacin.Las siguientes reglas de compatibilidad hacia adelante y hacia atrs se aplican a los protocolos de capa de aplicacinespecificados que utilizan ASN.112.5.1 Reglas de compatibilidad hacia atrsLas modificaciones de todas las futuras versiones de las Recomendaciones
15、del UIT-T sobre protocolos de sealizacinbasados en ASN.1 a partir de 1992 se llevarn a cabo de forma que se garantice la compatibilidad con versionesanteriores.El objetivo de las subclusulas siguientes es proporcionar directrices sobre los tipos de cambios que se pueden hacer auna especificacin de p
16、rotocolo asegurando la compatibilidad con el protocolo original.Los cambios que no afectan a la sintaxis de transferencia (es decir, los bits y bytes intercambiados entre entidades pares)o que la amplan, son compatibles. En otras palabras, la compatibilidad hacia atrs significa que una PDU codificad
17、a delprotocolo original es una PDU codificada vlida para el nuevo protocolo.Aparte de estos casos muy especficos, los cambios que no afectan a la sintaxis abstracta ni la amplan producen unasintaxis de transferencia compatible hacia atrs cuando se utilizan las reglas de codificacin bsica. Esos cambi
18、osfiguran en 12.5.1.1 y 12.5.1.2.Sin embargo, cuando no existen reglas de compatibilidad hacia adelante, slo se puede garantizar un adecuadointerfuncionamiento si los valores ampliados (es decir, los valores que pertenecen a la sintaxis abstracta ampliada perono a la original) no se envan nunca a un
19、a realizacin que slo admite el protocolo original.2 Addndum 1 a la Recomendacin (02/95)Los cambios no compatibles son aquellos que afectan la sintaxis de transferencia de forma no compatible. En este caso,una PDU codificada del protocolo original no es necesariamente una PDU codificada vlida para el
20、 nuevo protocolo.En general, un cambio no compatible desde el punto de vista de una sintaxis abstracta produce un cambio no compatibledesde el punto de vista de la sintaxis de transferencia. No obstante, puede haber algunas excepciones para un conjuntodado de reglas de codificacin.En 12.5.1.3 figura
21、n algunos ejemplos de esos cambios.Adems, es evidente que, en muchos casos la modificacin de las reglas de codificacin produce incompatibilidad desdeel punto de vista de la sintaxis de transferencia.12.5.1.1 Cambios sin repercusiones en la sintaxis abstractaEstos cambios se limitan estrictamente a l
22、a forma en que se especifican la sintaxis abstracta y el tipo utilizado para sudefinicin, y no afectan el conjunto de valores definidos por la sintaxis abstracta. Esos cambios pueden ser necesariospara armonizar una especificacin con las reglas indicadas en 12.5.1.2 y 12.5.1.3 de este addndum (esa l
23、ista no estnecesariamente completa).a) En un tipo de conjunto o tipo de secuencia, sustituir la utilizacin de COMPONENTS OF con lainclusin directa de los componentes equivalentes, o viceversa.b) En un tipo de opcin, sustituir los tipos de opcin anidados con la inclusin directa de cadaNamedType (tipo
24、 denominado) que aparece en la AlternativeTypeList (lista de tipos alternativos).c) Sustituir un tipo por una typereference (referencia de tipo) que representa el mismo tipo, o viceversa.d) Sustituir un valor por un valuereference (referencia de valor) que lo representa o viceversa: esto incluyela s
25、ustitucin de un number (nmero) por una valuereference.e) Sustituir un tipo por un tipo de seleccin equivalente o viceversa.f) Aadir o suprimir (si no se utiliza) uno o ms NamedBit (bit denominado) de un tipo de cadena de bits.g) Aadir o suprimir (si no se utiliza) uno o ms NamedNumber (nmero denomin
26、ado) de un tipo deentero.h) Cambiar sistemticamente la ortografa de typereference, modulereference (referencia de mdulo),valuereference o identifier (identificador) en todos los mdulos ASN.1. Esto incluye la adicin deidentificadores de la sintaxis cuando se permita.i) Dividir un mdulo ASN.1 en vario
27、s mdulos ASN.1.j) Reunir varios mdulos ASN.1 en un mdulo ASN.1.k) Trasladar partes de un mdulo ASN.1 a otro mdulo ASN.1.l) Aadir uno o ms Symbol (smbolo) a la lista EXPORTS. (O suprimir el enunciado EXPORTSpara indicar que todo se exporta).m) Aadir uno o ms Symbol a la lista IMPORTS (smbolos de mdul
28、os ASN.1 que ya aparecenreferenciados en la lista IMPORTS as como smbolos de mdulos ASN.1 referenciados nuevamente).n) Suprimir uno o ms Valueassignment (asignacin de valor) existentes si su valuereference asociadanunca se ha utilizado (ni siquiera implcitamente en la construccin ANY DEFINED BY) en
29、todos losmdulos ASN.1.o) Suprimir uno o ms Typeassignment (asignacin de tipo) existentes (incluidas aquellas del tipoOPERATION y ERROR) si nunca se han utilizado en todos los mdulos ASN.1.p) Aadir un tipo o valor ERROR ya incluido en la sintaxis abstracta (es decir, aadido a otro tipoOPERATION) a la
30、 lista de ERRORS de un tipo OPERATION si tena esa lista o aadir una lista deERRORS a un tipo OPERATION si no tena una lista.q) Aadir un tipo o valor OPERATION ya incluido en la sintaxis abstracta (por ejemplo, no como unaOperacin enlazada) a la lista de LINKED OPERATIONS de un tipo OPERATION si tena
31、 esa lista oaadir una lista de LINKED OPERATIONS a un tipo OPERATION si no tena una lista.Addndum 1 a la Recomendacin (02/95) 312.5.1.2 Ampliacin de una sintaxis abstractaSe amplia una sintaxis abstracta si se amplia su tipo asociado (es decir, si se trata de un tipo de opcin, se puede ampliaraadien
32、do un nuevo componente o ampliando uno existente). Una forma de ampliar una PDU (o cualquier tipoestructurado) es ampliar el tipo de cualquiera de sus componentes.Se considera que un tipo ASN.1 es una ampliacin de otro si el primero incluye todos los valores del segundo, yposiblemente algunos otros.
33、Dado un cierto tipo, sus ampliaciones son aquellos tipos que se podran derivar por uno o ms de los siguientes cambios,combinados con cualquier nmero de los descritos en la seccin 12.5.1.1.a) Cambiar un tipo simple en un tipo de opcin que incluya ese tipo en la AlternativeTypeList.NOTA 1 El rtulo de
34、esta alternativa ha de permanecer inalterado, no se permite ningn rtulo (EXPLICIT)adicional. Debe procurarse que todas las referencias a este tipo cambiado en todos los mdulos ASN.1 sigancumpliendo todos los requisitos ASN.1, en particular, que los rtulos sean distintos y los identificadores nicos.b
35、) Aadir uno o ms NamedType a la AlternativeTypeList de un tipo de opcin.NOTA 2 Vase la nota relativa al cambio de un tipo simple en un tipo de opcin.c) Aadir un componente opcional a un tipo de secuencia o a un tipo de conjunto.d) Aadir un componente por defecto a un tipo de secuencia o a un tipo de
36、 conjunto.e) Ampliar uno o ms componentes de un tipo de opcin, tipo de secuencia o tipo de conjunto.f) Ampliar el tipo con respecto al cual se define un tipo de secuencia o un tipo de conjunto.g) Cambiar un componente obligatorio de un tipo de secuencia o tipo de conjunto a un componente opcionalo p
37、or defecto.NOTA 3 El rtulo de este componente permanece inalterado y se debe asegurar la distincin de los rtulos.h) Aadir uno o ms nuevos NamedNumber a un tipo enumerado.NOTA 4 Se debe garantizar la distincin de valores y la unicidad de los identificadores.i) Ampliar el ValueRange (gama de valores)
38、de un tipo entero disminuyendo el LowerEndpoint (puntoextremo inferior) y/o aumentando el UpperEndpoint (punto extremo superior).j) Ampliar el SizeConstraint (constriccin de tamao) de un tipo de cadena de octetos, un tipo de cadenade bits o un tipo de cadena de caracteres disminuyendo el LowerEndpoi
39、nt y/o aumentando elUpperEndpoint.k) Ampliar el SizeConstraint de un tipo de secuencia o un tipo conjunto-de disminuyendo elLowerEndpoint y/o aumentando el UpperEndpoint.l) Cambiar el Value (valor) asignado a una valuereference si el efecto para todas las referencias cumplean todas las otras reglas
40、(por ejemplo, aumento de un valor utilizado slo como UpperEndpoint en unValueRange o SizeConstraint).Los siguientes cambios de la definicin OPERATION y ERROR afectan a la sintaxis abstracta formadapor el conjunto de valores cuyo tipo es el de los mensajes TCAP o las PDU ROSE parametrizados por unali
41、sta especfica de operaciones.m) Aadir una nueva definicin de valor de tipo OPERATION y ERROR, respectivamente, mientras seandistintas de otras definiciones de valor de tipo OPERATION y ERROR, respectivamente.n) Aadir un tipo como ARGUMENT/PARAMETER a un tipo OPERATION si no tena unARGUMENT/PARAMETER
42、.o) Aadir un tipo como RESULT a un tipo OPERATION si tena un RESULT vaco o ningn RESULT.p) Aadir un tipo como PARAMETER a un tipo ERROR si no tena un PARAMETER.12.5.1.3 Cambios no compatiblesLos cambios producen incompatibilidad desde el punto de vista de la sintaxis abstracta cuando un valor de la
43、sintaxisabstracta original no es un valor vlido para la nueva sintaxis abstracta.Un cambio no compatible al tipo o tipos con respecto a los cuales se define una sintaxis abstracta produce unaincompatibilidad entre la sintaxis abstracta original y la nueva.4 Addndum 1 a la Recomendacin (02/95)En la l
44、ista que figura a continuacin aparecen algunos ejemplos de esos cambios no compatibles: sustituir un tipo por otro aunque el rtulo siga siendo el mismo; suprimir una definicin de tipo o una definicin de valor al que se hace referencia explcita (IMPORTS) oimplcitamente (ANY DEFINED BY de TCAP); supri
45、mir un NamedType desde la AlternativeTypeList de un tipo de opcin; suprimir un NamedNumber de Enumeration (enumeracin) de un tipo enumerado; limitar el ValueRange de un tipo de entero; limitar el SizeConstraint de un tipo de cadena; limitar el SizeConstraint de un tipo secuencia-de; cambiar el orden
46、 de los elementos en la ElementTypeList de un tipo de secuencia; hacer cualquier combinacin de los cambios mencionados de uno o ms componentes de un tipoestructurado.12.5.2 Reglas de compatibilidad hacia adelanteEn la mayora de los casos, la compatibilidad hacia adelante se alcanza mediante negociac
47、in del contexto de aplicacin.Sin embargo, para minimizar el nmero de repliegues de protocolo en la red de sealizacin a veces ser necesariodefinir reglas de compatibilidad hacia adelante que permitan una versin de un protocolo aceptar unidades de datos deprotocolo generadas por una futura versin sin
48、tener que suministrar un nuevo nombre de contexto de aplicacin.Esto es necesario tambin cuando no se admite negociacin de contexto de aplicacin, por ejemplo, cuando no se admiteuna parte de dilogo opcional de TC.Si el diseador de protocolo desea asegurar de que el valor de una PDU de la nueva versin de un protocolo sea siempre(al menos) parcialmente reconocida por una realizacin de una versin ms antigua de ese protocolo, deben seguirse lassiguientes directrices: la nueva versin del proto
